オポチュニティ・ソリューション・ツリー（OST）は、プロダクトチームの思考プロセスを可視化するためのツールです。最上部には目指すべき成果（アウトカム）を配置します。その下には、その成果につながる顧客のニーズや課題（オポチュニティ）が並び、さらにそれらに対する解決策のアイデアや、検証すべき前提条件（仮説）へと続いていきます。

このフレームワークは、Teresa Torres氏が継続的ディスカバリー（Continuous Discovery）の一環として考案したものです。彼女のオポチュニティ・ソリューション・ツリーの解説ガイドでは、この構造がいかに探索とチームの認識合わせを後押しするかが説明されています。ツリーはあくまで思考を整理するための枠組みであり、項目を追加したからといって、その妥当性が証明されたわけではありません。

「オポチュニティ」と「解決策の機能」を混同しない

たとえば、アカウント初期設定の改善プロジェクトを考えてみましょう。目指すアウトカムが「自力でセットアップを完了できる新規管理者の増加」だとします。このときオポチュニティとなるのは、「同僚にどの権限を付与すべきかわからない」といった状況です。「権限設定ウィザードを作る」というのはその課題に対する解決策の1つであって、課題そのものではありません。

この2つを明確に分けておくことで、他の選択肢も視野に残り続けます。役割の説明をわかりやすくする、安全なデフォルト値を設定する、比較画面を用意する、ガイド付きフローを導入するなど、同じ課題に対してもさまざまなアプローチが考えられます。オポチュニティを置くべき場所に特定の機能を入れてしまうと、ツリーは単に「すでに決めたアイデアを正当化するための図」になりかねません。

オポチュニティはリサーチ結果と結びつけ、その課題がどの程度確かなものかを把握しておきましょう。たった1回のインタビューでも重要な課題は見つかりますが、それがどれくらい広く存在するかまではわかりません。課題の広がりが優先度判断に影響する場合は、より幅広いデータが必要になります。

「何が成り立っている必要があるか」をテストで検証する

ガイド付きの権限設定フローが有効に機能するためには、管理者が質問の意図を理解でき、必要な情報を持っていて、その結果を信頼できる必要があります。また、技術的な依存関係によって、その機能を安全にリリースできるかどうかが決まることもあります。

それぞれの不確実性に応じて、適切なリサーチや検証方法を選びましょう。理解度を確かめるならプロトタイプテストが向いていますし、実際に誰が権限の決定権を持っているかを知るにはインタビューが必要です。適切なデザインが用意できているなら、Ballparkのプロトタイプテスト機能を使ってインタラクションの検証を行うこともできます。

ツリーを更新する際は、観察された事実と自分たちの解釈を分けて捉えることが大切です。数回のテストでタスクがうまく完了できたからといって、そのソリューションにまつわる前提条件がすべてクリアされたわけではありません。

得られた証拠に合わせてツリーを変化させる

ツリーは常にアップデートしていく生きたモデルです。ブランチを見直したり、統合したり、時には削ったりしても構いません。なぜその方向性を選んだのか、どの代替案がまだ有力なのかを記録しておきましょう。すべてのブランチを埋め尽くすことや、見た目の完成度を高めることが目的ではありません。

次に何を検証すべきか、実際の意思決定にツリーを活用してください。提案された機能がリサーチに基づくニーズへと遡ることができ、残された不確実性がチーム内で共有されていれば、ツリーはその役割を十分に果たしています。もしツリーのすべての道筋が既存のロードマップに繋がっているだけなら、それが本当に新しい発見を捉えているのか、単に決まっていた計画を別の形でなぞっているだけではないかを見つめ直してみてください。