DRI の責任

Organizations チームがチームイニシアチブの ownership を扱う方法

ハンドブックが説明しているように、特定のエピックの DRI ステータスとは、担当領域について「目標を明確に述べ、進捗を確認し、フィードバックを与え受け取る」ことができることを意味します。

私たちのチームでは、DRI ステータスは作業の一部の ownership を意味します。これはその中の作業をリファインすること、その作業に関する優先順位付けやスケジューリングの推奨を行うこと、そして進捗、ブロッカー、達成事項をチーム全体と共有するための定期的なアップデートを書くことにまで及びます。

なぜこれを行うのか？DRI ステータスは通常、迅速な意思決定をサポートするために使用されます。しかしそれはまた、あなたが主要な意思決定者であり最も情報を持った専門家である領域でのテクニカルリーダーシップを担うことも意味します。キャリア開発とチームへの影響の一部として、次に取り組むべき作業やエンジニアリングの複雑さによりエスカレーションが必要な領域を明確に述べる能力は、あなたにとっても GitLab にとっても非常に価値があります。

3 つの責任

個々のエンジニアは複数のエピックの DRI を同時に務めることがあり、チームの目標と成果物を代表します。作業の規模やシニアレベルによっては、この地位を他の人と共有することもあります。

DRI がエンジニアリングとプロダクトマネージャーをサポートすべき責任の 3 つの領域があります:

1. 過去の作業に関するステータスアップデート

毎週、特定のエピックの名前の付いた DRI は Epic Issue Summaries ボットから ping を受けます。このボットは DRI に構造化された週次アップデートメッセージの提供を求め、それが週の後半にさまざまな場所に組み込まれます。

2. 今後の作業のリファインメント

マイルストーンが進むにつれて、DRI はエピック内の今後の Issue をリファインメントのために選択する必要があります。これは、可能であれば自動化によって促進/サポートされる、スケジュールされた活動である必要があります: マイルストーン初期にプレースホルダー/スタブ Issue を早めに作成し、マイルストーンが進むにつれて実装計画で肉付けします。必要に応じてチーム全体を巻き込みます。マイルストーンの終わりに、進めるのに十分なリファインされた作業があることを確認し、必要に応じて詳細を追加し続けます。

3. 次のマイルストーンの計画

マイルストーンの終わりが近づくにつれて、DRI は次のリリースにずれ込む可能性のある作業と、新たに取り込むべき項目についておおよその理解を持っている必要があります。計画する新しい作業に対して推奨を行い（ブロッカー、依存関係、またはユーザーニーズを把握した上で Issue を積極的にスケジュールします）、特にいくつかの Issue を他よりも高い優先度にする必要があります。

これらのタスクは週に組み込むためのタイムマネジメントを必要としますが、エンジニアリングの観点から正しいことを優先し、ブロッカーやリスクをできるだけ早く表面化させ、定期的に（小さなものでも）勝利を祝うことができます。

各依頼の詳細なステップ

上記の各要件に対する DRI への期待についての詳細なガイドラインを以下に示します:

エピックのステータスアップデート

毎週月曜日に、Epic Issue Summaries ボットからステータスアップデートの ping を受けます。これらのアップデートはいくつかのことに使用されます:

  • 子エピックの仕事の良い表のサマリーで親エピックに伝播されます（こちらの例を参照）
  • Protocells 週次スタンドアップなどの同期コールアジェンダを埋めるのに役立ちます
  • 部門全体のグランドレビューに貢献するチームの週次 Outlook レポートをまとめるために使用されます

よく書かれたステータスアップデートには次のプロパティ/ゴールがあります:

  • コンテキストを低く保つ: チームの外に座っていたり、ワークストリームの基本的な知識しか持っていない人でも読んで各箇条書きが何を意味するか理解できる必要があります。
  • 勝利を説明する: 複雑な技術的背景を持つ何かを出荷した場合、詳しくない人にとって重要な理由を概説するための背景を追加します。
  • 詳細にはリンクを使用する: フォローアップしたい人もいるので、関連する MR、ブロッキング Issue、またはその他の有用な場所へのリンクを追加します。

