ブルックスの法則と、進捗遅れの対策方法
人月の神話（The Mythical Man-Month: Essays on Software Engineering）の中で有名なブルックスの法則。
「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」
そんなこと言っても、実際にプロジェクトが遅れていたら、まずは人員追加投入という話が出てくるのが現実だ。
なら実際にどうするべきか、何が問題なのか。
PMBOKのタイムマネジメントでも、スケジュール短縮の方法としてのクラッシング（資源追加投入）は、あまり良い結果にならないと示している。
そもそも進捗遅れの原因はどこにあるものなのか。
工程遅れの原因
- 見積りがちゃんとできていない。（プログラマはみんな楽観主義。たぶんこれでいけるよーってやつ-(^^)）
- 努力と進捗を混同している。（人と月が交換出来ると思い込んでいる）
- マネージャーが見積りに自信がないから工程面での頑固さにかける（ちゃんとしたものを作るには時間がかかるという信念）
- 進捗がきちんと監視されていない
- スケジュール遅延したら、要員を追加する。（火に油を注ぐがごとく）
工程遅れの対策案
見積りがちゃんと出来ていないとかの根本的な話題は今回はおいておこう。スケジュール遅延が発生したらどうするかという点を今回は深堀する。
まずは、QCDのうち、納期も作業量も変わらないと仮定すると、出来るのはコスト面の調整だけである。
PMBOKでは、スケジュール短縮技法として以下の２点が挙げられている。
進捗遅れの事例
12人月かかるPJに3人が割り当たっている。
毎月末にチェックポイントがあり、2か月たって1か月遅れであることが分かった。
つまりタスク１を1か月で終わらせる予定が、2か月かかってしまったという事になる。残りは２か月で9人月分の作業がある。
クラッシングを検討
＜対策１＞
前提：見積りがまずかったのはタスク１のみとする。
対策：残り9人月で2か月だから、単純計算なら4.5人必要。1.5人足りない。よって2人追加。
そんな直ぐに仕事出来るわけないから、勉強期間で＋1か月。既存人員もこれに手を取られる。
この時点で、人員追加しなかった場合と同じく1か月遅れのスケジュールである。
さらに、人が増えたことによる作業再分割やコミュニケーションロスによる遅延が増えるかもしれない。
さらにさらに、タスク２、３の見積りも甘ければ、さらに期間が必要になる。
つまり、この事例の場合、クラッシングだと、人員を追加してもしなくても進捗は変わらないか、悪化する。
＜対策２＞
前提：見積りがまずかったのはタスク１のみとする。
対策：1.5人月分が工程上は溢れる作業量となる。このため、これを既存の3人で仲良く3等分して残業実施。
1.5×140H / 3 = 70H で、2か月あるので、ひと月35時間の残業をすればカバー出来る。
余計な教育工数が発生しないので、残業承認されるならば、これが良い。
ただし、タスク２、３の見積り精度が高いことが条件になる。
ファストトラッキングを検討
仮にタスク１～４の内容が下記であった場合、ファストトラッキングの実施は可能。つまり、設計が終わらない内に実装を開始してしまえばよい。しかし、直ぐに分かる通り、前工程である設計に変更が入れば、その時点で、実装工程のファストトラッキングは無駄になる。SW開発ではほぼほぼ成功しなさそうな対策手段である。
| タスク名 | 内容 |
|---|---|
| タスク１ | 仕様 |
| タスク２ | 設計 |
| タスク３ | 実装 |
| タスク４ | テスト |
QCDの前提を見直す
人月の神話では、工程遅れに対しては、基本的に仕様削減で対処せよという見解で書かれている。
つまり、QCDのうち、Qを見直して作業ボリューム自体を減らせということである。
精神的な余裕も出てくるから、これが出来るならベストだ。
PMBOK的に言えば、スコープ定義の変更になる。このため、これを実行に移そうと思えば、プロジェクトのスコープ定義に関わったステークホルダ全員（もしくは、対象要求定義に関わる人）とのスコープ縮小の合意を取っておく必要がある。
そうしないと、勝手に仕様削減して何事だ！という手戻りが発生してしまう。
