デザイン思考で陥りがちな「課題設定の曖昧さ」を克服する：真のニーズを捉える問題定義の技術
デザイン思考を実践する中で、「ユーザーの課題が漠然としている」「何から手をつけて良いか分からない」といった悩みに直面したことはありませんでしょうか。特にプロジェクトの初期段階である「問題定義（Define）」フェーズでの曖昧さは、その後のアイデア発想、プロトタイピング、テストといった全工程に悪影響を及ぼし、最終的な成果物の価値を低下させる原因となります。
本記事では、デザイン思考における課題設定の曖昧さがなぜ発生するのかを掘り下げ、真のニーズを捉え、プロジェクトを成功に導くための具体的な問題定義の技術と実践的なアプローチを解説いたします。
デザイン思考における課題設定の曖昧さ：その原因と影響
まず、なぜ課題設定が曖昧になりがちなのか、その主な原因を理解することが重要です。
曖昧になる主な原因
- 表面的な課題に囚われる: ユーザーの口から語られる直接的な不満や要望は、往々にして真のニーズの「表面」に過ぎません。深掘りせず、それらをそのまま課題として捉えてしまうと、本質的な解決には繋がりません。
- 早期の解決策思考: 問題が十分に定義されていない段階で、「どうすれば解決できるか」という解決策に意識が向きすぎてしまうことがあります。これにより、問題の本質を見失い、既存の解決策に引きずられる形で課題が設定されてしまうリスクがあります。
- ユーザー理解の不足: 十分な共感フェーズを経ていない、あるいは質的なデータが不足している場合、ユーザーの行動、思考、感情、動機といった深い洞察が得られず、結果として表面的な問題しか見えてこないことがあります。
- チーム内の認識齟齬: 複数のメンバーがそれぞれの解釈で課題を捉えているにもかかわらず、その認識を擦り合わせるプロセスが不足していると、曖昧な共通認識のままプロジェクトが進行してしまいます。
曖昧な課題設定が引き起こす影響
曖昧な課題設定は、以下のような深刻な問題を引き起こします。
- 無駄なアイデア発想: 本質とズレた課題に対し、多くのリソースを投じてアイデア出しを行っても、意味のある解決策は生まれにくくなります。
- 的外れなプロトタイピング: どのような価値を検証すべきかが不明確なままプロトタイプを作成しても、ユーザーにとって本当に必要なものかどうかの判断が難しくなります。
- ユーザーからの有効なフィードバックの欠如: プロトタイプをテストする際も、明確な課題意識がないため、ユーザーからのフィードバックも漠然としたものになり、改善に繋がりにくくなります。
- プロジェクトの方向性喪失: チーム全体が「何のために」「誰のために」活動しているのかを見失い、モチベーションの低下や手戻りの増加を招く可能性があります。
真のニーズを捉える問題定義の技術
それでは、曖昧な課題設定を克服し、真のニーズに基づいた問題定義を行うための具体的な技術とアプローチをご紹介します。
1. ユーザーの深層ニーズを探る質問術
ユーザーが「何を求めているのか」を深掘りするために、単なる聞き取りに終わらない質問テクニックを活用しましょう。
-
5Why分析の活用: ユーザーが抱える問題や不満に対して、「なぜ？」を最低5回繰り返すことで、表面的な原因から深層にある本質的な原因を突き止めます。これにより、単なる症状ではなく、根本的な課題に焦点を当てることができます。
- 例：「この機能が使いにくいです」
- なぜ使いにくいと感じるのですか？ → 「操作手順が多すぎます」
- なぜ操作手順が多いと問題なのですか？ → 「作業に時間がかかります」
- なぜ作業に時間がかかると問題なのですか？ → 「他の重要な業務に支障が出ます」
- なぜ他の業務に支障が出るのですか？ → 「残業が増え、プライベートな時間も確保できません」
- なぜプライベートな時間も確保できないと問題なのですか？ → 「ストレスが溜まり、仕事のモチベーションが低下します」
- この例では、単なる「機能が使いにくい」という問題の裏に「時間創出によるQOL向上」という深層ニーズが隠れていることが見えてきます。
- 例：「この機能が使いにくいです」
-
共感マップとペルソナの見直し: 共感フェーズで作成した共感マップやペルソナが、本当にユーザーの深層心理や行動原理を捉えているかを確認・更新します。ユーザーが「何を見ているか (Says)」「何を聞いているか (Hears)」「何を考えているか (Thinks)」「何を感じているか (Feels)」「何を行っているか (Does)」「どんな痛み (Pains) を感じているか」「どんなメリット (Gains) を求めているか」を詳細に洗い出すことで、見落としていたニーズを発見できます。
2. 「POVステートメント」で課題を明確化する
スタンフォード大学のd.schoolが提唱する「POV (Point of View) ステートメント」は、ユーザー、ニーズ、インサイトの3つの要素を用いて課題を明確にする強力なフレームワークです。
- 構成要素:
- [ユーザー] は、
- [ニーズ] を必要としている。
- なぜなら、[インサイト] だからだ。
- 作成のポイント:
- ユーザー: 特定のペルソナやセグメントを具体的に記述します。（例：〇〇という状況にあるIT企業の企画担当者）
- ニーズ: ユーザーが達成したい具体的な目標や解決したい課題を動詞を用いて記述します。（例：効率的に情報収集を行いたい）
- インサイト: そのニーズがなぜ存在するのか、ユーザーの行動、感情、思考から得られた深い洞察を記述します。（例：情報過多の時代で何が正しい情報か見極めるのに疲弊している）
- POVステートメントの例:
- 「新しいプロジェクトを任されたIT企業の企画担当者は、効率的にデザイン思考のトラブルシューティング情報を収集することを必要としている。なぜなら、現場での実践ノウハウが少なく、情報過多の中で具体的な解決策を見つけることに時間と労力を費やしているからだ。」
- このように明確に記述することで、誰のどのようなニーズを、なぜ解決すべきなのかがチーム内で共有されやすくなります。
3. 「How Might We (HMW)」で発想を広げる
POVステートメントで定義された課題を、具体的な解決策を探索するための問いに変換するのが「How Might We (HMW)」ステートメントです。
- HMWの作成方法とポイント:
- POVステートメントの「ニーズ」と「インサイト」を元に、「私たちはどのようにすれば〜できるだろうか？」という形で問いを立てます。
- 広すぎず、狭すぎない問い:
- 広すぎる問い（例：私たちはどうすれば世界を良くできるだろうか？）は、アイデアの方向性を見失いがちです。
- 狭すぎる問い（例：私たちはどうすれば青色のボタンを大きくできるだろうか？）は、革新的なアイデアの可能性を狭めてしまいます。
- ポジティブな問い: 問題を解決する可能性に焦点を当て、前向きな姿勢で問いを立てます。
- 解決策に飛びつかない問い: 具体的な解決策を直接示唆するのではなく、多様なアイデアを引き出すための余地を残します。
- 良いHMWと悪いHMWの例:
- 悪いHMW例（広すぎる）: 「私たちはどうすれば、企画担当者の仕事を楽にできるだろうか？」
- 悪いHMW例（狭すぎる・解決策に飛びついている）: 「私たちはどうすれば、AIアシスタントを導入して情報収集を効率化できるだろうか？」
- 良いHMW例: 「私たちはどのようにすれば、IT企業の企画担当者がデザイン思考の現場課題に対する信頼性の高い実践ノウハウを、ストレスなく効率的に見つけられるだろうか？」
- 良いHMWは、具体的なユーザーのニーズとインサイトに根ざしつつ、多様なアイデアの発想を促すような問いになっています。
4. チームでの合意形成と可視化
問題定義は、チーム全員が共通の理解を持つことが不可欠です。
- ワークショップの実施: POVステートメントやHMWステートメントをチームメンバー全員で作成するワークショップを実施し、それぞれの意見や解釈を共有し、擦り合わせる機会を設けます。
- ビジュアル化ツールの活用: ホワイトボード、付箋、デジタルホワイトボードツール（Miro, Muralなど）を活用し、問題定義のプロセスと結果を視覚的に共有します。これにより、抽象的な概念を具体化し、チーム全体の理解を深めます。
実践におけるヒントと注意点
- 「答えありき」の思考を避ける重要性: ユーザーインタビューや共感マップ作成の段階で、「こうであろう」という仮説や、自社の既存サービスに結びつけようとする思考は、真のニーズを見誤らせる大きな落とし穴です。常に中立的な視点を保ち、データやユーザーの声に謙虚に耳を傾ける姿勢が求められます。
- ステークホルダーを巻き込む利点: 顧客、営業、開発、経営層といった多様なステークホルダーを問題定義のプロセスに早期から巻き込むことで、多角的な視点から課題を検証し、解決策への納得感を高めることができます。また、プロジェクトの進行における支援も得やすくなります。
- 失敗から学ぶ：過去の曖昧な課題設定の教訓: 過去にプロジェクトがうまくいかなかった事例を振り返り、その原因が問題定義の段階にあったのではないかという視点で分析してみることも有効です。具体的な失敗例とその教訓を共有することで、チーム全体の学習と改善を促します。
まとめ：実践的な問題定義でプロジェクトを成功に導く
デザイン思考における問題定義は、プロジェクトの成否を分ける極めて重要なフェーズです。表面的な課題に惑わされず、ユーザーの深層ニーズに根ざした明確な課題を設定することで、その後のアイデア発想やプロトタイピングの質が飛躍的に向上し、最終的にユーザーにとって真に価値のある製品・サービスを生み出すことができます。
本記事でご紹介した「5Why分析」「POVステートメント」「How Might We」といった具体的な技術を日々のプロジェクトに適用し、チーム内で共有することで、曖昧な課題設定の壁を乗り越え、実践的なデザイン思考を推進してください。地道な問題定義の積み重ねが、組織全体のイノベーション文化を育む第一歩となるでしょう。