データドリブン共感——定量データと定性インサイトをデザイン思考で統合する方法

「データはある。でも何を作るべきかわからない」。この言葉を、新規事業やプロダクト開発の現場で聞いたことはないだろうか。

ダッシュボードは毎朝更新される。NPS、継続率、クリック率、ファネル離脱ポイント——数字は揃っている。しかしその先が詰まる。「離脱率が38%に上昇した。なぜか?」「NPS推奨者と中立者の差分は何か?」数字は問いを立てるが、答えは出さない。

逆のケースもある。インタビューを重ね、観察調査を丁寧に実施した。「ユーザーが感じているのはこういうことだ」という確信はある。しかし規模感がわからない。一部の声なのか、多数派の問題なのか。経営層への説明で必ず「それは何人の話?」と問い返される。

定量データと定性インサイトは、別々に扱われるかぎり、両方の弱点を抱えたままだ。デザイン思考の共感フェーズは、この二つを統合することで初めて機能する。

データドリブンと共感は対立しない

「データ重視」と「ユーザー共感」は対立概念ではない。にもかかわらず、組織の中では分断されやすい。定量分析はビジネスアナリティクスやデータサイエンスの領域、定性リサーチはUXリサーチやデザイン部門の領域——縦割りで専門化が進むほど、統合の機会は失われる。

データドリブンな共感とは、定量データを「どこに問いを立てるか」の地図として使い、定性調査を「なぜそうなのか」の掘削機として使うアプローチだ。地図なしに掘削しても広大な土地を探し続けるだけ。掘削なしに地図を眺めても、宝の場所はわからない。

共感フェーズの目的はユーザーの文脈・行動・動機・感情の深い理解だが、「どのユーザー」「どの行動」「どの場面」にフォーカスするかは、定量データが示してくれる。逆に、定量データの解釈に深みをもたらすのは定性インサイトだ。

定量データを「共感の入り口」として使う

定量データから共感フェーズを起動するには、数字を「答え」として読むのではなく、「問いの地図」として読む習慣が必要だ。

具体的には、異常値・逆張り・セグメント差分に注目する。

異常値は仮説の宝庫だ。 全体の離脱率が20%の中で、特定のセグメントだけ60%の離脱が起きているとする。その数字は「なぜこのセグメントだけ離脱するのか」という問いを立ててくれる。ここから先は定性調査の仕事だ。

逆張りユーザーは隠れたインサイトを持つ。 NPSの推奨者と批判者の行動ログを比較すると、操作パターンや使用頻度に差が見つかることがある。同じ製品を使いながら、なぜ評価が分かれるのか。アンケートのスコアだけでは見えない文脈が、そこにある。

セグメント差分は文脈の違いを示唆する。 年齢・職種・使用デバイス・利用シーンなど、どの軸でセグメントを切っても行動が変わらないなら、差分から学べることは少ない。差分が大きいほど、「このセグメントが違う使い方をしているのはなぜか」という共感の問いが生まれる。

定性調査で「なぜ」を掘る

地図ができたら、掘削を始める。ステークホルダーインタビューや観察調査を設計する際、定量データが示した問いを起点に対象者と問いを絞る。「全ユーザーを理解しよう」ではなく、「離脱率が突出しているこのセグメントを理解しよう」と目標が定まる。

定性調査のサンプル数をめぐる議論は多い。「何人インタビューすれば十分か」という問いへの実践的な答えは、定性調査のサンプルサイズで整理しているが、重要な前提は「代表性ではなく多様性を担保すること」だ。定量調査が代表性を担う。定性調査は多様な文脈と例外的なケースを発見するためにある。

インタビューで引き出すべきは意見ではなく行動と文脈だ。「このアプリを使いやすいと思いますか」という質問は意見を引き出す。「最後にこのアプリを使ったのはいつで、その時何をしていましたか」は行動と文脈を引き出す。ユーザーは自分の行動の理由を正確に報告できないが、具体的なエピソードは語れる。そのエピソードの中に、数字が語れなかった「なぜ」が埋まっている。

SpotifyとAmazonの統合アプローチ

データドリブン共感の実践例として、SpotifyとAmazonの取り組みは参照価値が高い。

Spotifyは「データとリスナー共感の統合」を組織設計に組み込んだ。 Spotifyのプロダクト開発チームは、定量的なストリーミングデータ（再生数・スキップ率・プレイリスト追加率）と定性的なユーザーリサーチを並走させる体制を持つ。Discover Weekly（週次推薦機能）の開発は、「なぜユーザーは自分でプレイリストを作るのか」という定性的な問いから始まった。データは「ユーザーは多くの曲をスキップする」という事実を示したが、インタビューが明らかにしたのは「発見したい気持ちはあるが、選ぶのが面倒」という文脈だった。数字だけでは「スキップ率を下げる」という解決策しか見えなかったが、定性インサイトが「キュレーションを自動化する」という別の解を開いた。

Amazonは「フリクションの発見」にデータと観察を組み合わせる。 Amazonの1-Click購入機能は、ユーザビリティテストとチェックアウトのドロップオフデータを組み合わせて設計された。カート放棄率というデータは「問題がある」ことを示したが、「何が問題か」を明らかにしたのは実際の購入シーンの観察だった。ユーザーが支払い情報の入力で手が止まること、その間に「本当に必要か」という迷いが生まれることが、定性観察から見えた。ワンクリックは数字への応答ではなく、文脈への応答だ。

