ユーザビリティテストの最中、参加者がフォームの前で手を止め、「ここは入力したくないですね」と言ったとします。録画でもその躊躇は確認できますが、その場にリサーチャーがいれば、プライバシーへの懸念なのか、項目の妥当性に疑問があるのか、あるいは単に手元に情報がないだけなのかを掘り下げることができます。こうした予期せぬ瞬間に柔軟に対応できることこそ、モデレーター付きテスト（有人テスト）を選ぶ最大の理由です。

モデレーター付きテストでは、参加者がプロダクトやプロトタイプでタスクを行う様子にリサーチャーが立ち会います。対面で行うこともあれば、リモートで実施することもあります。リサーチャーはタスクの概要を説明し、操作を見守り、何が起きたのかを理解するために適宜質問を投げかけます。このとき、デザインの仕組みを教えたり誘導したりしないよう注意を払います。

その場にいるからこそ見えてくるもの

モデレーターの存在は、タスクの進め方に複数のルートがある場合や、プロトタイプが未完成な場合、あるいはクリックデータだけでは判断の背景が掴めないときに特に力を発揮します。また、参加者のアクセシビリティへの配慮に応じて柔軟に進行を調整できる利点もあります（ただし、リアルタイムの通話が誰にとっても最も快適で利用しやすい形式とは限りません）。

たとえば、経費精算ツールを日常的に使うユーザーを対象にしたテストを考えてみましょう。インターフェースはわかりやすそうに見えるのに、参加者がレシートの送信を保留にしました。理由を聞いてみると、「マネージャーにコストセンターのコードを確認しているところだった」ことが分かります。つまり、問題の一因は組織の業務フローにあり、ボタンの文言を変えただけでは根本的な解決にはなりません。こうした背景が見えてくれば、ユーザビリティテストにとどまらず、さらに踏み込んだユーザーインタビューが必要になるかもしれません。

一方で、モデレーターの存在そのものが影響を与えることもあります。参加者が安心感を求めてリサーチャーの顔色をうかがったり、トーンから正解を推測したり、1人なら諦める場面でも粘り強く進めてしまったりすることがあります。GOV.UKによるモデレーター付きユーザビリティテストのガイドラインには、セッションの焦点を参加者自身の体験に保ち続けるための実践的なヒントがまとめられています。

つまずく瞬間も想定してセッションを設計する

質問リストを細かく作り込む前に、まずはリサーチクエスチョンとタスクシナリオを固めましょう。そのクエスチョンに直結する背景を持つ参加者をリクルーティングし、リアルなテスト用データを用意して、プロトタイプの操作ルートをリハーサルしておきます。参加者には、何を録画・記録するのか、誰が見学するのか、そして得られた情報がどのように使われるのかを事前に伝えておく必要があります。

また、どのタイミングでサポートを入れるかについても基準を決めておきましょう。自力でのタスク完了率を測る調査であれば、手助けをすることは結果の意味を変えてしまうため、必ず記録に残さなければなりません。一方、体験の後半フェーズを検証することが目的であれば、早い段階での失敗を記録したうえで、先へ進めてもらう判断も合理的です。いずれにせよ、沈黙の気まずさに耐えかねて衝動的に助けてしまう、といった事態は避けなければなりません。

スケジュールには、同意取得や接続テスト、最後の振り返りのための時間を十分に確保しておきましょう。タスクを詰め込みすぎると、リサーチの核心となる重要なインシデントを掘り下げる時間がなくなってしまいます。リモートテストの場合は、参加者が実際に使用するデバイスで画面共有がスムーズにいくかを事前に確認してください。リサーチャーと参加者を自然につなぐ手段として、Ballparkのライブインタビュー機能などを活用するのもひとつの選択肢です。

答えを誘導せず、体験について問いかける

「何をお探しですか？」という問いかけなら、参加者自身の言葉で語る余地が残ります。一方、「レシートのタブをお探しですか？」と聞いてしまうと、解釈や進むべきルートを先回りして提示することになります。この違いはスクリプト上では一目瞭然ですが、目の前で参加者が困っていると、つい後者のような聞き方をしてしまいがちです。

あえて沈黙を保つ時間を意識し、「リサーチ自体への質問」と「プロダクトの操作に関するヘルプ」を明確に区別しましょう。タスクの趣旨を説明することは必要かもしれませんが、どのボタンを押せばいいかを教えてしまえば、それはもはや別のタスクになってしまいます。思考発話法（シンクアラウンド）を用いる場合も、促す言葉はニュートラルにとどめ、作業中の参加者を質問攻めにしてしまわないよう配慮が必要です。

モデレーターの介入も記録に残す

分析の際には、リサーチャーが何を話し、どう動いたか、特に躊躇やエラー、サポートが発生した場面の記録をしっかりと含める必要があります。ヒントを出した後にタスクが完了したなら、それは「支援付きでの成功」としてのデータであり、自力で達成した成功数に紛れ込ませてはいけません。

複数のリサーチャーでひとつの調査を分担する場合も同様の注意が必要です。セッションの結果を同列に扱う前に、導入の説明、声かけの仕方、介入のルールが揃っているか突き合わせておきましょう。モデレーター付きテストは、実際の行動を起点に深みのある対話ができる優れた手法ですが、その信頼性は「リサーチャー自身も観察対象の場の一部である」という自覚があってこそ成り立ちます。