概要

観察データからユーザーの本質的な課題を抽出し、創造的な解決策へと繋げる「問い」を設計するためのプロセスを解説する。

• インサイトの特定・クラスタリング・マッピングにより、表面的な不満の奥にある潜在ニーズを可視化する
• HMW（How Might We）によって、インサイトを創造的跳躍を促す「問い」へと変換する
• 問いのスコープ調整と評価基準の適用により、チームが一丸となって取り組める課題定義を確立する

課題定義：集めた情報からインサイトを抽出する

ユーザーの行動や発言の背後にある矛盾や感情の動きを分析し、解決すべき核心的な「インサイト」を特定する。

• 観察データから深層の「インサイト」を特定する
• 課題のクラスタリングとパターンの発見
• 潜在ニーズを可視化する情報のマッピング

観察データから深層の「インサイト」を特定する

ユーザーの行動や発言の背後にある矛盾や感情の動きを分析し、解決すべき核心的な「インサイト」を特定する。

「共感」フェーズで得られた膨大な定性データ（発言、行動、周囲の環境）を統合し、表面的な問題の奥に潜む本質的な意味を掘り下げます。単なる「不満のリストアップ」ではなく、なぜユーザーがそのような行動をとるのかという動機や、既存の解決策では満たされていない心理的な渇望を言語化します。

• 言行の不一致に注目する： 「満足している」と言いながら、実際には複雑な手順を踏んで回避策をとっているような矛盾は、強力なインサイトの源泉となります。
• ユーザーの「驚き」と「違和感」を解析する： 調査チームが予想していなかった行動や、一見不合理に見える選択に焦点を当て、その背後にある独自の論理や価値観を解明します。
• インサイトの形式化： 「ユーザーは [特定のニーズ] を必要としている。なぜなら [発見したインサイト：感情や背景、矛盾] だからだ」という構文に落とし込み、解決すべき核心を明確にします。

【インサイト構文テンプレート】
ユーザーは [特定のニーズ] を必要としている。
なぜなら [感情・背景・矛盾] だからだ。

インサイト形式化：ビフォー／アフター比較

💡 ポイント: インサイトは「ユーザーの言葉」ではなく「チームの解釈」です。観察事実と感情の推論を明確に区別して記述することで、後工程のHMWに説得力が生まれます。

課題のクラスタリングとパターンの発見

個別の断片的な情報をグループ化し、共通するテーマや構造的な問題を可視化することで、解決すべき課題の優先順位を判断可能な状態にする。

個別の断片的な情報をグループ化し、共通するテーマや構造的な問題を可視化することで、解決すべき課題の優先順位を判断可能な状態にします。

• 親和図法（Affinity Diagram）の活用： 多種多様な気づきを付箋等で抽出し、直感的に関連性の高いものを集約します。これにより、単一のユーザーの声を超えた「共通の痛み（Pain Points）」や「共通の喜び（Gains）」を浮かび上がらせます。
• コンテキストの構造化： 物理的な制約、時間的な変化、人間関係の軋轢など、課題が発生している背景（文脈）を整理し、問題がどの層で起きているのかを特定します。
• 共通認識の醸成： チーム全体で情報を共有し、誰もが納得できる「真に解くべき問題」を絞り込みます。

親和図法のステップ

💡 ポイント: グルーピングは「議論しながら」ではなく「沈黙の中で行う」のが鉄則です。言語化より先に直感を動かすことで、思い込みに縛られないパターンが浮かび上がります。

潜在ニーズを可視化する情報のマッピング

ユーザーの感情の起伏や行動の流れを時系列で整理し、どの接点がユーザー体験を毀損しているのかを具体化する。

ユーザーの感情の起伏や行動の流れを時系列で整理し、どの接点がユーザー体験を毀損しているのかを具体化します。

• カスタマージャーニーマップとの照合： 行動のプロセスに感情の動きを重ね合わせ、ポジティブな体験からネガティブな体験へと急落する「落とし穴」を特定します。
• 共感マップの深掘り： 「言っていること（Say）」と「考えていること（Think）」の落差から、ユーザーが言語化をためらっている真の欲求や社会的・心理的な摩擦を特定します。
• 価値の再定義： ユーザーが最終的に得たい「成果（Job to be Done）」を定義し、現在の体験がその目的を阻害している要因を浮き彫りにします。

共感マップの4象限

HMW（How Might We）による問いの構築

抽出したインサイトを「私たちはどうすれば〜できるか？」という前向きな問いに変換し、創造性を刺激する適切な制約を設ける。

• 創造的跳躍を促す問いの言語化
• 拡散と収束をコントロールする「問いの解像度」
• インサイトから問いを生成する視点の切り替え

創造的跳躍を促す問いの言語化

