課題と解決策の概念の話は昔からよく論じられてきていて、「空・雨・傘」などのフレームワークなどでも問われてきています。プロダクトマネジメントの世界でも例外ではなくこれらの概念は登場します。この2つの概念と実務で混在しがちな状況について今回は述べてみます。
- Problem Discovery（課題の発見）とSolution Discovery(解決策の発見)の違い
- プロダクトの要望は「Solution(解決策)」に言及されるものが多い
- 解決策の要望から「課題」を把握するプロセスを挟むと良い(Problem Discovery)
- 課題を明確にした上で解決策を検討する(Solution Discovery)
- まとめ
Problem Discovery（課題の発見）とSolution Discovery(解決策の発見)の違い
Problem DiscoveryとSolution Discoveryはプロダクトマネジメントの分野で使われる用語です。以下の５年前の記事にも記載されています。
この記事によると、製品開発における「発見」プロセスは「課題の発見(Problem Discovery)」と「解決策の発見(Solution Discovery)」があると書かれています。
課題の発見フェーズでは「顧客に何の課題があるのか？」や「その課題は解決に値する課題か？」、「課題を解決するとどのようなインパクトが得られるのか？」などを評価します。
解決策の発見フェーズでは解くべき課題に対して「どのような解決策があるのか」を探究していきます。リソースの有限性やUXを損なわないことなどいくつかの制限を設けると解決策を絞りやすくもなり得ます。
「Problem Discovery」で課題を明確化してから、「Solution Discovery」で解決策を検討すること。これが定石です。 言葉にすると当然な話なのですが、これらを意識していると動きやすいことがあります。
プロダクトの要望は「Solution(解決策)」に言及されるものが多い
B2B SaaSのプロダクトマネージャーをしている中で、日々ユーザーやセールス、カスタマーサクセスから要望を頂きます。その中から今後作るべき機能やプロダクトの方向性を検討するのですが、気をつけるべきことがあります。要望は、「Solution(解決策)」に言及する要望が多いのです。
プロダクトマネージャーの方はわかると思うのですが、「Aという機能が欲しい」という形での要望が多いと思います。例えば、「カレンダーのUIで直接テキストを入力して日付を絞り込みたい」といった風にです。これは課題 -> 解決策の順序での検討と逆です。
要望は解決策であるゆえに、そのまま検討しようとするとProblem Discoveryのフェーズを飛ばしてしまいます。古典的なものでは「ドリルが欲しい」という顧客にドリルを販売するのはアンチパターン。本当に顧客が欲しいものは「穴を開けたい」なので穴の空いている板など複数の解決策を検討できる、という話などでしょうか。
解決策の要望から「課題」を把握するプロセスを挟むと良い(Problem Discovery)
「要望」収集は解決策の要望が多いので、「課題」収集ではないと考えています。例えば先程の「カレンダーのUIで直接テキストを入力して日付を絞り込みたい」はどういった課題に対する解決策なのかわかりません。マウスでの絞り込み操作では操作が煩雑になる背景が存在するのか、テキスト入力にしていないために他のUI部品とのバランスが取れていないからなのか等。
課題を把握しなければその「解決策」の要望が適切な解決策かは見当がつきませんし、仕様を切るときに本来の課題からズレたものが仕上がってしまう可能性もあります。
つまり、本当の課題は何かを見極める必要があります。
- 課題は具体的に何なのか
- 顧客が自分の言葉で課題をどのように説明していたのか
- 顧客は現在、その課題をどのように解決しているか
- 自身がその要望を聞いた時、本当の課題は何だと思ったか
などの問いかけを通じて本来の課題を発見する必要があります。
課題を明確にした上で解決策を検討する(Solution Discovery)
Problem Discoveryのプロセスを通して課題が解決すべきものであると考えた場合、解決策の検討を行います。
- もともと要望として聞いていた解決策が適切か
- そうでなければ適切と考えられる解決策は何か
- 解決策のコストは何なのか
- 新たに解決策を機能として作らなくても既存機能や運用で対応など代替手段がないか
- ペーパープロトタイプを作って顧客に見せてみた時の反応はどうなのか
などの問いかけを通じて「筋の良い」解決策を検討していきます。すでにみたように、Problem Discoveryで課題を明確にした前提であるからこそSolution Discoveryが行いやすくなります。
まとめ
この記事ではProblem DiscoveryとSolution Discoveryの違いと、順序の重要性を述べました。また、多くの要望を収集するプロダクトマネージャーの立場では、要望は解決策の言及に関するものが多いこともあり、まずProblem Discoveryとして課題発見を行うことを検討することが重要だと思います。
社内の同僚を通して要望を伝えられる場合、「（事業上重要なので）これを作って欲しい」と言われることもしばしばです。近い立場から要望を伺うと重く、早く対応しなければならないと受け止めがちですが、そんな時も「課題は何なのか」と共に問いて、適切な順序でプロダクト開発ができると理想だと思います。
関連記事
