"問題"とか"課題"とか"アイデア"とか"インサイト"とかややこしいので関係性を整理したい
これはなに？
問題、課題、イシュー、原因、ニーズ、インサイト、アイデア、仮説…..
日本語の奥ゆかしさ、日本語と英語における互換性のなさ、などに起因して、よくよく考えると意味は違うが日常生活においてそこまで意識して喋っていないよ！という言葉はとても多いと思います。
ビジネスシーンにおいてはなるべくハイコンテクストな表現を避け、明確で具体的な言葉選びが求められるわけですが、いざ定義をしようにも
1. ぐぐる
2. 整理されたものが見つかる
3. 他のページを見る
4. 異なる定義が出てくる
5. 🤯 🤯 🤯 🤯 🤯
などのように翻弄されつづける経験はありませんか？
今回はそのような課題に対して、
あくまでプロダクトマネジメントに関する文脈に閉じる
流派は流派として無理に統合をしない
ただし概念として類似する用語については関連性を示す
といった縛りを課すことで、ローコンテクスト化しつつ用語の関係性を示せるのではないかということを思い、とりあえずやってみたという企画です。
ややこしい用語マップ
⚠️ 注意点
あくまで用語の関係性を示すことを目的としており、用語の定義やプロセスなどを表すものではありません。
■ 価値探索: Discovery
[共通]
・要望: Request, ユーザーの声: VoC
「利用者」を主語として、プロダクトに対する声などを指す。
これ自体も「事実」ではあるが、声に表されていない様々なコンテキストが含まれているケースも多いため、精査を行うことが重要となる。
・意見: Opinion, (勘, ひらめき, 思いつき)
「関係者」を主語として、プロダクトに対する声などを指す。
あくまでもユーザーの声ではないので、どのような観点に基づいた「意見」であるかなど取り扱いには十分な注意が必要。
※ なお、根拠のある「意見」は「インサイト」や「アイデア」とする。
・事実: Fact
定性/定量問わず、一切の加工や解釈を含まない情報のことを指す。
[課題解決型の系譜]
・問題: Problem
ありたい姿と現実のGapが「問題」となる。
この時点では粒度が荒いことも多く、「問題」を起こしている「原因」を突き止めていくことが重要。
※ なお、ありたい姿に紐づかない「問題」は「問題」ではない
・課題 / 論点: Issue
「問題」のうちアウトカムにより繋がりそうなものを「課題 / 論点」としている。「問題」含めこれらの定義には多様な流派があり、認識もブレやすいため、事前にチーム内で認識合わせをしておくとよいでしょう。
→ 参考: ビジネス書で読み解く「課題と問題と論点とイシュー」の違いが分らない問題
「課題」が「課題」であることを証明するためには、「課題仮説」として扱い「仮説検証」を経て「立証」をしていく。
故に「課題」に対する状態として「仮説」「立証」の2つを設定している。
[探索検証型の系譜]
・洞察: Insight, ニーズ: Needs
1. 顕在ニーズ: 本人が認識しているニーズ
2. 潜在ニーズ: 本人は認識していないが、インタビュー等で引き出せる
3. インサイト: 本人は認識していない深層心理にあるもの
のようなグラデーションがあり、インタビューや分析などを経てインサイトを見つけていくことが重要。
・アイデア: Idea
発見されたインサイトを起点に、アウトカムに繋がる可能性のあるもの
※ なお、根拠のない「アイデア」は「意見」や「勘」とする。
[統合型の系譜]
・機会: Opportunity
ニーズ、ペイン、願望、欲求などを包含した表現。
区別することなく全てをテーブルに並べ、よりアウトカムに近づくであろうオポチュニティを見定めていく。
■ 価値提供: Delivery
・打ち手: Solution
「価値探索」で発見された課題等に対する、プロタクトを通じた解決策。
課題に対する打ち手は無数にあるので、これも「ソリューション仮説」としとして扱い「仮説検証」を経て「立証」をしていく。
故に「打ち手」のステータスに「仮説」「立証」の2つを設定している。
・アウトプット: Output
動作する利用可能なプロダクトとしてリリースを行う。
※ アウトカムとアウトプットを識別してもらうことを目的に
・成果: Outcome
アウトプットを通じて生まれるものであり、施策の良し悪しやビジネスインパクトなどを表す評価指標。
Discoveryにおける３つの系譜について
Discoveryには大きく3つの系譜を設定しました。
多分に私見を含んでいますが、それぞれの以下のように整理をしています。
課題解決型の系譜: 課題が起点
e.g. ロジカルシンキング、クリティカルシンキング
to B(SaaS)のプロダクトにおいて主流な印象
探索検証型の系譜: 事実や現象が起点
e.g. デザイン思考、UX Research
to Cのプロダクトにおいて主流な印象
統合的な系譜: 価値探索を中心とする
e.g. Continuous Discovery、Mixed Methods
継続的な価値探索を行っていくために、様々な専門性を組み合わせこれを推進していくという比較的プラクティカルな系譜
「課題解決型の系譜」や「探索検証型の系譜」については、すでに多くの情報が世にありますのでここでは触れませんが、「統合的な系譜」について簡単に紹介をしていきます。
「統合的な系譜」について
アジャイルソフトウェア開発宣言を皮切りに、クラウドコンピューティング、CI/CD、DevOpsといった技術的発展が開発工程の高速化を実現していきます。
これに伴い、今までは開発工程と比較すると相対的に短かった企画工程についても高速化をしていく必要性が高まり、「アジャイルな価値探索」の重要性が高まっていくことになります。
このような背景から、マーケティング、UXリサーチ、アナリストなどのソフトウェア事業における非開発セクションにおいても「アジャイル」の考え方が受け入れられておき、現在ではDXの後押しもあって「組織」や「会社」レベルにまで広がっているように感じてます。
この「アジャイルな価値探索」を実現するためには、異なる専門領域を横断して価値探索に取り組むことが合理的であり、現在では開発工程も含めて価値探索の手段の一つであるというところまで専門性の垣根は溶け、統合化されてきています。
この系譜においては「課題解決型」や「探索検証型」もまた一体のものとして扱われています。例えば、
「課題解決型の系譜」であれば、Issue - Solution
「探索検証型の系譜」であれば、Idea - Solution
になると思いますが、Continuous Discoveryの中心概念であるOpportunity solution treeにおいては、その名の通りOpportunity - Solutionという形で整理を行っています。
ここでのOpportunityという表現は意図的なものであり、あらゆるものを区別することなく整理を行うという点が肝となります。
# Why is it called an opportunity and not a problem?
In the product world, we don’t just solve customer problems. The word “problem” implies something needs fixing. However, we have many examples of products or services that don’t fix problems.
Disneyland entertains me; ice cream is delicious; mountain biking is fun. These products address my desires. I could try to shoehorn these desires into needs—I need something to fill my time, I need nutrients, and I need to exercise. However, writing a book, eating spinach, and going to the gym might be more effective ways of addressing these needs.
The key difference here is that I enjoy Disneyland, ice cream, and mountain biking. These products were designed to address my desires, not solve my problems. Opportunities include needs, pain points, and desires.
---
(以下DeepL訳)
---
製品の世界では、顧客の問題を解決するだけではない。「問題」という言葉は、何かを解決する必要があることを意味する。しかし、問題を解決しない製品やサービスの例はたくさんある。
ディズニーランドは私を楽しませてくれる、アイスクリームはおいしい、マウンテンバイクは楽しい。これらの製品は、私の欲求に応えてくれる。時間を埋める何かが必要だ、栄養が必要だ、運動が必要だ。しかし、本を書いたり、ほうれん草を食べたり、ジムに通ったりすることのほうが、これらの欲求を満たすには効果的かもしれない。
ここで決定的に違うのは、私はディズニーランド、アイスクリーム、マウンテンバイクを楽しんでいるということだ。これらの商品は、私の欲求を満たすためにデザインされたものであり、私の問題を解決するものではない。機会には、ニーズ、ペインポイント、願望が含まれる。
まとめ
ややこしい用語マップという形で今回まとめてみましたが、いかがでしたでしょうか。
まだまだ甘い点は多いと思いますが、全体のプロセスづくりや、バックログマネジメント、チーム内における共通言語化あたりで役立つ場面はあるような気がしています。
これが正解であるとは全く考えていませんが、もし言葉の迷宮に迷い込んでしまったら、思考や議論の起点として使っていただけると嬉しいです。
参考記事一覧
おいしいごはんでも食べて次の活力にします！