言い換えると、悪いステータスアップデートはこのようなものです:

コンテキストがなく、ただリンクのリストになっており、作業のより広いインパクトを説明しようとしていないことに注意してください。

人々はこれらを読むので、書くことに時間と労力をかけてください！この対象者のために何かを表現する方法がわからない場合は、Duo に助けを求めてみてください。チームハンドブックのページにこのためのプロンプト例があります。確認して投稿できるエピックアップデートを自動的に生成できる自動化スクリプトもあります。

アップデートのベースとなる実際の良い例を以下に示します:

今後の作業のリファインメント

チーム全体がリファインメントを互いにサポートします。DRI（主題の専門家）にどこで助けるかをガイドするよう求めることでこれを行います。

エピックの DRI であれば、新しいチームリファインメントダッシュボードを訪問することでこれを行えます。このツールはあなたがアサインされているすべてのエピックを一覧し、workflow::refinement のラベルまたは Refinement のステータスを持つ子 Issue を拾い上げます。このツールを使用してリファインメントが必要な Issue を見つけてください。毎時更新されます。

  • 毎週エピックの今後の作業を見直す時間を確保する
  • Issue がリファインメントを必要としている場合、詳細（実装ガイド、ウェイト、Issue の分解など）を追加するために既存の指示に従う
  • 他の同僚のサポートが必要な場合は直接メンションするか、チームのグループタグを使用する:
    • @gitlab-com/gl-infra/tenant-scale/organizations/backend-engineers
    • @gitlab-com/gl-infra/tenant-scale/organizations/frontend-engineers
  • マイルストーンが進むにつれて、リファインメントが必要なアイテムの数が減っていることを確認する

今後のマイルストーンの Issue の計画

マイルストーンが終わりに近づき新しいものが始まると、今後のリリースにスケジュールする作業を推奨するよう求められます。これはプランニング Issue で追跡されます。すでにエピックのステータスを報告し、複雑さ、バグ、またはその他の不明点のためにずれ込む可能性があるものをフラグ立てしているはずです。

これが起きるとき、積極的であり行動へのバイアスのバリューに従ってください: 計画どおりに対応できないことが明らかになった場合、Issue を将来のマイルストーンに再スケジュールする権限を持っているはずです。これが起きるとき、全員が把握できるよう決定を説明するコメントを Issue に残してください。

それ以外の場合、新しい作業がリファインされたら、いつスケジュールするかの推奨を行ってください。優先順位の決定を行いたいと思うシナリオの例:

  • 外部要因が制約する場合（例: 組み込む必要がある必須の停止またはメンテナンスウィンドウ）
  • 順次デプロイのステップがある場合（例: 次のリリースで有効化できるよう、あるリリースでフィーチャーフラグを追加する）
  • 特定の機能を最初にリリースすることで別のチームのブロックを解消するというチーム間のインパクトがある場合

差し迫ったマイルストーンに対するエピックの ownership のこの種の優れた例を示します: https://gitlab.com/gitlab-com/gl-infra/tenant-scale/group-tasks/-/work_items/478#note_2807737845

覚えておいてください: あなたは直接責任者であり、この領域をよく知っています。チームはあなたにこの作業を所有してほしいと思っており、私たちがより速く到達するために役立つことを表明してほしいと思っています。

まとめ / TL;DR

  • 月曜日に低コンテキストでアップデートを書き、何かが良い（または悪い）理由の説明と何が助けが必要かを示す
  • 毎週エピック内の新しい作業をリファインし、他の人からのインプットを求める
  • 新しいマイルストーンが近づいたら、担当領域の次の優先順位の計画を手伝い、ずれ込む可能性があるものを確認する
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License