opportunity-solution-tree

目的

ステークホルダーの要望から目標成果を抽出し、機会の選択肢（解決すべき問題）を生み出し、潜在的なソリューションを整理し、実現可能性、インパクト、市場適合性に基づいて最適な概念実証（POC）を選定することで、プロダクトマネージャーが機会ソリューションツリー（OST）を作成できるよう支援します。漠然としたプロダクトの要望を構造化されたディスカバリーへと導き、ソリューションに飛びつく前にチームが適切な問題を解決できるようにします。これにより、「機能工場」症候群や、アイデアを時期尚早に絞り込むことを防ぎます。

これはロードマップの生成ツールではありません。テスト可能なソリューション仮説を伴う、検証済みの機会を導き出すための構造化されたディスカバリープロセスです。

入力

最適な入力： ステークホルダーの要望、または出発点となる目標成果。 あると役立つ入力： すでに得ている顧客のエビデンス、制約、すでに推進されているソリューション。

呼び出し時に渡された内容（スキル名の後に続くテキスト、貼り付けられたコンテキストのダンプ、または追記された ARGUMENTS: 行）は、すでに回答済みの情報として扱います。内容を活用し、そこに含まれている質問は再度しないでください。

何も用意していなくても大丈夫です。 このスキルは、要望または望ましい成果を尋ねるところから始め、そこから測定可能な目標成果を抽出します。

呼び出し例： Build an OST from this request: 'Sales says we need a mobile app because competitors have one.'

主要な概念

機会ソリューションツリー（OST）とは？

OSTは、次の要素を結び付ける視覚的なフレームワークです（Teresa Torres、『Continuous Discovery Habits』）。

1. 望ましい成果（ビジネス目標またはプロダクト指標）
2. 機会（成果につながる可能性のある顧客の問題、ニーズ、ペインポイント、または願望）
3. ソリューション（各機会に対処する方法）
4. 実験（ソリューションを検証するテスト）

構造：

         Desired Outcome (1)
                |
    +-----------+-----------+
    |           |           |
Opportunity  Opportunity  Opportunity (3)
    |           |           |
  +-+-+       +-+-+       +-+-+
  | | |       | | |       | | |
 S1 S2 S3    S1 S2 S3    S1 S2 S3 (9 total solutions)

効果がある理由

• 成果主導： 機能の要望ではなく、ビジネス目標から始めます
• 発散してから収束： ソリューションを選ぶ前に、複数の機会を検討します
• 問題に焦点を当てる： 機会は問題であり、問題を装ったソリューションではありません
• テスト可能： 各ソリューションを実験に結び付け、「作ってリリースする」だけで終わらせません
• POCの選定： リソースを投入する前に、実現可能性、インパクト、市場適合性を評価します

アンチパターン（これは何ではないか）

• 機能のリストではありません： 機会とは顧客が直面する問題であり、「ダークモードが必要」ではありません
• ソリューションから始めません： 「Xを作るべき」ではなく、「顧客はYに苦労している」から始めます
• ウォーターフォール計画ではありません： OSTはディスカバリーツールであり、プロジェクト計画ではありません
• 一度きりの演習ではありません： OSTは実験から学ぶにつれて進化します

使用する場面

• ステークホルダーから機能またはプロダクト施策の要望がある
• 新しいプロダクト領域のディスカバリーを開始する
• 漠然としたOKRや戦略目標を明確にする
• どの問題を優先して解決するか決める
• 目指す成果についてチームの認識を合わせる

使用しない場面

• 問題がすでに検証済みの場合（ソリューションのテストに進みます）
• 戦術的なバグ修正や技術的負債への対応（ディスカバリーは不要です）
• ステークホルダーが特定のソリューションを要求している場合（まず認識のずれに対処します）

---

ファシリテーションの基準

このスキルの標準的なやり取りのプロトコルとして、workshop-facilitation を使用してください。

次の内容を定義しています。

