「使いやすいと思って作ったのに、なぜユーザーは離脱するのか？」——この問いに対して、開発チームだけで答えを出すことは構造的に難しい。
開発者やデザイナーは製品に詳しすぎる。メニューの場所も、ボタンの意味も、全部知っている。だから「初めて使う人がどこでつまずくか」を想像することすらできない。これを心理学では「知識の呪い」と呼ぶ。
社内レビューで「使いやすい」と言われた画面が、実際のユーザーには全く通用しない。この現実を受け入れることから、ユーザビリティテストは始まる。
1. 手法の定義
実際のユーザーに製品を使ってもらい、その行動を観察して問題点を発見する評価手法。
「使いやすいですか？」と聞くのではなく、タスクを与えて黙って観察する。ユーザーがどこでクリックし、どこで止まり、どこで戻ったか——その行動が、言葉では語られない真実を教えてくれる。
2. いつ使うか
適している場面
- プロトタイプ完成時: リリース前に致命的な問題を発見する
- 離脱率が高いページの原因特定: データでは「離脱した」としか分からないが、テストで「なぜ」が見える
- 大規模リニューアル前: 現行版の課題を洗い出す
- 新機能追加時: 既存フローとの矛盾をチェックする
向いていない場面
- コンセプト検証段階: → ユーザーインタビュー
- 統計的な裏付けが必要な場合: → A/Bテスト
- 深い動機理解が主目的の時: → ユーザーインタビュー（操作上の問題発見が主目的ならユーザビリティテスト）
3. 設計判断の核
ユーザビリティテストは「感想を聞く」手法ではない。行動を観察し、言語化できない問題を発見する手法である。
よくある誤解
テストが終わったら「使いやすかったですか？」と聞く。
実際
ユーザーは「使いやすかった」と答えながら、タスクに失敗している。態度（言っていること）と行動（やっていること）は違う。だから行動を見る。発言を聞くのはオマケ。
設計判断の基準
- 「このタスクは具体的なゴールがあるか？」→「サイトを見てください」はNG、「赤いスニーカーを購入してください」はOK
- 「観察者は誘導していないか？」→ 迷っているユーザーを助けたくなるが、助けた瞬間にデータが汚れる
- 「5人以上テストしているか？」→ 3人以下では見落としが多い
4. 調査タイプ
| 軸 | 内容 |
|---|---|
| データ | 定性 |
| 対象 | 行動（操作） |
| サンプル | 5人（85%の問題を発見） |
| 実施フェーズ | Design / Deliver |
手法のポジション
深さ（Why）
↑
ユーザーインタビュー
↑
ユーザビリティテスト ← ここ
↑
サーベイ
→ 規模（How many）
ユーザビリティテストは「行動」を見る。インタビューは「なぜ」を聞く。思考発話法（考えていることを声に出してもらう）を併用すると、1回のテストで両方のデータが取れる。
補足: ユーザビリティテストで得られるのは「行動（操作）」の観察。「なぜ迷ったか」は思考発話法や事後インタビューで補完する。
5. 実施プロセス
1. 調査設計
- 目的: 何を検証するか（例: 購入フローの問題点）
- タスク設計: 具体的なゴールで設計
- ❌「サイトを見てください」
- ✅「赤いスニーカーを購入してください」
2. 参加者募集
- 対象: ターゲットユーザーに近い人
- 人数: 5人（3人以下は見落としリスク高）
- 謝礼: 3,000〜5,000円程度
3. 調査実施
セッション構成
- 導入（5分）: 目的説明、「製品をテストしている（あなたをテストしていない）」と伝える
- タスク実行（20〜30分）: タスクを1つずつ提示
- デブリーフィング（10分）: 全体の印象をヒアリング
観察のポイント
- クリック・スクロール・停止・戻りを記録
- ファシリテーターは誘導しない（「ここをクリック」と言わない）
- 思考発話法を併用すると「なぜ迷ったか」も把握可能
4. 分析
重大度 × 頻度マトリクス
| 重大度 | 頻度高（3人以上） | 頻度低（1〜2人） |
|---|---|---|
| 高（タスク失敗） | 🔴 最優先 | 🟠 次回リリース |
| 中（大幅遅延） | 🟠 次回リリース | 🟡 バックログ |
| 低（軽微な混乱） | 🟡 バックログ | ⚪ 様子見 |
6. 実務チェックリスト
最低ライン（Must - これがないと失敗）
理想ライン（Better - プロの品質）
7. 関連リンク
関連するUXリサーチ手法
- ユーザーインタビュー — 「なぜ」を深掘りする
- A/Bテスト — 統計的に検証する
- サーベイ — 規模を把握する
関連するUX心理
関連する用語
まとめ
ユーザビリティテストは「感想を聞く」手法ではない。行動を観察し、言語化できない問題を発見する手法である。ユーザビリティテストは「問題発見」の手法であり、「正しさの証明」の手法ではない。5人で85%の問題が見つかる。テストで問題を発見し、インタビューで「なぜ」を深掘りし、A/Bテストで改善案を検証する——これがUXリサーチの基本サイクルだ。
