この記事の要約
- 機能要望は「目的→機会→解決策→実験」の4段階で構造化すると、真に取り組むべき課題が見える
- ユーザーリサーチでは定量分析で仮説を立て、インタビューでコンテクストを深堀りすることで潜在ニーズを発見できる
- 解決策は一度に実装せず小さく実験して検証を重ねることで、開発リソースを無駄にせず正しい方向へ進める
顧客や社内メンバー、営業担当など、多様なステークホルダーから次々と届けられる要望は、気づけば“大量のリスト”になりがち………..
それらをすべて満たすのは不可能であり、闇雲に実装してしまうと散漫なプロダクトになってしまうリスクも。
- 「顧客からの声だし、対応しなきゃ」
- 「営業が『この機能が必要だ』と言うから緊急度高い？」
といった具合に、要望が殺到している状態はまさに“カオス”です。優先度の付け方ひとつで、売上や顧客ロイヤルティに大きな影響が出かねないからこそ、PdMの頭を悩ませるのです。
このような状況では、要望の真の意図や、顧客がどんな課題を抱え、どんな価値を求めているのかを深く掘り下げる枠組みが必要。その枠組みの1つとして非常に有効なのが、Teresa Torres氏が提唱する「Opportunity Solution Tree（OST）」です。
Opportunity Solution Treeとは？
Opportunity Solution Tree（OST）は、プロダクトの方向性を見失わずに“継続的に顧客価値を発見し、実行に移す”ためのフレームワーク。
提唱者のTeresa Torres氏は著書『Continuous Discovery Habits』で、チームが日常的に顧客インサイトを得て、仮説検証を行う「継続的ディスカバリー」の方法論を詳説しています。その基盤となるのがOSTです。
OSTはシンプルにまとめると以下の4段階で構成されます。
- 目的（Outcome）：どんなビジネス上の目標・成果を達成するかを設定する
- 機会（Opportunity）：ユーザーが抱える課題やニーズを洗い出す
- 解決策（Solution）：洗い出した機会に対する具体的なプロダクトアイデアを考える
- 実験（Experiment）：優先度の高い解決策を短期的に検証し、学びを得る
このように階層を分けて考えることで、「闇雲に機能を追加していくプロダクト開発」から脱却できます。なぜなら、常に“どの機会を狙っていて”“何を実験し”“目的達成にどう貢献するか”を意識できるようになるからです。
具体的なアウトプットイメージがこちら。
機会を発見するためのユーザーリサーチ
OSTのなかでも特に重要なのが、「機会（Opportunity）」の発見。多くの場合、“どのような機能を作るか”ばかりに注目が集まりがちですが、本来は“どの機会を解決したいのか”が先。そのためにはユーザーリサーチが欠かせません。僕自身、ユーザーインタビューを累計700人以上行い、そこで得られるインサイトの重みを実感しています。
ユーザーリサーチを行う際は、まずログ分析で定量的なユーザー行動を把握するのが有効です。
- どの機能がどの頻度で使われているか？
- どのページで離脱が多いか？
など、数字から仮説を立てます。そして、その仮説を深堀りするためにインタビューを実施します。インタビューでは質問の設計が極めて重要ですが、もし1つだけ意識するポイントを挙げるなら、「コンテクストの徹底的な深堀」。ユーザーがその機能を使うシーンや目的、その背景にどんな真の課題があるのかを探り出すことが、“機会”の発見につながります。
また、ログ分析とインタビューを組み合わせることで、表面的な要望の背後にある「実際の困りごと」を可視化できます。それがユーザー本人も言語化できていない潜在ニーズだったり、実は違う問題があることに気づく大きなきっかけになるのです。こうして見えてきた機会リストをツリー上に整理すると、「どれが本当に取り組むべき優先度の高い機会なのか？」をチームで議論できる状態になります。
解決策の優先度付けと実験設計
機会を整理した後は、それを解決するためのアイデア（解決策）を洗い出します。ここでありがちな罠は、「解決策を増やすのは良いが、検証コストがどんどん増える」というものです。そのため、OSTでは解決策を一度にすべて実行するのではなく、優先度の高い仮説から小さく実験するアプローチを推奨します。
実験の仕方としては、PoC（Proof of Concept）や、ユーザーへの限定的なβテストなどが代表的です。PoCで技術的な検証や初期的なユーザー反応を探り、一定の確度が見えたら、βテストでスケールして本格的にユーザーへ提供する流れがおすすめです。開発リソースに限りがあるなかで、早期に失敗を見極めたり成功の手応えを得たりするために、小さく作って早く試す姿勢が大切です。
たとえば、社内向けの小規模テストを経て、一定の定性・定量的な指標を満たせばプロトタイプを外部ユーザーに試してもらうなど、検証手法を段階的に組み合わせます。この“検証の仕組み”をチームとして回すことで、OST上の各解決策が正しい方向へ向かっているかを継続的にチェックできるようになります。
運用Tips：チーム全員が視覚的に把握できる環境づくり
OSTは文字どおりツリー型の構造を描くため、MiroやMURALなどのオンラインホワイトボードツールが非常に便利です。大きな画面に「目的」「機会」「解決策」「実験」を階層的に整理しておくことで、関係者全員が最新の状態をひと目で把握できます。
もうひとつ重要なのは、社内外のステークホルダーを巻き込みやすいフォーマットにしておくことです。例えば、営業チームに「機会」に関する仮説を投げてもらうときに、営業視点で見込み顧客の声を反映しやすいようなテンプレートを用意するなど、誰もが気軽にアイデアを追加できる仕組みがあると、OSTが豊かに育ちます。
また、ツリーの更新に合わせて社内Wikiなどにもサマリーを共有し、「いつ何をアップデートしたのか」を明確にしておくことが理想です。これによって、チームの新メンバーや他部署のメンバーでも目的と進捗をすぐ理解できる環境が整います。
Opportunity Solution Treeのケーススタディ
ここでは架空の事例をもとに、OSTの有効性をイメージしてみます。たとえば、あるBtoB向けSaaS企業が「ユーザーの導入後活用率を高め、解約率を減らす」という目的（Outcome）を設定していたとします。営業やカスタマーサクセスからは「もっと高機能なレポート画面を作るべきだ」という要望が殺到していました。
ところが実際にログ分析とインタビューを行ってみると、
- 「そもそもレポート自体を全然使いこなせていない」
- 「最初の設定が複雑で挫折している」
という課題が浮かび上がりました。レポート機能を高度化するより、導入オンボーディング時のガイド機能を拡充するほうが機会としては大きかったのです。これがOSTでいう“機会（Opportunity）”の発見です。そこで新しいオンボーディングフローをプロトタイプとして作り、限られたユーザーに使ってもらい、改善を重ねることで離脱率が顕著に低下。結果として契約更新率の向上につながりました。
このように、当初ステークホルダーが主張していた解決策（レポート機能の強化）だけにこだわらず、ユーザーの真の課題に切り込むOST思考が成功の鍵になったのです。
よくある失敗例と対処法
OSTを導入したからといって、すべてがスムーズに回るわけではありません。よくある失敗のひとつは「機会」のリスト化が不十分なまま、すぐに「解決策」へ飛びついてしまうケースです。焦って開発に走ると、結局“要望リストの消化”と変わらなくなり、本来の学習と発見のプロセスが省略されてしまいます。
また、PdMだけがOSTの図を作って満足しているパターンも失敗例に挙げられます。せっかく作ったのにチームメンバーがその存在を知らない、または理解していない状態では、OSTが分断を生む要因にすらなりかねません。定期的なチームレビューやステークホルダーミーティングでOSTを振り返り、更新する習慣を根付かせることが大切です。
さらに、実験を設計するときに「失敗を悪」として捉えすぎる文化も障害となります。OSTの利点は、小さな失敗を早期に回収して、次の解決策へ軌道修正できるところにあります。実験の失敗は成功への近道だという考え方をチームに浸透させ、心理的安全性を育むことも重要です。
今日から実践できるアクション
まずは小さな単位でOSTを導入してみるとよいでしょう。ステークホルダーから提案された機能要望を、「目的」「機会」「解決策」「実験」のどこに位置付けるかをホワイトボードやオンラインツールで可視化します。すべての要望を一気に整理するのは大変なので、チームが直面している課題だけを対象にしても構いません。
次に、ユーザーリサーチのプロセスをOSTに絡めて考えます。ログ分析やインタビューを実施するときに、「今回のリサーチの目的（Outcome）は何か」「どの機会を検証しようとしているのか」を明確にしましょう。ぼんやりとインタビューするよりも、焦点が定まりやすくなります。
最後に、実験サイクルをチームで具体化します。PoCやβテスト、ユーザーへの限定リリースなど、どのステップでどんな検証を行うかをあらかじめ決めておくと、OSTが机上の空論で終わらなくなります。失敗を前提とした小さな実験文化を育てるのもポイントです。
Q&A
Q1. OSTと従来のロードマップ管理はどう違うの？
A1. 従来のロードマップ管理は「いつ、どの機能を出すか」にフォーカスしがちですが、OSTは「どんな機会を解決するのか」「なぜそれが重要か」を重視します。ロードマップとOSTを併用することで、優先度や目的の連動性が明確になります。
Q2. 小規模なスタートアップでもOSTは活用できる？
A2. むしろ小規模スタートアップこそ迅速な検証が重要なので、OSTは有効です。チームメンバー全員が目的と機会を共有し、小さく実験を重ねることで、早期に正しい方向性を確認できます。
Q3. 多くの機能要望が既に溜まっていて、どこから手をつけていいかわからない…
A3. 全部を一度に整理しようとする必要はありません。まずは最近特に優先度が高そうな要望や、課題感が強い顧客セグメントに絞り、OSTを組み立ててみると良いでしょう。
参考情報
- Torres, Teresa. (2021). Continuous Discovery Habits. Evergreen Workshops.
- Cagan, Marty. (2018). INSPIRED: How to Create Tech Products Customers Love. Wiley. → 書籍の要約記事はこちら：『INSPIRED』顧客に愛されるプロダクトを生むプロダクトマネジメントの極意
- Ries, Eric. (2011). The Lean Startup. Crown Business. → 要約記事：リーン・スタートアップをあらためて噛み締める
- 社内でアイデアの整理をどう進めるか？ → 「アイデアマネジメント」
- インタビューで機会を深堀りする手法 → 「ユーザーインタビューでたった1つ意識するなら『コンテクストの徹底的な深堀』」
コメント