• セッション開始時の案内と参加モード（ガイド形式、コンテキストのダンプ、最善の推測）
• 平易な言葉によるプロンプトを使った、1ターンにつき1つの質問
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 割り込みへの対応と一時停止・再開の動作
• 判断が必要な場面での番号付き推奨事項
• 通常の質問に対する番号付きのクイック選択回答（必要に応じて Other (specify) を含める）

このファイルでは、ドメイン固有の評価内容を定義します。矛盾がある場合は、このファイルのドメインロジックに従ってください。

アプリケーション

全項目を記入するための構成は、template.mdを使用してください。

このインタラクティブなスキルは、2段階のプロセスに従います。

フェーズ 1： OST を生成する（成果を抽出し、機会を特定し、解決策を整理する） フェーズ 2： POC を選択する（解決策を評価し、最適な開始点を推奨する）

---

ステップ 0：コンテキストを収集する（質問の前に）

エージェントが提案します：

オポチュニティ・ソリューション・ツリーを作成する前に、コンテキストを集めましょう。

ステークホルダーからの依頼または製品イニシアチブ：

• ステークホルダーからの依頼内容は何ですか？（機能リクエスト、製品アイデア、戦略目標）
• 既存の資料はありますか？PRD の草案、OKR 文書、戦略メモ、議事録など
• 問題の記述、顧客からの苦情、調査結果など

製品のコンテキスト（あれば）：

• Web サイトのコピー、ポジショニングの説明、製品の説明
• 競合他社の資料、顧客レビュー（G2、Capterra）、コミュニティでの議論
• 利用状況データ、サポートチケット、解約の理由

これらの内容を直接貼り付けるか、依頼内容を簡潔に説明してください。

---

フェーズ 1：オポチュニティ・ソリューション・ツリーを生成する

質問 1：望ましい成果を抽出する

エージェントが尋ねます： 「このイニシアチブで望む成果は何ですか？（どのビジネス指標または製品指標を改善しようとしていますか？）」

番号付きの選択肢を 4 つ提示します：

1. 収益の成長 — 「ARR を増やす、既存顧客からの収益を拡大する、新たな収益源を開拓する」（拡大を目指す製品で一般的）
2. 顧客維持 — 「解約を減らす、アクティベーションを増やす、エンゲージメントや定着率を向上させる」（顧客維持に課題がある既存製品で一般的）
3. 顧客獲得 — 「登録数を増やす、トライアルからのコンバージョンを増やす、新規ユーザーの成長を促す」（初期段階または成長中の製品で一般的）
4. 製品効率 — 「サポートコストを削減する、価値を実感するまでの時間を短縮する、業務指標を改善する」（業務の最適化を進める成熟した製品で一般的）

または、望ましい成果を具体的に説明してください（測定可能な形にします。例：「トライアルから有料プランへのコンバージョン率を 15% から 25% に引き上げる」）。

ユーザーの回答：［選択または自由記述］

エージェントが抽出して確認します：

• 望ましい成果：［具体的で測定可能な成果］
• 重要である理由：［ステークホルダーからの依頼またはコンテキストに基づく根拠］

---

質問 2：機会（解決すべき問題）を特定する

エージェントは、望ましい成果と提供されたコンテキストに基づいて、3 つの機会を生成します。

エージェントが述べます： 「望ましい成果（質問 1 の内容）と提供されたコンテキストに基づいて、この成果につながる可能性のある3 つの機会（顧客の問題またはニーズ）を挙げます。」

例（成果が「トライアルから有料プランへのコンバージョン率を上げる」の場合）：

1. 機会 1：ユーザーがトライアル中に価値を実感できていない — 「新規ユーザーは登録するものの、オンボーディングを完了せず、『なるほど』と思う瞬間を経験できないまま、製品の中核的な価値を知る前に利用をやめてしまう」

   • 根拠：［コンテキストから：オンボーディング分析、サポートチケット、終了時アンケート］