抽出したインサイトを「私たちはどうすれば〜できるか？」という前向きな問いに変換し、創造性を刺激する適切な制約を設ける。

「How Might We（HMW）」は、特定されたインサイトを具体的なアイデア創出（イデーション）へと繋げるための架け橋となる手法です。現状の不満を単に裏返しただけの課題設定ではなく、チームが「解決したい」と思えるような、楽観的かつ挑戦的な問いを構築することが重要です。

HMWの3語が持つ意味

拡散と収束をコントロールする「問いの解像度」

HMWのスコープが広すぎると具体策が浮かばず、狭すぎると改善案に終始する。革新的なアイデアを生むには適切な「制約」を含んだ問いの設計が必要。

HMWを設定する際、その範囲（スコープ）が広すぎると具体的な解決策が浮かばず、狭すぎると既存の改善案に終始してしまいます。革新的なアイデアを生むためには、適切な「制約」を含んだ問いの設計が求められます。

HMWスコープ比較

💡 ポイント: 「適切なHMW」はユーザーの感情的な文脈（朝の通勤＝義務感）を含みながら、解決手段（アプリ・コンテンツ・コミュニティ等）を限定しないのが特徴です。

インサイトから問いを生成する視点の切り替え

一つのインサイトから複数のHMWを作成し、多角的にアプローチを検討する。視点を変えることで、問題の捉え方を再定義（リフレーミング）する。

一つのインサイトから複数のHMWを作成し、多角的にアプローチを検討します。視点を変えることで、問題の捉え方を再定義（リフレーミング）します。

• ネガティブをポジティブに変える： ユーザーの痛みを取り除くだけでなく、その状況を利用して新しい価値を提供できないか考えます。
• 極端な状況（エクストリーム）を想定する： もし予算がゼロなら、あるいは時間が半分しかないならどうするか、といった制約を設けて問いを立てます。
• 構成要素を分解する： 体験をプロセスごとに分け、特定の接点における感情の動きをターゲットにした問いを作ります。

リフレーミング手法の例（インサイト：「忙しくて食事に気を遣えない」）

問いのスコープ調整と共通認識の形成

広すぎず狭すぎない「絶妙な抽象度」に問いを調整することで、チーム全員が納得感を持って進める解決の方向性を確立する。

• アイデアを解き放つ「適正な抽象度」のチューニング
• チームの「共通言語」としての問いの合意形成
• 収束とリフレーミングによる問いの洗練

アイデアを解き放つ「適正な抽象度」のチューニング

広すぎず狭すぎない「絶妙な抽象度」に問いを調整することで、チーム全員が納得感を持って進める解決の方向性を確立する。

HMW（How Might We）を設定する際、その問いの範囲が解決策の質と量を左右します。抽象度が高すぎると「何から手をつけてよいか分からない」という困惑を生み、逆に低すぎると「既存の改善案」の域を出ない平凡なアイデアに終始してしまいます。

• 広すぎるスコープの弊害： 「どうすれば健康を増進できるか？」のような問いは、対象や手段が無限に存在するため、チームの思考が分散し、具体的な議論が困難になります。
• 狭すぎるスコープの弊害： 「どうすれば野菜不足を解消するアプリの通知を増やせるか？」のような問いは、解決策が「アプリの通知」に固定されており、より本質的な解決策（例：コミュニティでの共有や購買体験の変革）を排除してしまいます。
• 絶妙なバランスの探求： ユーザーが直面している「文脈」と「感情的なニーズ」を問いに組み込みます（例：「どうすれば忙しい会社員が、罪悪感なく短時間で栄養価の高い食事を選べるようになるか？」）。

抽象度チューニングの判断軸

チームの「共通言語」としての問いの合意形成

特定された問いが、チームメンバー全員にとって「解く価値がある」と確信できる状態を作る。定義された問いは、その後の判断基準（北極星）となる。

特定された問いが、チームメンバー全員にとって「解く価値がある」と確信できる状態を作ります。定義された問いは、その後のブレインストーミングやプロトタイピングにおける判断基準（北極星）となります。

• インサイトとの紐付け確認： 設定したHMWが、前工程で抽出したユーザーのインサイトや「痛み（Pain）」を確かに解消するものであるかを検証します。
• 「ワクワク感」の判定： 問いを提示した際、メンバーから自然とアイデアが溢れ出すか、あるいは「挑戦したい」という意欲が湧くかどうかを、チームの共通認識のバロメーターとします。
• ステークホルダーとの目線合わせ： 現場のチームだけでなく、意思決定者とも問いを共有し、解決の方向性がプロジェクトの制約やビジネスの目的に反していないかを確認します。

収束とリフレーミングによる問いの洗練

一度立てた問いを疑い、異なる角度からリフレーミング（再定義）することで、最もインパクトの大きい「真の課題」へと収束させる。

