opportunity-solution-tree

機会・ソリューションツリー（OST）

望ましい成果 → 顧客の機会 → ソリューション → 実験をつなげて、プロダクトディスカバリーを構成します。問題領域を検証する前にソリューションへ飛びつくのを防ぎます。

Teresa Torres 著、Continuous Discovery Habits（2021）に基づいています。

---

4 段階の構造

                    ┌─────────────────────┐
                    │   DESIRED OUTCOME   │  ← single measurable metric
                    └──────────┬──────────┘
               ┌───────────────┼────────────────┐
        ┌──────┴─────┐  ┌──────┴─────┐  ┌──────┴─────┐
        │Opportunity │  │Opportunity │  │Opportunity │  ← customer pain/need
        │     A      │  │     B      │  │     C      │
        └──────┬─────┘  └──────┬─────┘  └────────────┘
        ┌──────┴───┐    ┌──────┴───┐
    ┌───┴──┐ ┌───┴──┐ ┌───┴──┐ ┌───┴──┐
    │Sol 1 │ │Sol 2 │ │Sol 3 │ │Sol 4 │  ← possible solutions
    └───┬──┘ └──────┘ └───┬──┘ └──────┘
  ┌────┴────┐         ┌───┴────┐
  │ Exp 1   │         │ Exp 2  │          ← fast experiments
  └─────────┘         └────────┘

主な原則：

• 一度に扱う望ましい成果は 1 つだけにします。すべてを解決しようとしないでください
• 機会は顧客の問題やニーズであり、ソリューションではありません
• 1 つを選ぶ前に、機会ごとに 3 つ以上のソリューションを考案します
• 実験は、仮説を検証する最も低コストな方法です
• ツリーは更新し続けるドキュメントです。学びに応じて毎週更新します

---

OST の構築方法

ステップ 1 — 望ましい成果を定義する

ツリーの最上位に置く、測定可能な成果を 1 つ確認するか、ユーザーが明確にできるよう支援します。

良い成果：

• 「7 日間の継続率を 20％ から 35％ に増やす」
• 「初回価値を得るまでの時間を 3 日から 1 日に短縮する」
• 「無料から有料へのコンバージョン率を 2％ から 5％ に増やす」

悪い成果（採用しないでください）：

• 「より良いオンボーディングを構築する」— これはソリューションです
• 「プロダクトを改善する」— 測定できません
• 「機能 X をリリースする」— これはアウトプットです

ユーザーが指標を提示できない場合は、次のように尋ねます。「この取り組みが成功したと判断するには、何が実現している必要がありますか？」

ステップ 2 — リサーチから機会を整理する

顧客インタビュー、分析データ、サポートチケット、NPS のフィードバックから、顧客の機会（ペインポイント、満たされていないニーズ、願望）を 3～7 個特定します。

それぞれを顧客の視点から表現します：

• ✅ 「自分に合ったプランがどれなのか、理解するのに苦労しています」
• ✅ 「過去の購入履歴をすぐに見つけられません」
• ✅ 「自分のデータが安全かどうか不安です」
• ❌ 「ユーザーにはより良い検索機能が必要です」— これはソリューションです

Opportunity Score を使って優先順位を付けます（Dan Olsen 著、The Lean Product Playbook）：

Opportunity Score = Importance × (1 − Satisfaction)

顧客にアンケートを実施し、それぞれのニーズについて重要度（0～1）と現在の満足度（0～1）を評価してもらいます。

• 重要度が高く、満足度が低い = スコアが最も高い = 最良の機会
• 重要度と満足度のグラフにプロットします。左上の領域が最適な領域です

ステップ 3 — ソリューションを考案する（収束する前に発散する）

優先度の高い各機会について、次の 3 つの視点から 3 つ以上のソリューションをブレインストーミングします。

• PM の視点：どのような UX やプロダクトの変更で対応できますか？
• デザイナーの視点：どのような操作性やビジュアルの変更が考えられますか？
• エンジニアの視点：どのような技術的アプローチが考えられますか？（最も創造的な案が出ることもよくあります）

ルール：

• 最初のアイデアに決めつけず、比較して検討します
• 「最良のアイデアはエンジニアから生まれることがよくあります」— 技術的なソリューションも含めます
• ソリューションは互いに独立している必要があります（同じ機会に対する異なるソリューションにします）

ステップ 4 — 実験を設計する

最も有望なソリューションについて、短期間で実施できる実験を 1～2 個設計します。

実験	検証する仮説	方法	成功指標	工数
<実験名>	<検証する考え>	<A/B テスト / フェイクドア / プロトタイプ / インタビュー>	<指標 + 閾値>	<1d / 3d / 1w>

仮説のカテゴリ（次の順で優先します）：

1. 価値：ユーザーはこれを望むでしょうか？（最初に検証する最重要項目）
2. ユーザビリティ：ユーザーは使い方を理解できるでしょうか？
3. 実現可能性：これを構築できるでしょうか？
4. 事業性：ビジネスとして成り立つでしょうか？

低コストな実験の種類：

• 既存プロダクト：A/B テスト、フェイクドア、プロトタイプ、ユーザーインタビュー、データ分析
• 新規プロダクト：XYZ 仮説（「Y のうち少なくとも X％ が Z を行う」）、ランディングページ、コンシェルジュ MVP

ステップ 5 — 可視化して文書化する

docs/discovery/OST-<outcome-slug>.md を作成します：

# Opportunity Solution Tree: <Outcome>

**Desired outcome**: <metric> from <current> to <target> by <date>
**Last updated**: <date>

## Opportunity map

| # | Opportunity | Importance | Satisfaction | Opportunity Score | Priority |
|---|------------|-----------|-------------|-------------------|---------|
| A | <customer need> | 0.8 | 0.3 | 0.56 | 1st |
| B | <customer need> | 0.7 | 0.6 | 0.28 | 3rd |
| C | <customer need> | 0.6 | 0.2 | 0.48 | 2nd |

## Solutions for top opportunities

### Opportunity A: <name>
| Solution | Description | Experiment |
|---------|-------------|-----------|
| Sol A1 | <description> | <experiment> |
| Sol A2 | <description> | <experiment> |
| Sol A3 | <description> | <experiment> |

## Active experiments

| Experiment | Assumption | Status | Result |
|-----------|-----------|--------|--------|
| <name> | <assumption> | Running / Done | <result or pending> |

## Learning log

- <date>: Discovered <insight> from <source>. Killed <solution> / promoted <opportunity>.

---

/spec prd との連携

機会が検証され、ソリューションが選ばれたら： → 検証済みの機会を問題の記述として /spec prd を実行します → OST の Opportunity Score のデータは、PRD §3（成功指標）と §4（ターゲットユーザー）に直接反映されます

---

アンチパターン

❌ 機会を装った解決策：「ユーザーには検索バーが必要です」は解決策です。「ユーザーは過去の購入を見つけられません」は機会です。

❌ 発散の省略：機会ごとに最初に思いついた解決策を選ぶことです。選ぶ前に、必ず3つ以上案を出してください。

❌ 1週間を超える実験：学びを得るのに1週間以上かかるなら、それは実験ではなく機能です。

❌ ツリーを一度だけ更新する：OSTは継続的な取り組みです。学びに応じて毎週更新してください。

❌ 成果が多すぎる：ツリーごとに成果は1つです。成果が複数ある場合は、複数のツリーを実行するか、最も優先度の高いものを選んでください。