CodeNote

『人月の神話』フレデリック・P・ブルックス，Jr.（著） を読んだので、書籍から得た知見をご紹介します。

背景 人月の神話、ブルックスの法則

人月の神話、ブルックスの法則について理解を深めたく、この本を読みました。

以下、印象に残った箇所の引用とメモです。

第2章 人月の神話

第四の理由は、スケジュールの進捗がきちんと監視されていないことにある。

第五には、スケジュールの遅延が発覚した場合、自然（かつ伝統的）な対応として要員を追加することがある。火に油を注ぐがごとく、この対応は事態を悪化、それもかなりひどくする。火が大きくなればガソリンをもっと欲するように、悪循環はこうして始まり、結局大失敗に終わる。

楽観主義

プログラマはみんな楽観主義者である。

人月

人と月が交換可能になるのは、多くの作業者の間でコミュニケーション（意思疎通）を図らなくても、仕事が分担できる場合だけである（図 2.1）。これは小麦を刈り取るとか、綿を摘むとかいうことには当てはまるが、どうがんばってもシステムプログラム開発には当てはまらない。

📝 人月はソフトウェア開発には当てはめられない。

過去数年間、私は以下の目安を使用してソフトウェア開発のスケジュールにうまく対応してきた。

1/3 計画
1/6 コーディング
1/4 単体テストおよび初期システムテスト
1/4 すべてのコンポーネントを統合して行うシステムテスト

📝 ソフトウェア開発のスケジュールの目安

ブルックスの法則をひと言で述べると、
遅れているソフトウェアプロジェクトへの要員追加は、さらにプロジェクトを遅らせるだけだ
ということになる。

📝 ブルックスの法則

第3章 外科手術チーム

問題点

研究の一環として、経験を積んだプログラマグループの実績を測定した。そのグループの中だけでも、最高と最低の実績比率は生産性にして平均10対1、プログラム開発のスピードと量ではなんと5対1だった。

📝 生産性10倍、開発スピード・量5倍の差がある。

ミルズの案

大規模な仕事の各セグメントにチームで取り組むことを提案している。ただしチームと言っても、全員で豚を解体するようなものではなく、外科手術チームのように編成されたチームでなければならないと言っている。つまり、メンバー1人ひとりが問題を切り分ける代わりに、1人が執刀して他のメンバーはそれを助け、効果と生産性が上がるようにするのである。

📝 大規模な仕事の各セグメントにチームで取り組む。

第7章 バベルの塔は、なぜ失敗に終わったか？

バベルプロジェクトの管理監査

以上のものすべてが揃っていながら、なぜプロジェクトは失敗に終わったのか。どこに不足があったのだろうか。彼らに欠けていたのは、コミュニケーションとそれから生まれる組織の2点であった。互いに話をすることができなかったため、まとめることが不可能だった。

📝 全て揃っていても、コミュニケーション不足でプロジェクトは失敗する。

第14章 破局を生み出すこと

マイルストーンか、それともミルストーンか？

大規模プロジェクトをどのようにして厳しいスケジュールに合うようにコントロールするのか。最初のステップとして、スケジュールそのものを作らなくてはならない。マイルストーンと呼ばれるイベントのリストには、それぞれ日付が振られている。

📝 大規模プロジェクトに必要なマイルストーン。

マイルストーンの決定に関し、関係する規則は1つだけだ。それは、マイルストーンを具体的かつ明確で測定可能なイベントとして、ナイフの刃のような鋭さをもって定義しなければならないということである。

📝 マイルストーンの定義が肝。

これに対して具体的なマイルストーンは、 100パーセントのイベントだ。

しかし、これから10年間という水平線を見渡すと、銀の弾などはどこにも見あたらない。技術においても、管理手法においても、それだけで10年間に生産性や信頼性と容易性での飛躍的な改善を1つでも約束できるような開発は1つとしてない。

📝 10年経っても銀の弾は出てこなかった。

第19章 『人月の神話』から20年を経て

捨石にするつもりで構築してはならない ――ウォーターフォールモデルは間違いだ！

「1つは捨石にするつもりで構築せよ」という考え方における最大の誤りは、 ソフトウェア構築に関して古典的な順次モデルまたはウォーターフォールモデルを暗黙のうちに想定していることだ。

📝 ウォーターフォールモデルを想定した考え方は誤り。

●ある段階からそれ以前の段階へのフィードバック
●フィードバックがもたらすコストとスケジュールの遅れを取り込むことができるように、フィードバックは直前の段階までのみと限定すること

ブルックスの法則はどこまで当たっているか？

これまで、ブルックスの法則（故意に単純化してある）の妥当性を慎重に評価する研究がなされてきた。

(中略)

彼らは「遅延しているプロジェクトにさらに要員を追加することは、つねにコストがより高くつくことにはなるが、完了をつねに遅らせるわけではない」（強調部 分は原文のママ）という結論を出している。特に、スケジュールの初期段階で要員を追加することは、後から追加するよりはるかに安全な戦術だとしている。

📝 追加人員は早い方が良い。

開発プロジェクトに後から追加される新 要員は、チームプレイヤーとしてプロジェクトの中に勢いよく飛び込んで仕事をしようとする意欲の持ち主でなければならず、工程自体を変更または改善しようとする人ではいけない、と言っているのだ。

📝 遅延プロジェクトのプロセス改善をせず、勢いよく飛び込むのは無謀だと思う。

以上、ブルックスの法則と無縁で過ごしたい、現場からお送りしました。