ユーザビリティテストのやり方｜Web録画との違いと、課題の作り方

ユーザビリティテストは、想定するユーザーに具体的な課題を操作してもらい、どこで迷うか、目的を達成できるかを観察する調査です。

「この画面は使いやすいですか」と感想を聞くだけでなく、実際に使う場面を見ることで、修正する場所を探します。

普段の訪問を振り返るセッションリプレイで気になる動きを見つけたら、その理由を掘り下げる方法として役立ちます。

ただし、課題を渡された参加者の行動と、目的を持って自分から訪問した人の行動は、同じ条件ではありません。

この記事では両者を使い分けながら、課題・参加者・成功条件・記録方法を決める手順を解説します。

初めて実施する担当者向けに、資料請求ページを例にした実施計画書も用意しました。

ユーザビリティテストで確かめること

まずは「何を操作できるようにしたいか」を一つ決め、調査の範囲を絞ります。

自然な訪問の録画と分ける

ユーザビリティテストでは、参加者へ課題を渡し、操作を観察しながら必要に応じて質問します（参考：GOV.UKの実施ガイド）。

一方、セッションリプレイでは、通常の訪問で起きたクリックやスクロールなどの記録を振り返ります。

たとえばClarityの録画は、利用者の画面をそのまま動画撮影したものではなく、HTMLや操作から視覚的に再構成する方式です（出典：Clarityの録画概要）。

観点	ユーザビリティテスト	通常訪問のセッションリプレイ
操作の目的	調査側が課題として提示	訪問者自身の目的
理由の確認	その場や操作後に質問できる	操作記録だけでは直接聞けない
対象の状態	試作品や修正案でも実施できる	計測している実際の訪問が中心
注意点	観察や課題の与え方が行動に影響する	記録されない操作や表示があり得る

二つを組み合わせるなら、録画で気になる工程を見つけ、テストで理由の仮説を確かめる流れが考えられます。

録画にない心の動きを想像で埋めず、質問や追加の観察が必要な部分として残しましょう。

実際の課題から問いを作る

「サイト全体を評価してほしい」では、何ができれば改善したと言えるのかが曖昧になります。

最初の問いは、読者や顧客が達成したいことに結び付けます。

見えている問題	テストで確かめる問い
資料請求ページへ進む人が少ない	欲しい資料を見つけ、請求方法を理解できるか
フォームで戻る操作が多い	入力条件やエラーの直し方が分かるか
料金ページを何度も行き来する	自分に合うプランと必要な費用を説明できるか

この表は、調査の問いを作るための例です。

「申込ボタンを目立たせるべきだ」という修正案から入ると、その案に都合のよい課題を作りやすくなります。

先に「資料を探して請求できるか」を問いにし、ボタン以外の障害も観察できるようにします。

対象ページ、想定ユーザー、確認する操作を一枚のメモに書いたら、関係者で共有してください。

ユーザビリティテストの参加者を決める

参加者の選び方によって、見つかる問題は変わります。

想定ユーザーに近い人を選ぶ

調べたいサービスの実際の利用者、または利用する可能性がある人を選ぶことが基本です（参考：GOV.UKの参加者と計画の説明）。

社内でページの構成を知っている人だけに試してもらうと、初めて使う人の迷いを見落とすことがあります。

社内の試行は、課題文や録画機器が機能するかを確かめる予行演習として使い、利用者の評価と分けて扱いましょう。

募集条件には、調査に必要な違いだけを具体的に書きます。

• 初めて使う人か、継続して使う人か
• 普段その作業を行う立場か
• 主に使う端末はスマートフォンかPCか
• 比較や申込に必要な前提知識があるか
• キーボード操作や支援技術など、利用環境に配慮が必要か

アクセシビリティを調べる場合も、一人の結果を同じ障害のあるすべての人へ広げて解釈しないことが大切です（参考：W3C WAIのユーザー参加による評価）。

調査した人の条件と、今回調べられなかった人の条件を、結果と一緒に残します。

参加条件と同意を整理する

参加者には、調査の目的、記録する内容、閲覧する人、保存期間、途中でやめる方法を事前に説明します（参考：GOV.UKの調査同意ガイド）。

画面録画と音声録音は別の記録なので、何を取得するかを曖昧にしないようにしましょう。

