scenario-war-room について
scenario-war-room は、経営チーム向けのシナリオ計画スキルです。複合リスクと部門横断の連鎖的影響をモデル化し、コスト、担当者、期限を含む対策をまとめます。
主な機能
- 01最大 3 つのシナリオ変数のモデル化
- 02部門横断の影響と連鎖のマッピング
- 03基本・ストレス・深刻シナリオの作成
- 04早期警告シグナルとしきい値の設定
- 05コスト・担当者・期限を含む対策の策定
活用シーン
- 01複数の脅威が同時発生するリスクの評価
- 02資金調達、買収、市場参入前のプレモーテム
- 03経営チームによる四半期リスクレビュー
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ borghei/ claude-skills --skill scenario-war-roomインストール後、Claude Code で/scenario-war-roomを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
scripts/decision_tree_analyzer.pyimpact_matrix_calculator.pyscenario_builder.py詳細
シナリオ・ウォールーム
ティア: 強力 カテゴリー: Cレベル・アドバイザリー タグ: シナリオプランニング、ウォールーム、リスクモデリング、連鎖的影響、コンティンジェンシープランニング、プレモーテム、危機シミュレーション
概要
シナリオ・ウォールームは、すべての事業機能にわたる連鎖的な仮定シナリオをモデル化します。単一の前提条件によるストレステストではなく、複合的な逆境がどのように次の問題を引き起こすのか、また、その連鎖をどこで断ち切れるのかを明らかにします。各シナリオでは、コスト、担当者、期限を含む具体的なヘッジ策を提示します。
使用する場面
- 重大なリスクの発生確率が15%を超え、ARRへの影響が20%を超える場合
- 2つ以上の脅威が同時に発生する可能性がある場合
- 戦略的な意思決定を誤った場合の下振れリスクが大きい場合
- 取締役会や投資家から「最悪のケースは何か」と尋ねられている場合
- 大きな決断(資金調達、買収、市場参入)の前にプレモーテムを行う場合
- 経営陣向けに四半期ごとのリスクレビューを行う場合
使用しない場面
- 単一変数の財務感度分析(CFO Advisorのストレステストを使用)
- 通常のプロジェクトリスク評価(プロジェクト管理のリスクフレームワークを使用)
- 技術的な故障モード分析(エンジニアリングのインシデント計画を使用)
まず確認すること
生成する前に、次の入力内容を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。
- 経営陣が実際に最も懸念している変数(最大3つ) — モデル全体はこれらを中心に構築されます。変数を誤ると、シナリオは役に立ちません
- 各変数の発生確率、タイムライン、定量化した影響 — 「収益が落ちる」では具体的な対応ができません。「60日間でARRの42万ドルがリスクにさらされる」なら対応可能で、深刻度の段階もこれに左右されます
- 現在のベースライン(ARR、月単位のランウェイ、従業員数) — 連鎖と深刻度の計算(例:ランウェイが14か月から8か月に短縮)には、開始時点の数値が必要です
- 会社のステージ — よくあるシナリオのパターンや存続を脅かす事態の基準は、ステージによって異なります
中断ルール:出力に最も大きく影響する2~3項目だけを質問してください。ユーザーが「とにかく下書きを作って」と言った場合は、そのまま進め、アーティファクトの冒頭に前提条件を列挙してください。
6段階の連鎖モデル
ステップ1:シナリオ変数を定義する(最大3つ)
変数が3つを超えると、洞察ではなく分析麻痺を招きます。経営陣が実際に夜も眠れなくなるほど懸念している3つを選んでください。
各変数について、次の項目を指定します。
| 項目 | 説明 | 例 |
|---|---|---|
| 何が変化するか | 具体的かつ定量化する | 「ARRの28%を占める最大顧客から、60日前の解約通知が届く」 |
| 発生確率 | 最善の推定値 | 15% |
| タイムライン | いつ発生する可能性があるか | 90日以内 |
| 検知シグナル | 発生しているとどうすれば分かるか | スポンサーとの連絡が途絶え、利用が前月比で25%減少 |
変数テンプレート:
Variable A: [Specific change]
Probability: [X]% | Timeline: [When]
Detection: [Early warning signal]
First-order impact: [Immediate consequence]
Variable B: [Specific change]
Probability: [X]% | Timeline: [When]
Detection: [Early warning signal]
First-order impact: [Immediate consequence]
Variable C: [Specific change]
Probability: [X]% | Timeline: [When]
Detection: [Early warning signal]
First-order impact: [Immediate consequence]
ステップ2:領域ごとの影響をマッピングする
各変数について、すべての事業機能にわたる影響を評価します。
| 領域 | 主な質問 | 典型的な影響領域 |
|---|---|---|
| 財務(CFO) | バーンへの影響は?ランウェイはどう変化するか?ブリッジの選択肢は? | 現金、ランウェイ、コベナンツの発動条件 |
| 収益(CRO) | ARRの不足額は?解約の連鎖は?パイプラインへの影響は? | NRR、拡大、新規顧客獲得のリスク |
| 製品(CPO) | ロードマップが狂うか?PMFが危険にさらされるか?顧客ニーズが変化するか? | デリバリーのタイムライン、機能の優先順位 |
| エンジニアリング(CTO) | 開発速度への影響は?キーパーソンのリスクは?技術的負債への影響は? | キャパシティ、アーキテクチャ、採用 |
| 人事(CHRO) | 離職の連鎖は?採用凍結は?士気への影響は? | 定着率、企業文化、組織の人材層 |
| オペレーション(COO) | キャパシティへの影響は?プロセスが破綻するか?OKRへの影響は? | SLA、効率性、スケーリング |
| 市場(CMO) | CACへの影響は?競争上の脆弱性は?ブランドリスクは? | パイプライン創出、ポジショニング |
| 法務/コンプライアンス | 規制対応のタイムラインにリスクはあるか?契約上の責任に影響はあるか? | 義務、期限、ペナルティ |
ステップ 3:カスケードのマッピング(核心)
これが最も重要なステップです。変数 A がどのように変数 B を増幅する結果を引き起こすかをマッピングします。
カスケード図:
TRIGGER: Customer churn ($560K ARR)
│
├──▶ CFO: Runway drops 14 → 8 months
│ │
│ └──▶ CHRO: Hiring freeze imposed
│ │
│ └──▶ CTO: 3 open engineering reqs frozen, roadmap slips 2 months
│ │
│ └──▶ CPO: Q4 feature launch delayed → 2 more customers at risk
│ │
│ └──▶ CRO: NRR drops → additional churn risk (DEATH SPIRAL ENTRY)
│
└──▶ CRO: Revenue concentration increases (next largest = 22%)
│
└──▶ Investors: Concentration risk flagged → Series A terms worsen
カスケードには明確な名前を付けます。 よくあるカスケードパターン:
| カスケードパターン | 説明 | 介入ポイント |
|---|---|---|
| 収益から資金余力へのデススパイラル | 顧客離れ → 資金余力の低下 → 採用凍結 → 製品開発の鈍化 → さらなる顧客離れ | 緊急の収益源多様化 |
| キーパーソンのカスケード | スター社員の退職 → チームの士気低下 → 周囲の社員も退職 → 生産性の崩壊 | 退職前の引き留めボーナス |
| 市場の圧迫 | 競合他社が値上げ → 価格競争 → 利益率の圧縮 → 製品に投資できない | 価格追随ではなく差別化 |
| 信頼のカスケード | インシデント → 顧客の懸念 → 顧客離れ → 報道 → さらなる顧客離れ | 迅速で透明性のあるコミュニケーション |
| 資金調達とバーンのスパイラル | 目標未達 → 資金調達の遅延 → 不利な条件でのつなぎ融資 → バーン削減 → チームの離脱 | 複数の資金調達を並行して進める |
ステップ 4:深刻度マトリックス
深刻度が高まる 3 つのシナリオをモデル化します。
| シナリオ | 該当する変数 | 定義 | 回復の難易度 |
|---|---|---|---|
| 基本 | 3 つのうち 1 つ | 単一のショックが発生し、他の事象は起こらない | 準備済みの対応で管理可能 |
| ストレス | 3 つのうち 2 つ | 複合的なショックが発生し、カスケードが始まる | 大幅な方針転換と取締役会の関与が必要 |
| 深刻 | 3 つすべて | カスケードが全面化し、存続が脅かされる状況 | 緊急措置が必要で、取締役会の介入が必要になる可能性がある |
深刻度の各段階について、以下を数値化します。
BASE SCENARIO (Variable A only):
Runway impact: [X] months → [Y] months
ARR impact: -$[X] ([Y]% of total)
Headcount impact: [freeze / reduction / none]
Timeline to critical: [X] months
Recovery plan: [specific actions]
STRESS SCENARIO (Variables A + B):
Runway impact: [X] months → [Y] months
ARR impact: -$[X] ([Y]% of total)
Headcount impact: [specifics]
Timeline to critical: [X] months
Recovery plan: [specific actions]
SEVERE SCENARIO (All three):
Runway impact: [X] months → [Y] months
ARR impact: -$[X] ([Y]% of total)
Headcount impact: [specifics]
Timeline to critical: [X] months
Existential: [yes/no]
Emergency plan: [specific actions requiring board approval]
ステップ 5:早期警戒シグナル(トリガーポイント)
シナリオが確定する前に進行中であることを示す、測定可能なシグナルを定義します。この演習の価値は、遅れて対応するのではなく、早期に行動することにあります。
シグナル設計の基準:
- 観測可能(実際に測定できる)
- 先行性がある(影響全体が現れる前に現れる)
- 具体的(単に「何かがおかしいと感じる」ではない)
- 実行可能(具体的な対応を引き起こす)
| 変数 | シグナル | しきい値 | 対応 |
|---|---|---|---|
| 顧客離れ | スポンサーから返信がなくなる | 3 週間以上音沙汰なし | 経営幹部へのエスカレーション、QBR の依頼 |
| 顧客離れ | 利用量が減少する | 前月比で 25%超の減少 | CS から連絡し、価値を見直す |
| 資金調達の遅延 | タームシート | プロセス開始から 60 日後に 3 件未満 | つなぎ融資の協議を並行して進める |
| 資金調達の遅延 | 投資家からの要請 | デューデリジェンス期間の延長が 30 日超 | バーンを削減し、資金余力を延ばす |
| キーパーソンの退職 | 市場水準の報酬 | 過去 90 日以内に対抗オファーが必要になった | 引き留めパッケージ、後継者計画 |
| キーパーソンの退職 | 社外での活動 | エンジニアが競合他社のカンファレンスで登壇している | 直接話し合い、役割の拡大 |
ステップ 6:ヘッジ戦略
各シナリオについて、シナリオが現実になる前に、今すぐ実行して影響を軽減できる行動を検討します。ヘッジにはコストがかかります。目指すのは安価な保険であり、過度な心配ではありません。
ヘッジの評価基準:
| 基準 | 質問 |
|---|---|
| コスト | このヘッジの実施にはどのようなコストがかかりますか? |
| 可逆性 | シナリオが起きなかった場合、元に戻せますか? |
| 所要期間 | 実施にどのくらいかかりますか?(検知から影響発生までの期間より短い必要があります) |
| 対応範囲 | このヘッジはどのシナリオに対する備えになりますか? |
| 副作用 | このヘッジによって別の問題が起きますか? |
ヘッジ表のテンプレート:
| ヘッジ | コスト | 対応するリスク | 担当者 | 期限 | ステータス |
|---|---|---|---|---|---|
| $500K の融資枠を確保する | $5K/年 | 運転資金の不足(基本+ストレス) | CFO | 60 日 | 未着手 |
| 主要エンジニア 3 名に 12 か月の定着ボーナスを支給する | $90K | キーパーソンの離職(すべてのシナリオ) | CHRO | 30 日 | 進行中 |
| 顧客ごとの売上構成比を 20% 未満に分散する | 営業活動(6 か月) | 特定顧客への依存 | CRO | 2 四半期 | 計画中 |
| 資金調達の並行トラックを開始する | CEO の時間(週 10 時間) | 資金調達の遅延(ストレス+深刻) | CEO | 直ちに | 未着手 |
| 既存投資家とブリッジ条件を事前に交渉する | 取締役会での協議 2 回 | 運転資金の危機(深刻) | CFO + CEO | 45 日 | 未着手 |
| バス係数の低減に向けてアーキテクチャを文書化する | エンジニアリング 2 週間 | キーパーソンの離職 | CTO | 30 日 | 未着手 |
出力形式
すべてのウォールームセッションで、次の構造化された出力を作成します。
SCENARIO: [Name]
DATE: [Date of analysis]
PARTICIPANTS: [Who was involved]
VARIABLES:
A: [Description] — Probability: [X]%, Timeline: [When]
B: [Description] — Probability: [X]%, Timeline: [When]
C: [Description] — Probability: [X]%, Timeline: [When]
MOST LIKELY PATH: [Which combination actually plays out, with reasoning]
SEVERITY LEVELS:
Base (A only): Runway [X]→[Y]mo, ARR impact -$[X]
Recovery: [2-3 specific actions]
Stress (A+B): Runway [X]→[Y]mo, ARR impact -$[X]
Recovery: [3-4 specific actions]
Severe (A+B+C): Runway [X]→[Y]mo, ARR impact -$[X]
Existential: [yes/no]
Emergency: [actions requiring board approval]
CASCADE MAP:
[A] → [domain impact] → [triggers B amplification] → [domain impact] → [end state]
Interruption points: [where cascade can be broken]
EARLY WARNING SIGNALS:
1. [Signal] → indicates [scenario], threshold: [specific]
2. [Signal] → indicates [scenario], threshold: [specific]
3. [Signal] → indicates [scenario], threshold: [specific]
HEDGES (implement now):
1. [Action] — cost: $[X] — protects: [scenarios] — owner: [role] — deadline: [date]
2. [Action] — cost: $[X] — protects: [scenarios] — owner: [role] — deadline: [date]
3. [Action] — cost: $[X] — protects: [scenarios] — owner: [role] — deadline: [date]
RECOMMENDED DECISION:
[One paragraph: what to do, in what order, and why]
REVIEW DATE: [When to re-run this analysis — typically 90 days or after any variable shifts]
企業ステージ別の一般的なシナリオ
シードステージ
- 共同創業者が離職し、製品のローンチが予定日に間に合わない
- 運転資金が底をつき、ブリッジの条件が法外なものになる
- 主要な技術職の採用が不成立となり、競合が先に製品を出す
シリーズ A
- ARR 目標を達成できず、資金調達が遅れる
- 最大顧客が解約し、競合が大型ラウンドで資金調達する
- 主要エンジニアが退職し、重要機能の期限に間に合わない
シリーズ B 以降
- 市場が縮小し、バーン・マルチプルが 3 倍を超えて急上昇する
- リード投資家が戦略転換を求め、チームが反対する
- 規制が変更され、製品のアーキテクチャ再構築が必要になる
ウォールームの基本ルール
- **シナリオあたりの変数は最大 3 つです。**それ以上はノイズになります。本当に重要な変数をモデル化してください。
- 定量化または推定してください。「売上が減る」では有用ではありません。「60 日間で $420K の ARR がリスクにさらされる」なら有用です。不確実な場合は範囲を使ってください。
- **一次的な影響だけで終わらせないでください。**本当の損害は、必ず連鎖的な影響の中にあります。
- **影響だけでなく、回復もモデル化してください。**すべてのシナリオに「何をするか」という道筋が必要です。
- 基本ケースと感度分析を分けてください。「おそらく起きること」と「起こり得ること」を混同しないでください。
- **計画サイクルごとに 3~4 個のシナリオを扱ってください。**それ以上では分析麻痺を招きます。
- **90 日ごとに見直してください。**確率や変数は変化します。古いシナリオは誤った安心感につながります。
- **遠慮なく話せる場にしてください。**人々が深刻なシナリオを安心して挙げられる必要があります。
関連スキル
| スキル | 利用する場面 |
|---|---|
| ceo-advisor | シナリオが判断材料となる戦略的な意思決定 |
| cfo-advisor | シナリオの影響に関する財務モデリング |
| coo-advisor | オペレーションの緊急時対応計画 |
| internal-narrative | シナリオの結果をステークホルダーに伝える |
| cs-onboard | シナリオの変数につながる企業のコンテキスト |
トラブルシューティング
| 問題 | 考えられる原因 | 解決策 |
|---|---|---|
| シナリオが抽象的すぎて、具体的な行動につながらない | 変数が十分に具体的でなく、数値化されていない | すべての変数について、金額、割合、期間を明示してください。「収益が減少する」では行動につながりませんが、「60日間で420KドルのARRがリスクにさらされる」なら具体的です |
| チームが明白で発生確率の低いシナリオしか作成しない | 同調バイアスがあり、メンタルモデルに疑問を投げかけるShellのシナリオプランニング手法を適用していない | 反転の手法を使い、「失敗を確実にするには何が必要か」と問いかけてください。外部の視点を取り入れ、業界固有の過去の事例を参照してください |
| カスケードマッピングが一次的な影響で止まる | ファシリテーターが直接的な結果の先まで掘り下げていない | 各変数について最低3段階のカスケードを求めてください。各領域への影響について、「その次に何が起こるか」と問いかけてください |
| ヘッジ策が特定されても、実施されない | 担当者、期限、費用が定められていない | すべてのヘッジ策に、費用の見積もり、担当者名、期限、進捗状況の追跡を設定してください。毎週のリーダーシップ会議で確認してください |
| ウォールームのセッションに時間がかかりすぎる(4時間超) | 変数が多すぎる、またはすべてのシナリオをモデル化しようとしている | 1回のセッションで扱う変数は最大3つ、シナリオは3~4つに制限してください。重大度マトリックスを使い、影響が最も大きい組み合わせに集中してください |
| 早期警戒シグナルが監視されていない | シグナルは割り当てられているが、既存のレポートに組み込まれていない | 既存のダッシュボードと週次スコアカードにシグナルを追加してください。各シグナルの監視担当者を明確に割り当ててください |
| 参加者が最悪のシナリオを挙げることをためらう | 否定的、または過度に警戒していると思われることへの懸念 | 基本ルールを明確に定めてください。Shellの経験を引き合いに出し、「価値は、ほかの人が口にしないことを表面化させることにある」と伝えてください。厳しい現実を挙げた人を評価してください |
成功基準
- 各シナリオセッションで、変数3つ、重大度レベル3段階、中断ポイントを特定したカスケードマップを必ず作成する
- 早期警戒シグナルは、監視できるだけの具体性を備えている。つまり、観察可能で、先行指標となり、しきい値が定義されていて行動につながる
- ヘッジ策の費用、担当者、期限を定め、ウォールームのセッションから7日以内に設定する
- 各シナリオについて、少なくとも1つのヘッジ策を30日以内に実施する(計画だけで終わらせない)
- 新しい情報に基づいて発生確率を更新し、90日ごとにシナリオを見直す
- 早期警戒シグナルが発動した場合、事前に計画した対応を定められた期間内に実行する
- ウォールームの成果物を、取締役会で確認できる簡潔さにまとめる。シナリオごとに1ページの要約を作成する
対象範囲と制限事項
- 対象範囲: 複数の変数を用いたシナリオ構築、すべての事業機能にまたがるカスケードモデリング、重大度マトリックス分析、早期警戒シグナルの設計、費用対効果分析を伴うヘッジ戦略、シナリオの見直しサイクル
- 対象範囲外: 単一変数の財務感度分析(CFO Advisorのストレステストを使用)、技術的な故障モード分析(エンジニアリングのインシデント計画を使用)、日常的なプロジェクトリスク評価(プロジェクト管理のフレームワークを使用)、保険とリスク移転(専門ブローカーを利用)
- 制限事項: シナリオの発生確率は主観的な推定であり、保険数理上の計算ではありません。価値は予測精度ではなく、備えにあります
- 制限事項: このフレームワークでは、シナリオが独立している、または相関していると仮定します。ブラックスワン事象は定義上、モデル化できません
- 制限事項: カスケードマッピングは一般的な組織パターンに基づいています。独自の企業構造では、異なるカスケード経路になる場合があります
- 制限事項: シナリオあたりの変数を最大3つとするのは、意図的な制約です。変数を増やしても洞察が深まるのではなく、分析麻痺を招きます
統合ポイント
| スキル | 統合 | データフロー |
|---|---|---|
ceo-advisor | シナリオ分析に基づく戦略的意思決定 | ウォールームのシナリオ → CEO の意思決定への入力 |
cfo-advisor | シナリオの影響とヘッジコストの財務モデリング | ウォールームの財務的影響 → CFO のストレステストモデル |
coo-advisor | オペレーションの緊急時対応計画と連鎖の中断 | ウォールームの連鎖マップ → COO の緊急時対応計画 |
executive-mentor | 事前検証で特定した失敗要因をシナリオ変数に反映 | メンターが特定した失敗要因 → ウォールームの変数 |
internal-narrative | 危機シナリオには事前に作成したコミュニケーション計画が必要 | ウォールームの危機シナリオ → ナラティブの危機対応テンプレート |
org-health-diagnostic | 健全性の各指標のスコアからシナリオ変数を抽出 | 健全性に関する危険信号 → ウォールームの変数候補 |
strategic-alignment | シナリオの結果によっては戦略の再調整が必要 | ウォールームの結果 → アラインメントの再評価 |
Python ツール
| ツール | 目的 | 使用方法 |
|---|---|---|
scripts/scenario_builder.py | 変数、確率、検知シグナル、深刻度レベルを含む構造化シナリオを作成します | python scripts/scenario_builder.py --name "Customer Concentration Risk" --variable "Top customer churns" --probability 20 --impact 500000 --timeline 90 --json |
scripts/impact_matrix_calculator.py | 深刻度マトリックスと連鎖リスクのスコアリングを用いて、複数の変数にまたがる複合的な影響を計算します | python scripts/impact_matrix_calculator.py --variables "churn:500000:0.2" "fundraise_delay:0:0.3" "key_departure:0:0.15" --arr 2000000 --runway-months 14 --json |
scripts/decision_tree_analyzer.py | 戦略的選択肢の期待値を計算し、意思決定ツリーを構築して評価します | python scripts/decision_tree_analyzer.py --decision "Enter Japan market" --option "Direct:0.6:2000000:-500000" --option "Partnership:0.75:1000000:-200000" --option "Wait:1.0:0:0" --json |