Organizations チーム

概要

Organizations チームの主な焦点は、Cells のコンテキストにおいてデータのシャーディングと分離に必要な Organization エンティティを開発することです。チームは製品内のグループ、プロジェクト、ユーザープロフィールのサポートも提供しています。

お問い合わせ

私たちに連絡するには、関連するプロジェクト（通常は GitLab）で Issue を作成し、~"group::organizations" ラベルと適切なその他のラベルを追加するのが最善です。

緊急の件については、Slack チャンネル（社内）: #g_organizations を気軽にご利用ください。

ビジョン

チームは Organizations を新しいトップレベルエンティティとして実装することで、GitLab のためのよりスケーラブルで統合されたアーキテクチャの開発に取り組んでいます。

Organizations はセルラーアーキテクチャ全体での配布を可能にする論理コンテナとして機能し、セルフマネージドと SaaS の GitLab インスタンス間の機能的なギャップを橋渡しします。 新しい Organizations エンティティは複数のトップレベルグループの傘として機能し、企業がグループ全体でコンテンツを集約し、組織全体のロールを実装し、コンテンツを他の Organizations から分離できるようにします。

同時に、チームはいくつかの重要な課題に対処することでグループとプロジェクトの改善を目指しています: 多様な企業構造に対応するためのより柔軟な階層の作成、グループ内でのプロジェクトのネストに関する混乱の軽減、製品全体での発見可能性の向上、削除と復元プロセスの標準化、アーカイブ機能と可視性の改善。 これらの改善は総合的に、企業が自社のビジネス構造を表現し権限を管理するための、より直感的で柔軟なシステムを構築することに向けて取り組んでいます。

ゴール

Organizations グループのエグゼクティブサマリーのゴールには以下が含まれます:

• GitLab.com のデイリーアクティブユーザーの成長をサポートする
• 特定のデータストアの問題がすべてのユーザーに影響しないようにする
• セルフマネージドのユースケースにおける複雑さを最小化または排除する

チームメンバー

以下の方々が Organizations グループの常任メンバーです:

チームメンバー情報は 原文 (英語) を参照してください。

安定したカウンターパート

以下の他の職能チームのメンバーが私たちの安定したカウンターパートです:

チームメンバー情報は 原文 (英語) を参照してください。

Organization ロールアウトカウンターパート

以下の方々が Organizations のロールアウトをサポートしています。

チームメンバー情報は 原文 (英語) を参照してください。

プロジェクト

私たちはそれぞれに直接責任者（DRI）が割り当てられた複数の大きなプロジェクトに取り組んでいます。 DRI の役割は、必要な作業の範囲を定義し、目標の明確さを確保し、潜在的なブロックやリスクを 3〜6 ヶ月先まで見通す責任を負います。その担当範囲に限定されず、必要に応じて他の領域でも作業します。

グループ & プロジェクト

Organizations

プロジェクトは 1 つまたは複数のエピックで構成される場合があります。 プロジェクトの一部である各エピックには、実装フェーズ中にエンジニアリングの DRI が割り当てられます。 進捗はチームのエピック進捗ダッシュボードで追跡しています。 エピックのステータスはさまざまなチームメンバーによって次のように更新されます:

1. チームメンバーがプロジェクトの新しいエピックを作成し、説明にエピックのゴールと利点を定義します。
2. デザインが必要な場合、プロダクトマネージャーはエピックを workflow::ready for design としてマークします。テーブルマイグレーションやパーティショニングなどのバックエンドのみの作業はこのステップを必要としません。
3. デザインが完了してエピックに追加されたら、必要に応じてエピックは実装 Issue に分解するために workflow::refinement としてマークされます。
4. すべての初期実装 Issue が定義されたとき、エンジニアは workflow::ready for development ラベルを追加します。
5. 最初の Issue の作業が始まる際にエピックのエンジニアリング DRI を割り当てます。この時点で、DRI はエピックのステータスを workflow::in dev に変更します。
6. 開発フェーズが開始した後に新しい Issue が作成される場合、バックログリファインメントプロセスを通じて対処する必要があります。
7. リファインメントスクリプトに拾い上げられるよう、リファインメントが必要な Issue に今後のマイルストーンが割り当てられていることを確認します。
8. エピックの最後の未解決 Issue がクローズされたら、週次グランドレビューでエピックをフラグ立てする必要があるかどうか検討します。フラグ立てが必要な場合は、次のグランドレビューでエピックをクローズすべきという旨を EM に通知するコメントをエピックに追加します。不要な場合はエピックをクローズします。

