オポチュニティ・ソリューション・ツリー（OST）とは？｜成果・機会・解決策を一枚の木でつなぐディスカバリー手法

ロードマップには機能の名前がずらりと並んでいます。けれど、その機能がどの顧客のどんな困りごとを解き、どの数字を動かすのかを、チームの全員が同じように説明できるでしょうか。

多くのチームでは、答えが人によって少しずつ違います。PMは売上の話をし、デザイナーは使いやすさの話をし、エンジニアは実装の話をします。

この食い違いを一枚の図で解消しようとするのが、オポチュニティ・ソリューション・ツリー（Opportunity Solution Tree、略してOST）です。この記事では、OSTの成り立ちと構造、作り方の手順、よくある失敗、そして日々の計測との組み合わせ方までを順に解説します。

オポチュニティ・ソリューション・ツリーとは？

OSTは、チームが目指す成果と、それを実現しうる道筋を木の形で見える化するフレームワークです。まずは誰が広めたのか、そして何のための道具なのかを押さえましょう。

Teresa Torresが広めたディスカバリーの地図

OSTは、プロダクトディスカバリーのコーチングを行うProduct Talkの創業者、Teresa Torres氏が2016年ごろからプロダクト開発の文脈で紹介してきた手法です。2021年に出版された著書Continuous Discovery Habitsでは、継続的なディスカバリーの中心となる道具として位置づけられています。

ここでいうディスカバリーとは、作るものを決める前に、それが本当に必要とされているかを確かめる活動のことです。進め方の全体像はプロダクトディスカバリー入門｜作る前に確かめる進め方で解説しているので、あわせて読むと位置づけがつかみやすくなります。

何を解決するための道具なのか

OSTが解こうとしているのは、解決策から先に考えてしまうというチームの癖です。会議ではつい、何を作るかという話から始まりがちです。

しかし解決策から入ると、それがどの課題に効くのか、他に選択肢はなかったのかが見えなくなります。OSTは、成果から課題へ、課題から解決策へと、考える順番そのものを図の構造で強制します。

もう一つの役割は、チームの頭の中をそろえることです。同じ図を見ながら話せば、どの枝をなぜ選んだのかを後から説明できるようになります。

KPIツリーとの違い

形が似ているため、OSTはKPIツリーと混同されがちです。KPIツリーは、大きな指標を掛け算や足し算で分解し、数字どうしの関係を示す図です。

一方のOSTは、指標の下に顧客の困りごとを置く点が違います。数字をどう分解するかではなく、顧客のどんな状態を変えれば数字が動くのかを描くのがOSTの役割です。

両者は対立するものではありません。KPIツリーで根に置く成果を選び、OSTでその成果に効く機会を探す、という使い分けが自然です。

OSTを構成する4つの層

OSTは、上から下へ4つの層で組み立てます。それぞれの層が何を表すのかを、ひとつずつ見ていきます。

根：目指す成果（アウトカム）

木のいちばん上、根にあたるのが成果（アウトカム）です。機能をリリースすることではなく、チームが動かしたい数字を置きます。

Torres氏は、売上や解約率のようなビジネス成果と、チームが直接影響を与えられるプロダクト成果を区別することを勧めています。売上はチームの努力以外の要因でも上下するため、根にはたとえば週あたりの利用継続率のような、行動に近い指標を置くほうが扱いやすくなります。

どの指標を根に据えるかは、指標体系の設計と表裏一体です。北極星指標とKPIツリーの考え方はプロダクト指標の設計｜北極星指標とKPIツリーの作り方を参照してください。

幹と枝：機会（オポチュニティ）

成果の下に並ぶのが機会（オポチュニティ）です。機会とは、顧客のニーズ、不満、願望のうち、解消すれば成果が動くと考えられるものを指します。

ここで大事なのは、機会は顧客の言葉で書くということです。機能の名前ではなく、顧客が困っている状態として表現します。

機会は大きなものから小さなものへと枝分かれします。たとえば、請求書の処理に時間がかかるという大きな機会の下に、承認者がつかまらない、金額の確認が二度手間になる、といった小さな機会がぶら下がります。

