CAPDで回す炎上プロジェクト：「頑張ります」の代わりに「消火の型」を【Excelテンプレート＋Claudeスキルダウンロード】

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

「要件が固まらないまま開発が始まった」「キーパーソンが不在でGOが出ない」「納期の直前に仕様が変わった」「情報が共有されていない」「作業者が問題を隠していた」。
プロジェクトでは日々さまざまな問題が起きます。では、どの時点から「炎上」と呼ぶのでしょうか。

「このままではローンチ予定日に間に合わない」と、あなたや現場が気づいた瞬間。
本記事では、この瞬間を炎上の始まりと考えます。

本記事では、期限のあるプロジェクトが炎上したときの立て直し手順「CAPD（Check→Act→Plan→Do）」を紹介します。
扱うのは平常時の運用改善ではありません。
納期が迫るなかで炎上を鎮め、着地点を見つけるための「消火の型」を、精神論抜きでまとめました。

発火源別の対処法から読む場合は「3-4. Step 4. D（Do）」へ

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

CAPDを回すと、「頑張ります」の一言に代わる材料が2つそろいます。
どちらも、上位者や顧客への説明・交渉・再合意にそのまま使えます。

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

この2つを出力するClaude専用スキルと、書き込みながらCAPDを進められるExcelの実践ガイドを、記事末尾のDOWNLOAD CONTENTで配布中です。

1. 「炎上」を分解する

プロジェクトの炎上は、突然起きるものではなく、いくつかの要因が積み重なった結果です。
「なぜ炎上したのか」を分解すると、原因となる発火源は次の4つに集約できます。発火源①：認識・調整不足（言った言わない、仕様のコロコロ変更）

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

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

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

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

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

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

外部依存の遅延や前提条件の変化など、自分たちでは制御できないもの。

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

だからこそ、型に沿って動くことが必要です。

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

炎上に気づいた直後にやるべきことは、新しい策を考えることではありません。意思決定に必要な情報を、最短で集めることです。
資料探しに半日かけるより、10分話せる人を1人見つけたほうが早く進みます。
まずは資料そのものより、情報を持っている人と、情報の置き場所を押さえてください。

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

最低限そろえるINPUTは3つだけです。
この3つがあれば、「間に合うか」「何を切るか」「誰に何を伝えるか」を整理して、CAPDを回し始められます。

1. 納期×成果物の定義 ゴールラインがわからないと、着地シナリオを描けない。
2. 課題管理表やWBS 「今どこにいるか」がわからないと、残りの工数を積み上げられない。
3. 決裁できる人 GOを出せる人がいないと、現場が動けない。

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

ここから先は、そろっていると心強い材料です。
資料が見つからない場合は、「存在しない」こと自体を事実として記録してください。資料がないという事実も、状況を判断する重要な情報になります。

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

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

資料が見つからないときは、そこから読み取れるリスクと次の一手に置き換えます。

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

3. PROCESS：CAPDとは？現場で回す消火の型

CAPDとは、炎上したプロジェクトをCheck（測る）→Act（止める）→Plan（決める）→Do（消す）の順に立て直す手順です。
PDCAが計画から始めるのに対し、CAPDは現状の把握と止血から始めます。
消火の第一歩は、火の規模をつかむことです。CAPDの順に考えると、集めたINPUTを実行できるアクションに分解できます。

D（Do）の後は、再びCheckです。
「鎮火したか、まだ燃えているか」を判定するまでを1サイクルとし、火が完全に収まるまでループを回します。

「それって、OODAじゃないの？」

PDCAと並べて語られることの多い手法に、OODA（ウーダ）ループがあります。
本記事で提唱するCAPDとOODAは、どちらもPDCAの「P（計画）から始める」という前提を覆している点で共通しています。

違いは使う場面です。CAPDは、炎上プロジェクトの収束を目指す全体のプロセスです。
OODAはCAPDのD（Do）フェーズで使います。状況が定まらないなかで、顧客と高速に壁打ちを重ねるための意思決定ツールという位置づけです。

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