2. 機会 2：料金が不明瞭、またはニーズに合っていない — 「ユーザーは有料プランに価値があるか判断できず、料金に何が含まれるのか理解できない。料金ページも分かりにくい」

   • 根拠：［コンテキストから：料金ページでのコンバージョンファネルの離脱、営業上の懸念事項］

3. 機会 3：無料プランで十分だと感じている — 「無料プランでニーズを満たせるため、ユーザーはいつまでも無料プランを使い続け、アップグレードする動機がない」

   • 根拠：［コンテキストから：フリーミアムユーザーの維持率データ、回避策を尋ねるサポートチケット］

エージェントが尋ねます： 「最初に深掘りするうえで最も重要だと感じる機会はどれですか？または、機会を変更・追加しますか？」

ユーザーの回答：［選択または自由記述］

---

質問 3：選択した機会のソリューションを生成する

エージェントが選択した機会に対するソリューション案を3つ生成します。

エージェントの発言： 「機会 [X]：[Name] に対して、テストする ソリューション案を3つ ご紹介します。」

例（機会1「ユーザーがトライアル中に価値を実感できない」を選択した場合）：

1. ソリューション1：ガイド付きオンボーディングチェックリスト — 「主要なワークフローを手順ごとに案内するインタラクティブなチェックリストです（例：「最初のプロジェクトを作成する」「チームメイトを招待する」「タスクを完了する」）」

   • 仮説：構造化されたガイダンスによって完了率が向上します
   • 実験：チェックリストありとなしで A/B テストを行い、アクティベーション率を測定します

2. ソリューション2：価値実感までの時間に応じたトリガー — 「ユーザーが行き詰まったときに自動でメッセージを表示します（例：「まだプロジェクトを作成していません。こちらのテンプレートを使って始めましょう」）」

   • 仮説：先回りした働きかけによって離脱を防げます
   • 実験：メッセージへのエンゲージメントを追跡し、トライアルから有料への転換率の向上を測定します

3. ソリューション3：担当者によるオンボーディング支援 — 「価値の高いトライアルユーザー（エンタープライズプラン、チームプラン）に、カスタマーサクセスマネージャー（CSM）との15分間のオンボーディング通話を提供します」

   • 仮説：個別の対応によって、利用意欲の高いユーザーの転換率が向上します
   • 実験：トライアルユーザー50人に提供し、対照群と比較して転換率を測定します

エージェントの質問： 「別の機会に対するソリューションを検討しますか。それとも、POC の選定に進みますか。」

ユーザーの回答： [選択または自由入力]

---

フェーズ 2：概念実証（POC）の選定

ソリューションの生成後、エージェントは最初にテストするソリューションの選定を支援します。

---

質問 4：ソリューションを評価する（実現可能性、インパクト、市場適合性）

エージェントの発言： 「最適な出発点を選ぶために、ソリューションを評価しましょう。それぞれのソリューションを 実現可能性（構築の難易度）、インパクト（成果をどの程度向上させられるか）、市場適合性（顧客のニーズとの適合度）で採点します。」

エージェントが評価表を生成します：

ソリューション	実現可能性（1～5）	インパクト（1～5）	市場適合性（1～5）	合計スコア	根拠
ソリューション1：ガイド付きオンボーディングチェックリスト	4	4	5	13	実現可能性が高い（UI パターン）、効果が実証されている（業界標準）、市場適合性が高い（ユーザーはオンボーディングを期待している）
ソリューション2：価値実感までの時間に応じたトリガー	3	3	4	10	実現可能性は中程度（分析機能との連携が必要）、インパクトは中程度（トリガーの質による）、市場適合性は良好
ソリューション3：担当者によるオンボーディング支援	5	5	3	13	実現可能性が高い（開発作業不要）、インパクトが大きい（個別の対応）、市場適合性は低め（規模を拡大しにくく、手厚い対応が必要）

