アクセス解析を見ると、どのページで離脱が多いかは分かります。しかし、なぜそこで離れるのかは、数値だけでは分かりません。
その理由を確かめる方法が、ユーザビリティテストです。ユーザビリティとは、サイトやアプリがどれだけ使いやすいかを表す言葉で、テストでは実際の利用者に具体的な作業を頼み、迷ったり止まったりする様子を観察します。
少人数でも始められます。担当者が最初に決めるのは、確かめたい問いと、参加者に頼む作業の2つです。この記事では、進め方の6手順、作業の作り方、参加者と人数の考え方、観察結果を課題の優先順位にして改善へつなげる方法を説明します。実施前の確認項目はチェックリストにまとめました。
ユーザビリティテストとは｜数値で分からない離脱の理由を確かめる手法
ユーザビリティテストは、実際の利用者（またはその代わりになる人）にサイトやアプリを使ってもらい、行動を観察して使いにくい点を見つける手法です。完成したページだけでなく、試作段階の画面でも実施できます。ユーザビリティやユーザー体験（UX）の研究・コンサルティングを専門とする組織「Nielsen Norman Group（ニールセン・ノーマン・グループ）」は、質の高いユーザー体験に至る唯一の道は、設計の早い段階からユーザーテストを始めることだと述べています。
ユーザビリティの考え方は、Nielsen Norman Groupが整理しています。同グループは、ユーザビリティを「ユーザーインターフェースがどれだけ使いやすいかを評価する品質特性」とし、次の5つの要素で捉えます。
| 要素 | 確かめること |
|---|---|
| 学びやすさ | 初めて使う人が、基本の作業をどれだけ簡単にできるか |
| 効率 | 使い方を覚えた後に、作業をどれだけ速く終えられるか |
| 覚えやすさ | しばらく使わなかった人が、どれだけ簡単に使い方を思い出せるか |
| エラー | 間違いがどれだけ起き、どれだけ深刻で、どれだけ簡単に立て直せるか |
| 満足度 | 使っていてどれだけ心地よいか |
ここでは、問い合わせや申し込みの導線を調べるときは「学びやすさ」と「エラー」を主な確認対象として扱います。初めて訪れた人が目的の操作にたどり着けるか、間違えたときに戻れるかが、完了できるかどうかを左右するためです。
アクセス解析とユーザビリティテストは、役割が違います。
| 手法 | 分かること | 分からないこと |
|---|---|---|
| アクセス解析 | どのページで、どれだけの人が離れたか | 離れた理由 |
| ユーザビリティテスト | どの操作で、なぜ止まったか | 問題が起きている人の全体での割合 |
解析で見つけた離脱の多い場所を、テストで掘り下げる使い方が基本です。
テストで分かること、分からないこと
テストで分かるのは、利用者が実際に操作したときの行動です。たとえば、次のような点が見つかります。
- ボタンやリンクが見つからず、探し回った場所
- 担当者には自明でも、利用者には意味が伝わらない言葉
- 想定と違う順番で操作された箇所
- 入力フォームで間違えやすい項目
一方で、テストの結果から「何％の利用者が困っているか」は分かりません。参加者は少人数のため、割合や傾向の強さは測れないからです。また、商品への関心や購入意向といった気持ちも、作業の観察だけでは判断できません。
割合を知りたい場合は、アクセス解析やアンケートなどの数値で確かめます。
ユーザビリティテストのやり方｜6つの手順
確かめたい問いを決めてから、整理までを順に進める
進め方は、次の6手順です。
- 確かめたい問いを1つに絞る
- 参加者に頼む作業（以下、タスク）を決める
- 参加者を決めて集める
- 当日の台本と記録の方法を準備する
- 実施して、行動を観察する
- 結果を課題にまとめ、優先順位をつける
最初の手順では、「サイト全体の使いやすさを調べる」のように広い問いを立てないことが重要です。テストが長くなると参加者が疲れ、観察の精度も落ちます。たとえば「資料請求のフォームに、初めて訪れた人が迷わずたどり着けるか」のように、1つの導線に絞ります。
タスクの作り方｜離脱が多い場所から逆算する
タスクとは、参加者に頼む具体的な作業です。タスクの作り方で、観察できる内容が大きく変わります。
離脱が多い場所の見つけ方は、ユーザー導線分析の方法で、GA4とヒートマップを使った手順を説明しています。
目的と状況を伝え、操作の手順は教えない
タスクは、参加者が自分の目的を持って操作できるように、状況を添えて頼みます。操作の手順や画面上の言葉をそのまま指示すると、実際の探し方を観察できません。
| 悪い例 | 良い例 |
|---|---|
| 「お問い合わせ」ボタンを押して、フォームを開いてください | ある会社のサービスについて、資料を取り寄せたいとします。取り寄せるところまで進めてください |
| 検索してください | 競合のサービスと比べるため、料金の目安を調べたいとします。このサイトで探してください |
悪い例の1行目では、ボタンの場所と名前を教えてしまっています。2行目は検索機能を使うよう指示しているため、利用者が検索窓を使うのか、メニューから探すのかを観察できません。実際の利用者は、「お問い合わせ」という言葉を探しているとは限りません。「資料がほしい」人が「資料請求」を探すのか、「お問い合わせ」から探すのかは、手順を教えない状況でしか観察できません。
タスクの種類を使い分ける
タスクには2つの種類があります。
- 完了を確かめるタスク：「資料請求を完了してください」のように、成功か失敗かがはっきり分かるタスクです。完了できたかどうかを数えられます。
- 自由に探してもらうタスク：「このサイトで、自社に合うサービスを探してください」のように、進め方を参加者に任せるタスクです。想定していなかった探し方が見つかりやすくなります。
一例として、初めてのテストでは、完了を確かめるタスクを中心にして、最後に自由に探してもらうタスクを1つ加えると進めやすくなります。
成功の基準を先に決める
タスクごとに、どの状態になれば完了とするかを、実施前に決めておきます。「資料請求の完了画面が表示されたら成功」のように具体的に書いておくと、複数の参加者の結果を同じ基準で比べられます。
参加者の選び方と人数｜5人で足りるとは限らない
誰に頼むか
参加者は、サイトの想定利用者に近い人から選びます。サイトを作った担当者や、サービスをよく知る社内の人にテストを頼むと、結果が偏ります。サイトの作り手を前にすると、使いにくさを遠慮して伝えにくくなる点にも注意が必要です。
利用者の種類が複数ある場合は、種類ごとに参加者を分けます。たとえば、初めて訪れた人と、すでに取引のある人では、探し方も迷う場所も違います。募集の際は、事前のアンケートで「サービスの利用経験」「普段のネット利用の頻度」などを聞き、想定利用者に当てはまる人を選びます。
5人という目安
人数の目安としてよく挙げられるのは、5人という数字です。Nielsen Norman Groupは、1人のテストで見つかる問題の割合は、調べた多くのプロジェクトの平均で31％だったと説明しています。この値をもとに、最初の5人で問題の約85％が見つかるとしています。
また、5人を超えると同じ発見を繰り返し観察することが増えるため、1回の調査を大きくするより、5人以下の小さなテストを予算の許す限り何度も行うほうがよいとしています。15人分の予算があるなら、15人で1回行うのではなく、5人ずつ3回に分ける進め方が示されています。
人数の決め方
5人の組は、問題の99％を見つけた組もあれば、55％にとどまった組もあった（60人のテスト結果から無作為に抽出）
ただし、この数字は、どのテストでも5人で十分という意味ではありません。Faulkner（2003）は、60人にテストをした結果から5人以上の組を無作為に取り出して比べました。5人の組の中には問題の99％を見つけた組もあれば、55％しか見つけなかった組もありました。10人にすると、最も低い組でも80％、20人では最も低い組でも95％まで上がっています。5人では見つかる問題の割合が大きく振れることを示した研究です。
この2つを合わせると、人数は目的で考えるのが現実的です。
| 目的 | 人数の考え方 |
|---|---|
| 大きな使いにくさを早く見つけて直したい | 5人前後で実施し、直してから再度5人前後で実施する |
| 見落としを減らしたい（問題が多そうなサイト、重要な申込み導線など） | 人数を増やす。最も低い組の発見率は、10人で80％、20人で95％と上がる |
| 利用者の種類が複数ある | 種類ごとに参加者を集める |
人数は、これらの研究の数字を目標値にするのではなく、予算と見落としの許容度から決めます。5人で始めても、結果に不安があれば追加します。
当日の進め方｜観察で見るもの
準備するもの
当日は、進行役、記録係、画面と音声の記録手段を用意します。進行役が観察と記録を兼ねると、参加者の様子を見落としやすくなります。台本を作り、説明の言い方やタスクの伝え方を参加者ごとに変えないことも、結果を比べるために必要です。
冒頭の説明と、進行中の声かけ
開始時には、次の3点を伝えます。
- 試されているのは参加者ではなく、サイトである
- 迷ったり間違えたりしても、参加者の失敗ではない
- 考えていることや、探しているものを声に出してほしい
進行中は、できるだけ口を挟みません。画面の前で止まっても、すぐに答えを教えず、「いま何を探していますか」「ここに何があると思いましたか」と聞いて、考えを引き出します。答えを教えてしまうと、実際の利用場面でその人が止まってしまう場所が分からなくなります。
何を記録するか
記録する項目を決めておくと、後の整理が楽になります。
| 記録項目 | 見るポイント |
|---|---|
| 完了・未完了 | 事前に決めた成功の基準を満たしたか |
| 迷った場所 | どの画面で、どれだけ探し回ったか |
| 言葉の受け取り方 | ボタン名や見出しを、意図と違う意味で読んでいないか |
| 想定外の操作 | 設計時に想定していなかった順番や場所を使っていないか |
| 発言 | 迷ったときや完了したときに、何を言ったか |
進行役が参加者の隣に付く対面の方式のほか、参加者が一人で行い、画面の記録を後から確認する方式もあります。後者は多くの人を同時にテストできる反面、その場で理由を聞けないため、問いを絞ったタスクに向きます。
課題の見つけ方｜事実と解釈を分けて整理する
観察が終わったら、メモを課題にまとめます。この段階で意識するのは、起きた事実と、その原因の推測を分けて書くことです。
| 項目 | 書く内容 | 例（仮想例） |
|---|---|---|
| 場面 | どの画面のどの操作か | 資料請求フォームの入力画面 |
| 起きたこと（事実） | 参加者が実際にしたこと、言ったこと | 「会社名」の入力欄で手が止まり、「個人でもいいのかな」と言った |
| 考えられる原因（解釈） | 事実から推測した理由 | 個人の利用者も対象か、入力欄の説明では分からない |
| 起きた人数 | 何人に同じことが起きたか | 参加者のうち3人 |
事実と解釈を同じ欄に書くと、後から課題の根拠をたどれなくなります。解釈が違っていても、事実の欄を見れば、別の原因を考え直せます。
優先順位のつけ方
影響が重く、多くの参加者に起きた課題から先に直す
課題が複数見つかったら、優先順位をつけます。この記事では、次の3つの観点で判断します。
| 観点 | 見ること |
|---|---|
| 影響の重さ | タスクを完了できなくなるか、少し手間が増えるだけか |
| 起きた広がり | 参加者の何人に、同じことが起きたか |
| 直しやすさ | 文言の変更で済むか、画面の作り直しが要るか |
タスクを完了できなくなる課題で、複数の参加者に起きたものは、最優先になります。直しやすい課題は、他の課題より先に直してしまう判断もあります。
改善につなげる｜直して、再テストし、数値で確かめる
確かめた結果をもとに、次の場所探しへ戻って繰り返す
課題を一覧にしても、直さなければ成果になりません。優先度の高い課題から、改善案を作ります。
改善案は、課題の原因に対応させて書きます。仮想例では、フォームの会社名欄で止まった参加者が複数いました。原因が「個人の利用者も対象か分からない」ことなら、欄の近くに「個人の方は空欄で構いません」と説明を足す案になります。画面全体の作り直しは、この時点では不要です。
直したら、同じタスクで再度テストします。改善した箇所で、前回止まった場所を通過できたか、直したことで別の場所が使いにくくなっていないかを確認します。
公開後は、アクセス解析の数値で効果を確かめます。テスト前に決めた導線の離脱の割合を、改善の前後で、同じ期間の長さと条件で比べます。季節や流入元の変化など、改善以外の要因でも数値は動くため、効果の確認は目安として扱います。
テストと改善を継続して回す全体の枠組みは、CROの考え方と改善サイクルで整理しています。
よくある失敗と避け方
- 社内の人だけで実施する：サイトを知っている人は、迷う場所を知らずに通過します。想定利用者に近い人を入れます。
- 参加者の意見をそのまま採用する：「ボタンを大きくしたい」といった要望は、行動の観察とは別物です。観察された行動を根拠に、原因を考えます。
- 課題を並べて終わる：優先順位と担当、直す時期まで決めて、はじめて改善に進めます。
実施前のチェックリスト
- 確かめたい問いを、1つの導線に絞った
- アクセス解析で、離脱が多い場所を確認した
- タスクを、画面上の言葉や操作手順を示さずに実行できる内容にした
- タスクごとに、成功の基準を決めた
- 参加者を想定利用者に近い人から選び、利用者の種類ごとに分けた
- 進行役と記録係、画面と音声の記録手段を用意した
- 事実と解釈を分けて書く記録表を準備した
- 優先順位を決める観点（影響の重さ、広がり、直しやすさ）を決めた
- 改善後に再テストする予定と、数値で確かめる指標を決めた
まとめ
ユーザビリティテストは、アクセス解析で見つけた離脱の理由を、利用者の行動から確かめる手法です。
- 位置づけ：解析は離脱の場所、テストは離脱の理由を調べる。テストでは離脱の割合は測れない
- タスク：目的と状況を伝え、操作の手順は教えない。成功の基準を先に決める
- 参加者：想定利用者に近い人を、利用者の種類ごとに集める。社内の人だけにしない
- 人数：5人前後の小さなテストを繰り返す考え方がある。一方で、5人では見つかる問題の割合が大きく振れる。目的と予算で決める
- 整理：事実と解釈を分け、影響の重さ、広がり、直しやすさで優先順位をつける
- 改善：直して再テストし、アクセス解析の数値で効果を確かめる
まずは、離脱が多い導線を1つ選び、その導線を使う想定利用者に近い数人にタスクを頼むところから始めてください。
参考文献・データ元
この記事で参照した情報を確認できます。
閲覧日は2026年10月20日です。
- Nielsen Norman Group「Usability 101: Introduction to Usability」 https://www.nngroup.com/articles/usability-101-introduction-to-usability/
- Nielsen Norman Group「Why You Only Need to Test with 5 Users」 https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
- Faulkner, L.（2003）「Beyond the five-user assumption: benefits of increased sample sizes in usability testing」Behavior Research Methods, Instruments, & Computers, 35(3), 379-383. DOI: 10.3758/bf03195514（PubMed ID 14587545）
‹ 親記事: CROとは？コンバージョン率最適化の考え方・KPI・改善サイクル
