新規事業開発やプロダクト開発の現場では、「どこの誰の、いかなる課題を解決するのか」を明確にしないまま、機能要望やアイデアだけが先に積み上がってしまうことが少なくありません。顧客インタビューやユーザーリサーチを実施していても、その発見が意思決定にうまくつながらず、結局は思いつきや社内事情で優先順位が決まってしまう――そんな悩みを抱えている方も多いのではないでしょうか。
Opportunity Solution Tree（OST）／オポチュニティー・ソリューション・ツリーは、そのような課題を整理し、顧客の声と解決策とのつながりを見える化するための強力なツールです。単なる発想法でも、単なる図解フレームでもありません。顧客が抱える事業機会を起点に、どの解決策が有望なのか、どの前提仮説を優先して検証すべきなのかを、チームで筋よく議論するための土台になります。
この記事では、OSTの基本的な考え方から、Continuous Discovery（継続的市場探索）との関係、実務での造り方と運用方法、導入時に陥りやすい注意点、さらに具体的な事例までを順を追って解説します。読み終わる頃には、顧客の声と機能要望が混ざってしまう状態から抜け出し、市場価値を伴う（＝ちゃんと売れる）プロダクト開発を前に進めるための具体的な視点が見えてくるはずです。
OST／Opportunity Solution Tree（オポチュニティ・ソリューション・ツリー）とは何か？
テレサ・トーレスと Continuous Discovery（コンティニュアス・ディスカバリー／継続的市場探索）
いまや、世界の現代プロダクトマネジメント界のスーパースターとなった、Teresa Torres（テレサ・トーレス）氏は、アジャイル開発でSaaSを開発している現場で、デリバリーすれどもすれども、市場価値が一向に積みあがらない矛盾を目撃しました。
そこで彼女は Continuous Discovery（直訳：継続的発見、この記事では「継続的市場探索」と、両利きの経営的に意訳しました）という考え方を提唱し、いかなる機能であっても、造り始める前に、徹底的に顧客を理解し、顧客にとってのバリューをより提供できるよう、ソフトウェアを拡張し続けることをプロダクト開発の中心に据えました。継続的市場探索とは、開発の前や途中に一度だけ調査をするのではなく、日常的に顧客理解と検証を回し続けるプロセスのことです。顧客インタビューや小さな検証を繰り返しながら、「本当に我々は価値があるのか？」を確かめ続けます。
では、なぜ「継続的市場探索」が必要になったのか。この考え方が、少なくても米国ではすでに新しいデファクトスタンダードと化した背景には、プロダクト開発現場の「あるあるな失敗」があります。
問題の一つは、「アジャイルの体裁をした」事実上のウォーターフォールの失敗です。本来は、顧客にぴったりくっついて、学習しながら開発を進めていくはずのアジャイル開発が、実態としてはいつの間にか、顧客の言うことなんてろくすっぽ聞かずに、造ることだけに集中し、自分たち本位で作成した要件を実現するためだけに開発を進めるだけの状態になってしまうケースです。結果、市場価値の検証をせずに造るため、誰も欲しくないものをリリースして炎上する、という事例が後を絶たなくなりました。
もう一つ大きな問題は、組織の分断です。「新製品開発はプロダクト側の仕事」「顧客理解や市場はマーケの仕事」と切り分けてしまい、顧客理解がチームの外に追い出される構造です。この状態では、開発する側が顧客を知らないまま意思決定をしてしまいます。こうした反省から、「開発チーム自身が継続的に顧客と向き合うべきだ」という考えが強く求められるようになりました。それがテレサの体系化した、継続的市場探索です。
私はこの考え方は、ソフトウェアばかりでなく、製造業に是非とも当てはめるべき考え方だと主張します。なぜなら、アジャイル開発をやっている！と自称なさっている製造業の中には、顧客から口頭で事実上のダメ出しをあらかじめ食らっているにもかかわらず、そのまま猪突猛進して最終的に売れずに炎上している、つまり、仕様の改良＝イテレーションは申し訳程度にしても、ピボットすなわち企画自体の破棄は決して実行しない企業が、数多くあるようにお見受けするからです。
【関連記事】Continuous Discovery Habitsの実践ガイド：プロダクトの市場価値を最大化する継続的市場探索の方法
いかに Continuous Discovery（継続的市場探索）の「進捗管理」を行うのか？
顧客とインタラクティブにやりとりしていなければ、製品開発の進捗が出ていても、市場価値の開発の進捗が出ているとは言えません。
アジャイルで開発したはずのソフトウェアなりハードウェアなりが、最終的に出荷され、値段をつけられて売られる段階になってさっぱり売れないのであれば、開発手法がアジャイルであろうが、ウォーターフォールであろうが、開発期間中、市場価値はまったく生み出されていなかったと考えるしかありませんよね？
したがって、Continuous Discovery/継続的市場探索では、この 市場価値の創造の進捗を、どうしても測る必要が出てきます。
ウォーターフォール型のプロジェクトで進捗を測ろうとすると、ガントチャートを使いたくなるものです。一方で、アジャイル ≒ 今日日はスクラムで進捗を測るときは、皆さんバックログを使います。「アジャイルで開発していても、最終的に顧客のまったく喜ばない製品ができあがることはままある」という欠点は、バックログの使い方に引きつけて言うと、こういうことです。
「このバックログに含まれるすべてのイシュー、ユーザーストーリーは無効になりました。
なぜならば昨日、顧客に聞いたところ、それらはまったく欲しくないと言われたからです。
開発チーム、ごめんなさい」
などというメタレベルのユーザーストーリーをバックログに放り込むプロダクトオーナーが、事実上存在しない、ということなのです。
では、継続的市場探索では、いったい何を用いて進捗を測るべきでしょうか。
そのツールとして、テレサ・トーレスが発案したのが、Opportunity Solution Tree／オポチュニティ・ソリューション・ツリー（事業機会と解決策を木構造で整理する図表）というツールです。OST は、継続的市場探索で発見し、創り出し、確かめていくアウトカム（大目的）、オポチュニティ（モヤモヤ）、ソリューションを見える化するためのツールです。
Outcome（大目的）／Opportunity（事業機会）／Solution（ソリューション）／Experiment（テスト）
このツリーは、以下のような構造になっています。
レベル1：Outcome／アウトカム（大目的）
テレサは、アジャイルが失敗するのは、それが構築するものがハードウェアだろうがソフトウェアだろうが、開発の本当の目的を見失っているからだ、と指摘しました。開発者は皆、開発チームは皆、開発することそのものを目的に動いてしまう。そのことが致命的な誤りとなって、いざ値段をつけたあとに表面化するわけです。だからテレサは、このツリーのトップレベルに、必ずアウトカムを持ってくるよう奨めています。
彼女の著書『Continuous Discovery Habits』では、この「アウトカム」を、単なるスローガンとして掲げるのではなく、チームが日々の意思決定をするときの、最上位の判断基準として置くべきだと、繰り返し説かれています。つまり、何を造るか？ より先に、どんな行動変化を顧客側に起こしたいのか？ を明確にしなければならない、ということです。ここが曖昧なままでは、開発チームは、どうしても「今月は何を造ったか」「どれだけ実装したか」「どれだけチケットを消化したか」に引っ張られてしまいます。しかしそれでは、顧客価値の創造がどれだけ実際に進捗したのか、計測することができません。
ハードウエアの開発であっても、「造ることを目的にして」開発を進めて大失敗を喫するパターンは、モトローラの衛星電話イリジウムをはじめとして、枚挙にいとまがありません。
【関連記事】プロダクトアウト「イリジウム」はなぜ失敗したのか？
レベル2：Opportunity／オポチュニティ（事業機会、顧客の「モヤモヤ」）
アウトカムの下には、顧客が抱えている複数の困りごと、欲求、不満、ためらい、未充足のニーズ……と、もろもろ、顧客が考えているモヤモヤがぶら下がります。
ここで重要なのは、実際にはほとんどの場合、オポチュニティ＝モヤモヤは階層構造になっている、ということです。大きなモヤモヤの下に、より具体的な下位のモヤモヤがぶら下がる。そういう構造として捉えないと、現実の顧客理解はできません。
つまりチームは、オポチュニティを一枚の平面的な箇条書きとして並べるのではなく、大きな問題領域から小さな問題領域へと、木構造で整理していく必要があります。この構造を取ることによって初めて、我々はいま、どの大きな事業機会を重視しているのか、その中の、どの下位の事業機会を優先するのか、を切り分けて議論できるようになります。
レベル3：Solution／ソリューション（解決策）
最下位レベルのオポチュニティの下に、複数のソリューション案を並べます。ここで重要なのは、オポチュニティレベルがびっしり埋まって、顧客にあたって、その念入りな検証を済ませてから、解決策を「おっとり刀」で発案すること、そのときに、必ず複数の解決策を考えることです。
開発現場では、一度ソリューションが決まった瞬間に、それが既定路線になってしまいがちです。その結果、本当はもっと筋のいい解決策があるかもしれないのに、チーム全体が、決まった案を予定どおり造ることに重点を置き始める、という、せっかくOST を導入したのに、意味がなくなってしまう流れができかねません。
しかし、どんな状況であっても上梓されるまでは、ソリューションは厳しく検証すべき仮説、仮の案にしかすぎません。しかも一つではなく、複数並べて比較検討されるべき仮説です。つまり、オポチュニティ・ソリューション・ツリーは、「正解の機能」を一つ選んでそこへ全てを流し入れるための道具ではなく、顧客が抱えるいくつかのモヤモヤを並べておいて、どのモヤモヤをどう解消するのが最も筋がよいのかを、複数案をお互いに戦わせて考え、検証するための道具なのです。
レベル4：Experiment／テスト
ここで重要なのは、継続的探索では、ソリューションそのものをいきなり検証するのではない、という点です。
テレサが強調しているのは、私たちが検証すべきなのはソリューションそのものではなく、そのソリューションが成り立つと私たちが信じている根拠にあたる、Assumption／アサンプション（直訳は想定、ここでは前提仮説）だ、ということです。
たとえば、ある機能案を思いついたとします。
このとき本当に検証すべきなのは、
- そもそも顧客のモヤモヤは完全に解消するのか？
- もし解消するとして、顧客の RoI はいくつか？
- 顧客にとり、この機能の魅力は、すぐにピンとくるのか？
- この案は事業として成り立つのか？
- 技術的・法務的・運用的に実現可能なのか？
といった、ソリューションの背後に隠れている、それを成立させている Assumptions／前提仮説群です。
OSTの作り方と運用
Step 1 事業アウトカムと製品アウトカムを定義する
最初に決めるべきなのは、「何を造るか」ではなく、「どんな変化を起こしたいのか」です。
ここは私のオリジナルな補足ですが、実務では、このアウトカムも、二層に分けたほうが混乱しません。すなわち、ビジネス・アウトカム と プロダクト・アウトカム です。今までの導入経験から、驚くほど高い確率でトップに「この製品を売ること」という、アウトカムになっていないアウトカムを素で書いてくる開発チームが多いことが分かっています。しかしそれは、事業として達成したい成果と、製品が顧客の行動にもたらす変化とが、ごちゃ混ぜになっている状態であり、かつ、「製品が顧客の行動にもたらす変化」が一意には定義されていない状態です。
「継続率を上げる」「新規市場での売上を立てる」はビジネス・アウトカムです。
一方で、「顧客が初回利用で価値を実感できるようになる」「顧客が導入時の不安を減らせる」はプロダクト・アウトカムです。
この二層を分けておかないと、売上を増やしたいという経営目標と、顧客にどんな前進を起こしたいのかという製品上の目標が混線し、結局また「とにかくこの製品を売れ」という、従来型の発想に逆戻りしてしまいます。
この二つを分けておかないと、「この製品を売ること」が最上位に来てしまい、OST が単なる稟議用の飾りになってしまいます。事業アウトカムは北極星として必要ですが、日々の探索の起点は、製品アウトカムのほうに置いたほうが回りやすいことが多いです。
Step 2 取材・顧客調査からオポチュニティを見つける
ここで初めて、顧客インタビュー、観察、営業同行、問い合わせ分析、解約理由の読み込みなどを使って、顧客のモヤモヤを拾いにいきます。ポイントは、「何を造ればよいですか？」と聞くことではありません。どこで立ち止まり、何に不安を感じ、どこで諦め、何を面倒だと思っているのかを集めることです。オポチュニティとは、顧客の脳内にある“未解消の何か”です。
Step 3 オポチュニティを2〜3階層で整理する
拾ってきたモヤモヤを、平面的な箇条書きのままにしないこと。大きな問題領域から、より具体的な下位の事業機会へと枝分かれさせます。
- （ルートオポチュニティ）導入の手間が大きい
- （ブランチオポチュニティ）長期のコスパが読めない
- （ブランチオポチュニティ）社内承認を通しにくい
- （ブランチオポチュニティ）初期設定が難しい
このようなツリー構造にすると、「我々はいま、どの大きな問題を見ているのか」「その中のどの枝を優先して調べているのか」が見えるようになります。
Step 4 ソリューションを複数発想する
オポチュニティが見えてきたら、ようやく解決策を考えます。
ただし、ここで一案だけ出して終わらせないこと。
一個の案に惚れ込んだ瞬間に、OST の価値は急速に失われます。複数案を並べて比較するからこそ、「本当にこの筋がよいのか？」を問い続けられます。ここでの仕事は、正解を見つけることではなく、より筋のよい仮説を戦わせることです。
Step 5 アサンプションを網羅的に発案し、小さくテストする
オポチュニティ・ソリューション・ツリーの「テスト段階」で行うべきことは、「このソリューションを、たとえそれが MVP であっても、丸ごと市場に出してみること」ではありません。実際に行うのは、
- このソリューションが成り立つために、絶対に正しくなければならない前提は何かを網羅的に特定していく。
- その中でも最もリスキーな、もし間違っていたらサービスが成り立たない前提仮説から順に、小さく、素早く、低コストで検証していくことです。
ここでいうExperiment／テストとは、要するに、MVPの概念の巧みな言いかえです。私は、「ソリューションでなくアサンプションをテストする」というこの考え方に接したとき、テレサは、MVP という概念に本来的に付きまとう誤解をうまく回避したな、と思いました。
MVP は字面からして「最も簡素なプロトタイプ」と誤解され、アジャイルで造ったはずのサービスがどんどんこけていく奇妙な現象の一因になっていますが、エリック・リース自身は、口を酸っぱくして「MVPは顧客価値を測るための道具です！ 安く短期間でつくれればなんでもいいってもんじゃない！」と主張しているものの、そもそも MVProduct と名付けてしまったリース氏側の責任も正直あると思います。
例えば、ある化成メーカーが実験を重ねた結果、全く新しい物質を造りだし、その物性表をペーパープロトタイプとしてテストにかけたとします。この物性表、でも、「もし解消するとして、顧客の RoI はいくつか？」というアサンプションを検証する道具としては、おそらく不十分です。なぜなら、物性表には通常、「最終的に量産したらお値段はおいくらになります」という見積もりが入っていないからです。その結果どうなるかというと、サンプルワークまではお客様の評判も上々ですが、実際に値段をつけたら誰も買わない……ということになりかねません。
Step 6 毎週、顧客と話しながら更新していく
OST は、一回描いて壁に貼って終わりの図ではありません。
毎週、あるいは隔週で顧客にあたり、学んだことに応じて枝を足し、枝を切り、優先順位を変え、前提仮説の検証結果を書き戻していく。そうやって初めて、OST は「顧客理解の地図」になります。実際、継続的探索をうまく回しているチームは、毎週の顧客接点や定期的な実験を回しながら、ツリーを更新し続けています。
OSTのメリット
フォルスポジティブ（偽陽性、自分の事業企画にとり都合の良い解釈をしてしまうこと）を減らせる
私は、このオポチュニティとして複数の候補を挙げ、それが下に枝分かれしていることが、OST および継続的探索のメリットがいちばん大きい部分だと思っています。なぜなら、必ず複数の事業機会＝モヤモヤを意識しておけば、顧客が「そんなニーズなんか全くない」と仮説を容赦なく全否定してきても、さしてショックではないからです。したがって、確証バイアスでフォルスポジティブに陥る弊害は免れます。
使われない機能を減らせる
OST の強みは、「造る前に、顧客価値を問い直せること」です。
顧客のモヤモヤと解決策が一本の線でつながっていなければ、その機能は危ない。逆に、なぜその機能を実装すべきと考えているのかが明確に説明できるなら、無駄な機能の開発は、原理的には、ほぼなくなることになります。
優先順位をつけやすい
「どの機能が好きか」ではなく、「どの事業機会のもやもやを解消するのが、いちばん目的達成のためにインパクトが大きいのか？」で議論できるようになります。
これは、プロダクトの開発チームと社内のほかのステークホルダーとの会話を著しく生産的にします。「本当にこんなものが売れるのか？」と稟議のときに問い詰められても、もともと顧客との会話ベースのアイデアなので、即座にエビデンスを出すことができ、顧客価値を生み出すという点で最も効果的な形で開発を進めることができます。
顧客理解に沿って自然にアイデアを出せる
OSTを使用して継続的探索を続けていくと、アイデアは“ひねり出すもの”ではなく、“顧客との共創によって勝手にポンポン出てくるもの”になります。これは実際に継続的探索を実践してみないとぴんと来ないところですが、顧客と継続的に話し続けていると、自分はアイデアパーソンではないと思っている方でも、どんどんアイデアを出せるようになるものなのです。MFTでいう Function は、やはり技術部門でなければ思いつかないところがあるので、余計にそうなります。弊社が継続的探索とOST導入を支援したクライアント様からも、「社内で議論していたのでは全く出てこないアイデアを企画書に盛り込めた」と、称賛のフィードバックをいただいております。
逆に、顧客理解が浅いと、ソリューションは思いつきの品評会になり、品評のさいの基準のあいまいさが不毛なやり取りになるのは、あなたもご存じの通りです。
【関連記事】MFTフレームワークとは？新規事業に役立つ活用手順や事例を解説！
チームの認識をそろえやすい
OST は、顧客理解、優先順位、解決策、検証状況を一枚で見せられるので、チームの共通言語になりやすいです。実際に導入したチームからは、「目的を見失わなくなった」「社内のステークホルダーとの会話がしやすくなった」という声が出ています。
導入時の注意点
曖昧なアウトカムから始めない
「この製品を売ること」「DX を進めること」では、粗すぎます。
それはアウトカムというよりスローガンです。顧客のどんな行動変化が起きたら前進と呼べるのか、まで落とす必要があります。
オポチュニティとソリューションを混ぜない
「AIで自動化する」「ダッシュボードを造る」は、事業機会ではありません。それは解決策です。オポチュニティのノードにそれを書きいれた瞬間、確証バイアスがチームの意識に入り込み、顧客と対話したときに「その解決策を証明しようと」して顧客を誘導する質問を発する、すなわち、事実上の売り込みなってしまいます。
多くのチームは、アジャイルであっても、トップが口にした思いつき、営業が持ち込んだ顧客の要望、プロダクトオーナーや開発者が思いついた便利機能や仕様を、そのまま「やるべきこと」として盛り込んでしまうものです。けれども、それらは本来、顧客が抱えている課題の一候補に対する解決策の、さらに一候補にしかすぎないわけです。したがって、それは事業機会＝顧客のモヤモヤでは、決してないのです。
同じ理由で、ソリューションレベルに自分たちの開発したい解決策を書き込んでおいて、そこから逆算してオポチュニティをでっち上げることも厳禁です。
アサンプションの検証を飛ばさない
テストは、プロトタイプを見せること自体ではありません。
何を前提としてこの案が成り立っているのかを言語化し、その前提を潰すことです。ここを飛ばすと、OST を描いても、結局は“感じのいい図”で終わります。
事例
事例1 ストリーム動画サービス
テレサ本人の説明による、ネットフリックスのOSTです。
出典：Lenny’s podcast “Build better products with continuous product discovery | Teresa Torres”
オポチュニティ＝モヤモヤ部分の記述が、すべて顧客が主語で書かれているところにご注目ください。
事例2 tails.com：90日継続率のままでは、探索が遅すぎた
tails.com のチームは、当初「90日継続率」を重視していましたが、それは日々の意思決定には広すぎ、しかも遅すぎる指標でした。30日、5日と測定軸をいじりながら、最終的には顧客インタビューで見つけた具体的な事業機会に対応する、より行動に近い指標へと寄せていきました。ここで重要なのは、「最初に決めたアウトカムを守り切ること」ではなく、「探索とともに、より使えるアウトカムへと更新したこと」です。これは、OST の上流が固定物ではなく、学習とともに磨かれるべきものだと示しています。
事例3 Amazon.comのPrime Video 事業
実際にAmazon.com が Continuous Discovery を学び、OSTを描いたわけではありませんが、あえて同社の戦略をOSTで説明してみました。
事例4 FCSAmerica：顧客と話していても、意思決定にはつながっていなかった
FCSAmerica は顧客と近い企業でしたが、「顧客に会ってはいたが、それを製品判断につなげる方法が分かっていなかった」と振り返っています。OST を会議のガイドとして使うようになってからは、顧客と話すことそのものではなく、そこからどう製品判断へ接続するかが改善していきました。これは、「インタビューしているのに、なぜか何も決まらない」という日本企業で非常によくある症状に、そのまま刺さる事例です。
終わりに
継続的探索における進捗とは、「どれだけ機能を造ったか（≒ベロシティ）」ではなく、どれだけ重要な前提仮説を潰せたか、あるいは、どれだけ危険な思い込みを早く否定できたか、で測るべきだ、ということがお分かりいただけたと思います。つまり、ガントチャートが予定との差分を示し、バックログが作業の一覧を示すのに対して、オポチュニティ・ソリューション・ツリーは、
- 顧客理解がどこまで進み、
- どの事業機会が本当に顧客にとって重要だと判明し、
- どの解決策の筋がよさそうで、
- どの前提仮説が生き残り、どの思い込みが否定されたのか、
を可視化するための道具なのです。私がこの考え方を高く評価しているのは、このツリーが、開発チームの視線を「造ること」から「顧客価値を学ぶこと」へと、強制的に引き戻すからです。ぜひOSTを使いこなして、真の意味での開発の成功を勝ち取ってください、と申し上げたいところなのですが、事実上、OSTの書き方を学んだところで、Continuous Discovery／継続的探索の手法をしっかりと理解しない限り、その運用は事実上できません。
OSTの取り扱いを含む、Continuous Discovery／継続的探索の手法についてセミナーを行います。興味のある方は Peatix 「[参加無料] 売上1兆円企業が勝ち筋をついに見出した、最新の市場探索メソッド」にお申し込みください！
イントラプレナーとして、合計８つの新規事業開発を経験。1,300回に及ぶ顧客インタビューの実施経験を持つ。生成AIによるアイディエーションの世界初のサービスである、「AIディアソン」を、2023年の1月に上梓。それ以降も次々とAIサービスをローンチしている。
翻訳書の発行される前の版の、The Four Steps to the Epiphany （邦訳「アントラプレナーの教科書」、リーンスタートアップの下敷きになった本）を所持するほど、古くから事業開発の方法論を考究。最近はアメリカで最新とされるプロダクト開発のメソッドである、継続的発見(Continous Discovery)手法を取り入れ、エフェクチュエーションと組み合わせて事業開発に応用。