テスト NEW

ユーザビリティテスト計画の立て方：5ステップ完全ガイド

ユーザビリティテストで最も省略されるのは「計画フェーズ」だ。目標設定・参加者設計・タスク設計・環境準備・スケジュール設計の5ステップを体系化し、計画なきテストが生む失敗パターンと対策を解説する。

17分で読める
#ユーザビリティテスト #テスト計画 #タスクシナリオ #参加者リクルーティング #テストフェーズ #ユーザーリサーチ #デザイン思考

「テストは来週やろう」——この言葉がチームから出た瞬間、計画は既に崩壊しかけている。

ユーザビリティテストを取り巻く議論の多くは「どの手法を使うか」に集中する。モデレーテッドかリモートか、シンクアラウドか行動観察か。テストフェーズの全体像や5つの検証手法を学んだとき、多くの実践者が感じる充実感はそこから来る。

しかしテストが失敗する理由の大半は、手法ではなく計画の欠如にある。参加者を急いで集めたせいで対象ユーザーがズレていた。タスクの指示が曖昧で、参加者ごとに全く違う操作をした。録画環境を確認していなかったため、最重要セッションの映像が残らなかった。これらは手法の問題ではなく、計画段階で防げた失敗だ。

本記事は、ユーザビリティテストの「計画フェーズ」に特化した実践ガイドだ。①目標設定、②参加者設計、③タスク設計、④環境・ツール準備、⑤スケジュール設計という5ステップで、計画の全体像を体系化する。

なぜ計画フェーズは省略されるのか

組織でユーザビリティテストの計画が省略される理由には、構造的なパターンがある。

第一の理由は「テストを準備作業だと捉えていない」ことだ。 プロトタイプが完成すれば「後は見せるだけ」という認識が生まれやすい。しかしテストそのものの品質は、事前の計画精度によってほぼ決まる。参加者選定の基準、タスクシナリオの設計、記録方法の決定——これらは「準備」ではなく「設計の一部」だ。

第二の理由は「スケジュールの後ろ詰め」だ。 プロジェクトの締め切りが固定されている場合、テストに充てられる時間は常に最後の余りになる。1週間の予定が3日に圧縮され、3日の計画が「明日の午後やろう」になる。この構造は、テストに先行するプロトタイプフェーズが長引くことによってさらに悪化する。

第三の理由は「計画の仕方が分からない」ことだ。 ワークショップやトレーニングでテストの実施方法は教わっても、テスト計画の立て方を体系的に学ぶ機会は少ない。結果として、場当たり的な進め方になる。

ステップ1：目標設定 — 何を知るためのテストか

テスト計画の出発点は、「このテストで答えたい問いを1〜3個に絞ること」だ。これは議論なしに実行できることではない。チーム内で「何が不確かで、何を知れば次に進めるか」を言語化するプロセスが必要だ。

テスト目標の書き方

目標は「〜を確認する」ではなく「〜が分かる」という形で書くと、後からテスト結果との照合がしやすくなる。

悪い例：「UIの使い勝手を確認する」

良い例：「新規ユーザーが登録フローを完了できるか、どのステップで離脱するかが分かる」

目標が曖昧だと、タスク設計もデータ分析も曖昧になる。 目標を1〜3個に絞る作業は、チームが「何を諦めるか」を明示的に決める作業でもある。4つ目の目標候補が出てきたときに「これは今回のスコープ外」と言えるかどうかが、計画の規律を決める。

仮説をセットで書く

目標と並行して、検証する仮説を明文化しておく。「初めてのユーザーは、ダッシュボードのナビゲーションが分かりにくいと感じている可能性がある」のような形で書くと、テスト後に「仮説は支持されたか」という問いで分析を整理できる。

ステップ2：参加者設計 — 誰にテストしてもらうか

参加者の選定は、テストの品質を決定する最重要変数だ。 間違った参加者に正しいタスクを与えても、有効なインサイトは得られない。

参加者基準（スクリーニング条件）を作る

まず「テストに参加すべき人」の条件を文章で書き出す。行動特性（頻度・経験・デバイス）、属性（年齢・職業・デジタルリテラシー）、除外条件（競合製品の従業員、開発チームの知人）を含める。

この条件文書がスクリーニングアンケートの設計に直接使える。リクルーティングを外部会社や社内のUXチームに依頼する場合、この文書なしに動いてもらうと「条件に合わない人が来た」という事態が発生する。

何人集めるか

