Month: February 2021

2.4 失敗のコスト 2.4.1 ここにも１０億ドル、あそこにも１０億ドル 2.4.2 新しい研究、相変わらず危機 内容 ソフトウェア開発にはとにかくコストがかかっていて２００２年時点ではアメリカだけで年間６００億ドルの損失がある。 コストの内訳を見てみると、リリース後のコストが多く、最大で８０％増しにかかっている。 それは保守性に重きをおいてこなかったから。 学び 保守性はコストで図れるかもしれない。 ランニングコストがどれくらいかかっているかを測るのは重要。 学びを活かすアイディア・行動 何にいくらかかっているか、利益がどれくらいかを出す

2.3 プロジェクトがなぜ失敗するのか 2.3.1 コードの変更 2.3.2 蔓延 2.3.3 複雑性の危機 内容 失敗する理由を大きく分けると２つ。 ビジネスの優先度変化や市場ニーズの変化などの開発側がコントロールできないことが要因 技術プラクティス不足による開発側の要因 技術プラクティス不足が招いてる原因はさらに３つに分けられる。 コード変更ができない バグの修正が時間がかかる 複雑さが増している コード変更ができない大きな改修する場合、多くのチームは既存のコードや設計を理解しようとせず、自分たちのやり方でやる傾向にある。それはコードが複雑でわかりにくいから。結果として一貫性がなくなり、さらに変更しづらいコードになる。 バグの修正が時間がかかる何が時間がかかるかって、大量コードの中からバグを見つけること。どれだけバグを見つけやすい作りになっているかが重要。 複雑さが増している調査によると使っていない機能が45%もある。なのに残っているから複雑になり、バグが見つけられなくなる。バグ修正に時間がかかる件に関連しているが、このせいで開発の80％はバグ修正にコストをかけていると調査結果が出ている。 学び 複雑さが保守不可能にしてる 学びを活かすアイディア・行動 保守しやすいアーキテクチャを考える

1.7 ここにドラゴンがいる 1.8 未知を見積もる 1.9 素人業界 1.10 本章のまとめ 内容 ソフトウェア開発の未知について説明している。 エンジニアは経験から作業を見積もるが、これは結局の憶測を越えない。全部で9ヶ月のPJを8ヶ月目にふたを開けてみたら全体で6ヶ月の遅れがあるなんてこともある。 なぜこんなことになるかというと、単にわかっていないで憶測したから。 業界の冗談で、開発の3つの状態「終わった」「始めていない」「ほとんど終わった」とういのがある。 ドラゴンというのは、モンスターが多くて恐ろしいことや未知なことの例え。 タスクを見積もることができないのはやったことがないから。わからないことが多いから。 見積もりはちゃんとやろうとすると時間がかかる。再利用できるもの、ライブラリの利用などを始め、作ろうとすることに対してもろもろの経験を活かしながら。 しかし、一見似たようなことも進めてみると違っていて、当初の見積もりどおりにならないことがほとんど。 間違った前提で見積もりをすることもある。ウォーターフォールでコーディングに時間をかけずに設計書を最新に保つことに多くの時間を割くのが代表的。これが問題解決の手助けになると信じて作られているが、こういった設計書は実際は殆ど使われず、価値を発揮できないまま捨てられるので、無駄が多い。 ソフトウェア業界は安定して成功できる決まったやり方はまだない。 エンジニアによって多種多様なアプローチをする。その中でもうまくいくのは本当に自分たちの問題を直視し、過去のやり方にとらわれずに勇気をもって踏み出す人たちだけ。 まだまだ未熟な業界だからエンジニアもマネージャーも、ソフトウェアは変化できるという性質と、その必要性を共通認識としてもち、協力して勇気を持って進まなければいけない。 今の業界は全然未熟で、特にウォーターフォールは全然間違っていることが多い。 時代の変化についていくためのソフトウェアづくりのために、みんな目を覚まして真剣に変えていこう。 学び 経験上、「ほとんど終わった」は怪しい。 正確に見積もるのは難しい 自分たちの問題をどんなことでも直視し、他のやり方は参考にすれど、囚われずに考え実践する姿勢がまず大事。特に、コミュニケーションプロセス。多くのジャンルの人達が関連するから。 学びを活かすアイディア・行動 特になし

