kill-criteria-exit-ramps

中止基準と撤退への道筋

---

よくあるパターン

パターン 1：事前の中止基準（ローンチ前）

適用時：新しいプロジェクト、実験、製品を開始するとき

プロセス：（1）成功指標を定義する（「コンバージョン率 10％」）、（2）期間を設定する（「6 か月」）、（3）中止基準を定める（「6 か月後に 5％未満なら中止」）、（4）決定権を持つ人を指定する（具体的な担当者）、（5）正式に文書化する（署名済みの PRD）

例：新機能 — 成功条件：3 か月で導入率 20％、中止条件：導入率 10％未満、決定者：プロダクト担当 VP が判断

パターン 2：Go／No-Go ゲート（マイルストーンベース）

適用時：投資額が段階的に増えていく複数段階のプロジェクト

構成：ステージ 1（低コスト、コンセプト）→ Go／No-Go → ステージ 2（中程度、MVP）→ Go／No-Go → ステージ 3（高コスト、ローンチ）→ Go／No-Go

例：ゲート 1（4 週間、$10k）：顧客インタビュー 15 件以上で関心が確認できたら → GO。ゲート 2（3 か月、$50k）：週次アクティブ率 40％（実績は 25％）→ NO-GO、中止

利点：まず小規模に投資し、コストの高い段階に進む前に中止できます

パターン 3：トリガーに基づく撤退への道筋

適用時：結果が不確かな継続中のプロジェクト

よくあるトリガー：期間ベース（「18 か月目までに黒字化できない」）、指標ベース（「2 か月連続で解約率が 8％超」）、市場ベース（「競合がローンチする」）、リソースベース（「予算超過が 30％超」）、機会ベース（「よりよい選択肢が現れる」）

例：SaaS — トリガー 1：MRR の成長率が 3 か月間、月 10％未満 → 評価。トリガー 2：CAC の回収期間が 24 か月超 → 評価。トリガー 3：競合が $50M 超の資金調達を実施 → 評価

注：トリガーは評価を促すものであり、自動的に中止するものではありません

パターン 4：ピボットか中止かの判断

適用時：プロジェクトが計画どおりに進んでいない場合 — ピボットすべきか、中止すべきか？

フレームワーク：

次の場合はピボットします：

• 中核となる洞察は正しいが、実行方法が間違っている
• 顧客の課題は実在するが、解決策が間違っている
• 市場は存在するが、市場開拓の方法が間違っている
• 学習速度が速い（新たな洞察を急速に発見している）
• リソースの消費が持続可能である（追い詰められた状態ではない）

次の場合は中止します：

• 顧客の課題がない（あると便利なだけで、必須ではない）
• 市場が小さすぎる（事業を維持できない）
• 進捗に対して消費率が高すぎる
• チームがビジョンを信じていない
• よりよい機会がある（機会費用）
• 規制上または法的な障壁がある

例：エンゲージメントが低いモバイルアプリ

• 状況：フィットネスアプリをローンチし、ダウンロード数は 1 万件、週次アクティブ率は 5％（目標は 40％）
• ピボット案：インタビューから、ユーザーがワークアウトの記録ではなく食事の記録を望んでいると判明 → 栄養管理アプリにピボット
• 中止案：ユーザーはフィットネスの記録自体に関心がなく、市場も飽和している → 中止し、チームを再配置

判断：仮説が正しいのに実行方法が間違っている場合はピボットします。仮説が間違っている場合は中止します。

パターン 5：ポートフォリオの中止基準（複数のプロジェクト）

適用時：プロジェクトのポートフォリオを管理し、集中するために一部を中止する必要があるとき

プロセス：

1. 期待価値で順位付けする：ROI、戦略との適合性、リソース効率
2. 最低基準を定める：「ポートフォリオの上位 70％にリソースを割り当てる」
3. 下位 30％を中止する：埋没費用にかかわらず、基準を下回るプロジェクト
4. リソースを再配分する：中止したプロジェクトのリソースを、成果を上げているプロジェクトに割り当てる

例：10 件のプロジェクトを抱え、7 件まで対応可能な企業

• 順位付けの基準：（期待収益 × 成功確率）/ リソースコスト
• 中止：順位が 8 位、9 位、10 位のプロジェクト（「ほぼ完了」でも中止）
• 再配分：中止したプロジェクトのエンジニアを上位 3 件に配置

原則：埋没費用よりも機会費用が重要です。よりよい選択肢があるなら、「ほぼ完了」は継続の根拠になりません。

パターン 6：サンクコストの罠を避ける

状況：過去の投資を理由に、チームがプロジェクトの中止に抵抗している場合

手法：プレモーテムの反転

1. 尋ねます：「投資がゼロの状態で今日始めるとしたら、このプロジェクトを始めますか？」
2. 答えが「いいえ」なら → 中止します（サンクコストは関係ありません）
3. 答えが「はい。ただし、やり方を変えます」なら → 方針を転換します
4. 答えが「はい。まさに今のままです」なら → 続行します