Jakobニールセンが1993年に示したモデルでは、同一ユーザーグループにおいて、ユーザービリティ問題の約85%は5名のテストで発見できる（Nielsen, J. & Landauer, T.K., 1993）。この数字はユーザビリティテスト（問題発見）の文脈でのモデルであり、探索的インタビューや多様なユーザーセグメントを含む場合には当てはまらない。

実際の参加者数の決め方は、ユーザーセグメントの数に依存する。対象ユーザーが「初心者」と「経験者」に分かれるなら、各グループに5〜6名——合計10〜12名が出発点の目安になる。定性調査のサンプルサイズに関する詳細な議論は別記事で扱っているが、重要な原則は「何人いればいいか」ではなく「どのセグメントをカバーできているか」で判断することだ。

サンプリング偏差のリスク

最も頻繁に起きる失敗は、参加者の母集団がズレることだ。 社内のアーリーアダプター層や、リクルーティング会社の登録モニター常連者ばかりが集まると、実際のユーザー行動から乖離したデータになる。

特に注意が必要なのは「テストに慣れた参加者」の混入だ。ユーザビリティテストの経験が豊富な人は、タスクの「意図」を読もうとする傾向があり、一般ユーザーよりも探索的に動く。スクリーニングで「過去12ヶ月以内にユーザーテストに参加したことがあるか」を確認するのは有効な対策だ。

ステップ3：タスク設計 — 何を操作してもらうか

タスクシナリオはユーザビリティテストの核心だ。タスクの設計が悪ければ、どれだけ適切な参加者を集めても、得られるデータは現実から離れる。

タスクシナリオの書き方

タスクシナリオは「シチュエーション（状況） + ゴール（達成すべきこと）」で構成する。

悪い例：「このアプリの予約機能を使ってください」

良い例：「今日の夜、友人2名と食事に行く約束があります。明日の夜19時に3名で入れるレストランを、このアプリで予約してください」

良い例が優れている理由は、現実のユースケースに近いからだ。ユーザーが実際の目的意識を持って操作することで、自然なナビゲーション行動が観察できる。「予約機能を使ってください」という直接指示は、UIラベルをそのまま読み上げているようなものであり、ユーザーが通常の状況でどこから探し始めるかが分からない。

タスクの数と順序

1セッション（45〜60分）に詰め込めるタスクは3〜5個が上限だ。1つのタスクに15〜20分を配分し、バッファを含めて設計する。 タスク間の移行時間、参加者が行き詰まった際の対応時間、セッション後のデブリーフィング時間を見落とすと、必ず最後のタスクが駆け足になる。

タスクの順序は「発見したい情報の優先順位」に基づいて決める。参加者が疲れる後半にもっとも重要なタスクを置くのは避ける。また、タスク間に学習効果が生まれないよう注意する——前のタスクで画面の構造を学んだことが、次のタスクのパフォーマンスに影響するようなら、順序を入れ替えるか、タスク間でUIをリセットする手順を挟む。

パイロットテスト（予行演習）の実施

本番セッションの前日までに、チームメンバーの1人を参加者役にして1セッション分を通しで実施する。パイロットテストで確認するのは、タスクシナリオの言葉が曖昧でないか、セッション時間が予定内に収まるか、録画・記録の設定が機能するか、の3点だ。

実際にやってみると、「自分たちには明確に見えていた指示が、参加者役にとっては全く別の意味に聞こえた」という発見が必ず出てくる。省いたセッションほど、本番で同じ穴に落ちる。パイロットテストはタスク設計の質を上げる最も確実な手段だ。

ステップ4：環境・ツール準備 — どこで、何を使うか

実施環境の選択

ユーザビリティテストの実施環境は大きく3つに分かれる。

対面（ラボ）形式は、参加者の行動を直接観察でき、表情や手の動きといった非言語情報も収集できる。設備として、参加者用端末、スクリーン録画ツール、観察用の別室（ワンウェイミラー）があると理想的だが、会議室でも実施可能だ。

リモートモデレーテッド形式は、ZoomやMicrosoft Teamsなどのビデオ会議ツールで参加者の画面共有を受けながら進行する。地理的制約がなくリクルーティングの幅が広がるが、通信環境や技術的なトラブルへの対処計画が必要だ。

リモートアンモデレーテッド形式は、UserTesting.comやLookback.ioなどのプラットフォームで参加者が一人でタスクをこなし、録画を後から分析する。量を確保しやすいが、想定外の行動に対してその場でフォローアップできない。

記録方法の決定と事前確認

セッションの記録方法を決定し、本番前日に必ず動作確認する。 記録しておくべきなのは、画面の操作（スクリーンキャプチャ）、参加者の発話（音声）、表情と手の動き（カメラ映像、対面の場合）、オブザーバーのリアルタイムメモだ。

