「ユーザビリティテストで使う質問例を教えてほしい」とよく聞かれますが、ユーザビリティテストの本質は「質問」ではなく「観察」 です。
質問を中心に設計すると、本来観察すべきものが見えなくなります。本記事ではユーザビリティテストの正しい設計、タスクの作り方、観察すべきポイント、そして補助的な質問の使い方を整理します。
ユーザビリティテストとは
ユーザビリティテストは、実際のユーザーが製品/サービスを使う様子を観察し、使いにくさ（ユーザビリティ問題）を発見する 定性調査手法です。
| 観点 | ユーザビリティテスト | ユーザーインタビュー |
|---|---|---|
| 中心 | 行動の観察 | 対話 |
| 対象 | 使う場面そのもの | 使った経験の記憶 |
| 場 | 製品を操作してもらう | 会話のみ |
| 発見 | 具体的な使いにくさ | 動機・価値観 |
ユーザビリティテストでは 「何を聞くか」より「何を観察するか」 が重要です。
質問ではなくタスクを設計する
ユーザビリティテストの中心は 「タスク」 です。
タスクとは
「実際にやってもらう作業の指示」です。
タスク例：
「あなたは40代の会社員で、来月の社員旅行の幹事になりました。
30人のスケジュール調整をしたいです。
このサイトを使って、希望日の候補を募るアンケートを作ってください。」
タスクには以下を含めます：
- 具体的な状況設定（誰として、何のために）
- 達成すべきゴール
- 必要な制約（時間、予算など）
「アンケートを作ってください」という抽象的な指示ではなく、具体的な状況を描写 することで、ユーザーが現実に近い行動を取れます。
タスク設計のポイント
ポイント1：ゴールを設定する（手順は教えない）
× 「左上のメニューから新規作成をクリックしてください」（手順の指示）
○ 「30人にスケジュール調整アンケートを送りたいです。やってみてください」（ゴールのみ）
手順を教えると、ユーザーが自然に取る行動 が観察できなくなります。
ポイント2：3〜5タスクに絞る
1セッション60〜90分で、深く観察できるのは3〜5タスク が限界。それ以上は集中力が切れます。
ポイント3：難易度を段階的に上げる
タスク1：簡単（基本機能の確認）
タスク2：中程度（少し探す必要あり）
タスク3：難しい（複雑な操作）
タスク4：応用（典型的な業務シナリオ）
最初に難しいタスクで挫折させると、以降のテストの精度が落ちます。
ポイント4：「できなかった」も成果
タスクが完了できなくても、それは 「ユーザビリティの問題発見」という成果。「全員にタスクを成功させる」のは目的ではありません。
「Think-aloud（思考発話）」プロトコル
ユーザビリティテストの中心技法。ユーザーに「考えていることを声に出してもらう」 手法です。
実施の作法
モデレーター：「いま考えていることを、声に出してもらえますか？」
ユーザー：「えーと、新しいアンケートを作るので、
右上に『新規作成』ボタンがあるかな……
あ、ここに『+』ボタンがある。これかな？
でも、これでアンケートが作れるかわからない……」
このように 「迷い」「探索」「気付き」 を声で表現してもらうことで、画面上では見えない 思考プロセス が観察できます。
Think-aloudの注意点
- モデレーターが解説しない。「これは○○ですよ」と教えると意味がない
- 沈黙しているユーザーには促す。「いま何を考えてますか？」と適度に声をかける
- 判断しない。「正しい」「間違い」と評価しない
補助的な質問のタイミング
質問はあくまで補助。タスク中・タスク後に限定的に使います。
タスク中の質問（最小限）
1. 「いま何を考えていますか？」（思考の促し）
2. 「いま何を探していますか？」（行動の確認）
3. 「これは予想通りでしたか？」（期待値の確認）
タスク後の質問
1. 「タスクを通して、特に困ったことは何でしたか？」
2. 「使いにくかった部分はありましたか？」
3. 「期待していたものと違ったところは？」
4. 「もう一度同じことをするとしたら、何を変えたいですか？」
5. 「全体的な評価を1〜10で言うとしたら、何点ですか？」（簡易定量）
セッション最後の質問
1. 「全体を通して、最も印象に残ったことは？」
2. 「他に伝えたいことはありますか？」
3. 「友人に薦めるとしたら、どう説明しますか？」
ここからが本題 — 「できますか？」と聞いた時点で失敗
最も多い失敗が 「できますか？」と聞くこと です。
なぜ失敗なのか
× モデレーター：「アンケート作成、できそうですか？」
ユーザー：「はい、できそうです」
実際：3分後に詰まり、5分後にギブアップ
「できますか？」と聞かれると、ユーザーは 無意識に「できます」と答えがち。これは：
- 自尊心を保ちたい心理
- モデレーターを失望させたくない
- 「できない」と言うと自分が無能に思われる不安
これらの心理から 本音と乖離 します。
正しいアプローチ
○ モデレーター：「では、やってみてください。考えていることを声に出しながらお願いします」
（ユーザーの実際の行動を観察）
ユーザー：「えーと、どこから始めれば良いか……」
（迷っているのが観察できる）
「やってもらって観察する」が原則。「できそう？」と聞かない のがユーザビリティテストの基本ルールです。
観察すべき5つのポイント
ポイント1：詰まる場所
ユーザーが 数秒〜数十秒迷う場所 はユーザビリティ問題の可能性が高い。
ポイント2：誤った操作
ユーザーが 間違った場所をクリック・タップ する場面。期待値と実装のズレが見える。
ポイント3：表情・声のトーン
「あれ？」「なんで？」「もしかして……」など、感情を表す言葉 が出る瞬間に注目。
ポイント4：諦めるタイミング
タスクを 諦める瞬間 は、ユーザビリティ問題の頂点。「もうダメだ」「分からない」が出たら必ず記録。
ポイント5：自分流の解釈
ユーザーが 製品の意図と異なる解釈 をする瞬間。「これは○○のボタンだと思った」など。
ユーザビリティテストの実施パターン
パターン1：対面テスト
- リサーチャーと対象者が同じ場所
- 表情・身体反応も観察可能
- 工数大、対象者の負担も大
パターン2：リモートテスト（ツール使用）
- Zoom + 画面共有 + 録画
- 距離・時間の制約が小さい
- 表情の細部は対面より見えにくい
パターン3：非同期テスト
- 専用ツール（Maze、UserTesting等）
- ユーザーが自分のタイミングで実施
- 規模が出せるが、深い観察は難しい
アンケートとの組み合わせ
ユーザビリティテストは n=5〜10 が標準。これだけでは規模が出ないため、アンケートと組み合わせるのが理想：
組み合わせパターン
1. アンケートで「使いにくい」と回答した人を抽出
↓
2. その人にユーザビリティテストを実施
↓
3. 具体的な詰まりポイントを発見
↓
4. UI改善実施
↓
5. 改善後にアンケート再実施で効果検証
ユーザーインタビューとアンケートの違い で扱った定性×定量の組み合わせがそのまま当てはまります。
ユーザビリティテストでよくある失敗
失敗1：タスクが抽象的すぎる
× 「サイトを使ってみてください」
○ 「あなたは○○の状況で、××を達成したいです。やってみてください」
失敗2：モデレーターが助けすぎる
ユーザーが詰まっていると、つい「ここをクリックすると...」と教えたくなりますが、これは 観察の機会を逃す行為。
失敗3：1人だけでテストして結論付ける
n=1では特殊事例の可能性大。最低5名 を観察しないと共通パターンが見えません。
失敗4：知り合いだけでテストする
身近な人は 製品理解が高すぎ て、本物のユーザーの反応が再現できません。意図的に 製品を知らない人 を含める。
失敗5：定量化を強要する
「使いやすさを10点満点で」は便利な指標ですが、ユーザビリティテストの本質ではない。観察した質的な発見を、無理に数値化しないこと。
レポアンのユーザビリティテスト連携
レポアンは「ユーザビリティテストの前後アンケート」で連携できます。
- テスト前のスクリーニング — 適切な対象者を絞り込むアンケート
- テスト後の感想アンケート — 即時の感想を構造化して収集
- 改善後の効果検証 — UI改善の前後でアンケート比較
- 複数テストセッションの統合 — 個別の発見を全体傾向と紐付け
まとめ
ユーザビリティテストは：
- 中心は「観察」、質問は補助
- タスク設計が9割（具体的な状況、ゴール、3〜5個に絞る）
- Think-aloudで思考プロセスを声にしてもらう
- 「できますか？」と聞いた時点で失敗
- n=5〜10で共通パターンを発見、アンケートと組み合わせて規模検証
UIや UXの改善には、アンケートでは絶対に見えない領域 があります。ユーザビリティテストはその領域を捉える定性手法。観察の力を磨くことが、AI時代でも代替されない人間のスキルです。