Content last updated 2026-02-23

チームプロセス

Product Data Insights チームのプロセスの概要

Issue の衛生 (Issue hygiene)

必須項目

すべての Issue には以下が必要です:

Team::PDI ラベル
- これは、チームの作業を特定し追跡するために使用されるラベルです
product data insights ラベル
ワークフローラベル (例: workflow::1 - triage)
PDI 優先度ラベル (例: pdi-priority::2)
セクション優先度ラベル (例: section-priority::1)
セクションラベル (例: section::dev)
- 「この作業はどのセクションをサポートしているのか？」という質問に答えます
ステージラベル (例: devops::create)
- 「この作業はどのステージをサポートしているのか？」という質問に答えます
グループラベル (例: group::code review)
- 「この作業はどのグループをサポートしているのか？」という質問に答えます
Issue の重み
イテレーション (Issue がスケジュールされた後)

Issue のワークフロー

上記で述べたように、すべての Issue にはワークフローラベルが必要です。これらは、私たちのボード上で Issue の現在のステータスを追跡するために、最新の状態に保つ必要があります。 Product Data Insights チームは、Data チームが使用するワークフローラベルのサブセットを使用しています。

ステージ (ラベル)	説明	完了基準
`workflow::1 - triage`	新しい Issue が初期評価を受ける	要件とビジネスコンテキストが完了
`workflow::3 - refinement`	Issue がスコープ化されリファインされる	Issue が完全にスコープ化されリファインされる
`workflow::4 - ready to develop`	Issue が開発を待っている	Issue で作業が開始
`workflow::5 - development`	作業が進行中	Issue がレビューに入る
`workflow::6 - review`	レビュー待ちまたはレビュー中	Issue がクローズ基準を満たす
`workflow::X - blocked`	Issue に、担当者が実行できない介入が必要	作業のブロックが解除される

ブロックされた Issue

Issue がブロックされた場合:

workflow::X - blocked ラベルを適用
なぜ/どのように Issue がブロックされているか、Issue のブロックを解除するために必要なこと、ブロック解除の推定日 (わかっている場合) を説明したコメントを追加
作業のブロックを解除する Issue へのリンク (該当する場合)

イテレーションのロールオーバー

新しいイテレーションを開始するとき、前のイテレーションからのオープンな Issue は自動的にロールオーバーされません。そのため、Issue が完了する前に視野から外れないよう、Issue を更新することに注意する必要があります。

イテレーションの終わりに、アナリストは残っているオープンな Issue をレビューし、イテレーションの値を更新して、イテレーションボードで Issue を追跡できるようにする必要があります。

計画外の作業

イテレーションが開始した後に、優先度の高いおよび/または緊急の作業が発生することがあります。計画外の Issue がイテレーションの途中で開かれた場合:

利害関係者に、その作業がなぜ優先される必要があるのかを Issue に文書化してもらう
- 計画外の作業を現在のイテレーションに引き入れるべきかどうか不明な場合は、Manager, Product Data Analysis が優先順位付けの最終決定を行います
Unplanned ラベルを適用
計画外の作業が他の計画された Issue を置き換えるほど大きい場合は、該当する利害関係者に連絡し、彼らの Issue が遅延していることを認識してもらう

他のプロジェクトの Issue

Product Data Insights および Data チームプロジェクトの外側でアナリストに割り当てられている Issue が開かれることがあります。そのため、追跡が困難で (私たちのボードに表示されないため)、私たちの速度にもカウントされません。作業を捕捉するために、アナリストは Product Data Insights プロジェクト内にプレースホルダー/追跡 Issue を開くオプションがあります。プレースホルダー/追跡 Issue は、元の Issue へのリンク、および標準ラベル、イテレーション、重みなどを含むべきです。

Issue のクローズ

セルフレビュー

すべてのコードと Issue はセルフレビューを受ける必要があります。当たり前のように思えるかもしれませんが、チームが高品質で信頼できる作業を生み出していることを保証するために重要です。

セルフレビューのチェックリスト:

コードがエラーなく実行される
結果が論理的に意味をなす
集計された結果が「既知の真実」と一致する (例: 総ユーザー数、ベースラインコンバージョン率など)
結果の非集計版が期待どおりに動作する (該当する場合)
- 単一のエンティティ (例: 自分自身のアクティビティ) を JOIN などの操作を通して追跡すると、結果が意味をなす

ピアレビュー

次の場合は、ピアにコードおよび/または発見をレビューするよう依頼すべきです:

チームに新しい場合
データセットに新しい、または不慣れな場合
コードが再利用されたり、視認性が高い場合 (例: Sisense スニペットやダッシュボード)
コードが実験を測定するために使用される場合
出力が重要なビジネス上の決定を伝える場合
追加の目が欲しい場合！レビューを依頼することは決して悪いことではありません

ピアレビューに送る前に、以下を確認してください:

コードがセルフレビューに合格している
Issue またはコードが目的および/または望ましい出力を明確に指定している
コードが十分にコメントされていて、フォローしやすい
- これには、JOIN、WHERE 句で使用される値などへのコメントが含まれます。疑わしいときは、コメントを追加してください
- 参照を明示的にするために、カラム名にエイリアスを追加することを検討してください
特定の懸念事項や焦点を当てるべき領域が指摘されている
- 例: 「この LEFT JOIN に追加の目が欲しい」、「これは最も複雑な 2 つの CTE です」など
- コードの一部がすでにレビューされている場合は、何が新しく何が変わっていないかを指摘してください

レビューをリクエストするには、Product Data Insights プロジェクトで MR を開きます。

code_reviews/ の下に新しいディレクトリを追加し、Issue 番号を名前として使用
- 例: Issue # 60 のコードレビューの場合、ディレクトリは code_reviews/60/ にする必要があります
その新しいディレクトリ内のファイルにクエリまたはコードを追加
- 例: code_reviews/60/experiment_events_snippet.sql
MR が開かれたら、チームに連絡してレビューする余裕がある人がいるかを確認
- レビューされ承認されるまでコードをマージしない

レビューに MR を使用すると、簡単なフィードバックとコラボレーションが可能になります。ただし、そのディレクトリのコードはすぐに古くなる (例: 別の Issue でスニペットに追加の変更が加えられる可能性がある) ため、クエリを SSOT とみなすべきではありません。

Issue クローズのチェックリスト

Issue をクローズする前に、以下のチェックリストを使用してください:

コードがセルフレビューとピアレビュー (該当する場合) に合格
発見または結果が Issue に文書化されている
別のチャネルを通じた追加のコミュニケーションが Issue に記念されている (例: Slack での会話、会議でのディスカッションなど)
- 実際のテキスト (スクリーンショットでも) を含めるか、コミュニケーションの簡単な要約を書く
- ガイドライン: 6 か月後に新しいチームメンバーが Issue を見たときに、必要なコンテキストがすべて Issue に含まれていて、チームメンバーが発見を理解できる
コードが Issue に含まれている (またはリンクされている)
- ここでは、マークダウンの折りたたみセクションを使うのが便利です！
折りたたみセクションの例
```
<details markdown=1>
  <summary>これはセクションの名前です</summary>

  ```

  ここにコードを追加

  ```

</details>
```
発見が利害関係者に伝えられている
他の DRI をタグ付け (該当する場合)
- 例: 発見が Create に関連する場合は、該当する Create PM をタグ付け
利害関係者が Issue をクローズしてよいと同意している
- スコープクリープに関するルールを覚えておいてください。未解決の質問やフォローアップがある場合は、新しい Issue に移動してリンクできます
次のステップまたはフォローアップのある新しい Issue を開き、元の Issue にリンク (該当する場合)

チームの速度 (velocity) の計算

Product Data Insights チームは、速度を決定するために 2 つの異なる完了作業の測定値を使用します。1 つはイテレーション中に完了した Issue で行われた作業に基づくもの (Completed Issue Weight)、もう 1 つは行われた作業量に基づくもの (Issue がクローズされていなくても) (Total Issue Weight) です。どちらの場合も、Analyst Working Days を分母として使用します。

Completed Issue Velocity

これは、私たちのメインハンドブックページで概説された、より伝統的な速度計算です。これは、イテレーション中にクローズされた Issue で行われた作業に限定的に結びついており、次のイテレーションにロールオーバーされる Issue の作業は考慮されません。

Completed Issue Velocity = Completed Issue Weight / Analyst Working Days

「Completed issue weight」は、イテレーション中に完了した Issue で行われたすべての作業の合計として定義されます。

Total Issue Velocity

これは、速度のあまり伝統的でない適応で、内部チームメトリクスとして使用されます。Issue がクローズされていなくても、イテレーション中にアナリストが行ったすべての作業を捕捉することを意図しています。私たちの作業の性質を考えると、Issue が次のイテレーションにロールオーバーすることは珍しくなく、特に計画外の作業が発生して優先順位が変わる場合に顕著です。このバージョンの速度は、イテレーションの途中で開始されたより大きなプロジェクトや作業を制御します。

Total Issue Velocity = Total Issue Weight / Analyst Working Days

「Total issue weight」は、部分的に完了した Issue での作業を含む、イテレーション中に行われたすべての作業の合計として定義されます。

以下に 2 つの例を示します:

アナリストがイテレーションの終わり近くに 8 ポイントの Issue を開始し、半日分 (3 ポイント) の作業を完了します。
- Completed Issue Velocity には 0 ポイントがカウントされます
- Total Issue Velocity には 3 ポイントがカウントされます
次のイテレーションで、アナリストは前のイテレーションで開始した Issue の残りの 5 ポイントの作業を完了します。
- Completed Issue Velocity に 5 ポイントがカウントされます
- Total Issue Velocity に 5 ポイントがカウントされます

ワークロードキャリブレーション

Product 部門の流動的な性質と会社の優先順位の変化を考えて、PDI は年に 2 回ワークロードキャリブレーションを実施します。大まかに言うと、キャリブレーションの目標は、PDI のワークロードがチーム全体に公平に分散されていることを確認することです。たとえば、製品の特定領域へのより大きな焦点につながる会社の優先順位の大きな変化がある場合、単一のアナリストが作業で過重負担にならないように人員配置されていることを確認すべきです。