録画ツールの設定ミスや保存先の問題は、現場でのトラブルの中で最もダメージが大きい。「最重要なセッションが録画されていなかった」という事態は、チェックリストで防げる。

チームの役割分担

テストセッションに関わるチームの役割を事前に明確にする。モデレーター（進行）、ノーテイカー（記録担当）、オブザーバー（観察）の3役は、別々の人間が担当するのが理想だ。

モデレーターがリアルタイムで記録を取ろうとすると、参加者への注意が分散する。ノーテイカーは参加者の言葉・行動・特記事項を時系列で記録し、オブザーバーは「何を感じたか」という解釈レベルの観察を別紙に書く。この3層の記録が、分析フェーズでデータの密度を上げる。

ステップ5：スケジュール設計 — いつ、どう進めるか

テスト全体のタイムライン

テスト計画から結果の共有まで、最低限のタイムラインは以下が目安になる。

フェーズ期間の目安
計画・設計（ステップ1〜4）1〜2週間
参加者リクルーティング1〜2週間（並行可）
パイロットテスト本番セッション前日までに1セッション
本番セッション実施2〜3日（5〜8セッション）
データ分析・パターン抽出2〜3日
結果の共有・レポート1日

リクルーティングは計画フェーズと並行して走らせる。 「計画が完成してからリクルーティングを開始する」という順番で動くと、トータルのリードタイムが2週間以上伸びる。スクリーニング条件の大枠が決まった段階でリクルーティングを開始し、詳細な条件は後から精緻化する。

セッション間のバッファ

1日にセッションを詰め込みすぎることは避ける。セッションとセッションの間に15〜20分のバッファを設ける。 このバッファは、前のセッションのメモを整理する時間、機材のリセット時間、そして次の参加者への引き継ぎ準備のために使う。

実際にやってみると、1日4〜5セッションがモデレーターの集中力の限界に近い。6セッション以降では、質問の鋭さやフォローアップの精度が落ちる傾向がある。セッション数が多くなる場合は、複数日に分散させるか、モデレーターを交代させる計画を組む。

分析セッションのスケジューリング

テストセッションの終了直後（翌日以内）にチーム全員で分析セッションを開くことを、計画段階からスケジューリングしておく。観察者の記憶が鮮明なうちにパターンを抽出する「ダウンロードセッション」は、データ分析の品質を大きく左右する。

「録画があるから後でやろう」という発想は、分析の先延ばしと映像を見直す時間の二重コストを生む。セッション当日か翌日に30〜60分の分析時間を確保することを、計画の一部として組み込む。

計画チェックリスト

テストを開始する前に、以下の項目が揃っているかを確認する。

目標設定

  • テストで答える問いが1〜3個に絞られている
  • 検証する仮説が文章で書かれている

参加者設計

  • スクリーニング条件が文書化されている
  • 参加者数がユーザーセグメントに基づいて決定されている
  • 除外条件（テスト経験者・業界関係者）が明記されている

タスク設計

  • 全タスクが「シチュエーション + ゴール」形式で書かれている
  • タスク数と時間配分が計算されている
  • パイロットテストが実施済み、またはスケジューリング済み

環境・ツール準備

  • 録画・記録の設定が動作確認済み
  • チームの役割（モデレーター・ノーテイカー・オブザーバー）が決定済み
  • 参加者への同意書・謝礼の手配が完了している

スケジュール

  • リクルーティングが計画フェーズと並行して開始されている
  • 分析セッションの日時がカレンダーに確保されている

テスト計画と問題定義の接続

テストは独立したアクティビティではなく、問題定義の仮説を検証するプロセスだ。 テスト目標の設定が難しいと感じるチームの多くは、POVステートメントが曖昧なまま手法の選定に進んでいる。

「POV文（Point of View文）」で「どんなユーザーが、どんな状況で、何に困っているか」を明確にしていれば、「そのインサイトが本当に正しいか」をテストで検証する問いが自然に出てくる。逆に問題定義が曖昧なテスト計画は、「全てを確認しようとして何も確認できない」状態に陥りやすい。

テスト計画に入る前に、チームのPOV文を開いてみると、目標設定のズレに気づくことが多い。計画の精度は、その上流にある問題定義の精度に比例する。

参考文献

Related

テスト

デザイン思考のユーザーテスト手法完全ガイド｜5つの検証技法と現場実践

 テスト

テストフェーズ——ユーザーから学び、改善を続ける