「炎上案件で最初に何をすべきか分からず、まず原因を探ろうとして1週間経ってしまった」
炎上初動で最もよくある失敗の一つです。なぜこうなったかを明らかにしようとするのは正しい方向ですが、炎上中に原因分析から入ると、その間も損失・混乱・信頼低下が続きます。
ケガをした直後に「なぜケガしたか」を調べ始める前に、まず出血を止める。炎上対応も同じです。
炎上初動で原因分析から入る危険
原因分析自体は必要です。ただ、炎上の最中に原因を探り始めると2つの問題が起きます。
問題1：原因が決まるまで何も動かない
「原因が分かってから対策を打とう」と考えると、分析が終わるまで手が止まります。現場では毎日問題が積み上がっているのに、PMが分析中で動けない状態が続きます。
問題2：顧客・上司が「何もやっていない」と見る
分析しているのは事実でも、外から見えるのは「まだ状況が変わっていない」ことだけです。炎上中の沈黙は、関係者からは「対応できていない」と受け取られます。
原因分析は止血の後でやります。先に「今日・今週、何を止めるか」を決めることが初動の優先事項です。
止血判断の3対象：顧客・品質・チーム
炎上初動で止血すべき対象は3つです。それぞれに「これ以上悪化させない」ための判断が必要です。
対象1：顧客への信頼低下
顧客が「何も連絡が来ない」「聞いても正確な答えが返ってこない」という状態が続くと、信頼は急速に失われます。内容が整っていなくても、「現在対応中・○日までに状況をお伝えする」という連絡を先に入れることで、信頼低下のスピードを落とせます。
止血アクション：48時間以内に現状報告の連絡を入れる。完全な答えでなくてよい。
対象2：品質・成果物の劣化
炎上中に「急いで対応する」ために品質確認を省略すると、後から別の問題が生まれます。特にテスト省略・コードレビュー省略は、短期的には対処できた気になっても、中期的に別の炎上の種になります。
止血アクション：今週省略しようとしている品質ゲートをリストアップする。省略してよいものと省略してはいけないものを分ける。
対象3：チームの疲弊と混乱
炎上対応で残業・土日出勤が続くと、チームのパフォーマンスが落ちます。加えて、「何のために動いているか分からない」という混乱状態が続くと、メンバーが指示を待つだけになります。
止血アクション：今週チームに伝える優先タスクを3つ以内に絞る。「とにかく頑張る」ではなく「これをやる」を明示する。
まず止めることリスト
炎上初動の1〜3日で、以下を確認してリストアップします。
| 対象 | 今起きている悪化 | 止血アクション | 期限 |
|---|---|---|---|
| 顧客 | 連絡が止まっている | 現状報告を送る | 今日中 |
| 品質 | テストを省略しようとしている | 省略してよいものを分ける | 今週中 |
| チーム | 残業が3週間続いている | 今週の優先タスク3つを決める | 今日中 |
このリストを作るだけで、「今動くべきこと」が整理されます。
原因分析に移るタイミング
以下の条件が揃ったら原因分析に移ります。
- 顧客への連絡が取れており、今後のコミュニケーション計画が合意されている
- 今週・来週の優先タスクが決まっており、チームが動いている
- これ以上急激に悪化する要素が一時的に抑えられている
「完全に安定した後」を待つ必要はありません。燃え盛っている状態から「くすぶっている状態」になれば、原因分析を並行で始められます。
止血後の再計画につなげる
止血判断の後には「今後どう動くか」を設計する再計画フェーズがあります。ここで初めて、原因分析の結果が活きてきます。
「なぜ炎上したか」が分かれば、再計画で同じリスクを避けた計画が作れます。逆に、原因分析なしに作った再計画は、同じ問題を再び起こしやすくなります。
止血→再計画→原因分析の組み合わせが、炎上対応の正しい順番です。
止血とは何かを定義する
「まず止血する」という原則を実行するには、「止血とは何か」をプロジェクトごとに定義する必要があります。一般的には「これ以上の悪化を止める」ことですが、具体的には「顧客からのクレームを止める」「バグの新規報告を止める」「スコープの追加を一時停止する」などプロジェクトの状況によって異なります。
炎上に気づいたら、最初の30分で「今週の止血目標は何か」を決めてください。この目標が決まると、チームの行動の優先順位が揃います。「根本原因の究明」と「止血」が並行して走ると、チームの集中が分散します。まず止血を完了してから根本原因に向き合うという順序を守ることが、炎上対応の成功率を高めます。
根本原因の究明を急がない理由
炎上直後に根本原因を究明しようとすると、「誰が悪かったか」という個人責任の追及につながりやすくなります。チームが守りに入り、情報共有が減少し、問題解決が遅れます。
根本原因の究明は、止血が完了し、プロジェクトが安定してから行うのが理想です。安定した状況で行う振り返りは、建設的な改善につながります。炎上中の原因追及は問題を悪化させることが多いため、「今は止血に集中、原因究明は後で」という原則を徹底してください。
止血後の「収束段階」への移行
止血が完了したら、次は「収束段階」への移行を意識してください。収束段階とは「問題が増えなくなり、解決が進み始めている状態」です。
収束段階に入ったサインは「新規の重大課題が出なくなった」「未解決課題の件数が減少傾向になった」「顧客からのクレームメールが減った」の3点です。このサインが見えたら、止血モードから「計画的な回復モード」に切り替えてください。止血と収束と回復を区別して管理することで、炎上対応全体の見通しが立ちやすくなります。
止血を「完了」と判断する基準を決める
「止血できた」かどうかを判断するには、事前に「止血完了の基準」を決めておくことが必要です。基準なしに止血を続けると、いつまでも止血モードが終わらず、チームが疲弊します。
基準の例として「顧客からのクレームメールが2週間ゼロになった」「新規重大バグの報告が1週間ゼロになった」「追加スコープの要求が一時停止された」など、数えられる指標で定義してください。
止血完了の基準が明確になると、チームに「ここまで頑張れば一段落する」という見通しが生まれ、炎上対応のモチベーション維持に役立ちます。
止血の「担当者」を明確に決める
炎上案件の止血を誰かに任せる場合、担当者を明確にすることが重要です。「チーム全員で止血する」という形は、責任の所在が曖昧になりやすく、結果として誰も積極的に動かない状況になることがあります。
止血の担当者を「バグ修正チームのリード」「テストマネージャー」「PMが兼務」など明確に決め、その担当者が「止血の進捗をPMに日次で報告する」という体制を作ってください。止血の責任者が明確になることで、進捗の把握と対処が速くなります。
炎上対応は「全員で頑張る」よりも「役割を明確にして動く」方が実際には効果的です。
炎上初動の「まず止血する」という原則は、シンプルですが実行には判断力が必要です。何を止血するか・担当者は誰か・完了の基準は何かを明確にすることで、チームが一方向に動けます。止血を完了することが、その後の収束・回復への最短経路です。
炎上案件の初動設計を学ぶ
炎上初動の全体設計・止血判断・再計画スキルは以下で学べます。