ユーザビリティテストのやり方【2026年版完全ガイド】手順・ツール・チェックリスト付き

ユーザビリティテストとは何か

ユーザビリティテストとは、実際のユーザー（またはターゲットに近い人）にシステムやWebサイトを操作してもらい、使いにくさの問題を発見する調査手法です。

開発チームは自分たちが作ったシステムに慣れてしまっているため、「初めて使う人がどこで迷うか」に気づきにくい。ユーザビリティテストは、この盲点を客観的に明らかにします。

UXの専門家ヤコブ・ニールセンの研究によると、5人のユーザーでテストすれば、ユーザビリティ問題の約85%を発見できるとされています。大規模な調査が必要なわけではなく、少人数でも大きな効果が得られるのが特徴です。

ユーザビリティテストが必要な場面

以下のような場面で特に効果を発揮します。

• 新規システム・Webサイトの開発時 — リリース前に問題を発見し、手戻りコストを削減
• 既存システムの改修・リニューアル時 — 「使いにくい」という声の具体的な原因を特定
• コンバージョン率の改善 — 離脱ポイントや操作のつまずきを可視化
• 業務効率化システムの導入前 — 現場スタッフが実際に使いこなせるか検証
• アプリのストア評価が低い時 — 星1〜2の低評価レビューの根本原因を特定

ユーザビリティテストの種類と手法比較

対面テスト（モデレーテッド）

進行役（モデレーター）が同席し、被験者にタスクを依頼しながら観察する方法です。被験者の表情・迷い・つぶやきをリアルタイムで把握でき、深い洞察を得られます。

• メリット — 行動の背景を深掘りできる。その場で追加質問が可能
• デメリット — 日程調整が必要。1人あたり30〜60分かかる
• 向いているケース — 複雑な業務システム、初回テスト、重要な画面フローの検証

リモートテスト（アンモデレーテッド）

ツールを使い、被験者が自分のPCやスマホで自由にテストする方法です。進行役は同席せず、録画・ログを後から分析します。

• メリット — 地理的制約なし。多人数に同時実施可能。コストが低い
• デメリット — 深掘りができない。被験者が途中離脱するリスクがある
• 向いているケース — Webサイト・アプリの基本操作フロー、A/Bテストの補完

ゲリラテスト（廊下テスト）

カフェや廊下で通りかかった人に5〜10分だけテストしてもらう非公式な手法です。「コストゼロで今すぐ始めたい」という場合の最初の一歩に最適です。

ヒューリスティック評価

UXの専門家が、ニールセンの10原則などのガイドラインに基づいてUIを評価する手法です。ユーザーは参加しません。

手法比較表

2026年版 ユーザビリティテストツール比較

リモートテスト・録画ツール

アンケート・定量測定ツール

• Googleフォーム（無料）— SUS（System Usability Scale）調査に最適
• Typeform（無料〜）— 回答体験が良く離脱率が低い。事後インタビューに
• Hotjar（無料〜）— ヒートマップ・セッション録画。リリース後の継続改善に
• Microsoft Clarity（無料）— Hotjar類似。無料で使えるヒートマップ・録画ツール

ユーザビリティテストの進め方【6ステップ】

ステップ1：テスト計画を立てる

「使いやすさを確認したい」という漠然とした目的では、テスト後に何も改善できません。具体的な検証仮説を立てることから始めます。

計画で決めるべき5項目：

1. 検証仮説 — 「新規ユーザーが会員登録を5分以内に完了できるか」など具体的に
2. 被験者の条件 — ターゲットユーザー層（年齢・職種・ITリテラシー等）
3. 実施方法 — 対面 or リモート、使用デバイス（PC/スマホ）
4. 評価指標 — タスク完了率、所要時間、エラー回数、SUSスコア
5. スケジュール — 計画〜改善完了までのマイルストーン

テスト計画チェックリスト：

• □ テストの目的・検証仮説が明確になっている
• □ ターゲットユーザーのプロフィールが定義されている
• □ テスト環境（デバイス・ブラウザ等）が決まっている
• □ 実施スケジュールが確定している
• □ 録画・観察ツールが準備できている

ステップ2：タスクと質問を設計する

タスクは「実際の業務・利用シーン」に近い形で設計することが最重要です。「ボタンを押してください」ではなく、「友人に商品を贈るため、3,000円以内のギフトを選んで購入してください」のように、ゴールを自然な言葉で伝えます。

良いタスク設計のポイント：

