リサーチャーが「先月のプロジェクトをアーカイブしてください」というタスクを作成したところ、最初のセッションで参加者の半数が「アーカイブ」を「コピーをダウンロードすること」と解釈していることに気づきます。プロトタイプ自体は意図通りに動作していても、調査ではチームが想定していたものとは別の事象を測定してしまっている可能性があります。パイロット調査を行うことで、本格的なフィールドワークを始める前に、こうしたズレを発見できます。

パイロット調査とは、計画している調査の実現可能性（フィージビリティ）や手順、測定手法を評価・改善するために実施する小規模な事前テストです。プロダクトリサーチにおいては、参加者のリクルート、案内文、所要時間、記録方法のほか、得られたデータが意図した分析に耐えうるかどうかの検証によく用いられます。

一連のフロー全体をリハーサルする

メインとなる設問だけでなく、案内文、スクリーナー（事前選定アンケート）、参加手順の調整、技術的なセットアップまで含めて検証しましょう。アンケートはリサーチャーのノートPCでは見やすくてもスマートフォンでは回答しづらい場合がありますし、リモートテストでは参加者がプロトタイプを開けず、最初のタスクに着手する前に失敗してしまうこともあります。

Nielsen Norman Groupのパイロットテストに関するガイドでは、調査の事前準備におけるその役割が解説されています。対象ユーザーに近い参加者を交えることで、プロダクトに慣れた社内メンバーでは見落としてしまいがちな誤解をあぶり出すのに非常に役立ちます。

パイロットで得られたデータを使って、予定している分析を一通り試してみましょう。タスクの成功判定をブレなく行えなかったり、チームが必要とするカテゴリに回答を分類できなかったりする場合は、同じ問題を抱えたデータをこれ以上集める前に調査ツールや設計を見直します。

調査設計を変更する判断基準を決めておく

パイロット調査に向けて、実践的な問いを設定しましょう。対象条件に合う人をリクルートできるか、タスク内容が正しく伝わっているか、予定時間内にセッションが収まっているか、必要な操作ややり取りが記録できているか、といった点です。より複雑なリサーチ計画の場合は、リスクやリソースに応じた実現可能性の基準をあらかじめ定めておきます。

何を変更し、なぜそうしたのかを記録しておきましょう。曖昧だったタスクシナリオを書き直す場合は、新しい表現によって操作手順の答えを教えてしまっていないか、あるいはどのゴールを目指すべきか参加者を迷わせていないかを確認します。大幅な変更を加えた場合は、もう一度リハーサルを行う価値があります。

小規模なパイロット調査で問題を洗い出すことはできますが、それで「問題がゼロになった」と証明できるわけではありません。数回のセッションでは、稀なケースやアクセシビリティ上のニーズは見つからない可能性があるため、パイロットでカバーできた範囲は率直に捉えておく必要があります。

運用の検証結果とプロダクトの結論を混同しない

パイロットのわずかな参加者が示した好みを、デザインの優劣を決定づける根拠にしてはいけません。初期の回答を見た後に、都合の良い結果が出るよう調査設計を調整することは避けてください。

パイロットのデータを本調査の分析に含められるかどうかは、調査設計、対象条件、手順、そして加えられた変更によって決まります。実質的に異なるバージョンのデータを、その差異を考慮せずに統合してはいけません。検証型の調査では、可能であれば事前にその判断方針を決めて文書化しておきましょう。

パイロット調査の実質的なゴールは、よりクリアな条件下で、本来の目的に答える準備が整った調査を作り上げることです。優れたアンケート設計と入念な準備によってその完成度は高まりますが、本調査には本調査ならではのリクルート、分析、解釈が引き続き必要となります。