ミーティング

私たちはグローバルに分散したグループであり、主に非同期でコミュニケーションしていますが、同期ミーティングも実施しています。全員が参加できるとは限らないため、録画して文書化した要約（アジェンダ）を共有しています。

現在、以下の定期ミーティングが予定されています:

毎週水曜日 - Organizations チーム同期

プロダクトマネージャー（PM）がチーム、エンジニアリングマネージャー（EM）、その他のステークホルダーのインプットを受け、製品優先順位付けプロセスに従って Issue のリストをまとめます。 イテレーションサイクルは月の第 2 金曜日まで続き、翌月曜日から新しく始まります。 各マイルストーンはリリースされる GitLab のバージョンで識別されます。

マイルストーンプランニング

マイルストーン開始前に、グループはプランニング Issueを使用して調整します。 私たちは次のプロセスに従います:

• PM がマイルストーンのゴールを定義します。
• チームメンバーがマイルストーンに関連すると考える Issue についてコメントします。
• PM と EM が連携して最終的な Issue リストを決定します。
• チーム全体がマイルストーン開始前に予定されている項目をレビューします。

何に取り組むか

作業の主なソースはプランニングボードで、現在のサイクルで予定されているすべての Issue が一覧されています。 Issue に自分自身をアサインすることで、作業中であることを示します。

未回答の質問や不明確な要件など、Issue をすぐに始めることを妨げることがある場合は、Issue にあなたの調査結果と質問を記入する限り、スキップすることができます。 これにより、次にその Issue を担当するエンジニアが役立てることができます。

通常、Issue は直接誰かに割り当てられることはありません。ただし、ある Issue で最も知識やコンテキストを持つことが明らかな場合は除きます。 ただし、会社に大きなインパクトを与えるために、エンジニアが特定のプロジェクトやエピックの ownership を持つことを奨励しています。

製品ソリューションワークフロー

私たちは GitLab の製品開発ワークフローガイドラインに従っています。現在のマイルストーンにおけるすべての Issue のステータスの概要を把握するには、開発ワークフローボードを確認してください。

プロセスは主に次のとおりです:

• workflow::ready for design - Issue がデザイン作業を開始できる状態であることを示す
• workflow::design - デザイナーが Issue に積極的に取り組んでいることを示す
• workflow::planning breakdown - デザインが完了し、実装のためのサブ Issue に分解する準備ができていることを示す。デザインプロセス中のコンテキストと決定を保持するために、可能な限り、デザイン Issue をエピックに昇格させて再利用し、実装 Issue をそれに追加します。これにより、エピックをデザインのSSOTとして使用でき、すべての議論が一箇所にまとまり、元のデザイン Issue と対応する実装 Issue との間の不整合を防ぐことができます。
• workflow::refinement - Issue がエンジニアリングによるリファインメントを必要としていることを示す。このステップでは、実装ガイドとウェイトを Issue に追加する必要があります。
• workflow::ready for development - 項目がエンジニアリングによって作業できる状態であることを示す

開発ワークフロー

私たちは GitLab のエンジニアリングワークフローガイドラインに従っています。現在のマイルストーンにおけるすべての Issue のステータスの概要を把握するには、開発ワークフローボードを確認してください。

