CAPDで回す炎上プロジェクト——「頑張ります」の代わりに「消火の型」を

「気合で乗り切る」以外の選択肢はありますか？

「要件が固まってないのに開発が始まった」「キーパーソンが不在でGOが出ず停滞中」「納期直前に仕様変更」「情報連携されてない」「作業者が問題を隠していた」——日々さまざまな問題は起きますが、何をもって炎上と呼ぶのでしょうか。

「これローンチ予定日に間に合わないな」とあなたが、現場が、気づいた瞬間。
そこを一つの境目として、プロジェクトは静かに炎上へと足を踏み込んでいきます。

本記事では、期限付きプロジェクトが「間に合わない」と気づいた瞬間からの立て直し術——CAPDサイクルを紹介します。
運用改善の話ではありません。
納期が迫るなかで炎上を鎮火し、着地点を見つけるための消火の型を、ANDGATE METHODSが精神論抜きでまとめました。

 発火源別の対処法は「3-4. Step 4. D（Do）——発火源別に消火し、再燃を防ぐ」へ

OUTPUT：CAPDを回すと何が手に入るか

本記事で紹介するCAPDのプロセスを回すと、「頑張ります」だけじゃない、説明・交渉・再合意に使える「次へのINPUT」が揃います。

1. 健康診断レポート
   下記4ベースラインの判定表。
   どこで・何が・どれくらい燃えているかが一目でわかる。
   C（Check）のアウトプットであり、最後の「再びC」で鎮火判定に使う比較基準にもなる。
   • スコープ・ベースライン
   • スケジュール・ベースライン
   • コスト・ベースライン
   • パフォーマンス測定ベースライン（PMB）
2. 着地シナリオ比較表
   QCDのどこを譲るかを「ベスト・リアル・ワースト」の3シナリオで整理することで、「どうしますか？」ではなく「どれで進めますか？」と提示できる。ステークホルダーへの説明資料としてそのまま使える。

本記事のDOWNLOAD CONTENTでは、上記を出力するClaudeスキルを配布しています。

1. 「炎上」を分解する

火は突発的に燃え広がるのではなく、いくつかの要因が積み重なった結果として炎上状態になります。
「なぜ炎上したのか」を分解すると、火種は4つに集約されます。

発火源①：認識・調整不足（言った言わない、仕様のコロコロ変更）

• 仕様がわからない
• 仕様がコロコロ変わる
• 仕様に対しての合意ができてない
• スコープが明確にできてない
• レビューが甘い
• 検証できてない

発火源②：計画・見積の甘さ（終わらないタスク、溶けるコスト）

• タスクが完了するのが遅い
• 予算が削減された
• タスクのサイズ・役割・スコープが適切じゃない
• 設計が甘い

発火源③：体制・属人化の罠（キーマン離脱、ブラックボックス）

• 担当者がいなくなった
• ドキュメントを残してない
• 特定の人に聞かないとわからない状態の常態化

発火源④：アンコントロール（外部遅延、前提条件の崩壊）

外部依存の遅延・前提条件の変化など、制御が効かないもの。

こうした発火源に直面したとき、人は「まだ大丈夫」と全体像を見失い、「ここまでやったから」と損切りを先延ばしにし、「誰が悪いか」に時間を使って「どう着地するか」を後回しにしてしまいます。
そして炎上レベルが上がるほど、「気合でなんとかする」に流れていく。
——これらの判断の歪みが、ボヤを大火災にしていきます。

だからこそ、型で動く必要があるのです。

2. INPUT：消火活動を始める前に集める材料

炎上を認識した瞬間にやるべきは「新しく考える」ことではなく、意思決定に必要な情報を最短距離で集めることです。
資料を探して半日溶かすくらいなら、10分話せる人を1人見つけたほうが早い。
まずは「資料」ではなく「情報の供給源（人・場所）」を押さえます。

2-1. 「これだけ」の最小INPUT3点

最低限必要なINPUTは3つだけ。
これらが揃うと「間に合うか／何を切るか／誰に何を言うか」を整理して、CAPDを回し始めることができます。

2-2. 炎上のINPUTに「あると心強い」材料7点

ここから先は「あると心強い」材料。重要なのは、資料がないなら「存在しない」ことを事実として記録すること。それ自体が重要な情報となります。

• 議事録・会議メモ——合意の証跡。「OK」「了解」の文脈と範囲を確認
• 契約書・発注書・SLA——責任分解の根拠、発動できる条項の確認
• 要件定義書・仕様書——仕様のベースライン。変更管理の基準線
• 変更履歴・変更依頼ログ——スコープの変更を追うための材料
• 組織図・体制図——責任の所在。曖昧なら「曖昧だ」と認識することも一助になる
• 課題管理表・リスク管理表——既知リスク・未解決課題の一覧
• メール・チャットの証跡——口頭合意の裏付け

