Content last updated 2026-02-12

UX 調査参加者を募集する方法

GitLab で調査研究のために適切な参加者を見つける方法

GitLab では、UX Research Operations Coordinator が調査をリクエストする人々と密接に協力し、フィードバックを集める対象者が適切であることを確認します。UX Research Operations Coordinator の代理を務める場合は、このページを参考にしてください。

参加者をどこで見つければよいか分からない場合に参加者を募集する方法

知っている顧客の参加者を募集する方法

ターゲットオーディエンスを特定する（つまり、どのような特性を持つべきか？）
顧客に連絡し、関心を尋ねる
顧客と直接調整してセッションをスケジュールする。これには、Calendly イベントの作成が含まれる場合があります
インセンティブリクエスト Issue を開く

Issue から参加者を募集する方法

ターゲットオーディエンスを特定してどのような特性を持つべきかを決定します
スクリーナーを作成する
Calendly イベントを作成する
関連する公開 Issue にスクリーナーへのリンクを投稿して参加者を募集する
リクルートメントリクエスト Issue を開く
インセンティブリクエスト Issue を開く

UX Researcher または UX Research Operations Coordinator がプロセス全体を通じてあなたとコラボレーションする場合があり、私たちは常に質問に答える用意があります。

ターゲットオーディエンスを特定する

あなたの質問に答えるのに役立つデータを集めることが不可欠です。それを行う唯一の方法は、適切な人々と話すことを確保することです。ターゲットオーディエンスを定義するのに役立つように、以下の質問を自分自身に問いかけてください:

どの調査手法を選択しましたか？
何人の参加者が必要ですか？
誰から話を聞きたい／話したいですか？
- 参加者がするべきタスクは何ですか？
- 参加者が使用するべきツールは何ですか？
- 彼らの経験レベルはどのくらいですか？

これらの質問への答えは、調査のために以前に特定した目標と目的から直接流れ出るはずです。調査研究に関わる全員がこれらに合意し、リクルートメントを開始する前にそれらが最終決定されることが重要です。明確な目的から始める方が、単に合わない参加者を調査に押し込めようとするよりもよいです。

職種ではなく、タスクと責任の観点から考えるのが最善です。なぜなら、しばしば人の職種はその人が行うタスクと完全に一致しないからです。

スクリーナーを作成する

スクリーナーには特定の機能があります - それは、あなたのターゲット層である人々を特定することを意図しており、調査で本当に知りたいことを彼らに尋ねることができるようにします。ベストプラクティスは、Google Docs のScreener Template（内部リンクのみ）をコピーし、すべての質問が最終決定されるまでステークホルダーとコラボレーションすることです。効果的なスクリーナーを書く方法のヒントについては、このページをご覧ください。次に、質問を含む Qualtrics でスクリーナーを作成します。Qualtrics へのアクセス権がない場合は、リクエストしてください。Qualtrics で最終的なスクリーナーが作成され、UX Research Operations Coordinator と共有されるまで、リクルートメントは開始されません。

スクリーナーの質問は、参加者基準と一致しなければなりません。これにより、UX Research Operations Coordinator は希望する基準をレビューし、スクリーナーでどの答えを見たいかを知ることができます。スクリーナーで抽象的または自由形式になるほど、UX Research Operations Coordinator が探している答えがどれであるかを解析するのが難しくなります。ベストプラクティスは、スクリーナーで自由回答形式の質問を避けることです。

参加者は、モデレート調査に参加するためにこれらの質問のそれぞれに同意する必要があります。すべてのスクリーナーに次の質問を含める必要があります:

セッションの記録への同意
記録を GitLab に保存することへの同意

IP Assignment や GitLab の Individual Contributor License Agreement が必要かどうかを判断します

IP Assignment とそれを表示するタイミングについて詳しく学びます

私たちが含める一般的な質問は次のとおりです:

職種
一般的なタスク
業界
チームと会社の規模
使用するツール

これらの質問の標準的な表現のコピーは、Qualtrics の UX Research ライブラリにあります。上記で言及されたスクリーナーテンプレートに基づく Qualtrics の汎用テンプレートもあります。このテンプレートを使用するには、Qualtrics で新しいプロジェクトを作成し、次のオプションを選択します:

アンケートを開始する方法は？ Use a survey from your library
Library UX Research & Product
Survey UXR Generic Screener（Templates フォルダから）

Create project を選択した後、Qualtrics 内の調査ビルダーにリダイレクトされ、スクリーナーを自由に編集できるようになります。

