データチーム - 働き方

クイックリンク

• カレンダー
• インシデント管理
• MR の役割と責任
• 新しいデータソース
• プランニングドラムビート
• トリアージ
• データチームオンボーディング
• データチームプログラム

データチームプロジェクトへのコントリビューションの実践ガイド

GitLab でデータに実際に携わりたいですか？すべてのチームメンバー向けに設計された実践ガイドをご確認ください。

このガイドは既存のリソースを補完するものですが、データチームのプロジェクトにコントリビュートするためのステップバイステップのプロセスにより実践的な焦点を当てています。

働き方

私たちはデータを活用して目標を達成できるようお手伝いします。有限な時間とキャパシティを持つ中央共有サービスとして、また会社の中央エンタープライズデータを運用・開発する責任を持つ者として、データチームは全体的なグローバル最大化に向けて顧客の成果を向上させるために最大のプラスの影響をもたらすイニシアチブに時間とエネルギーを集中させる必要があります。

作業の分類と優先付け

データチームは、エンタープライズデータプラットフォームと関連システムの開発・運用、システム全体のデータフローを最新の状態に保つこと、分析に利用可能なデータの幅を定期的に拡大すること、高い影響を持つ戦略的プロジェクトの提供に大半の時間を費やすよう努めています。以下のフレームワークを使用して作業を分類します。

本番環境のメンテナンス、データチームの OKR、ビジネスオペレーション全体のキャパシティの割り当ては、計画ファイル内で各ピラーが四半期ごとに決定します。目標とする割り当ては、データチームのピラーとビジネスのニーズによって異なります。割り当ては、ピラーに必要な本番環境のメンテナンスサポートの量、ピラーが支援する必要がある戦略的イニシアチブ、およびサポートが必要なビジネスオペレーションプロジェクトを考慮します。各作業カテゴリー内では、Issue は独立して優先付けされ、オプションとして 1、2、3 の優先度のスコープラベルを使用できます。

作業カテゴリーの追跡と優先付けには GitLab のスコープラベルを使用します。

上記のエンタープライズデータプラットフォームと関連システムの運用・開発に焦点を当てた作業カテゴリーに加え、エンタープライズデータチームは四半期ごとに学習と実験に時間を費やします。この時間は、新しいスキルを習得したり、新技術を試したり、データプログラムを改善するために使用されます。これらの学習と実験の Issue は、個別成長計画とデータプログラムを改善する方法を考慮しながら、チームメンバーとそのマネージャーの間で優先付けされます。

プロジェクトの取り込み

新しいデータ Issue を作成するためのプロセスは以下のとおりです。

1. Data Team Analytics プロジェクトで新しい Issue を開いてください。
2. 要求している作業に最もマッチする以下の表からテンプレートを選択してください。
3. テンプレートの説明をできるだけ完全に記入してください。
4. 担当者は空白のままにしてください。データチームはデイリートリアージの一部として要求を処理します。

バックログのグルーミング

バックログのグルーミングは、バックログを健全で実行可能な状態に保つためにレビューしてクリーンアップする継続的なプロセスです。定期的なグルーミングにより、ビジネス価値を提供し続ける作業に集中できます。これはデータチームのすべてのメンバーの共同の責任です。チームメンバーは、自分に割り当てられた Issue や自分が作成した Issue を定期的にレビューし、不要になった、置き換えられた、古い（アクティブなビジネスニーズなしで 365 日間触れられていない）、または十分な詳細がない項目をクローズする必要があります。項目をクローズしても作業は失われません。優先度が変わった場合は再開できます。判断を活用し、不確かな場合はマネージャーやステークホルダーに相談してください。グルーミングは年間を通じて行われます。

注: 自動化されたトリアージポリシーは、365 日間変更されていない Issue を自動的にクローズします。ボットは Issue 内の（技術的な）変更を確認するため、Issue へのリンクのようなアクションも更新としてカウントされ、クローズを防ぎます。

バックログ管理と優先付け

データチームのバックログは、データチームが取り組むことができるが、まだ開発作業を開始していないすべての Issue で構成されています。これには workflow::2 - waiting for prioritization、workflow::3 - refinement、workflow::4 - ready to develop のステージの Issue が含まれます。これらの Issue はトリアージ中に検証され、開発に値すると判断されたものです。

バックログの定義

バックログを構成するもの:

• workflow::2 - waiting for prioritization、workflow::3 - refinement、workflow::4 - ready to develop のステージの Issue
• トリアージされてスコープが設定された、十分な詳細がある Issue
• ビジネス価値を提供することが判断されており、開発リソースに値する作業

バックログの一部でないもの:

