フレームワーク活用ガイドひとことで言うと#
**成果目標（Outcome）→ 機会（Opportunity）→ 解決策（Solution）→ 実験（Experiment）**をツリー構造で可視化するフレームワーク。「何を作るか」をいきなり決めるのではなく、「なぜそれを作るのか」から逆算して最適な打ち手を見つける。
押さえておきたい用語#
- Outcome（成果目標）
- ツリーの頂点に置くビジネスで達成したい定量的な目標のこと。OKRのKey Resultをそのまま使えることが多い。
- Opportunity（機会）
- 成果目標の下に並べるユーザーの課題・ニーズ・ペインポイントのこと。解決策ではなくユーザー視点の課題で書く。
- Solution（解決策）
- 各機会に対する具体的な機能やデザインの提案のこと。1つの機会に最低3つの解決策を出して比較検討する。
- Experiment（実験）
- 有力な解決策に対して作る前に検証する小さなテストのこと。プロトタイプテスト、A/Bテスト、コンシェルジュテストなど。
オポチュニティソリューションツリーの全体像#
こんな悩みに効く#
- アイデアは出るが、どれがビジネス成果に繋がるかわからない
- 「顧客の声」と「ビジネス目標」をどう結びつけるか迷っている
- チーム内で「なぜこれを作るのか」の合意が取れない
基本の使い方#
ツリーの頂点にビジネスで達成したい成果目標を1つ置く。
良い成果目標の条件:
- 測定可能: 数値で評価できる（「月間アクティブユーザーを20%増やす」）
- チームが影響を与えられる: マクロ経済のような制御不能な要素ではない
- 時間軸がある: いつまでに達成するか明確
例:
- ○「新規ユーザーの初月リテンション率を30%→50%にする（Q2中）」
- ×「良いプロダクトを作る」（曖昧すぎる）
OKRを使っている場合は、Key Resultをそのまま成果目標に使える。
成果目標の下に、ユーザーの課題・ニーズ・ペインポイントを機会として並べる。
機会の見つけ方:
- ユーザーインタビューから抽出した課題
- サポート問い合わせの分析
- 行動ログから見える離脱ポイント
- 競合分析で見つけた未充足ニーズ
構造化のコツ:
- 大きな機会を小さな機会に分解する（例: 「セットアップが難しい」→「初期設定の項目が多すぎる」「どこから始めればいいかわからない」）
- 機会はユーザー視点の課題で書く（「ダッシュボード機能の追加」は機会ではなく解決策）
1つの成果目標に対して5〜15個の機会が出るのが理想。
それぞれの機会に対して複数の解決策を考える。ここがイノベーションの源泉。
ルール:
- 1つの機会に最低3つの解決策を出す（最初に思いついたものが最善とは限らない）
- 解決策は具体的な機能やデザインの形で書く
- 実現可能性やコストはこの段階では考慮しない
重要: いきなり1つの解決策に飛びつかない。比較検討できる選択肢があることで、より良い意思決定ができる。
有力な解決策に対して小さな実験を設計し、作る前に検証する。
実験の種類:
- プロトタイプテスト: モックアップで5人にユーザビリティテスト
- コンシェルジュテスト: 手動でサービスを提供して反応を見る
- ABテスト: 既存機能の小さな変更で効果を検証
- スモークテスト: LPだけ作って需要を確認
1つの解決策に1つの実験を紐づける。実験結果に基づいて、本格的に開発するかどうかを判断する。
ツリー全体を壁やMiroに貼り出して、チーム全員が見える状態にする。
具体例#
状況: MAU20万人のECアプリ。初月リテンション率が25%と低迷。チームが「何を作ればいいか」で迷っている状態。
OSTの構築:
成果目標: 初月リテンション率 25% → 40%（Q2中）
| 機会 | 解決策 | 実験 | 結果 |
|---|---|---|---|
| 欲しい商品が見つけられない | A: パーソナライズおすすめ | プロトタイプテスト20人 | 85%が「欲しい」 |
| B: 閲覧履歴レコメンド | — | — | |
| C: 類似商品通知 | — | — | |
| 購入後に再訪理由がない | A: 配送追跡＋レビュー依頼 | — | — |
| B: コーディネート提案 | プロトタイプテスト20人 | 85%が「欲しい」→開発決定 | |
| C: リピート割引 | — | — | |
| アプリを開く習慣ができない | A: タイムセール | — | 利益率圧迫で見送り |
| B: 新着商品の朝通知 | A/Bテスト1,000人 | Day 7リテンション+12%→開発決定 | |
| C: ログインボーナス | — | — |
| 指標 | OST導入前 | Q2末 |
|---|---|---|
| 初月リテンション率 | 25% | 37% |
| 実験→開発決定の件数 | — | 2件/9候補 |
| 開発した機能の効果実証率 | 30% | 100% |
OSTで「作る前に検証する」プロセスを入れたことで、9候補のうち本当に効果がある2件だけを開発できた。開発リソースの無駄遣いが激減した。
状況: 従業員50名のタスク管理SaaS。無料トライアルから有料転換率が8%と低い。「オンボーディングが悪い」とは分かっているが、具体的に何を改善すべきかチームで合意できない。
OST（ツリー構造）:
成果目標: トライアル→有料転換率 8% → 20%（H1中）
├── 機会1: 初期設定が多すぎて途中で離脱する（設定完了率35%） │ ├── A: 業種別テンプレート（設定を5個に削減） │ ├── B: AIが利用パターンを学習して自動設定 │ └── C: 対面セットアップサポート（CSが30分つきっきり）
├── 機会2: 使い始めても「便利」と感じるまで時間がかかる │ ├── A: ステップバイステップのガイドツアー │ ├── B: サンプルデータ入りのデモ環境 │ └── C: 活用事例動画を3日目にメール配信
├── 機会3: 無料期間中に上司への稟議材料が準備できない │ ├── A: 自動生成の「導入効果レポート」 │ ├── B: ROI計算シミュレーター │ └── C: 上司向けの1分デモ動画
実験結果:
- テンプレート（機会1-A）: コンシェルジュテスト10社 → 設定完了率85%に → 開発決定
- 導入効果レポート（機会3-A）: モック20社に提示 → 14社が「これがあれば稟議が通せる」 → 開発決定
- ガイドツアー（機会2-A）: A/Bテスト → 効果+3%のみ → 見送り
| 指標 | OST導入前 | 6ヶ月後 |
|---|---|---|
| トライアル→有料転換率 | 8% | 18% |
| 初期設定完了率 | 35% | 82% |
| 平均商談期間 | 45日 | 28日 |
「オンボーディング改善」という曖昧な課題を、OSTで3つの機会×9つの解決策に分解し、実験で絞り込んだ。ガイドツアーは「みんなが正解だと思っていた」が、実際は効果が薄かった。実験なしでは見抜けなかった。
状況: 蔵書15万冊の地方図書館。来館者数がコロナ前の60%に低迷。デジタル化の予算500万円をどこに投じるべきか、職員間で意見が割れている。
OST（ツリー構造）:
成果目標: 月間利用者数（来館＋オンライン）を8,000人→15,000人にする（1年以内）
├── 機会1: 読みたい本があるか分からず来館しない │ ├── A: オンライン蔵書検索＋予約システム │ ├── B: AIおすすめ本レコメンド │ └── C: 職員の「今月のおすすめ」SNS配信
├── 機会2: 子連れで来ると滞在が難しい │ ├── A: キッズスペースの拡充 │ ├── B: 子ども向け読み聞かせイベント │ └── C: 絵本宅配サービス
├── 機会3: 電子書籍を読みたいが図書館にない │ ├── A: 電子書籍貸出サービス │ ├── B: オーディオブック配信 │ └── C: 電子雑誌の無料閲覧
実験結果:
- SNSおすすめ配信（機会1-C）: 1ヶ月間Instagram運用 → フォロワー1,200人、来館者+15% → 即時展開
- 読み聞かせイベント（機会2-B）: 試験開催3回 → 参加者平均28組、リピート率65% → 月2回の定例化
- 電子書籍貸出（機会3-A）: アンケート300人 → 要望度82%だが導入コスト350万円 → 次年度予算で検討
| 指標 | OST導入前 | 1年後 |
|---|---|---|
| 月間利用者数 | 8,000人 | 13,500人 |
| オンラインサービス利用 | 0人 | 2,800人/月 |
| 投入予算 | 500万円全額 | 初年度180万円（残りは電子書籍用に温存） |
500万円を電子書籍に一括投資する案が有力だったが、OSTで機会を分解し実験したことで「SNS配信とイベントだけで利用者の68%回復が可能」と分かった。残り予算を翌年の電子書籍に回すという賢い判断ができた。
やりがちな失敗パターン#
- 解決策から始めてツリーを後付けで作る — 「この機能を作りたい」が先にあり、正当化のためにツリーを描くと本末転倒。必ず成果目標→機会→解決策の順番で考える
- 機会と解決策を混同する — 「ダッシュボードを追加する」は機会ではなく解決策。機会は「ユーザーが全体の状況を把握できない」のようにユーザー視点の課題で書く
- ツリーを一度作って更新しない — インタビューや実験を通じて新しい機会が見つかるのは当然。週次でツリーを更新し、学びを反映する
- 1つの機会に1つの解決策しか出さない — 最初に思いついた解決策が最善とは限らない。最低3つの選択肢を出すことで、より良い意思決定ができる
まとめ#
オポチュニティソリューションツリーは「何を作るか」と「なぜ作るか」を一枚の図で繋げるフレームワーク。成果目標から逆算し、ユーザーの機会を構造化し、複数の解決策を比較検討して実験で検証する。思いつきの機能開発から脱却し、成果に直結するプロダクト開発を実現しよう。