時々、同じ組織から参加者を募集する必要があります。これらの場合、スクリーナーの最後に潜在的な参加者に追加の見込み客を募集するよう尋ねる質問を追加することを検討してください（スノーボールサンプリングと呼ばれます）。例:

私たちは、同じ組織／チームの方々で、あなたとは異なる役割を持つ方々ともお話しすることに興味があります。全員のインタビューは個別に行われ、セッションが終了したら全員に同じ金額が支払われます。あなたのセッションへの参加は、他の誰かの参加に依存しません。この調査に参加することに興味のある同僚をご存知の場合は、彼らのメールと役割／職種を提供してください。私たちはこのスクリーナーへのリンクを彼らに送ります。

時々、異なる調査で共通のスクリーナーを使用することで取り組みを統合できる場合があります。これはCommon Screenerと呼ばれます。

スクリーナーはアンケートと同じではないことを覚えておくことが重要です。 答えを知りたいが、その参加者が中に入るかどうかを判断するために厳密に必要ではない余分な質問を積み重ねたい誘惑があるかもしれません。代わりに、これらの質問をディスカッションガイドやスクリプトに含めることから利益を得るでしょう。

Calendly イベントを作成する

参加者をスケジュールするには、Calendly イベントを作成する必要があります。UX Research Operations Coordinator は資格のある参加者に個別のメールを送信し、あなたとの時間を予約するよう依頼します。Calendly をここで設定します。

「New Event Type」をクリックします。
One-on-One ミーティングオプションに対して「Create」を選択します。
Event 名には、調査のトピックを含めます。
Location には、Zoom ミーティング URL を入力します。ベストプラクティスは、定期的なミーティングを使用することです。
Description/Instructions は任意です。
Event リンクには、セッションのトピックを記述する短いフレーズを使用します。
Event カラーには、現在使用していない色を選択します。
Event Duration には、調査手法を参考にしてください。通常、私たちのユーザーインタビューとユーザビリティセッションは 30〜60 分です。
Date Range には、「Edit」をクリックし、ドロップダウンメニューから「Over a Date Range」を選択します。次に、セッションを開催したい日を選択します。ベストプラクティスは、調査セッションを実施するために自分自身に 5〜7 営業日を与えることです。
カレンダーで各日をクリックして、セッションに利用可能な時間を示すことができます。

リクルートメントリクエスト Issue を開く

リクルートメント Issue を開く前に、すべての資料を準備してください:

スクリーナー
スクリプト
リクルートメントタイムライン

これらの資料がなければ、UX 調査運用コーディネーターはあなたのリクエストを進めることができません。リクルートメント Issue を早期に作成すると、リクルートメント Issue のターンアラウンドタイムの追跡が過剰に膨らみます。

ステップ 1 - リクルートメントリクエスト Issue を開く

このステップは、リクエストを完了するために必要なすべての情報を提供します。

UX Research Projectに移動し、新しい Issue を開きます。
テンプレートを選択し、必要な情報を入力します。

ステップ 2 - 1〜2 営業日待つ

UX Research Operations Coordinator は、1〜2 営業日以内に調査をクレームし、参加者を見つけるためにあなたと協力します。彼らはさらなる質問とタイムラインの更新をあなたに連絡します。あなたの調査がクレームされたとき、コーディネーターは ReOps::Triage ラベルを削除します。彼らがそれに取り組んでいることを識別するために置き換えられます、例えば ReOps::Cait - Caitlin Faughnan の場合。

早めにスタートしたいが、まだ準備ができていない場合は？

調査がまだリクルートメントの準備ができていない場合、リクエストを早めに開いている場合は、タイトルを WIP または DRAFT で始めてください。 UX Research Operations Coordinator は調査をクレームし、ただし、Issue が WIP/DRAFT フェーズを離れるまでリクエストに取り組みません。 Issue が WIP/DRAFT フェーズを離れる準備ができたら、リクエストに割り当てられた UX Research Operations Coordinator に @mention してください。

UX Research Coordinator は私のリクエストで何を担当しますか？

UX Research Operations Coordinator は、リクルートメントキャンペーンの開始、リクエストの優先順位付け、参加者のスケジュール - 必要な場合、時間に対する払い戻し、および必要に応じて NDA が署名され、適切に保管されることを確保する責任があります。

どのリクルートメント方法が使用されますか？