2-3. 「ない」を次の一手に変換するヒント

• 議事録がない → 合意の証跡が存在しない ＝ スコープ争いリスク
• 契約書が出てこない → 責任分界が曖昧 ＝ ステークホルダー調整が先（決裁ライン確保を優先）
• 契約（条項）が使えない → 交渉カードがない ＝ 待ちが発生しやすい（中間の合意・チェックポイントを先に作る）
• 「了解」の範囲が不明 → 合意範囲が分解されていない ＝ 追加要件の混入リスク（合意範囲を棚卸しして再合意が必要）
• 口頭合意の裏付けがない → 証跡がない ＝ 言った言わないリスク（ログの確保 or 議事録運用を必須化）
• 暗黙の前提が多い → 前提が言語化されていない ＝ 再燃リスク（前提を列挙して合意取り直し）
• 資料そのものが存在しない → そもそも基準線が存在しない ＝ スコープ紛争リスク（最小の合意ドキュメントを今から作る）

3. PROCESS：現場で回す消火の型——CAPD

まず必要なのは、火の規模を把握することです。
初動は、CAPD（Check→Act→Plan→Do）という消火のフレームワークを通して考えることで、INPUTを実行可能なアクションに分解することができます。

Actの後にもう一度Checkを実施。
「鎮火したか、まだ燃えてるか」を判定するまでをワンサイクルと考え、完全に火がおさまるまで、ループを回します。

3-1. Step 1. C（Check）——最初の30分で「火の規模」を測る

材料を集めたら、まず現状の可視化をしましょう。
以下の3つの軸で状況を把握します。

• 残時間と残タスク——あとどれだけの時間で、何を終わらせる必要があるか
• 最大のボトルネック——すべてのタスクが等しく燃えているわけではない。最大の問題がどこにあるのかを特定する
• 影響範囲のマッピング——何が・誰に・いつ影響するのかを整理する

この3つを、以下の4つのベースラインで測定します。
完璧に情報を把握する必要はなく、30分で全体像をつかむことが目的です。

この測定結果をまとめることで、プロジェクトの「健康診断レポート」を作ることができます。
ネクストステップのA（Act）で共有する第一報のベースになり、さらに、P（Plan）を組み立てるためのインプットにもなります。

3-2. Step 2. A（Act）——初動で火を止める

火の規模がわかったら、計画を立てる前にまず手を打つ。
燃え広がりを止めるための初動です。

第一報を出す

把握した被害状況は、すぐ共有すること。「もう少し調べてから…」と思った瞬間に、ボヤが大火事に広がります。
不完全でよいので、「今わかっていること」と「まだわかっていないこと」を分けて、上位者・顧客に第一報を出しましょう。

最悪ケースのシミュレーション

「このまま何もしなかったら、3日後にどうなってる？」を具体的にイメージする。
これがエスカレーションの根拠になり、P（計画）の出発点にもなります。

応急処置：これ以上燃やさない

• 影響が拡大中のタスクを一時凍結——走り続けるより止めたほうが傷が浅いこともある
• 暫定の意思決定ラインを確保——キーパーソン不在なら代理承認者を即決
• 情報の一元化——散らばっている情報を1か所（課題管理表・Slackチャンネルなど）に集約

「計画を立ててから動く」のがPDCA。「まず目前に迫る火を消してから計画する」のがCAPDです。

3-3. Step 3. P（Plan）——現実的な消火計画を立てる

炎上プロジェクトにおける計画とは、Q（品質・スコープ）・C（コスト）・D（納期）のどこを譲り、どこを死守するかを決めること。「理想の計画を立て直す」ことではありません。

• Q（品質・スコープを譲る）——機能先送り・運用カバー・非機能要件緩和・テスト範囲絞り込み
• C（コスト調整）——追加請求・自社負担＝「貸し」記録・責任分界の再交渉・分割検収
• D（納期調整）——リリース延期・フェーズ分割・マイルストーン再定義・並行稼働延長

そしてこの3シナリオを持って、即エスカレーション。
自分たちだけで着地点は決められないから、顧客も巻き込んで一緒にQCDの優先順位を決めていく。
「言いにくい」の先送りがいちばんのコストであり、焼け野原にしない着地点を見つけることこそがプロの仕事です。

 よくある状況は「よくある質問（FAQ）」で