• 操作手順を直接指示しない（「左上のメニューをクリック」はNG）
• 現実の業務・利用シーンに近いシナリオにする
• 1タスクは5〜15分で完了できる粒度にする
• 重要な画面フローを3〜5タスク程度に絞る
• 難易度が低い→高いの順番で並べる

思考発話法（シンクアラウド法）の活用：
テスト中は「今、何を考えているか声に出して教えてください」と被験者に伝えます。これにより「なぜそのボタンを押したか」「なぜ迷ったか」という内部状態が把握でき、UIの改善ポイントを特定しやすくなります。

タスク設計チェックリスト：

• □ 操作手順を誘導する表現が含まれていない
• □ 現実の利用シーンに即したシナリオになっている
• □ タスクの難易度が被験者のスキルに合っている
• □ 思考発話法の説明を準備している
• □ 事前アンケート・事後インタビューの質問が用意されている

ステップ3：被験者をリクルートする

ニールセンの研究に基づけば、最低5人でテストすれば問題の85%を発見できます。予算に応じて以下の方法を選んでください。

被験者リクルートの選択肢：

• 廊下テスト（コスト0円） — 社内の別部署スタッフに5〜10分だけ依頼。最初の一歩に最適
• 知人・既存顧客（低コスト） — 実際のユーザー層に近い人を紹介してもらう
• クラウドソーシング — ランサーズ・クラウドワークスで条件を指定して募集（リモートテスト向け）
• リクルートサービス（中〜高コスト） — popinsight等の専門会社に委託。質の高い被験者を短期間で確保

被験者選定チェックリスト：

• □ ターゲットユーザー像（ペルソナ）を定義している
• □ ITリテラシーレベルが実際の利用者と合っている
• □ 開発関係者・社内スタッフは除外している
• □ 謝礼・同意書・秘密保持の準備ができている
• □ スクリーニング質問で条件に合う人を事前選別している

ステップ4：テストを実施する

テスト当日は被験者がリラックスできる環境づくりが最優先です。「テストされているのはシステムであり、あなたの能力を評価しているわけではない」と冒頭に必ず伝えましょう。

テスト当日の流れ（60分の場合）：

1. アイスブレイク・自己紹介（5分）
2. テストの目的・思考発話法の説明（5分）
3. 思考発話法の練習（「コーヒーを淹れる手順を声に出しながら説明する」等）（3分）
4. タスク実施・観察・録画（30〜40分）
5. 事後インタビュー・SUSアンケート（10〜15分）

モデレーターが注意すべきこと：

• 被験者が迷っていても、ヒントを与えない（観察が目的）
• 「正解があります」「使いにくいですか？」などの誘導発言をしない
• 被験者の発言・行動・表情を逐一メモする
• タスク完了/未完了の判断基準を事前に決めておく（制限時間を設定する等）
• 被験者の沈黙が2分以上続いたら「今何を考えていますか？」と中立的に聞く

テスト当日チェックリスト：

• □ 録画・録音の許可を同意書で取得している
• □ テスト環境（URL・アカウント・デモデータ）が整備されている
• □ モデレーターガイド（進行台本）を準備している
• □ 観察者向けの別室またはリモート視聴環境がある
• □ タスクシートを被験者に渡す準備ができている

ステップ5：結果を分析する

テスト結果は「発生頻度×影響度」で優先順位をつけます。5人中4人以上が詰まった問題は最優先で改善します。

問題の優先度分類：

SUS（System Usability Scale）スコアの活用：
SUSは10問の標準アンケートでユーザビリティを0〜100点で数値化できます。無料で実施でき、改善前後の比較に有効です。一般的に68点以上が「平均的」、80点以上が「優れている」の基準です。

アフィニティダイアグラム（KJ法）による分析：
複数の被験者の発言・行動を付箋に書き出し、類似のものをグルーピングすることで、根本的な問題の構造を可視化できます。

ステップ6：改善して再テストする

ユーザビリティテストは1回で終わりにせず改善→再テストのサイクルを回すことが重要です。「5人でテスト→主要問題を修正→3人でもう一度テスト」という短いサイクルが最も効果的です。

改善サイクルの目安：

• Critical問題の修正後：1〜2週間以内に再テスト
• 通常の改善サイクル：月1〜2回のペースで継続
• 大規模リニューアル後：必ずリリース前に5人テスト

SUS（System Usability Scale）スコアの測り方

SUSは1986年にジョン・ブルックが開発した、ユーザビリティを数値化する標準的なアンケートです。10の質問に「全く思わない（1点）〜強くそう思う（5点）」で回答し、計算式で0〜100点のスコアを算出します。