プロジェクトに割り当てられた UX Research Operations Coordinator は、リクルートメント基準に基づいて、リクルートメントに最適な方法を選択します。これは、基準に応じて複数のアプローチを使用することを含む場合があります。オプションには次のものが含まれます:

データウェアハウス
Marketo
Respondent.io - サードパーティのリクルートメントツール
ソーシャルアウトリーチ
LinkedIn 経由のダイレクトソーシング
ドキュメントサイトバナー
UserTesting.com - サードパーティのリクルートメントツール（主に Product Designer がセルフサーブで使用）

これらのリクルートメント方法について詳しく学びます。

参加者のスケジューリング

スクリーナーが潜在的な参加者に送信されると、UX Research Operations Coordinator は結果を監視し、リクルートメントをリクエストした人と共有します。これは Google スプレッドシートを介して行われます。彼らは、あなたのリクルートメント基準に最も合う潜在的な参加者を提案します。調査の DRI は、招待したい応答から UX Research Operations Coordinator に名前のリストを提供することもできます。

潜在的な参加者が合意されると、UX Research Operations Coordinator は資格のある参加者に Gmail を介してスケジュールメールを送信します。UX Research Operations Coordinator は、予約が行われたかどうかについてタイムリーに更新するのをあなたに頼っています。予約があなたのカレンダーに行われていない場合は、数営業日以内に彼らに知らせる計画を立てる必要があります。そうすれば、リマインダーまたは新しい招待を送ることができます。彼らはリクエストが満たされるまでこのサイクルを繰り返します。

時間に対して参加者に払い戻しをする

リクエストに割り当てられた UX Research Operations Coordinator が参加者への支払いを処理します。ただし、参加者のインセンティブをタイムリーに処理することで参加者にポジティブな体験を提供することを確実にするために、セッション完了から 48 時間以内にコーディネーターに知らせるのはプロジェクトの DRI の責任です。すべての参加者に支払いが行われ、残りのセッションがなくなったら、UX Research Operations Coordinator が Issue を閉じます。

UX Research Operations にインセンティブリクエストを提出するタイミングは？

プロセスを開始するためにリクルートメント Issue を作成したので、これは自動的に行われます; このステップはプロセスの一部としてすでに組み込まれています。つまり、何もする必要がなく、インセンティブは割り当てられた UX Research Operations Coordinator によって自動的に処理されます。

自分で参加者を見つけて、インセンティブだけを配布する必要がある場合は？

リクルートメント Issue を作成せずにインセンティブを配布する必要があるシナリオがある場合は、インセンティブリクエスト Issue を開く必要があります。

UX Research Projectに移動し、新しい Issue を開きます。
Incentives Request テンプレートを選択し、必要な情報を入力します。
スプレッドシートへのリンクを Issue に貼り付けます。

UX Research Operations Coordinator のうちの 1 人は、すべての必要な情報がスプレッドシートにあれば、1 営業日以内にリクエストをピックアップし、参加者のインセンティブを処理します。調査が進行中の場合は、Issue にコメントするか、処理する必要のあるインセンティブがさらにある場合はスプレッドシートで UX Research Operations Coordinator にタグを付けるだけです。

リクルートメントタイムライン

リクルートメントは通常、エンジニアや DevOps プロフェッショナルなど、私たちの調査パネルと顧客データベースに豊富にいるターゲット参加者には 2 週間かかります。セキュリティプロフェッショナルや新しくリリースされた機能のユーザーなど、発生率の低いユーザーのリクルートメントには 2 週間以上かかる場合があります。まれに、ターゲット参加者が見つからない場合、UX Research Operations Coordinator は他のオプションを提案します。

どの場合でも、UX Research Operations Coordinator は、リクルートメント Issue にコメントすることでリクルートメント努力の進捗を最新の状態に保ちます。

プロモーションゲーム

プロモーションゲームやコンテスト（例: 3 つの $30 (または同等通貨) Amazon ギフトカードのうちの 1 つを獲得する機会）を通じてユーザーを募集する予定の場合は、ハンドブックの以下の情報を確認し、リーガルに相談してください。リーガルに連絡する方法については、Legal Team ハンドブックページの私たちへの連絡方法を参照してください。リーガルに承認を求め、インセンティブリクエストを作成することは、プロモーションゲームやコンテストを含む調査を実施する前に完了する必要があります。

Respondent.io のプロセスと戦略

Respondent.io の使用方法のビデオ概要については、GitLab Unfiltered の内部のみの録音をご覧ください。注意: ビデオで概説されているプロセスは、主に UX Researcher 向けです。Respondent.io を使用することに興味がある場合は、支援のために UX Research チームの誰かに連絡してください。

