ユーザーリサーチとユーザビリティテストの違いとは？調査フェーズでの正しい使い分け

この記事の要点（UIXHERO視点） UIXHEROでは、ユーザーリサーチを「何を作るべきか発見する」、ユーザビリティテストを「作ったものを検証する」と定義し区別する。リサーチは設計前、テストは設計後。この順序を間違えると「誰も求めていないものを使いやすくする」という無駄が生じる。

導入：「ユーザーテストしましたか？」への違和感

「このデザイン、ユーザーテストしましたか？」

プロジェクトでよく聞くフレーズです。しかし、この質問には曖昧さがあります。

ユーザーに ニーズを聞いた のか？
ユーザーに プロトタイプを触らせた のか？

この2つは全く異なる活動です。前者は ユーザーリサーチ ** 、後者は ** ユーザビリティテスト です。

（なお「ユーザーテスト」という言葉は曖昧なため、本記事では正式名称である「ユーザビリティテスト」を使います）

リサーチとテストを混同すると、「何を作るべきか」と「ちゃんと作れているか」の判断がごちゃ混ぜになる。

この問題を解く鍵が、ユーザーリサーチとユーザビリティテストの使い分けです。

ユーザーリサーチとユーザビリティテストの違い（定義）

ユーザーリサーチは「発見」であり、ユーザビリティテストは「検証」である。

項目	ユーザーリサーチ	ユーザビリティテスト
目的	ユーザーのニーズ・課題・文脈を理解する	UIの使いやすさを評価する
タイミング	設計前（探索フェーズ）	設計後（検証フェーズ）
問い	「何を作るべきか？」	「ちゃんと使えるか？」
対象	ユーザーの行動・目標・課題	UI・プロトタイプ・製品
手法例	インタビュー、観察、日記調査	タスクテスト、シンクアラウド、A/Bテスト

語源と背景

ユーザーリサーチ ** は、人類学・社会学の調査手法がデザインに取り入れられたもので、「ユーザー中心設計（UCD）」とともに普及しました。 ** ユーザビリティテストは、ヤコブ・ニールセンらが「5人で85%の問題を発見できる」と実証し、標準プラクティスになっています。

研究からの引用 : 「5人のユーザーでテストすれば、ユーザビリティ問題の85%を発見できる。」（Jakob Nielsen）

なぜ重要なのか

1. 順序を間違えると無駄が生じる

順序	結果
✅ リサーチ → 設計 → テスト	正しいものを正しく作る
❌ 設計 → テスト（リサーチなし）	誰も求めていないものを使いやすくする
❌ リサーチ → 設計（テストなし）	正しいものを間違って作る

リサーチなしでテストだけ行うと、「そもそもこの機能は必要だったのか？」という根本的な問いに答えられません。

2. 得られる知見が異なる

ユーザーリサーチ : 「ユーザーは〇〇に困っている」「△△が本当のニーズだった」
ユーザビリティテスト : 「このボタンに気づかない」「この言葉の意味がわからない」

リサーチは「問題の発見」、テストは「解決策の検証」です。

具体例・ケース比較

ケース1：ECサイトのリニューアル

フェーズ	ユーザーリサーチ	ユーザビリティテスト
問い	「なぜカート離脱率が高いのか？」	「新しいチェックアウトUIは使いやすいか？」
手法	離脱ユーザーへのインタビュー、行動観察	プロトタイプを使ったタスクテスト
発見例	「送料がいつわかるかわからず不安」「会員登録が面倒」	「住所入力フォームで郵便番号の位置がわからない」
次のアクション	送料早期表示、ゲスト購入機能を設計	フォームのレイアウトを修正

ケース2：社内ツールの改善

フェーズ	ユーザーリサーチ	ユーザビリティテスト
問い	「現場はどんな業務で困っているか？」	「新機能は現場で使えるか？」
手法	現場観察（シャドーイング）、コンテキストインタビュー	実際の業務データを使ったテスト
発見例	「Excelとの行き来が多い」「承認フローが複雑」	「一括インポート機能の場所がわからない」
次のアクション	Excel連携機能、承認フロー簡略化を設計	ナビゲーションにインポートボタンを追加

ケース3：新規プロダクト開発

フェーズ	ユーザーリサーチ	ユーザビリティテスト
問い	「このプロダクトに市場はあるか？」	「MVPは最低限使えるか？」
手法	問題インタビュー、競合ユーザーへの調査	ペーパープロトタイプ、コンセプトテスト
発見例	「既存ツールに不満はあるが、乗り換えコストが高い」	「価値は伝わるが、初期設定で詰まる」
次のアクション	乗り換えコストを下げる機能を検討	オンボーディングを強化

実務でなぜ区別すべきか

UIXHEROがこの2つを厳密に区別する理由は3つあります。

1. 予算・スケジュールの配分が異なる

	ユーザーリサーチ	ユーザビリティテスト
タイミング	プロジェクト初期	設計中〜リリース前
頻度	プロジェクトあたり1〜2回	イテレーションごとに複数回
コスト	高め（深い調査が必要）	低め（5人で十分）

「ユーザー調査」と一括りにすると、適切な予算配分ができません。

2. 必要なスキルが異なる

	ユーザーリサーチ	ユーザビリティテスト
聞き方	オープンクエスチョン、深掘り	タスク指示、観察
分析	親和図法、テーマ分析	タスク成功率、エラー分類
アウトプット	ペルソナ、ジャーニーマップ	課題リスト、改善提案

リサーチャーとテスターは、重なる部分もあれば異なるスキルも必要です。

3. 「テストすればいい」という誤解を防ぐ

「ユーザーテストすればOK」という考えは危険です。テストで発見できるのは「UIの問題」であり、「そもそも何を作るべきか」はリサーチでしか発見できません。

よくある質問 (FAQ)

Q1. 時間がないときはどちらを優先すべきですか？

状況によります 。

新規プロダクト・大きな方向転換 : リサーチを優先。間違った方向に進むと、後で大きな手戻りが発生する
既存プロダクトの改善 : テストを優先。すでにユーザーニーズはある程度わかっている前提で、UIの改善に集中

どちらも省略すべきではありませんが、フェーズに応じて重みづけを変えます。

Q2. インタビューはリサーチですか？テストですか？

目的によります 。

「普段どんな課題がありますか？」→ リサーチ （課題発見）
「このプロトタイプを使って〇〇してください」→ テスト （検証）

同じ「インタビュー」という手法でも、目的が異なれば位置づけが異なります。

Q3. A/Bテストはユーザビリティテストですか？

別物として捉える方が実務的 です。

	観察型ユーザビリティテスト	A/Bテスト
データ	定性（観察、発話）	定量（コンバージョン率）
規模	5〜10人	数千〜数万人
発見	「なぜ使いにくいか」	「どちらが成果が出るか」

A/Bテストは「どちらが良いか」はわかりますが、「なぜ良いか」はわかりません。両者は補完関係にあり、組み合わせて使うのが理想です。

まとめ

ユーザーリサーチ : ユーザーのニーズ・課題を発見する（設計前・探索）
ユーザビリティテスト : UIの使いやすさを検証する（設計後・検証）
使い分け : リサーチで方向を定め、テストで品質を担保する。両方を適切なタイミングで行うことで、「正しいものを正しく作る」ことができる。

「ユーザーテストしました」では不十分。「何を発見し、何を検証したか」を語れるチームが、良いプロダクトを作る。

ページを読み込み中...