はじめに：私たちは本当に顧客を理解しているのか？

多くの企業は自社のユーザーをよく理解していると思い込んでいます。しかし、そのほとんどは「確信に満ちた推測」に過ぎません。アンケートで「必要です」と答えたユーザーが、実際のプロダクトではまったく異なる行動をとるケースを、私たちは数え切れないほど見てきました。

問題の本質は ユーザーの「発言」と「実際の行動」の間に存在するギャップ にあります。Erika Hall が指摘するように、直接的な質問は真実の回答を得るための最悪の方法です。人々は自身の本当の動機を常に認識しているわけではなく、質問に自分自身の文脈を上書きし、極端なケースに固執し、短期的な目標を長期的な目標よりも優先させる傾向があるからです。

本記事では、Hannah Shamji の 「顧客理解の4レベル (Four Levels of Customer Understanding)」 フレームワークを基に、表面的なフィードバックの先にあるユーザーの真のニーズと動機を発見するための実戦的な戦略を共有します。

本記事は Smashing Magazine の原文 に触発され、日本の開発者・デザイナーの実務文脈に合わせて再構成しました。

UX researcher observing user behavior on laptop for empathy-driven product design Algorithm Concept Visual

ユーザー理解の4レベル：発言、思考、行動、そして理由

Hannah Shamji が提案する4段階モデルは、ユーザー理解の深さを階層化します。各レベルは互いに矛盾するデータを提供することがあり、真の理解はこれらすべてのレベルを三角測量 (Triangulation) することで得られます。

レベル1：「ユーザーが言うこと」 (What they say)

  • 収集方法: アンケート、CRMデータ、インタビューの文字起こし、NPSスコア
  • リスク: 最も簡単に収集できますが、最も信頼性が低いです。ユーザーは自分の行動を「望ましい方向」に説明しようとする傾向があります。
  • 実務のヒント: NPS (Net Promoter Score) は個人的には推奨しません。スコアそのものよりも「なぜそのスコアをつけたのか」という定性的な文脈の方がはるかに重要です。日本のSI/受託開発環境では、顧客企業の役員の「発言」がプロジェクトの方向性を歪めるケースが多いため、レベル1のデータは常に疑い、クロスチェックする必要があります。

レベル2：「ユーザーが考え、感じていること」 (What they think and feel)

  • 収集方法: 深層インタビュー、文脈的調査 (Contextual Inquiry)、感情マップ (Emotion Map)
  • ポイント: 記憶と好みに大きく影響されます。ユーザーが「この機能は重要です」と言っても、実際には一度も使ったことがないケースがよくあります。
  • ツール推薦: Geoffrey Roberts の 感情ホイール (Emotion Wheel) は、インタビュー中にユーザーの微妙な感情を捉えるのに非常に役立ちます。「良い/悪い」を超えて、「混乱」「疑念」「好奇心」といった具体的な感情を引き出すことができます。

レベル3：「ユーザーが実際にすること」 (What they do)

  • 収集方法: 行動ログ分析 (Amplitude, Mixpanel)、ヒートマップ、セッションリプレイ、タスク分析
  • 重要性: 真の行動データです。ユーザーが「比較テーブルが必要だ」と言っても、実際には検索機能を多用しているなら？ 言葉よりも行動が優先されます。
  • 観察ポイント: マウスがホバーするがクリックしない箇所、スクロール速度の変化、繰り返されるキャンセル/戻る操作。こうした微視的なシグナルが大きなインサイトをもたらします。

レベル4：「ユーザーがなぜそうするのか」 (Why they do it)

  • 収集方法: 縦断的観察 (Longitudinal Study)、日記研究 (Diary Study)、タスクウォークスルー (Task Walkthrough)
  • 難易度: 最も深いですが、最も時間と信頼関係を必要とする段階です。ユーザーとの真の関係構築が不可欠です。
  • 実務適用: 日本のB2B SaaSでは、顧客企業の業務プロセスを2〜3日間実際に追跡する「シャドーイング (Shadowing)」が効果的です。「顧客はなぜこの段階でExcelにエクスポートするのか」という問いへの答えはここにあります。
// 簡単な行動ログ収集の例 (React + GA4 イベント)
// 実際のプロダクトに埋め込んでレベル3データを収集するコード

function trackUserBehavior(eventName, payload) {
  // 例: 'product_compare_click', 'search_used', 'filter_applied'
  window.gtag('event', eventName, {
    ...payload,
    timestamp: Date.now(),
    session_id: getSessionId() // セッションベースの分析
  });
}

// 使用例: 比較テーブル機能の使用有無を追跡
function ProductTable({ products }) {
  const handleCompare = (productId) => {
    trackUserBehavior('compare_table_used', { productId });
    // 実際の比較ロジック
  };

  return (
    <table>
      <thead>
        <tr>
          <th>製品名</th>
          <th>比較する</th>
        </tr>
      </thead>
      <tbody>
        {products.map(p => (
          <tr key={p.id}>
            <td>{p.name}</td>
            <td>
              <button onClick={() => handleCompare(p.id)}>
                比較
              </button>
            </td>
          </tr>
        ))}
      </tbody>
    </table>
  );
}

