「ヒートマップでどこが読まれていないかは分かったが、なぜ読まれないのかが分からない」——行動データは「どこで」を教えてくれますが、「なぜ」は教えてくれません。 その答えを取りに行く手段がユーザビリティテストです。
本記事では、ユーザビリティテストを目的設定・タスク設計・実施・分析の4工程に分けて解説します。
記事のポイント
- 5人でテストすれば約85%の問題が見つかる根拠
- タスク設計が結果の質を決める
- 司会がやってはいけないこと
- 観察結果をABテストの仮説に変換する手順
- ヒートマップとの役割分担
目次
- ユーザビリティテストとは
- なぜ5人で足りるのか
- ①目的を決める
- ②タスクを設計する
- ③実施する
- ④結果を改善案に変える
- ヒートマップとの役割分担
- Dejamで定量と定性をつなぐ
- よくある質問
- まとめ
ユーザビリティテストとは
ユーザビリティテストとは、実際のユーザーに特定のタスクを実行してもらい、その過程を観察して問題を見つける手法です。
「感想を聞く」のではなく「行動を観察する」ことが本質です。 感想は事実と一致しません。「分かりやすかったです」と答えた人が、実際には3回迷っていることは珍しくありません。
| 聞く調査 | 見る調査 |
|---|---|
| アンケート・インタビュー | ユーザビリティテスト |
| 意見・態度・記憶が取れる | 実際の行動が取れる |
| 本人が自覚していることしか出ない | 本人が気づいていない迷いも出る |
行動データ（ヒートマップ・GA4）で「どこで落ちているか」を絞ってから実施すると、最小の回数で答えが出ます。
なぜ5人で足りるのか
ユーザビリティテストは大人数を集める必要がありません。
Nielsen Norman Group は、テストで見つかる問題数を次の式で示しています。
見つかる問題数 = N × (1 − (1 − L)^n) （N = デザイン内の総問題数、L = 1人のテストで見つかる問題の割合、n = 被験者数）
Lの典型値は31%（多数のプロジェクトの平均）で、この場合次のようになります。
| 被験者数 | 見つかる問題の割合 |
|---|---|
| 1人 | 約31% |
| 5人 | 約85% |
| 5人以降 | 同じ知見の繰り返しになり、新しい発見が最小化する |
（出典: Why You Only Need to Test with 5 Users - Nielsen Norman Group、Jakob Nielsen, 2000）
同じ資源を使うなら、15人で1回より5人で3回のほうが成果が大きくなります。 見つけた問題を直してから次のテストを回せるためです。
ユーザー層が複数ある場合は、各層3〜4人が推奨されています。 BtoBで「決裁者」と「実務担当」が分かれる場合などが該当します。
①目的を決める
「サイト全体を見てもらう」テストは失敗します。 何を確かめるかを1つに絞ります。
| 悪い目的 | 良い目的 |
|---|---|
| LPの使いやすさを確認する | 料金プランを自分で選べるかを確認する |
| サイトの印象を聞く | 問い合わせフォームを最後まで入力できるかを確認する |
| 改善点を教えてもらう | どの情報が足りずに離脱するかを特定する |
目的は行動データから決めてください。 離脱ヒートマップで料金セクションの離脱が多いなら、目的は「料金プランを自分で選べるか」です。
仮説も先に立てます。 「料金表の項目名が専門用語で理解されていない」のように書いておくと、観察の焦点が定まります。仮説の書き方は「結果の出るABテストは仮説検証ができていた」も参考になります。
②タスクを設計する
タスク設計が結果の質を決めます。 ここが甘いと、何回テストしても学びが出ません。
| 原則 | 悪い例 | 良い例 |
|---|---|---|
| 答えを言わない | 「右上の資料請求ボタンから申し込んでください」 | 「資料を取り寄せてください」 |
| 具体的な状況を与える | 「商品を探してください」 | 「3歳の子ども向けに5,000円以内で贈り物を選んでください」 |
| 完了条件を決めておく | 「見てみてください」 | 「注文完了画面が出たら終了です」 |
| 1タスク1目的 | 「登録して、商品を探して、買ってください」 | 3つのタスクに分ける |
| サイトの用語を使わない | 「マイページに行ってください」 | 「過去の注文履歴を確認してください」 |
サイト内の用語をタスク文に入れてはいけません。 「マイページ」と言った時点で、ユーザーは画面上の「マイページ」という文字を探します。その言葉が伝わるかどうかを検証できなくなります。
タスクは3〜5個が目安です。 1人あたり30〜60分に収まる範囲にします。
本番前にパイロットテスト（社内の1人で試す）を必ず行ってください。 タスク文の曖昧さは、実施して初めて分かります。
③実施する
| 役割 | やること |
|---|---|
| 司会 | タスクを提示し、思考を声に出してもらうよう促す |
| 記録 | 発言・操作・所要時間を記録する |
| 観察 | 発言以外の行動（迷い・戻る・止まる）を記録する |
司会がやってはいけないこと
| やってはいけない | 理由 |
|---|---|
| 操作を教える | そこがまさに検証対象 |
| 「分かりますか？」と聞く | 「分かります」と答えさせてしまう |
| 誘導する（「ここを押すとどうなりますか？」） | 自発的な行動が観察できなくなる |
| 沈黙を埋める | 迷っている時間そのものがデータ |
| 言い訳をする（「まだ開発中でして」） | 遠慮した回答になる |
「思ったことを声に出してください」（発話思考法）を最初に依頼してください。 沈黙が続いたら「今、何を考えていますか？」とだけ聞きます。
「使いにくかったですか？」と聞かないでください。 被験者は気を遣って否定します。聞くなら「今、何を探していましたか？」のように事実を聞きます。
オンラインで実施する場合
画面共有とレコーディングで実施できます。モバイルの検証は、実機のカメラで手元を映すか、画面共有アプリを使ってください。 PCでモバイル表示を再現しても、タップ領域と親指の可動域は検証できません。モバイル固有の論点は「モバイルLP最適化の方法」を参照してください。
④結果を改善案に変える
「使いにくそうだった」で終わらせないでください。 次の形に整理します。
| 記録すること | 例 |
|---|---|
| 何が起きたか（事実） | 5人中4人が料金表で15秒以上止まった |
| 何が原因と考えられるか（解釈） | プラン名が機能名になっており、自社が該当するか判断できない |
| どう直すか（施策） | プラン名の下に「◯◯な企業向け」の一行を足す |
| どう確かめるか（検証） | ABテストで料金セクションからの離脱率を比較する |
「事実」と「解釈」を分けて書くことが重要です。 混ぜると、観察していないことを観察したことにしてしまいます。
5人中1人だけの問題は保留してください。 全員が同じ場所で止まったなら確度が高く、1人だけなら個人差の可能性があります。ただし致命的な問題（購入できない・エラーになる）は1人でも即対応です。
最後は必ずABテストで確かめます。 ユーザビリティテストは5人の観察であり、統計的な検証ではありません。仮説の質を上げる手段であって、勝敗を決める手段ではありません。 検証するアイデアの出し方は「ABテストのアイデア52選」にまとめています。
ヒートマップとの役割分担
| ヒートマップ・GA4 | ユーザビリティテスト | |
|---|---|---|
| 分かること | どこで落ちているか | なぜ落ちるか |
| データ量 | 全ユーザー | 5人 |
| 得意 | 問題箇所の特定 | 原因の推定 |
| 苦手 | 理由が分からない | 一般化できない |
順番は「ヒートマップで絞る → テストで理由を取る → ABテストで確かめる」です。
この順番を守らないと、テストの回数が増えます。 どこが問題か分からない状態でテストを始めると、5人分の観察が散らばって結論が出ません。
ヒートマップの使い方は「ヒートマップとは？種類・見方・LP改善への活用法」、GA4との併用は「GA4とヒートマップの併用方法」を参照してください。
実際の観察例としては「認知的ウォークスルー『マイナビ転職編』」も参考になります。
Dejamで定量と定性をつなぐ
ヒートマップ
熟読・滞在・離脱の3種類で「どこで止まっているか」が5%刻みで分かります。 ユーザビリティテストの目的とタスクは、ここから決めます。テスト後は「観察された問題が全ユーザーでも起きているか」の確認にも使えます。
ABテスト
テストで得た仮説をノーコードで検証できます。5人の観察を全ユーザーの数値で確かめる工程がここです。
自動解析
どのコンテンツがCVRに貢献しているかをAIが解析します。「テストで問題が見つかった箇所が、そもそもCVRに効いているか」の優先順位づけに使えます。
よくある質問
Q. ユーザビリティテストは何人でやればいいですか？
A. 5人です。 Nielsen Norman Group の分析では、1人あたり平均31%の問題が見つかり、5人で約85%に達します。同じ資源なら15人で1回より5人で3回のほうが成果が大きくなります。
Q. 被験者はどう集めますか？
A. 実際のターゲットに近い人を選んでください。 社内の人間は前提知識があるため適しません。ユーザー層が複数ある場合は各層3〜4人が推奨されています。
Q. アンケートやインタビューとの違いは何ですか？
A. アンケートとインタビューは「聞く」、ユーザビリティテストは「見る」調査です。 感想は事実と一致しません。「分かりやすかった」と答えた人が3回迷っていることは珍しくありません。
Q. タスク文はどう書けばいいですか？
A. サイト内の用語を使わず、具体的な状況を与えてください。 「マイページに行ってください」と言うと、ユーザーは「マイページ」という文字を探すだけになり、その言葉が伝わるかを検証できません。
Q. テストの結果はそのまま実装していいですか？
A. 仮説として扱い、ABテストで確かめてください。 5人の観察は統計的な検証ではありません。ただし致命的な問題（購入できない・エラーになる）は1人でも即対応してください。
まとめ
ユーザビリティテストのやり方について、要点を整理します。
- 「感想を聞く」のではなく「行動を観察する」
- 5人で約85%の問題が見つかる（1人あたり平均31%）
- 15人で1回より5人で3回のほうが成果が大きい
- 目的は1つに絞る。行動データから決める
- タスクにサイト内の用語を入れない（その言葉が伝わるかを検証できなくなる）
- タスクは3〜5個。本番前にパイロットテストを必ず行う
- 司会は操作を教えない・誘導しない・沈黙を埋めない
- 「使いにくかったですか？」と聞かない。事実を聞く
- 結果は事実・解釈・施策・検証の4つに分けて書く
- 5人中1人だけの問題は保留。ただし致命的なものは1人でも即対応
- 順番は「ヒートマップで絞る → テストで理由を取る → ABテストで確かめる」
CVR改善ならDejam！「どこで」と「なぜ」を両方そろえる
Dejamは、LP制作・ヒートマップ分析・ABテスト・AI自動解析をオールインワンで提供するCVR改善特化ツールです。「離脱箇所は分かるが理由が分からない」という段階から、仮説を検証して積み上げるまでを総合支援します。
Dejamが選ばれる理由
- ワンプロダクトで完結: LP制作・ヒートマップ分析・ABテストをすべて単一ツールで実施
- 月額3万円〜利用可能: オプティマイズプラン月額3万円〜 / CMSプラン月額5万円〜 / オールインワン月額12万円〜
- ユーザー課金なし: 何名で使っても追加費用は発生しない
- ISMS認証取得: ISO/IEC 27001:2022 & JIS Q 27001:2023認証取得済み
- 毎週アップデート: 市場トレンドとユーザーリクエストに応じて機能を毎週拡充
- 権威ある実績: 代表がダイレクトアジェンダで2連覇。LPO顕彰制度「LPO AWARD」主催者
Dejamの主要機能
- LP/記事LP制作: ノーコード・コードの切り替えに対応。AIで生成したコードを直接取り込み可能
- ヒートマップ: 5種類（クリック/クリックイベント/熟読/滞在/離脱）。データ保存期間無制限
- ABテスト: デザイン変更テスト・リダイレクトテスト・ポップアップテストの3種類。AIが自然言語でテストコードを自動生成
- 自動解析: どのコンテンツがCVRに貢献しているかAIが自動解析。ゴールデンルート機能でページ遷移の最適パスも特定
- プロジェクト管理: 改善施策の進捗をチームで共有できる
ユーザーテストの結果をチームで共有し、施策として管理するところまでDejam内で完結します。 観察が個人のメモで終わると、改善サイクルになりません。
