レッスン3：ユーザビリティテストの設計と実施

このレッスンで学ぶこと

タスクの設計が、テストの結果を大きく左右することを理解する
モデレート法と非モデレート法の違いを説明できる
思考発話法と、司会が誘導しないための言い回しを身につける
少人数の観察でも重大な問題が見えやすい理由と、その主張の前提を正しく理解する

レッスン2では、評価者自身が原則にもとづいて画面を点検するヒューリスティック評価を学びました。このレッスンでは、実際の利用者に画面を操作してもらい、その様子を観察する「ユーザビリティテスト」を扱います。ヒューリスティック評価が専門家の目を借りる手法であるのに対し、ユーザビリティテストは利用者自身の行動を直接観察する手法です。両者を組み合わせることで、感想を観察に変えるという本コースの中心的な考え方が、実務として完成します。

タスク設計が結果を決める

ユーザビリティテストは、参加者に特定の作業を依頼し、その様子を観察する形で進みます。この「特定の作業」をタスクと呼びます。タスクの設計は、テスト全体の質を左右する、最も重要な工程です。

よくある失敗は、「このページをご覧になった感想を教えてください」のように、感想を尋ねるだけの依頼をタスクとしてしまうことです。これでは参加者は画面を眺めて感想を述べるだけで、実際の操作を観察できません。タスクは、参加者が実際に手を動かして達成しようとする、具体的な目的として設計する必要があります。

良いタスクの条件は、次の 3 つです。

具体的な目的がある：「トップページを見てください」ではなく「来月開催されるイベントの参加申し込みをしてください」のように、達成すべき状態を明確にする
答えを誘導しない：「検索窓を使って探してください」のように操作方法を指定すると、本来観察したかった、参加者が自力でたどり着く経路が見えなくなる
実際の利用場面に近い：現実にはあり得ない状況を想定したタスクは、参加者の行動も現実離れしたものになりやすい

⚠️ 注意 タスクの文中に、探してほしい機能の名前をそのまま含めてしまうと、参加者はその名前を画面上で探すだけになり、本来見たかった「迷う様子」が観察できなくなります。機能名を伏せて、目的だけを伝える書き方を心がけましょう。

モデレート法と非モデレート法

ユーザビリティテストの実施方法は、大きく 2 つに分けられます。

モデレート法は、司会役が参加者と同じ場に立ち会い、タスクを依頼しながら、その場でやり取りをしつつ観察する方法です。参加者の反応に応じて追加の質問を挟めるため、行動の背景にある考えを深く理解できます。一方で、司会役の準備と時間の確保が必要になります。

非モデレート法は、参加者が 1 人で、指示に従ってタスクに取り組み、その様子を録画・記録する方法です。司会役が立ち会わないため、都合の良い時間に複数の参加者から同時に記録を集められる利点があります。一方で、参加者が操作の途中で迷っても、その場で質問を投げかけて理由を深掘りすることはできません。

	モデレート法	非モデレート法
司会役の立ち会い	あり	なし
その場での深掘り	できる	できない
実施の手間	大きい	比較的小さい
向いている場面	初期段階の大きな問題の発見、行動の背景理解	数を集めた検証、進捗確認

どちらか一方が常に優れているわけではありません。設計の初期段階で大きな問題を洗い出したい場合はモデレート法が向いており、ある程度形になった画面を数多くの参加者で確かめたい場合は非モデレート法が向いています。

📝 補足 本コースでは、参加者の行動の背景にある考えまで理解できるモデレート法を軸に解説します。非モデレート法を使う場合も、タスク設計の考え方や、誘導しない言い回しの原則は共通して役立ちます。

思考発話法

モデレート法で特によく使われる技法が、思考発話法です。参加者に、画面を操作しながら頭の中で考えていることをそのまま声に出してもらう方法です。「いま何を探しているか」「なぜこのボタンを押そうとしているか」といった思考の過程を、行動と同時に言葉にしてもらいます。

思考発話法が有効なのは、行動の結果だけを見ていても、参加者がなぜその行動を取ったのかまではわからないためです。例えば、参加者が目的のページにたどり着くまでに 3 回クリックをやり直したとします。この事実だけでは、何が原因だったのかは推測にとどまります。しかし、参加者が「この言葉だと、探している内容とは違う気がする」と声に出していれば、原因はラベルの表現にあると特定できます。

思考発話法を始める前には、参加者に趣旨を説明します。「操作の正しさを試すテストではなく、画面のほうを試すテストです」と伝え、参加者が操作に失敗しても評価されるわけではないと安心してもらうことが大切です。この一言があるかないかで、参加者が本音を声に出しやすくなるかどうかが大きく変わります。緊張したまま始めると、参加者は「正しい操作」を探そうとしてしまい、ふだんの自然な行動から離れてしまいます。

