「リカバリ計画を出しました」と報告を受けて確認してみると、線がきれいに並んだガントチャートがある。しかし2週間後には再び遅れている——こういう展開は炎上案件でよく起きます。
リカバリ計画が機能しない理由は、計画が「現実の制約」を反映していないことです。やりたいことを並べたスケジュールは、実際に動けるリソース・待ち時間・判断のタイミングを無視しているため、作った翌日から実態とずれ始めます。
本記事では、リカバリ計画が絵に描いた餅になる4つの理由と、現実に機能する計画の作り方を整理します。
リカバリ計画が守られない理由
炎上案件で作られたリカバリ計画が守られないとき、原因は4つのパターンのいずれかに当てはまることがほとんどです。
理由1：現実の制約を入れていない
「フル稼働すれば間に合う」という前提で作られた計画は、現実のリソース状況を無視しています。
確認すべき制約は、担当者の実際の稼働時間（既存業務との兼務や体調面も含む）、休日・祝日・会議の時間、リソースの追加に必要な引き継ぎ時間です。
特に「追加要員を入れてリカバリする」という計画には注意が必要です。追加要員のプロジェクト参加には、環境構築・引き継ぎ・習熟の期間が必要です。追加してすぐ戦力になるわけではありません。
計画を作る前に「実際に動かせる工数は1日あたり何人日か」を確認してください。
理由2：追加作業を見積もっていない
炎上状態のプロジェクトには、通常作業の外に追加で発生する作業があります。
状況報告の頻度増加：炎上中は報告書の作成・会議参加・説明の機会が増えます。この時間がリカバリ作業を圧迫します。
不具合対応の追加工数：テスト中に出てくるバグの対応工数が計画に入っていないことがあります。
手戻り：仕様の再確認・コードレビューのやり直し・テストの再実施などの手戻りは、リカバリ計画に往々にして含まれていません。
これらを計画に入れないと、「作業工数は足りているのになぜ遅れるのか」という状況になります。
理由3：意思決定待ちを入れていない
リカバリ計画の中に「顧客確認待ち」「上長承認待ち」「外部ベンダーの回答待ち」が含まれていても、その待ち時間が計画に反映されていないことがあります。
「確認後すぐ次のタスクに進む」という前提で計画が作られていると、確認に3日かかった時点で計画が3日後ろにずれます。
各外部待ちに対して「最短〇日・想定〇日・最長〇日」の幅を持たせ、「最長で〇日かかる場合の計画への影響」も事前に整理しておくことで、遅れが出たときの対応が早くなります。
理由4：確認タイミングがない
リカバリ計画を作ったあと、「計画が機能しているかを確認するタイミング」が設定されていない場合、計画はそのまま形骸化します。
特に炎上中は1日単位で状況が変わります。「週次での確認」では変化への対応が遅れます。リカバリ中は「日次で進捗を確認する」「3日おきに計画との差分を確認する」など、短いサイクルで状況確認の場を設けてください。
確認のたびに「計画を修正する権限」がPMにあるかどうかも確認します。現場の状況が変わったときに計画を更新できないと、計画が実態から乖離し続けます。
現実的なリカバリ計画の作り方
4つの理由を踏まえて、現実的なリカバリ計画を作る際のポイントをまとめます。
実稼働工数から逆算する：「理論的に必要な工数」ではなく「実際に動かせる工数」から計算します。余裕ゼロの計画は、初日のトラブルで崩れます。
待ち時間をタスクとして入れる：「顧客確認（想定3日）」「上長承認（想定2日）」を計画に明示的に入れます。
確認サイクルを設定する：「〇日おきに計画と実態を比較する」というルールを最初に決めます。
代替案を事前に考える：「この計画が守れなかった場合の次の手」を1〜2パターン用意しておきます。計画が崩れたときに「どうしましょう」から考え始めると、判断が遅れます。
リカバリ計画が機能し始めるサインと機能しないサインの見分け方
リカバリ計画を立てた後、「うまくいっているか」を見分けるための指標を持っておくことが重要です。
機能しているサインは「毎日の残作業が計画通りに減っている」「ブロッカーが翌日までに解除されている」「顧客からの問い返しが減ってきた」の3点です。逆に機能していないサインは「毎週同じ課題が繰り越される」「対応したはずのタスクが再びブロックされる」「チームから新たな問題が連続して出てくる」です。
機能していないサインが2週続いたら、計画の前提を見直す必要があります。「リソースの見積もりが甘かった」「依存関係に見落としがあった」「顧客側の承認プロセスが予想より長い」のいずれかが原因であることが多いです。
リカバリ計画の共有対象を決める
リカバリ計画は、誰に・どこまで開示するかを意識的に決めてください。顧客に全て開示するケースと、社内向けにのみ詳細を共有するケースでは、内容の粒度が異なります。
顧客には「何を・いつまでに完了するか」の計画を共有し、社内リカバリ計画（リソース配置・バッファ量・リスク対処の順序）は上司・PMOと共有する形が基本です。顧客にリカバリ計画の全詳細を見せると、「バッファがあるなら追加要求を入れよう」という判断につながることがあります。共有する内容と共有しない内容を分けて管理することも、PMのスキルの一つです。
リカバリ計画を「守れる計画」にするための設計原則
リカバリ計画が機能しない最大の原因は「達成不可能な前提で組まれている」ことです。守れない計画を立て続けることは、チームと顧客の両方の信頼を失います。
「守れる計画」にするための設計原則は3つです。実績ベースの見積もり（理想ではなく直近の実績工数を基準にする）、バッファの明示（10〜20%の余裕を組み込み、隠さずに示す）、週次マイルストーン（月次の大きな目標より、週次の小さな達成で進捗を確認する）です。
特に炎上案件では、週次マイルストーンの達成が「立て直しが進んでいる」という実感を顧客とチームに与えます。月次の目標だけでは、「どこまで進んでいるか分からない」という不安が顧客に残りやすいです。
リカバリ計画の見直しタイミングを事前に決める
リカバリ計画は「作って終わり」にしてはいけません。計画を見直すタイミングを事前に決めておくことで、状況変化に対応できます。
推奨するのは「2週間ごとの計画見直しサイクル」です。2週間ごとに「計画通りに進んでいるか」「前提に変化があったか」「新たなリスクが出てきたか」を確認し、必要に応じて計画を更新します。
計画見直しは「計画が失敗した」ではなく「現実に計画を合わせている」という積極的な行動です。リカバリ計画の見直しを当初計画への敗北として捉えず、「生きた計画管理」として位置づけることが、炎上案件の立て直しを着実に進める考え方です。
リカバリ計画を機能させるために最も必要なのは、「立てること」よりも「使い続けること」です。現実に合わせて計画を更新する勇気と、達成した小さなマイルストーンを丁寧に確認する習慣が、炎上案件の収束を支えます。
リカバリ計画が「機能しない」原因を知ることが、機能する計画を作る第一歩です。現実的な前提・定期的な見直し・週次マイルストーンの3点を守れば、炎上案件でも着実に前進できます。
リカバリ計画の設計と炎上案件の立て直し手順については、炎上予防・立て直しパックで体系的に学べます。PJ炎上 初動ナビで現在の炎上レベルを確認してから取り組むとより効果的です。