challenge

/em:challenge — 事前検死による計画分析

コマンド： /em:challenge <plan>

現実が明らかにする前に、あらゆる計画の弱点を体系的に見つけます。計画を潰すためではなく、現実に直面しても計画が持ちこたえられるようにするためです。

---

基本的な考え方

ほとんどの計画は、予測可能な理由で失敗します。運が悪かったのではなく、前提が悪かったのです。需要を過大評価した。複雑さを過小評価した。誰も疑問を呈さなかった依存関係があった。表計算では筋が通っていても、現実には通用しないタイミングだった。

事前検死の手法：今から12か月後、この計画が惨憺たる結果に終わったと想像してください。そこからさかのぼって考えます。なぜ失敗したのでしょうか？

悲観的になるためではありません。崩壊しないものを作るための方法です。

---

チャレンジを実施するタイミング

• 計画に多大なリソースを投入する前
• 取締役会や投資家に提示する前
• 計画への肯定的なフィードバックしか耳に入ってこないと気づいたとき
• 計画の実現に、複数の外部依存要因の連携が必要なとき
• 急いで進め、「後で何とかする」よう求められているとき
• 計画に期待を感じているとき（期待の高まりは、より厳しく精査する合図です）

---

チャレンジのフレームワーク

ステップ 1：主要な前提を洗い出す

計画を検証するには、真実だと仮定していることをすべて表面化させる必要があります。

計画の各セクションについて、次の点を問いかけます。

• これがうまくいくには、何が真実でなければなりませんか？
• 顧客の行動について、どのような前提を置いていますか？
• 競合の対応について、どのような前提を置いていますか？
• 自分たちの実行能力について、どのような前提を置いていますか？
• どのような外部要因に依存していますか？

よくある前提の分類：

• 市場に関する前提 — 市場規模、成長率、顧客の支払い意欲、購買サイクル
• 実行に関する前提 — チームの対応能力、開発速度、大規模な採用は不要
• 顧客に関する前提 — 顧客に課題があり、その課題を認識していて、解決のために費用を払う
• 競合に関する前提 — 既存企業が対抗策を講じない、新規参入者が現れない、競争優位性が維持される
• 財務に関する前提 — 資金消費率、収益化の時期、CAC、LTV の比率
• 依存関係に関する前提 — パートナーが納品する、API が変更されない、規制が変わらない

ステップ 2：各前提を評価する

洗い出した各前提を、次の 2 つの側面から評価します。

確信度（その前提が真実であるとどれほど確信しているか）：

• 高 — データ、顧客との対話、市場調査によって検証済み
• 中 — 大筋では正しいが、検証されていない
• 低 — 妥当そうだが、未検証
• 不明 — 単純に分からない

誤っていた場合の影響（その前提が成り立たなかった場合に何が起きるか）：

• 致命的 — 計画全体が失敗する
• 大 — 大幅な遅延またはコスト超過
• 中 — 大幅なやり直しが必要
• 小 — 対応可能な調整で済む

ステップ 3：脆弱性を特定する

確信度が低い／不明 × 影響が致命的／大の組み合わせが、最もリスクの高い前提です。

脆弱性 = 確信度が低い + 影響が大きい

これらは無視してよい問題ではありません。あなたが賭けている要素です。問うべきなのは、その賭けを自覚しているかどうかです。

ステップ 4：依存関係の連鎖を見つける

多くの計画が失敗するのは、個々の前提が誤っているからではなく、複数の前提が同時に正しくなければならないからです。

連鎖を整理します。

• 前提 B は、まず前提 A が真であることに依存していますか？
• 最初の段階で問題が起きた場合、その後のどれだけの項目に影響しますか？
• クリティカルパスは何ですか？余裕がまったくない箇所はどこですか？

ステップ 5：可逆性を検証する

重大な脆弱性ごとに、この前提が 3 か月目に誤りだと判明した場合、どうするかを考えます。

• 方向転換できますか？
• スコープを縮小できますか？
• すでに資金を使っていますか？
• すでに約束をしていますか？

可逆性が低いほど、コミットする前に、より厳密に検証する必要があります。

---

出力形式

チャレンジレポート：［計画名］

CORE ASSUMPTIONS (extracted)
1. [Assumption] — Confidence: [H/M/L/?] — Impact if wrong: [Critical/High/Medium/Low]
2. ...

VULNERABILITY MAP
Critical risks (act before proceeding):
• [#N] [Assumption] — WHY it might be wrong — WHAT breaks if it is

High risks (validate before scaling):
• ...

DEPENDENCY CHAIN
[Assumption A] → depends on → [Assumption B] → which enables → [Assumption C]
Weakest link: [X] — if this breaks, [Y] and [Z] also fail

REVERSIBILITY ASSESSMENT
• Reversible bets: [list]
• Irreversible commitments: [list — treat with extreme care]

KILL SWITCHES
What would have to be true at [30/60/90 days] to continue vs. kill/pivot?
• Continue if: ...
• Kill/pivot if: ...

HARDENING ACTIONS
1. [Specific validation to do before proceeding]
2. [Alternative approach to consider]
3. [Contingency to build into the plan]

---

計画の種類別チャレンジパターン

製品ロードマップ

• 顧客がお金を払うものを作っていますか。それとも、顧客が欲しいと言ったものを作っていますか？
• 開発速度の見積もりは、理論上ではなく実際のチームの対応能力を考慮していますか？
• 主要機能の開発に、見積もりの 3 倍の時間がかかった場合、どうなりますか？
• 要件が衝突したとき、誰が意思決定の責任を負いますか？

市場投入計画

• 実際の ICP コンバージョン率はどれくらいですか？期待値ではなく、実績を教えてください。
• 成約までに何回の接点が必要ですか？そのための営業体制は整っていますか？
• 最初の10件の成約に1か月ではなく3か月かかった場合、どうなりますか？
• 「ランド・アンド・エクスパンド」は実際の戦略ですか？それとも単なる期待ですか？

採用計画

• 重要な人材の採用に6週間ではなく4か月かかった場合、どうなりますか？
• 離職する可能性のある特定の人材を維持できることが計画の前提になっていませんか？
• 戦力として十分に機能するまでに通常3〜6か月かかることを考慮していますか？
• 人員が売上に対して6か月先行した場合、バーンレートにどのような影響がありますか？

資金調達計画

• リード投資家に断られた場合の代替策は何ですか？
• 3か月ではなく6か月かかった場合のスケジュールを試算していますか？
• 調達ラウンドが目標額の下限で成立した場合、現在のバーンレートでのランウェイはどれくらいですか？
• 目標額の50％しか調達できなかった場合、どの前提が崩れますか？

---

最も厳しい質問

見過ごされがちな質問です：

• 「基本ケースではなく、悲観ケースはどうなりますか？」
• 「この計画を、私たちが信頼していないチームが実行しても成功しますか？」
• 「気まずくて口に出せないために、言えていないことは何ですか？」
• 「この計画を実際より良く見せる動機があるのは誰ですか？」
• 「この計画に敵対する人なら、まず何を攻撃しますか？」

---

成果物

/em:challenge の出力は、そこで止めてよいという許可ではありません。弱点を示すマップです。これをもとに、リスクの高い前提を検証し、重要な前提には対策を講じるか、または自覚したうえで賭けに出るかを判断できます。

未知のリスクは危険です。把握しているリスクなら管理できます。