例：エンタープライズ営業の取り組みが失敗

• 状況：18か月で200万ドルを投じ、顧客は2社（事業として成立するには50社が必要）
• 反転：「今日始めるとしたら、エンタープライズ営業に取り組みますか？」→「いいえ。セルフサービス型のSMBに注力します」
• 決定：エンタープライズ営業を中止し、SMBに方針を転換します（投じた200万ドルは関係ありません）

罠：「これほど投資したのだから、今さらやめられない」→これはサンクコストの誤謬です 回避策：重要なのは将来のコストと便益だけです。過去は取り戻せません。

---

ワークフロー

中止基準を定義または適用する際は、次の構造化されたアプローチを使用します。

□ Step 1: Define success metrics and time horizon
□ Step 2: Establish objective kill criteria
□ Step 3: Assign decision rights and governance
□ Step 4: Set milestone gates or trigger points
□ Step 5: Document formally (signed agreement)
□ Step 6: Monitor metrics regularly
□ Step 7: Evaluate at gates/triggers
□ Step 8: Execute kill decision (if triggered)

ステップ 1：成功指標と期間を定義する（詳細） 定量化可能な成功基準（例：「コンバージョン率20％」）と評価期間（例：「ローンチ後6か月」）を指定します。

ステップ 2：客観的な中止基準を設定する（詳細） 中止の決定につながる数値しきい値を設定します（例：「6か月後のコンバージョン率が10％未満の場合」）。基準は主観的ではなく、客観的なものにします。

ステップ 3：意思決定権とガバナンスを割り当てる（詳細） 中止を決定する担当者を具体的に指定します。エスカレーションのプロセスを定義します。「チームの合意」は避けてください（決定が麻痺する原因になります）。

ステップ 4：マイルストーンのゲートまたはトリガーポイントを設定する（詳細） 複数段階のプロジェクトでは、継続可否を判断するゲートを定義します。継続中のプロジェクトでは、評価を促すトリガーを定義します。

ステップ 5：正式に文書化する（詳細） 中止基準をPRD、プロジェクト憲章、または投資メモに記載します。ローンチ前にステークホルダーの署名または承認を得ます（後から基準を変更するのを防ぎます）。

ステップ 6：指標を定期的に監視する（詳細） 指標を毎週または毎月追跡します。中止基準のしきい値を明確に示すダッシュボードを用意します。しきい値に近づいた際のアラートを自動化します。

ステップ 7：ゲートまたはトリガーで評価する（詳細） ゲートまたはトリガーに達したら、正式な評価を実施します。プレモーテムの反転を使います。「今日、これを始めますか？」と問いかけ、続行、方針転換、中止のいずれかを決定します。

ステップ 8：中止の決定を実行する（詳細） 中止が決まった場合は、決定を伝え、プロジェクトを終了し、リソースを再配分して、事後分析を行います。ゾンビプロジェクトを避けるため、速やかに実行します。

---

ガードレール

1. ローンチ前に中止基準を設定する（開始後ではなく）

危険性：プロジェクト開始後に中止基準を定義すると、後から基準を変更することにつながります。

ガードレール：感情的または金銭的な投資をする前に、初期のプロジェクト文書に中止基準を記載します。ステークホルダーの承認を得ます。

危険信号：「進めながら、いつやめるかを考えます」—これはサンクコストの罠につながります。

2. 基準を客観的にする（主観的ではなく）

危険性：主観的な基準（「チームがうまくいっていないと感じている」）は、無視されやすくなります。

ガードレール：定量化可能な指標（数値、日付、マイルストーン）を使います。「導入率が低い」ではなく「コンバージョン率5％」、「妥当な期間」ではなく「6か月」とします。

テスト：2人がそれぞれ独立して基準を評価した場合、同じ結論に達するでしょうか？そうでなければ、主観的すぎます。

3. 明確な意思決定権を割り当てる

危険性：「チームで決める」や「話し合います」では、決定が麻痺します（全員にサンクコストがあるため）。

ガードレール：中止を決定する担当者を具体的に指定します。必要なデータを定義します。決定を覆す場合のエスカレーション経路を定めます。

例：「製品担当VPが6か月間の指標に基づいて中止を決定します。書面による理由を示したCEOのみが、その決定を覆せます。」

4. ゴールポストを動かさない

危険：中止基準に近づくと、チームが基準を下げたり、期限を延長したりします。

ガードレール：中止基準は開始時に固定します。変更には正式な手続き（書面による正当化、上級者の承認、新しい文書）が必要です。

危険信号：6か月の基準を満たしていないときに「あと3か月続けましょう」と言う

5. サンクコストは無関係

危険：「200万ドルを投資したのだから、今さらやめられない」—サンクコストの誤謬

ガードレール：プレモーテムの反転を使います。「今日、投資額ゼロで始めるとしても、これをやるでしょうか？」大切なのは将来だけです。