🔰 初学者の方へ 慣れていない参加者は、声に出すことを途中で忘れてしまいがちです。沈黙が続いたら「いま何を考えていますか」と穏やかに促しましょう。ただし促しすぎると参加者の集中を妨げるため、10 秒から 20 秒程度の沈黙は待つ姿勢も大切です。

司会が誘導しないための言い回し

司会役の発言は、参加者の行動に大きな影響を与えます。無意識のうちに答えを誘導してしまう言い回しは、テストの結果を歪めてしまいます。

避けたい言い回し	理由	代わりの言い回し
「ここを押せばいいですよ」	操作方法を教えてしまっている	「次に何をしますか」
「これでわかりやすいですよね」	同意を誘導している	「いま、どう感じていますか」
「間違えましたね」	参加者を評価する言葉になっている	（沈黙で待つ、または「いま何が起きましたか」）
「メニューの中を見てください」	探す場所を指定してしまっている	「次にどこを見ますか」

司会役は、参加者にとっての「正解」を示す立場ではなく、参加者の行動と発言をありのまま引き出す立場です。参加者が困っている様子を見ると、つい助け船を出したくなりますが、その瞬間こそ、画面の問題が最も明確に現れている場面です。可能な限り見守り、参加者が自力で解決を試みる様子を観察しましょう。

💡 ポイント どうしても参加者が完全に行き詰まってしまった場合は、無理に沈黙を続けるのではなく、次のタスクに進める判断も必要です。1 つのタスクに固執しすぎると、参加者の負担が大きくなり、後半のタスクへの集中力が落ちてしまいます。

参加者の集め方

ユーザビリティテストの参加者は、実際にその画面を使う可能性のある利用者層に近い人を選びます。社内の別部署の人に頼む、既存の利用者に協力を依頼する、外部の協力者を募るなど、方法はいくつかあります。

参加者を選ぶ際に気をつけたいのは、身近で頼みやすいという理由だけで、開発に関わった人や、その画面に詳しすぎる人を選ばないことです。すでに操作を覚えている人では、初めて触れる利用者が迷う箇所を再現できません。同じ理由で、テストを企画した担当者自身が参加者を兼ねることも避けましょう。

また、複数の異なる利用者層が対象となる画面では、それぞれの層から参加者を集める必要があります。例えば、申請する側の利用者と、それを承認する側の利用者が別々に存在するシステムでは、両方の立場から参加者を集めなければ、片方の視点だけに偏った結果になってしまいます。

参加者を募集する際は、対象条件を確認するための簡単な質問（スクリーニング）を事前に用意しておくと、実施したい利用者層とずれた人を招いてしまう事態を防げます。利用頻度、担当している業務、その画面に触れた経験の有無など、テストの目的に応じて条件を絞り込みましょう。条件を絞り込みすぎると参加者が集まらなくなるため、譲れない条件と、あれば望ましい条件を分けて考えることも大切です。

📖 もっと詳しく ユーザビリティテストと似た響きを持つ手法に、A/B テストがあります。A/B テストは、2 つ以上の案を実際の利用者に無作為に振り分けて配信し、数値の違いを比較する検証手法です。少人数の行動を観察して原因を探るユーザビリティテストとは異なり、多数の利用者を対象に、どちらの案の数値が優れているかを確かめる場面で使われます。

少人数で大きな問題が見える理由と、その前提

ここからは、本コースの中核となる論点を扱います。「少人数を丁寧に観察すると、大きな問題は早い段階で見える」という考え方は、ユーザビリティテストの実務でよく語られる発想です。この背景には、ヤコブ・ニールセン氏が提示したモデルにもとづく主張があります。

このモデルの骨子は、複数の参加者が同じタスクに取り組むとき、深刻な問題ほど、多くの参加者が同じ箇所でつまずく傾向があるという考え方です。1 人目の参加者が迷った箇所に、2 人目、3 人目の参加者も同じように迷えば、それは個人の癖ではなく、画面側に原因がある可能性が高いと判断できます。逆に、非常に稀にしか起きない軽微な問題は、少人数の観察では見つからないこともあります。

ただし、この考え方には重要な前提が付きます。想定している利用者層が 1 つにそろっていること、そして観察するタスクの種類がある程度絞られていることです。前提が崩れると、少人数の観察で見えてくる範囲も変わってきます。

例えば、先ほど触れた「申請する側」と「承認する側」のように、異なる利用者層が混在する画面では、それぞれの層ごとに参加者を集める必要があります。1 つの利用者層のうちの数名を観察しただけでは、もう一方の利用者層特有の問題は見えてきません。同様に、扱うタスクの種類が多岐にわたる場合は、代表的なタスクに絞って観察する設計が必要です。

