GitLab のリサーチオペレーション (ReOps)

リサーチオペレーションとは?

リサーチオペレーション（しばしば ReOps と呼ばれる）は、Experience Research 内の専門分野で、Experience Research チームが行うリサーチ活動をサポートするプロセス、ツール、インフラの管理と最適化に焦点を当てています。リサーチオペレーションの主な目標は、必要なサポートとリソースを提供することで、リサーチャーがより効率的かつ効果的に作業を行えるようにすることです。

GitLab におけるリサーチオペレーションのいくつかの重要な側面を以下に示します:

1. 参加者リクルーティング
2. ツールとリソースの管理
3. プロセスの最適化
4. ガバナンスとコンプライアンス
5. トレーニングとサポート
6. ロジスティクスと管理

ReOps チームは上記のすべての側面を推進します。また、リサーチ DRI は ReOps スペシャリストの監督のもと、自分たちのプロジェクトの ReOps 側面をリードできる場合もよくあります。

私たちの戦略

現在の ReOps 戦略 は内部のみアクセス可能です。

一般的に、私たちは 3 つの柱と 1 つの原則に従います。

ReOps の柱

• リーチを拡大し、戦略的なリサーチニーズを満たすニッチな参加者のパネルを構築・管理する。
• リサーチ DRI が自信を持って迅速に進められるよう、リクルーティングプロセスの効率と柔軟性を向上させる。
• コミュニケーション、エンゲージメント、コミュニティ構築を通じて、ReOps と UX リサーチのインパクトを推進する。

ReOps の原則

• 私たちの仕事と進捗について透明性を保ち、リサーチプロセスとプラクティスの継続的な改善の文化を育てて、誰もが（UX リサーチャー、プロダクトデザイナー、プロダクトマネージャーなど）参加できるようにする。

リサーチオペレーションスペシャリスト 1 人は何件のスタディをサポートできますか?

短い答え: いつでも約 5 ～ 10 件です。長い答え: スタディの種類とターゲット集団によります。各スタディが、データベースとコミュニティに比較的豊富にいる 5 ～ 8 人の参加者しか必要としない場合、マイルストーンごとにリクルートされるスタディ数は約 10 件になる可能性があります。これは、スペシャリストが複数のリクルーティングの取り組みを同時にこなせるよう、プロダクトデザイナーとプロダクトマネージャーが完全なリクエストを十分早く提出することにも依存します。50 人以上の回答者を必要とする調査や、新しいユーザーグループや機能を対象としたスタディがある場合、マイルストーンごとにリクルートされるスタディ数は 5 件に近づく可能性があります。これらのスタディには持続的な努力と創造性が必要です。

リクルートリクエストを挙げることを決してためらわないでください。リサーチオペレーションスペシャリストがあなたと協力してリクルーティングの取り組みをスケジュールします。Slack で @Caitlin に気軽に連絡してください。

リサーチオペレーションスペシャリストはどう先を計画するか?

リクエスト数が 10 を超えると、スペシャリストはキャパシティオーバーになります。これが発生すると、一度に正常に管理できないほど多くのプロジェクトがあり、GitLab 内部と外部で次の副作用が経験されます:

• タイムラインが遅延する
• リサーチオペレーションスペシャリストからのアウトバウンドコミュニケーションが減り、音信不通の感覚が生じる
• ステータスを知りたい人や次のステップでヘルプが欲しい人からのインバウンドコミュニケーションが増加する
• プロセスでエラーが発生する

キャパシティオーバーの状況に対処するため、2 つの行動計画があります:

1) 四半期計画

私たちが GitLab でリサーチを行う方法の性質上、いつでもパイプラインを正確に把握して、どのリサーチプロジェクトがいつ来るかを理解するのは困難です。しかし、過去のリサーチプロジェクト量データに頼り、いくつかのプロジェクトのケイデンスを四半期ごとに予測してそれに応じて計画できます。追加調整が必要な、特定されたプロジェクトの例:

• SUS 測定
• 大規模 N の調査（n=200+）

四半期計画セッションは各四半期の開始時に実施されます。計画演習では、月別に今後のリサーチリクエスト、既知のリサーチプロジェクト、予測されるリサーチプロジェクト、リサーチ参加者を必要とする今後のイベント、プロセスへの予想される変更（例: 新規採用、非モデレートテストなど）、スペシャリストの不在をマッピングします。さらに、UX リサーチオペレーションコーディネーションと UX リサーチディレクターの間で、各月の初めにチェックインが行われます。

四半期計画演習の目標は、いつでも四半期へのかなり正確な視点を持ち、潜在的な納品リスクを特定でき、それらのリスクに対する緩和計画で早期に対処を開始することです。

スペシャリストは、リサーチコーディネーション四半期計画演習、月次チェックイン、Google Sheet を最新かつ正確に保つことを推進・維持する責任を持ちます。

2) バックアッププラン

