リスケジュールの際は、前提や想定を確認し続けることが重要。そうしなければ、路頭に迷う
itpjstudy
スケジュール遅延が大きくなり過ぎると、もとの予定のまま進捗管理をしていても、状況把握が難しくなります。そのため、リスケジュールをおこなって、分かりやすく進捗管理が出来る状態に戻します。しかし、リスケジュールしても、すぐに遅れが再発することがあります。そういうときは、リスケジュールする際の想定が漏れていたり、間違っていたりしたということです。
今回は、リスケジュールとは、仮説検証のプロセスであるという観点で、お話をしたいと思います。
Must-Read Insights
リスケジュールは、実態把握ののちに、仮説を立てるということ
Step 1 シミュレーション
まずは、一定期間の実績をもとに、完了予定をシミュレーションします。
具体的なシミュレーションの方法は、「状況変化を継続的モニタすると、将来の着地予想もできるようになる」を参照
[シミュレーション結果]
2週間の予備期間はあるが、それを使っても、このままでは大きく遅延する可能性が高い。
Step 2 シミュレーション結果を裏取り（実態把握）
次に、出てきたシミュレーションが妥当か、裏取りをします。今回は、以下のような裏取りができたとします。
具体的な裏取りの方法は、「状況変化を継続的モニタすると、将来の着地予想もできるようになる」を参照
- 不具合対応が遅れており、シナリオ実施が進まない
- 多くのシナリオを止めている不具合があるが、対応に時間がかかっている
- テスト機のパフォーマンスが遅く、シナリオ実施に時間がかかる
Step 3 仮説をもとに、再シミュレーションする
実態把握で分かった阻害要因に対して対策を考えて、それぞれの効果について仮説を置く。それを踏まえて、再シミュレーションを実施
対策が完了する時期、対策によるスループットの上昇率などについて仮説をおき、再シミュレーションを行う
Step 4 仮説→再シミュレーションを繰り返したのち、リスケジュールを確定する
通常は、最初のシミュレーションでは、遅延を完全にはリカバリできるような結果は出てきません。そのため、他に阻害要因はないか、もっと効果的な打ち手はないかと考えて、何度も仮説→再シミュレーションを繰り返すことが多いように見受けます。
納得がいくまでシミュレーションを実施したのち、リスケジュールを確定して、進捗会議などで利用する公式なスケジュールも更新する
これで、ようやくリスケジュール完了ですが、ここで終わりではありません。
リスケジュールは仮説をもとにしているため、予想が外れることがある。そのため、仮説検証を行わなければならない
Step 5 仮説を検証する
まずは、うまくいったケース。
リスケジュールで設定した予定通りに進捗しており、とりあえずは、仮説通りに進んでいるように見える
➡ 継続モニタ
しかし、うまくいくケースばかりではありません。
シミュレーションの通りには進んでいないため、仮説が間違っていたか、7週目以降に新たな問題が発生したと推測される
➡ 再び、実態把握 → 仮説 → 再シミュレーション
リスケジュールは、しょせんは仮説にもとづくシミュレーションでしかありません。そのため、リスケジュールしても、必ずその通りになる訳ではありません。どちらかというと、問題が発生して、リスケジュールする羽目になるまで追い込まれている状態ですので、全部は見通せていないと考えていた方が無難です。
そのため、仮説は外れるかもしれないと考えて、継続的に仮説検証を繰り返していく心構えが重要です。
実際、リスケジュールに追い込まれるプロジェクトは少なくないと思います。しかし、多くのプロジェクトで、リスケジュールしたあとのフォローが十分にできていないように感じます。
リスケジュールは、あくまで「仮説にもとづくシミュレーション」でしかないと考えて、油断なく継続モニタしていくことが大変重要です。
最後まで読んで頂き、ありがとうございました。ご意見・ご感想を頂けますと幸いです。
ITプロジェクト研究会