日本の開発エコシステムにおける適用文脈: 国内スタートアップでは「とりあえず作ってみよう」という文化が強く、レベル1〜2のデータだけでプロダクトの方向性を決めてしまうケースが少なくありません。しかし、これでは「お客様が言った通りに作ったのに使われない」という状況が繰り返されます。最低でもレベル3（行動データ）を併せて見なければ、その「発言」は単なる礼儀や短期的なニーズである可能性が高いです。

Product team analyzing user feedback and behavioral data to improve customer understanding Technical Structure Concept

感情を捉える技術：観察とミラーリング

ユーザーの感情を捉えることは難しいですが、プロダクトの情緒的影響を測定する上で不可欠です。以前は「発話思考法 (Think-Aloud Protocol)」がよく使われましたが、これはむしろ妨害になります。ユーザーが話すことに集中すると、自然な感情反応が隠れてしまうからです。

代わりに、以下の戦略を使用してください：

  1. 沈黙観察: ユーザーがタスクを実行している間は声をかけず、マウスホバー、スクロールパターン、表情の変化（しかめ面、眉をひそめるなど）を記録します。
  2. ミラーリング (Mirroring): ユーザーが言ったことをそのまま繰り返すか、同じ質問を言い換えて再度尋ねます。「先ほどおっしゃった『比較が難しい』という点について、もう少し詳しく状況を説明していただけますか？」
  3. 感情ホイールの活用: インタビューの途中で感情ホイールを見せて、「今、この中のどの感情に最も近いですか？」と尋ねると、ユーザーは自分の感情をより正確に表現できます。

感情だけが全てではない

Alin Buda の強力な反論も心に留めておく必要があります。「私たちの仕事はユーザーの問題、苦痛、混乱を解決することであり、感情を演じたり共感を誇示したりすることではない。」私はこの主張にかなり同意します。感情は シグナル に過ぎません。重要なのは、その感情の背後にある 根本的なニーズと行動パターン を診断することです。

本技術の限界または注意点: 感情分析に過度に依存すると、「ユーザーを喜ばせる」表面的な改善に集中してしまい、本当の問題解決を見失う可能性があります。例えば、ユーザーが「戸惑っている」のはUIが複雑だからかもしれませんが、実際にはその機能自体が必要ないからかもしれません。感情データは常に行動データと一緒に解釈する必要があります。

Designer using emotion wheel tool during user interview to capture nuanced feelings System Abstract Visual

結論：バリデーションではなく、診断をせよ

多くの組織が「ユーザーテストによるバリデーション」を口にしますが、それは往々にして既存の仮定を確認するための道具に過ぎません。真のリサーチとは 先入観なくユーザーの実際の行動を診断すること です。

実務にすぐに適用できる5つの戦略

David Travis が提案する方法の中から、特に日本の組織で即座に導入できる戦略を紹介します：

  1. エクスポージャーアワー (Exposure Hours): 全メンバー（開発者、マーケター、経営陣）が6〜12週間ごとに最低2時間、顧客と直接接触することを義務付けましょう。日本では「コールセンターのモニタリング」や「営業同行」から始められます。
  2. ライブUXテスト: 会社全体が参観できるユーザビリティテストセッションを四半期ごとに開催しましょう。開発者が実際のユーザーが迷う姿を見れば、共感度が完全に変わります。
  3. 共同デザイン (Co-design): 新機能のプロトタイプをユーザーに見せてランク付けしてもらいましょう。「この中で最も必要なものはどれですか？」と尋ねるだけで、レベル2のデータを得られます。
  4. ヘルプデスクインサイト: 3〜6ヶ月ごとにカスタマーサポートの主要な苦情や質問を収集し、プロダクトチームと共有しましょう。「よくある質問」はプロダクトの最大のユーザビリティ問題を反映しています。
  5. リスニングイン (Listening In): カスタマーサービスの電話、ウェブチャット、またはユーザーが活動するコミュニティ（日本ではオープンチャット、Yahoo!知恵袋など）でユーザーの生の声を聞いてみましょう。

合わせて読みたい記事

次のステップとしての学習方向性

本記事で扱った4レベルのフレームワークを実際のプロジェクトで適用してみてください。まずは、現在のチームが主に使用しているデータがレベル1〜4のどこに該当するかを診断することから始めることをお勧めします。その後、1つの戦略（例：エクスポージャーアワー）を選び、3ヶ月間実行し、その前後でプロダクト改善のスピードとユーザー満足度がどのように変化したかを測定してみてください。

核心はシンプルです。 尋ねるな、観察せよ。バリデーションするな、診断せよ。 その違いが、凡庸なプロダクトとユーザーの生活を実際に変えるプロダクトを分ける唯一の道です。

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。