ブルックスの法則（ブルックスのほうそく）は、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。
これは1975年にフレデリック・ブルックスによって出版された著書『人月の神話』[1]に登場した。
根拠
ブルックスによれば、この法則が成り立つ主な理由は以下の通りである。
- 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる
- ソフトウェアプロジェクトは、複雑な作業である。また、新たにプロジェクトに参加した人は、仕事に取りかかる前に、まず開発の現状や設計の詳細などを理解しなければならない。つまり、新たに人員を追加するには、その人員を教育するために、リソースを割かなければならないのである。したがって、人員の増加がチームの生産性に与える効果は、短期的にはマイナスになる。また、プロジェクトに慣れない間はミスを犯しやすいので、新たなバグが挿入されることが多くなり、その結果、プロジェクトがさらに遅れる可能性もある。
- 人員の投下は、チーム内のコミュニケーションコストを増大させる
- プロジェクトを進めるうえで、プロジェクトチームは、協力して同じ課題に取り組む必要がある。しかし、これを実現するには、調整のためのコストがかかる。一般に、
人が協調して仕事を進めるためには、
のコミュニケーションチャンネルを調整する必要がある。したがって、プロジェクトの人員に対してコミュニケーションコストは、
のオーダーで増加することになる。単純にいえば、開発メンバーを2倍に増やしたチームは、それに伴って4倍のコミュニケーションコストを負担するのである。
- タスクの分解可能性には限界がある
- ホテルの部屋の清掃のような分解可能性の高いタスクであれば、人員投入によってタスク全体の所要時間は短くなる（作業者同士の干渉が起きないかぎり）。しかし、分解可能性の低いタスクもある。
解決策
ブルックスの法則が指摘している問題を避けるためには、プロジェクト全体を小規模のグループが担当できるサイズに分け、より上位のチームがシステムの統合を引き受ける必要がある。しかし、この解決策にも問題がある。なぜなら、プロジェクトを適切に分割できなければ、チームの間の意思疎通コストが増えるので、プロジェクトがさらに大きくなってしまう可能性があるからである。
そのほか分野への適用
ブルックスの法則は、果たそうとする仕事の素性によって、適用できるかどうかが変わる。たとえば、遅延した建設計画で、ダンプトラックを追加投入した場合、計画は遅滞しない。これは仕事の性質上、最小限の技術とトラックだけを持っていたら誰でも業務をすぐ処理できるし、トラック運転手たちどうしで議論をして仕事をする必要も少ないからだ。
一方、ソフトウェア開発のようなデザイン作業では、新たに投入された人員は、プロジェクトに対する基本的な方向や方法、すでに進行している作業に対する教育がなされて初めてプロジェクトに貢献できる。
関連項目
脚注
