よくログ分析などの定量データと、ユーザーインタビューなどの定性データが矛盾する瞬間に出会うことはありませんか？「数字が示す方向とユーザーの声が合わない」といった事態は決して珍しくないないですよね。
これは「どちらかが間違い」と断じるのではなく、両者を再整理することでより深いインサイトが得られることが多々あるのではないか？と僕は感じています。今回は、定量と定性が食い違う原因と、そこから生まれる学びを最大化する再設計プロセスを解説します。
矛盾が起きるよくあるパターン
まず「なぜ矛盾が起きるのか」を整理しましょう。主な原因として次の3つが考えられます。
1. タイムラグやサンプリングの違い
定量データ（ログ解析など）は一定期間の全ユーザー行動を含むことが多い。一方で、インタビューは特定のペルソナや利用状況に絞って行われる場合が多く、調査対象の期間も限られます。
結果的に「行動ログの時期」と「ユーザーがインタビューで語っている最新の意識」にズレが生じ、数字と発言が食い違ってしまう。
2. ユーザー自身が抱える認識ギャップ
インタビュー中には「自分ではこういう行動をしているつもり」と語る一方で、実際のログを見るとまったく異なる使い方をしているケースがあります。
心理学的には、これは自己呈示や社会的望ましさバイアス（“こう答えたい”という欲求）とも関係します。ユーザーが“ありたい姿”を語ること自体はよくある現象。
3. 定量・定性それぞれの分析視点が異なる
ログ解析は行動データを基にしているので「実際にどのボタンが何回クリックされたか」という事実を示す。一方、インタビューは「なぜそこをクリックしたのか、使いにくかった理由は何か」といった背景や心理を探る。
この2つのアプローチは相補的ですが、適切に突き合わせないと「あれ、数字とインタビューが真逆を示してる？」と感じることがあります。
矛盾はインサイトや実態把握の源泉
矛盾に直面すると「どちらかが間違いでは？」と考えがちですが、僕はむしろ定量と定性の矛盾は宝の山だと思います。
- ユーザーが言葉にしていない意外な背景
- ログには映っていない複数人のワークフロー……
こうした見落としをあぶり出すチャンス。
重要なのは、すぐに定量・定性どちらを“正”とするかを決めないこと。特にプロダクトチーム内で「数字は嘘をつかないから」と一蹴してしまうケースがある一方、「ユーザーが言ってるのだからこうすべき」と感覚論に走る場合もある。
両者が示す違いを「新たな仮説」に転換できれば、プロダクト改善の切り口が広がるはずです。
僕が実際に体験した例として、ある機能をユーザーが「全然使えていない」とインタビューで言っているのに、ログを見るとそのボタンは1日何十回もクリックされていたケースがありました。調べてみたら、別部署のアルバイトスタッフが代行していて、インタビュー対象の方は実際に操作していなかった、ということが発覚しました。
この矛盾をきっかけに「利用者は誰か？」「現場の実態は？」という観点でリサーチ設計を立て直し、最終的にアルバイトでも操作しやすいUIや権限設計にアップデートできました。
こんな感じで、矛盾は新たな問いを生む原動力です。
矛盾解消のステップ1：データを改めて検証する
ではここからは、そんな矛盾と遭遇した時のプロセスを説明します。
矛盾を見つけたら、まず定量と定性それぞれのデータがどのように収集・分析されたかを振り返ります。下記のような点を再検証すると、意外な穴が見つかることが多いです。
- 定量データ：集計期間は適切か、サンプリングは偏っていないか、追跡しているKPIやログ指標は正確か
- 定性データ：インタビュー対象の選定基準、質問設計の妥当性、インタビュアーや回答者にバイアスがなかったか
- 外部要因：キャンペーン実施期間とデータ取得時期のズレ、季節要因（繁忙期など）
たとえば、ある期間だけ大幅に割引クーポンを発行していた場合、ログ上は利用率が高まるものの、インタビュー対象者は「いつも割引があるわけじゃないから使わない」と答えるかもしれない。こういった一時的・外部的な要因を見落としていると、簡単に数字と発言がズレる。
このような点を一度棚卸しして、そもそも矛盾がデータ精度やサンプリングミスに起因するものではないかを確かめる。ここで問題が解決すれば早い段階で次のアクションに移れるはずです。
矛盾解消のステップ2：追加インタビューや再仮説で深堀り
データの収集・分析プロセスを見直しても、なお矛盾が残る場合は「両者がともに正しい可能性」を念頭に置く。状況が違ったり、利用者が分散していたり、時間帯や操作する人が違うなどの可能性です。
ここで有効なのが、追加インタビューや再仮説の作成。具体的には以下のような手順を踏むと、整理しやすいです。
- 新しい仮説リストを作成
例えば「実は操作しているのは他の担当者」「限定的な環境（モバイル/PC）でのみ使われている」など、数字と声の両方を説明できる仮説を洗い出す - 該当するユーザー層を改めてインタビュー
必要があれば、部署違いや立場違いの人にも話を聞く。巻き取る対象を広げるほど、矛盾の背景が明確になる - 検証結果をログや行動データと再照合
追加インタビューの内容をもう一度ログと突き合わせ、「その仮説が成立するか」をチェック
このプロセスはやや手間ですが、矛盾を放置したまま開発を進めるより、はるかにリスクが低い。僕自身も定量と定性がかみ合わないときは、改めて「筋の良い仮説」を練り直すところから始めるようにしています。
矛盾解消のステップ3：社内合意の取り方
定量と定性が食い違うと、社内メンバー間でも意見が割れやすいです。たとえば、「数字が正しい派」と「ユーザーの声が正しい派」が対立してしまう。
ここで重要になるのが、事実と仮説を切り分けて伝えること。具体的には次のアクションを取ると、合意形成がスムーズに進みます。
- データソースをオープンに：ログの集計方法や期間、インタビュー対象者や質問リストを可視化し、誰もが検証できる状態にする（SQLを書いているならクエリを共有して全員が見れるようにしましょう）
- 仮説ベースで議論：「この矛盾をこういう仮説で説明できそうだが、どうか？」と問いを投げる。結論を押しつけず、みんなが検証したくなる状況を作る
- 小規模検証を組み込む：アジャイル的に追加インタビューやユーザーテストを実施し、数日～数週間で結果を確認。その場しのぎで終わらないようにする
また、社内報告や共有時には「ログ分析→追加インタビューの流れ」を可視化するのも有効です。
実例：なぜ“使わない”と言いながら高トラフィックが発生したのか
例を用いてより理解を深めていきましょう。
※実体験を元にしながら架空のケースを作っています
とあるテックサービスの管理機能について、ユーザーインタビューでは
- 「正直、あんまり使っていない」
- 「操作しにくいし、導入メリットを感じない」
という声が散見されました。
ところがログを覗くと、毎週一定以上のトラフィックがあり、その管理機能のページがよく開かれている事実がわかりました。
どうして矛盾が起きたのでしょうか？
結果として判明したのは、企業側の経理担当が「他部門の指示で仕方なく操作している」という状態。インタビューに応じていたのはマネージャークラスで、彼らは自分たちが管理機能を触ることはなく、経理担当や派遣スタッフに任せていたのです。
ユーザーが「使ってない」と言っていたのは事実で、一方で「使われている」もログ上では事実。両方が正しい、というケースでした。矛盾に気づいたことで、マネージャークラスだけでなく経理担当や派遣スタッフにも追加インタビューを行い、その結果「操作マニュアル」「画面権限の最適化」など具体的な改善提案に落とし込めました。
定量×定性を強化するためのリサーチ設計ポイント
矛盾を起こさないためには、日頃からログ計測とインタビュー設計を連動させる工夫が大切です。僕が実践しているポイントは以下のとおりです。
- イベントトラッキングやタグ付けを細かく設定：ログで「誰がどんな操作をしたか」をある程度セグメントできるようにする
- インタビュー対象をログから絞り込み：「頻繁に使っている層」「まったく使っていない層」など、使い方が明確に異なる人をあえてピックアップ
- インタビュースクリプトにログ前提の質問を入れる：たとえば「この画面を月に何回くらい使っていますか？」と聞く際、実際のログ回数との比較を事後にチェック
これらを意識すると、定量と定性が補完し合い、あとのフェーズで「実は矛盾が起きていた」状態を少しでも回避できる。特にイベントトラッキングは初期に設計を誤ると後から分析できなくなりがちなので、PMが丁寧に要件を定義するのが重要です。
社内での情報共有とリサーチ体制の仕組み化
また、矛盾が見つかると、迅速に追加インタビューや再仮説検証を行う必要があります。そのためには、社内でのリサーチ体制がある程度整備されていないと難しい。
たとえばインタビュー対象者のリクルーティング手段が常時オープンになっているのか、バイアスの少ない質問リストや録画ツールがチームで共有されているか。
さらに、組織として「ユーザーヒアリングを組織に根付かせる」仕組みを作ることも効果的。矛盾を見つけたときにすぐ“追加の声”が取りにいける環境を整備しておけば、スピード感が大きく違います。
僕はよく生成AIツールを活用して、ユーザーインタビューの文字起こしやログ分析の要点抽出を迅速化しています。とくにChatGPTでユーザーインタビューの分析を爆速にする具体手法はおすすめ。矛盾ポイントの整理や共通項の抽出をサクッと行えるので、チーム内で仮説をシェアしやすくなります。
まとめ：矛盾はイノベーションのきっかけ
定量データとユーザーインタビュー（定性データ）が矛盾するのは、プロダクト開発の現場では当たり前に起こりうる現象です。むしろ矛盾こそが、これまで想定外だった新たな仮説や改善点を生むチャンスになります。
ただし放置すると、開発方針がブレたり、チーム内で対立が深まったりするリスクも無視できません。今回紹介したステップやリサーチ設計を踏まえて、素早く追加検証と合意形成を行うことが大切です。
矛盾の背景にこそ、ユーザーの“本音”が隠れている。そこの解像度を上げることで、本当に解くべき課題が明確になり、プロダクトが一段進化すると僕は信じています。
今日から実践できるアクション
- まずは定量・定性のデータ取得期間や対象者の属性など、前提条件を整理する
- 矛盾点を「新しい仮説」と捉え、追加インタビュー対象を広げる
- ログ分析→ユーザーインタビューの流れを改めて見直し、再検証する手順をチームで共有する
- 社内でデータソースやインタビュー設計をオープンにし、検証を即実行できる仕組みを構築する
- 複雑な要点整理やテキスト要約にはChatGPTなどの生成AIツールを積極活用する
Q&A
- Q. 数字のほうが正しいのでは？ ユーザーインタビューは主観が入るから信憑性が低いのでは？
- A. 双方とも事実を捉えていますが、見え方が異なるだけ。定量データは行動の実測値を、インタビューは行動の背景や心理を示します。どちらが正しい・間違いではなく、互いを補うことで全体像が見えてきます。
- Q. 矛盾が解消されないまま開発を進めても大丈夫？
- A. リスクが高いので追加検証をおすすめします。矛盾は未解決のユーザー課題や利用状況のズレを示すシグナル。放置すると、ローンチ後に想定外のトラブルや低利用が発生する可能性が高まります。ただし、工数や全体に与える影響が少、かつ可逆な意思決定なのであれば定性/定量どちらか確からしい計測をしている方を正とする意思決定も現実としてはあり得ます。
- Q. 社内で「数字派」と「インタビュー派」が対立しています。どうまとめればいい？
- A. ログの前提条件やインタビュー手法をまずオープンにし、仮説として統合する場を作るのが第一歩です。追加インタビューやミニテストを実施し、2～3週間で結果を確認するような小さなサイクルを回すと、実証ベースで合意を得やすくなります。
参考情報
- 「デザイン思考」における定量・定性アプローチの活用：d.school, The Bootcamp Bootleg (Stanford University)
- Card, S. K., Moran, T. P., & Newell, A. (1983). The Psychology of Human-Computer Interaction. Lawrence Erlbaum Associates.
- Ries, E. (2011). The Lean Startup. Crown Business.
- ログ分析→ユーザーインタビューの流れで、「本当に解くべき課題」を明確にする
- ユーザーインタビュー前に「筋の良い仮説」をチームで設定する具体的な方法やフレーム
- ユーザーヒアリングを組織に根付かせる4つの仕組みを考察した
- ChatGPTでユーザーインタビューの分析を爆速にする具体手法を解説
コメント