1.5 「プロセス」が「忙しい仕事」になるとき 1.6 ガチガチのマネジメント 内容 人は成果を出せないとやる気を失う。初めはやる気があったとしても。 IBMのプログラミングのコメントポリシーは何をやっているかをすべて書くことだったが、これは良くなかった。自明なコメントはコードが読みづらくなったり、シンプルすぎるメソッド名にコメントで注釈を入れて実際のふるまいとメソッド名にギャップがあったり、コメントへの反映し忘れでコメントが嘘になってしまったり。 このような良くないプロセスは忙しさを産み、やる気を無くさせる。 マネージャーは開発者が正しいことをしていると保証したい。 正しいこととは何か？答えられる人はほとんどいない。 ソフトウェア開発でやっていることは、考えること、モデル化、コーディングで、これらは創造的でそれぞれが違うことがほとんど。実質、定量的に図ることは難しい。 正しいことをしたいあまり、プロセスを追加することがあるが、追加すればするほど悪くなる傾向がある。創造性にプロセスは影響しないから、単純に作業が複雑になり創造性を阻害し忙しくなるだけ。 学び コメントはプログラムで表現できないことを書く。 結局の所どうやって計測する？という疑問が出た 学びを活かすアイディア・行動 現場のコーディング規約づくり

1.2 滝（ウォーターフォール）に流される 内容 ウォーターフォールモデルは製造業や建設業をもとにしており、1970年にウィンストン・ロイスが言及したもの。そして彼は「このやり方は機能しないだろう」と次のページに書いていた。どうやら、これまでに誰もそれを読んでいないようだ。 ウォーターフォールは、機能の要求をリリース単位でまとめるような橋の建設や部品の製造では効率的で理にかなっている。しかし、ソフトウェア開発はあらかじめできあがった部品を組み立てるわけではない。一部の部品は事前に用意できるかもしれないが、大部分は、何をしなければいけないかは、その場になってみないとわからないことがほとんど。 だからフェーズをきっちり分けるウォーターフォールモデルは機能しない。 学び 習慣や当たり前を疑う大切さ。 ウォーターフォールはきっちりした計画を立てて進めていかないと意味がないにもかかわらず、ソフトウェア開発は進めてみないとわからない事が多いので、それは難しい。だからバッファを多く取るが、ウォーターフォールでの開発は基本ロングスパンなので早い段階のバッファも信憑性が薄いことが多いと思う。 似たようなソフトウェアを創るのであればバッファの信憑性も上がるが、経験上、一見似ているが、進めてみると結構違うことがあるので、やっぱり計画が難しい。 学びを活かすアイディア・行動 アジャイルプラクティスを学んで取り入れていく

1.1 レガシーコードとは何か 内容 「レガシーコード改善ガイド」著者のマイケル・フェザーズは、テストのないコードをレガシーコードと定義している。 変更のリスクが大きく、事実上、ほとんど変更不可能で、置き換えるしかないようなコード。 保守できないようなわかりにくいコード。 ソフトウェアの延命措置程度の改修しかできないようなコード。 ソフトウェアの作り方の欠点や他の業界との違いを知れば、どのようにレガシーコードが生まれるかがわかり、対処できるようになる。 学び レガシーコードの定義 学びを活かすアイディア・行動 なし

