リサーチセッション自体はスムーズに進んでも、参加者が調査対象の状況を経験したことがないために、的外れな答えしか得られないことがあります。たとえば、初めて利用する人を対象とした調査に使い慣れた既存ユーザーを採用してしまうと、チームが本当に把握すべき課題が見えなくなってしまうかもしれません。参加者のリクルーティングは、意思決定のヒントとなる経験を持っているのが誰なのかを見極め、その人たちに無理なく、かつ敬意を払って参加してもらう方法を見つけることから始まります。

そのプロセスには、応募条件の設定、募集チャネルの選定、スクリーニング、参加調整、そして最終的なサンプルの確認が含まれます。招待に応じた人数は、リクルーティングが成功したかどうかを判断する一要素にすぎません。

属性の前に、関連する「経験」を明確にする

まずは、参加者が何を経験し、何に取り組み、どんな場面に直面している必要があるかから始めましょう。たとえばソフトウェア購入に関する調査なら、肩書を見るよりも、最近ベンダー選定に関わったか、予算を承認したか、選ばれたツールの導入を担当したかどうかのほうが参考になります。関わり方によって、意思決定に対する視点は異なります。

属性情報はリサーチの問いに答えるうえで役立つ場合に活用し、アクセシビリティのニーズ、サービスの利用への自信、置かれている状況などの違いも考慮に入れましょう。英内務省（Home Office）の参加者リクルーティングガイドは、サービスが支えるべき実際の人々とリクルーティングを結びつける実践的なヒントになります。

必須の条件と、幅を持たせたい要素は分けて考えましょう。条件を細かく絞り込みすぎるとリクルーティングが難しくなるだけでなく、一般的なユーザーを無意識に締め出してしまうことにもつながります。募集の途中で条件を変更した場合は、その理由を記録し、それが調査結果にどう影響するかを検討してください。

対象者に合ったルートを選ぶ

既存の顧客からはプロダクトの生の声を聞くことができますが、将来的に使い得るすべての人を代表しているわけではありません。利用をやめた人、競合を選んだ人、そもそも提供内容を理解できなかった人は、既存顧客リストには載っていないことが多いはずです。コミュニティ組織や専門のリクルーター、参加者パネルなど別のルートも視野に入れましょう。それぞれリーチできる範囲や進めやすさは異なります。

Ballparkの参加者パネルもリクルーティングの選択肢のひとつです。ただし、チャネルの選択と「サンプルが母集団を代表しているか」という点は分けて考える必要があります。母集団の大きさや細かい絞り込み、属性ごとの割り付けだけで、代表性が担保されるわけではありません。

ユーザビリティ上の課題を見つけるための調査と、母集団全体の傾向を把握するための調査では、サンプリングの判断基準が異なります。求めている経験を捉えられない手法を取っている場合、人数を増やしたところでその問題は解決しません。

案内文とスクリーナーを連動させる

リサーチの内容、所要時間、謝礼、録画・録音の有無などを明確に伝え、参加するかどうかを判断できるようにします。アクセシビリティへの配慮を行い、セッションの前に気になる点を質問できる窓口も用意しておきましょう。

スクリーナー（選考アンケート）では、条件を満たす回答がどれかをあからさまにせず、対象者であるかを確認できるようにします。具体的な経験について尋ねるようにし、「後で役立つかもしれない」といった理由だけで個人情報を集めるのは避けましょう。GOV.UKのリクルーティングガイドでは、参加者を見つけるための具体的なルートや手配方法について解説されています。

謝礼は、参加者の時間と労力に対して支払うものです。好意的な意見や同意、タスクの成否によって支払いを左右してはいけません。また、リクルーティング時だけでなくインフォームドコンセント（事前の説明と同意）にも十分な配慮が必要です。参加を承諾した人が、実際の調査内容に戸惑うような事態は避けなければなりません。

実際に誰が参加したかを確認する

キャンセルや除外、アプローチが難しかった層なども含めて、実際に集まったサンプルを当初の計画と照らし合わせてみましょう。ソフトウェア購入の例でいえば、参加者全員がスクリーナーを通過していたとしても、承認権限を持つ人ばかりが集まってしまっては、実際の導入現場のリアルな状況は見えてきません。

こうした調査の限界や前提条件は、結果と一緒に共有しましょう。誰を、どのチャネルから、どんな基準で採用したのかを簡潔にまとめておくと、チームメンバーがそのエビデンスをどのように捉えるべきか判断しやすくなります。また、どの経験がまだ検証できていないのかが明確になるため、次の調査の計画も立てやすくなります。