プロダクト開発にOpportunity Solution Treeを導入した話
はじめに
約1年前、データを活用した新ビジネスモデルの創出、即ちDX推進を目的とする新規事業開発支援チームにアサインされました。しかし、社内のメンバーだけで結成された支援チームには重大な不安要素がありました。伝統的な化学系製造業である私の会社（仮称：JTC）にいる人材には事業創出やプロダクト開発の経験者が皆無だったのです。
このままでは、新規事業開発なんてできない！
私が実践を通じたプロダクト開発の学びの場を求めてPM DAOに参加したのは、そういった本業での危機感からでした。PM DAOでは機会があって“Value Discovery”というプロダクトの立ち上げから携わることができ、その中でContinuous Discovery Habitsに従ったプロダクト開発の仕方やOpportunity Solution Tree（以下、OST）の運用をしていきました。それらの実践を通じて、プロダクト開発の進め方や考え方を学んでいくことができました。
そしてつい先日、PM DAOで実践してきたOSTフレームワークを社内で提案・導入することができました。本記事では、製造業の事業会社でOSTを導入した背景、プロセスを紹介します。プロダクト開発のフレームワークの実務での活用に悩まれている方の参考になれば幸いです。
Continuous Product DiscoveryとOSTとは
Teresa Torres氏によって開発されたOSTは、Continuous Product Discoveryの実践を支援するフレームワークです。
Product Discoveryとは、顧客の課題を探求してソリューションを考えて行く営みを指します。Continuous Product Discoveryはこれを継続的に実施していくことで、プロダクトを成長させていく活動になります。
OSTでは顧客にとって望ましい成果（Desired Outcome）に到達するために、顧客のペインやニーズといったOpportunityをTree状に構造化して組み立てていきます。OSTを用いることで、チーム内での共通理解を促すことができます。
OSTの導入背景
OSTを導入した背景は以下のようなものでした。
課題感
JTCでのプロダクト開発において、私は大きく分けて３つの課題感を持っていました。
JTCはモノ売りのビジネス経験しかなかったため、顧客の声を適切に事業に取り入れる方法や仕組みがない
事業メンバーの認識をあわせる仕組みがない
社内の期待も高く、経営陣からの干渉がある
タイミング
MVPの定義後、ベータ版ローンチを控えた時期にOSTを導入しました。
これは事業が動き始めて変更コストがかかり始める前に導入したかったからです。幸い（？）JTCではこれまでプロダクト開発を組織的に実施したことがなかったため、特段の反発もなくOSTのフレームワークをクリーンインストールすることができました。
導入の仕方
顧客の声をプロダクトに反映させるプロセスを定義し、その中にOSTを組み込みました。全体のプロセスの概要は以下のようになりました。
顧客の声から得られた示唆を大まかに、現在のサービス・機能の問題とまだ満たせていないOpportunityに分類して、それぞれのプロセスに分けて開発バックログにあげていくという流れを作りました。運用しやすく、事業メンバーの認識が取りやすい様にアレンジしました。
営業時に得られた声、インタビューで得られた声、アンケートから得られた声、それぞれのチャンネルから得られる声を適切に処理※してOSTに上げていきました。このプロセスに従って運用することで、顧客の声は原則、一度OSTを経由して開発のバックログに上げられていきます。
※Whyがない声はそのまま採用しない、検証された仮説とそうでない仮説を分けるなど
OSTの運用方法
当初の課題感を解決できるように運用方法を検討しました。運用にあたっては以下の点を考慮しました。
バイアス：Opportunityを抽出する際に、人によって視点のブレやバイアスのかかり方が異なる
時間：生の顧客の声を事業メンバー全員が毎回見ることは時間的にも難しい
ミスリード：顧客の声を背景もなく見てしまうとミスリードしてしまう懸念がある
ひとまずMinimumな運用として、示唆出し作業はUX担当（筆者）に集約することにしました。サービス開始初期の顧客の声は特に重要ですので、まず一定の目線で顧客の声を取り扱うことを優先しました。
また共有は、途中工程ではなくOSTの形に整理し終わったものを月1で程度の頻度でやることにしました。例えば営業時に得られた顧客の声では細かい・背景のわからない注文も含まれましたので、これをいちいち全部は共有せず、整理後のOSTのみを共有時に説明するようにしました。
※整理過程はOSTの横のMIROボードに置いておいて、時間がある人は自由に見にいけるようにしました。
効果
この記事執筆時点でOSTを運用して１ヶ月ほど立ちました。運用を始めたばかりなのでまだまだ見えていないことばかりですが、以下のようなポジティブな効果が見えてきました。
意識：事業メンバーが顧客の声を意識するようになった
優先順位：機能開発の優先順位が個人の感覚や声の大きい人の意見ではなく、OSTの深さ・幅・重さそしてDesired Outcome（顧客の欲しい成果）の観点で考えるようになった
外圧への抵抗力：優先順位の判断基準が明確になったので、役員の声などの外圧を押し返しやすくなった
この中で思った以上に効果があったのは、外圧への抵抗力でした。これまで経営層に新規事業の定例報告をするたびに、いろいろなご指摘（例えば、UIの改善や機能開発など）を頂いており、そのたびに事業メンバーは対応と報告に追われていましたが、今回OSTを導入して顧客の声から開発までのプロセスを定義・運用を開始したことで、事業の実態に合わない、その場の思いつきのような指摘をはねのけやすくなりました。
お陰で社内の忖度ドリブンではなく、顧客中心のプロダクト開発の第一歩を踏み出すことができました。
おわりに
会社の中になにか新しい仕組みを取り入れるには、タイミングです。OSTの導入はまさにジャストタイミングだったと思います。たぶん、これより早く導入することはできなかったですし、逆にこれより遅かったら変更コストが高くなりすぎて動かなかったでしょう。まだ何も仕組みができていない、でも進む方向だけ決まっているタイミングだからこそクリーンインストールすることができたのだと思います。
OSTというフレームワークを初めてPM DAOで導入した当初、私はまだOpportunityをこのような形式で整理していくことの意味を十分理解できていませんでした。しかし、Continuous Discovery Habitsに従い、半年間継続したユーザーインタビューを通じて、プロダクトのValue Discoveryを深めるうちに、利用者のOpportunityの広がりを徐々に理解し始めました。Opportunityに対する理解が深まるにつれ、OSTフレームワークの価値を実感するようになりました。
運がいいことに、PM DAOでOSTを実践して、その意味理解が進んできた時に、本業のJTCで進めていた新規事業のローンチが重なりました。プロダクト開発のどんなところにどのようにOSTを組み込めばいいのかは、半年間の実践を通じて私の中に答えがありましたので、提案して導入することができました。
逆説的ではありますが、何かを導入したい時は、それを何処かで主体的に実践してから導入する提案をするのがいいのかもしれません。今回は事前の実践があったからこそ、良いタイミングを掴みにいくことができました。
本記事を読んでPM DAOに興味を持った方は、ぜひDiscordに参加してみてください。しっかりと関わると、面白い経験ができる場所です。
参考文献：
この記事が気に入ったらサポートをしてみませんか？