人月の神話第2章：見積もり失敗の原因と対処法

ソフトウェア開発の失敗の原因は開発期間の不足によるものが圧倒的に多い。その理由と対策は以下の通りである。

原因1 楽観主義などの要因により、コストを低く見積もる傾向がある（見積もったコストが量的に不足している）。
原因2 人月が開発の進捗を表すという誤った考え（順序的制約と人員数によるコスト変動の軽視）。
1. 定量的研究による裏付け（第19章 pp. 273-274より）
原因3 顧客の要望を書いただけの開発完了予定日。　
原因4 他の工学分野に比べ、進捗が適切にモニタリングされていない。
原因5 開発の遅れに対して人員を追加するという不味い対応が行われやすい。
1. 関連研究（第19章 pp. 274-275より）
対処法1 開発期間の半分をテスト期間に割り当てる。
対処法2 遅れがはっきりしたときは、人員追加ではなくスケジュールの立て直しを。機能削減も有効。
対処法3 見積もりに関するデータと手法の共有。
対処法4 気を強く持つ。
対処法5 開発期間短縮より開発コスト低減を優先したスケジュールを立てる。

原因1 楽観主義などの要因により、コストを低く見積もる傾向がある（見積もったコストが量的に不足している）。

楽観主義。「全部うまく行くだろう」。それぞれの仕事にかかる時間は、かかるべきと考えられる時間だけであろう。
人が何かを作るときには3段階、つまり、アイデア（idea）、実装（implementation）、利用者との相互作用（interaction）がある。
- このうち実装には、物理的制約（時間や空間の制約）があり、これが予期せぬ実装の難しさを生むことがある。
- アイデアの欠陥は実装段階になってから明確になる。また、アイデアの欠陥は見過ごされやすい。なぜなら、自分が作ったアイデアよりは、自分が作ったわけではない物理的制約のせいにしがちだからである。
- プログラムの扱いやすさ（やり直しが効いて扱いやすいという第1章で触れられた開発の喜び）は、実装の難しさを忘れ、アイデアの欠陥を見落とす要因の1つである。
単一の作業ならまだしも、一連の作業が全て上手く行き、全てで遅れが発生しない確率は、ゼロに近い。

原因2 人月が開発の進捗を表すという誤った考え（順序的制約と人員数によるコスト変動の軽視）。

農作物の収穫は、多数の人で取りかかれば早く終わる。一方で、どんなに多くの人が手助けしても、妊娠期間を短くすることは出来ない。この違いはどこから来るのだろうか。

順序的制約があると、作業を複数に分割できても平行して行うことが出来ない。例えば、デバッグにおいて混乱を避けるために、コードの修正と修正後の確認を1つずつ実施しようとするならば、現在作業中のバグの修正・確認が終わらなければ、次のバグの修正・確認を開始できない。
平行して行う作業の分割数（＝作業人数）に応じて増加するコストがある。
- 教育・訓練コスト：新たに開発チームに加わるメンバーは、技術、その開発の目的、目的を達成するための戦略、及び、作業計画について、教育・訓練が必要である。他人が肩代わりは出来ないので、教育・訓練コストはメンバー数に比例して増加する。
- コミュニケーションコスト：分担された各作業間で、担当者同士2者間調整が必要であるとする。すると、分割数がnの場合、n(n-1)/2通りの組み合わせで調整が必要となる。これは分割数nの2乗で増加する項を持つコストである。2者間調整で足りず、3者以上が1回の会議で同時に調整する必要があれば、コストはよりひどく増加するだろう。

作業人数と作業量の関係の例を表すグラフ。作業人数が増えるにつれて、開発作業自体よりも教育・訓練コストやコミュニケーションコストが問題となることが分かる。

ソフト開発は複雑な相互関係を本質的に扱っているので、コミュニケーションに必要な労力はどうしても大きい。
作業人数（＝分割数）を増やすとコストも増える。さらに、コミュニケーションコストは2乗以上で増える。そのため、作業人数を増やしていくと、どこかで開発期間は短くならなくなり、逆にどんどん長くなっていく。

