ブルックスの法則とは
遅れているソフトウェア開発プロジェクトに後から人員を追加しても、かえって遅らせることになる
外注に依存している企業が陥りがちなトラップではないでしょうか。
人員が増えてるのになぜ早くならないかと言うと、以下の問題があるからです。
- 新しい人員への教育
- 配置されてすぐに仕事できるわけではない。教育する人の工数もかかるので、その間開発が止まってします。
- コミュニケーションコストの増大
- 人員が増えた分、全員の進捗把握や情報共有・意識共有に時間がかかるようになる
- タスクの分解には限度がある
- 1人だと100日かかるタスクに、99人追加したら1日で終わるかと言うとそうではないという話
人月の神話
多くの企業の工数計算で人月が使われていると思います。1人の人間が1ヶ月で完了できるなら1人月です。
この方式はもともとは建築業などの肉体労働の工数計算に使われていたところから来たと言われています。肉体労働の場合、人数と期間が反比例する（多ければ多いほど早く終る）事が多いため、計算しやすかったと思います。
システム開発においてこの方式が全くうまくいかないのは容易に予想できると思います。単純に人によって1ヶ月にこなせる作業量はぜんぜん違うからです。新人エンジニアとベテランエンジニアの1人月は場合によって10倍くらいの差があるかもしれません。
この人月計算の数値が「多ければ早く終る」の誤解の元凶になっている気がします。
システム開発の進捗遅れは取り戻せない
システム開発の進捗遅れを途中から取り戻すのは極めて難しいです。
現チームの労働時間を月160時間のところを月320時間に増やしたら開発スピードが2倍になるかというとそんなことはなく、人間の体力や集中力には限度があり、無理にそういうことをやっても、開発スピードの低下やバグの多発などで、実際にはせいぜい良くても1.5倍くらいではないでしょうか。
ところが、感情論が高く評価される日本では「進捗遅れを取り戻すため最大全努力する姿勢を見せないといけない」という配慮から、効率悪いと知っていても長時間労働で誠意を見せる傾向があります。
違う解決策を見つける
スケジュールが遅れたときにできる解決策は2つだけだと思います。
- スケジュールを伸ばす
- スケジュールに間に合う内容に変える
- 段階リリースにするとか