経営陣がやりがち｢人員補充｣が大失敗を招くワケ 遅延プロジェクトに増員すると､さらに遅れる謎

著者のブルックスは、1964年にIBMが当時の金額で50億ドル（現在の価値で数兆円）を投じて開発し、コンピューター市場で圧倒的なシェアを獲得した大規模プロジェクト・システム／360で、同システムの中核ソフト・OS／360の開発プロジェクトマネジャーを務めた人物。ブルックスはこの巨大プロジェクトを通じて得た知見をもとに本書を書いた。私もかつてIBM大和研究所でソフトウェア製品開発マネジャーを担当したことがあり、本書の言葉は骨身に染みる。そこで本書を紐解きながら、この問題を解き明かしてみよう。

「人月」の進捗管理が破綻する理由

ソフトウェア開発は「人月（にんげつ）」で作業量を見積もる。1人月は「1人で1カ月かかる作業量」だ。

OS／360プロジェクトは、6万人月という巨大な規模だった。人月に比例して開発費が増えるので、この人月の考え方は見積もりではとても役に立つ。しかしこの人月で進捗管理した途端、プロジェクトがおかしくなる。これは人月で進捗管理するとうまくいく仕事（❶の宅配便）と比較すればわかる。

❶ 宅配便などの単純業務：宅配便の場合、配達作業の進捗が遅れたら、残りの配達作業量を1人当たりの配達量で割れば、必要人数がわかる。宅配便は配達員同士でコミュニケーションを取らずに作業できるので、配達員を増やせば期間を短縮できる。

❷ 多くのソフトウェア開発：宅配便の方法は、ソフトウェア開発では使えない。各担当者の作業が密接に関連しているからだ。各担当者が分担してプログラムを書き、各プログラムをつなげてテストして、バグが出たら問題を解析し、どのプログラムで問題が起きたか特定して、修正する必要がある。これらの各作業では担当者間で密接なやり取りが必要なので、宅配便のように完全な分担ができない。そして各作業を行うために必要な時間も決まっている。だから図のように、人を増やしても作業時間は変わらない。ブルックスは本書で「女性がどれほどたくさん動員されたところで、子ども1人が生まれてくるまで十月十日かかることに変わりないのと同じだ」とたとえている。

❸ 一部のソフトウェア開発：中にはある程度の作業分担ができるソフトウェア開発もある。しかしこの場合でもお互いにコミュニケーションを取る労力は必ず発生するので、人を増やしても期間はさほど減らない。

❹ 大規模なソフトウェア開発：大規模なソフトウェア開発プロジェクトでは密接なコミュニケーションが必要なので、途中で人を増やすとコミュニケーションに手間が取られ、逆にスケジュールが遅れてしまう。しかし現実には「プロジェクトが遅れている」と報告を受けた経営幹部は、こう指示する人が多い。「人を追加するから遅れを取り戻そう」。しかし人を追加すると、さらに遅れてしまうのだ。チームがn人だと、コミュニケーション労力は n（n-1）／2 に比例して増える。たとえば2人の作業と比べて、3人だと労力3倍、4人だと6倍、5人だと10倍になる。人を増やすほどコミュニケーション労力が増えるので、実作業に割ける労力は減ってしまう。これがソフトウェア開発の現場で起こる現実だ。

しかしソフトウェア開発を知らない人たちはこの現実が理解できない。そして「遅れているのなら、人を投入すれば問題はすぐ解決するのに、なんでやらないの？」と考えてしまう。これが「人月で進捗を管理する」考え方の弊害だ。