顧客が何を片付けたくて製品を使うのかという視点は、機会を見つける手がかりになります。この考え方はジョブ理論（JTBD）とは？で詳しく扱っています。

葉：解決策（ソリューション）と仮説検証

機会の下にぶら下がるのが解決策（ソリューション）です。ひとつの機会に対して、ひとつではなく複数の解決策を並べるのが原則です。

さらに解決策の下には、その解決策が成り立つための前提、つまり仮説を確かめる仮説検証（アサンプションテスト）を置きます。作り切る前に、いちばん危うい前提だけを小さく試すための層です。

4つの層を整理すると、次のようになります。

表の例は説明用の仮のものです。自社の状況に置き換えて読んでください。

OSTの作り方：5つのステップ

構造がわかったところで、実際にOSTを描く手順を見ていきます。いきなり完璧な木を描こうとせず、週単位で育てる前提で始めるのがコツです。

ステップ1：成果をひとつに絞る

最初に、根に置く成果をひとつだけ決めます。複数の成果を同時に追うと、木が何本にも分かれ、どこに集中すべきかが分からなくなるからです。

成果は、チームが四半期程度の期間で動かせる粒度にしましょう。大きすぎる目標は、ビジネス成果とプロダクト成果に分けて、手の届くほうを根に置きます。

ステップ2：インタビューから機会を集める

次に、顧客インタビューから機会を集めます。Torres氏は、PM・デザイナー・エンジニアの3人組、いわゆるプロダクトトリオが、少なくとも週に1回は顧客と話すことを勧めています。

インタビューでは、欲しい機能を聞くのではなく、最近の具体的な出来事を話してもらいます。先週その作業をしたとき、何から始めて、どこで手が止まったか、といった聞き方です。

話の中から出てきた不満や願望を、機会としてカードに書き出していきます。この段階では、整理より量を優先して構いません。

ステップ3：機会を構造化して、ひとつ選ぶ

集めた機会を、親子関係で並べ直します。似たものをまとめ、大きな機会の下に小さな機会をぶら下げると、木の骨格ができてきます。

そのうえで、いま取り組む対象の機会をひとつ選びます。選ぶ基準は、影響を受ける顧客の多さ、成果への効きやすさ、自社が取り組む理由があるかどうか、などです。

候補の比べ方には、スコアリングの手法が役立ちます。数字で優先順位をつける方法は開発の優先順位づけ｜RICEとICEをデータで運用するで解説しています。

ステップ4：解決策を複数出して比べる

対象の機会が決まったら、解決策を複数出します。ひとつ目に思いついた案にすぐ飛びつかず、たとえば3つ程度の案を並べて比較しながら選ぶのがポイントです。

案が一つしかないと、その案が良いか悪いかしか議論できません。複数あれば、どちらのほうがより良いかという比較の議論ができ、判断の質が上がります。

ステップ5：仮説を洗い出して小さく試す

最後に、有力な解決策ごとに、それが成り立つための前提を書き出します。ユーザーはその画面に気づくか、使いたいと思うか、技術的に作れるか、事業として成り立つか、といった観点です。

そのうち、外れたら致命的で、まだ確かめていない前提から順に小さく試します。試作画面での操作テストや、偽の入口を置いてクリック率を見るテストなどが典型です。

小さな木の例を、テキストで書くと次のようになります。

成果：登録後7日以内の再訪率を上げる
├─ 機会：初期設定で何をすべきか分からない
│   ├─ 解決策A：設定チェックリストを表示する
│   │   └─ 検証：試作画面で5人に操作してもらう
│   ├─ 解決策B：サンプルデータ入りで始められるようにする
│   └─ 解決策C：初回に短い案内メールを送る
└─ 機会：チームメンバーを招待する方法が分からない
    └─ （まだ解決策は検討していない）

これも説明用の仮の例です。実際の木は、インタビューを重ねるほど枝が増えたり、剪定されたりしていきます。

よくある失敗と、その避け方

OSTは構造が単純なぶん、描き方を少し間違えるだけで効果が薄れます。ここでは現場でよく見られる失敗のパターンを整理します。

機会の欄に解決策を書いてしまう

もっとも多いのが、機会の層に解決策が紛れ込む失敗です。ダッシュボードが欲しい、CSV出力が必要、といった書き方は、実は顧客が考えた解決策です。

