機能要望の“カオス”を整理し、顧客に本当に必要な価値を届ける「Opportunity Solution Tree」の活用法

2025年5月24日 23:22

本記事は僕が運営するPM x LLM STUDIOからの転載です。詳細や最新の情報を知りたい方は、ぜひこちらのオリジナル記事もあわせてご覧ください（本noteは本記事を少し変更しています）。

要望の氾濫

プロダクトを運営していると、顧客や社内の営業、サポートなどから多様な「機能要望」が次々と飛び込んできますよね。実装すればするほど魅力的に見える一方で、全部に応えていては散漫なプロダクトになりかねない。
「営業が“この機能が重要だ”と言うから急ぎで作るべきか？」
「既存ユーザーの声を無視するのもどうなんだろう…」
こうした悩みを抱えるプロダクトマネージャー（PM）は多いはず。まさに“要望リストの消化”が壮大なカオスを生み出し、かえってプロダクトの方向性を見失う原因になるわけです。

そこで注目したいのが、Teresa Torres氏が提唱する“Opportunity Solution Tree（OST）”というフレームワーク。要望をそのまま鵜呑みにするのではなく、ユーザーが本当に抱える課題（機会）を見極め、そこに対して複数の解決策を検討・実験するという考え方を示してくれます。本記事ではこのOSTのエッセンスと、具体的な活用法を解説します。

第1章：Opportunity Solution Tree（OST）とは？

1-1. Teresa Torresの“継続的ディスカバリー”から生まれたフレーム

Teresa Torres氏は著書『Continuous Discovery Habits』で、チームが日常的に顧客インサイトを得て学習し、機能開発や施策に活かす「継続的ディスカバリー」の方法を提唱。その中核にあるのが“Opportunity Solution Tree”です。

OSTは以下の4段階をツリー状に整理するフレームワーク：

目的（Outcome）: ビジネス上の成果・ゴール
機会（Opportunity）: ユーザーが抱える課題やニーズ
解決策（Solution）: 機会を解決するための具体的アイデア
実験（Experiment）: 解決策を検証するためのPoCやABテストなど

こうして階層を分けることで、要望が混在するカオス状態から脱却し、“どの機会を優先すべきか”と“それをどう検証するか”を冷静に判断しやすくなります。

1-2. “要望リスト”から“機会ベース”への転換

“機会”という視点がOSTのキモ。従来は「こんな機能を付けてほしい」「このUIをこう変えてほしい」という形で、解決策ありきの要望が浮かびがち。でも、実際にはユーザーの要望が必ずしも“真の課題”を表しているとは限りません。
OSTでは、先に「ユーザーがどんな課題を抱えているか、どんな価値が必要か」という“機会”を整理し、そのうえでいくつもの解決策をブレストしたり比較検討したりする流れを取ります。
結果、安易に要望を呑むのではなく、本当に大きな価値を生む“機会”に集中できるわけです。

第2章：実践するためのユーザーリサーチ活用

2-1. “機会”を見極めるにはユーザーリサーチが鍵

OSTでいう“機会”を明確化するには、定量・定性両面のデータが重要。

ログ分析: どの機能が多用され、どこで離脱が起きるか把握
ユーザーインタビュー: 表面的な要望の裏にある本質的なニーズや困りごとを発見

僕も累計600人以上のインタビューをこなしてきましたが、ユーザー自身が“何を本当に求めているか”を正確に理解していないケースは多々あります。だからこそインタビューを通じて「いつ・どのシーンで困っているのか」をコンテクストごと深掘りするのが効果的。これによって潜在的な機会を洗い出せます。

2-2. ログ分析とインタビューを組み合わせて立体的に捉える

機会をより確実に捉えるために、ログ分析とインタビューを両方行うのがおすすめ。
たとえばログから、ある機能だけ使われていない事実が見えても、なぜ使われないかは分からない。そこでインタビューで「どんな障壁を感じたか」を聞くと「UIが複雑」「メリットが分からない」という隠れた原因が浮上する。こうして機会をさらに言語化できるわけです。
→ 「本当はユーザーが○○したいと思っているのに、今のプロダクトはまだ対応しきれていない」と発見し、Opportunity欄に追加。そこから初めて解決策を考え始めます。