Checkでは、最初の30分で現状を可視化し、4つのベースラインに照らして火の規模を測ります。
まず、次の3つの軸で状況を把握してください。

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

この3つの軸を、次の4つのベースラインに照らして測定します。
情報を完璧にそろえる必要はありません。30分で全体像をつかむことが目的です。

• スコープ 当初合意したスコープと現状の差分（例：要件追加10件中6件が未合意のまま開発に着手）
• スケジュール マイルストーンの遅延状況（例：結合テストの開始が2週間遅延し、クリティカルパス上にある）
• コスト 予算の消化率と残工数の見通し（例：予算の80％を消化したのに、残作業が40％ある）
• パフォーマンス測定ベースライン（PMB） 計画と実績の総合的な乖離（例：SPI 0.7／CPI 0.8で、計画比30％の遅延と20％の超過）

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

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

Actでは、計画を立てる前に第一報を出し、燃え広がりを止める応急処置を行います。第一報を出す

把握した被害状況は、すぐに共有してください。「もう少し調べてから」と待つ間に、ボヤは大火事に広がります。
不完全でかまいません。「今わかっていること」と「まだわかっていないこと」を分けて、上位者と顧客に第一報を出しましょう。最悪ケースのシミュレーション

「このまま何もしなかったら、3日後にどうなっているか」を具体的に想像します。
この想定がエスカレーションの根拠になり、P（Plan）の出発点にもなります。応急処置：これ以上燃やさない

• 影響が拡大しているタスクを一時凍結する 走り続けるより止めたほうが、被害が小さく済む場合もある。
• 暫定の意思決定ラインを確保する キーパーソンが不在なら代理の承認者をその場で決める
• 情報を一元化する 散らばった情報を課題管理表やSlackチャンネルなど1か所に集める

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

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

Planでは、Q（品質・スコープ）・C（コスト）・D（納期）のどこを譲り、どこを守り抜くかを決めます。
理想の計画を一から立て直す作業とは異なります。

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

これらを組み合わせて、次の3つの着地シナリオを30分で作ります。

1. ベストケース 最大限の努力で実現できる着地
2. リアルケース 現実的にいちばん確率が高い着地
3. ワーストケース 最低限これだけは守るライン

3つのシナリオができたら、すぐにエスカレーションしてください。
着地点は自分たちだけでは決められません。顧客も巻き込み、QCDの優先順位を一緒に決めていきます。
言いにくい報告は、先送りするほど損失が大きくなります。焼け野原にしない着地点を見つけることが、プロの仕事です。

よくある状況への対処は「4. よくある質問（FAQ）」へ

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

Doでは、着地シナリオに沿って、発火源のタイプごとに決まった手順で消火します。
有効な打ち手は発火源によって異なります。自分のプロジェクトがどのタイプに当てはまるかを確認し、該当する手順へ進んでください。

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

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

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

1. 「何が合っているか」を逆転確認する 全部がダメなわけではないので、ズレの範囲を特定する。
2. 議事録をすぐ共有する 「何を合意したか」を毎回確認して記録する
3. 仕様変更は1件ごとに評価する 影響・コスト・納期をすぐに評価し、積み重なった影響を数字で示す。
4. 期待値を再調整する 「何ができて何ができないか」を早めに示し、選択肢から選んでもらう。

着地例 追加要望10件のうち、優先度の低い6件をフェーズ2へ先送りした（スコープを譲歩）。残り4件の追加工数は変更管理表で見える形にし、追加費用として顧客と再合意した（コストを再交渉）。

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

計画の甘さが原因の場合、プロジェクト全体を一度に立て直そうとしても成功しません。
スコープを一点に絞り込み、相手と一緒に優先順位を決めていきます。

