炎上中の案件に追加要員を入れることがありますが、追加要員を入れるのはプロジェクトを進める中でオススメできません。
なぜ追加人員を投入したのにプロジェクトの助けにならないのかを今回は【ブルックスの法則】を使用してご説明させて頂きます。
ブルックスの法則
ブルックスの法則の要点は以下になります。
ブルックスの法則はフレデリック・ブルックスによって提唱された、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。
これは1975年に出版された著書 "The Mythical Man-Month"（邦題：『人月の神話』）に登場した。
- 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる。
- 人員の投下は、チーム内のコミュニケーションコストを増大させる。
- タスクの分解可能性には限界がある。
解説
開発の追加要員は生産性の向上に貢献するまでには時間がかかる。
新たに人員を投入した際にプロジェクトの現状や設計の詳細などを理解するまで時間がかかる。
新たな追加した人員の生産性向上させるために教育のため既存の人員のリソースを割かなければイケない。
そうなると短期的には生産性の低下が発生し、また追加した人員は慣れない間はミスを犯しやすくプロジェクトのさらなる遅延につながる。
追加人員はチーム内のコミュニケーションコストを増大させる。
プロジェクトチームは協力してして同じ課題に取り組む必要があり、課題の共有や打ち合わせの調整のためのコストがかかる。
n人が協調して仕事を進めるためには、n(n-1)のスケジュールなどを調整する必要がある。
プロジェクトの人員に対してコミュニケーションコストは、 n²のオーダーで増加することになる。
開発メンバーを2倍に増やしたチームは、それに伴って4倍のコミュニケーションコストを負担するのである。
タスクの分解可能性には限界がある。
1人の妊婦が9か月で赤ちゃんを出産できても、9人の妊婦が1ヶ月で赤ちゃんを出産することはできないのである。
タスクの最小分解が決まっているので人数を増やしたところで人員に適切に割り振りが出来ない問題がある。
それでも投入される人員
それでも遅延してるプロジェクトには人員が投入されます。
上記のことを踏まえると追加人員に依頼出来るタスクは「テスト」になりやすいです。
- テストはテスト仕様書があれば可能。
- テスターには情報を共有しなくてもいい（テスト仕様書を淡々とやってもらう場合）
- テストはテストケース毎にタスクを分解しやすい
まとめ
案件が炎上すると安易に追加人員を求めることがありますが、上記の理由から炎上する前に人員を投入しないと効きません。
なので炎上案件になるとテスターを募集し始めて、開発者が行ってた「開発&テスト」の作業から「開発者とテスター」にタスクを分割し始めます。
ソフトウェア開発は人月作業に置き換えられますが、人を集めても早く終わるという単純なことはありません。
0 件のコメント :
コメントを投稿