3-4. Step 4. D（Do）——発火源別に消火し、再燃を防ぐ

計画ができたらいよいよ消火活動。発火源ごとの対処法を回していきましょう。
着地シナリオを用意したら、ここからが消火の本番です。
ただし、有効な打ち手は発火源によって異なります。自分のプロジェクトがどのタイプに当てはまるか確認してから、該当する手順へ進んでください。

•  「言った言わない・仕様ブレ」→ ① 認識・調整不足
•  「タスクが終わらない・コスト超過」→ ② 計画・見積の甘さ
•  「キーマン不在・情報がブラックボックス」→ ③ 体制・属人化
•  「外部遅延・前提が崩れた」→ ④ アンコントロール

発火源①：認識・調整不足（言った言わない、仕様のコロコロ変更、合意不足）

認識のズレが火種になっている場合、情報は常に不完全で、待っていても正解は降ってきません。
ここではOODAループ（観察→状況判断→意思決定→行動）の考え方をベースに、相手と一緒に高速で認識合わせを回していきます。

発火源②：計画・見積の甘さ（タスクが終わらない、予算削減、スコープが不適切）

計画の甘さが火種の場合、プロジェクト全体をどうにかしようと挑んでも勝ち目はありません。
スコープを一点に絞って、相手と共同で優先順位を決めていきます。

発火源③：体制・属人化の罠（担当者がいなくなった、ドキュメントがない、ブラックボックス化）

属人化とは、知識が個人に閉じている状態です。
暗黙知を形式知に変換し、「あの人に聞かないとわからない」状態を解消していきます。

発火源④：アンコントロール（外部起因の遅延、前提条件の崩壊）

外部要因で燃えている場合、待っていても状況は好転しません。
「ここから先は燃やさない」線を引き、被害の最小化に努めます。

3-5. Step 5. 再びC（Check）——「正常」か「まだ燃えてる」かを判定する

A（Act）まで回したら、もう一度Checkに戻る。
Step 1で作った健康診断書の4つのベースラインに対して、今の状況を再測定します。

4. よくある質問（FAQ）

よくある疑問に、ANDGATE METHODSの視点でお答えします。

5. LOGIC COMMENT：ANDGATEとしての意味

どれかひとつが欠けても鎮火はできません。
すべての入力を揃えてから、出力を得る。
それがANDGATE METHODSの思想で、炎上プロジェクトにおける生存戦略そのものです。

Appendix.

A-1. 炎上のINPUTに「あると心強い」材料7点

ここから先は「あると心強い」材料。重要なのは、資料がないなら「存在しない」ことを事実として記録すること。それ自体が重要な情報となります。

• 議事録・会議メモ——合意の証跡。「OK」「了解」の文脈と範囲を確認
• 契約書・発注書・SLA——責任分解の根拠、発動できる条項の確認
• 要件定義書・仕様書——仕様のベースライン。変更管理の基準線
• 変更履歴・変更依頼ログ——スコープの変更を追うための材料
• 組織図・体制図——責任の所在。曖昧なら「曖昧だ」と認識することも一助になる
• 課題管理表・リスク管理表——既知リスク・未解決課題の一覧
• メール・チャットの証跡——口頭合意の裏付け

A-2. 「ない」を次の一手に変換するヒント

• 議事録がない → 合意の証跡が存在しない ＝ スコープ争いリスク
• 契約書が出てこない → 責任分界が曖昧 ＝ ステークホルダー調整が先（決裁ライン確保を優先）
• 契約（条項）が使えない → 交渉カードがない ＝ 待ちが発生しやすい（中間の合意・チェックポイントを先に作る）
• 「了解」の範囲が不明 → 合意範囲が分解されていない ＝ 追加要件の混入リスク（合意範囲を棚卸しして再合意が必要）
• 口頭合意の裏付けがない → 証跡がない ＝ 言った言わないリスク（ログの確保 or 議事録運用を必須化）
• 暗黙の前提が多い → 前提が言語化されていない ＝ 再燃リスク（前提を列挙して合意取り直し）
• 資料そのものが存在しない → そもそも基準線が存在しない ＝ スコープ紛争リスク（最小の合意ドキュメントを今から作る）

DOWNLOAD CONTENT

基本設計で仕込む「回せる運用」——誰がやっても再現できる型を【Claude 専用スキル】で無料配布！

※本スキルはClaude専用の「AIエージェント構築セット」です。他AIでは設計通りの動作にならない場合があります。
※生成AIの特性上、回答の正確性は保証されません。本ツールの利用により生じた不具合・損害・法的トラブル等について、当社は一切の責任を負いかねます。