通常、参加者はすぐに資格を取得し始めます。
ほとんどの調査では、1 つの Respondent キャンペーンのみが必要です。
CM スコアカードでは複数のキャンペーンが必要な場合があります。
複数の異なるセグメントを募集したい場合は、各セグメントごとに 1 つのキャンペーンが必要になる可能性があります。これは、各キャンペーンに資格基準を設定するため、参加者が設定したロジックに従って自動的に資格を取得し、失格になるからです。例えば、Jenkins ユーザーと GitHub Actions ユーザーの 2 つの同等のセグメントと話したい場合は、同一のスクリーナーで 2 つのキャンペーンを設定する必要があります。1 つのキャンペーンでは GitHub actions を must select 項目として設定し、もう 1 つでは Jenkins を must select 項目として設定します。Jenkins ユーザーが最初のキャンペーンを訪問するときに「失格」になる場合があります。あなたは最初のプロジェクトで彼らを手動で資格を取得させてインタビューすることができます、実際に各ユーザーが何人いるかの集計を保つだけです。これは複雑になりますが、Respondent はあなたの資格基準に一致するユーザーの 2 倍を見つけるまで募集し続けるので、必要なユーザーを最速で取得する方法です。

コーディネーターがキャンペーンを作成したら、インタビュアーを Respondent に参加するよう招待し、インタビュアーに彼らのカレンダーを追加してプロジェクトをフォローするよう助言し、その後特に議論しない限りサポートの役割に移ります。これは、インタビュアーがキャンペーンを監視し、好みのユーザーをスケジュールに招待する責任があることを意味します。コーディネーターは数日ごとにチェックインする計画を立てるべきですが、インタビュアーが質問がある場合、または数日後に適切な参加者が見つからない場合は、コーディネーターに ping を送るのはインタビュアーの責任です。

プロジェクトの命名
- あまり具体的でないパブリック名を作成します; 人々があなたのスクリーナーをゲームする可能性があるため、基準について多くを明かさないようにします。例: Seeking GitLab users! は問題ありませんが、Seeking daily GitLab CI/CD users with 3+ years of experience! はあまりにも具体的です。
- 内部チームメンバーがどのプロジェクトが彼らのものかを見ることができるプライベート名を付けます。例: Lorie: CI/CD pipeline set up exp.
カレンダーの追加
- Respondent では、プラットフォーム内で参加者をスケジュール、支払い、コミュニケートする必要があります。プラットフォーム参加者を他の場所に誘導しようとすることは大きなタブーです。
- プロジェクトの calendars タブで Google カレンダーを接続します。
- 高度な設定に移動し、新しい予約までの最小時間を 8 hours 以上に指定します。これにより、あなたが寝ている朝一番のサプライズセッションを人々がスケジュールするのを防ぎます。
- 1 日あたりの予約の最大数を、あなたが快適なものに設定します。推奨は 1 日あたり 3〜4 セッションです: それ以上は非常に課税です。
- セッション間にバッファ時間を設定して、ノートを完成させ、別のセッションを開始する前に短い休憩を取る時間があるようにします。推奨は 15 分です。
Zoom の使用 Respondent プロジェクトを設定するときは、必ず個人の Zoom ルームリンクを使用してください、参加者ごとにリンクを変更することはできないからです（これはすべての参加者が同じ Zoom ルームリンクを持つことを意味します）。さらに、これらのセッションのパスワード要件を必ずオフにしてください。
重要なプラットフォームエチケット:
- インタビューを実施した後、参加者を速やかに attended としてマークします。これにより、コーディネーターに支払いが必要な参加者がいることを通知します。
- リスケジュールのインタビューについて連絡を取る努力をしなかった場合のみ、誰かを no-show としてマークします。no-show は参加者のプラットフォームでの評価に対して非常に懲罰的です。
- 同様に、セッションをリスケジュールしなければならない場合は、参加者ができるだけ事前通知でリスケジュールできるようにします。セッションに現れない、または 24 時間以内にキャンセルする場合、私たちはネガティブな評価を受け、参加者に支払いをしなければなりません。
- プロジェクト内のメッセージに注意を払ってください。インタビューがスケジュールされている日には、最初にそれらをチェックすることをお勧めします。参加者はリスケジュールするため、または技術的な問題について尋ねるために連絡を取るかもしれません。空の Zoom で待ち、ますますフラストレーションを感じる前に、最初にこれらに対処するのが最善です 🙂