• workflow::1 - triage & validation にある Issue（まだ検証されていない）
• workflow::5 - development またはそれ以降の Issue（開発作業がすでに開始されている）
• トリアージ中に won’t-fix またはクローズとマークされた Issue

優先付けフレームワーク

戦略的プロジェクト（データチーム OKR）

特徴:

• 会社の目標に沿った大規模なイニシアチブ
• 大幅なクロスファンクショナルな調整が必要
• 通常（複数の）四半期にわたるか、実質的なスコープを持つ
• Data Team OKRs としてラベル付けする必要がある

スケジューリングプロセス:

• データステアリング委員会との協力を通じて四半期ごとにスケジュール
• 四半期計画サイクル中にレビューして優先付け
• 評価のためのOpportunity Canvas文書が必要
• データステアリング委員会のレビューと承認が必要

ビジネスオペレーションプロジェクト

特徴:

• 日常業務を支援する小規模で戦術的な改善
• 通常、より短い期間（週から月）で完了できる
• 特定のビジネスパートナーのニーズや運用効率をサポート
• 緊急のビジネス要件に対応する場合がある

スケジューリングプロセス:

• データチームメンバーが継続的にスケジュール。
  • チームは quarter:: ラベルを使用する場合があります。これは現在の四半期のチームが優先する作業を示します。新しい Issue が利用可能になったとき、チームメンバーは最初に四半期ラベルの付いた Issue から選ぶ必要があります。 このラベルは最終的なコミットメントではなく、新しい情報/優先度が生じるにつれて四半期を通じて Issue にラベルが追加/削除される場合があります。
• 適切な場合は関連するビジネスパートナーと調整
• チームメンバーのキャパシティに応じて優先付けして着手できる
• チームメンバーの専門知識と現在の作業負荷に沿っている必要がある

データチームメンバーのエンパワーメント

データチームメンバーは、GitLab のManager of Oneの原則に従い、ビジネスオペレーションプロジェクトのスケジューリング決定を独立して行うことができます。チームメンバーは以下のことを行う必要があります。

1. 現在の可用性と作業負荷を評価する - 進行中のコミットメントとキャパシティをレビューする
2. ビジネスへの影響と緊急度を評価する - 即時のニーズと戦略的価値の両方を考慮する
3. 次に優先して取り組む作業について自律的な決定を行う
4. 決定を透明に伝える - Issue の割り当てとステークホルダーを速やかに更新する
5. 必要に応じてマネージャーに相談する - 複雑な決定や追加サポートが必要な場合はガイダンスを求める

動的な優先付けと作業負荷管理

変化するビジネスニーズ、緊急の問題、または新しい戦略的イニシアチブに基づいて優先度が変わる場合があります。バックログ管理に対する私たちのアプローチはこの現実を認識しており、透明性と説明責任を維持しながらチームメンバーが動的に適応できるようにします。

より高い優先度の作業が出てきた場合（自分自身、ビジネスパートナー、またはマネージャーによって識別された場合のいずれか）、チームメンバーは進行中のイニシアチブを一時停止して、より重要な項目を優先する必要があります。ただし、優先度変更のアプローチは作業のタイプによって異なります。

「今すぐやる」アプローチ:

他の作業や他のチームメンバーからのガイダンスをほとんど必要とせずに、すぐに完了できるほど単純で直接的なタスクについては、チームメンバーは「今すぐやる」アプローチを使用できます。これはエンパワーメントの原則を基にしており、単純な問題を対処するための効率的な方法を提供し、バックログの蓄積を減らすのに役立ちます。例には、クイックドキュメントの更新、単純な設定変更、または軽微なバグ修正が含まれます。

KR と戦略的プロジェクト: 一般的に複数の四半期にわたる大規模な作業である KR については、優先度の変更は広範なアラインメントを必要とします。KR は通常複数のチームからの貢献を必要とし、1 人のチームメンバーがより高い優先度の作業に移行する場合、KR と他のチームメンバーの作業全体への影響に基づいて議論する必要があります。KR 関連作業を一時停止または優先度を下げる前に、チームメンバーはマネージャーと関連するステークホルダーに相談して、より広い影響を評価する必要があります。

ビジネスオペレーションプロジェクト: 優先付けの柔軟性はビジネスオペレーションのイニシアチブに対してうまく機能します。より高い優先度の作業が出てきた場合、チームメンバーは進行中のビジネスオペレーションプロジェクトを一時停止し、既存の Issue をバックログに戻し（workflow::2 - waiting for prioritization）、ステークホルダーに変更と更新されたタイムラインを知らせ、一時停止した作業から自分自身の割り当てを外してラベルを適切に更新することができます。

このアプローチにより、優先度が変わっても何が起きているかと理由をステークホルダーが常に把握できるようにしながら、異なるタイプの作業に対する異なる調整要件を認識します。