採点基準：

• 実現可能性： 1 = 数か月の作業、5 = 数日～数週間
• インパクト： 1 = 成果への影響がごくわずか、5 = 成果が大きく変化
• 市場適合性： 1 = 顧客は関心がない、5 = 顧客が積極的に要望している

エージェントの推奨：

推奨する POC：ソリューション1（ガイド付きオンボーディングチェックリスト）

この POC を推奨する理由：

• 実現可能性（2～4週間で構築可能）とインパクト（実績のあるパターン）のバランスが取れています
• 市場適合性が高い（ユーザーはオンボーディングのガイダンスを期待しています）
• 検証可能な仮説があります：「主要なワークフローをユーザーに案内すれば、アクティベーション率は X% から Y% に上昇する」

代替の POC：ソリューション3（担当者によるオンボーディング支援）

• 開発作業なしですばやく学びたい場合は、こちらから始めましょう
• トライアルユーザー20～50人を対象に手動でテストし、定性的なフィードバックを集めます
• 得られた知見を自動化ソリューション（ソリューション1）の参考にします

POC として推奨しない案：ソリューション2（価値実感までの時間に応じたトリガー）

• 事前の投資がより多く必要です
• インパクトはトリガーの質によって異なります（適切なトリガーを見つけるには実験が必要です）
• 基本的なオンボーディングの流れを検証した後のフォローアップに適しています

---

質問 5：実験を定義する

エージェントの質問： 「このソリューションをどのようにテストしますか？実験内容は何ですか？」

番号付きの選択肢を 3 つ提示します：

1. A/B テスト — 「MVP を構築し、トライアルユーザーの 50％に提示して、コンバージョン率を対照群と比較します」（最適な用途：定量的な検証、トラフィックが必要）
2. プロトタイプ＋ユーザビリティテスト — 「クリック可能なプロトタイプを作成し、10 人のユーザーがオンボーディングを試す様子を観察して、定性的なフィードバックを集めます」（最適な用途：初期段階の検証、トラフィックが少ない場合）
3. 手動コンシェルジュテスト — 「20 人のユーザーに対して手動でソリューションを実施し（例：オンボーディングを個別に案内する）、結果を測定します」（最適な用途：素早く学ぶ場合、開発作業が不要）

または、実験の進め方を説明してください。

ユーザーの回答：［選択または自由記述］

---

出力：Opportunity Solution Tree ＋ POC 計画

フローの完了後、エージェントは次の内容を出力します：

# Opportunity Solution Tree + POC Plan

## Desired Outcome
**Outcome:** [From Q1]
**Target Metric:** [Specific, measurable goal]
**Why it matters:** [Rationale]

---

## Opportunity Map

### Opportunity 1: [Name]
**Problem:** [Description]
**Evidence:** [From context]

**Solutions:**
1. [Solution A]
2. [Solution B]
3. [Solution C]

---

### Opportunity 2: [Name]
**Problem:** [Description]
**Evidence:** [From context]

**Solutions:**
1. [Solution A]
2. [Solution B]
3. [Solution C]

---

### Opportunity 3: [Name]
**Problem:** [Description]
**Evidence:** [From context]

**Solutions:**
1. [Solution A]
2. [Solution B]
3. [Solution C]

---

## Selected POC

**Opportunity:** [Selected opportunity]
**Solution:** [Selected solution]

**Hypothesis:**
- "If we [implement solution], then [outcome metric] will [increase/decrease] from [X] to [Y] because [rationale]."

**Experiment:**
- **Type:** [A/B test / Prototype test / Concierge test]
- **Participants:** [Number of users, segment]
- **Duration:** [Timeline]
- **Success criteria:** [What validates the hypothesis]

**Feasibility Score:** [1-5]
**Impact Score:** [1-5]
**Market Fit Score:** [1-5]
**Total:** [Sum]

**Why this POC:**
- [Rationale 1]
- [Rationale 2]
- [Rationale 3]