1. 交渉の3択を30分で作る ①追加請求、②スコープ削減、③自社負担（「貸し」として記録）の3つを用意する。
2. 3択を持ってすぐエスカレーションする 「問題の報告」ではなく「解決策の提案」として届ける。
3. 変更合意書の流れを守る ドラフト、承認、締結の順で進め、口約束では動かない。
4. スケジュールはスコープ調整で対応する 無理な短縮は品質の崩れを招くため、期間を圧縮せずに作業を減らす。
5. 「貸し」にするなら線引きを記録する 分割検収で入金を早め、次の案件の見積りに反映する旨を書面で合意する。

着地例 全20機能のうち影響の低い5機能をカットし、リリースを2フェーズに分けた（品質と納期を譲歩）。カット分の工数80時間は「貸し」として記録し、次の案件の見積りに反映することを書面で合意した（コストの線引き）。

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

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

1. 棚卸しセッションをすぐ開く 現担当と有識者で暗黙知を言葉にする。旧担当がいれば最優先で呼ぶ。
2. 蒸し返しを防ぐ 決定事項・未決事項・前提を1か所に集め、合意の履歴を残す。
3. ブラックボックスを洗い出す 影響の大きい箇所から、ペア体制とドキュメント化に着手する。

目指すのは完全な解消ではありません。「ドキュメントを見れば6割わかる」状態です。

着地例 キーマンの離脱を受けて、1週間の状況整理期間を確保した（納期を譲歩）。ブラックボックスになっていた機能は当面運用でカバーし、ドキュメント化を並行して進めた（品質を一部譲歩）。

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

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

1. 自チームの手を止めない モックやスタブで作業を進め、相手の成果物が届いたらすぐ結合できる状態を保つ。
2. 48時間ルールを決める 48時間返答がなければ、エスカレーション先に直接連絡する。
3. 契約書の発動できる条項を確認する 使えるなら中間チェックポイントを設計し、使えないなら中間の合意を先に作る。
4. 前提が崩れたらすぐマッピングして再合意を求める 影響が及ぶ部分と及ばない部分を切り分け、「防火帯」の考え方で対処する。

着地例 外部ベンダーのAPI提供が3週間遅れた。自チームはモックAPIで結合テストを先に進め、手戻りを最小限にした（品質を一部譲歩）。リリースは2週間後ろ倒しにし、遅延期間中の追加稼働コストを外部ベンダーとの責任分界として記録した（納期を譲歩し、コストを線引き）。

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

最後のCheckでは、4つのベースラインを測り直し、鎮火したかどうかを3段階で判定します。
Step 1で作った健康診断レポートと比べて、今の状況を確認してください。

• 正常 4つのベースラインすべてで乖離が許容範囲に収まった状態。通常のPDCAに戻り、再燃を防ぐ仕組みを定着させる。
• くすぶり 一部のベースラインに乖離が残っている状態。残ったリスクに絞って、A（Act）からもう一度ループを回す。
• 燃えてる 複数のベースラインで乖離が広がった、または新しい火種が出た状態。着地シナリオを作り直してエスカレーションし、CAPDを最初から回す。

最後のCで鎮火を確認できるまで、CAPDのループを回し続けます。
DOWNLOAD CONTENTのスキルは、判定を「正常／要注意／炎上中」の3段階で表示します。それぞれ上の「正常／くすぶり／燃えてる」と同じ意味です。

4. よくある質問（FAQ）

炎上の現場でよくある疑問にお答えします。

5. CAPDで回す炎上プロジェクトのまとめ

炎上プロジェクトの立て直しは、CAPDの順に進めます。最初の30分で火の規模を測り（Check）、第一報と応急処置で燃え広がりを止め（Act）、3つの着地シナリオで譲る範囲を決め（Plan）、発火源ごとに消火します（Do）。
消火の成否は、状況把握・現実的な計画・実行・相手と一緒に動く姿勢の掛け算で決まります。どれかひとつが欠けると、ほかがそろっていても火は消えません。

「間に合わない」と気づいたら、まず30分で火の規模を測り、第一報を出すところから始めてください。
DOWNLOAD CONTENTのスキルとExcelの実践ガイドを使えば、健康診断レポートと着地シナリオの材料を手早くそろえられます。

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