炎上後のプロジェクト再スタートチェックリスト：ゼロから積み直す30の確認事項

プロジェクトが一度炎上して立て直しを依頼された場合、「修正」ではなく「再スタート」の覚悟が必要になることが多い。半端な修正では同じ問題が繰り返される。

本稿では、炎上後のプロジェクト再スタートに必要な30の確認事項をカテゴリ別に整理する。

カテゴリ1：現状の正確な把握（最初の1週間）

1. スコープの現状確認 [ ] 当初合意したスコープと現在の実装状況のギャップを文書化 [ ] 「実装済み」「進行中」「未着手」の3分類で全機能を棚卸し

2. 進捗の実態把握 [ ] 「完了」と報告されている機能が実際に動作するか確認 [ ] テスト環境での全機能の動作確認

3. チームの実態把握 [ ] 各メンバーの稼働率・モチベーション・スキルレベルの確認 [ ] バーンアウト兆候があるメンバーの特定

4. ステークホルダーの現状把握 [ ] クライアント・経営層の現在の期待値と不満の明確化 [ ] 誰が「最も怒っているか」「最も懸念しているか」の特定

5. リスクの洗い出し [ ] 炎上の根本原因を5 Whysで特定 [ ] 同じ問題が再発するリスクの評価

カテゴリ2：スコープの再定義（2週目）

6. 実現可能なスコープへの縮小 [ ] 残り期間・予算で現実的に達成できる範囲を正直に評価 [ ] Must have / Should have / Won’t haveで再分類

7. 新しいスコープのステークホルダー承認 [ ] 縮小したスコープへの公式な合意取得 [ ] 削除した機能の「次フェーズ候補」としての記録

8. 受け入れ基準の再確認 [ ] 各機能の「完了の定義」を明確に文書化 [ ] テスト基準・品質基準の明示

カテゴリ3：プロセスの再設計（2週目〜3週目）

9. 変更管理プロセスの導入 [ ] スコープ変更の申請・評価・承認フローの設計と合意

10. 週次レポートの形式確定 [ ] クライアントが「見たい情報」を確認して、レポートフォーマットを再設計

11. リスク管理プロセスの導入 [ ] リスクログの作成と週次更新のルール化

12. エスカレーション基準の明文化 [ ] 「どんな状況になったら誰にエスカレーションするか」を明記

13. 意思決定ルールの設定 [ ] 誰がどんな決定を行う権限を持つかのRACIを更新

カテゴリ4：チームの再整備（並行して）

14. 役割・責任の再確認 [ ] 変更後のRACIマトリクスを全員で確認

15. 期待値のリセット [ ] 「このプロジェクトで何を達成するか」を全員で再確認

16. 心理的安全性の回復 [ ] 炎上中に生まれたチームの不信感・疲弊への対処

17. 1on1の頻度引き上げ [ ] 立て直し期間中は週1回30分の1on1を実施

18. 特定メンバーへの過負荷解消 [ ] 兼務・過負荷メンバーのタスクを再配分

カテゴリ5：ステークホルダー関係の修復（並行して）

19. 正式な「リスタート宣言」会議 [ ] 現状・対策・新しい計画を全ステークホルダーに説明する会議の設定

20. コミュニケーション頻度の引き上げ [ ] 立て直し期間中は報告頻度を倍にする（週次→週2回など）

21. 「勝ちやすい小さな成果」の設計 [ ] 最初の2週間で見えるかたちで成果を出すためのタスク選定

22. 期待値の明示的な合意 [ ] 「いつ・何が・どのクオリティで完成するか」を文書で合意

カテゴリ6：技術的な立て直し

23. 技術負債の優先度評価 [ ] 炎上の技術的原因となった負債の特定と優先度付け

24. テスト環境の整備 [ ] テスト自動化・CIパイプラインの整備で品質の可視化

25. ドキュメント整備 [ ] 設計書・仕様書が現状のコードと一致しているかの確認

26. デプロイフローの整備 [ ] 本番リリースのリスクを最小化するデプロイプロセスの確立

カテゴリ7：軌道に乗るための仕組み

27. 週次KPIダッシュボードの設定 [ ] 立て直しの進捗を数値で確認できる指標の設定

28. マイルストーンの細分化 [ ] 大きなマイルストーンを2週間以内の小さな目標に分解

29. 「成功の定義」の再合意 [ ] プロジェクトが「終わった」と判断できる状態を全員で合意

30. 振り返り（レトロスペクティブ）の定期実施 [ ] 毎スプリント末に「うまくいったこと・改善すべきこと」を振り返る

まとめ

30項目を一度に全部実施しようとすると混乱する。「最初の1週間でカテゴリ1を完了させる」「2週目でカテゴリ2と3に着手する」というように、時系列で優先順位をつけて進める。炎上後の立て直しは「速さ」よりも「確実性」が重要だ。