第3章：解決策を優先度付け＋実験で早期検証

3-1. 解決策アイデアの拡散と絞り込み

機会がリストアップできたら、それぞれに対してどんな解決策があり得るかを自由にブレストします。「こういうUI変更」「この機能追加」「料金プランの見直し」など多様な案が出てくるでしょう。
OSTではこの解決策をどんどん出して、一気に全部実装するのではなく、優先度の高いものから検証する流れ。ここでまた「ログ分析」「簡易PoC」「ユーザーインタビュー」などの手法を使い、小規模実験の結果に応じて次ステップを決めます。
こうすることで機能のリリース前に“これは刺さるか？”をある程度見極められ、要望リストに振り回される無駄が減るのです。

3-2. 小さな実験、失敗の許容

解決策を実装してから失敗が判明するのはコストが大きすぎるので、PoCやベータ版、A/Bテストなど、小さな実験を挟むのがポイントです。

機能のプロトタイプを作ってユーザーに試してもらい、アンケートや観察で反応を測る
限定ユーザーだけに先行公開し、KPIをチェック
こういった実験を回す文化がないと、OSTでいくら機会と解決策を整理しても“実際にどう検証する？”の部分で止まってしまいがちです。社内に「失敗もアリ」という風土を育てるのが、OST運用の成功要因ともいえます。

第4章：チーム全員で視覚的に把握する仕組みづくり

4-1. MiroやMURALでツリーを描く

OSTはツリー型のフレームワークなので、オンラインホワイトボードツールが相性抜群。たとえばMiroを使い、

目的（Outcome）をツリーの根幹
機会（Opportunity）を枝
解決策（Solution）をさらに枝葉
実験（Experiment）を各解決策ごとに付箋で追加
という形で表現すると、ひと目で現状が把握しやすくなります。
ステークホルダーが多いなら、コメントや編集を簡単に共有できるMiroなどを活用し、誰でも最新の全体像を見られるようにするのがベスト。

4-2. 他部門や営業を巻き込む

せっかくPdMがOSTを作っても、プロダクトチームだけが見て満足している状況は危険。営業やCS、マーケなどの部門にも「機会」と「解決策」を見える状態で共有し、“自分たちもアイデアを追加できる”体制を作ると、OSTが活きたドキュメントになります。
たとえば定例ミーティングで毎回ツリーを映して、営業が「この機会は顧客の声が多いです」「こういう解決策も面白いかも」と付箋を追加していく流れ。するとステークホルダーからの要望が“要件リスト”になる前に、まず機会として整理され、議論できるわけです。

4-3. 社内WikiやNotionで進捗をドキュメント化

OSTは生きたツリーなので、アップデートのたびに履歴を残すとよいです。NotionやConfluenceなどで、

現在のOST構造
各解決策の実験結果・学び
をドキュメント化しておけば、メンバーの入れ替えや新プロジェクト参画時にもスムーズに情報を共有できます。

第5章：ケーススタディ――BtoB SaaSでのOST活用イメージ

5-1. 目標（Outcome）は「解約率を20％削減」

例えば、あるBtoBのSaaS企業が「1年後に解約率を20％削減したい」というビジネス目標を掲げているとします。
OSTだと上位に「解約率20％削減」という**目的（Outcome）**があり、その下に「どんな機会（Opportunity）が解約を引き起こしているのか？」を整理します。
ログ分析とユーザーインタビューを行ったところ、

導入後のオンボーディングがわかりにくい
月次レポートの価値を活かしきれてない
サポートが遅い
という3つの大きな機会が浮上したとしましょう。

5-2. Opportunityごとに解決策を並べる

機会1（オンボーディング不十分）に対しては、

新規ユーザー向けガイド機能の追加
専用サポートチームの立ち上げ
“1週間トライアル中に個別メールフォロー”などの施策

と複数の解決策を並べ、Initiativesをブレストします。
機会2（レポート機能の活用不足）には

レポートUIのリデザイン
カスタムテンプレートを簡単に作れるようにする

などの解決策が考えられます。

5-3. 実験で優先度を確認

