タグ

開発に関するkkotyyのブックマーク (15)

  • 接触確認アプリCOCOAからの教訓|情報処理学会・学会誌「情報処理」

    楠 正憲(内閣官房 政府CIO 補佐官) 2021年1月 Android版の接触確認アプリCOCOAが数カ月にわたって動作していなかったことが明らかにされた.筆者は 2020年4月から接触確認アプリの導入について,有志での議論に参加し,有識者会議のメンバとして,また途中から政府CIO補佐官として, 接触確認アプリの導入を支援してきた.稿では接触確認アプリCOCOAの開発と運用について,どのような課題があったかについて振り返る. 接触確認アプリ導入の経緯 筆者が接触確認アプリについて知ったのは昨年(2020年)3月頃のことである.ちょうどシンガポールのTrace Togetherが話題となって,日でも接触確認アプリをリリースできないかといった話題で,いくつかのコミュニティが盛り上がり始めた. Androidのシェアが高いシンガポールに対して,日ではiPhoneのシェアが非常に高く,iP

    接触確認アプリCOCOAからの教訓|情報処理学会・学会誌「情報処理」
  • 俺が考える最強の新規サービス開発フロー - 小さなお城

    インターネットサービスを想定した理想を書いてます。 エンジニアリングに特化した話ではなく、アイディアを思いついてからリリースするくらいまでの浅く広い話で、個人的な趣向であり、組織や環境によっては合わないかもしれません。 とりあえず、リーン・スタートアップとアジャイルサムライ−達人開発者への道−は、すごくいいで勉強させていただきました。 アイディアを整理します 実現したいアイディアが解決するユーザプロブレム、提供する価値を整理します。 例えば、 ● ユーザプロブレム: お腹いっぱい美味しいものをべたい! ● 提供する価値  : 安くて美味しくて腹持ち良いべ物屋さん アイディアの簡単なペルソナを想像します ペルソナとは提供するサービスの一番の顧客になってくれる人の人物像です。 例えば、 G太、小学1年生男児。体重40kg。 頭はおにぎりのような形をしており、10円ハゲがある。 小学校では

    俺が考える最強の新規サービス開発フロー - 小さなお城
  • 自社製品で食べていけるようになるまでやったこと

    ミドルウェアのパッケージ製品でべていけるようになるまでやったことを自分のメモ代わりにまとめておきます。 製品の事業計画を明確にしない自分が想定したとおりに行くことが少ないこともあり事業計画を書いたりしません。日々の状況を見ながら判断をしていくということをしています。そのため中長期的な計画は品質の向上くらいにしておき、機能追加に関してはその度々に考えて実装していくのが一番です。 変化が早い分野でもあるので、事業計画を用意するメリットが零細企業にはないと考えています。 リリース前の開発進捗を共有するステルスはデメリットが多いと判断し、今開発しているもの開発中の状況などを共有しました。これは「製品をステルスで開発して、出したとしても買ってもらうまでの時間がかかる」と考えたからです。 それよりはあの会社があんなの作ってるそろそろ出るらしいと思ってもらえたほうが検討してもらいやすくなります。 今、

  • システム発注側の愚痴

    朝も早くから目が覚めたので、出社前に愚痴っとく。 当方のスペックは ・30代、化学系メーカに勤務。 ・大学での専攻は情報系ではない。パソコンは趣味でいじってきた。 1. SIerへの思い ・毎回、見積もりの度に「何人月ですか?」と聞くが、聞いてる私だって無意味な質問だと思ってるよ。 すまん、私の説明が悪すぎるのか、こっちの決裁権者は上から下まで人月でしか理解できないんだよ。 妥当かどうかはわからんけど、例えばソースの行数単価とか、プログラムの容量単価とかで説明したこともある。「訳がわからないから、やっぱり人月で表現してくれ」と言われたがな。 ・要求する機能に対して短い納期を設定しているが、「なんとかします」って言ってくれてありがとう。無理をねじ込んでごめん。 私にはお金関係を決裁する権限もなければ給料も安いから、ありがとう、ごめんと言うしかできない。 ・毎年「保守費、下がりませんか?」とお

    システム発注側の愚痴
    kkotyy
    kkotyy 2017/04/13
    耐えるも良し、転職するも良し。
  • System of Record と System of Engagement

    補足を以下に記載しています: https://www.wantedly.com/companies/ikyu/post_articles/42802

    System of Record と System of Engagement
    kkotyy
    kkotyy 2016/11/14
    「SoRが得意な人たちへのリスペクト」そうだなぁ。分断されがち。
  • 良いデバッグログはプロジェクトの資産である

    http://eventdots.jp/event/591027 (2016-07-30追記:Rails 5.0からproductionでもDEBUGがデフォルトらしいです) (2020-09-23追記:https://github.com/rails/rails/pull/39707 INFOに戻りそう)

    良いデバッグログはプロジェクトの資産である
    kkotyy
    kkotyy 2016/08/01
    "チームメンバーが理解できれば簡潔にして良い"というのは、人が入れ替わる際に引き継ぐ"コンテキスト"が多くなるのであまり同意できない。その他は良いこと言ってる。
  • 某S社のddd(メイリオ)

    2. 自己紹介 名前@kumake1004 ‒ Sansan 株式会社 アプリケーションエンジニア ‒ 2011年入社 (5年目) 仕事 ‒ 法人向け名刺管理アプリのサーバーサイド実装 ‒ アプリエンジニアインフラエンジニアの板挟みにあうこと 興味 ‒ .NET (C#) / DDD / テスト / マネジメント 3. どうしてこうなった駆動開発とは 職場で DDD 導入したら失敗しました ‒ (個人の感想です) 再挑戦を始めたところ、、、 ‒ 漠然と思いはあって、良い機会なので振り返って言語化します ‒ という普通の失敗事例紹介 つまりただの出オチ 4. - 実践ドメイン駆動設計 コアドメイン (スクラム) における集約の使用 “彼らには DDD の経験があまりなかった。そのため、チームは DDD に関 してちょっとした間違いを犯した。” “最終的に彼らは、自分たちが集約を扱った経験を

    某S社のddd(メイリオ)
    kkotyy
    kkotyy 2015/08/10
    良い話。発表をききたかった。自分達の力量を知るというのは新たなチャレンジをするときは無理な話なので、スモールスタートするしかないと思う。さもなくば屍が積み上がる。
  • CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」

    社内ライブラリを8年間に渡って作り、サポートし続けてきた講演者が、1~2年で完成するだろうという当初の想定とは裏腹に、なかなか進まない作業、得られないサポート、バグの押し付け合い、それら数々の修羅場から得られた、技術面およびサポート面でのノウハウをお伝えします。 http://cedec.cesa.or.jp/2014/session/ENG/8073.html ※2014/9/4にCEDEC2014@パシフィコ横浜で行った講演です。Read less

    CEDEC2014 「ライブラリを作ってはいけない ~それでも作りたいあなたへのアドバイス~」
    kkotyy
    kkotyy 2015/02/14
    つらい話
  • 日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経

    最近ネットで話題になったスライド「ウォーターフォールの歴史」を見ながら、むしろ皆の仮想敵はウォーターフォールではなく、日型ソフトウェアファクトリーなのではないかと考えた次第。 最近アジャイル界隈でよく聞く話 「自分の現場がウォーターフォールで全然ダメで それをアジャイルなら変えられないかと思って」 いったい誰と戦っているんだ・・・・・・ History of WaterFall - Speaker Deck 真の敵はこいつだ! ソフトウェアファクトリ software factory / ソフトウェア工場 / ソフトウェア生産工場 組織的ソフトウェア開発アプローチの1つで、ソフトウェア開発に関する手順、手法、ツールを標準化してノウハウや知識、成果物の蓄積と再利用を促進し、厳格な工程管理・品質管理を適用することで、ソフトウェア開発の生産性と品質を向上することを目指すコンセプトのこと。また、

    日本型ソフトウェアファクトリーこそ真の敵 - 勘と経験と読経
    kkotyy
    kkotyy 2012/07/18
    "プロセスやツールの改善、ノウハウの集約などには力が入れられる(ただし、効果があるのかは別の話)" まったくもって別の話。
  • xUnit成熟度モデル 〜あなたの組織はどのレベル? - 谷本 心 in せろ部屋

    エントリーは、Software Test & Quality Advent Calendar 2011の10日目です。 http://atnd.org/events/22833 前の9日目は @m_seko さんの 「負荷テスト対象のWebアプリがこういう非機能要件(+α)を備えていたらいいのにという願望」です。 http://d.hatena.ne.jp/sekom/20111209 普段、品質やテストなどには興味なさそう(?)にしている私ですが、 たまには、エンジニア視点から、テストについて語ってみましょう。 xUnit成熟度モデルって? xUnit成熟度モデルとは、 組織がxUnitをより適切に利用できるようになることを目的として 遵守するべき指針を体系化したものである。 あわせて読みたい : 能力成熟度モデル統合 (CMMI) - Wikipedia 正味の話で言うと、僕がJUn

    xUnit成熟度モデル 〜あなたの組織はどのレベル? - 谷本 心 in せろ部屋
    kkotyy
    kkotyy 2011/12/10
    当社は、、、コメント自粛。。。
  • 5つの世界 - The Joel on Software Translation Project

    Joel Spolsky ジョエル・スポルスキ 翻訳: Yasushi Aoki 青木靖 2002/5/6 ある重要なことがプログラミングやソフトウェア開発についての文献でほとんど語られず、そのため私たちは互いに誤解する結果となっている。 あなたはソフトウェア開発者だ。私もそうだ。しかし私たちの目的や要求は異なっているかもしれない。実際、ソフトウェア開発にはいくつかの異なる世界があり、異なった世界ではルールも異なっている。 あなたがUMLモデリングのを読んでも、それがデバイスドライバのプログラムを作るのには役立たないということはどこにも書かれていない。あるいは「(.NETに必要な)20MBのランタイムは問題ではない」というアーティクルを読んでも、それは当たり前のことに触れていない:あなたがROMが32KBの携帯電話のためのコードを書いているなら、それは十分に問題だ! ソフトウェア開発には

    kkotyy
    kkotyy 2011/06/16
    "コンサルウェアはパッケージソフトの変種のひとつで、多くのカスタマイズを必要とし、インストールには一群のコンサルタントが必要となり、法外なコストがかかる。"
  • Joshua Kerievsky 氏講演会「リファクタリングの戦略と戦術」 - 科学と非科学の迷宮

    概要 URL http://patterns-wg.fuka.info.waseda.ac.jp/JK2010.html 日時 2010/03/18 18:30 - 20:30 場所 国立情報学研究所(学術総合センター) 12階 会議室 twitterハッシュタグ #PWG_JK 講演タイトル Refactoring Strategies & Tactics 講演者 Joshua Kerievsky (Industrial Logic, Inc. and Cutter Consortium) 「パターン指向リファクタリング入門」の著者。 パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法 作者: ジョシュア・ケリーエブスキー,小黒直樹,村上歴,高橋一成,越智典子出版社/メーカー: 日経BP社発売日: 2005/08/04メディア: 単行購入: 11人 クリック: 31

    Joshua Kerievsky 氏講演会「リファクタリングの戦略と戦術」 - 科学と非科学の迷宮
    kkotyy
    kkotyy 2011/04/07
    "手動テストは20世紀のものです" "リファクタリングの前に充分なテストカバレッジが必要です" "テストの自動化はイノベーションを加速する"
  • Part1 ソフトウエアのフレームワークとはなにか

    フレームワークの使い方を表層的にマスターするだけでも,アプリケーションの開発ができないわけではありません。しかし,フレームワークについて深い知識があれば,アプリケーションの構造が分かるので見通しよく開発できるようにになります。 Part1では,まずフレームワークの質を理解します。そのうえで,エンタープライズ(業務)アプリケーションの基的なアーキテクチャと,その中でフレームワークがどのように使われるのかを説明します。 日少子化問題を解決する方法を提言しなさい――突然,このような課題を与えらた場合,すぐに課題解決のための作業に着手できる人はどのくらいいるでしょうか? 人間はどんな課題を解決しようとするときも,アプローチの切り口や物事の考え方を示されなかったら,何をしてよいかわからず途方に暮れてしまうものです。そこで登場するのが,一般的な意味での「フレームワーク」です。フレームワークとは

    Part1 ソフトウエアのフレームワークとはなにか
  • チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ

    Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は

    チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ
    kkotyy
    kkotyy 2011/03/05
    "チケットが増えて困るというのなら、それはプロジェクト運営として他に原因がある"
  • ソフトウェアエンジニアのためのホームページ Presented by System Creates Inc.

  • 1