原則：過去のコストは取り戻せません。問うべきなのは、「将来の投資をここに使うべきか、それとも別の場所に使うべきか？」だけです。

6. 速やかに中止する（ゾンビプロジェクトを避ける）

危険：中止すべきプロジェクトが長引き、リソースを消耗します（「ゾンビプロジェクト」）。

ガードレール：中止を決定したら、直ちに終了プロセスに入ります。1週間以内に発表し、1か月以内にチームを再配置します。

危険信号：プロジェクトが3か月を超えて「終了プロセス中」になっている — これは中止ではなく、ゾンビ状態です。

7. 機会費用 > サンクコスト

危険：より良い機会があるにもかかわらず、「もうすぐ完了する」という理由でプロジェクトを続けます。

ガードレール：ポートフォリオの視点で考えます。「これらのリソースを使う最善の方法でしょうか？」そうでなければ、90％完了していても中止します。

原則：より良い選択肢を追求しないことによる機会費用は、多くの場合、現在のプロジェクトを完了するメリットを上回ります。

8. 責任を追及せず、事後検証する

危険：中止の判断が「失敗」と見なされ、チームが中止を避けるようになります。

ガードレール：プロジェクトの中止を当たり前のことにします。規律ある中止を称賛します。事後検証では、責任追及ではなく学びに焦点を当てます。

文化：「今四半期に3つのプロジェクトを中止した」は良いことです（成果を上げたプロジェクトのためにリソースを解放できた）。悪いことではありません（失敗ではありません）。

---

クイックリファレンス

中止基準チェックリスト

プロジェクト開始前に、以下に回答してください。

• 成功指標を定義しましたか？（定量化可能なもの。例：「コンバージョン率20％」）
• 期間を設定しましたか？（例：「ローンチ後6か月」）
• 中止基準を設定しましたか？（例：「6か月後にコンバージョン率が10％未満なら中止」）
• 意思決定権を割り当てましたか？（「チーム」ではなく、具体的な個人）
• 正式に文書化しましたか？（PRDに記載し、関係者が署名）
• モニタリング計画を立てましたか？（担当者、頻度、ダッシュボード）
• 終了計画を立てましたか？（基準に達した場合の中止方法）

Go／No-Go ゲートのテンプレート

ゲート	投資額	期間	成功基準	判断
ゲート1：コンセプト	$10k	4週間	強い関心を示す顧客インタビューが15件以上	GO / NO-GO
ゲート2：MVP	$50k	3か月	週間アクティブユーザー40％（ベータユーザー50人）	GO / NO-GO
ゲート3：ローンチ	$200k	6か月	コンバージョン率10％、CAC <$100	GO / NO-GO

ピボットか中止かの意思決定フレームワーク

要素	ピボット	中止
顧客の課題	課題は実在するが、解決策が間違っている	課題がない、あると便利な程度
市場規模	十分に大きい	小さすぎる
学習率	高い（新たな知見がある）	低い（行き詰まっている）
燃焼率	持続可能	高すぎる
チームの確信	変更すれば実現できると信じている	信じていない
機会費用	ピボットが最善の選択肢	より良い選択肢がある

---

リソース

リソースへのナビゲーション

• テンプレート：中止基準の文書、Go／No-Goゲートのテンプレート、ピボット／中止の意思決定フレームワーク、終了計画
• 方法論：サンクコストの心理学、ポートフォリオ管理、意思決定権のフレームワーク、事後検証のプロセス
• 評価基準：中止基準の品質を評価するための基準（10項目）

関連スキル

• expected-value：継続と中止の機会費用を定量化するため
• hypotheticals-counterfactuals：プレモーテム分析（「もっと早く中止していたらどうなっていたか？」）のため
• decision-matrix：継続／ピボット／中止の選択肢を比較するため
• postmortem：中止したプロジェクトから学ぶため
• portfolio-roadmapping-bets：ポートフォリオレベルで中止を判断するため

---

コンテキストでの例

例1：スタートアップの機能廃止

コンテキスト：SaaS で「高度な分析」をリリース。廃止基準：3か月後の利用率が15%未満

結果：利用率12% → 機能を廃止し、エンジニア2名をコア機能に再配置。6か月分の保守作業を削減しました。

例2：エンタープライズ営業の方向転換

コンテキスト：B2B SaaS。方向転換のきっかけ：12か月目までに顧客が10社未満

結果：顧客7社 → セルフサービス型のSMB向けに方向転換。6か月でSMBの顧客数が200社に達し、成長が4倍速くなりました。

例3：研究開発ポートフォリオの中止

コンテキスト：研究開発プロジェクト8件に対し、対応可能なのは5件。EV/コストで順位付け：A(3.5)、B(2.8)、C(2.5)、D(2.1)、E(1.8)、F(1.5)、G(1.2)、H(0.9)

決定：F、G、Hを中止しました。Fは「80%完了」していました。上位3件のプロジェクトを4か月早くリリースしました。