見分け方は、書いた文を顧客の状態に言い換えられるかどうかです。CSV出力が欲しいの背後に、上司への報告資料を作るのに手間がかかるという機会があれば、そちらを書きます。

成果が大きすぎる、または出力になっている

根に売上や時価総額のような大きすぎる目標を置くと、どの機会がそれに効くのかを誰も判断できなくなります。逆に、新機能をリリースする、のような出力（アウトプット）を根に置くのもよくある誤りです。

出力を根に置くと、木は最初から一本の解決策に向かって描かれることになります。それではOSTを使う意味がありません。

一度描いて終わりにしてしまう

OSTは計画書ではなく、学習の記録です。仮説検証で前提が外れたら、解決策を差し替えるか、別の機会を選び直すか、場合によっては成果そのものを見直します。

木を更新しないまま数か月たつと、図は現実と乖離し、誰も見なくなります。週に一度、インタビューや検証の結果を反映する時間を決めておくとよいでしょう。

機会を広げすぎて選べなくなる

インタビューを重ねるほど、機会のカードは増えていきます。すべてを同時に追いかけようとすると、どの枝も中途半端なまま時間だけが過ぎてしまいます。

木の全体は広く描いてかまいませんが、同時に取り組む機会はひとつに絞るのが原則です。選ばなかった枝は捨てるのではなく、次の候補として木に残しておけば、後で見直すときの材料になります。

失敗のパターンと対処を、比較表にまとめておきます。

定量データでOSTを育てる

OSTの材料はインタビューが中心ですが、定性の情報だけでは機会の大きさを見誤ることがあります。ここでは、行動データとOSTをどう組み合わせるかを考えます。

機会の大きさを数字で見積もる

インタビューで印象に残った困りごとが、実は一部の顧客にしか起きていないこともあります。そこで、機会ごとにどれくらいの人が影響を受けているかを行動データで確かめます。

たとえば、初期設定で何をすべきか分からないという機会なら、設定画面に入ったものの途中で離脱した人の割合を見ます。ファネルの離脱率が高ければ、その機会は大きいと判断できます。

検証結果を成果の指標で確かめる

解決策を出したあとは、根に置いた成果の指標が実際に動いたかを確認します。仮説検証の段階では小さなテストで十分ですが、リリース後はA/Bテストなどで成果への効果を比べるのが理想です。

このとき、指標の定義がぶれていると、効果があったのかどうか判断できません。成果の数字は、チーム内で定義をそろえたうえで、毎週同じ条件で見られるようにしておきましょう。

一人の行動から機会を見つける

集計値だけでは、なぜ離脱したのかまでは分かりません。個々の訪問者がどの順番でページを見て、どこで止まったのかを時系列で追うと、インタビューでは出てこなかった機会が見つかることがあります。

たとえばMonaLensのように、Cookieや個人情報に頼らずにファネル分析や訪問者ひとりの行動の追跡ができるツールを使えば、インタビュー対象を選ぶ前の当たりづけにも使えます。定量で場所を特定し、定性で理由を聞くという往復が、OSTを太く育てます。

関係者への説明にも使う

OSTは、チームの外に向けた説明資料としても役に立ちます。なぜこの機能を作るのか、なぜあの要望を後回しにしたのかを、成果と機会のつながりで示せるからです。

要望を出した営業や経営に対しても、木のどの枝で検討しているのかを見せれば、却下ではなく順番の問題だと伝えやすくなります。

まとめ：解決策の前に、木を一本描く

オポチュニティ・ソリューション・ツリーは、成果、機会、解決策、仮説検証の4層で、チームの考えをつなぐ地図です。解決策から考える癖を、図の構造によって矯正してくれます。

使い方の要点は、成果をひとつに絞ること、機会は顧客の言葉で書くこと、解決策は複数並べて比べること、そして木を週単位で更新し続けることです。完璧な木を描く必要はありません。

次の企画会議の前に、ホワイトボードに成果をひとつ書き、その下に最近のインタビューで聞いた困りごとを3つ並べてみてはいかがでしょうか。解決策の議論が、いつもより少し落ち着いたものになるはずです。