コモンスクリーナー: 複数のスタディで効率的にスクリーニングする方法
コモンスクリーナーは、複数のスタディにまたがる募集で同じ質問を使用するものです。これは、独自に募集を行うチームが、同じ種類の背景質問(共通タスク、業種、企業規模など)を使って参加者を特定する場合に実施できます。
特定のスタディでコモンスクリーナーを使用する各チームメンバーは、各質問について独自の包含基準を選択します。たとえば、あるスタディでは従業員 100 名未満の企業のユーザーが必要かもしれませんし、別のスタディでは 1,000 名以上の企業のユーザーが必要かもしれません(図 1 を参照)。各スタディは、企業規模に関する同じ共通質問に対して異なる包含基準を設定します。

上の図は、コモンスクリーナーのアプローチを使用して、同じ質問でさまざまなスタディに参加者をマッチングできることを示しています。この例では、100 人以上の企業からの参加者は、スタディに対して単一のスクリーナーが使われている場合はそのスタディから除外されるかもしれませんが、コモンスクリーナーアプローチを使う場合は別のスタディにマッチする可能性があります。これは、各スタディが企業規模に関する同じ質問に対して異なる包含基準を設定するために可能になります。この例では、コモンスクリーナーアプローチによって、JTBD の質問でキーとなるタスクを選んでもらい、異なるペルソナに該当する参加者をマッチさせることもできます。
コモンスクリーナーは Qualtrics の機能を活用して、スタディの包含基準と、共通質問への回答から得られる参加者プロファイルとの間でマッチングを行います。例にあるように、ハンドブックの JTBD タスクのリストを含む質問を入れて、各回答者のペルソナを特定するかもしれません。次に、その回答を使って、そのペルソナを探しているスタディとマッチングします。さらに、企業規模に関する質問と組み合わせて、異なる企業規模で同じペルソナを探しているスタディや、同じ企業規模で異なるペルソナを探しているスタディと回答者をマッチングできます。
このようなスクリーナーは、早期に計画されており、企業規模など、参加者間で類似の質問が使われるスタディに最適です。
コモンスクリーナーを使うメリットは何ですか?
コモンスクリーナーには次のような効果があります:
- チームが募集に関するリソースをプールするのに役立つ
- DRI が四半期ごとに作成またはサポートする必要のある募集 Issue、謝礼 Issue、リサーチスクリーナー、募集プッシュの数を削減する
- あるスタディのすべての基準を満たさない参加者を、別のスタディに含めることを可能にする
- 各スタディの募集中に必要なコンテキストスイッチの量(たとえば、募集データベースへのアクセス回数)を最小限に抑える
- 参加者を見つけるために必要な労力を減らし(たとえば、同じソーシャルメディア投稿で複数のスタディをサポートできる)、見込み参加者への連絡数を減らす
コモンスクリーナーがどのように使われたかの例はありますか?
Verify チームと Package チームは 2022 年初頭にコモンスクリーナーの最初の GitLab イテレーションに取り組みました。同じスクリーナーを使って 5 つの問題検証スタディで募集を行うことができました(詳しくはこちら)。現在、同じスクリーナーで 2022 年後半に問題検証と解決策検証の両方のスタディで募集をサポートできるかを確認するためにこのプロセスを利用しています(詳しくはこちら)。
パイロットは Verify チームと Package チームの User Personas に焦点を当てています:
- Presley, Product Designer
- Sasha, Software Developer
- Devon, DevOps Engineer
- Sidney, Systems Administrator
- Sam, Security Analyst
- Rachel, Release Manager
- Alex, Security Operations Engineer
私たちのコモンスクリーナーでは、回答者をリサーチスタディとマッチングするために、次のようないくつかの重要領域に関する質問を使用しています:
- 企業規模
- 回答者の勤務先企業で採用されているさまざまな機能(たとえば Merge Trains)や製品(たとえば GitLab Dependency Proxy、JFrog Artifactory、Sonatype Nexus)
- 回答者が GitLab SaaS と Self-Managed のどちらを使用しているか、使用している GitLab 機能(たとえばマージリクエスト)
- どのタイムゾーンにいるか
- ターゲットのペルソナにマッピングするために使える共通のタスク
コモンスクリーナーで使用される質問の例は何ですか?
主要タスクに関する質問は、コモンスクリーナーで使用できるものの好例です。同じ質問への異なる回答が、回答者を異なるスタディにマッチングするのに役立つからです。
複数のペルソナをカバーするリストから共通タスクを選んでもらうことで、リサーチスタディに含まれることを期待して、実際には実行していないタスクを選んでしまう回答者による回答バイアスを最小限に抑えることもできます。以下は、タスクベースの質問がどのように見えるかの例です:
次のうち、あなたの主な職務責任の一部であるものはどれですか?該当するものすべてを選択してください。
- 効果的で共感的かつ効率的なユーザーエクスペリエンスのデザインをリードする
- 製品デザインをアプリケーションコードに翻訳する
- コードのデプロイ、ビルド、リリースを行う
- 機能やバグ修正の実装のためにアプリケーションコードを書く
- インフラストラクチャと構成を維持・スケーリングする
- チームと協力してセキュリティ修正を実装する/セキュリティテストを実行する
- パイプラインビルドを実行・テストする
- リリースを調整・オーケストレーションする
- セキュリティを強化するためのツールを構築・実装する
表 1。私たちのパイロットに含まれる各ユーザーペルソナに回答者をマッピングするのに役立つ、ハンドブックページからのタスクのリスト。
| ユーザーペルソナ | 差別化するタスク |
|---|---|
| Presley, Product Designer | 効果的で共感的かつ効率的なユーザー体験のデザインをリードする |
| Sasha, Software Developer | プロダクトデザインをコードに変換する |
| Devon, DevOps Engineer | コードのデプロイ・ビルド・リリースを行う;パイプライン定義と CI テンプレートを提供する;コードを使って機能やバグ修正を実装する |
| Sidney, Systems Administrator | インフラと構成を維持・スケールさせる;サーバーを構築してそこへデプロイする、もしくは開発者がそうするのを支援する |
| Sam, Security Analyst | チームと協力してセキュリティ修正を実装する;セキュリティテストを実行する、もしくは潜在的なセキュリティ問題を報告する |
| Rachel, Release Manager | パイプラインビルドを実行・テストする;パイプラインを自動化する;リリース横断でチームを調整する |
| Alex, Security Operations Engineer | セキュリティインシデントに対処する;セキュリティを強化するためのツールを構築・実装する |
コモンスクリーナーを使用するための要件はありますか?
はい、コモンスクリーナーアプローチを使用するには次の要件があります:
- コモンスクリーナー経由で参加者を募集するすべての人は、コーディネーション Issue に関連付けられた同じ謝礼スプレッドシートを使用する必要があります。これは、スタディ間で重複した参加者を使用していないことを確認するのに役立ちます。
- コモンスクリーナーを使用するすべての人は、コモンスクリーナーを使用したい各スタディに専用の募集リクエストを作成します。
あなたのチームがコモンスクリーナーから恩恵を受けると考える場合、どのようなステップを踏むべきですか?
新しいコモンスクリーナーをセットアップしたい PM とデザイナーのためのステップは次のとおりです:
- コモンスクリーナーのコーディネーション Issue テンプレートを使って、スクリーナーをコーディネートするためのIssueを作成します。
- 募集したいターゲットペルソナを特定します。
- 募集したいスタディの種類(たとえば、問題検証)と使用するフォーマット(たとえば、60 分の Zoom インタビュー)を特定します。
- コモンスクリーナーを活用する可能性のある GitLab 製品ステージチームを特定します。
- 出発点として使えるテンプレートのコモンスクリーナー(Qualtrics またはドキュメント形式)を UXR に依頼します。
- そのテンプレートのコピーを作成します。
- チームメンバーが調整を求められる(例: タスクのリストに追加される新しいタスクを提案する)よう、各コモンスクリーナー質問に対するフィードバック用の自由回答質問を追加します。
- 各チームメンバーに、Qualtrics 調査形式でドラフトに返信することでフィードバックを提供するよう依頼します。
- それらの変更を取り込みます。
- インセンティブリクエストを作成し、コモンスクリーナーから募集されたすべての参加者に使用する謝礼スプレッドシートを依頼します。
- コーディネーション Issue で UXR や ReOps の担当者にタグ付けし、新しい共通参加者プールに募集を開始する準備ができていることを確認します。
コモンスクリーナーが設定されたら、もう少しいくつかのステップに従います。
- 各スタディのリサーチ Issue と募集 Issue をコモンスクリーナーのコーディネーション Issue にリンクします。
- スタディ固有の募集 Issue で ReOps にタグを付け、コンタクトを取得し、次の人のために新鮮な参加者がいるように別の募集プッシュを行うよう依頼します。あなたの UXR もこれを手伝うかもしれません。
- 参加者がスタディのために連絡されることになった場合、UXR または ReOps の担当者によって、コモンスクリーナーの Qualtrics データダッシュボードの「study be included in」セクションに記載されます。参加者がスタディのために連絡されたら、次のスタディの募集からはその人を除外します。参加状況は謝礼スプレッドシートで追跡します。
既存のコモンスクリーナーを使用したい場合、どのようなステップを踏むべきですか?
適している既存のアクティブなコモンスクリーナーのコーディネーション Issue(下の表を参照)を見つけます。
Common Screener Types of Studies Benchmark Loop Stages Common Screener 60, 90 or 120 min Zoom sessions or moderated usability studies 2023 CI/CD Solution Validation Studies Surveys, 20 min online unmoderated studies, 30 or 60 min interviews or moderated usability sessions Problem Validation + Foundational Research 2023 30 or 60 min Zoom interviews, 60 min interviews, 30 or 60 min task based moderated usability studies コモンスクリーナーのコーディネーション Issue のオーナー(上記リンク先)にタグ付けし、次のことを伝えます:
- どのスタディで募集したいか
- 探しているペルソナ
- 参加者の募集をいつ開始したいか、また探している参加者の数
コーディネーション Issue のオーナーは、あなたが理想の参加者であるかのようにコモンスクリーナーに記入するよう依頼し、ReOps チームが参加者の候補リストを作成する際に使用できるフィルターを作成します。
bfd74782)