一度立てた問いを疑い、異なる角度からリフレーミング（再定義）することで、最もインパクトの大きい「真の課題」へと収束させます。

• 「なぜ（Why）」を問い直す： 設定したHMWに対して「なぜその課題を解決したいのか？」を繰り返すことで、一段高い次元のニーズを発見し、スコープを再調整します。
• 「もし（If）」による制約の変更： 「もしテクノロジーが使えないとしたら？」「もし予算が無制限なら？」といった極端な制約を設けて問いを書き換え、固定観念を打破します。
• 優先順位の選定： 複数のHMW候補がある場合、「実現可能性」「インパクト」「ユーザーへの共感度」の軸で評価し、チームが最も集中すべき一点に絞り込みます。

HMW候補の優先順位評価マトリクス

💡 ポイント: スコアリングはあくまで議論の補助ツールです。数値だけで機械的に選ぶのではなく、「なぜそのスコアにしたか」の対話プロセス自体が、チームの共通認識を深めます。

良いHMWを設定するための評価基準

設定した問いが、多様な解決策を想起させ、かつ具体的なユーザーのベネフィットに紐付いているかを検証する。

• アイデアの多様性を生む「広さ」と「深さ」の検証
• チームを突き動かす「納得感」と「熱量」の判定
• プロトタイプへの接続性を高める制約の妥当性

アイデアの多様性を生む「広さ」と「深さ」の検証

設定した問いが、多様な解決策を想起させ、かつ具体的なユーザーのベネフィットに紐付いているかを検証する。

優れたHMW（How Might We）は、チームの思考を制限するのではなく、むしろ解放する触媒として機能します。評価の第一基準は、その問いを聞いた瞬間に、メンバーが異なるアプローチの解決策を5つ以上即座に思い浮かべられるかどうかです。

• 解決策の誘導を避ける： 問いの中に「特定の技術」や「具体的な機能」が含まれていないかを確認します。例えば「どうすればアプリのUIを改善できるか」ではなく、「どうすれば操作の迷いをなくし、達成感を高められるか」とすることで、デジタル・アナログを問わない多様な解法を引き出せます。
• ユーザーの感情的ベネフィットへの直結： 問いを解決した結果、ユーザーのどのような感情（安心、興奮、誇りなど）が満たされるのかが明確である必要があります。機能的な充足だけでなく、心理的な変化を問いの核に据えます。
• 「もし〜なら」という跳躍の余地： 既存の枠組みを疑い、常識を打ち破るような斬新なアイデアが生まれる「遊び」があるかを評価します。

チームを突き動かす「納得感」と「熱量」の判定

問いの質は、論理的な正しさだけでなく、チームの動機付けに資するかという観点でも評価されるべきである。

問いの質は、論理的な正しさだけでなく、チームの動機付けに資するかという観点でも評価されるべきです。

• インサイトとの整合性： 設定したHMWが、前工程で発見した「ユーザーの真実（インサイト）」を解決する直接的な手段になっているかを再確認します。インサイトから乖離した問いは、どれほど魅力的でも「真の課題解決」には至りません。
• オーナーシップの醸成： チーム全員が「これは自分たちが解くべき、重要で面白い問題だ」と確信できるかが重要です。議論が停滞している場合は、問いの言語化が抽象的すぎるか、逆にワクワク感を削ぐほど具体的すぎる可能性があります。
• 測定可能性への配慮： 解決策が出た後に、それが「成功した」と判断できる基準が問いの裏側に透けて見えるかを確認します。

プロトタイプへの接続性を高める制約の妥当性

制約は創造性の敵ではなく、むしろ方向性を指し示すガイドとなる。問いに含まれる制約が、実行可能な範囲で最大限の革新を促すものであるかを精査する。

制約は創造性の敵ではなく、むしろ方向性を指し示すガイドとなります。問いに含まれる制約が、実行可能な範囲で最大限の革新を促すものであるかを精査します。

• ターゲットの解像度： 「誰のために」が明確になっているかを確認します。広すぎるターゲット（例：全人類）に対する問いは、結果として誰の心にも刺さらない平凡な回答を招きます。
• コンテキスト（状況）の具体性： どのような場面で、どのような状況下にあるユーザーを救うのかという「文脈」が問いに組み込まれていることで、解決策のリアリティが向上します。
• リソースと時間のリアリティ： プロジェクトの期間やリソースの制約を完全に無視した問いは、空想に終わるリスクがあります。適度な緊張感を持った制約を設けることで、より実効性の高いアイデアへと導きます。

HMW最終評価チェックリスト

💡 ポイント: チェックリストは全項目の満点を目指すものではありません。「5つ以上の解決策が出るか（#1）」と「インサイトとの整合（#4）」の2項目が最優先。残りは方向性の微調整に使います。