説明しておくこと	決める内容の例
調査の目的	資料請求の操作で分かりにくい場所を見つける
記録する範囲	対象画面、操作、発言、観察メモ
利用と共有	改善担当者が確認し、外部公開は行わない
保存と削除	保存場所、閲覧権限、削除予定日、窓口
中断の方法	途中でも参加をやめられる連絡方法

これは説明事項を整理するための表で、そのまま完成した同意書として扱うものではありません。

調査で使うフォームにはテスト用データを用意し、実際の購入や申込が発生しない環境で確認する方法を検討します。

オンラインで画面を共有する場合は、関係のない通知や別のタブが映らないことも事前に確認してください。

操作課題を作る

課題文では、参加者に達成してほしい目的を伝え、押すボタンや進む順番まで教えないようにします。

答えを誘導しない課題にする

課題には、参加者が現実に置かれそうな状況を短く添えます（参考：NN/gのタスクシナリオ設計）。

次の例は、同じ資料請求を調べるときの課題文の違いです。

手順を教えてしまう課題	目的を伝える課題
右上の資料請求を押してください	導入を検討している上司へ、料金と機能が分かる資料を共有したい状況です
料金タブでGrowthを選んでください	自社の利用条件に合うプランを探し、費用を説明してください
エラーの下の入力欄を直してください	入力した内容で申込を進め、続けられない場合は対応してください

最初の資料請求の例では、「共有する資料を入手するところまで進めてください」と続け、終了する地点を明確にします。

テスト環境で送信しない設計なら、「送信する直前で止めてください」と、必要な制限を別途伝えます。

画面内のメニュー名をそのまま課題へ入れると、情報を探す過程を測れなくなるため注意しましょう。

本番前に同僚へ課題だけを読み上げ、目的と終了地点が伝わるかを確かめると、当日の説明のばらつきを減らせます。

成功条件を決める

成功は「本人ができたと言ったか」だけでなく、観察できる到達状態で決めます。

資料請求なら、対象の資料を選べたことと、テスト用の受付完了まで進めたことを分けて判定します。

課題	成功条件の例	分けて残す状態
必要な資料を探す	指定した情報を含む資料を選べる	別の資料を選ぶ、見つからない
料金を確認する	条件に合う費用と対象プランを説明できる	金額だけ分かる、条件を誤解する
申込を完了する	テスト環境で受付完了を確認できる	入力のみ完了、送信エラー

手助けなしの完了と、ヒントを出したあとの完了も分けます。

成功率を使う場合は、成功の定義を先に決めておく必要があります（参考：NN/gのタスク成功率の解説）。

途中までできた人をどう扱うかも決めておくと、観察者ごとに判定が変わりにくくなります。

ユーザビリティテストを進める

当日は、進行役と記録役を分け、参加者の操作を落ち着いて見られる体制を作ります。

口を挟む場面を決める

冒頭では、参加者の能力を評価するのではなく、サービスの分かりにくい部分を調べることを伝えます。

操作中に考えたことを言葉にしてもらう「思考発話」は、行動の理由を理解する手掛かりになります（参考：NN/gの思考発話法）。

ただし、話しながら操作する条件では、普段と同じ速さや行動になるとは限りません。

操作時間を厳密に比較したい調査では、発話や進行役の介入をどう扱うかも設計しておきます。

状況	進行役の対応例
黙って操作している	必要に応じて、考えていることを尋ねる
意図が分からない操作があった	区切りで、そのとき探していたものを尋ねる
完全に行き詰まった	事前に決めた条件で手助けし、介入を記録する
調査を続けたくない様子	続けられるか確認し、中断できるようにする

「このボタンですよね」と答えを含む質問をせず、「今、何を探していますか」と尋ねます。

進行役が説明したあとに操作できた場合は、その説明も結果に残してください。

画面と発言を分けて記録する

記録には、実際に見えた操作、本人の発言、観察者の解釈を分けて書きます。

GOV.UKのガイドでも、操作の観察と解釈を混ぜず、後から調査を振り返れるように記録する方法が示されています（参考：メモと調査記録のガイド）。

次は、資料請求テストの仮の記録例です。

記録する欄	記入例
場所と時点	課題1、資料一覧へ到達した直後
観察した操作	二つの資料を開き、一覧へ戻った
本人の発言	「料金が入っている資料が分からない」
観察者の仮説	資料の説明に収録内容が足りない可能性
介入	なし
結果	別の資料を選択