チームメンバーはあまりにも多くの同時イニシアチブを抱えないようにする必要がありますが、「多すぎる」かどうかはいくつかの要因によって異なります。

• 個々のチームメンバーの経験とキャパシティ
• 作業の複雑さとタイプ
• 現在のビジネスの優先度と締め切り
• 外部の依存関係とコラボレーション要件

硬直したルールを課す代わりに、チームメンバーが自分の判断を使い、キャパシティについて不確かな場合はマネージャーに相談することを信頼します。このアプローチは GitLab の Manager of One の原則と一致します。

割り当ての意味と期待

データチームメンバーが自分自身を Issue に割り当てると、それは以下を示します。

• 完了まで Issue のオーナーシップを持つ
• プロアクティブなコミュニケーションと定期的な更新の責任を持つ
• 合理的かつ伝達された期間内に提供するコミットメントを持つ
• 作業に関連する技術的決定を行う権限を持つ

バックログの可視性と管理

ラベリングと追跡

Issue の適切なラベリングと割り当ては、バックログの可視性とチームの調整のための基盤として機能します。

現在のバックログのサイズは、workflow::2 - waiting for prioritization、workflow::3 - refinement、workflow::4 - ready to develop とマークされたすべての Issue（サイズの見積もりを含む）を通じて即座に把握できます。これにより、着手する準備ができた検証済み作業の明確な全体像が得られ、チームメンバーが次の優先度を識別し、マネージャーが前に控えている作業量を把握するのに役立ちます。同様に、アクティブな作業はチームメンバーに割り当てられた Issue と開発ステージを通じて進行状況が表され、現在何が提供されているかについての洞察を提供します。

ラベリングは、問題になる前にボトルネックを特定するのに役立ちます。過度の同時割り当てを持つチームメンバーを確認できれば、作業を再分配したり、追加サポートを提供したり、競合する要求を優先付けする手助けをしたりすることが可能になります。この可視性は、持続可能な作業習慣を維持し、燃え尽き症候群を防ぐために非常に重要です。

モニタリングと指標

チームリードとマネージャーは定期的に以下をレビューする必要があります。

• バックログのサイズと Issue の経年
• チームメンバーの作業負荷の分散
• 戦略的作業と運用的作業に費やす時間
• 対応時間に対するステークホルダーの満足度

新しい Issue

データステアリング委員会

データステアリング委員会は GitLab 全体のパートナーチーム（マーケティング、セールス、カスタマーサクセス、財務、IT、サポート、プロダクト、エンジニアリング、ピープル、セキュリティ、リーガル）の代表者を含み、GitLab のデータ管理と分析イニシアチブの戦略的方向性を監督・推進するために使用されます（プロジェクトの優先付けを含む）。このフォーラムは、ビジネス目標のサポート、意思決定プロセスの改善、イノベーションの推進のためにデータが効果的に活用されることを確保します。データガバナンス、データ品質、データプライバシー、データセキュリティのポリシー、標準、ベストプラクティスを確立するための統治機関として機能します。

OKR/プロジェクトをデータステアリング委員会を通じて優先付けするためには、Opportunity Canvas が必要です。Opportunity Canvas は、要求されている作業の詳細情報、その作業から期待されるビジネスへの影響、作業を達成するための大まかな工数見積もり、および既知のリスク/依存関係を含む特定の Issue テンプレートです。Opportunity Canvas には、バックログの作業を優先付けしランク付けする一つの要素であるバリューカリキュレーターに基づくビジネス価値スコアも含まれています。

四半期の途中で新しいプロジェクトが提起され、次の四半期計画サイクルより早く優先付けすることが提案された場合、フォーラムは新しいプロジェクトの Opportunity Canvas をレビューし、ビジネス価値と影響が再優先付けを正当化するかどうかを判断し、必要なトレードオフ（すなわち、その新しい作業を優先するためには、他の計画された作業の優先度を下げる必要がある）に関する決定を行います。

対応の迅速化の要求

対応、トリアージの Issue、または MR レビューの迅速化の要求はまれです。データチームの共有サービスモデルを考えると、1 つのタスクを優先すると、必然的に他の作業の優先度が下がります。迅速な対応を要求するには:

1. 自分の要求を他者よりも先に進める有効な理由があることを確認してください。
2. #data に Issue へのリンクと迅速な対応が必要な理由を含めて投稿してください。データチームの個人に直接 DM しないでください。
3. データチームのメンバーが 1 営業日以内に対応します。

何をどのように構築するかを決定する

