scenario-war-room について
Scenario War Room は、複数の事業領域にまたがる複合リスクをモデル化し、ある事象から次の影響が生じる過程を追跡します。危機対応を計画するチーム向けに、深刻度別のシナリオ、警告トリガー、ヘッジ策を提示します。
主な機能
- 01最大3つのシナリオ変数を設定
- 02事業領域ごとの影響を整理
- 03連鎖的な影響を追跡
- 043段階の深刻度を評価
- 05警告トリガーとヘッジ策を定義
活用シーン
- 01顧客喪失と資金調達遅延への備え
- 02人員変動が納期に与える影響の評価
- 03市場変化や競合の動きへの対応準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ alirezarezvani/ claude-skills --skill scenario-war-roomインストール後、Claude Code で/scenario-war-roomを入力して読み込まれたか確認します。
同梱ファイルreferences/scenario-planning.mdscripts/scenario_modeler.py
詳細
シナリオ・ウォールーム
すべての事業部門にわたる、連鎖的な「もしも」のシナリオをモデル化します。単一の前提に基づくストレステストではなく、ある問題が次の問題をどう引き起こすかを示す複合的な逆境シナリオです。
キーワード
シナリオプランニング、ウォールーム、What-if 分析、リスクモデリング、連鎖的影響、複合リスク、逆境への備え、緊急時対応計画、ストレステスト、危機対応計画、多変数シナリオ、プレモーテム
クイックスタート
python scripts/scenario_modeler.py # Interactive scenario builder with cascade modeling
または、自然言語でシナリオを説明します。
「主要顧客を失い、さらに Q3 の資金調達にも失敗したらどうなりますか?」 「エンジニアが 3 人辞め、さらに Q3 までにリリースする必要があったらどうなりますか?」 「市場が 30% 縮小し、さらに競合が 5,000 万ドルを調達したらどうなりますか?」
これは何ではないか
- 単一の前提に基づくストレステストではありません(それは
/em:stress-testです) - 財務モデリングだけではありません — すべての部門をモデル化します
- 最悪のケースだけではありません — 3 段階の深刻度をモデル化します
- 分析による麻痺を招くものではありません — 具体的なヘッジ策とトリガーを提示します
フレームワーク:6 ステップの連鎖モデル
ステップ 1:シナリオ変数を定義する(最大 3 つ)
各変数について、以下を記載します。
- 何が変わるか — 具体的に記載し、可能であれば数値化します
- 発生確率 — 最善の推定値
- タイムライン — いつ発生するか
Variable A: Top customer (28% ARR) gives 60-day termination notice
Probability: 15% | Timeline: Within 90 days
Variable B: Series A fundraise delayed 6 months beyond target close
Probability: 25% | Timeline: Q3
Variable C: Lead engineer resigns
Probability: 20% | Timeline: Unknown
ステップ 2:各領域への影響をマッピングする
各変数について、関連する各役割の担当者が影響をモデル化します。
| 領域 | 担当者 | モデル化する内容 |
|---|---|---|
| 資金とランウェイ | CFO | バーンレートへの影響、ランウェイの変化、つなぎ融資の選択肢 |
| 売上 | CRO | ARR の不足額、解約の連鎖リスク、パイプライン |
| プロダクト | CPO | ロードマップへの影響、PMF リスク |
| エンジニアリング | CTO | 開発速度への影響、キーパーソンリスク |
| 人材 | CHRO | 離職の連鎖、採用凍結の影響 |
| オペレーション | COO | 対応能力、OKR への影響、プロセスリスク |
| セキュリティ | CISO | コンプライアンスのタイムラインリスク |
| 市場 | CMO | CAC への影響、競争上の露出 |
ステップ 3:連鎖的影響をマッピングする
ここが中核です。変数 A がどのように各領域で結果を引き起こし、それがさらに変数 B の影響を引き起こすのかを示します。
TRIGGER: Customer churn ($560K ARR)
↓
CFO: Runway drops 14 → 8 months
↓
CHRO: Hiring freeze; retention risk increases (morale hit)
↓
CTO: 3 open engineering reqs frozen; roadmap slips
↓
CPO: Q4 feature launch delayed → customer retention risk
↓
CRO: NRR drops; existing accounts see reduced velocity → more churn risk
↓
CFO: [Secondary cascade — potential death spiral if not interrupted]
連鎖の内容を明示します。どこで連鎖を断ち切れるかも示します。
ステップ 4:深刻度マトリクス
3 つのシナリオをモデル化します。
| シナリオ | 定義 | 回復 |
|---|---|---|
| 基本 | 1 つの変数が発生し、ほかは発生しない | 計画に基づいて対応可能 |
| ストレス | 2 つの変数が同時に発生する | 大規模な対応が必要 |
| 深刻 | すべての変数が発生し、連鎖が全面的に進行する | 存続を脅かす状況であり、取締役会の介入が必要 |
深刻度ごとに、以下を確認します。
- ランウェイへの影響
- ARR への影響
- 従業員数への影響
- 許容できない状態に至るまでの期間(トリガーポイント)
ステップ 5:トリガーポイント(早期警戒シグナル)
シナリオの進行が確定する前にそれを知らせる、測定可能なシグナルを定義します。
Trigger for Customer Churn Risk:
- Sponsor goes dark for >3 weeks
- Usage drops >25% MoM
- No Q1 QBR confirmed by Dec 1
Trigger for Fundraise Delay:
- <3 term sheets after 60 days of process
- Lead investor requests >30-day extension on DD
- Competitor raises at lower valuation (market signal)
Trigger for Engineering Attrition:
- Glassdoor activity from engineering team
- 2+ referral interview requests from engineers
- Above-market offer counter-required in last 3 months
ステップ 6:ヘッジ戦略
各シナリオについて、発生した場合の影響を軽減するために、シナリオが現実化する前に今すぐ実行できるアクションを定めます。
| ヘッジ策 | コスト | 影響 | 担当者 | 期限 |
|---|---|---|---|---|
| 50 万ドルの融資枠を確保する | 年間 5,000 ドル | 解約が発生した場合、3 か月分を確保 | CFO | 60 日 |
| 主要エンジニア 3 人に 12 か月のリテンションボーナスを支給する | 9 万ドル | 資金調達までチームを維持 | CHRO | 30 日 |
| 顧客ごとの売上構成比を 20% 未満に分散する | 営業活動 | 単一顧客への依存リスクを軽減 | CRO | 2 四半期 |
| 資金調達のタイムラインを短縮し、並行プロセスを開始する | CEO の時間 | ランウェイが尽きる前に資金調達を完了 | CEO | 直ちに |
出力形式
すべてのウォールームセッションで、以下を作成します。
SCENARIO: [Name]
Variables: [A, B, C]
Most likely path: [which combination actually plays out, with probability]
SEVERITY LEVELS
Base (A only): [runway/ARR impact] — recovery: [X actions]
Stress (A+B): [runway/ARR impact] — recovery: [X actions]
Severe (A+B+C): [runway/ARR impact] — existential risk: [yes/no]
CASCADE MAP
[A → domain impact → B trigger → domain impact → end state]
EARLY WARNING SIGNALS
- [Signal 1 → which scenario it indicates]
- [Signal 2 → which scenario it indicates]
- [Signal 3 → which scenario it indicates]
HEDGES (take these actions now)
1. [Action] — cost: $X — impact: [what it buys] — owner: [role] — deadline: [date]
2. [Action] — cost: $X — impact: [what it buys] — owner: [role] — deadline: [date]
3. [Action] — cost: $X — impact: [what it buys] — owner: [role] — deadline: [date]
RECOMMENDED DECISION
[One paragraph. What to do, in what order, and why.]
効果的なウォールームセッションのルール
シナリオあたり変数は最大3つです。 3つを超えるとノイズになります。5変数の崩壊シナリオに有意義な備えをすることはできません。本当に懸念している3つをモデル化してください。
定量化するか、推定してください。 「収益が減少する」では役に立ちません。「60日間でARR 42万ドルがリスクにさらされる」なら役に立ちます。不確かな場合は範囲で示してください。
一次的な影響で止めないでください。 損害は、最初の打撃ではなく、連鎖の中で常に拡大します。
影響だけでなく、回復もモデル化してください。 すべてのシナリオに「実行すること」の道筋を用意してください。
基本ケースと感度分析を分けてください。 「おそらく起こること」と「起こりうること」を混同しないでください。
モデル化しすぎないでください。 計画サイクルあたり3〜4つのシナリオが適切な数です。それ以上になると分析麻痺を招きます。
ステージ別の一般的なシナリオ
シード:
- 共同創業者が離脱し、製品のローンチに間に合わない
- 資金が尽き、つなぎ融資の条件も不利
シリーズA:
- ARR目標を達成できず、資金調達も遅れる
- 主要顧客が離脱し、競合他社が資金調達を実施
シリーズB:
- 市場が縮小し、バーン・マルチプルが急上昇
- リード投資家が方向転換を求め、チームが反発
経営幹部の役割との連携
| シナリオの種類 | 主な役割 | 影響の波及先 |
|---|---|---|
| 収益未達 | CRO、CFO | CMO(パイプライン)、COO(削減)、CHRO(人員削減) |
| 重要人物の離脱 | CHRO、COO | CTO(エンジニアリングの場合)、CRO(営業の場合) |
| 資金調達の失敗 | CFO、CEO | COO(資金繰り期間の延長)、CHRO(採用凍結) |
| セキュリティ侵害 | CISO、CTO | CEO(コミュニケーション)、CFO(コスト)、CRO(顧客への影響) |
| 市場の変化 | CEO、CPO | CMO(ポジショニングの見直し)、CRO(新しいセグメント) |
| 競合他社の動き | CMO、CRO | CPO(ロードマップでの対応)、CEO(戦略) |
参考資料
references/scenario-planning.md— シェル・メソドロジー、プレモーテム、モンテカルロ法、連鎖フレームワークscripts/scenario_modeler.py— 構造化されたシナリオモデリング用のCLIツール