録画を残す場合は、問題が起きた時点をメモし、後で必要な場面を探せるようにします。

発言を短く要約した場合は、本人の言葉をそのまま記した引用と区別してください。

テスト結果を整理する

テストが終わったら、参加者ごとの感想集ではなく、操作上の問題ごとに結果をまとめます。

再現する問題をまとめる

「使いにくい」という一言だけでなく、どの条件で何ができなかったのかを記録します。

たとえば「資料名が分かりにくい」なら、選び間違えた資料、探していた情報、画面上の説明を一緒に残します。

複数の参加者が同じ箇所で止まった場合は、一つの問題としてまとめ、それぞれの操作記録へ戻れるようにします。

逆に、同じページで止まっていても、文字が読めない問題と、資料の内容が分からない問題は分けましょう。

分類	例	次に行うこと
操作を完了できない	必須エラーに気付かず送信できない	エラーの表示と案内を見直す
誤った判断になる	対象外のプランを選んでしまう	選択条件の説明を見直す
個人の好み	青より緑が好きと話した	行動上の問題があるか別途確認する
原因が不明	操作が止まったが理由を聞けなかった	追加の観察や質問を計画する

一人だけが経験した問題でも、重要な操作を完全に止めるなら修正対象になり得ます。

人数だけで消さず、起きる条件と影響で判断してください。

Web録画と照合する

テストで見つけた問題を、通常訪問のセッションリプレイでも探すと、別の条件でも起きるかを確認できます。

対象URL、端末、ページの版をそろえてから、該当する操作を振り返ります。

資料を選び直す問題なら、資料一覧と詳細ページの行き来、戻ったあとのクリックなどを見ます。

ただし、同じ動きがあっても、テスト参加者と同じ理由で動いたとは断定できません。

また、録画の欠損や再現のずれがある場合は、表示の不具合と実際の利用者の体験を切り分けます。

録画で見つからなかったことも、その問題が存在しない証明にはなりません。

テストの結果は問題の候補、通常訪問の記録は追加の手掛かりとして扱い、必要ならイベント集計で影響する範囲を調べましょう。

ユーザビリティ改善の優先度を決める

最後に、修正する問題と、修正後に確かめる課題を決めます。

重要な工程を止める問題を選ぶ

優先度は、発生の頻度だけでなく、目的達成への影響や、繰り返し起きるかも踏まえて判断します（参考：NN/gの重大度評価）。

実務では、まず申込・購入・重要情報の確認など、利用目的を達成できなくする問題を確認します。

そのうえで、修正の工数と依存関係を整理し、実施する順序を決めましょう。

小さな見た目の変更を先にできる場合もありますが、重大な問題を後回しにした理由が分からなくならないように記録します。

担当者へ渡すときは、対象画面、問題の起きる条件、観察記録、修正案、再確認する課題を一組にします。

以下は、今回の例を一枚にまとめた実施計画書です。

項目	資料請求ページを試す場合の記入例
調査の問い	必要な資料を見つけ、請求を完了できるか
参加者	サービスを初めて比較検討する担当者
対象と環境	テスト用の資料一覧・請求フォーム、普段の端末
課題	上司へ説明するために料金と機能の資料を入手する
成功条件	適切な資料を選び、テスト用の受付完了へ到達する
記録方法	同意した範囲の画面・音声、操作メモ、介入の有無
担当と準備	進行役・記録役、テストデータ、予行演習
中断条件	本人の希望、機器の不調、事前に決めた行き詰まり
結果の扱い	問題別に整理し、修正案と再テストの課題を決める

この表を自社の目的に書き換え、参加者を募集する前に関係者と確認してください。

修正案で再度試す

修正後は、前回と同じ目的を達成できるかを、同じ成功条件で確かめます。

同じ参加者を使う場合は、前回の操作を覚えている影響を考慮します。

新しい参加者で試せるなら、初めて見ても迷わず使えるかを改めて確認できます。

少人数の調査で「5人中3人が迷った」と分かっても、すべての訪問者の60％が迷うと一般化してはいけません。

W3C WAIも、限られた参加者の結果から広い集団への結論を出すことに注意を促しています（参考：評価結果の解釈と報告）。

調べた条件で問題が改善したかを確認し、実際のサイトへ反映したあとは、通常訪問の記録や成果の集計で変化を追います。

まずは重要な操作を一つ選び、答えを教えない課題と成功条件を作るところから始めましょう。