1. 何かが間違っている 負のスパイラルの原因は「レガシーコード」が原因という側面がある。そうならないために技術プラクティスがどのように機能するかを理解し実践すると、負のスパイラルにはならない。ということを長い例え話で説明している。 負のスパイラルの例チームの中心的な開発者たちは優秀だった。 一方で、チームにはコードモンキーがいて、自分の機能を作ることだけしか見ていなかった。その機能が全体にどう影響するかは考えておらず、彼らの仕事のいくつかが短期間で大きな問題を引き起こし、そのあとさらに大きな問題を引き起こすことに気づいていなかった。 チーム全体は、技術プラクティスの背後にある理由を理解してはいなかった。しまいには、あっちこっちで異なる標準を使って作業を進め、システム全体は見ていなかった。 そして、賢くて経験豊富なエキスパートがリードしていたのにも関わらず、ソフトウェアは扱いづらいものになった。 コードの統合は、誰も楽しみにしていない悪夢のような体験になった。 重量級のソフトウェア開発プロセスは大きな妨げになっていて、もはやまったくコードを生み出せないほどだった。 マネージャーたちも賢くて経験豊富だったが、結局、開発者と同じようにイライラしやる気を失った。もう、開発者に何を指示すればよいかわからないかのようだった。 組織内に信頼はなかった。 そこで経営陣は、多くのプロセスを追加する対応を取った。それがさらに信頼を損ね、締切がさらに変更となった。 会社全体が死のスパイラルに陥っていて、7億5,000万ドルの事業全体が危機に瀕していた。 会社は過去10年間で飛躍的に成長したにもかかわらず、結果としてコードはひどいことになっていた。この会社は何年にもわたって「アジャイル」を進めようとしていたが、多くのチームでアジャイルプラクティスのいくつかを導入すると、既存のコードがいつも邪魔をした。既存のレガシーコードと、こんな状況になるまで蓄積してきたすべての悪習の両方に対処しなければいけないことを彼らはわかっていた。 私は、この問題を「人の問題」ではなく「レガシーコードの問題」だと考えた。 学び アーキテクチャや設計を考慮せず、言われたことだけやるプログラマをコードモンキーと言うのか。 長い例え話に思いが詰まっていることが伝わる。そして共感する部分もある。 経験が浅いうちはやる気があっても視野が狭かったりスキルが追いつかなかったりで、実質コードモンキーの時期はある。 学びを活かすアイディア・行動 キャリア整理のための資料作り

はじめに 内容 本書は開発と保守のコストを下げるために書いた。内容は、開発者、マネージャー、顧客（システム担当）それぞれが、ソフトウェア開発そのものの理解を深めることを目的に、９つのプラクティスに焦点を当てて説明する。 開発者は変更可能なコードを書くための原則とプラクティスを学べる。マネージャーはそのプラクティスへの投資の仕方を学べる。そして開発者、マネージャー、顧客間のコミュニケーションギャップを埋めるサポートとなる。 レガシーコードがもたらす損失私達はレガシーコードのせいで、開発より保守にコストをかけて、チャンスを失っている。アメリカだけで年間何十億ドルも損失している。本書でのレガシーコードの定義は「理由はなんであれ修正、拡張、作業が非常に難しいコード」のこと。 ソフトウェア開発は他のものづくりとは違うソフトウェア開発は物理的なモノの開発とは大きく異なる。この業界の問題における原因の1つは、この認識を間違って捉えていることかもしれない。ソフトウェア開発を理解し予測可能にしようとする中で、製造業や土木業と比較されてきたが、ソフトウェア開発は「より変更可能」にするために特化したプラクティスが必要で、他とは違うのである。 プラクティスを使い、ソフトウェア開発での短期的なコストを減らし、問題となりやすい長期的な保守コストも削減のサポートとしてほしい。 注意紹介するプラクティスは重要性の説明に重きを置くため、HowToはそんなに書いていないので、HowToを見たい場合は具体的な参考書籍があるのでそちらを見てほしい。この本ではプラクティスの背景にある原則や目的を理解し、「なぜ」それを適用させるのかということを議論できるようになることに価値をおいている。 学び ソフトウェア開発は他の物理的なものづくり業界のノウハウを参考にされてきたが、ソフトウェアの特性である「変更しやすさ」にフォーカスしたときに、もう他の業界とは別のアプローチをしていかないと、変更しながら時代についていけないということを結論付け、今後はより「変更しやすさ」のためのアプローチを磨いていかなければならない。でないと、今後も無駄な損失を多く出すことになる。 学びを活かすアイディア・行動 特になし。