締め切りが目前なのに仕事が大幅に遅れていると、誰もが似たようなことを考えます。人を増やせば早く終わるのではないか、という考えです。引っ越しの荷物を運んだり畑を耕したりするときのように、人手が多いほど仕事が早く終わる場合が確かにあるからです。
ところが、ソフトウェア開発では逆のことがよく起こります。すでに遅れているプロジェクトに人を追加すると、スケジュールがさらに遅れるのです。この経験則は、最初にまとめた人の名前にちなんで「ブルックスの法則(Brooks's Law)」と呼ばれています。
本資料では、ブルックスの法則が生まれた背景と人月という単位に潜む思い違い、人を増やしても速くならない理由とコミュニケーション経路が増える計算の仕組み、そして法則を回避する方法と限界まで、順を追って整理します。
ブルックスの法則の原理と活用
法則の誕生と人月の思い違い
フレデリック・ブルックス(Frederick P. Brooks Jr.)は、1960年代に米国IBMで大型コンピューターSystem/360と、そのオペレーティングシステムOS/360の開発を率いたコンピューター科学者です。OS/360は当時としては屈指の大規模ソフトウェアプロジェクトで、多くの開発者が投入されましたが、スケジュールは遅れ続けました。
ブルックスはこのときの経験をもとに、1975年に『人月の神話(The Mythical Man-Month)』を出版しました。この本で彼は「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる(Adding manpower to a late software project makes it later)」という一文を残し、これがブルックスの法則と呼ばれるようになりました。
人月(Man-Month)は、一人がひと月に行う仕事の量を表す単位です。10人月の仕事なら、一人で十か月、十人でひと月で終えられると計算するわけです。ブルックスは、この計算が成り立つのは互いに話し合う必要がなく、仕事を均等に分けられる場合だけであり、人と月を互いに置き換えられるという考えそのものが思い違いだと指摘しました。
この本は、半世紀が過ぎた今もソフトウェア工学の古典に数えられています。1995年に刊行された20周年記念版には、生産性を一気に大きく引き上げる魔法のような方法はないという内容の論考「銀の弾丸はない(No Silver Bullet)」も収録されました。ブルックスはコンピューターアーキテクチャとソフトウェア工学への貢献により、1999年にチューリング賞(Turing Award)を受賞しました。
人を増やしても速くならない理由
遅れているプロジェクトに新しい人を加えると、一見、人手が増えたように見えます。しかし実際には、次のような理由でスケジュールがさらに遅れやすくなります。
(1) 習得に時間がかかる
新しく加わった人は、プロジェクトの構造やこれまでの決定、作業の進め方を覚えて初めて、一人分の役割を果たせるようになります。その間、既存のメンバーは自分の仕事を止めて新しい人に教えなければならないため、最初の数週間はかえって全体の速度が落ちます。
(2) 分割できない仕事がある
いくら人を増やしても、決まった順序で進めなければならない仕事もあります。ブルックスはこれを「赤ちゃんを産むには九か月かかる。何人の女性を割り当てても同じだ」という言葉で説明しました。
(3) すり合わせの作業が増える
仕事を細かく分けるほど、分けた部分を再びつなぎ合わせ、互いに整合しているか確認し、認識をすり合わせる作業が増えます。人が多くなるほど、この調整にかかる時間は急速に増えていきます。
この三つが重なると、新しい人が一人分の役割を果たし始めるより先に、もともとのスケジュールが崩れてしまいます。そのため、仕事の遅れを人数で埋め合わせようとする試みは、結果としてさらに大きな遅れを生むことが多いのです。
コミュニケーション経路が増える計算の仕組み
ブルックスの法則を最もよく示すのは、コミュニケーション経路の数です。チームの全員が互いに話し合う必要がある場合、人数をnとすると、コミュニケーション経路はn(n-1)/2本になります。人数は一人ずつ増えても、経路の数はそれよりはるかに速く増えていきます。
- 3人のチーム(Team of 3)：コミュニケーション経路は3本です。
- 5人のチーム(Team of 5)：コミュニケーション経路は10本に増えます。
- 10人のチーム(Team of 10)：コミュニケーション経路は45本になります。
- 20人のチーム(Team of 20)：コミュニケーション経路は190本に達します。
人数が二倍になると、経路は四倍近くに増える計算です。会議やメッセージ、確認作業がそれだけ増え、肝心のプログラムを作る時間は減っていきます。ある時点から、人を増やすほど全体の生産性がかえって低下する段階に達します。
法則を回避する方法と限界
ブルックスの法則は、人を増やしてはいけないというよりも、いつ、どのように増やすかを慎重に決めるべきだという意味に近いものです。実際の開発現場では、次のような方法でこの落とし穴を避けようとしています。
- 小さなチーム(Small Team)：チームの人数を少なく保ち、コミュニケーション経路を減らします。アマゾンの「ピザ二枚のチーム」という原則がよく知られた例です。
- モジュール化(Modularity)：仕事を互いに独立した部分に分け、部分同士の取り決めを明確にすることで、チーム間でやり取りする内容を減らします。
- 早期の人員配置(Early Staffing)：人が必要なら、スケジュールが遅れてからではなく、プロジェクトの初期に加えて、仕事を覚える時間を確保します。
- 範囲の調整(Scope Cut)：すでに遅れているなら、人を増やすよりも機能を減らしたり、スケジュールを組み直したりするほうがよい場合が多くあります。
ただし、この法則にも限界があります。ブルックス自身も後に、この法則が過度に単純化した表現だと認めています。テストや文書作成のように細分化しやすい仕事や、すでにプロジェクトをよく知っている人が加わる場合には、人を増やすことで実際に速くなることもあります。共同作業ツールや自動化が発達した今日では、コミュニケーションにかかる手間が以前より減っているため、法則がどれほど強く働くかは、チームや仕事の性質によって異なります。
結局、ブルックスの法則は、仕事の速さが人数だけで決まるわけではないという事実に気づかせてくれます。人手を増やす前に、仕事がどう分けられ、人々がどうつながっているのかをまず確かめること。それが、スケジュールを守る開発の第一歩です。
