OST／Opportunity Solution Tree（オポチュニティー・ソリューション・ツリー）とは何か？
テレサ・トーリスと Continous discovery （コンティニュアス・ディスカバリー／継続的探索）
ついには、世界の現代プロダクトマネジメント界のスターになることになる、
ソフトウェアって永遠に機能が成長し続けていくものなのに、
そこで彼女は continuous discovery（継続的探索） という考え方を提唱し、いかなる機能であっても、造り始める前に、徹底的に顧客を理解し、顧客にとってのバリューをより提供できるよう、
継続的探索とは、
では、なぜ「継続的探索」が必要になったのか？この考え方が広まった背景には、プロダクト開発現場の「あるあるな失敗」があります。
問題の一つは、「アジャイルの体裁をした」事実上のウォーターフォールの失敗です。本来は、顧客にぴったりくっついて、学習しながら開発を進めていくはずのアジャイル開発
し、自分たち本位で作成した要件を実現するためだけに開発を進め
もう一つ大きな問題は、組織の分断です。「新製品開発はプロダクト側の仕事」「
この状態では、
こうした反省から、「
私はこの考え方は、ソフトウェアばかりでなく、製造業に是非とも当てはめるべき考え方だと主張します。なぜなら、アジャイル開発をやっている！と自称なさっている製造
いかにContinous discovery （継続的探索）の「進捗管理」を行うのか？
アジャイルで開発したはずのソフトウェアなりハードウェアなりが
と考えるしかありませんよね？したがって、Continuous Discover（継続的探索）では、この顧客価値の創造の進捗を、どうしても測る必要が出てきます。
ウォーターフォール型のプロジェクトで進捗を測ろうとすると、ガントチャートを使いたくなるものです。一方で、アジャイル（≒ 今日日はスクラム）で進捗を測るときは、皆さんバックログを使います。アジャイルで開発しても売れないプロダクトは往々にして出来上がる、という構造的な欠点は、バックログの使い方に引きつけて言うと、バックログに、
というメタレベルの、ふざけたユーザーストーリーを放り込むプロダクトオーナーが、事実上存在しない、
これらのツールが顧客価値の創造を促せないのであれば、継続的探索では、
Outcome（大目的）／Opportunity（事業機会）／Solution（ソリューション）／Experiment（テスト）
このツリーは、以下のような構造になっています。
レベル1：アウトカム（大目的）
テレサ・トーリスは、アジャイルが失敗するのは、それが構築するものがハードウェアだろうがソフトウェアだろうが
だからテレサは、このツリーのトップレベルに、必ずアウトカムを持ってくるよう奨めています。
彼女の著書『Continuous Discovery Habits』では、この「アウトカム」を、単なるスローガンとして掲げるのではなく、チームが日々の意思決定をするときの、最上位の判断基準として置くべきだと、繰り返し説かれています。つまり、何を造るか？より先に、
を明確にしなければならない、ということです。ここが曖昧なままでは、開発チームは、どうしても
- 今月は何を作ったか
- どれだけ実装したか
- どれだけチケットを消化したか
という、顧客価値の創造ではなくて、機能開発の進捗で測るしかありません（スクラムでいうベロシティも、顧客価値の創造のペースは、原理的に測りようがありません）。
アウトカムに、「我々にとっての顧客行動のいい方向の変化とは、こう定義する」と謳っておけば、チームの全員が自分たちの本当に達成したいことについて、ブレずに仕事を進めることができます。
レベル2：オポチュニティ（事業機会＝顧客の「モヤモヤ」）
アウトカムの下には、顧客が抱えている、困りごと、欲求、不満、ためらい、未充足のニーズ……と、もろもろのモヤモヤがぶら下がります。
ここで重要なのは、実際にはほとんどの場合、オポチュニティ＝モヤモヤは、階層構造になっているということです。大きなモヤモヤの下に、
たとえば最上位では、「サービス導入の手間が障害になっている」といった大きな事業機会が見えていたとしても、そこからさらに、その背景たる
- 長期のコスパが読めない
- 導入事例がないので、社内承認を通しにくい
- 初期設定が難しい
といった、より具体的な下位の事業機会へと、
実は、私は、このオポチュニティが複数あって、
と仮説を容赦なく全否定してきても、
また、もう一つ、テレサがここで強調しているのは、このレベルのノードに、決して解決策を書くな、ということです。多くのチームは、アジャイルであっても、
- トップが口にした思いつき
- 営業が持ち込んだ顧客の（どこまで本気かわからない）要望
- プロダクトオーナーや開発者が思いついた便利機能や仕様
を、そのまま「やるべき（何を？）こと」
だから、それは事業機会などでは決してないし、ソリューションレベルに自分たちの開発したい解決策を書き込んで
レベル3：ソリューション（解決策）
そして初めて、そのオポチュニティの下に、複数のソリューション案を並べます。ここで重要なのは、最初に思いついた解決策を正解扱いしないことです。開発現場では、一度ソリューションが決まった瞬間に、それが既定路線になってしまいがちです。その結果、本当はもっと筋のいい案があるかもしれないのに、
チーム全体が「決まった案を予定どおり作ること」に集中し始めます。
しかし、コンティニュアス・ディスカバリーの前提では、ソリューションは仮説です。しかも一つではなく、複数並べて比較されるべき仮説です。
つまり、オポチュニティ・ソリューション・ツリーは、「正解の機能」を一つ選んでそこへ突っ込むための道具ではありません。顧客が抱える事業機会に対して、どの解き方が筋がよいのかを、いくつか並べて考えるための道具なのです。
レベル4：エクスペリメント（テスト）
ここで重要なのは、コンティニュアス・ディスカバリーでは、ソリューションそのものをいきなり検証するのではない、という点です。テレサが繰り返し述べているのは、私たちが検証すべきなのはソリューションそのものではなく、そのソリューションが成り立つと私たちが信じているアサンプション（前提仮説）だ、ということです。
たとえば、ある機能案を思いついたとします。このとき本当に問うべきなのは、
- 顧客は本当にこの課題を強く感じているのか。
- この解き方は、その課題を本当に軽減するのか。
- 顧客はこの使い方を自然に理解できるのか。
- 技術的・法務的・運用的に実現可能なのか。
といった、ソリューションの背後に隠れている、そのソリューション仮説を成立させている前提仮説です。したがって、オポチュニティ・ソリューション・ツリーの「テスト」の段階で行うべきことは、「このソリューションのプロトタイプを市場に出してみること」ではありません。そうではなく、このソリューションが成り立つために、絶対に正しくなければならない前提は何かを特定し、その中でも最も危ない前提仮説から順に、小さく、早く、安く検証していくことです。
この考え方に立つと、コンティニュアス・ディスカバリーの進捗とは、「どれだけ機能を作ったか」ではなく、どれだけ重要な前提仮説を潰せたか、あるいは、どれだけ危険な思い込みを早く否定できたか、で測るべきだ、ということになります。
つまり、ガントチャートが予定との差分を示し、バックログが作業の一覧を示すのに対して、オポチュニティ・ソリューション・ツリーは、顧客理解がどこまで進み、どの事業機会が本当に重要だと分かり、どの解決策の筋がよさそうで、どの前提仮説が正しいと証明され、どの思い込みが否定されたのか、を可視化するための道具なのです。
私がこの考え方を高く評価しているのは、このツリーが、開発チームの視線を「造ること」から「顧客価値とは何か？を考え抜くこと」へと、強制的に引き戻すからです。そして、新規事業や新製品開発で本当に必要なのは、まさにこの視線の切り替えだと思っています。
イントラプレナーとして、合計８つの新規事業開発を経験。1,300回に及ぶ顧客インタビューの実施経験を持つ。生成AIによるアイディエーションの世界初のサービスである、「AIディアソン」を、2023年の1月に上梓。それ以降も次々とAIサービスをローンチしている。
翻訳書の発行される前の版の、The Four Steps to the Epiphany （邦訳「アントラプレナーの教科書」、リーンスタートアップの下敷きになった本）を所持するほど、古くから事業開発の方法論を考究。最近はアメリカで最新とされるプロダクト開発のメソッドである、継続的発見(Continous Discovery)手法を取り入れ、エフェクチュエーションと組み合わせて事業開発に応用。