⚠️ 注意 「少人数でも十分」という考え方を、「何人でも同じ結果が得られる」と拡大解釈しないよう注意してください。あくまで、1 つの利用者層・1 つのタスク群という条件のもとで、重大な問題が早い段階で見えやすいという傾向を指すものであり、あらゆる場面に無条件で当てはまる主張ではありません。異なる利用者層やタスクを扱う場合は、その分だけ参加者の幅を広げる必要があります。

この前提を踏まえたうえでなお、少人数の観察には大きな価値があります。大規模な調査を計画してから着手するのではなく、まず数名の参加者で試し、見えてきた大きな問題から手をつけ、次の観察でさらに確かめるという、小さく回すサイクルが現実的です。完璧な調査計画を待つよりも、早く動き出すことのほうが、多くの現場で効果を上げています。

小さく回すサイクルを続けることには、もう 1 つの利点があります。1 回のテストで見つかった問題を直し、次のテストで直った様子を確かめるという流れを繰り返すうちに、チーム全体に「観察して直す」という進め方が習慣として根づいていきます。年に 1 度の大がかりな調査だけに頼るよりも、小さな観察を継続するほうが、長い目で見て組織の力になります。

記録と共有

観察した内容は、その場限りで終わらせず、関係者に共有できる形で記録します。記録の方法として、次のようなものが挙げられます。

行動記録：参加者がどの画面で、何を、どの順番で操作したかを時系列で書き出す
発言記録：思考発話法で参加者が発した言葉を、できるだけそのままの表現で書き留める
つまずきの一覧：参加者が迷った箇所、誤操作をした箇所を、タスクごとに整理する

記録をまとめる際は、レッスン1で触れた「解釈と事実を分ける」意識が重要です。「参加者は混乱していた」という記録ではなく、「参加者は画面を見たまま操作を止め、その後、前の画面に戻った」のように、行動そのものを書き残します。解釈は、複数の記録を見比べたあとで、まとめて加えるようにしましょう。

関係者への共有では、すべての記録を細かく読んでもらうことを期待せず、重大度の高い問題から順に、短くまとめて伝えることが有効です。参加者の発言をそのまま引用すると、関係者にとって説得力が増します。

記録をまとめる際のもう 1 つの工夫は、映像や音声の記録がある場合、問題が起きた場面だけを短く抜き出して見せることです。長い記録をすべて見返してもらうよりも、数十秒の場面を見てもらうほうが、関係者の理解は早くなります。文章による記録と、短く抜き出した映像を組み合わせると、参加者がその場に立ち会っていない関係者にも、状況が伝わりやすくなります。

講師の現場メモ：数と質、両方が必要だった話

私が生活サービス事業会社で UX リサーチの立ち上げを担当していた頃、年間 20 回以上のユーザビリティテストを運営していました。最初の数回は、とにかく多くの参加者を集めることに力を注いでいました。参加者の人数が多いほど、説得力のある結果になると考えていたからです。

しかし、ある画面のテストで、5 人の参加者のうち 4 人が同じ箇所で同じようにつまずいたにもかかわらず、社内の会議では「たった 5 人の結果でしょう」という反応が返ってきました。人数の少なさそのものが、説得力を弱めてしまっていたのです。

そこで私は、記録の見せ方を変えました。「5 人中 4 人がつまずいた」という数字だけを示すのではなく、4 人がそれぞれ何を考え、どう行動したかを、発言の引用とあわせて時系列で並べて見せるようにしたのです。すると、数字だけを見ていたときには響かなかった会議の空気が変わりました。「たしかに、これは誰が使ってもつまずきそうだ」という声が上がるようになったのです。

数を集めることは、たしかに大切です。しかし、少人数であっても、行動と発言を丁寧に記録し、具体的な場面として関係者に見せることができれば、人数の少なさを補って余りある説得力を持たせられます。数と質は対立するものではなく、両方を意識して初めて、観察が組織を動かす材料になるのだと、この経験から学びました。

まとめ

このレッスンでは、以下のことを学びました。

タスクは、具体的な目的があり、答えを誘導せず、実際の利用場面に近い形で設計する
モデレート法はその場での深掘りに向き、非モデレート法は数を集めた検証に向く
思考発話法は、行動の背景にある考えを言葉として引き出す技法である
司会役は参加者を誘導せず、行動と発言をありのまま引き出す姿勢を保つ
少人数の観察でも重大な問題は見えやすいが、1 つの利用者層・1 つのタスク群という前提のもとでの傾向である
記録は解釈と事実を分け、行動と発言をそのまま書き残す

次のレッスンでは、本コースの中核となる「情報設計」を扱います。利用者が迷わない構造をどう作るか、カードソーティングという手法を使った具体的な進め方まで、厚く掘り下げていきます。

確認クイズ

このレッスンの理解度をチェックしましょう。