mcpField
S
scenario-war-room

scenario-war-room

github.com/borgheiその他1.0k92 回インストール1 週間前に更新
リポジトリ

scenario-war-room について

scenario-war-room は、経営チーム向けのシナリオ計画スキルです。複合リスクと部門横断の連鎖的影響をモデル化し、コスト、担当者、期限を含む対策をまとめます。

主な機能

  1. 01最大 3 つのシナリオ変数のモデル化
  2. 02部門横断の影響と連鎖のマッピング
  3. 03基本・ストレス・深刻シナリオの作成
  4. 04早期警告シグナルとしきい値の設定
  5. 05コスト・担当者・期限を含む対策の策定

活用シーン

  1. 01複数の脅威が同時発生するリスクの評価
  2. 02資金調達、買収、市場参入前のプレモーテム
  3. 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.py
impact_matrix_calculator.py
scenario_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/年運転資金の不足(基本+ストレス)CFO60 日未着手
主要エンジニア 3 名に 12 か月の定着ボーナスを支給する$90Kキーパーソンの離職(すべてのシナリオ)CHRO30 日進行中
顧客ごとの売上構成比を 20% 未満に分散する営業活動(6 か月)特定顧客への依存CRO2 四半期計画中
資金調達の並行トラックを開始するCEO の時間(週 10 時間)資金調達の遅延(ストレス+深刻)CEO直ちに未着手
既存投資家とブリッジ条件を事前に交渉する取締役会での協議 2 回運転資金の危機(深刻)CFO + CEO45 日未着手
バス係数の低減に向けてアーキテクチャを文書化するエンジニアリング 2 週間キーパーソンの離職CTO30 日未着手

出力形式

すべてのウォールームセッションで、次の構造化された出力を作成します。

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 倍を超えて急上昇する
  • リード投資家が戦略転換を求め、チームが反対する
  • 規制が変更され、製品のアーキテクチャ再構築が必要になる

ウォールームの基本ルール

  1. **シナリオあたりの変数は最大 3 つです。**それ以上はノイズになります。本当に重要な変数をモデル化してください。
  2. 定量化または推定してください。「売上が減る」では有用ではありません。「60 日間で $420K の ARR がリスクにさらされる」なら有用です。不確実な場合は範囲を使ってください。
  3. **一次的な影響だけで終わらせないでください。**本当の損害は、必ず連鎖的な影響の中にあります。
  4. **影響だけでなく、回復もモデル化してください。**すべてのシナリオに「何をするか」という道筋が必要です。
  5. 基本ケースと感度分析を分けてください。「おそらく起きること」と「起こり得ること」を混同しないでください。
  6. **計画サイクルごとに 3~4 個のシナリオを扱ってください。**それ以上では分析麻痺を招きます。
  7. **90 日ごとに見直してください。**確率や変数は変化します。古いシナリオは誤った安心感につながります。
  8. **遠慮なく話せる場にしてください。**人々が深刻なシナリオを安心して挙げられる必要があります。

関連スキル

スキル利用する場面
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

コメント