リスケジューリング・繰り返される再計画とその対処法
プロジェクトの遅延が深刻化すると、どうしてもスケジュールを見直す必要が生じます。そのための手段として、多くの場合「リスケジューリング」という行為を経て、新たなスケジュール＝「再計画」が策定されます。しかし、この“再計画”を何度も繰り返してしまうプロジェクトも少なくありません。
本記事では、リスケジュール（再計画策定のための一連の行為）の全体像を整理しつつ、「なぜ何度も再計画を繰り返すことになるのか、その泥沼からどう抜け出すか」について解説します。プロジェクトが本当に立て直せるのか、それとも際限なく日程を再設定してしまうのか？ その分岐点となる要所をしっかり押さえていきます。
リスケジュールの全体像と再計画を繰り返さないためのポイント
リスケジュールは、以下のステップで進めていきます。
- 現状認識と遅延原因の分析
- フォワードスケジューリング
- 施策の洗い出しとバックワードスケジューリング
- 新しいスケジュールを守るためのリスク管理
- 再計画の承認および実行
ここで重要なのは、単に「作業日程を後ろにずらす」という作業だけを指しているのではない、という点です。そもそもなぜ遅れているのか、その原因をちゃんと把握できているのか、外部制約や内部制約には何があるのか？ そうしたところまで含めて「リスケジュールの一環」として捉えます。
その上で新しい計画（再計画）を立て直し、最終的に承認を得て実行しきることこそが、プロジェクトを“延命”ではなく“軌道修正”へと導くポイントになります。
現状認識と遅延原因の分析
まずは、実際にどれだけプロジェクトが遅延しているかを客観的に把握することが最優先です。ここでいう「客観的」とは、残存タスクと各タスクの残存時間を定量的に示すことを意味します。タスク管理が十分でないプロジェクトほど、この段階で対応すべき作業が山積みになっている傾向があります。
また、再度スケジュールを立て直す原因の一因として、元のスケジュールの精度が低かった（甘かった）ことが挙げられます。そのため、リスケジュールに取り組む前に、まずはスケジュールの精度向上に努める必要があります。スケジュールの精度は、タスクの粒度と見積工数と実績との差異で評価されます。WBS策定においては、ひとつのタスクが80時間（10日間）を超えないよう「8/80ルール」に基づいて設定することが推奨されます。例えば、「業務ヒアリング」というタスクは、業務領域ごとに「準備」「実施」「まとめ（整理）」に分割し、各タスクに適切なステータスを設定することで、見積もりの精度を高めることができます。
さらに、遅延の原因を明確にするためには、外部制約と内部制約の両面に目を向ける必要があります。例えば、「保守切れが○月末に迫っている」といった外部制約は、プロジェクト全体に強い影響を与えます。一方で、「承認フローが形骸化して常に承認が遅れる」「リソース不足の状態で無理に作業を詰め込んでいる」といった内部制約も、遅延の大きな要因です。外部制約が強い場合は、どうしても納期から逆算してバックワードスケジューリングに走りがちですし、内部制約が多い場合は、計画立案前の管理体制自体の見直しが必要になるかもしれません。
これらの要素をおろそかにしてしまうと、せっかく日程を再設定しても、すぐに想定外の問題が再発し、結果としてリスケジュールを繰り返す羽目になるのです。だからこそ、以下のポイントを意識して現状を正確に把握し、改善策を講じることが大切です。
- 残存タスクの洗い出し
- タスクごとにどれだけ工数（時間）がかかるのかを把握する。
- タスク管理が十分でないプロジェクトでは、ここに時間を要することを想定しておく。
- スコープ凍結の必要性
- スコープクリープ（導入範囲が曖昧、変更頻発）の状態であれば、まず凍結タイミングを設定する。
- 不足していた検証や機能追加の洗い出しも並行して行う。
- 遅延原因の分析
- 「開発工数増加」「リソース不足」「スキル不足」「スコープ増加」「承認の遅れ」「日程調整の難しさ」「問題先送り」「バッファ期間の不足」など、遅延の主な要因を整理する。
- 「そもそもWBSがなかった」「進捗を正確に把握できていなかった」「ユーザーとベンダーでゴール感が合っていなかった」「プロジェクト方法論の通りに運営されなかった」など、本質的な問題に掘り下げる。
このように、まずは現状を正確に把握し、外部制約と内部制約の両面から遅延要因を洗い出すことが、リスケジュールの第一歩となります。
フォワードスケジューリング
現状をある程度つかんだら、まずは期限をいったん忘れて、タスクの先行・後続関係と必要なリソースを考慮して、再開日（あるいは現時点）を起点に“現実的なスケジュール”を引きます。これがフォワードスケジューリングです。
「年度末に合わせなきゃいけない」とか「新工場の稼働が⚪︎日に決まっているから、それまでに切り替えなければならない」といった外部制約を無視するのは難しい、と感じる方もいるかもしれません。しかし、最初からそれに縛られてしまうと、どうしても計画に無理が出やすくなり、後々また計画を引き直さざるを得なくなるのが実情です。むしろ、外部制約をいったん脇に置くことで、「もし自由にリソースを割り振り、必要十分なバッファ期間をとったならば、いつ頃本稼働できるのか？」という目安がわかります。これこそが“純粋に計算したときの理想稼働日”であり、後段で行うバックワードスケジューリングとの“ギャップ”を見極めるための基準にもなるわけです。
なお、十数年前はERPの本稼働開始時期が、年末年始やゴールデンウィーク、お盆休みなど、決まった時期に限定されることが一般的でした。しかし、近年では週末にデータ移行を完了させた後、直ちに本稼働へ移行するプロジェクトがほとんどとなっています。短期間でデータ移行を終え、本稼働へと移行する方法の詳細については、「ERP知識シリーズ データ移行①から③」をご参照下さい。
施策の洗い出しとバックワードスケジューリング
フォワードスケジューリングによって導き出された理想的な稼働日と、実際に求められている期限（外部制約）との間には、大きなギャップが生じることが少なくありません。このギャップを埋めるために、次のステップとしてバックワードスケジューリングを行います。
ここでは、「現状認識」のステップで行った原因分析が活用されます。その分析結果をもとに、さまざまな施策を洗い出し、実行可能なものから優先的にスケジュールへ組み込んでいきます。
例えば、以下のような大小さまざまな施策を検討することになるでしょう。
- 並行作業を増やすためのリソース追加投入
- 検証作業迅速化のための業務ユーザーのプロジェクト専任化
- リスク低減のために難易度の高い拡張機能開発要件を削減
- クリティカルパス上のタスクの役割分担の見直し
- 承認がボトルネックになっている場合は、承認フローを見える化し、承認者がスムーズに対応できるようにする
- バッファ期間を再調整する
それでも当初の期限に間に合わない場合は、スコープを絞り、優先度の高い部分のみ先に稼働させることを検討します。
- サプライチェーンと財務会計を分ける
- 基幹系を先に稼働させて、例えば倉庫系や店舗系は後に回す
- 工場ごとに稼働する
これらは副次的にインターフェース開発など新たな課題も出てくるため、増加する工数もしっかり見積もって、バックワードでスケジュールを詰め直します。
ここまでの施策を講じてもなお当初の期限が守れない場合、万策尽きたと判断して本稼働日を見直します。しかし、外部制約であるコンペリングイベントで本稼働日の期限が厳格に定められないと、ユーザー企業からの反発は強まり、場合によってはプロジェクトキャンセルにまで発展する恐れがあります。だからといって、ユーザーの“機嫌”を損なわないための“期限”設定などで済ませてしまうから、何度もリスケジュールする羽目になるのです。
新しいスケジュールを守るためのリスク管理
せっかく策定した施策も、計画通りに実現しない事態は常に起こり得ます。そこで重要なのがリスク管理です。例えば「増員がうまくいかなかった」「開発削減が予定通り進まなかった」といった、想定されるリスクを具体的に洗い出し、その回避策・軽減策、さらには万が一の際の対策（コンティンジェンシープラン）を事前に準備します。
また、リスク対策は単にベンダー任せにせず、ユーザーを含むプロジェクト全体で取り組む必要があります。例えば、検証結果や開発物の承認期限を厳守するため、現行業務を兼任しているメンバーの一部をプロジェクト専任に変更したり、優先順位を上げるといった具体策を講じることが求められます。こうした対策を積極的に実施することで、プロジェクトは「人任せ」や「責任の押し付け合い」といった状態から脱却し、全員が「再計画に沿って進める」という前向きな姿勢を持つようになります。
何度もリスケジュールを繰り返すプロジェクトでは、「ベンダーが承認してくれなかったから遅れた」「ユーザーが情報を提供してくれなかったから進まなかった」といった後ろ向きな報告が散見されます。しかし、このような態度ではプロジェクトは決して軌道に乗りません。だからこそ、施策とリスク管理のプロセスを通じ、プロジェクト開始時の目的や初心に立ち返り、持続的かつ前向きに推進する基盤を築くことが重要なのです。
繰り返される再計画を防ぐために
もし「どうしても時間が足りない」や「要員が不足している」といった問題が再発しそうな兆候が見られるなら、リスク対応をさらに強化する必要があります。具体的には、WBS（Work Breakdown Structure）の粒度を細かく設定し、タスクの進捗をリアルタイムで把握する仕組みを整え、また、承認プロセスで停滞しがちな部分を優先的に改善することが求められます。ひとつひとつの対策は地味かもしれませんが、これらの積み重ねが最終的に再計画の連鎖を断ち切る大きな力となります。
再計画の承認および実行
最後に完成した新たなスケジュール（再計画）を、プロジェクトオーナーや取締役会など、しかるべきステークホルダーに承認してもらう必要があります。
役員でもあるプロジェクトオーナーは、プロジェクト成功の最終責任を負っているため、リスケジュールが実施されると、単に「失敗」としてではなく、改善に向けた積極的な対応として評価される場合もあります。しかし、同時に抵抗勢力が現れ、費用対効果の再検討や組織内での政治的駆け引きが発生することで、承認を得るのが難航するケースも少なくありません。これらの背景から、再計画の承認はプロジェクト全体の中でも最大の難所といえます。
承認が得られなければ、いくら計画を緻密に作り込んでも意味がありません。そのため、十分な資料やデータを用意し、可能な限り早い段階から経営層と連携して根回しを行うことが重要です。取締役会で納得されるレポートを作成するためには、以下の対策が有効です。
- 遅延の原因、追加施策、リスク対策を定量的かつ明確に示す。
- 新たな費用対効果シミュレーションと具体的なリスクマネジメント体制を提示する。
- 次回取締役会の日程を確認し、取締役および関連部門などのステークホルダーとの合意形成を着実に進める。
これらの課題をクリアした後、計画をプロジェクトメンバーに周知し、本番稼働日に向けた実行を開始します。また、承認後は「再度のリスケジュールを行わない」という不退転の決意を、全員が共有することが不可欠です。具体的には、以下の施策が効果的です。
- チーム全体で「決してリスケジュールを繰り返さない」という強い意志を共有する。
- 成果物の完成イメージや成功時の具体的なメリットを示し、メンバーのモチベーションを高める。
プロジェクトが長引くほどメンバーの士気は低下しがちですが、「なぜこのプロジェクトが必要なのか」「やり遂げればどのような価値があるのか」という共通認識が、その維持に大きく寄与します。再計画で作成したスケジュールが単なる形骸に終わらないよう、チーム全員で最後まで走り抜く意識を高めることが極めて重要です。
まとめ
リスケジュールは、「また遅れたから仕方なく日程を後ろ倒しにする」という単なる日程変更ではありません。むしろ、遅延の原因を徹底的に追究し、無理のない形に組み直すための重要なプロセスです。これを軽視して、当初の期限だけを前提にスケジュールを再設定してしまうと、同じ問題が再発し、再計画が連鎖してしまいます。
時にはプロジェクトを一旦リセットし、スコープや体制を大胆に見直す覚悟が必要です。無理に延命しデスマーチ化してメンバーが疲弊するよりも、リスケジュールをチャンスと捉え、ゼロベースで再スタートすることで、全員がフレッシュな気持ちで取り組めるようにするのです。こうしたプロセスを経た後、無事にプロジェクトが稼働した際に「リスケをしっかり行って正解だった」と振り返る瞬間は、仲間同士の絆を深める大切な思い出となるでしょう。メンバーがこの経験を共有できれば、プロジェクトは単なる導入作業に留まらず、組織全体が変革する貴重な機会となるのです。