インサイト統合の実践ステップ

定量と定性を統合してインサイトを導くプロセスは、インサイト統合の方法論で詳しく解説しているが、データドリブン共感に特化した実践ステップを示す。

ステップ1: 定量データで「どこに問いを立てるか」を決める。 セグメント別・フェーズ別・時系列での差分分析を行い、「なぜここだけ違うのか」という問いが生まれる箇所を特定する。この段階でリサーチ対象とリサーチ問いを絞る。

ステップ2: 問いに対応するインタビュー・観察を設計する。 「なぜこのセグメントだけ離脱するのか」という問いがあるなら、対象者は「離脱したユーザー」を中心にリクルーティングする。問いと対象者がずれると、定性調査の結果が定量データの問いに答えられない。

ステップ3: 定性データをコーディングし、定量パターンと照合する。 インタビューや観察から得たエピソードをテーマ別にコーディングし、「このテーマは定量データのどのパターンに対応するか」を照合する。完全に対応しないテーマは、まだデータ化されていない現象の候補だ。

ステップ4: ギャップを「仮説」として扱う。 定性インサイトが定量パターンを説明しない場合、それは測定指標の設計が現象を捉えていない可能性がある。「このインサイトを検証するには何を測定すべきか」という問いが、次の定量調査の設計につながる。

このサイクルはデザインリサーチとマーケットリサーチの違いでも論じているが、検証と発見の往復こそが両者を統合する実践の本質だ。

デザイン思考がKPIを変える

データドリブン共感の成熟した実践は、最終的にKPI設計そのものを変える。

多くの組織が測定しているのは「行動の結果」だ。購入率、継続率、NPS——これらは行動が起きた後の痕跡だ。しかし共感フェーズで得られるインサイトは、「なぜその行動が起きるか」の文脈を示す。文脈を理解すれば、結果の前兆となる「先行指標」が設計できる。

SpotifyがSkip率だけでなく「曲の30秒以上再生率」を先行指標として重視するのは、行動の結果を待たずに「ユーザーが曲を受け入れたか」を早期に検知するためだ。この指標は、データ分析だけでは発想できない。「ユーザーは何をもって『気に入った』と感じるか」という定性的な理解が先にある。

KPIの設計思想についてはデザイン思考とKPI測定で詳しく論じているが、測定すべき指標はユーザーの文脈から逆算されるべきであり、事業の都合から作られるべきではない、というのがデザイン思考の立場だ。

統合を阻む組織の壁

技術的な手順より難しいのは、組織の壁を越えることだ。

データサイエンスチームとUXリサーチチームが別々に存在し、それぞれの成果物が別々の会議で消費される組織では、統合は起きない。データ分析のレポートがプロダクト定例で共有され、ユーザーインタビューのサマリーがデザインレビューで共有されるという分断が続く限り、数字とエピソードが出会う機会はない。

統合を実現する最も確実な方法は、同じチームの中にデータ分析と定性リサーチを同時に配置することだ。 SpotifyがSquadモデルで実現したのはこの構造だ。機能横断チームの中にデータアナリスト、UXリサーチャー、プロダクトマネージャーが同席することで、「この数字が意味することをインタビューで確認しよう」という対話が自然に起きる。

組織設計を変えられない場合でも、共同リサーチプロセスの設計は有効だ。定量分析のレポートをUXリサーチャーがレビューし、「ここを深掘りすべき」という問いを共同で立てる。インタビュー設計の段階からデータアナリストを入れ、「この観察結果が真なら、データ上ではどのパターンになるか」を事前に仮説化する。こうした接点を意図的に作ることが、分断を埋める第一歩だ。

---

定量データは「どこを掘るか」を教える。定性インサイトは「何が埋まっているか」を教える。この二つを統合した共感は、アンケートデータの平均値でも、少数インタビューの印象でもない——測定された現象の背後にある人間の文脈の理解だ。

デザイン思考の共感フェーズは、この統合を組織的に実現するための構造を提供する。データは問いを立て、インサイトが答える。その往復こそが、「データはあるが何を作ればいいかわからない」という状況を抜け出す道だ。

---

参考文献

1. Rikke Friis Dam & Teo Yu Siang, “Empathize with Users to Build Products That Work,” Interaction Design Foundation, 2024. https://www.interaction-design.org/literature/article/empathize-with-users-to-build-products-that-work

2. IDEO, The Field Guide to Human-Centered Design, IDEO.org, 2015. https://www.designkit.org/resources/1

3. Spotify Engineering, “How We Built the Discover Weekly Playlist,” Spotify Engineering Blog, 2015. https://engineering.atspotify.com/2015/12/how-spotify-built-discover-weekly/

4. Creswell, J. W. & Plano Clark, V. L., Designing and Conducting Mixed Methods Research, 3rd ed., SAGE Publications, 2017.

5. Nielsen, J. & Landauer, T. K., “A mathematical model of the finding of usability problems,” Proceedings of ACM CHI’93 Conference, 1993, pp. 206–213.