企画や業務改善を考えるとき、つい「何を作るか」「どんな施策を打つか」から話し始めてしまうことはないでしょうか。新しい機能を入れる、キャンペーンを出す、資料を作り直す。どれも前向きな案ではありますが、そもそも何を解決したいのかが曖昧なままだと、良さそうな案が並ぶだけで判断が難しくなります。
オポチュニティ・ソリューション・ツリー（Opportunity Solution Tree）は、そうした「解決策から考えてしまう」状態を避けるために役立つフレームワークです。目指す成果を置き、その下に顧客や利用者の困りごと、欲求、行動上のつまずきを整理し、そこから解決策と検証方法へつなげていきます。
この記事では、オポチュニティ・ソリューション・ツリーの基本と使い方を、初心者にもわかりやすい形で解説します。プロダクト開発だけでなく、営業改善、社内業務、資料作成、顧客対応の見直しにも応用できる考え方として整理します。
この記事を読むと次のことがわかります
オポチュニティ・ソリューション・ツリーは、成果から施策までをつなぐ地図
オポチュニティ・ソリューション・ツリーは、プロダクトディスカバリーの文脈でよく使われる整理法です。日本語にすると「機会と解決策のツリー」といった意味になります。少し堅く聞こえるかもしれませんが、考え方自体はとても実務的です。
中心にあるのは、成果、機会、解決策、検証を分けて考えることです。成果とは、最終的に良くしたい状態です。機会とは、その成果につながる顧客の困りごとや欲求です。解決策とは、機会に対して取りうる案です。検証とは、その案が本当に良さそうかを確かめる小さな実験です。
この順番で考えると、いきなり施策を出すよりも、なぜその施策が必要なのかを説明しやすくなります。会議で案がたくさん出るけれど決めきれない、という場面でも使いやすいフレームワークです。
たとえば、社内の問い合わせ対応を改善したい場合でも、最初からチャットボットやFAQを作ると決める必要はありません。まず「問い合わせ対応にかかる時間を減らす」という成果を置き、その下に「必要な情報がどこにあるかわからない」「申請ルールが部署ごとに違って見える」「過去の回答を探せない」といったオポチュニティを並べます。すると、FAQが必要なのか、申請画面の文言を直すべきなのか、検索しやすいナレッジを整えるべきなのかを比べやすくなります。
最初に置くのは、作りたいものではなく成果
オポチュニティ・ソリューション・ツリーでは、最初に「何を作るか」ではなく「どんな成果を目指すか」を置きます。たとえば、問い合わせ件数を減らしたい、契約率を上げたい、初回利用後の離脱を減らしたい、といった形です。
成果が曖昧なまま施策を考えると、案の良し悪しを判断しづらくなります。良さそうなアイデアでも、成果に近づくかどうかが見えなければ、優先順位を決められません。
オポチュニティは、顧客や利用者側のつまずきとして見る
オポチュニティは、単なる課題リストではありません。顧客や利用者が何に困っているのか、何をしたいのにできていないのか、どんな不安や迷いを持っているのかを表します。
たとえば、資料請求後の商談率を上げたい場合、営業資料を増やす前に、顧客が比較ポイントを理解できていない、導入後のイメージを持てていない、社内説明に不安がある、といった機会を探します。
ソリューションは、オポチュニティにぶら下げて考える
解決策は、顧客のつまずきに対して考えます。そうすることで、施策が目的から離れにくくなります。動画を作る、チェックリストを作る、説明会を開くといった案も、どのオポチュニティに対応しているのかが見えていれば判断しやすくなります。
逆に、どのオポチュニティにもつながらないソリューションは、思いつきの案かもしれません。悪い案とは限りませんが、優先して取り組む理由は弱くなります。
テストは、大きく作る前に確かめるために置く
オポチュニティ・ソリューション・ツリーでは、解決策の下に検証を置きます。これは、いきなり本格的に作る前に、前提が合っているかを小さく確かめるためです。
たとえば、新しい説明資料を作る前に、既存資料の一部を変えて数件の商談で反応を見る。FAQページを作る前に、問い合わせ内容を分類して本当に同じ質問が多いか見る。こうした小さな検証が、無駄な作り込みを減らしてくれます。
解決策から考えると、なぜ企画がずれやすいのか
ビジネスの現場では、解決策から話が始まることがよくあります。チャットボットを入れよう、セミナーを開こう、料金表を変えよう、マニュアルを作ろう。具体的な案があると話は進んでいるように感じますが、その案が何に対する解決策なのかが曖昧なこともあります。
オポチュニティ・ソリューション・ツリーが役立つのは、この曖昧さを見える形にできるからです。施策の前に、成果と機会を置くことで、案を出す前の考え漏れに気づきやすくなります。
このフレームワークのよいところは、案を否定するためではなく、案をより良い場所に置き直せるところです。誰かが出したアイデアに対して「それは違う」と言うのではなく、「これはどのオポチュニティに対応しているだろう」と問い直せます。会議の雰囲気を壊さずに、考える順番を整えられるのは実務上かなり使いやすい点です。
良さそうな案ほど、前提を確認しにくい
会議で魅力的な案が出ると、その案をどう実行するかに意識が向きやすくなります。たしかに前向きな空気は生まれますが、顧客が本当にその解決を求めているのかは別の問題です。
たとえば、問い合わせ削減のためにFAQを増やす案が出たとします。しかし、問い合わせの原因が情報不足ではなく、申し込み画面の表現がわかりにくいことにあるなら、FAQを増やしても効果は限定的かもしれません。
課題と解決策が一対一で結びつくとは限らない
一つの課題に対して、解決策は複数あります。逆に、一つの解決策が複数の課題に効きそうに見えることもあります。この関係を頭の中だけで扱うと、どの案を選ぶべきかがわかりにくくなります。
ツリーにすると、ひとつのオポチュニティに複数のソリューションをぶら下げられます。比較できる状態になるため、案の数が多くても整理しやすくなります。
チーム内で問題の見え方が違うことに気づける
営業、開発、カスタマーサポート、管理部門では、同じ状況を見ていても気づくことが違います。営業は顧客の迷いを見ており、サポートは導入後のつまずきを見ているかもしれません。
オポチュニティ・ソリューション・ツリーを一緒に作ると、それぞれが見ているオポチュニティを持ち寄れます。誰か一人の思い込みではなく、複数の視点で問題を整理できます。
施策の優先順位を説明しやすくなる
施策を選ぶとき、実行しやすさだけで決めると、本当に重要な問題が後回しになることがあります。オポチュニティ・ソリューション・ツリーでは、どのオポチュニティが成果に近いか、どのソリューションが小さく試せるかを見ながら優先順位を決められます。
上司や関係者に説明するときも、「この施策をやりたい」ではなく「このオポチュニティが成果に近く、まずこのソリューションを小さく試したい」と話せます。判断の流れが見えるため、納得感を得やすくなります。
オポチュニティ・ソリューション・ツリーの作り方
オポチュニティ・ソリューション・ツリーは、きれいな図を作ることが目的ではありません。大切なのは、成果から機会、解決策、検証へと考えをつなげることです。最初は紙やホワイトボード、付箋、オンラインボードなど、使いやすい道具で十分です。
ここでは、業務改善や企画の場面でも使いやすいように、4つのステップで整理します。難しい専門用語を覚えるより、この順番で考えることを意識してみてください。
作るときは、正確なツリーにこだわりすぎないことも大切です。最初からきれいに分類しようとすると、手が止まってしまいます。まずは思いつくオポチュニティを付箋のように出し、似ているものをまとめ、あとから階層を整えるくらいで十分です。整理する前に材料を出すほうが、現場の感覚を拾いやすくなります。
1. 目指す成果を一つに絞る
最初に、今回の検討で良くしたい成果を一つ決めます。問い合わせ件数を減らす、申込率を上げる、会議後の対応漏れを減らす、研修後の実践率を上げるなど、できるだけ具体的にします。
成果が複数ある場合は、ツリーも分けたほうが扱いやすくなります。ひとつのツリーに多くの成果を入れると、オポチュニティもソリューションも広がりすぎてしまいます。
2. 顧客や利用者のオポチュニティを書き出す
次に、成果を妨げている利用者側のつまずきを書き出します。ここでは、社内業務なら社員、営業なら見込み客、サービスならユーザーの視点に立ちます。
ポイントは、解決策を書かないことです。「説明動画を作る」ではなく「導入後の操作イメージが持てない」と書きます。「チェックリストを作る」ではなく「確認すべき項目が毎回ばらつく」と書きます。
3. オポチュニティごとにソリューションを出す
オポチュニティが見えたら、それぞれに対して解決策を出します。この段階では、案を一つに絞りすぎなくても構いません。同じオポチュニティに対して、複数のソリューションを並べて比較できる状態を作ります。
たとえば「導入後の操作イメージが持てない」というオポチュニティなら、短いデモ動画、導入事例、初回設定ガイド、無料相談会などが考えられます。どれが最もよいかは、次の検証で見ていきます。
4. 小さなテストで前提を確かめる
最後に、ソリューションを本格実装する前に、どんな前提を確かめるかを考えます。顧客が本当にその情報を求めているのか、理解しやすい形式なのか、行動につながるのかを小さく確認します。
テストは大がかりである必要はありません。5人に見せて反応を聞く、既存ページに小さな導線を追加してクリックを見る、営業資料の一部だけ変えて商談で試す。こうした小さな確認で、施策の精度は上げられます。
日本の職場で使うときの実践ポイント
オポチュニティ・ソリューション・ツリーは、プロダクト開発の文脈で語られることが多いフレームワークですが、一般的な職場でも十分に使えます。むしろ、施策や改善案が先に出やすい職場ほど、考えを整理する道具として役立つはずです。
ただし、いきなり大きな図を作ろうとすると重く感じられます。最初は小さなテーマで、30分ほど使って試すくらいがちょうどよいでしょう。
また、オポチュニティ・ソリューション・ツリーは一度作って終わりではありません。顧客の反応、営業現場の声、問い合わせログ、テスト結果が増えるたびに更新していくものです。更新されるツリーは、チームの学習記録にもなります。なぜこの施策を選んだのか、どの前提が外れたのかを後から振り返りやすくなるでしょう。
まずは一つの会議や企画で試す
最初から全社的な戦略に使おうとすると、関係者も多くなり、整理が大変になります。まずは一つの企画、一つの業務改善、一つの顧客対応の見直しで試すのがおすすめです。
たとえば、資料請求後の商談化率を上げる、社内問い合わせを減らす、研修後の実践率を上げるなど、成果が比較的見えやすいテーマが向いています。
オポチュニティは事実と仮説を分けて扱う
ツリーに書いたオポチュニティが、すべて事実とは限りません。顧客が本当に困っていることもあれば、チームがそう思っているだけの仮説もあります。
そのため、オポチュニティには根拠を添えるとよいでしょう。問い合わせログに多い、営業でよく聞く、アンケートで出ている、まだ仮説である、といったメモがあると、検証の優先順位を決めやすくなります。
解決策の数を競わない
アイデア出しの場では、解決策の数が多いほど良いように見えることがあります。もちろん選択肢は大切ですが、数だけ増えても、オポチュニティとの関係が薄ければ判断は難しくなります。
大切なのは、どのオポチュニティに対するソリューションなのかがわかることです。少ない案でも、成果とのつながりが明確なら十分に検討する価値があります。
小さく試した結果をツリーに戻す
テストを実施したら、その結果をツリーに戻します。うまくいったならソリューションを深める。反応が弱ければ、別のソリューションを試す。そもそもオポチュニティの見立てが違ったなら、機会の整理に戻ります。
この戻り方があることで、失敗した施策も学びになります。単にうまくいかなかったで終わらず、どの前提が違ったのかをチームで確認できます。
まとめ
オポチュニティ・ソリューション・ツリーは、成果、機会、解決策、検証をつなげて考えるためのフレームワークです。いきなり施策を考えるのではなく、顧客や利用者のつまずきを整理してから解決策を出すことで、企画のズレを減らしやすくなります。
特に、良さそうなアイデアが多くて選べないとき、施策の優先順位を説明しづらいとき、チーム内で問題の見え方が違うときに役立ちます。図として見える形にすると、議論が「どの案が好きか」ではなく「どのオポチュニティに効きそうか」に変わります。
日本ではまだ、一般的なビジネスフレームワークとして広く浸透しているとは言いにくいかもしれません。ただ、顧客理解、企画、業務改善、AI活用の検討など、解決策が先走りやすいテーマではかなり使いやすい考え方です。
最初から完璧なツリーを作る必要はありません。まずは一つの成果を決め、利用者のつまずきを書き出し、解決策と小さな検証を並べるところから始めてみてください。施策を急がず、良い問いを見つけるための道具として使うのがポイントです。
今回のポイント
