リサーチの優先順位付け
UX Researcher は GitLab でユーザーリサーチを実施する唯一のメンバーではありませんが、すべてのリサーチが高品質で影響を重視したものになるようにする責任があります。小規模なチームとして、私たちはグローバル優先順位付けフレームワークとプロセスを適用します。これにより、次を実現できます:
- 組織全体で最優先のリサーチイニシアチブを評価し、優先順位を付ける
- サイロを解消し、データのトライアンギュレーションを標準化するプログラムを作成する
- 取り組み（現在および過去の作業）が重複するリスクを減らす
- リサーチャー間の学習とコラボレーションを促進する
リサーチプロジェクトの優先順位付けは誰が担うか
GitLab の UX Researcher は複数のステージグループに、また多くの場合はステージ横断で取り組みます。UX Researcher は、自身が支援する領域の優先順位について見解を示します（どの領域を誰が支援しているかを参照）。最終的なリサーチプロジェクトの優先順位付けは、Group Product Manager または Director of Product が決定します。
UX Research のグローバル優先順位付けの頻度
UX Research チームは、会社の OKR 計画のタイムラインに合わせ、毎四半期の開始時に同期してこのプロセスを実行します。この時期に、ステークホルダーまたは UX Researcher 自身からリサーチリクエストの大半が提起されます。これらのリクエストを話し合い、評価し、優先順位を付けます。
ただし、四半期中にも相当数のリサーチリクエストが提起されます。特に変化の速いテクノロジー業界では、状況や優先順位が変わるためです。アドホックなリサーチリクエストは、四半期開始時に提起されたものと同じフレームワークを使って話し合い、評価し、優先順位を付けます。
チームのキャパシティが埋まっている場合、新しいプロジェクトを引き受けるには別の作業を止める必要があります。より優先順位の高い新規プロジェクトが、現在の最も低い優先順位の作業に取って代わります。
四半期ごとのグローバル優先順位付けの仕組み
ステップ 1. インテーク
新しい四半期の開始時に、UX Researcher は Product と Design のステークホルダーに、戦略 / KR / ロードマップの変更や進展を確認し、新しいリサーチプロジェクトの可能性や既存プロジェクトの調整について話し合います。これはテンプレート化されたUXR Global Prioritsation Intake Issueで行えます。
ステップ 2. 基本を理解する
ステークホルダーまたは UX Researcher が提案するすべてのリサーチリクエストは、初期の有機的な妥当性確認フェーズを経ます。このフェーズでは、解決すべき問題、リサーチ目標、リサーチ結果がどの意思決定に役立つか、意図するビジネスインパクトの種類といった基本事項について話し合います。
各リクエストでは、意図する主要なインパクトの種類を1 つ明確に特定する必要があります。
| カテゴリ | インパクトの種類 |
|---|---|
| 意思決定へのインパクト | 1. 戦略 / 計画の変更 2. プロダクト / デザインの変更 |
| 知識へのインパクト | 1. 知識のギャップを特定 / 解消 2. ユーザーによるプロダクトの認識を把握 3. 次の大きな機会を特定 |
| UXR の成熟度へのインパクト | 1. UXR プロセスの効率性を改善 2. UXR の品質と信頼性を改善 |
このフェーズでは、既存のインサイト、より効率的な代替案を見つけ出したり、ビジネスインパクトに明確な根拠がないと合意したりした結果、一部のリクエストを取り下げることがあります。
目標、リサーチ質問、スコープが重複しているため、一部のリクエストを別のリクエストや既存プロジェクトに統合することがあります。
ステップ 3. 優先順位と支援レベルの評価
それ以外のすべてのリクエストを評価し、P1 から P4 の優先順位レベルを割り当てます。これは、UX Researcher が優先順位計算ツールをガイドとしてステークホルダーとの議論を主導して行います（Google Sheets の例 - 社内アクセスのみ）。
詳細を見るにはクリックしてください
優先順位計算ツールでは 6 つの質問をし、各質問に 1 ～ 5 のスコアを付けます。平均スコアを優先順位レベルに対応付けます。
| 基準 | 質問 | スコア / 重み |
|---|---|---|
| インパクト | このリサーチを行わない場合のビジネスインパクトは何か | 1: 重大なインパクト - 大きなリスク 2: 高いインパクト - 大きな機会 3: 中程度のインパクト - 有益なインサイト 4: 低いインパクト - あればよいもの 5: 最小限のインパクト - 明確な根拠なし |
| ユーザー | これは何人のユーザー / 顧客に影響するか | 1: すべてのユーザー / 重要なセグメント 2: 大規模なユーザーセグメント 3: 中規模なユーザーセグメント 4: 小規模なユーザーセグメント 5: ごく少数のユーザー |
| 依存関係 | これは直近の意思決定を妨げているか | 1: 重要なローンチを妨げている 2: 重要な意思決定を妨げている 3: 間もなく必要なインプット 4: 将来の計画 5: 特定の意思決定なし |
| タイムライン | タイムラインにはどの程度柔軟性があるか | 1: 今四半期 2: 直ちに（今月） 3: 6 ヶ月以内 4: 9 ヶ月以内 5: タイムライン上の圧力なし |
| 代替案 | この情報を得る別の方法はあるか | 1: 代替案がない 2: 代替案が限られている 3: 代替案がある程度ある 4: 良い代替案がいくつかある 5: 代替案が多数ある |
| 整合性 | これは戦略目標とどの程度整合しているか | 1: 中核となる戦略的優先事項 2: 四半期目標と整合 3: チーム目標を支援 4: 間接的に整合 5: 明確な整合性なし |
| 優先順位レベル | 平均スコア | 説明 |
|---|---|---|
| P1（必須） | <=1.5 | 重大なビジネスインパクト: 主要な会社指標 / OKR および年間計画に直接影響する。主要なプロダクトローンチ / リリースを妨げている。主要なプロダクトローンチ / リリースに関する未知の点に対処する。法的 / コンプライアンス要件 リサーチを行わない場合の高いリスク: 大幅な収益損失の可能性。大きなユーザー体験の低下。セキュリティ / プライバシー上の懸念 |
| P2（実施すべき） | <=2.4 | 戦略的重要性: 四半期目標と整合している。重要なプロダクトの意思決定が保留中。複数のチーム / プロダクトに影響する。 明確なビジネスインパクト: 収益機会 > $X。相当なユーザーベースに影響する。時間的制約のある機会 |
| P3（できれば実施） | <=3.5 | 中程度のビジネスインパクト: 単一のプロダクト / 機能に影響する。中期的な意思決定。影響範囲が限定的 良い機会: 既存の体験を改善する。チームの計画を支援する。ナレッジベースを構築する |
| P4（バックログ） | <=4.5 | 直近のインパクトが低い: 将来の計画。重要ではない改善。あればよいインサイト 延期可能: 直近の意思決定が保留中ではない。代替データソースが利用可能。戦略的整合性が低い |
| 実施しない | >4.5 | 最小限のビジネスインパクト: 明確なビジネスケースがない。範囲が非常に限定的。既存リサーチの重複 リソース集約的: 労力が大きく、リターンが低い。多大なリソースを必要とする。他の手段で対応した方がよい |
次に、支援レベル計算ツール（Google Sheets の例 - 社内アクセスのみ）を使用して、UX Researcher がこの取り組みをどのように支援するのが最適かを決定します。
詳細を見るにはクリックしてください
この計算ツールは、次の領域を考慮します。各基準には以下の表に従ってスコアが与えられ、合計を可能な合計スコアで割ってパーセンテージを求めます。これは適切な UX Research 支援レベルを示します:
| 基準 | 説明 | スコア / 重み |
|---|---|---|
| Issue | リサーチ Issue へのリンク | 該当なし |
| 種類 | プロジェクトが該当するリサーチの種類: 基盤リサーチ、Problem Validation、Solution Validation。 | 基盤リサーチ = 3 Problem Validation = 2 Solution Validation = 1 |
| 所有 | このリサーチは UX Researcher 以外が支援できるか | はい = 3 ある程度 = 2 いいえ = 1 |
| デザイン支援 | このプロジェクトは Product Design の支援を受ける Product チームから依頼されているか | このリサーチには該当しない（UX Research が作成 / 主導する調査）= 3 依頼元の Product チームに Product Designer がいる = 2 依頼元の Product チームに Product Designer がいない = 1 |
| 複雑性 | このプロジェクトには複数の調査または方法論が含まれるか | はい = 2 いいえ = 1 分からない = 0 |
| スキル開発 | UX Researcher が関与する場合、これはチームのスキル開発を支援するか、プロセスを洗練させるか | はい = 3 ある程度 = 2 いいえ = 1 |
| 確信度 | 提案されたソリューションまたは注力領域について、どの程度の確信または知識があるか | 高い = 3 中程度 = 2 低い = 1 |
UXR 支援レベルとは、UX Researcher が特定のリサーチプロジェクトに対してコミットできる支援のレベルです。
| UXR 支援レベル | パーセンテージ |
|---|---|
| エンドツーエンド（旧 Gold）🥇 | 80% 超 |
| タスク別（旧 Silver）🥈 | 51% ～ 80% |
| 相談 / レビュー（旧 Bronze）🥉 | 50% 以下 |
| UXR 支援レベル | 説明 |
|---|---|
| 🥇 エンドツーエンド（旧 Gold） | DRI: UX Researcher このようなプロジェクト: リサーチスペシャリストの恩恵を受けられる、大規模で戦略的かつ厳密なプロジェクト。通常は、基盤リサーチ、複雑なリサーチ質問、または優先度の高い Problem Validation。 誰が何をするか? UX Researcher がプロジェクト管理、実施の各側面、ほとんどのタスクの完了を主導しますが、Product と Design の支援を受けます。UX Researcher が DRI ですが、チームはリサーチセッション、分析、結果の議論などに参加することを強く推奨されます。 推定調査数: - 0.5 - 2 件のアクティブプロジェクト（UX Researcher のレベルに応じる） 例: - 複数の調査に影響するリサーチ - 複数の方法による調査 |
| 🥈 タスク別（旧 Silver） | DRI: Product/Design このようなプロジェクト: 主に Problem Validation プロジェクトで構成されます。 誰が何をするか? UX Researcher は調査内の指定されたタスクを引き受け、残りについて助言します。Product と Design は、UX Researcher の支援を受けて、プロジェクト管理、実施の各側面、ほとんどのタスクの完了を主導します。 推定調査数: - 1 - 6 件のアクティブプロジェクト（UX Researcher のレベルに応じる） 例: - UX Researcher と Product Manager または Product Designer が、リサーチ方法論について協力し、スクリプトを作成するか、分析をレビューします。 - UX Researcher は、実行に数日未満しかかからない特定のタスクに専任の支援を提供します。 |
| 🥉 相談 / レビュー（旧 Bronze） | DRI: Product/Design このようなプロジェクト: 主に Solution Validation と Problem Validation のプロジェクトで構成されます。 誰が何をするか? UX Researcher は、調査の特定の側面について相談を受けます。Product/Design は、UX Researcher の助言を受けて、プロジェクト管理、実施の各側面、ほとんどのタスクの完了を主導します。チームは、コンテキストとフィードバックが必要な期限を示すために、Issue で UX Researcher をメンションします。 推定調査数: - UX Researcher の時間の 10% 以下を、これらのプロジェクトの支援に充てる必要があります。 例: - インタビュースクリプトのレビュー - 参加者のリクルーティング基準 - 方法論の選択 |
どちらの計算ツールも推奨を生成するだけであることに注意してください。最終的な優先順位レベルと支援レベルを決定し、合意するのは UX Researcher とステークホルダーです。
ステップ 4. 意思決定とその伝達
優先順位レベルと支援レベルに合意すると、UX Researcher は作業量を営業日数で見積もり、ステークホルダーと合意して、引き受けるプロジェクト、取り下げるプロジェクト、または後ろ倒しにするプロジェクトを決定できます。
そのため、私たちはチームキャパシティに関する 3 つのルールに従います:
- 予期しない作業（アドホックなリクエストなど）、トレーニング、相互支援（ピアレビューや休暇中のカバレッジなど）のために、20% のキャパシティを確保します。
- 常に P1 プロジェクトを引き受けます。
- キャパシティが埋まっている場合、新しい優先事項を引き受けるには、別の作業を止める必要があります。より優先順位の高い新規プロジェクトが、現在の最も低い優先順位の作業に取って代わります。
全員の認識がそろったら、チームは今四半期に引き受けるプロジェクトを、関連する Slack チャンネル、Product と UX のミーティングで伝えます。
注: 現在の作業は、次の方法で四半期を通じて監視し、調整します:
- 中間チェックイン - グローバル優先順位付けプロセスのミニ版
- 毎月のバックログの整理
- 引き受ける必要があるアドホックリクエストを受けた後の再調整
アドホックなリクエストの扱い方
優先順位付けを行った後に、アドホックにまったく新しいリサーチプロジェクトを特定することは普通にあります。その新しいリクエストも、既存の優先順位付きリストに組み込めます。手順は次のとおりです:
- リクエスト者はリサーチ Issue（テンプレート）を作成し、基本情報を入力します。
- リクエスト者が Product または Design のステークホルダーであれば、Issue を自分自身とその領域の UX Researcher に割り当てます。リクエスト者が UX Researcher であれば、関連する領域の自分自身と Product および Design のカウンターパートに Issue を割り当てます。
- ステークホルダーと UX Researcher は、上で説明したステップ 2 ～ 4 を実行します。
- プロジェクトを引き受けると決定し、UX Researcher のキャパシティが埋まっている場合は、現在のより優先順位の低い作業を取り下げるか外部に委任し、関連するステークホルダーにそれを伝える必要があります。
注: 必要に応じて、UXR リーダーシップに優先順位の再設定を支援してもらえます。
リサーチ優先順位リストの維持
四半期を通じて、UX Researcher はグローバルリサーチ優先順位リストを維持し、プロジェクトのステータスを最新に保ち、変更および調整を Quarterly UX Research Global Priorities シート（Google Sheets の例 - 社内アクセスのみ）に記録します。
プロセスへのフィードバックを求める
任意: 四半期の終わりに向けて、UX Researcher は、チームにとってこのプロセスがどのように進んだかについてフィードバックを得るため、振り返りコメントスレッドを開きます。これは、計画プロセスを振り返り、そのサイクルを通じてリサーチがどう進んだかを話し合い、次のサイクルで行う改善を特定する機会です。
振り返りコメントスレッドで検討できる質問:
- うまくいったことは何ですか?
- あまりうまくいかなかったことは何ですか?
- 最も重要なリサーチプロジェクトに優先順位を付け、実行できたと感じますか?
c955a93f)