すべてのデータソリューションが同じレベルの品質、スケーラビリティ、パフォーマンスを必要とするわけではないため、必要な成果と投資レベルを合わせるためのデータ開発フレームワークを定義しました。データチームはすべてのチームと協力してニーズに適したソリューションを構築しますが、信頼できるデータ開発を使用した_信頼できるデータ_に集中します。

デザインスパイク

実験は探索的なデータ開発を行うための優れたアプローチです。多くの場合、ビジネス問題を解決するための複数のソリューションが存在し、さまざまなアプローチを効率的に評価して最終的に信頼できるデータソリューションに昇格させるソリューションを選択するためのプロセスが必要です。私たちは実験を促進するためにデザインスパイクを使用します。デザインスパイクは、提案されたソリューションが大きな変更や、データテックスタックの全体的なデザイン、構造、計算への大幅な変更をもたらす場合に特に有用です。

デザインスパイクを実行する際は、以下の手順に従ってください。

1. 価値の計算: データソリューションが GitLab に提供できる価値を確立してください。価値は、効率性から増収、コンピューティングの削減まで、さまざまな方法で測定できます。
2. 要件の定義: デザインスパイクの要件ドキュメントを作成して、データソリューションが成功するために満たさなければならないビジネス要件と技術要件を定義してください。各要件が Must Have か Nice to Have かを示してください。
3. 実験デザイン: これはデザインスパイクの最も複雑な部分です。データソリューションを定義された要件に対してどのようにテストするかを決定する必要があります。データソリューションのテストが成功するためには、多くの場合、本番ワークロードのシミュレーションが必要です。スコープ内のデータセット全体を代表する実験結果を達成するために、デザインに含めるデータの最小実行可能なサンプルサイズを定義する必要があります。
4. 実験の実施: これは「キーボードに指を置く」ことを含み、探索的なデータ開発環境にデータソリューションを立ち上げます。また、要件の定義フェーズで定義したことに従って実験の結果を収集することも含まれます。
5. 評価: 実験が完了したら、各データソリューションが要件の定義フェーズの要件に対してどれだけうまく機能したかの分析を実施し、各データソリューションが Must Have または Nice to Have の要件に対してどれだけうまく機能したかを確認します。この分析を、デザインスパイクの結果に基づく推奨ソリューションとともにドキュメントに記入する必要があります。その後、プロジェクトの各 DRI とステークホルダーに提出して、ユースケースの進め方に関するレビュー、フィードバック、最終決定を求めることができます。

ドキュメンテーション

データチームは GitLab の他の部門と同様に、できる限り多くのことを文書化するよう努めています。私たちは Divio によるこのドキュメントフレームワークが非常に価値があると考えています。ほとんどの場合、ハンドブックに記録されているのはチュートリアル、ハウツーガイド、説明であり、リファレンスドキュメントは主要な分析プロジェクト内にあります。私たちは、適切な機能でドキュメントにタグ付けし、各ドキュメントの想定される読者を明確に表現することを目指しています。

ドキュメントガイドライン

トピックを記録するために使用するいくつかのタイプのドキュメントがあります。どのタイプのドキュメントをいつ使用するかについての基準を記します。

• （公開）ハンドブック - 会社とチームで使用する運用モデルに関する項目、ツール、技術、プロセスについてのすべての説明、およびなぜそうするのかについての情報。公開して共有可能なデータで、GitLab またはその顧客に害または重大な影響を与えない（データ分類によるグリーンデータ）。
• 内部ハンドブック - パブリックハンドブックと同じカテゴリーを説明する項目で、内部ハンドブックには内部情報が含まれるという違いがあります。
• Readme.md ファイル - README.md ファイルが存在するコードに関連する特定の情報で、そのコードの使用方法を説明します。追加の説明が必要な場合は、ハンドブック記事を使用したり、リンクしたりすることがよい実践です。
• Runbooks - 本番環境で問題を解決する方法や他の問題を解決する方法を説明するコンテキスト。重要なことは、Runbook は問題解決アプローチのガイドラインであることを理解することです。
• WIKI - エピックに似ているが、より長期間にわたる定期的な更新が必要な項目（例: クォーター・トゥ・キャッシュプロジェクトへのデータチームの全体的な取り組み）。

どのドキュメントタイプをいつ使用するかの説明マトリクス:

データチームバリューカリキュレーター

バリューカリキュレーターは、ランク付けのための均一で透明なメカニズムを提供し、すべての作業を平等な条件で評価できるようにします。バリューカリキュレーターのアプローチは、プロダクトマネージャー向けの RICE スコアリングモデルやマーケティング向けのデマンドメトリクス優先付けモデルに似ています。

以下のカリキュレーターは、このバリューカリキュレータースプレッドシートに基づいています。以下の値を選択して新しい作業の価値を定義してください。

四半期とイテレーション計画

