Fire Recovery Playbook — From Crisis to Controlled Recovery
SAPプロジェクトを題材に ─ PMO・プロジェクトマネージャー・経営層向け実践書
2026年7月 Paddy&Water株式会社
| 本書を手にとったあなたへ |
本書を読んでいるあなたは、おそらく今、炎上の渦中にいるか、炎上の入口に立っているか、あるいは「これは炎上になるかもしれない」という予感を抱いている状況にあると思います。 本書は「立て直しの理論」ではなく「立て直しの手順書（Playbook）」です。今日から72時間で何をするか。1週間で何を決めるか。1ヶ月で何を達成するか。それを具体的な行動レベルで記述しています。 炎上プロジェクトの立て直しは「プロジェクトを救う」のではなく「プロジェクトを作り直す」ことです。同じメンバー・同じ計画・同じ体制のまま「もっと頑張る」では立て直せません。 |
| 真実 | 内容 | なぜ重要か |
| 真実① 問題は「見えている問題」ではない | 表に出ている問題（スケジュール遅延・テスト不合格）は 症状であり原因ではない。根本原因は「業務設計の失敗」 「意思決定不在」「スコープの無制限膨張」のいずれか | 症状を叩いても根本原因を放置すると 立て直した後に同じ症状が再発する |
| 真実② 人を足しても治らない | 炎上中に追加要員を投入することは「火に油を注ぐ」のと同じ 新規参入者のキャッチアップコストが現場を消耗させる 根本原因が設計品質の問題なら人数は関係ない | 炎上立て直しに必要なのは「質」であり 「量」ではない。スコープを削ることが先決 |
| 真実③ 立て直しは決断の連続 | 立て直しは技術的作業ではなく意思決定の連続 「何を諦めるか」「誰を外すか」「Go-Liveを延期するか」 という不快な決断を先送りした瞬間から再炎上が始まる | 立て直しリーダーに求められる最重要スキルは 「正確な技術知識」ではなく「速い意思決定と それを支えるコミュニケーション力」 |
炎上立て直しで最初にやるべきことは「計画を立てる」ことでも「犯人を探す」ことでもありません。最初の24時間は「プロジェクトが今どういう状態にあるか」を全員が同じ認識を持つことです。これなしに立て直し計画を作っても、各メンバーが異なる前提で動き、議論が噛み合いません。
| 72時間タイムライン（立て直し開始時の標準行動計画） |
【Day 1（0〜24時間）：現状凍結と事実収集】 09:00 立て直しリーダーのアサインを経営層が正式に承認・発表 10:00 全課題・リスクログの「凍結スナップショット」を取得（以降の変更はすべて記録） 11:00 PMO/PMから30分ヒアリング：「何が問題で・誰が何を決定していないか」 13:00 主要コンサル/SIリーダーから30分ヒアリング（PMと別室で実施） 14:00 現場キーユーザー（業務担当）から30分ヒアリング（コンサル不在で実施） 16:00 取得した情報から「5つの問い」に回答（下記参照） 17:00 翌日のステアリングコミッティ召集を経営層に依頼 【Day 2（24〜48時間）：経営層への現状報告と決断要求】 09:00 ステアリングコミッティ：現状を「糖衣なし」で報告（下記「5枚スライド原則」参照） 10:30 経営層から「立て直しの権限委任」を文書で取得 13:00 主要ステークホルダー1対1ミーティング（発注者PMO・IT部門長・主要業務部門長） 15:00 立て直しチームの構成案を作成（誰を外し・誰を核に置くか） 【Day 3（48〜72時間）：立て直し方針の仮決定と宣言】 09:00 立て直し3オプションを提示（スコープ削減案A/B/C） 11:00 経営層・発注者PMOが立て直しオプションを選択 14:00 全プロジェクトメンバーへ立て直し方針を正式通知 16:00 今後2週間の行動計画（Week 1-2 Sprint計画）を策定・配布 |
ヒアリング後の30分で以下の5問に答えられれば、問題の本質と立て直しの方向性が見えます。正直に答えられない項目が多いほど問題は深刻です。
| # | 問い | YESの場合 | NOまたは不明の場合 |
| Q1 | Go-Liveの日程が動かせない 制約になっているか？ | 日程制約の理由（法定・契約・経営判断）を明確化。 制約が事実なら日程を所与としてスコープ圧縮に集中 | 日程がなぜその日付なのかを問い直す。 「決まっているから」は理由ではない。 多くの場合、変更可能だが誰も問いかけていなかっただけ |
| Q2 | スコープの全量が リスト化されているか？ | リストをOpenとClosedに分類し Closedは変更委員会（CCB）なしに戻せないことを合意 | スコープリストがない = 何が終わっていないか誰も知らない状態 最優先でスコープ棚卸しを実施（1〜2日） |
| Q3 | 「誰がYESと言えば 決まるか」が明確か？ | 意思決定者を文書化し、全員に周知する | 意思決定者が不明 = エスカレーション先がないのと同じ 立て直しの最初の仕事は「決める人」を決めること |
| Q4 | 現在のチームで Go-Liveは可能か？ | 現体制での達成可能スコープを試算し それを経営層に提示する（諦める覚悟で） | 「現体制で不可能」という事実を経営層が知らないまま プロジェクトが続いているケースが最多。 不可能なら「何を外せば可能か」を提示する |
| Q5 | 品質（テスト）の問題か 設計の問題か？ | 品質問題なら：テスト体制・自動化・優先度付けで対処 | 設計問題なら：テストを重ねても品質は上がらない。 設計をやり直すための決断と期間確保が先 |
| 炎上報告の5枚スライド原則 — 糖衣を排除した事実報告フォーマット |
Slide 1：現在位置（事実のみ） 「当初計画」vs「現在の実績」：完了予定vs実完了タスク数、遅延週数、品質KPI 判定：スライドの80%は数字。意見・言い訳は一切記載しない Slide 2：根本原因（3つに絞る） 「遅延の根本原因はXです」を3つ以内に絞って明言する 「要因が複数あり複合的に...」という表現は根本原因が特定できていないサイン このスライドで最もよくある失敗：スケジュール遅延の原因を「スケジュールが遅れている」と書く（循環参照） Slide 3：オプション（3つ） Option A：スコープを削減してGo-Liveを守る（削減内容を具体的に記載） Option B：Go-Liveを延期してスコープを守る（延期期間と追加コストを記載） Option C：プロジェクトを一時停止して再設計する（再設計期間・コストを記載） 「Option Dを考えてください」は経営層に丸投げ。選択肢は必ずこちらが準備する Slide 4：推奨と理由 3オプションの中から立て直しリーダーの推奨を明記する 推奨できない = 問題を経営層に転嫁していることと同義 Slide 5：今日決めてほしいこと（意思決定の依頼） 「本日この会議でYES/NOを決定いただきたい事項」を箇条書きで記載 決定事項には「誰が・何を・いつまでに・どのフォーマットで」を明記 |
炎上の実態を正確に把握するために、「スコープ」「スケジュール」「品質」「組織・体制」の4領域で独立して診断します。立て直しリーダーが最初の48時間でこの4領域を診断できなければ、立て直し計画の精度は担保されません。
| スコープ診断 | 優先度 | |
| □ | スコープ一覧（WBS・機能一覧）が文書化されており、全員が同じ定義を参照している | H |
| □ | スコープの追加・変更がCCB（変更委員会）または明確な承認者を経て行われている | H |
| □ | 当初スコープから追加されたスコープの一覧とその承認者・承認日が記録されている | H |
| □ | Go-Liveに必須の機能（Must Have）とGo-Live後でも良い機能（Nice to Have）が明確に区別されている | H |
| □ | スコープの総量に対して現在の完了率（%）が客観的に計算されている（感覚値ではない） | M |
| □ | 「スコープ外」の作業が実質的にプロジェクト内で発生していないか確認している | M |
| スケジュール診断 | 優先度 | |
| □ | 現在のスケジュール遅延が「週単位」で正確に把握されている（感覚や「少し遅れています」ではない） | H |
| □ | クリティカルパス上のタスクが特定されており、遅延の連鎖的影響が計算されている | H |
| □ | Go-Liveまでの残作業量（残タスク数・残工数）が実測値として記録されている | H |
| □ | 「今のペースで進めた場合」のGo-Live予測日が計算されており、当初計画との乖離が明確 | H |
| □ | マイルストーンの達成・未達成の記録が文書化されており、何回計画変更したかが追えている | M |
| □ | テスト・移行・教育の工数が現実的な見積もりとして残り計画に含まれている | M |
| 品質診断 | 優先度 | |
| □ | テスト件数・合格率・未解決バグ数が最新のデータとして把握されている | H |
| □ | バグのうち「Go-Liveをブロックするもの（Blocker）」の数が特定されており、解消目処がある | H |
| □ | 設計書（業務フロー・画面設計・インターフェース仕様）の品質が次フェーズの作業に使えるレベルか評価されている | H |
| □ | テストが「画面を動かす確認」ではなく「業務シナリオの検証」になっているか確認している | M |
| □ | データ移行のリハーサルが実施されており、移行に要する時間・エラー率が実測されている | M |
| □ | 本番環境へのパフォーマンステスト（負荷テスト）が実施されており、業務量での応答時間を確認している | M |
| 組織・体制診断 | 優先度 | |
| □ | 「誰が何を決定できるか」の権限マトリクス（DOA）が文書化されており、全員が知っている | H |
| □ | 発注者側にプロジェクトの意思決定ができる人物が実質的にアサインされており、プロジェクトに充分な時間を割いている | H |
| □ | コンサル/SI側のプロジェクトリーダーが業務設計・システム設計両方の判断ができる力量を持っているか評価した | H |
| □ | エスカレーション事項が積み残されておらず、週次で意思決定されている | H |
| □ | 主要なメンバーの離脱リスク（転職・病欠・異動）が把握されている | M |
| □ | 現場キーユーザー（業務担当者）がプロジェクトに十分な時間を割けているか、兼務過多になっていないか確認した | M |
| □ | 会議が「報告会」でなく「決定会」になっているか：毎回の会議で意思決定事項が明記されているか | M |
炎上プロジェクトの立て直しで最も重要な判断は「スコープを削ること」です。「全部やる」は炎上を継続させる判断です。「何かを諦める」は炎上を終わらせる判断です。立て直しリーダーの仕事は「何を捨てるか」を決断し、その痛みをステークホルダーが受け入れられる形で提示することです。
| スコープ削減の判断基準 — 「何を捨てるか」の優先順位 |
【Step 1：全スコープをMHNリストに分類する（所要時間：2〜4時間）】 M（Must Have）= Go-Liveに法的・契約的・業務継続上必須のもの H（High Value）= なければ業務が非効率になるが、手作業で代替できるもの N（Nice to Have）= あれば便利だが、Go-Live後1年以内に追加できるもの 【Step 2：MだけでGo-Liveできるか試算する】 Mスコープのみの残工数 ÷ チームの生産性 = 最短Go-Live可能日 → この日付が許容範囲内 → Mに絞ってGo-Live → この日付が許容範囲外 → さらにMを絞るか、日程を延期するか判断 【Step 3：Hの中から「短期追加可能なもの」を選別する】 Go-Live後30日以内・90日以内・1年以内のフェーズに分けて Hスコープをロードマップ化。「捨てる」ではなく「後でやる」として合意 【Step 4：Nをプロジェクトから正式に除外する】 CCBで正式に除外決議。「Phase 2検討」として記録。 Nを除外する際は「なぜNになったか」の理由を記録 （後で「約束したはずだ」という議論を防ぐため） |
| 計画要素 | 内容 | 作成責任者 | 完成目標 |
| 立て直し宣言文書 | 何が起きているか・何をどう変えるか・誰が決定権を持つかを 1枚にまとめた「新出発宣言」。プロジェクト全員に配布 | 立て直しリーダー | Day 3 |
| 削減後スコープ一覧 （Revised WBS） | MHN分類後の新スコープ一覧。Go-Live対象と後工程対象を明確化 変更前後の対比表を添付して「何を外したか」を可視化 | 立て直しリーダー + PMO | Week 1 |
| 現実的マスタースケジュール （Recovery Schedule） | 残作業量・チーム生産性・バッファを組み込んだ 「本当に達成できる」スケジュール。週次更新が前提 | PMO | Week 1〜2 |
| 品質回復計画 （Quality Recovery Plan） | Blockerバグの解消計画・テスト再実施計画・ Data移行リハーサルスケジュールを含む | QA担当 + テストリーダー | Week 1〜2 |
| コミュニケーション計画 （Communication Plan） | 誰に・何を・いつ・どのフォーマットで報告するかを設計 経営層/発注者/チーム/サプライヤー別に設計 | 立て直しリーダー | Day 5 |
| リスク登録簿 （Updated Risk Register） | 立て直し後の新リスクを追加したリスク登録簿 各リスクに対策・オーナー・発動条件を明記 | PMO | Week 2 |
炎上プロジェクトの残りスケジュールは必ず3段階で作ります。最初から全作業の詳細スケジュールを作ろうとすると精度が出ず、かえって信頼を失います。
| 段階 | 期間 | 内容 | 精度 |
| Sprint計画 （短期確定） | 今後2週間 | タスクレベルまで分解した確定計画 毎週月曜に翌週分を更新 | ±2日程度 |
| フェーズ計画 （中期見通し） | 今後1〜2ヶ月 | マイルストーン単位のスケジュール 隔週でレビュー・更新 | ±1週間程度 |
| ロードマップ （長期方向性） | Go-Liveまで・Go-Live後 | フェーズの大きな流れとGo-Live目標日 月次でレビュー | ±2〜4週間（許容） |
| スケジュール設計の4つの禁止事項 |
禁止①：「全員フル稼働」前提のスケジュールを作ること → 実効稼働率は公称の60〜70%が現実的。残業・会議・割込み対応を考慮する 禁止②：バッファ（予備期間）を入れないこと → 炎上中のプロジェクトで事前通知なしの問題が発生しない日はない → マイルストーン間に最低10〜20%のバッファを設計する 禁止③：依存関係なしにタスクを並列化すること → 「A完了後にBができる」という依存関係を無視して計画を作ると → 予定通り全員着手しても完成しないスケジュールができあがる 禁止④：スケジュールを「希望」で作ること → 「頑張ればできる」「うまくいけば間に合う」はスケジュールではない → 残工数を実績の生産性で割った「実績ベース完了予測日」を起点に作る |
立て直しで最も難しい判断の一つが「誰を外すか」です。炎上の原因がチームメンバーの能力・姿勢にある場合、人を替えずに立て直すことはできません。しかしこの判断を感情・個人的関係で行うと立て直しリーダーへの信頼が失われます。以下の観点で「機能できているか」を基準に判断します。
| 判断カテゴリー | 具体的な判断基準 | 判断の結果 |
| ロールに対して スキルが不足 | コンサルが業務設計できない PMがスケジュール管理できない リーダーが意思決定できない | スキルのある人への交代または補佐の追加 スキルなしで継続は立て直しの障害になる |
| ロールへの コミットが不十分 | 会議に来ない・資料を作れない 他業務との兼務で実質的に動けない 「やります」と言ったことが常に遅延する | コミット確保か交代。本業に戻すことは相手にとっても誠実 |
| チームへの ネガティブ影響 | 会議で批判・否定のみで建設的提案がない 他メンバーの士気を下げる言動がある PMやリーダーの判断を公の場で否定する | 単独ミーティングでの直接対話→改善なければ別役割へ 放置するとチーム全体に伝染する |
| 役割のミスマッチ | 「担当」と「実務能力」が合っていない （例：品質管理担当なのに品質の判断ができない） | より適した役割への変更。「格下げ」でなく「専門化」として提示 |
| 「人を外す」際のコミュニケーション原則 |
① 決断は速く、伝え方は丁寧に 「外す」という結論を出したら、引き延ばすほど当人・チーム両方にダメージが増える 決断後48時間以内に当人と1対1で話す ② 「あなたが悪い」ではなく「役割と能力のミスマッチ」として伝える 「このプロジェクトに必要なスキルセットと、今のあなたの専門性が合っていない」 批判ではなく「合っていない」という事実として伝える ③ 次のステップを提示する 「このプロジェクトでは別の役割をお願いしたい」か「一旦退いていただきたい」かを明確に 「考えておきます」という中途半端な終わり方は本人をより消耗させる ④ 第三者を入れる 難しい場合はHR担当者や上位のスポンサーに同席してもらう 立て直しリーダー単独での伝達はリスクがある |
| 役割 | 何をする人か | 必要なスキル | よくある配置ミス |
| 立て直しリーダー （Recovery Leader） | プロジェクト全体の立て直しを指揮 経営層・発注者・チームの橋渡し 「何を諦めるか」を決断し宣言する | 決断力と対人コミュニケーション プロジェクト全体像の把握 No（断ること）と言える力 | 技術が得意な人を充てる誤り 問題が起きた部門の責任者を充てる利益相反 |
| PMO（計画管理） | スケジュール・スコープ・課題の現状を 常に最新に保ち数字で見える化する 計画通りか否かを毎週報告する | スケジュール管理・課題管理ツール データを正確に記録・追跡する几帳面さ | コンサルが兼任する誤り（自分のスコープを甘く見る） 発注者と受注者どちらかに寄った立場での運営 |
| 業務設計者 （Functional Architect） | To-Be業務プロセスを設計・判断できる ユーザーが「したい」と言ったことを 「すべきか」まで提案できる | 対象業務領域の実務経験 SAPの標準プロセスへの深い理解 「標準化を説得する」コミュニケーション力 | 業務経験のない若手コンサルを業務設計者として充てる 「ヒアリングして記録する人」を設計者として扱う |
| 品質管理者 （QA Lead） | テスト計画・実施・品質判定を主導 「合格基準」を定義し「合格している」「していない」を判定 Go-Live判定の品質側責任者 | テスト設計（シナリオ設計）の経験 バグの優先度判定力 Go-Nogoを言える立場と力量 | テスト担当者をQAリードとして扱う誤り 「テストをたくさんする人」と「品質判定する人」は別 |
炎上プロジェクトで最も消耗するのは「誰に何をどう伝えるか」が設計されておらず、毎回場当たり的な報告と質問対応に追われる状態です。立て直し初週にコミュニケーション計画を設計することで、報告コストを劇的に下げられます。
| ステークホルダー | 伝えること（内容） | 頻度・形式 | 注意点 |
| 経営層 （スポンサー・CxO） | 現状の数字（完了率・品質・残課題数） 今週の意思決定事項（YESかNOを求める） 立て直しに必要な経営判断 | 週次30分（対面 or ビデオ） 1〜2枚のサマリー資料 | 報告ではなく「意思決定の場」として設計 問題の深刻さを糖衣なしで伝える 「概ね順調です」は最悪の報告 |
| 発注者PMO （プロジェクトオーナー） | 詳細な進捗・課題・変更事項 週次の判断事項リスト リスクの現状と対策 | 週次60分（定例会議） 進捗レポート1枚 | 課題を全部並べるのでなく「判断が必要なもの」に絞る 課題の深さと広さを正確に伝える |
| 業務部門長 （キーユーザーの上長） | 業務への影響（何が変わるか・変わらないか） キーユーザーへの協力依頼 Go-Live後の業務変更点 | 隔週30分 業務影響サマリー | 「システムの話」でなく「業務の話」として伝える IT用語を避け業務言語で話す |
| プロジェクトチーム 全メンバー | 今週のスプリント計画・達成目標 課題と対策の最新状況 良いニュース（小さな達成も重要） | 週次30分（全員参加） +日次15分（Standup） | 「情報格差」を作らない。全員が同じ情報を持つ 炎上中は「聞いていない」が不信感の種になる |
| コンサル・SI責任者 | 詳細課題・技術的判断事項 スケジュール達成の障害 | 週次60分（技術定例） 課題管理表 | 立て直しリーダーが直接出席し 「言い訳モード」にさせない明確な事実確認 |
| 炎上立て直し期の会議設計原則 |
原則①：議題のすべてに「決定事項」か「情報共有」かのラベルを付ける 「決定」ラベルの議題は必ずその会議でYES/NOを出す 「次回に持ち越し」は原則禁止（立て直し期は持ち越しが炎上を延長させる） 原則②：議題の数を絞る（会議ごとに最大3項目） 多くの議題を詰め込むほど何も決まらない 最重要3項目を決め、残りは書面報告にする 原則③：会議の最後5分は「Action Item確認」に使う 誰が・何を・いつまでに を全員の前で読み上げて確認 会議後30分以内に議事録（議題・決定事項・Action Item）を配布 原則④：「課題が多すぎて時間が足りない」場合は別途課題解消ワーキングを設ける 定例会議を課題の洗い出しの場にしてはいけない 課題解消は別のWG（ワーキンググループ）で行い、定例では解消済みと未解消のみ報告 原則⑤：会議に「決定権がない人」だけを集めない 報告を聞く人だけが集まった会議は情報交換会 決定権者が1名以上出席していない会議を「決定会」として開催しない |
立て直しフェーズは長期計画よりも「2週間スプリント」による短サイクルPDCAが有効です。2週間で計画→実行→レビュー→次スプリント計画を回すことで、実態に即した計画への適応が可能になります。
| スプリントの日程 | 活動 | 参加者 | アウトプット |
| Sprint Day 1（月曜） | スプリント計画会議 2週間で達成するタスクを全員でコミット | 全チームメンバー PMO・リーダー | スプリントバックログ （タスク一覧・担当・完了条件） |
| Sprint Day 1〜9（月〜翌週金曜） | 日次Standup（15分）：今日やること・昨日やったこと・障害 障害はその日のうちにエスカレーション | 全チームメンバー | 日次進捗記録 障害解消ログ |
| Sprint Day 10（翌週金曜） | スプリントレビュー：完了タスクのデモ・確認 スプリントレトロ：良かった点・改善点を30分で振返り | 全チームメンバー 発注者キーユーザー | スプリント完了報告 次スプリントへの改善事項 |
炎上立て直し期は「全てのテストをやり直す時間はない」という現実から出発します。テスト優先度付けにより、限られた時間で最大の品質確保を実現します。
| テスト優先度 | 対象 | 基準 | テスト時間の目安 |
| P0（Blocker必須） | Go-Liveをブロックするバグの修正後テスト 法的・コンプライアンス要件に関わるシナリオ 財務計算・在庫処理・受発注の基幹シナリオ | このテストが通らなければGo-Live不可 | 残時間の50%を投入 |
| P1（必須） | 主要業務シナリオ（利用頻度Top20のトランザクション） 月次・年次処理（バッチ・締め処理） 外部システム連携（EDI・銀行・EC） | このテストが通らなければ業務停止リスク | 残時間の30%を投入 |
| P2（重要） | サブシナリオ・例外処理 報告書・帳票の出力確認 パフォーマンステスト | 通らなければ業務に支障が出るが 手作業での代替手段がある | 残時間の15%を投入 |
| P3（後工程） | 低頻度シナリオ・将来機能 「あれば便利」レベルの確認 | Go-Live後に順次対処可能 後工程バックログとして管理 | 残時間の5%（必要に応じて後日） |
Go-Live判定は「全てが準備できているか」ではなく「Go-Liveして業務継続できる最低条件を満たしているか」で判断します。炎上立て直し後のGo-Liveは特に、この基準を事前に合意しておかないと「まだ心配だ」という感情論でGo-Live延期が繰り返されます。
| Go / No-Go 判断チェックリスト | 優先度 | |
| □ | P0テスト（Blocker必須）が全件合格しており、未解消のBlockerバグがゼロである | H |
| □ | P1テスト（主要業務シナリオ）の合格率が90%以上である | H |
| □ | データ移行リハーサルが本番データ量の50%以上で実施済みであり、移行エラー率・所要時間が許容範囲内 | H |
| □ | 本番環境でのパフォーマンステスト（業務ピーク想定）が完了し、応答時間の合格基準をクリアしている | H |
| □ | キーユーザートレーニングが完了しており、主要業務担当者全員がSAP操作を独力でできることを確認した | H |
| □ | Go-Live後の運用体制（ヘルプデスク・障害対応チーム・ベンダーサポート）が稼働準備完了している | H |
| □ | Go-Liveのロールバック（切り戻し）手順が文書化されており、ロールバック判断基準（誰が・何をもって）が合意されている | H |
| □ | 監督官庁・顧客・サプライヤー等、Go-Live影響する外部関係者への通知が完了している | M |
| □ | Go-Live後2週間の「安定稼働期間」のサポート体制（増員・延長対応）の計画が確定している | M |
炎上から立て直した後、3〜6ヶ月以内に再び問題が再発するプロジェクトは少なくありません。「立て直した」という安堵感で根本原因の対処が不完全なまま終わるからです。
| 再燃パターン | 発生する理由 | 防止策 |
| スコープクリープ の再発 | 立て直し後「追加要望を断れない」雰囲気になり 外したスコープが再び持ち込まれる | CCBを恒常的に機能させ 追加スコープの影響試算を必ず提示してから判断 |
| 品質劣化の 見えない進行 | Go-Live後の機能追加・設定変更で テストを省略する習慣が定着する | 全本番変更にテスト完了証跡を義務化 リグレッションテストの自動化を早期に実装 |
| 意思決定者の 後退 | 立て直し期に強い関与をしていた経営層が 安定後に離れ、意思決定が滞る | 四半期ごとのプロジェクトレビューを 経営層参加で継続。恒常的な権限委任構造を設計 |
| コンサル依存の 継続 | 立て直し後もコンサルがいないと判断できない状態が続く | 社内人材へのナレッジトランスファー計画を 立て直し開始時から並行して実施 |
| 根本原因の 未解決 | 炎上症状は消えたが根本原因（業務設計品質・意思決定構造）が 残ったまま別プロジェクトで再発 | Root Cause Analysisを実施し 組織課題（採用・育成・調達プロセス）への対策まで落とす |
| 炎上しないプロジェクトの「当たり前」チェックリスト |
以下が全て「当たり前」として機能していれば炎上は予防できる: 意思決定の体系 ✓ DOA（権限委任表）が文書化されており、判断事項のレベルに応じて誰が決めるかが明確 ✓ 変更委員会（CCB）が月1回以上稼働し、スコープ変更が必ず通過する ✓ エスカレーション先と期限（例：48時間以内に回答）が定義されている スコープ・計画の管理 ✓ WBS・機能一覧が最新版として1箇所で管理されており、全員が参照する ✓ スプリント計画→実行→レビューの2週間サイクルが止まらずに回っている ✓ 計画変更の際は「なぜ変わったか」の理由が記録されている 品質の担保 ✓ テスト完了の定義（Done Definition）が合意されており「なんとなく完了」がない ✓ 本番変更には必ずテスト証跡が添付される手順が徹底されている ✓ 月次でバグ件数・解消率・残テスト件数がトラッキングされている コミュニケーション ✓ 週次の全体会議（決定会）・隔週の経営報告が継続している ✓ 悪いニュースが早く上がる文化がある（遅れを隠さない） ✓ 問題を発見した人が「報告しやすい」心理的安全性が保たれている |
プロジェクト完了（Go-Live安定稼働確認）後に実施するPost Mortem（事後検証）は、炎上プロジェクトの知見を組織に残す唯一の機会です。「犯人探し」でなく「次のプロジェクトを炎上させないための学習」として設計します。
| Post Mortem 構成要素 | 内容 | ファシリテーター | 参加者 |
| タイムライン復元 | プロジェクト開始から完了までの主要事象を 時系列で客観的に記述（評価なし） | 外部・中立の第三者が理想 | 全主要メンバー |
| 良かった点 （Keep） | 炎上立て直し・プロジェクト全体を通じて 「次もやる」と合意できる取り組み | — | 全主要メンバー |
| 改善点 （Problem） | 炎上の原因・立て直しで困難だったこと 次回は変えたい点 | — | 全主要メンバー |
| 具体的な改善策 （Action） | 次のプロジェクトで実装する具体的な プロセス変更・ツール変更・人材育成計画 | プロジェクトスポンサー （実行コミット） | 経営層・PMO・リーダー |
| ナレッジ文書化 | 設計判断の背景・失敗と学習を 社内wiki・プロジェクト完了報告書にまとめる | PMO | — |
以上