リサーチプロジェクトを軌道に乗せ続けるため、リサーチオペレーションスペシャリストが不在の場合、またはキャパシティオーバーで追加支援が必要な場合に備えて、少なくとも 2 人の他の UX リサーチャーが リサーチオペレーションスペシャリストとして働くようトレーニング されています。

リサーチオペレーションスペシャリストは次の責任を持ちます:

• UX リサーチャーをトレーニングするためのトレーニング教材の開発
• トレーニングの実施

トレーニング用のカバー領域の例:

• リクルーティング受付プロセス（例: すべての関係者にどう応答するか、Service Level Agreement (SLA)、スペシャリストへの期待など）
• パネリストやリクルーティングソースに連絡する際のコミュニケーションガイドライン（それぞれの例を提供、使用する特別なログイン/アカウントなど）
• 異なる国での謝礼の取り扱い
• リクルートリクエスト用と謝礼リクエスト用で作成される異なる Issue タイプの理解、およびそれらの完了

理想的には、適切な計画が行われていればバックアッププランはほとんど使用されません。

キャパシティオーバーが発生したとき

正確な計画があってもキャパシティオーバーは発生する可能性があります。これが発生すると、スペシャリストは次の行動を取ることができます:

• チームに知らせる - 透明性を保つ。 #experience_research チャンネル、およびマネージャーに、リサーチオペレーションスペシャリストが現在キャパシティオーバーであることを伝え、通常に戻ると予想される時期を伝えます。これにより、既存および新規のリクエストへの期待が自動的に設定されます。最後に、キャパシティが通常に戻ったときに、チャンネルに知らせる投稿でフォローアップします。
• 納品日への期待をリセットする - 影響を受けたプロジェクトの主要な人々に、納品日が変更される可能性があることを伝えます。
• 参加者に知らせる - 透明性を保つ。 参加者に悪影響が及ぶ場合は、現在忙しい状況にあることを伝え、心からの謝罪を述べたうえで、タイミングに関する期待値を参加者とすり合わせ直します。
• 助けを求める - リサーチオペレーションスペシャリストは、トレーニングされた UX リサーチチームのバックアップに助けを求める必要があります。リサーチオペレーションスペシャリストは、最大のインパクトをもたらすため、UX リサーチャーに適切な任務を委任する必要があります。
• 新しい受信リクエストはより長く時間がかかる - キャパシティオーバーのときに新しいリサーチを受け付けるのをやめません。代わりに、新しいリクエストに対して早期に期待を設定します。新しいリクエストはキャパシティオーバーに対応するために適宜バッファーされ、プロジェクトオーナーには理由について教育されます。
• セルフサービスを奨励する - リサーチオペレーションスペシャリストは、ハンドブックの指示へのリンク付きで、人々をセルフサービスのリソースに案内できます（例: Respondent と User Interviews を使って参加者を見つけるなど）。

リサーチオペレーションスペシャリストが不在のとき

リサーチオペレーションスペシャリストは、GitLab でのリサーチの成功に不可欠なユニークな責務を持つため、スペシャリストが不在のときはリクルーティングの取り組みが遅くなります。これは、すべての関係者に一連の問題をもたらします。

これに対処するため、スペシャリストが不在のときにバックアップとして機能する 2 人の UX リサーチャーが利用可能です。バックアップは進行中のタスクを完了し、新しいリクエストを受け付け、既存のリクエストを軌道に乗せ続けます。

スペシャリストが不在になる前に、アサインされたバックアップに次を明確に詳細にリストアップした Issue を作成します:

• 進行中のリサーチプロジェクト
• 各プロジェクトに必要な行動 - および実施タイミング
• 各プロジェクトの主要連絡先
• すべての関連 Issue へのリンク
• バックアップのリサーチオペレーションスペシャリストが行う必要があることを正確にフラグ

スペシャリストは、バックアップが自身の責務と責任を理解していることを確認する責任を持ちます。

リクルーティングを速くするためにリクルートリクエストを統合できますか?

場合によっては、間違いなく可能です。これは、2 つ以上のスタディが非常に類似している場合（例: 両方が似たタイムラインで面接を必要とし、同一のスクリーナーを持つ）に最も効果的です。

互いに非常に異なるスタディのリクルートを統合することは通常推奨されません。たとえば、大規模調査と一連のユーザー面接です。これは、これらの異なるスタディの異なるタイムフレームのためです。

人々を面接のためにスケジュールするには、一般的にフィードバックループをできるだけタイトに保ちたいです。スクリーナーに回答した後できるだけ早く、適格な参加者を面接にスケジュールするよう招待します。これは、リクルートプロセス全体がわずか数日かかる可能性があることを意味します。逆に、多数の回答を必要とする調査は、数週間にわたって Qualtrics で複数ラウンドのメールを必要とする場合があります。早期に回答したユーザーに連絡することを思い出す頃には、非常に長い時間が経過しており、非常に低い回答率を見る可能性が高いです。これにより、私たちは 2 回リクルートする必要が生じます。

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