読者です 読者をやめる 読者になる 読者になる

ウォータフォールの弊害 WBS

※用語集

PJ:プロジェクト

 

既存システムへの機能追加PJでした。外部設計者と開発者が異なりました。

追加する機能は1つだけだったのですが、呼び出し元の修正などもあり、設計と開発を並行して進めるようにスケジュールが引かれていました。たしか7つくらいタスクのまとまり(設計=>製造=>テスト=>修正)を並行して進めていました。

 

スケジュールはWBSで管理していました。それぞれのタスクに工数と完了予定日付が設定されていました。「3/1にこのタスクが終わっていれば遅延なし!」といった形でスケジュール管理していきます。

 

まぁただ、設計が順番通り進まないわけです。一番最初に終わっているはずの設計が予定通り終わらずに、先に最後に終わるはずだった設計が終わってしまったりするのです。そうすると設計が終わったタスクから順に開発してきます。

 

これで遅延なく進んでいれば問題ないのですが、遅延なく進んでいるかどうかWBSだと一目で判断できないのです。一目で判断するにはタスクの順番を適切な順番に並び替え、そのタスクの完了予定日付を再算出する必要があります。

それって結構めんどくさいんですよね。無駄な作業だし。

 

Scrumだとそのスプリント内でこなすタスクの総時間と完了したタスクの時間(掛かった時間ではなく、そのタスクの見積時点での時間)と完了していないタスクの時間で管理します。タスクの順番が変わっても、遅延していないかどうかが判断出来ます。

 

ウォータフォールでも工夫すればタスクの順番が変わっても遅延があるかどうか判断できるのかもしれませんが、ウォータフォールの場合、多くはWBSでスケジュール管理を行い上記のような自体になってしまうことが多いように思います。