オポチュニティソリューションツリーの例：最初の演習を完了しやすくする

オポチュニティソリューションツリーは、チームが混同しやすい三つの要素を分けます。目指す成果、まだ満たされていない顧客のニーズ、そして実装を検討するアイデアです。区別がなければ、何を解決するのか説明されないまま「チャットボットを追加する」がロードマップに載ってしまいます。

共同編集できるオンラインホワイトボードを使うと、それぞれのつながりを見ながら検討できます。以下は、受講者が最初の演習を完了できるようにしたいオンライン講座チームの例です。無関係な機能案で木を埋めず、一つの枝を掘り下げて複数の案を比較します。

ツリーの各階層を区別する

Teresa Torresは、Product Talkのオポチュニティソリューションツリーのガイドでこの手法を説明しています。目指す成果は探索の方向を定めます。機会とは顧客のニーズ、困りごと、望みです。解決策は、選んだ機会に応えるための候補です。前提条件とテストは、案がうまくいく、あるいはいかない理由を調べる助けになります。

「受講者が最初の演習で何を求められているか分からない」は機会の候補です。「解答例を加える」は解決策です。「解答をただ写すのではなく、例から指示の意味を理解できる」は調べるべき前提条件です。三つを同じ階層に置くと、考えのつながりを確認しづらくなります。

このツリーはリリース計画ではありません。枝には、実装しないかもしれない選択肢も含まれます。また、ツリー自体が根拠になるわけではありません。機能を成果へきれいに結んでも、その機能が成果を生むと示したことにはなりません。

講座で目指す成果を定義する

受講者が導入動画を見た後、短い演習に取り組む架空の講座を考えます。チームは演習を始めた人のうち、完了する人を増やしたいと考えています。そこで成果を、最初の演習を開いた初回受講者のうち、必要な内容を満たした解答を提出する人の割合と定義します。

この定義にも、観察期間、不完全な提出の扱い、テストアカウントの除外方法が必要です。数値目標を決める前に、自分たちのデータから現状値を得ます。ここでは現状値や改善率を仮定しません。

完了はサービス上の行動であり、学習できた証拠ではありません。「演習が本来求める思考を省かない」という学習上の条件を成果のそばに置きます。課題を取り除いて送信ボタンを押しやすくすれば完了率は上がるかもしれませんが、講座の価値を損ねます。

受講者のニーズを軸に機会を整理する

次の枝は、この例で調べる候補であり、実際のインタビュー結果ではありません。実際のツリーでは、調査セッション、取り組みの観察、サポートでの会話など、出典と状況を各機会の隣に置きます。根拠のないアイデアは、確認した観察と見分けられる状態にします。

最初の二つは似ていますが、想定する行動は異なります。課題を説明できない人には、内容を明確にする必要があります。正しく説明できても始められない人には、作業を分ける助けが必要かもしれません。「演習を簡単にする」にまとめると、この違いが消えてしまいます。

Product Talkの機会マッピングのガイドは、機会の全体像を理解することを重視しています。ニーズは、発言された画面だけでなく、意味と関係に基づいてまとめます。困りごとは複数の画面にまたがることがあります。

一つの機会について三つの案を比較する

調査により、受講者は授業内容を理解しているものの、演習で何を求められているか分からないと確認できたとします。チームはこのニーズを次に調べる対象とし、最初の提案をそのまま計画にせず、三つの応え方を比べます。

三案は同じニーズに異なる仕組みで応えます。指示用チャットボット、出席のリマインダー、講師向けダッシュボードを比較するより、違いを検討しやすくなります。そうした機能は別々の枝に属するためです。

見るべきなのは、受講者がデザインを気に入ったと言うかどうかだけではありません。初めて見る演習での行動を観察し、その後に迷った場面を尋ねます。プロトタイプは理解しやすさや使いやすさの調査には役立ちますが、それだけで長期的な学習や講座の完了を確認することはできません。

都合の悪い根拠も残す

解答例を見て始められる人がいる一方、課題を理解せず表面的な形だけ写す人もいたとします。単純に成功とは言えません。両方の観察を解決策のそばに残し、対照的な例、より明確な指示、別の方法が問題に応えられるか考えます。

指示は理解していて、未習の内容が必要なために止まっているなら、ツリーの上へ戻ります。選んだ機会が違っていたのかもしれません。同じ枝に問いかけを増やし続けても、誤った説明を細かくするだけです。

前提知識が足りないかどうかなど、複数の案が同じ不確実性に依存するなら、各デザインを仕上げる前にその点を調べます。前提条件マップで重要だが根拠の弱い主張の優先順位を考え、機会のツリーには受講者のニーズとのつながりを残せます。

Boardmixでツリーを作る

Boardmixのキャンバス上部に成果を置き、その下に三つのニーズを加えます。それぞれの横に出典メモの余白を残します。選んだニーズだけを三つの解決策に展開し、各案の下に前提条件と、調べる助けになる観察内容を置きます。

観察したニーズ、仮説、解決策の候補を一貫した方法で区別します。色よりラベルが重要です。後で読む人が未検証の提案を調査結果と誤解しないようにします。見送った案は黙って消さず、短い理由とともに別の場所へ置きます。

Boardmixのボードを開き、成果と、既に得ている顧客の根拠から始めます。最初に置いたものが機能要望なら解決策の場所へ移し、上へたどりましょう。どのニーズに応えるのか。それに応えることは、なぜ重要なのでしょうか。