私たちの計画プロセスはプランニングドラムビートと呼ばれ、四半期計画とイテレーション計画を含みます。プランニングドラムビートは、変化するビジネス優先度を管理するのに十分なアジリティを維持しながら、データチームが作業をより広い会社と整合させるのに役立つ最も重要な活動の 1 つです。

四半期 KR ステータスレポート

FY25-Q1 から、データチームは四半期ごとのコミットメントを管理するために GitLab Objectives and Key Results プロジェクトを使用しています。

プロセス:

1. コミットされたキーリザルトそれぞれについてプロジェクトで KR を作成します。
2. KR の説明に、開発作業が追跡されている GitLab データチームプロジェクトの対応するエピックへのリンクを追加します。
3. 四半期を通じて、ワークストリームの DRI は以下の更新を行います（最低限、Division:: スコープラベルが適用されている KR については、四半期の各月末に更新を追加する必要があります。一部のチームはより頻繁に更新することを選択する場合があります）。
   • 完了した作業と KR を完了するために残っている作業の概要を含むコメントを追加します。
   • KR の % 完了フィールドを更新します。
   • KR が On Track（順調）、Needs Attention（注意が必要）、At Risk（リスクあり）のどれかを示すようにヘルスステータスフィールドを更新します。

DataPulse

DataPulse は、セントラルデータチームメンバーがレベル 3 とレベル 4 のエピックのステータス更新を提供するための月次のショーケースです。目標は、すべての人がプロジェクトのステータスについて把握し、新しい機会を特定し、さまざまなワークストリーム間のアラインメントを維持することです。

私たちは以下を目的とした集中したセッションで集まります。

• お互いから学び、会話を豊かにする
• 特定の関心分野をより深く掘り下げる
• 浮かび上がった質問に対応する
• 課題の解決のためにコラボレーションする
• 次のステップを調整する

仕組み

• プレゼンター: 毎月 3 名のチームメンバーがアクティブなレベル 3 またはレベル 4 のエピックの更新を共有するために選ばれます。
• ローテーション: 幅広い可視性とクロスチームの認識を確保するために、チーム全体でプレゼンターを交代します。
• スケジュール: セッションは月次で実施され、すべてのタイムゾーンに対応するために IST/UTC と PST/EST のタイムスロットを交互に使用します。
• 録画: セッションのタイミングが自分のタイムゾーンに合わない場合にチームメンバーが後から視聴できるよう、セッションは録画されます。
• 形式: プレゼンターはセッション中にプロジェクトを共有します。チームメンバーは質問をしたり、フィードバックを提供したり、全体を通じてコラボレーションしたりすることが奨励されます。

インシデント

インシデントとは、混乱を防ぐか運用状態を回復するために即座の人的介入を必要とする、サービス低下、データ品質の問題、またはシステム障害につながる、またはその可能性がある異常な状態です。データシステムの場合、これには以下が含まれます。

• データの不可用性またはアクセス不能
• データの不正確さまたは破損
• データの鮮度違反（古い/時代遅れのデータ）
• 不正なデータ公開または漏洩

インシデント基準: すべての技術的障害がインシデントになるわけではありません。主な基準は以下のとおりです。

1. SLO 標準ごとの SLO 違反があるか
2. 下流モデル、ビジネス運用、またはデータコンシューマーへの即時の影響があるか
3. インシデントを解決するための即時対応が必要か

以下のイベントは通常インシデントとして認定されます。その他のケースも適用される場合があります。

• インフラの障害: Snowflake、Tableau、またはその他の重要なプラットフォームの利用不能
• ソースシステムの失敗: 外部データソースが停止または破損
• アクセスの問題: 複数のユーザーがデータプラットフォームシステムにログインして必要なものにアクセスできない
• ソース鮮度の失敗 SLO 違反
• dbt モデルの失敗 （下流の）データモデルが影響を受ける場合
• dbt テストの失敗 データ品質の問題を示す
• 不正確なデータ レポートが不正確なデータを表示している

インシデント基準: すべての技術的障害がインシデントになるわけではありません。主な基準は以下のとおりです。

1. データ、下流モデル、ビジネス運用、またはデータコンシューマーへの即時の影響があるか
2. SLO 標準ごとの SLO 違反があるか
3. インシデントを解決するための即時対応が必要か

詳細なインシデントの定義、重大度レベル、および作成手順については、データチームインシデント管理ハンドブックページを参照してください。

インシデントを通じて作業するためのプロセス

• 「Incident Report」テンプレートを使用してインシデント Issue を開いてください。または、既存の Issue がインシデント基準を満たす場合、それをインシデントに変換することもできます（注: 各 Issue に新しい行を追加して /incident と入力することでできます）。
  • 注: データプログラムに関連するインシデントは、一元化されたインシデント追跡と管理を維持するために常に Analytics プロジェクトに作成されます。
