綴ります。プログラミング、アプリ開発について。
3.2 小さいほどよい 3.3 アジャイルの実践 内容 アジャイルでは、長距離ランナーのように小さなラップでゴールまでの道のりを徐々に明確にしていくことを良しとしている。 プロジェクトが計画が立てづらい理由は様々だが、惰性ではない。 ポイントになるのは、小さなスコープ、仕事を決めていき、それをタイムボックスの中で消化していく。タイムボックスは１イテレーション１〜２週間にすることが多いが、重要なのは期間ではなく、小さくスコープ、仕事を分けられているかどうか。 それが明確なゴールへと近づけてくれる。 この点を理解していないと、アジャイルしているとは言えない。 ソフトウェアは物理法則に従っていないため、同じように捉えると痛い目に合う。そして群を抜いて不安定なので、小さく確実に進めたほうがよい。 学び 小さな仮説検証サイクルを回すために小さなタスクをつくる 学びを活かすアイディア・行動 大きな案件は小さいタスクにちぎる
3 賢人による新しいアイデア 3.1 アジャイルへの入門 内容 2000年終わり頃から開発プロセスはアジャイルへと向かっている。 エドワード・デミングは戦後、アメリカからやって来て日本復興のために取り組んだ。 フォーカスしたのは、「無駄をなくし、取り組むべき課題を継続的に改善すること」。 その考え方はトヨタに取り込まれ、トヨタ生産方式となり、やがてアメリカに逆輸入され、リーンやスクラムの基礎となった。 ソフトウェア開発において無駄なのは「着手したものの、完了しておらず、まだ価値を提供していないすべての仕事」という考えで、これをベースにXP、スクラム、リーンが生まれた。 学び アジャイルの歴史を知れた。トヨタ生産方式がアメリカの方が原案を持ってきたんだということを知れた。 アジャイルの基本思想が、「無駄をなくし継続的に改善すること」 学びを活かすアイディア・行動 今は思い浮かばない
2.4 失敗のコスト 2.4.1 ここにも１０億ドル、あそこにも１０億ドル 2.4.2 新しい研究、相変わらず危機 内容 ソフトウェア開発にはとにかくコストがかかっていて２００２年時点ではアメリカだけで年間６００億ドルの損失がある。 コストの内訳を見てみると、リリース後のコストが多く、最大で８０％増しにかかっている。 それは保守性に重きをおいてこなかったから。 学び 保守性はコストで図れるかもしれない。 ランニングコストがどれくらいかかっているかを測るのは重要。 学びを活かすアイディア・行動 何にいくらかかっているか、利益がどれくらいかを出す
2.3 プロジェクトがなぜ失敗するのか 2.3.1 コードの変更 2.3.2 蔓延 2.3.3 複雑性の危機 内容 失敗する理由を大きく分けると２つ。 ビジネスの優先度変化や市場ニーズの変化などの開発側がコントロールできないことが要因 技術プラクティス不足による開発側の要因 技術プラクティス不足が招いてる原因はさらに３つに分けられる。 コード変更ができない バグの修正が時間がかかる 複雑さが増している コード変更ができない大きな改修する場合、多くのチームは既存のコードや設計を理解しようとせず、自分たちのやり方でやる傾向にある。それはコードが複雑でわかりにくいから。結果として一貫性がなくなり、さらに変更しづらいコードになる。 バグの修正が時間がかかる何が時間がかかるかって、大量コードの中からバグを見つけること。どれだけバグを見つけやすい作りになっているかが重要。 複雑さが増している調査によると使っていない機能が45%もある。なのに残っているから複雑になり、バグが見つけられなくなる。バグ修正に時間がかかる件に関連しているが、このせいで開発の80％はバグ修正にコストをかけていると調査結果が出ている。 学び 複雑さが保守不可能にしてる 学びを活かすアイディア・行動 保守しやすいアーキテクチャを考える
2. CHAOSレポート再考 2.1 CHAOSレポート 2.1.1 成功 2.1.2 問題あり 2.1.3 失敗 2.2 スタンディッシュレポートの誤り 内容 CHAOSレポートとは「ソフトウェアは何らかの理由でよく失敗する」ということがわかったレポート。 CHAOSレポートの詳細スタンディッシュグループというソフトウェア業界の調査機関が調査した。「初期仕様を納期内、予算内に作ることができたか」という観点で以下の結果に分類している。 成功・・・納期内、予算内にできた 問題あり・・・納期は過ぎた、または予算は越えた 失敗・・・キャンセルされた、リリースできなかった 1994〜2012まで実施。34000PJを対象に毎年10年前の3400PJを新しい3400PJと入れ替えながら調査。 成功率は1/8から1/3に上がったものの、そもそも「初期仕様を作り終えること」だけにフォーカスしており、「有用性」「利益」「ユーザー満足度」「そのための途中発生した改善プロセス」などが一切考慮されていないため、次のようなPJも「成功」扱いとなっている。 頻繁にクラッシュする ユーザーにとってUIUXが悪い 機能拡張できないような作りになっている 二度と発注されなくなった また、「問題あり」のものも、リリース後に改善されている場合もある。 確実だったのは、失敗した確率がわかったことだけ。 というのを、15年以上かけて調査したレポートがCHAOSレポート。 学び KPIを間違えるとイタイ KPIはユーザー満足度、利益、を測るのが大事 間違った観点に気づかず続けてしまうこともイタイ 学びを活かすアイディア・行動 定期的なKPIの見直し
1.7 ここにドラゴンがいる 1.8 未知を見積もる 1.9 素人業界 1.10 本章のまとめ 内容 ソフトウェア開発の未知について説明している。 エンジニアは経験から作業を見積もるが、これは結局の憶測を越えない。全部で9ヶ月のPJを8ヶ月目にふたを開けてみたら全体で6ヶ月の遅れがあるなんてこともある。 なぜこんなことになるかというと、単にわかっていないで憶測したから。 業界の冗談で、開発の3つの状態「終わった」「始めていない」「ほとんど終わった」とういのがある。 ドラゴンというのは、モンスターが多くて恐ろしいことや未知なことの例え。 タスクを見積もることができないのはやったことがないから。わからないことが多いから。 見積もりはちゃんとやろうとすると時間がかかる。再利用できるもの、ライブラリの利用などを始め、作ろうとすることに対してもろもろの経験を活かしながら。 しかし、一見似たようなことも進めてみると違っていて、当初の見積もりどおりにならないことがほとんど。 間違った前提で見積もりをすることもある。ウォーターフォールでコーディングに時間をかけずに設計書を最新に保つことに多くの時間を割くのが代表的。これが問題解決の手助けになると信じて作られているが、こういった設計書は実際は殆ど使われず、価値を発揮できないまま捨てられるので、無駄が多い。 ソフトウェア業界は安定して成功できる決まったやり方はまだない。 エンジニアによって多種多様なアプローチをする。その中でもうまくいくのは本当に自分たちの問題を直視し、過去のやり方にとらわれずに勇気をもって踏み出す人たちだけ。 まだまだ未熟な業界だからエンジニアもマネージャーも、ソフトウェアは変化できるという性質と、その必要性を共通認識としてもち、協力して勇気を持って進まなければいけない。 今の業界は全然未熟で、特にウォーターフォールは全然間違っていることが多い。 時代の変化についていくためのソフトウェアづくりのために、みんな目を覚まして真剣に変えていこう。 学び 経験上、「ほとんど終わった」は怪しい。 正確に見積もるのは難しい 自分たちの問題をどんなことでも直視し、他のやり方は参考にすれど、囚われずに考え実践する姿勢がまず大事。特に、コミュニケーションプロセス。多くのジャンルの人達が関連するから。 学びを活かすアイディア・行動 特になし
1.5 「プロセス」が「忙しい仕事」になるとき 1.6 ガチガチのマネジメント 内容 人は成果を出せないとやる気を失う。初めはやる気があったとしても。 IBMのプログラミングのコメントポリシーは何をやっているかをすべて書くことだったが、これは良くなかった。自明なコメントはコードが読みづらくなったり、シンプルすぎるメソッド名にコメントで注釈を入れて実際のふるまいとメソッド名にギャップがあったり、コメントへの反映し忘れでコメントが嘘になってしまったり。 このような良くないプロセスは忙しさを産み、やる気を無くさせる。 マネージャーは開発者が正しいことをしていると保証したい。 正しいこととは何か？答えられる人はほとんどいない。 ソフトウェア開発でやっていることは、考えること、モデル化、コーディングで、これらは創造的でそれぞれが違うことがほとんど。実質、定量的に図ることは難しい。 正しいことをしたいあまり、プロセスを追加することがあるが、追加すればするほど悪くなる傾向がある。創造性にプロセスは影響しないから、単純に作業が複雑になり創造性を阻害し忙しくなるだけ。 学び コメントはプログラムで表現できないことを書く。 結局の所どうやって計測する？という疑問が出た 学びを活かすアイディア・行動 現場のコーディング規約づくり
1.3 一か八かの勝負 1.4 なぜウォーターフォールは機能しないのか？ 1.4.1 レシピと公式 1.4.2 開発とテストの分離 内容 ウォーターフォールで最後に統合するのは一か八かの賭けに似ている。 多くのバグは統合フェーズで見つかる。これがコストが高くなる理由。 再テストとコードの再統合に多くの人手が必要になる。ある領域で加えた変更が、ほかの多数の領域に影響を与える可能性がある。そのため、システムのいかなる箇所にいかなる変更が加わった場合でも、再テストをするのが賢明ということになる。さらに、これが手動のプロセスのままだと、途方もないコストがかかる。 何かをものを作るとき、ものごとをまとめてやるというのは直感的には正しそうに見える。たとえば、家づくりであれば基礎を作るのに必要なものすべてを現場に渡したい。そうすれば追加のコンクリートや何かを待って止まることもないから。 しかし、ソフトウェアの場合はまとめてやろうとするのは上手くいかない。 ソフトウェアの場合、物理的なものと違い、設計が変わる可能性が高い。まとめて作業するということは、その分は変更しないで進めるということを意味する。 料理のレシピは、レシピ通りにやれば誰が作っても同じようなものができる。 ソフトウェア開発の場合、ある場面では正しいことがある場面では間違っていることが多く、実質他のレシピと同じようには作れない。 ウォーターフォールでは開発とテストのフェーズを分離し、最後のQAでリリース候補のテストを行う。そして出たバグをその時点から修正する。 バグはプロジェクトの終盤であればあるほど、修正にコストがかかる傾向があるので、リリースは遅れる。（もろもろの修正手続きだったり、密結合による難易度だったり） 開発とテストはもっと近くなければならない。 学び 最後に問題が出るのが一番コストがかかる 常に全統合で自動テストを行う環境にしておけば問題の先送りは防げる ウォーターフォールは設計と開発のフェーズを分けているため、設計変更の仕方に柔軟性がなくなる。ウォーターフォールの契約やプロセスに無理に当てはめて進めようとすると、設計変更しないと問題が出るような箇所に対応するタイミングが遅くなる可能性が高い。その遅さは、今の時代の変化についていくためのリスクになる場合がある。 ソフトウェア開発をレシピで例えるなら、１つ１つが料理自体が違うくらい違うと思う。 関連する人や業界が違えば、工程の順序も違ってきておかしくない。もちろん、ビジネスによって内容も違う。 開発とテストは近いほうがよい。間違いは速くに見つけられる方が、より根本的なプロセス改善につながる。 学びを活かすアイディア ウォーターフォールに頑なにこだわっているプロジェクトには入らない TDDの実践
1.2 滝（ウォーターフォール）に流される 内容 ウォーターフォールモデルは製造業や建設業をもとにしており、1970年にウィンストン・ロイスが言及したもの。そして彼は「このやり方は機能しないだろう」と次のページに書いていた。どうやら、これまでに誰もそれを読んでいないようだ。 ウォーターフォールは、機能の要求をリリース単位でまとめるような橋の建設や部品の製造では効率的で理にかなっている。しかし、ソフトウェア開発はあらかじめできあがった部品を組み立てるわけではない。一部の部品は事前に用意できるかもしれないが、大部分は、何をしなければいけないかは、その場になってみないとわからないことがほとんど。 だからフェーズをきっちり分けるウォーターフォールモデルは機能しない。 学び 習慣や当たり前を疑う大切さ。 ウォーターフォールはきっちりした計画を立てて進めていかないと意味がないにもかかわらず、ソフトウェア開発は進めてみないとわからない事が多いので、それは難しい。だからバッファを多く取るが、ウォーターフォールでの開発は基本ロングスパンなので早い段階のバッファも信憑性が薄いことが多いと思う。 似たようなソフトウェアを創るのであればバッファの信憑性も上がるが、経験上、一見似ているが、進めてみると結構違うことがあるので、やっぱり計画が難しい。 学びを活かすアイディア・行動 アジャイルプラクティスを学んで取り入れていく
1.1 レガシーコードとは何か 内容 「レガシーコード改善ガイド」著者のマイケル・フェザーズは、テストのないコードをレガシーコードと定義している。 変更のリスクが大きく、事実上、ほとんど変更不可能で、置き換えるしかないようなコード。 保守できないようなわかりにくいコード。 ソフトウェアの延命措置程度の改修しかできないようなコード。 ソフトウェアの作り方の欠点や他の業界との違いを知れば、どのようにレガシーコードが生まれるかがわかり、対処できるようになる。 学び レガシーコードの定義 学びを活かすアイディア・行動 なし