Respondent.io を通じて支払いを提供するプロセス

Respondent では、プラットフォームを通じて直接参加者に支払いをする必要があります。

Respondent.io で参加者に支払いをするためには、いくつかのステップが必要です:

Respondent.io で（調査を開始した後）プロジェクトを選択します
調査を正常に完了した人を Participants タブで見つけ、Mark As Attended ボタンをクリックします
参加者を評価するための簡単な調査質問に記入します（つまり、ポジティブ、ネガティブ、ニュートラル）
必要に応じてステップ 2 と 3 を繰り返します
Payments タブに移動します
Payment Method ドロップダウンを見て、Credit Balance（これがデフォルトオプションです）と表示されていることを確認します
支払いボタンを選択します（注意: 参加者が追加の作業を行った場合は、設定されたインセンティブコストを超えるチップを指定できますが、これは一般的には行われません）

支払い資金は組み込みの残高から引き出されます。Respondent.io は、Payments タブ内およびページの左上隅にこの実行残高を表示します。

リクルートメントのケーススタディ

上記のプロセスが実際にどのように機能するかを理解するために、次の調査研究は素晴らしい例です:

アクセシビリティソリューション検証調査 Issue

ターゲット回答者の特定

調査の述べられた目標は次のとおりです:

GitLab の自動テスト機能を改善する継続的な取り組みの一環として、アクセシビリティテストのための新機能を出荷したいと思います。この機能のためのいくつかのソリューションを検証したいと思います。私たちが持つ質問は:
開発中に導入されたアクセシビリティ問題をどのようにユーザーに表示するか、正確に。
提案されたデザインのうち、CI プロセスの一部としての自動アクセシビリティテストのユースケースを満たすのはどれか。

何人の参加者が必要でしたか？

これはユーザビリティテストだったので、約 5 ユーザーが一般的にスイートスポットです。

タイムラインは何でしたか？

Product Designer は、いつでも開始できる状態であると述べ、UX Research Operations Coordinator に休暇の時間を通知しました。

彼らは誰と話したかったですか？

Frontend エンジニアが提出されましたが、それはあまりにも広範すぎます。代わりに、彼らの日々の活動に焦点を当てることで、UX Research Operations Coordinator が正確な一致を見つけるのに役立ちました。

スクリーナーの作成

この例では、リクルートメントが依存する主要な質問は本当に明確でした: UX Research Operations Coordinator は、職種、参加者が実行する一般的なタスクや持っていた職務責任、アクセシビリティコンプライアンスの重要性をどう認識しているかについての何かに関する質問を見ることを期待していました。UX Research Operations Coordinator は、私たちがほぼ常に含めるもの、つまり会社の規模と業界（調査の対象でない場合、私たちが混合を得ようとするもの）も見ることを期待していました。

この研究は、人々がどのツールを使用するかについて尋ねていない点で珍しいです。多くの場合、GitLab の経験を持つ、または持たない人が何を考えているかを明示的に見たいと思っています。この研究には関連がなかったので、その情報は収集していません。

短くて簡潔なことを保つことで、スクリーナーの完了率が高まります。

完成したスクリーナーを ご覧ください

リクルートメントリクエストを開く

上記の会話の多くはリクルートメントリクエストで発生しました。

UX Research Operations Coordinator は、私たちの調査パネルからセグメントを作成する際に細心の注意を払いました。研究はアクセシビリティに関するもので、多くの人が情熱を持っているトピックだったので、この研究はカスタムの件名とメールコピーを使用するのに良いものでした。UX Research Operations Coordinator は、件名 New study - let's talk accessibility のメールを送信しました。2 通のメールの後、20 件以上の応答を受け取りました。

UX Research Operations Coordinator は、仕事でアクセシビリティテストを行っていると述べ、アクセシビリティコンプライアンスが重要であることに強く同意する人々を緑でハイライトしました（合計 4 人）。後者の基準のみに合う人々をオレンジでハイライトしました（9 人）。全体として、これは参加者の余剰ですが、次のアクセシビリティ研究が利用可能になったときに直接連絡できる参加者がいくつかあります。

UX リサーチ募集メールのヒント

UX リサーチの参加者をメールで募集する方法に関するガイダンス

コモンスクリーナー: 複数のスタディで効率的にスクリーニングする方法

GitLab でリサーチスタディの参加者を見つけるためのコモンスクリーナー利用アプローチの概要

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)

ページのソースコードを見る - ページの編集 - please contribute.