SUSの10項目（日本語訳）：

1. このシステムを頻繁に使いたいと思う
2. このシステムは必要以上に複雑だと感じた
3. このシステムは簡単に使えると思った
4. このシステムを使うには技術的な支援が必要だと思う
5. このシステムの様々な機能はうまく統合されていると思った
6. このシステムには一貫性がないと思った
7. 多くの人がすぐにこのシステムの使い方を覚えられると思う
8. このシステムはとても使いにくいと思った
9. このシステムを使うのは自信を持ってできると感じた
10. このシステムを使い始める前に多くのことを学ぶ必要があった

スコアの解釈：

• 90点以上：Excellent（卓越している）
• 80〜89点：Good（優れている）
• 68〜79点：OK（平均的・許容範囲）
• 51〜67点：Poor（問題あり）
• 50点以下：Awful（深刻な問題あり）

中小企業・低コストで始めるユーザビリティテスト

「専門家がいない」「予算がない」という中小企業でも、以下の方法で低コストにテストを始められます。

コストゼロで始める「廊下テスト」

同僚や社内の別部署スタッフに5〜10分のタスクをやってもらうだけで、最初のフィードバックが得られます。開発したシステムに慣れていない人であれば、社内スタッフでも有効です。

無料・低コストツールの組み合わせ

• プロトタイプ作成 — Figma（無料プランで共有・テスト可能）
• 録画・観察 — Zoom/Google Meet（画面共有+録画機能）
• リモートテスト — Maze（無料プランあり・Figma連携）
• アンケート — Googleフォーム（SUSアンケートに最適）
• ヒートマップ — Microsoft Clarity（無料・制限なし）

プロトタイプ段階でのテストが最もコスパが高い理由

開発完了後にユーザビリティ問題が見つかった場合の修正コストは、設計段階の10〜100倍になるとも言われています。UIの画面遷移を1つ変えるだけで数十時間の修正が発生することもあります。プロトタイプ段階でテストすることで、後工程の大幅なやり直しを防げます。

プロトタイプ開発の詳細は、プロトタイプ開発とは？メリット・費用・進め方をご覧ください。

UI/UX設計プロセスへの組み込み方

ユーザビリティテストはUI/UX設計のプロセスと組み合わせることで最大の効果を発揮します。

システム開発全体の品質管理については、システム開発の検収ガイドとシステム開発のテスト工程も参考にしてください。

よくある失敗と対策

失敗1：被験者にヒントを与えてしまう

「ここをクリックすればいいですよ」「わかりにくいですよね？」という発言はテストを台無しにします。
対策：モデレーターガイドに「誘導しない」を明記し、「困ったら声に出してください、でも私はヒントを出しません」と事前に伝える。

失敗2：社内スタッフ・開発者のみでテストする

システムを知っている人がテストしても、実際のユーザーの体験は再現できません。
対策：開発関係者は除外し、最低2〜3人は社外・実際のユーザー層から確保する。

失敗3：テスト結果を改善につなげない

「テストして終わり」では意味がありません。
対策：テスト後48時間以内に問題リストを作成し、優先度をつけて次のスプリントに組み込む。

失敗4：リリース直前にしかテストしない

リリース直前では修正コストが高く、大きな変更ができません。
対策：プロトタイプ段階から小さくテストを繰り返す。「1回5人×複数回」の方が「1回30人」より効果的です。

失敗5：定性データだけで判断する

「被験者が褒めた」「1人が問題を指摘した」だけでは優先度の判断が難しい。
対策：SUSスコアやタスク完了率などの定量データと組み合わせて判断する。

まとめ

ユーザビリティテストは、システム・Webサイトの「使いにくさ」を客観的に発見するための最も効果的な手法です。

• 5人のテストで問題の85%を発見できる（ニールセン研究）
• 廊下テスト（無料）からリモートテスト（有料ツール）まで、予算に応じた方法がある
• Figma+Zoom+Googleフォームの組み合わせでコスト0円から始められる
• 計画→タスク設計→リクルート→実施→分析→改善の6ステップで進める
• プロトタイプ段階でのテストが最もコスト効率が高い
• SUSスコアで定量的に改善効果を測定できる
• 改善→再テストのサイクルを継続的に回すことが品質向上のカギ

システム開発やUI/UX改善のご相談は、お問い合わせからお気軽にどうぞ。FUNBREWでは、プロトタイプを作って確認しながら進める開発スタイルで、使いやすいシステムづくりをサポートしています。