人を増やせば早くなると思う上司へ『人月の神話』

詳しく解説！雑学のコーナー

『人月の神話』は、1975年にフレデリック・ブルックスが著したソフトウェア工学の古典的名著です。IBMでSystem/360の開発を指揮した経験から、「遅れているソフトウェアプロジェクトに人員を追加しても、さらに遅れるだけだ」というブルックスの法則を提唱しました。出版から半世紀近く経った今も、その洞察は色褪せていません。 ブルックスは、ソフトウェア開発の工数を「人月」で計算することの誤謬を指摘しました。「人月」という単位は、人と月が交換可能であることを暗に示唆しますが、実際には「9人の妊婦を集めても1ヶ月で赤ちゃんは生まれない」のです。タスクには並列化できないものがあり、特に設計や統合作業は本質的に逐次的です。 コミュニケーションコストの問題も重要です。n人のチームでは、n(n-1)/2の通信経路が存在します。5人なら10通り、10人なら45通り、20人なら190通り。人数が2倍になってもコミュニケーションコストは4倍になるため、実質的な生産性はむしろ低下します。Microsoftの研究では、Windowsの開発において、チームサイズが2倍になると、バグの数が2.5倍に増加することが判明しました。 「外科手術チーム」モデルも提案されました。優秀なプログラマー（外科医）を中心に、補助的な役割（麻酔医、看護師など）を配置する小規模チームです。この構造により、コミュニケーションコストを抑えながら、生産性を最大化できます。実際、優秀なプログラマーと平均的なプログラマーの生産性の差は10倍以上という研究結果もあります。 「セカンドシステム症候群」も重要な概念です。成功した最初のシステムの後、2番目のシステムは過度に複雑になりがちです。Windows Vistaや、Netscape 6.0がその典型例。機能を詰め込みすぎて、開発が遅延し、品質も低下しました。ブルックスは「機能の追加は簡単だが、概念的一貫性を保つのは困難」と警告しています。 現代のアジャイル開発は、人月の神話への対応策と言えます。スクラムでは理想的なチームサイズを3-9人と定義し、それ以上になる場合は分割を推奨します。また、イテレーティブな開発により、大規模な統合作業を避け、継続的な価値提供を実現しています。 日本のIT業界は特に人月商売の弊害が顕著です。多重下請け構造により、実際に開発する人員と管理する人員の比率が逆転している例も珍しくありません。ある政府系プロジェクトでは、1000人月と見積もられた案件に実際に2000人が投入されましたが、完成は2年遅れ、予算は3倍に膨れ上がりました。 「遅延しているプロジェクトに人を追加すると、さらに遅延する」というブルックスの法則は、今や常識となりました。しかし、いまだに「人を増やせば早くなる」と考える管理者は後を絶ちません。GitHubの共同創業者は「優秀な3人のチームは、平凡な30人のチームに勝る」と述べています。 最新の研究では、リモートワークがブルックスの法則を緩和する可能性が示唆されています。非同期コミュニケーションにより、コミュニケーションコストを削減できるためです。しかし、それでも「人月」という考え方自体が、ソフトウェア開発の本質を見誤っているという事実は変わりません。