広告・PR：この記事にはアフィリエイト広告を含みます。
開発が予定より遅れている。人を増やせば、その分だけ早く終わるはず。そう考えても、現場では説明や調整に時間を使い、かえって完成が遠のくことがあります。この落とし穴を表すのが、ブルックスの法則です。
目次
ブルックスの法則の意味
ブルックスの法則は、遅れているソフトウェア開発へ人員を追加すると、さらに遅れることがあるという経験則です。フレデリック・ブルックスが著書『The Mythical Man-Month』で論じました。
原文では「遅れたソフトウェアプロジェクトに人を加えると、さらに遅れる」と強い言い方で示されますが、著者自身も、非常に単純化した表現であると述べています。原著の該当章では、人数と期間を単純に交換できない理由が説明されています。
増員すると、何が増える？
1．引き継ぎと学習の時間
新しく入った人には、仕様、コードの構造、開発環境、判断の経緯を知る時間が必要です。説明する人も、もとの作業を止めることになります。能力のある人でも、その製品固有の知識を最初から持っているとは限りません。
2．連携と確認の時間
担当する人が増えると、変更内容を合わせる必要があります。全員が互いに直接調整すると仮定した場合、2人ずつの組み合わせはn×(n−1)÷2。3人なら3組、6人なら15組です。
これは組み合わせの数であって、会議時間が必ず5倍になるという計算ではありません。担当の境界や連絡の経路を整理すれば、全員が全員と相談する必要は減らせます。
3．並行できない作業
仕様が決まらないと実装を確定できない、修正した版ができないと最終確認できないなど、順番が必要な作業があります。作業量の合計だけでなく、どこが次の作業を待たせているかを見る必要があります。
人月が同じでも、完成時期は同じとは限らない
1人が10か月働くことと、10人が1か月働くことは、投入する人月だけなら同じです。しかし、仕事を10個に切り分けられるか、知識を共有する時間はどれくらいか、統合後の確認はいつできるかが違います。
人数を足すだけでは、依存関係や調整の負担は消えません。これはソフトウェアで特に目立つ問題ですが、ほかの仕事でも、準備・連携・作業の順番があれば同じ視点で考えられます。
増員が役立つのは、どんな場合？
独立して進められる仕事があり、受け入れる準備ができていれば、増員は役立ちます。たとえば、手順が整った別の端末での確認や、仕様が固まった画像素材の作成などは、分担の候補になりえます。どちらも内容によるので、切り出す前に必要な知識と完成条件を確認します。
- 遅れている原因を、作業量・未決の仕様・不具合などへ分ける。
- 人が増えたら任せられる仕事を、具体的に選ぶ。
- 説明する人の時間も、予定に入れる。
- 担当の境界と、受け渡すものを決める。
- 今回は出さない機能など、範囲の調整も考える。
アプリ開発なら、最初に小さな境界を作る
問題データ、回答判定、画面の表示が混ざっていると、複数人で同じ場所を直すことになりがちです。それぞれの責任を分け、入力と出力を決めると、説明や確認もしやすくなります。謎解きアプリの設計や回答判定の作り方でも、この分け方を紹介しています。ブルックスの法則は、増員を諦めるためではなく、人が役立てる形に仕事を整えるための問いとして使えます。
増員できる仕事と、説明が先に必要な仕事
独立した確認作業を手順付きで渡せる場合と、全員が同じ複雑な設計を理解してから触る場合では、増員の影響が違います。人数を決める前に、切り離せる成果物、説明する人の時間、統合時の確認を見積もります。人数だけから遅延の大きさを計算できるわけではありません。