人月の神話-ブルックスの法則について

まず、ブルックスの法則とは 1975 年に出版された『人月の神話』という書籍で提唱された法則です。この本の著者がフレデリックブルックスという名前のため、ブルックスの法則と呼ばれています。ブルックスの法則の 1 番のポイントは、ソフトウェアプロジェクトの要員追加はプロジェクトをさらに遅らせるだけであるという点です。

これは直感に反した内容かと思います。ソフトウェアの開発スケジュールに遅れが生じていた場合、人を追加することがかなり自然な解決策として浮かびます。

しかし、ブルックスの法則では人を追加しても、開発速度は改善するどころか逆にプロジェクトを遅らせてしまうと提唱しています。ブルックスの法則によれば、その理由は主に 3 つです。

プロジェクトが遅れる3つの理由

1 つ目の理由は新たに投入された開発者が生産性の向上に貢献するまで、ある程度時間が必要になるからです。ソフトウェアの開発に新しい人材が入ってくるとまず設計書を読んだり、プロジェクトの進捗を確認したり、コードを読んだりと、実際の作業に入るための事前準備が必要になるため、すぐに活躍できるわけではありません。また、既存のメンバーに対してプロジェクトに関する様々な質問をすることが考えられます。これにより、既存のメンバーは新しい人材の教育コストに足を引っ張られることになります。
更に、優秀ではない人材が入ってきた場合、その傾向はさらに顕著になります。新しいメンバーがすぐにやるべきことを理解できなかったり、業務を怠ったりすると、プロジェクトチーム全体の足を引っ張ることにつながります。

2 つ目の理由は、人員の増加がチーム内のコミュニケーションコストを増大させるからです。プロジェクトを進めるためにはプロジェクトチーム間のコミュニケーションが重要です。チームの人数が増えるにつれてコミュニケーションは複雑になり、コミュニケーションコストは高くなることが予測されますが、ブルックスの法則では、1人増えた際のコミュニケーションコストは単純に考えることはできないと提唱してます。この法則はN 人で協調して仕事をするためには、 「N ( N -1)」 のコミュニケーションチャネルの調整が必要であるとしています。

この法則にそって計算すると、開発メンバーを 2 倍に増やしたチームは、4 倍のコミュニケーションコストを負担することになります。プロジェクトの内部にいる人は、当事者としてコミュニケーションコストの増加を実感しやすいですが、経営者などビジネスの観点で考えている人は、「人員を 2 倍に増やしているのだから、 2 倍とまではいかなくてもプロジェクトのスピードが向上するのではないか？」 「コミュニケーションコストは確かに増えるだろうが、4 倍にまで増えるのは少し考えづらいのではないか」と疑うはずです。

しかし、この法則は理にかなっています。例えば 2人のチームが 4 人になったと仮定します。まず、新しい 2人から最初に学習するドキュメントに対して色々質問が来ます。 2人から同時に質問が来るので、それに対応するためのコミュニケーションコストが必要になります。また、新しい機能を開発をする場合、その機能に対する基礎知識が不足している 2人に説明をする必要があります。もとのチームメンバーと新しい人材の双方からコミュニケーションが発生するため、コミュニケーションコスト が 4 倍になるというのは、適切な数値であるということになります。

 3 つ目の理由は、タスクの分解可能性には限界があることです。タスクの分解可能性とは1 つのタスクを分解し、多くの人に作業を分担して依頼できるかを意味します。

最も分かりやすい例が妊婦と出産の関係です。妊婦は通常9 ヶ月程度で赤ちゃんを出産しますが、9 人の夫婦を揃えたところで1 ヶ月で赤ちゃんを出産することができるわけではありません。

このように、タスクの分解可能性には限界があります。逆に、ホテルの部屋の清掃などは、「この部屋はあなた」というように部屋ごとにタスクを分解し人に依頼しやすい作業であるため、タスクの分解可能性が高いと言えます。

ソフトウェア開発のタスクは分解しにくい

ここで本題に戻ると、ソフトウェア開発は一般的にタスクの分解がしにくい作業です。開発においては要件定義から設計、開発、テストまでの一貫性が求められる作業であるため、タスクを分解するには適しません。
これら 3 つの理由をまとめます。まず新しい人材を 1人入れたとしても、事前学習の時間が最低でも 2  、3 週間必要になるため、その人がチームの戦力になるにはある程度時間を確保しなければならないということです。

さらに、その 2、3 週間の間、既存のメンバーは教育コストとしてその人にプロジェクト外の時間を用いて対応しなければいけませんその人が戦力になった後も、新しい機能開発やテストをする際はコミュニケーションが必須になるため、コストが増大します。

さらに、タスクの分解可能性には限界があるので、現在取り組んでいるタスクを人に渡せないケースも存在します。そのような場合、その人はプロジェクトメンバーであるのにも関わらず、業務内容がないということが発生します。

プロジェクトの遅延を回避するには

では、プロジェクトが遅れている時の解決策ですが、銀の弾丸はないと言われています。つまり、「これさえしておけばプロジェクトの遅れを解決できる」というたった 1 つの有効な施策はないということです。

つまり、プロジェクトが 1度遅れてしまうと取り戻すのはほぼ不可能だと考えた方が良いです。そのため、スケジュールを伸ばしたり、段階ごとのリリースをおこなったりするなど、事前に遅れを防ぐことが効果的です。

しかし、自宅開発の際はこのスケジュールを伸ばすことが難しいケースが多いです。そのため、プロジェクトに取り組む際には、最初の計画を大幅なバッファーを持って作る必要があります。

まとめ

ソフトウェア開発でよく耳にする理論として、ブルックスの法則というものがあります。ブルックスの法則は遅れているソフトウェアプロジェクトの追加要員は更にプロジェクトを遅らせているだけだというものです。その根拠は、入った人材が戦力になるまで時間がかかり、人材が追加で 1 名入るだけでコミュニケーションコストをかなり増大させてしまうということが挙げられます。

また、ソフトウェアのプロジェクトのタスクには分解の可能性に限界があるという 3 つの理由からです。またこれを解決する銀の弾丸のようなものはないと言われています。結局はスケジュールを遅延させることでしか対応ができないと言われています。そのため、最初に計画を立てる際はこの法則を頭に入れ、絶対に遅れないよう、バッファーを持った計画を作る必要があります。