Issue の担当者として、エンジニアはワークフローラベルを最新の状態に保つことが期待されています。エンジニアが Issue の作業を開始するとき、起点として workflow::in dev ラベルをマークし、開発全体を通じて Issue を更新し続けます。 Issue をクローズする前に、workflow::complete ラベルを追加することが重要です。これは、完了した項目が各月のリリースポストの改善点とバグの概要に表示されるための要件の一つだからです。プロセスは主に次の図に従います:

graph LR

  classDef workflowLabel fill:#428BCA,color:#fff;

  A(workflow::in dev):::workflowLabel
  B(workflow::in review):::workflowLabel
  C(workflow::verification):::workflowLabel
  F(workflow::complete):::workflowLabel

  A -- Push an MR --> B
  B -- Merged --> C
  C --> D{Works on production?}
  D -- YES --> F
  F --> CLOSE
  D -- NO --> E[New MR]
  E --> A

独自の領域を超えたコードベースへの変更を含む新しい MR を作成する際は、CODEOWNERS などの自動化がトリガーしない場合でも、影響を受けるチームに積極的に連絡を取る必要があります。

• 変更内容が可視性のためだけの場合でも、変更を通知する適切な担当者を見つけるために追加の努力をする必要があります。
• ownership が不明な場合（CODEOWNERS などが owner を特定していないなど）、エンジニアはこれを明示的にフラグ立てし、関与できる DRI を特定する手助けを求めるべきです。
• 所有者が不明な場合は、次のアプローチを検討してください:
  • オープンなチームチャンネルで質問する
  • EM/PM にタグを付けて調査を依頼する
  • コードベースの履歴をレビューして最近のコントリビューターを特定する
  • 所有権情報の関連ドキュメントを確認する

エピックボード

以下のエピックボードで進行中のイニシアチブを追跡しています:

• Group::Organizations エピック進捗

Issue ボード

以下の Issue ボードで作業を追跡しています:

• Group::Organizations マイルストーン優先順位
• Group::Organizations 部門横断優先順位
• Group::Organizations プランニング
• Group::Organizations バリデーション
• Group::Organizations 開発ワークフロー
• Group::Organizations バグ
• Group::Organizations リリースポスト
• Group::Organizations マイルストーン
• Group::Organizations チームメンバー
• Group::Organizations 重要
• Group::Organizations コミュニティコントリビューション
• Groups and Projects サブチーム開発

トラッキングダッシュボード

Issue とエピックボードに加えて、次のような独自ダッシュボードで主要なイニシアチブの進捗も追跡しています:

• スキーママイグレーション
• シャーディングキーマイグレーション

ダッシュボードはCells Progress Trackerプロジェクトの一部です。 チームは、他のチームが独自のエピックベースのトラッキングダッシュボードを作成するために使用できるプロジェクトとしてEpic Dashboardsもスピンオフしました。

キャパシティプランニング

各マイルストーンで管理可能な量の作業を確保するために、シンプルな Issue ウェイトシステムをキャパシティプランニングに使用しています。Time Off by Deel を使用して、チームのスループットと各エンジニアの今後の可用性の両方を、Google Apps Scriptで考慮します。

ウェイトは集計で使用することを意図しており、ある人が特定の時間でできることは、その Issue に関する知識レベルによって他の人とは異なる場合があります。正確さを目指しますが、これらは見積もりであることを理解してください。正確でない場合や Issue が当初の予想より困難になった場合はウェイトを変更してください。ウェイトを変更した理由を示すコメントを残し、EM と PM にタグを付けて、スコープをより深く理解し継続的に改善できるようにしてください。

ウェイト

Issue のウェイトを評価する際は、次の重要な要素を考慮してください:

• 作業量: コードベースへの変更の予想規模。
• 複雑さ:
  • 問題の理解: どれだけ問題が理解されているか。
  • 問題解決の難しさ: 遭遇すると予想される困難のレベル。

開発作業を見積もる際は、適切なウェイトを Issue に割り当ててください:

ウェイト 5 以上のものは可能な限り分解する必要があります。

バックログリファインメント

エンジニアリングチームは毎週、今後の Issue をレビューするためのバックログリファインメントプロセスを実施しています。この作業の目的は、すべての Issue にウェイトを設定することで、各マイルストーンをより正確に計画し、知識共有を改善することです。

バックログリファインメントプロセスに加えて、エンジニアはこのバックログリファインメントプロセスに従わずに任意の Issue を見積もることができます。

ステップ 1: リファインメントが必要な Issue の特定

チームは workflow::refinement ラベルを使用して、リファインメントが必要な Issue を特定します。バックログリファインメントプロセスの良い候補（ウェイトなし、要件が不明確など）の Issue がある場合は、ラベルを使用してください。週に最大 5 件の Issue をリファインします。

リファインメント Issueは毎週初めに自動生成されます。 スクリプトはステージプロジェクトで調整できます。

ステップ 2: Issue のリファインメント

その週、チームの各エンジニアはバックログリファインメント用に選択された Issue のリストを確認します。現在のバックログリファインメント Issue。

各 Issue について、チームメンバーは次を確認して提供します:

• 見積もりウェイト
• 必要に応じた Issue の分解
• 実装ガイド

Issue をリファインする際は、次の点を考慮してください:

• コンテキストを保持するために会話を元の Issue に残すか、Issue 内の関連する議論へのリンクを提供する
• 情報が集まるにつれて Issue の説明、実装計画、ラベルを更新する
• 効率のために、完了としてマークされた既にリファインされた Issue のリファインメントをスキップできる
• 修正が明確で簡単な場合は、自分自身に Issue をアサインし、ウェイト 1 を付け、修正をプッシュして Issue をクローズできる

ステップ 3: リファインメントの最終化

エンジニアがインプットを提供する機会を持った後、EM または PM は次を行います:

• ウェイトを割り当てる
• 懸念事項がある場合は安定したカウンターパートに通知する
• workflow::refinement ラベルを削除する
• workflow::ready for development ラベルを追加する

議論されてウェイトが付与されなかった Issue については、PM や UX から詳細情報が必要かどうかエンジニアと協力します。

レトロスペクティブ

「マイルストーンごと」の定期的なレトロスペクティブを開催し、「プロジェクトごと」のアドホックなレトロスペクティブも開催できます。

マイルストーンごと

マイルストーンレトロスペクティブ Issue があります。 これには EM、PM、エンジニア、UX、そして全ての安定したカウンターパートが含まれます。 すべてのマイルストーンへの参加を強く推奨しています。詳細については、毎月 26 日に現在実行中のマイルストーンに対して作成されるグループレトロスペクティブを参照してください。

プロジェクトごと

Issue、機能、またはその他のプロジェクトが特に有益な学習体験になった場合、それから学ぶために同期または非同期のレトロスペクティブを開催することがあります。取り組んでいることでレトロスペクティブが必要だと思う場合:

1. Issue を作成して、なぜレトロスペクティブを開催したいのか、同期か非同期かを説明します。
2. EM と、PM やカウンターパートなど参加すべき全員を含めます。
3. 該当する場合は同期ミーティングを調整します。レトロスペクティブのすべてのフィードバックを将来の参照のために Issue に追加します。

エラーバジェット

GitLab は機能の可用性とパフォーマンスを測定するためにエラーバジェットを使用しています。各エンジニアリンググループには独自のバジェット消費があります。Tenant Scale グループの現在の 28 日間の消費は、このGrafana ダッシュボードで確認できます。

グループが長期的なスケーラビリティ作業に集中できるよう、99.85% のエラーバジェット例外が承認されました。

ダッシュボード

グループのメトリクスは、以下の Tableau ビューで確認できます:

• 主要なエンジニアリングメトリクス
• マージリクエストメトリクス
• フレーキーテスト Issue
• 低速 RSpec テスト Issue

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