• 適切なタイムスタンプと重大度レベルを含む関連情報を詳細に記録してください。
• データチームと通知が必要なその他のチームの人々にタグを付けて割り当ててください。
• SRE とのコラボレーションが必要なインフラの問題については、対応する GitLab インシデントを維持しながら incident.io も使用してください。

データチームのインシデントは、Analytics プロジェクト内のインシデント概要ページでレビューできます。

ワークフローサマリー

一般的に、Issue はこのプロセスを線形に進めます。一部のテンプレート化された Issue は triage から scheduling または scheduled にスキップされます。

Issue ポインティング

Issue ポインティングは Issue の複雑さを表すものであり、Issue の完了にかかる時間ではありません。そのため、ポインティングは Issue の担当者が誰であるかに依存しません。

• ポイント値とその意味については、以下の表を参照してください。
• Issue のサイズとポイントはグループとして設定します。
• 効果的なポインティングは Issue がより詳細に作成されることを必要としますが、その要件は人々が Issue を作成することを妨げるべきではありません。
• データチームプロジェクト以外で行われる作業のポインティングを行う場合は、関連するデータチームプロジェクトの Issue にポイントを追加し、Issue が相互リンクされていることを確認してください。

Issue ラベリング

これらのラベルのグループはそれぞれ、行われた作業をバケット化する方法と考えてください。

すべての Issue には以下のラベルのクラスが割り当てられている必要があります。

• チーム: 作業を実行する責任があるデータチーム。データプラットフォーム、アナリティクスエンジニアリング、データサイエンス、BI、またはデータガバナンスのいずれかです。
• チャンピオン: 作業を要求するチーム。これは機能パートナーチームまたはデータチーム自体である可能性があります。
• ワークフロー: 作業の現在のステータス。すべての Issue は workflow::1 - triage ラベルから始まる必要があります。作業を実行するチームは、作業が進むにつれてワークフローステータスを更新する責任があります。
• 優先度: 作業の優先度レベル。以下のように分類されます。
  • P1: 運用（最高の緊急性）
  • P2: OKR 関連の作業（目標主導）
  • P3: その他（低優先度または非緊急タスク）

2025 年 1 月から有効で、データチームプロジェクトのボットを使用して、開かれてから 14 日後にチーム、チャンピオン、ワークフロー、優先度ラベルが Issue に適用されているかどうかを確認します。ボットは、見つからないラベルを追加するよう Issue 内でリマインダーを送信します。ラベルを追加するための最初のトリアージ対応は、Issue を開いたチームメンバーです。ラベルを追加するための 2 番目のトリアージ対応は、トリアージ中のデータアナリスト、データサイエンティスト、アナリティクスエンジニア、データエンジニアです。チーム、チャンピオン、ワークフロー、優先度ラベルが 30 日後に適用されていない Issue は自動的にクローズされます。必要なラベルが原因で Issue がクローズされた場合、チームメンバーはクローズされた Issue を再開して、Issue の精緻化要件を満たすためにラベルを適用するオプションがあります。

状態や他の優先度を伝えるのに有用なオプションのラベル:

• 何に関して:
  • データ: 処理されるデータ（Salesforce、Zuora、Zendesk、GitLab.com など）
  • ツール: （Tableau、dbt、Stitch、Airflow など）
  • ポッド: 作業をスケジュールしているデータチームポッド
• ビジネスロジック変更: このラベルは、新しいディメンション、ファクト、マートの追加、結合の変更、新しい計算フィールドの追加などのビジネスロジックの変更に対して適用されます。
• Opportunity Canvas: このラベルは Opportunity Canvas テンプレートに自動適用されますが、大規模なプロジェクトに変換された作業にも適用できます。このラベルは、月次データステアリング委員会での議論と優先付けのためのトピックを識別するために使用されます。

エピックラベリング

Issue ラベリングと同様に、エピックラベリングはデータチームがバックログのプロジェクトを分類、定量化、優先付けするのに役立ちます。

最低限、すべてのエピックには**チーム:**ラベルが適用されている必要があります。これにより、主に作業を実行する責任があるデータチームにエピックがタグ付けされ、マネージャーが各チームのプロジェクトのバックログをレビューできるようになります。これは四半期計画中に特に有用です。

エピックリストは親エピックのみに簡単にフィルタリングできないため（エピックはサブエピックとして他のエピックにネストされる場合があります）、OKR レベルのコミットメントが検討されているエピック（これらには Opportunity Canvas ラベルが適用されている必要があります）と、一般的なテーマの下に関連する Issue をグループ化するために使用されるエピック（これらには Opportunity Canvas ラベルを_適用すべきでない_）を区別するための追加ラベルを使用します。