作業人数と開発月数の関係の例を表すグラフ。この例では、作業人数を1人から2人に増やすと開発期間が4ヶ月から3ヶ月に減る一方で、3人に増やしても3ヶ月のままであり、4人以上では作業人数を増やせば増やすほど開発期間が増えることが分かる。

定量的研究による裏付け（第19章 pp. 273-274より）

Barry Boehmが63のソフトウェアプロジェクトに対して行った定量的研究では、以下が示された。

Boehmが立てたモデルを使うと、見積もった人月からコスト最適スケジュール時間が計算できる。
計画されたスケジュールがこの最適時間より短くなるにつれ、コスト曲線が急激に上昇する。
投入された人数にかかわらず、この最適時間の3/4以下の期間で成功したプロジェクトはほとんどない。

原因3 顧客の要望を書いただけの開発完了予定日。　

ソフトウェア開発では、他分野に比べ顧客の要望に合うようにスケジュールが立てられることが多い。
データが不足しやすく、定量的にはなりにくく、直感による部分が大きいソフトウェア見積もりを、開発サイドが弁護するのはとても難しい。
しかし、例え顧客が開発完了予定日を思いのままに出来たとしても、実際の開発完了を思いのままに出来るわけではない。

原因4 他の工学分野に比べ、進捗が適切にモニタリングされていない。

他の工学分野では立証され日常的に利用されている技術が、ソフトウェアエンジニアリングでは革新と考えられている。

原因5 開発の遅れに対して人員を追加するという不味い対応が行われやすい。

どんなに早く、どんなに有能な人を確保できたとしても、教育・訓練（技術、目的、戦略、計画）は必要である。
教育・訓練には開発チームの既存メンバーから最低でも1人を担当させる必要がある。
この教育・訓練の間は、新メンバーとこの既存メンバーの人月の多くは、教育・訓練コストとして消える。
教育・訓練コストに加え、コミュニケーションコストの増加もある。
極端な人員増加では、チーム構成を質的にも変化させてしまう。
安易な人員増加はソフトウェアの品質も低下させる。

対処法1 開発期間の半分をテスト期間に割り当てる。

（ここでの議論は特に、ウォーターフォールモデルが暗黙的前提になってしまっていることに注意が必要である。後に書かれた第19章で言及されているように、ウォーターフォールモデルがそもそも間違っている。ウォーターフォールモデルの一巡ではなく、別の開発モデルであるスパイラルやアジャイルのイテレーションにおいても、それぞれの論点が成立するのかは読者の判断に任されるのであろう。）

著者の調査によると、半分の期間をテスト期間に割り当てている開発プロジェクトは少ないが、大半のプロジェクトでは結局開発期間の半分がテスト期間になってしまっている。
ソフトウェアコンポーネントのデバッグとシステムテストは、もっとも順序的制約を受けやすい。
バグの数と難しさで必要な時間は異なるが、楽観主義のせいで実際より少なく見積もる傾向があるため、テスト部分のスケジュール作成は最も失敗をしやすい。（そもそも実装と平行して行う単体テストで全てのバグが取れていると楽観してしまうと、実装期間後のテスト期間に見つかるバグは存在しないことになってしまう。当然実際は違う。）
十分なテスト期間の割り当ては、開発遅延による二次的コストのリスクを下げる。
- 二次的コストの発生の仕方：テスト期間を十分に設けない -> テスト期間に入るまでは遅れが表面化しない -> そのソフトウェアを利用してビジネスを行う顧客企業に突然のように遅れが通知される -> 莫大な二次的コスト
- テスト期間を十分設けていれば、このような事態になるリスクを下げられる。

対処法2 遅れがはっきりしたときは、人員追加ではなくスケジュールの立て直しを。機能削減も有効。

「小さな遅れを重ねるな」
各作業を注意深く完全に実施するのに十分な時間を持つ新しいスケジュールを立てて、二度と遅れが発生しないようにする。
機能の削減などで作業量を削減しても良い。
- 公式に、慎重に、計画を立て直すのが一手。
- 時間不足の設計と不十分なテストにより、静かに仕事が減っていくのを眺めるのが別の一手。