全解決策をいきなり実行せず、PoCやユーザーへの限定テストを行い、インタビューで反応を確かめるなどの実験を進めます。優先度が高いものから順に小さく試し、結果をOSTにフィードバック。“やはり導入オンボーディングが一番効果的そうだ”とわかればそこに集中リソースを投入。もしレポートリデザインは思ったほど反響がない、という結果なら別の解決策を試す、といった機敏な判断が可能に。

結果、オンボーディングの改良が成功し、解約率が3ヶ月後に5ポイント減少。さらにサポートの体制強化で、顧客の問い合わせ満足度が向上。これにより「解約率20％削減」の目標に着実に近づく――という流れですね。

第6章：よくある失敗例と対処法

6-1. 「機会」を深掘りせず、解決策だけズラズラ並べてしまう

OSTの最大のメリットは、「機会」を軸に考える点。しかし、時間がないからと「機会」を十分に探索せずに、要望リストそのままをツリーに貼るだけで終わらせると本質的な課題抽出が不十分で、結局はタスク消化リストと変わらなくなる。
対策：機会を見つける段階で、ユーザーインタビューを使って「その要望の背景にある課題は？」「何を実現したい？」を徹底的に探る時間をとる。

6-2. OSTを一部の人だけが更新して、チームに周知されない

PdMや一部リーダーだけがOSTを管理し、メンバーが存在すら知らない状況はNG。チーム全体の合意形成がなく、俗人的になりがち。
対策：MiroやNotionなどでチームがいつでも見られる形にし、週次や月次の会議でツリーをチェックする習慣を作る。誰もがコメントやアイデアを追記できる環境を整える。

6-3. 小さい実験を挟まずに大規模リリースする

実験フェーズを省略して本番実装してしまうと、間違った解決策に大きなリソースが浪費されるリスクが高い。
対策：PoCやベータ版、A/Bテストなど、失敗コストを最小化する手段をあらかじめ用意。大きな機能もまずは一部ユーザーに限定公開して反応を測る等、段階的ロールアウトを徹底する。

第7章：今日からできるアクション

要望リストを「機会」に変換
- 現在抱えている機能リストや要望リストを見直し、なぜそれが必要なのか“機会”として言語化してみる。「〇〇を改善するとユーザーは何が嬉しいのか？」を問い直す。
ユーザーインタビュー＋ログ分析で真の課題を把握
- ログから利用頻度や離脱箇所を捉え、インタビューで背景を深堀りする。そこで見えた課題をOSTの機会に追記。
OSTを簡単な形で描き、チームに共有
- Miroなどで「Outcome→Opportunity→Solution→Experiment」のツリーを作成。小さなスコープで試して、定例会議で確認。
1つの機会に対して複数の解決策を検討
- 安直に「機能Aを作ろう」で終わらず、ほかにどんな手段があるか考える。UI変更やサポート体制の強化、価格プラン見直しなど多方面からソリューションを出す。
実験計画を立てて小さく試す
- 選んだ解決策をPoCやβリリースで早期に検証。成功/失敗関係なく、学びをOSTに反映して次のステップを決める。

まとめ：要望が溢れる状況でも真の課題を外さない

機能要望の嵐に翻弄されがちなプロダクトチームにとって、Opportunity Solution Tree（OST）は“要望処理”から“ユーザー課題の本質を解く”姿勢へシフトするための有力なフレームワークです。

目的（Outcome）：ビジネスとして達成したいゴールを設定
機会（Opportunity）：ユーザーリサーチで得た課題やニーズを言語化
解決策（Solution）：複数のアイデアを検討
実験（Experiment）：小さく検証して結果を学びとして蓄積

このプロセスを踏むことで、単なる機能要望リストに振り回されることなく、本当にインパクトの大きい改善を見極められるようになる。ユーザーインタビューやログ分析の結果をツリーに取り入れれば、チーム全員がデータに基づいてディスカッション可能になり、意思決定の質とスピードが上がるんです。

取り組み始めは少し時間がかかるかもしれませんが、OSTを運用し続けることで、プロダクト開発が“一連の学習サイクル”として回り始めます。要望に圧倒されるのではなく、“機会”を捉えて解決策を着実に検証する。そんなプロダクトチームの理想形に近づくために、ぜひOSTを試してみてください。