マージリクエストワークフロー

理想的には、ワークフローは以下のとおりであるべきです。

1. 分析プロジェクトへのアクセス権があることを確認してください。ない場合は、ブランチ、マージリクエスト、Issue を作成できるよう開発者アクセスを要求してください。

2. Issue を作成するか、既存の Issue を開くか、または既存の Issue に自分自身を割り当てます。Issue は作業を行う人に割り当てられます。

3. Issue に適切なラベルを追加します（上記参照）

4. 「マージリクエストの作成」ボタンを使用して Issue から MR を開きます。これにより、Issue 名に基づいた固有のブランチが自動的に作成されます。これにより、MR がマージされると Issue がクローズされるようにマークされます。

5. ブランチに作業をプッシュします

6. 適切なテンプレートで MR を更新します。現在のテンプレートは以下のとおりです。

   • dbt 変更 - dbt が関係するすべての変更に使用。アナリストが最も頻繁に使用するもの
   • add_manifest_tables - pgp エクストラクトにテーブルを追加するため
   • periscope - Periscope ダッシュボードのレビューを受けるため
   • python_changes - Python コードへの一般的な変更のため
   • その他すべての変更 - 一般的にこれらのカテゴリに当てはまらない作業のため

7. 提案されている作業に関連するジョブを実行します

   • 例: dbt 変更に取り組んでいる場合、変更に最も適したジョブを実行してください。各ジョブの説明については CI ジョブページを参照してください。

8. MR の説明に、MR の目的、MR を有効にするために必要な追加の変更、および複雑な MR の場合は変更が機能することをどのように検証したかを文書化します。良いドキュメントの例については、この MR を参照してください。目標は、レビュアーが MR が何をしているかを理解しやすくすることで、できるだけレビューしやすくすることです。

9. マージリクエストレビュアー機能を使用して MR をピアに割り当てることでレビューを要求します。

   • このようにレビューを要求することは、その人にコードレビューとすべてが問題なければ承認を求めることを示します。これは彼らが承認した場合に MR をマージすることを意味するわけではありません。
   • ピアレビュアーは、MR のレビューを完了して MR の変更を承認した後、MR のネイティブ承認ボタンを使用する必要があります。
   • 承認後、レビュアーはレビュアーリストから自分自身を外すことができます。レビュアーは最終タスクに責任を持ちません。作者はチェックリストの最終化、スレッドのクローズ、下書きの削除、マージ準備完了状態への移行に責任を持ちます。

10. MR が承認された場合、Draft: ラベルを削除し、ブランチを削除としてマークし、コミットをスクワッシュとしてマークし、プロジェクトのメンテナーに割り当てます。添付された Issue が適切にラベル付けされポインティングされていることを確認します。

    • 一般的に、MR をメンテナーに割り当てることは、問題がなければそれをマージしてほしいことを示します。メンテナーが CODEOWNER グループの一部としてマージ前に MR を承認する必要がある場合は、マージ前にレビューを行います。そうでない場合は、単純にマージします。メンテナーのレビューを希望する場合は、そのようにコメントを残してください。
    • 誰かに MR を割り当てることは、その人からのアクションが必要であることを意味することに注意してください。
    • MR のタイトルにまだ Draft: が含まれている場合、メンテナーは作者に MR を割り当て直して MR がマージ準備ができているかどうかを確認します。

その他のヒント:

1. マージリクエストワークフローは明確な期待を提供しますが、以下のとおり特定のステップには若干の余裕と自由があります。

   • シンプルな変更については、スレッドをクローズする責任は MR 作者にあります。複雑な変更で懸念が対処された場合、レビュアーが承認すれば、作者またはレビュアーのいずれかがスレッドを解決することができます。

2. レビュアーはレビューを完了するために 48 時間あります。そのため、イテレーションの終わりに向けて事前に計画してください。

3. 可能であれば、MR をレビューのために提出する前にレビュアーと質問/問題について議論してください。特に大きな変更については、すでに作業の大半を終えているため、レビュー時に意味のある変更を行う必要があるのは最も非効率な時間です！

4. MR が最新のコミットで最新の状態になるよう、プライマリブランチからの最新のコミットをマージすることを検討してください。コメントに /rebase と入力することでこれを素早く行うことができ、GitLab がマージコンフリクトがない限り自動的に行います。

KPI 開発ワークフロー

データチームは、以下のステップが完了したら、エンタープライズデータベースモデルと BI レポートに KPI とパフォーマンス指標を追加する作業を行います。

