opportunity-solution-tree

オポチュニティ・ソリューション・ツリー（OST）

継続的なプロダクトディスカバリーを構造化するための視覚的なフレームワークです。望ましい 成果 を、顧客の オポチュニティ、考えられる ソリューション、それらを検証する 実験 につなげます。

ドメインの背景

オポチュニティ・ソリューション・ツリー（Teresa Torres、『Continuous Discovery Habits』）は、現代のプロダクトディスカバリーの基盤です。チームがまずオポチュニティの領域を把握するよう促すことで、ソリューションに飛びつくのを防ぎます。

構造（4つのレベル）：

1. 望ましい成果（最上位）— チームが目指す、測定可能なビジネスまたはプロダクトの成果です。明確な単一の指標にします（例：「7日後の継続率を40％に引き上げる」）。これは OKR またはプロダクト戦略に基づきます。

2. オポチュニティ（第2レベル）— 調査を通じて見つかった顧客のニーズ、悩み、望みです。解決する価値のある問題であり、機能ではありません。顧客の視点から、「〜に苦労しています」や「〜できたらいいのに」という形で表現します。オポチュニティスコアを使って優先順位を付けます：重要度 ×（1 − 満足度）（Dan Olsen、『The Lean Product Playbook』）。重要度と満足度を0〜1の範囲に正規化します。

3. ソリューション（第3レベル）— 各オポチュニティに対処する方法の候補です。オポチュニティごとに複数のソリューションを生み出し、最初のアイデアに決めつけないようにします。プロダクトトリオ（PM＋デザイナー＋エンジニア）が一緒にアイデアを出します。「最良のアイデアは、エンジニアから生まれることがよくあります。」

4. 実験（最下位）— ソリューションが実際にオポチュニティに対処できるかを検証する、迅速で低コストなテストです。前提条件の検証（価値、ユーザビリティ、実現可能性、実行可能性のリスク）を行います。意見に基づく検証よりも、「身銭を切る」実験（Alberto Savoia）を優先します。

主な原則：

• 一度に扱う成果は1つです。 すべてを解決しようとしないでください。ツリーの焦点を、望ましい単一の成果に絞ります。
• 機能ではなく、オポチュニティです。 「顧客にソリューションを設計させてはいけません。機能ではなく、オポチュニティ（問題）を優先してください。」
• 比較検討します。 選択する前に、オポチュニティごとに少なくとも3つのソリューションを必ず考えます。「最初のアイデア」の落とし穴を避けます。
• ディスカバリーは直線的ではありません。 実験が失敗したら前の段階に戻ります。検証できなかったソリューションは打ち切ります。新しい分岐を探ります。
• 定期的ではなく、継続的に行います。 インタビュー、分析、実験から得た学びに応じて、毎週ツリーを更新します。

手順

$ARGUMENTS を対象に、プロダクトチームがオポチュニティ・ソリューション・ツリーを作成するのを支援します。

入力要件

• 改善したい望ましい成果またはビジネス指標
• 顧客調査データ（インタビュー、アンケート、分析、フィードバック）
• 任意：整理したい既存のオポチュニティまたはソリューション案

プロセス

1. 望ましい成果を定義する — ツリーの最上位に置く、測定可能な単一の成果を確認するか、その表現を整えます。

2. オポチュニティを把握する — 提供された調査から、顧客のオポチュニティ（ニーズ／悩み）を3〜7個特定します。関連するオポチュニティをグループ化し、それぞれを顧客の視点から表現します。

3. オポチュニティの優先順位を付ける — オポチュニティスコアまたは定性的な評価を使って順位を付けます。上位2〜3個に焦点を当てます。

4. ソリューションを考案する — 優先度の高い各オポチュニティについて、PM、デザイナー、エンジニアの視点から3つ以上のソリューションをブレインストーミングします。

5. 実験を設計する — 有望なソリューションについて、迅速な実験を1〜2個提案します。仮説、方法、指標、成功のしきい値を明記します。

6. ツリーを可視化する — OST 全体を、明確な階層形式で提示します。

段階を追って考えてください。内容が多い場合は Markdown ファイルとして保存してください。

---

参考資料

• 拡張版オポチュニティ・ソリューション・ツリー
• プロダクトディスカバリーとは？ ステップごとに解説する完全ガイド
• プロダクトトリオ：当たり前を超えて
• 継続的なプロダクトディスカバリーのマスタークラス（CPDM）（ビデオコース）