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