---

## Next Steps

1. **Build experiment:** [Specific action, e.g., "Create onboarding checklist wireframes"]
2. **Run experiment:** [Specific action, e.g., "Deploy to 50% of trial users for 2 weeks"]
3. **Measure results:** [Specific metric, e.g., "Compare activation rate: checklist vs. control"]
4. **Decide:** [If successful → scale; if failed → try next solution]

---

**Ready to build the experiment? Let me know if you'd like to refine the hypothesis or explore alternative solutions.**

---

例

OST の完全な例については、examples/sample.md を参照してください。

短い抜粋例：

**Desired Outcome:** Increase trial-to-paid conversion from 15% to 25%
**Opportunity:** Users don’t reach "aha" moment during trial
**Solution:** Guided onboarding checklist

よくある落とし穴

落とし穴 1：ソリューションに見せかけた機会

症状：「機会：モバイルアプリが必要です」

**結果：**問題を掘り下げる前に、すでにソリューションを決めてしまっています。

**対処法：**機会を顧客の課題として捉え直します。「モバイルを主に利用するユーザーは、外出先で製品にアクセスできません。」

---

落とし穴 2：発散を省略する（1 つのソリューションに飛びつく）

症状：「ソリューションは［X］だと分かっています。あとは構築するだけです」

**結果：**より良い選択肢を見逃し、学びが得られません。

**対処法：**機会ごとに少なくとも 3 つのソリューションを考えます。収束する前に、必ず発散させます。

---

落とし穴 3：成果が曖昧すぎる

症状：「望ましい成果：ユーザーエクスペリエンスの向上」

**結果：**成功を測定できず、機会に優先順位を付けられません。

**対処法：**成果を測定可能にします。「NPS を 30 から 50 に引き上げる」または「オンボーディングの離脱率を 60％から 40％に下げる」などとします。

---

落とし穴 4：実験をせずに、ただ構築する

**症状：**ソリューションを選び、すぐにロードマップに進む

**結果：**検証が行われず、間違ったものを構築するリスクが高まります。

**対処法：**すべてのソリューションを実験に対応付ける必要があります。実験がなければ、OST もありません。

---

落とし穴 5：分析麻痺（いつまでも検討し続ける）

**症状：**20 個の機会と 50 個のソリューションを考え出し、どれも選ばない

**結果：**チームは発見の段階から抜け出せず、進展がありません。

**対処法：**機会は 3 個、各機会のソリューションは 3 個（合計 9 個）に制限します。POC を選び、実験を実施し、学び、改善を繰り返します。

---

参考資料

関連スキル

• skills/problem-statement/SKILL.md — 機会を顧客の課題として捉える方法
• skills/jobs-to-be-done/SKILL.md — JTBD リサーチから機会を特定する方法
• skills/epic-hypothesis/SKILL.md — 検証済みのソリューションをテスト可能なエピックに変える方法
• skills/user-story/SKILL.md — 実験を実現可能なストーリーに分割する方法
• skills/discovery-interview-prep/SKILL.md — 顧客インタビューを通じて機会を検証する方法

外部フレームワーク

• Teresa Torres 著、Continuous Discovery Habits（2021）— Opportunity Solution Tree の起源
• Jeff Patton 著、User Story Mapping（2014）— 成果主導型のプロダクト計画
• Ash Maurya 著、Running Lean（2012）— 仮説主導型の実験

Dean の取り組み

• Productside Blueprint — 戦略的なプロダクト発見プロセス
• ［Dean に OST の資料がある場合は、ここにリンクします］

---

スキルの種類： インタラクティブ 推奨ファイル名： opportunity-solution-tree.md 推奨配置先： /skills/interactive/ 依存関係： skills/problem-statement/SKILL.md、skills/jobs-to-be-done/SKILL.md、skills/epic-hypothesis/SKILL.md、skills/user-story/SKILL.md を使用します