ブルックスの法則

1人が10か月かかりきりでやっと終わる仕事があるとします。単純に計算すれば、10人集めて投入すれば1か月で終わりそうですよね。でも、現実はそうは回りません。9人の妊婦さんが集まっても、赤ちゃんを1か月で産むことはできないのと同じです。世の中のどんな仕事にも物理的に時間が必要で、順番に一歩ずつ進めるしかない工程があるからです。

新しく加わったメンバーが、初日から手際よく働くことはできません。既存のメンバーが自分の手を止めて、プロジェクトの目標、システムの構造、現在の進み具合を一つひとつ教える必要があります。その間、頼れるエース級の既存メンバーの作業時間まで削られてしまいます。

結局、新しい人が仕事に慣れて一人前に働けるようになる前に、最初の教育と慣れるまでに使う時間のせいで、プロジェクトの締め切りの時計はいっそう速く「遅刻」の側へ傾いていきます。

人数が増えるとき、もう一つ大きな問題になるのがコミュニケーションです。2人で働くなら、会話の経路はたった1本。ところがメンバーが4人になると線は6本、8人になると28本、10人になるとなんと45本へと、爆発するように増えていきます。

メンバーが増えるほどチャットのルームは入り組み、会議は延々と長くなり、お互いが何をしているのか確かめるだけで大きなエネルギーを使うようになります。本来の仕事を進める時間は減り、会議室に缶詰になる時間だけが増える、というわけです。

こうして、それぞれの成果物をひとつにまとめて調整するためのコミュニケーションコストが雪だるま式に膨らむため、チーム全体の生産性は人数ほどには伸びず、ひどいときにはむしろ下がってしまいます。

ブルックスの法則は、「人を増やすことはいつでも無意味だ」という極端な主張ではありません。レンガを運んだり、単純な梱包作業をしたりするように、仕事の分担がはっきりしていて、お互いに相談する必要のない単純作業なら、人を増やすほど速くなります。

しかし、ソフトウェア開発やデザイン、複雑な企画といった知的労働は違います。自分が書いたコードの1行が、ほかの人の画面にすぐ影響するので、絶えずお互いの作業を確認して突き合わせなければなりません。仕事が複雑になるほど、人を足す効果は半減します。

ですから、すでにスケジュールが崩れてしまった状況では、やみくもに新しい人員を投入するよりも、中核となる機能だけを残して範囲を絞る、あるいは締め切りそのものを現実的に交渉し直すといった方法が、代案としてよく挙げられます。