ユーザビリティテスト（ユーザーテスト）とは
やり方・人数のポイントを解説
ユーザビリティテスト（ユーザーテストとも呼ばれます）とは、サイトやアプリをその想定ユーザーに操作してもらい、その行動と発話を観察して、「どこでつまずくか」（問題）と「なぜつまずくか」（原因）を特定するUI評価手法です。アクセス解析では「どのページで離脱したか」はわかっても、「なぜ離脱したか」まではわかりません。その理由を明らかにして改善策につなげるのがユーザビリティテストです。
こんな課題はありませんか？
- アクセスはあるのに、購入・申し込み・問い合わせにつながらない
- フォームや購入手続きの途中で離脱が多いが、理由がわからない
- GA4などのアクセス解析を見ても、改善の打ち手が決まらない
- リニューアルやアプリ改修の前に、使いにくい点を把握しておきたい
- 社内では使いやすいと思っているが、はじめて使う人の反応がわからない
これらは、ユーザビリティテストで原因を特定できる可能性が高い課題です。
ユーザビリティテスト（ユーザーテスト）とは：目的とわかること
ユーザビリティテストの主な目的は、開発者やデザイナーが気づきにくいサイトやアプリの「わかりにくさ」「使いにくさ」を、ユーザーの実際の行動から見つけて改善につなげることです。作り手は画面を熟知しているため、はじめて使う人がどこで迷うかを想像しにくいのです。
テストでは、たとえば次のようなことがわかります。
- 目的の情報や機能にたどりつけない箇所
- 文章やボタンの文言が意図どおりに理解されていない箇所
- 想定と違う操作手順をたどっているという事実
- 迷い・ためらい・誤操作が起きる瞬間とその理由
評価の観点は、UIが「ユーザーの思考・利用状況・目的に合っているか」だけでなく、「ビジネス側の目的（購入・申し込み・問い合わせなど）を達成できる設計か」にも及びます。
評価対象：サイト・アプリ・組み込みシステムの、現行版でもプロトタイプでも
評価は、参加者が簡易的にでも操作できるUIがあれば可能です（画面でも機械でも音声UIでも）。
ウェブサイト
サービスサイト、LP、見積もり・申し込みフォーム、ECサイト、企業サイトなど
スマートフォンアプリ
EC、クーポン・コード決済、動画サブスクリプション、カメラ連携アプリなど
組み込みシステム
テレビ・STB、自動車・HMI、ATM・セルフ手続き端末、スマートスピーカーなど
ユーザビリティテストによって、一般の消費者向けのサイトやアプリのUIを評価することはもちろん可能です。また、業務用のシステム、たとえば、金融機関職員向けの機械や、小売店の管理者向けの機械などの操作性を評価することもできます。
現行版のUIの問題を探すことを目的に現行版を評価することもできますし、リリース前の改善のために新規やリニューアルの開発最中のプロトタイプを評価することもできます。
ポイント：開発途中の場合、早めのテストをおすすめします。見た目や挙動を作り込んだ評価対象ほど「変更したくない」という心理が働き、終盤で大きな問題が見つかっても修正する時間が残っていないことがあります。開発の早い段階で簡単なかたちにしてテストし、早めに失敗するほうが、改善に十分な時間を割けます（参考：UXプロトタイプ：低忠実度か高忠実度か）。
ユーザビリティテストのやり方（5つのステップ）
ステップ1 目的と評価したいことを決める
「料金情報にたどりつけるか」「申し込みを完了できるか」のように、確かめたいことを具体的にします。アクセス解析で離脱が多いページや、社内で懸念されている箇所などが手がかりになります。
ステップ2 対象ユーザーを定義し、参加者を集める
目的と評価項目に基づいて、年代・利用経験・利用意向などの条件を定め、ネットアンケートなどで条件に該当する人を探し（スクリーニング）、テストへの参加日時を調整します（リクルート）。
ステップ3 シナリオとタスクを設計する
目的と評価項目に基づいて、実際の利用場面に沿ったシナリオ（状況設定）の説明と、スタートとゴールを明確にしたタスク（参加者に実行してもらう課題）の指示をまとめます。
ステップ4 テストを実施する
司会進行役（モデレーター）がシナリオとタスクを提示し、参加者には考えていることを声に出しながら操作してもらいます（思考発話）。観察者は、操作の様子・つまずき・発話を記録します。
ステップ5 分析し、深刻度と改善策をまとめる
つまずいた箇所ごとに「誰が、どう思考・操作し、何が原因か」を分析し、深刻度を判定し、原因に基づいた改善策を検討します。
2から5までの各ステップについて、これから詳しく説明します。
タスク・シナリオの作り方と例
タスクとは、参加者に実行してもらう課題です。人がサイトやアプリを使うときには何らかの背景・目的があるため、それを短いシナリオとして提示します。この内容・指示説明・順序を考えるのが調査設計です。
- 現実的な状況・目的を設定：ユーザーが実際に直面しそうな状況や目的を与え、自然な行動を引き出す
- スタートとゴールを明確に：「どこから始め、どうなれば完了か」をあいまいにしない
- 操作箇所や手順を伝えない：ボタン名や操作手順を伝えて誘導せず、ユーザーの自然な行動を観察する
タスク・シナリオ例（ECサイトの場合）
- シナリオ：普段履いているスニーカーが古くなったため、新しいものへの買い替えを検討しています。
- タスク：1万円以内の軽量なスニーカーを複数比較し、最も欲しいと思った商品を購入してください。
- スタート：ECサイトのトップページ
- ゴール：条件に合ったスニーカーが買い物かごに追加された状態
ダメなタスクの例
- シナリオ：来週、トライアスロンの大会に出場するため、競技用のシューズの購入を検討しています。
- タスク：左上の「≡」メニューから「スポーツ＆アウトドア」の「シューズ」を開き、一覧の中からどれでもいいので商品詳細ページを開き、右側の「買い物かごに入れる」を押してください。
- スタート：ECサイトのトップページ
- ゴール：何らかのスポーツ用シューズが買い物かごに追加された状態
このシナリオは多くの人にとって現実的ではなく、参加者がこの状況を自分ごととして捉えられません。また、タスクは操作手順の指示に終始しています。そのため、ユーザーが自然に商品を探し、比較・検討する行動を観察できず、目的達成のしやすさではなく、決められた操作を実行できるかしか評価できません。
モデレーターの役割と注意点
モデレーターはユーザビリティテストの司会進行役です。タスクの説明、参加者の操作の観察、思考発話（何を考えながら操作しているのかを言葉にすること）の促し、操作意図の確認を行い、事前のプロフィール確認や終了後の総括的な質問も行います。
参加者が安心して率直に話せる関係を作る
- 評価対象はUIであり、参加者の操作スキルではないことを伝える
- わかりにくい／操作しにくい点を率直に話してもらうことがUIの改善につながることを伝える
行動を観察し、その背後にある理由を把握する
- タスク実行中、何を考えながら操作しているのかを言葉にするよう、参加者に促す
- 参加者の操作の意図が不明なときは、適切なタイミングで質問する（誘導的な確認をしないように）
- 参加者に原因分析や改善提案をさせない（参加者はUIデザインの専門家ではなく、当てにならない）
参加者の思考や行動をゆがめない（バイアスをかけない）
- 参加者に操作方法を聞かれても答えず、迷っている行動を観察する
- 誘導的な「ここがわかりにくいのですね？」ではなく、オープンに「何を考えていますか？」と尋ねる
参加者の本音を引き出しつつ結果をゆがめない進行には、専門的な技量と細心の注意が必要です。
参加者として、どんな人を何人集めるか
想定ユーザーに近い人に参加してもらう
ユーザビリティテストでは、「誰にテストしてもらうか」が結果を大きく左右します。評価対象物の想定ユーザーに近い人に参加してもらうため、年代や職業といった属性だけでなく、評価対象物や類似サービスの利用経験・利用意向などの条件に基づいて参加者を募集します。通常は、インターネットアンケートを設計・作成した上で、アンケートパネルに配信して多くの方に回答してもらい、その中から条件に合う人を選定します（スクリーニング）。その候補者に電話して参加日時を調整します（リクルート）。
もし、評価対象物の想定ユーザーとは知識・経験・ニーズが異なる人がテストに参加すると、タスク実行時の思考や判断が実際のユーザーとは異なり、結果の妥当性を疑うことになります。そのため、スクリーニングの条件設定、アンケートの設問・選択肢の設計、リクルート時の電話確認を慎重に行うことが重要です。
5人程度のテストを、改善のたびに繰り返す
定性的なユーザビリティテストの目的は問題の発見ですが、5人の参加者で主要な問題の多く（全体の約85%）を発見できるとされています（Nielsen and Landauer, 1993／下図）。
また、同じUIを評価対象としたテストへの参加者を5人より多く増やしていっても、次第に新たな問題は見つかりにくくなっていきます。同じUIを十数人でテストするよりも、まず5人程度でテストし、見つかった問題を改善し、新たなUIをテストするというサイクルを繰り返すほうが、効率よく品質を高められます。
実施方法：対面でもオンラインでも
ユーザビリティテストは、従来から対面で行われてきましたが、最近ではオンライン（ZoomやMicrosoft Teamsなどのウェブ会議）でも行われるようになりました。
対面でのテスト
対面でのテストでは参加者の表情や手の動きを直接観察でき、非言語的な戸惑いや違和感にも気づけます。
ただ、テスト会場に来てもらう必要があるため、参加者は会場の近くに居住・勤務する人に限定され、移動時間や交通費がかかるという、物理的なハードルがあります。
オンラインでの（ウェブ会議による）テスト
一方、ウェブ会議によるテストにはインターネットにつながればどこからでも参加してもらえます。対面での実施では必要な会場費が（地域によってはモデレーターの出張費も）かからないメリットもあります。
ただ、対面のテストでは可能だった表情や手の動きを直接観察することができなくなりますので、たとえば、スマートフォンでの指の迷いや誤タップ（タップ可能だと思ったが反応しなかった）はわかりません。
そして、ウェブ会議では、通信が途切れる、参加者の音声が聞こえない、画面が共有できないなどの技術トラブルが発生することがあります。弊社では事前の接続テストでこのようなトラブルを極力防いでいますが、その分、対面でのテストより実施までに追加の日数が必要、という時間的なデメリットがあります。
また、公開前のプロトタイプを見てもらう場合、参加者と秘密保持契約を結ぶとはいえ、スクリーンショットを撮影される恐れがあるなど、情報のコントロールが対面の場合より難しい、という欠点もあります。
ユーザーテスト・アクセス解析・インタビューなどとの違い
ユーザビリティテストとユーザーテストの違い
ユーザビリティテストとユーザーテストは、呼び方が違うだけで同じ手法です。どちらも、想定ユーザーに実際に操作してもらい、つまずく箇所とその原因を明らかにする手法を指します。本ページでは「ユーザビリティテスト」と表記していますが、「ユーザーテスト」と読み替えていただいてかまいません。
定性テストと定量テスト
ユーザビリティテストには、定性的なものと定量的なものとがあります。
| 定性的なユーザビリティテスト（一般的） | 定量的なユーザビリティテスト | |
|---|---|---|
| 目的 | 問題の所在と原因を特定し、改善策を探る（形成的評価） | 使いやすさを数値で測り、比較・判定する（総括的評価） |
| 主なデータ | 行動の観察、思考発話、事後ヒアリング | タスク成功率、所要時間、エラー数、満足度スコア |
| 人数の目安 | 5人程度 | 統計的な分析に足る人数（数十人規模） |
| 向いている場面 | 改善点を見つけたい、改善を繰り返したい | リニューアル前後や競合との比較（ベンチマーキング） |
本ページでは、最も一般的な定性的なユーザビリティテストを中心に解説しています。
他の調査・評価手法との違い
| 手法 | 何がわかるか | 向いている場面 |
|---|---|---|
| ユーザビリティテスト | 実際の操作で、どこでなぜつまずくか | UI上のわかりにくさ・使いにくさの原因を特定し、改善したいとき |
| ヒューリスティック評価 | 専門家が経験則に照らして見つける問題点 | 短期間・低コストでUI上の問題を洗い出したいとき |
| アクセス解析 | どのページで何が起きたか（数値） | 問題のありそうな箇所の見当をつけたいとき |
| A/Bテスト | 2つの案のどちらが成果が高いか | 公開後に案を比較して選びたいとき |
| ユーザーインタビュー | 利用の背景、ニーズ、価値観 | 何を作るべきか、なぜ使われるかを知りたいとき |
アクセス解析やA/Bテストでは「何が起きたか」や「どちらがよいか」はわかりますが、「なぜか」はわかりません。ユーザビリティテストは、その「なぜ」を明らかにする手法で、想像ではなく事実に基づいた改善策の検討に役立ちます。
また、ユーザーを深く理解し、ユーザーが何を求めているのかを探る場合にはユーザーインタビューが適しています。一方、ユーザーがうまく使えるのかを確かめ、問題があれば改善する場合はユーザビリティテストが必要です。