• DRI は、KPI の定義、ビジネスロジック、計算ステップがハンドブックの関連セクションに文書化され、GitLab KPI のすべてのパーツとともに追加されることを確認する必要があります。
• ハンドブックの定義は、必要な協議された & 情報を受けるクロスファンクショナルパートナーによってレビューされる必要があります。場合によっては、定義はクロスファンクショナルパートナーからの承認も必要になることがあります。
• KPI がエンタープライズレポートに追加される準備ができたら、DRI は GitLab データチームの Issue トラッカーの標準データチーム Issue テンプレートを使用して Issue を作成する必要があります。
• データチームはデータソースを検証し、自動化する方法を見つけるのを助けます（必要な場合）。

KPI がエンタープライズ BI プラットフォームに追加されたら、データチームはテストと最終承認のために DRI にプレゼンします。

Issue とマージリクエストの SLO

• 新しい Issue のファーストレスポンス SLO: Issue 作成から 2 営業日
• 新しい MR のファーストレスポンス SLO: コードオーナーへの提出から 2 営業日

Issue を開くか MR をレビューのために提出する際は、DRI またはコードオーナーの注意を引くためのコメントを追加することがよいでしょう。追加の更新または Issue や MR に対するファーストレスポンスを要求する前に、SLO の期間が経過するまで待ってください。SLO 期間内の Issue と MR はブロックされているとは見なされません。Issue や MR が緊急または緊急修正のシナリオの場合は、必要な緊急性と重要性によって決定される SLO 期間内に Issue または MR 内のチームメンバーにフォローアップすることがよいでしょう。

削除プロセス

時間が経つと、環境には不要なソフトウェア/コード/コンポーネントが含まれるようになります。使用されていない、使用されていないように見える、または使用しないよう言われたソフトウェアを削除するのは危険に感じます（ユーザーアクセスが削除されている場合など）。

削除を実施する理由は複数あります。

1. 使用されなくなったソフトウェア（またはその一部）を確認する
2. ユーザーアクセスの削除要求がある
3. ユーザーアカウントの削除要求がある
4. データパイプラインを無期限に停止する要求がある

観察と要求に対処し、削除が制御された方法で行われることを確保するために、Cleanup Old Tech テンプレートを使用して Issue を開いてください。

Issue に削除のスコープを記述する

削除されるものを書き留め、可能であれば既存の Issue へのリンクを含めてください。

リスクスコアの計算

リスクスコアは 2 つの変数に基づいて構築されます。

1. 何かを壊す確率
2. 削除が誤って実行された場合または誤った方法で実行された場合の影響

各変数は 1 から 3 でスコアリングされます。

確率 * 影響 = リスクスコア

データ & アナリティクス成熟度年次評価

FY24 から毎年、データチームは GitLab チームメンバーからデータプログラムに関する匿名フィードバックを募るためのアンケートを実施します。このアンケートは、重点分野を推進し、時間とともに成熟度を追跡するのに役立ちます。

YouTube

全員がビデオを録画して GitLab Unfiltered に投稿することを奨励します。YouTube のハンドブックページは、なぜそうすべきかを非常によく説明しています。データチームのビデオをアップロードする場合は、以下の追加ステップを確実に行ってください。

• ビデオタグとして data を追加する
• データチームプレイリストに追加する
• Slack の #data チャンネルでビデオを共有する

データの採用とインタビュープロセス

1. 最新のプロセスとポリシーについて最新の状態であることを確認するためにピープルインタビューガイドをレビューしてください。
2. ピープル BP（ビジネスパートナー）に連絡して、求人の開始を知らせてください。ピープル BP は求人、採用要件、インタビュープロセスを管理する責任があります。
3. ピープル BP に追跡目的の要件番号を提供するよう依頼してください。複数の求人を同時に管理する場合は、複数の求人管理はすぐに混乱するため、この Req# を使用してピープル BP とコミュニケーションしてください。
4. インタビュープランを作成します。インタビュープランには各インタビュージョブロールタイプの責任、ヒント、リマインダー、カスタムインタビュー質問が含まれます。例については、データサイエンティストインタビュープランとアナリティクスエンジニアインタビュープランを参照してください。
5. 各データジョブロールとジョブレベルにはカスタマイズされたホームワーク評価があります。ホームワーク評価を必要に応じてレビューして更新してください。ジョブロールのホームワーク評価が利用できない場合は、作成してホームワーク評価 Google ドライブに保存してください。
6. ホームワーク評価を採用プロセスに含めるためにピープル BP に送付してください。採用プロセスは各データジョブファミリーに含まれており、候補者と面接官の期待を設定するのに役立ちます。例はデータエンジニア採用プロセスです。
7. インタビュアーと調整するための新しい Slack チャンネルを作成してください（例: bt-data-data-science-interview）。Slack を通じてインタビュアーとインタビュープランを共有してください。

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