キャリブレーションの目標

ワークロードキャリブレーションは次のことを意図しています:

Product 部門に可能な限り最高のサポートを提供する
コンテキストスイッチを最小限に抑え、成果物に対する合理的な期待を維持することで、アナリストを成功に導く
健康的なワークライフバランスを可能にする

このキャリブレーションは、アウトプットに関してアナリスト同士を比較する練習ではありません。

キャリブレーションでの考慮事項

キャリブレーション中に考慮すべきいくつかの異なる項目があります (優先順位順ではありません):

流入する作業の量
- 利害関係者がどれくらいの頻度でバックログに追加し、どれくらいの作業を提供する必要があるか？
流入する作業のタイプと複雑さ
- 流入する作業は主にアドホック要求、PI チャート更新、深掘りなどで構成されているか？
流入する作業の相対的な緊急性と予想される処理時間
- アナリストは作業を前もって計画できるか、または不釣り合いな量の緊急で計画外の作業があるか？
利害関係者の量
- アナリストが維持する必要のある関係はいくつあるか？
必要な製品の知識
- アナリストは、製品の大きく異なる機能/領域に関する詳細な知識を必要とするか？
関連データの必要な知識
- アナリストは特定のデータソースに特化する必要があるか？アナリストは複数の異なるタイプのデータ/データソースで SME である必要があるか？
「その他の」作業の量
- PM のサポートに加えて、アナリストは他のクロスファンクショナルなイニシアチブに従事しているか？
アナリストのフィードバック
- アナリストはワークロードが合理的でバランスが取れていると感じているか？
- これは間違いなく最も重要です！

キャリブレーションのメカニズム

(レビューの正確なメカニズムはまだ WIP です)

プロダクトアナリストは、上記の検討事項のすべての領域への入力を提供します。さらに、PDI 管理職は会社の優先順位に対するワークロード割り当てを評価します。

キャリブレーションの頻度

PDI は年に 2 回、Q1 と Q3 に向かう前にキャリブレーションを実施します。アナリストが利害関係者との四半期計画に適切に関与できるようにキャリブレーションを完了することを目指します。理想的には、キャリブレーションは優先順位の変化やワークロードの不均衡に対処するのに十分な頻度で行いますが、作業を妨げるほど頻繁ではありません。

キャリブレーションの頻度とタイミングの両方は、必要に応じて再考できます、再考します。

スタイルガイドライン

Product Data Insights グループは、Data チームの SQL スタイルガイドとベストプラクティスに従います。

チームミーティング

毎週の Product Data Insights ナレッジ共有とイテレーション計画
- 出席者: Product Data Insights チーム
- 目標: 毎週のナレッジ共有と集合的なブレインストーミング。隔週でイテレーション計画を行うためにミーティングが延長されます。
- アジェンダ: リンク
Product Data Insights オフィスアワー
- メインの Product Data Insights ハンドブックページを参照

ギア比

GitLab では、機能別の長期的な財務目標を予測するためのビジネスドライバーとしてギア比を使用しています。Product Data Insights グループは現在、1 つのギア比に焦点を当てています: プロダクトアナリストあたりのプロダクトマネージャー。将来、他の比率 (例: プロダクトアナリストあたりのアクティブな実験) を検討する可能性がありますが、現時点では PM:プロダクトアナリスト比率に焦点を当てています。

目標

プロダクトアナリストあたりのプロダクトマネージャー比率の長期的な目標は 3:1 です。この比率で成功するためには、PM が日常的な質問や活動を自助できる能力が重要な要素であり、最適なツールを見つけることが FY23 Q2-Q3 の R&D Fusion チームの焦点となっています。さらに、アナリストがコンテキストスイッチ (関連のないあるタスクから別のタスクへの切り替え) や異なるデータセットのニュアンスの学習により多くの時間を費やすのではなく、実際に分析を行うことに時間を費やすことを保証したいと考えています。プロダクトアナリストは、複雑な質問に答え、メトリクスを開発または改善し、ビジネスクリティカルな推奨事項を作成することに時間を費やすべきです。

目標比率を検証するために、LinkedIn、Intuit、HubSpot、Squarespace、iHeartRadio、Peloton Digital を含む他の大規模なプロダクト組織のプラクティスを調べました。ほとんどがプロダクトアナリストあたり 1.5 ～ 3 名の PM 比率を、セルフサービスツールに加えて維持していることがわかりました。そのため、3 PM:1 プロダクトアナリスト比率の目標を設定することに自信があります。

ギャップを縮める

現在の PM:プロダクトアナリスト比率は ~7:1 です - 40 名の IC プロダクトマネージャー (現在の募集を含む) と 6 名のプロダクトアナリスト (5 名の IC と 1 名の IC/Manager ハイブリッド)。ギャップを縮めて 3:1 の目標に向かう中で、PM にはオフィスアワーの活用をお勧めします。

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

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