問題定義
インサイト統合の実践ガイド｜定義フェーズで「本当の問題」を見つける技術
デザイン思考の定義フェーズでインサイトを抽出・統合し、POVステートメントとHMWに落とし込む実践プロセスを解説。ワークショップで繰り返し起きる「ギャップの見えなさ」を克服する具体的手順。
13分で読める
「ユーザーインタビューを10人やった。付箋が300枚出た。でも、何がインサイトなのか分からない」——この行き詰まりは、デザイン思考の定義フェーズで最も頻繁に起きる問題です。
収集した情報を「整理した」と「統合してインサイトを見つけた」は、全く別の作業です。インサイト統合とは、バラバラなデータを並べ直すのではなく、「なぜそうなっているのか」という因果の解釈を生み出すプロセスです。このガイドでは、定義フェーズの実務的な進め方を、ワークショップの現場で繰り返し観察されるパターンを踏まえながら解説します。
「観察」と「インサイト」は別物である
インサイト統合を学ぶ前に、最も重要な区別を確認しておきます。
観察（Observation）: ユーザーが実際に言ったこと・やったことの記録。「Aさんは、スマートフォンで地図を開く前にまず紙の地図を取り出した。」
インサイト（Insight）: 観察の背後にある動機・信念・矛盾の解釈。「紙の地図を取り出したのは、デジタル地図への不信感ではなく、まず全体像を把握してから詳細を確認するという認知スタイルの表れかもしれない。」
インサイトは観察から直接導けるものではありません。複数の観察を重ね合わせて初めて「見えてくる」ものです。KJ法（アフィニティダイアグラム）の発明者である川喜田二郎が強調したのは、既成のカテゴリーに当てはめるのではなく、データそのものに語らせることでした。
ワークショップでよく起こるのは、観察メモをグルーピングして「テーマ名」を付けた時点で「インサイトが出た」と思い込んでしまうパターンです。「移動に関する不満」というグループ名はテーマであって、インサイトではありません。インサイトは「なぜ不満が生まれているのか、その背景にある構造」を指します。
定義フェーズの全体プロセス
インサイト統合は、以下の5段階で進みます。それぞれを順番に解説します。
- 生データの書き出し（Downloading）
- パターンの発見（Clustering）
- インサイトの言語化（Insight Framing）
- POVステートメントの作成
- HMW（How Might We）への変換
ステップ1: 生データの書き出し（30〜45分）
共感フェーズで収集した情報を、1枚の付箋に1つの観察として書き出します。
書き方のルール:
- ユーザーの行動・発言・感情を具体的に書く（主語を「◯◯さんは」にする）
- 解釈・評価を加えない（「使いにくそうだった」ではなく「同じボタンを3回押していた」）
- ユーザーへの共感の言葉ではなく、観察の事実を書く
この段階で解釈を混ぜてしまうと、後工程でバイアスが固定されます。参加者からの声として多いのは「細かく書こうとすると時間がかかる」という感想です。ここで意識してほしいのは、1枚の付箋に詰め込もうとしないことです。1観察 = 1付箋。多くなりすぎることを恐れないでください。
ステップ2: パターンの発見（45〜60分）
書き出した付箋を壁に貼り、類似する観察を手で動かしながらグループを作ります。これがアフィニティダイアグラム（KJ法）の作業です。
進め方のポイント:
- 無言で始める: 最初の5〜10分は会話なしで付箋を動かします。「この付箋、こっちじゃない?」の会話が始まると思考が言語化に引っ張られ、直感的なグルーピングが阻まれます
- グループは3〜7枚が目安: 2枚だけのグループは後でどこかに統合できます。10枚以上になったらサブグループを作ります
- グループ名は後付けにする: グループを先に決めてから付箋を当てはめると、当てはまらない観察が捨てられます。グループ名は「中に入っている付箋を見てから」付けます
実際にやってみると、直感的に「なんか近い気がする」で動かした付箋が、後からグループ名を考えると驚くほどきれいに意味をなすことがあります。逆に「テーマとして正しそう」という判断でグルーピングしたものが、見返すと意味がバラバラだったりする。手を動かすことが思考を深めるのです。
ステップ3: インサイトの言語化（45〜60分）
各グループを見ながら「なぜ」を問い続けます。このステップがインサイト統合の核心です。
インサイトを引き出す問いかけ:
- 「このグループに共通するユーザーの動機は何か?」
- 「このパターンが繰り返し起きているのはなぜか?」
- 「このグループ内の観察の中で、最も驚いたものはどれか? なぜ驚いたのか?」
- 「このユーザー行動は、どんな信念・恐れ・習慣から来ているか?」
良いインサイトの特徴:
良いインサイトは「チームが知らなかった何か」を含みます。「ユーザーは説明書を読まない」は一般常識で、インサイトではありません。「ユーザーは説明書を読まないのではなく、最初の失敗体験から”この種の製品の説明書は役に立たない”という学習済みの信念を持っていて、意図的にスキップしている」はインサイトです。
インサイト文の書き方:
「ユーザーは◯◯をしている/しない。なぜなら、◯◯という信念・恐れ・矛盾を持っているからだ。」
インサイトと「面白い観察」を混同しない:
「70代の方がスマートフォンを両手の人差し指で打っているのが面白かった」は観察です。「70代のユーザーが両手で入力するのは、タッチ入力自体への信頼感のなさから生まれた過剰な確認行動であり、これはフィードバックの不明瞭さが原因かもしれない」はインサイトです。
ステップ4: POVステートメントの作成（30〜45分）
インサイトを特定のユーザーに紐づけた問題定義文を書きます。d.school の形式は以下です。
[ユーザー] は [ニーズ] を必要としている。なぜなら、[インサイト] だからだ。
例:
- 観察: 「Bさんは、クレジットカードの明細を確認するたびに、使った記憶のない金額の行を不安そうに調べていた」
- インサイト: 「小さな不確実な支出が積み重なることへの不安が、金融管理への動機より強く働いている」
- POV: 「Bさんのような家計管理に不安を感じる人は、支出の”意外性”を排除する仕組みを必要としている。なぜなら、知らないうちにお金が減るという感覚が管理への意欲を下げているからだ」
POVで陥りやすいミス:
- 解決策を入れてしまう: 「通知機能が必要」など、HOWが混入するとPOVでなくなります
- 具体的ユーザーが消える: 「一般的なユーザー」を対象にすると、インサイトが薄まります
- 「〜したい」というウォンツをそのままニーズにする: ウォンツの背後にある深層ニーズに掘り下げます
ステップ5: HMW（How Might We）への変換（20〜30分）
POVを「どうすれば〜できるだろうか?」という形式の問いに変換します。この問いがIdeateフェーズの出発点になります。
先の例をHMWに変換すると:
- 「どうすれば、支出の”意外性”を体験の前に知ることができるだろうか?」
- 「どうすれば、知らない支出が発生した瞬間にわかるようにできるだろうか?」
- 「どうすれば、家計管理への不安を”確認の楽しさ”に変えられるだろうか?」
HMWは1つのPOVから複数生成できます。「狭すぎず、広すぎない」範囲を意識してください。
「どうすれば家計管理全体を改善できるか?」は広すぎて、どこから始めるかわかりません。「どうすれば通知の色を決められるか?」は狭すぎて、創造的な解決策が生まれません。
定義フェーズで頻出する失敗パターン
失敗1: インタビューが終わった直後にアイデアを出し始める
参加者からの声として最も多いのが「インサイトを言語化する前に、自分たちがすでにアイデアを話し合っていた」というケースです。共感フェーズ後の興奮でIdeateに滑り込んでしまう。
対策: ワークショップの冒頭で「この時間はアイデアを出す場ではなく、問題を定義する場」と明示する。ホワイトボードに「今日はアイデア禁止」と書いてもよい。
失敗2: グルーピングを「テーマ別分類」で終わらせる
「使いやすさ」「価格」「デザイン」などのカテゴリ別に付箋を分けた時点で作業が止まるパターンです。これは「整理」であって「統合」ではありません。
対策: グルーピング後に必ず「このグループが存在するのはなぜか?」と問う時間を設ける。グループ名を書いた後、その下に「インサイト文」を書くセクションを用意しておくと構造的に強制できます。
失敗3: POVが全員に当てはまりすぎる
「すべてのユーザーは使いやすい製品を必要としている」のような POVは誰も否定できませんが、設計の指針にもなりません。
対策: 作成したPOVを「これは◯◯さん（インタビューした実在の人物）のことを正確に描写しているか?」と確認する。実在の人物に当てはまらなければ抽象化しすぎです。
失敗4: HMWが解決策になってしまう
「どうすれば通知機能を実装できるか?」という形のHMWは、すでに解決策（通知機能）を前提にしています。
対策: HMWに固有名詞の技術・機能・手段が入っていたら書き直す。「どうすれば〜できるか?」の主語が「ユーザーの体験」に向いているかを確認する。
インサイト統合のクオリティチェックリスト
定義フェーズが終わったタイミングで、以下を確認してください。
- インサイトに「チームが以前は知らなかった情報」が含まれているか
- POVが特定のユーザーに紐づいているか（「一般的なユーザー」になっていないか）
- POVに解決策が混入していないか
- HMWが広すぎず、狭すぎない範囲か
- チーム全員がPOVを読んで「これを解きたい」という手応えを感じているか
最後のチェックを軽視しがちですが、定義した問いに「解きたい感」がなければ、Ideateフェーズで本気のアイデアは出てきません。問いの質が、その後のプロセス全体の質を決めます。
やってみよう
次のワークショップで試せる最小実践を紹介します。
インタビュー後、まず 10分間の「観察書き出し」 を個人作業でやってみてください。この間は「インサイト」「アイデア」という言葉を使わず、ひたすら「◯◯さんは何をしたか、何を言ったか」を書く。
その後で 「なぜリスト」 を作ります。書き出した観察のうち「最も驚いた3つ」を選び、「なぜそうなったのか」を3回問い続けます（5 Whys の短縮版）。この2ステップだけで、インサイトの解像度が明確に上がります。
関連項目
参考文献
- Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018
- Voltage Control, “Mastering Synthesis and Insight Generation”, voltagecontrol.com
- Interaction Design Foundation, “Stage 2 in the Design Thinking Process: Define the Problem by Synthesising Information”, interaction-design.org