Optimize グループ

Analytics:Optimize

Optimize FY26 の方向性と目標

働き方

• GitLab バリューに従います。
• 透明性を持って：ほぼすべてを公開し、可能な限りミーティングを録画・ライブストリーミングします。
• 取り組みたいことに取り組む機会を得ます。
• 誰もが貢献できる；サイロを作らない。
  • 目標は、プロダクトがエンジニアリングとデザインを最初から方向性と Issue の定義に関与させる機会を与えることです。
• グループのスタンドアップチャンネルで非同期の日次スタンドアップを行います:
  • #g-optimize-engineers-standup
• Slack でチームに連絡するには: #g_plan_optimize
  • すべての Optimize チームメンバーは、質問の性質に関わらず、チームの Slack チャンネルへのリクエストのトリアージと回答を奨励されています。

優先順位付け

私たちの優先順位はプロダクト全体のガイダンスに従うべきです。これはスケジュールされた Issue の優先度ラベルに反映されるべきです:

一般的なガイドラインとして、各リリースを次のように計画することを目指しています:

• バグ: 25%
• 機能: 50%
• メンテナンス: 25%

これらの目標は、レトロスペクティブで各リリース後に月次でレビューされます。

Optimize 機能全体のデータフローの SSoT

Contribution Analytics のデータフロー

グループ Contribution Analytics と グループ Value Stream Dashboard コントリビューションのデータフロー

flowchart TB
    subgraph User Actions
        user_actions["User Actions\n(MRs, Pushes, Issues, etc..)"]
    end

    subgraph Postgres
        events_table_pg["Events Table"]
    end

    subgraph ClickHouse
        events_table_ch["Events Table"]
        contributions_mv["Contributions\nMaterialized View"]
    end

    subgraph GraphQL
        contribution_analytics["ContributionAnalyticsContribution\n(Group Contribution Analytics)"]
        value_stream["ValueStreamDashboardCount"]
    end

    user_actions -->|EventCreateService| events_table_pg
    events_table_pg -->|EventSyncStrategy\nevery 3min| events_table_ch
    events_table_ch --> contributions_mv
    events_table_pg --> contribution_analytics
    contributions_mv --> contribution_analytics
    contributions_mv --> value_stream

AI Impact Analytics のデータフロー

グループ/プロジェクト AI Impact Analytics のデータフロー

flowchart TB
    subgraph Postgres
      ai_code_suggestion_events
    end
    subgraph ClickHouse
      code_suggestion_usages
      duo_chat_events
      duo_chat_daily_events_mv
      code_suggestion_daily_usages_mv
    end
    subgraph GraphQL
      aiMetrics
      aiUserMetrics
      aiUsageData
    end
    subgraph Redis
      Ai::UsageEventWriteBuffer
      ClickHouse::WriteBuffer
    end
    user_IDE-->|/usage_data/track_events|REST_API
    REST_API-->Ai::UsageEventWriteBuffer
    REST_API-->ClickHouse::WriteBuffer
    Ai::UsageEventWriteBuffer-->|sync every 5min|ai_code_suggestion_events
    ClickHouse::WriteBuffer-->|sync every 5min|code_suggestion_usages
    ClickHouse::WriteBuffer-->|sync every 5min|duo_chat_events
    duo_chat_events --> duo_chat_daily_events_mv
    code_suggestion_usages --> code_suggestion_daily_usages_mv
    ai_code_suggestion_events --> aiUsageData
    duo_chat_daily_events_mv --> aiMetrics
    code_suggestion_daily_usages_mv --> aiMetrics
    code_suggestion_daily_usages_mv --> aiUserMetrics

作業の整理

私たちは一般的に Product Development Flow に従います:

1. workflow::problem validation - 解決すべき問題が明確でない
2. workflow::design - 明確な提案が必要（視覚的側面のモックアップも）
3. workflow::solution validation - エンジニアリングからの改善と承認が必要
4. workflow::planning breakdown - ウェイトの見積もりが必要
5. workflow::scheduling - マイルストーンの割り当てが必要
6. workflow::ready for development
7. workflow::in dev
8. workflow::in review
9. workflow::verification - コードは本番環境にあり、DRI エンジニアによる検証を保留中
10. workflow::complete - コードが検証され作業が完了しており、Issue はクローズされるべき

一般的に、Issue は 2つの状態のどちらかにあります:

• 発見/改善: 開発を開始できない質問にまだ答えている段階、
• 実装: Issue がエンジニアの対応を待っているか、または積極的に構築されている段階。

Basecamp はこれらの段階を丘の登りと降りとして考えています。

個々のグループは Product Development Flow ワークフロー内で有用と思われる多くのステージを自由に使用できますが、Issue が発見/改善から実装に移行する方法についてはある程度規定的であるべきです。

チームの成果物の価値測定

顧客への価値フローを視覚化するため、計画から本番までの時間を測定するために Value Stream Analytics をドッグフーディングしています。

バックログ管理

バックログ管理は非常に困難ですが、ラベルとマイルストーンを使用してそれを実施しようとしています。

改善

最終目標が定義されており、すべての直接関係者が「はい、これは開発に向けて準備ができている」と言う状態です。Issue によっては素早く到達できるものもあれば、数回のやり取りが必要なものもあります。

目標は、エンジニアがロードマップに関与感を持つことです。エンジニアリングをより早い段階から含めることで、プロセスははるかに自然でスムーズになります。

そのため、エンジニアリングマネージャー、エンジニア、デザイナーは Issue から直接 ping を受けることができます。現在、グループメンバーにより簡単に ping できるようにするために Manage プロジェクトをグループに変換することを検討しています。

改善が必要な Issue を見つけるには、Next Up ラベルとその目的を参照してください。

Next Up

• 改善が必要な Issue を特定するには、“Next Up” ラベルを使用します。
  • “Next Up” ラベルの目的は、workflow::ready for development より前の_任意の_ワークフローステージにある Issue を特定することです。このワークフローラベルに加えて “Next Up” ラベルを使用することで、改善中のもの（例：問題、デザイン、ソリューション）を正確に確認できます。これにより、スケジュールに向けてどの Issue が準備に近づいているかを特定できます。
• Issue は、プロダクトとエンジニアリングの両方から 👍 を受けるまで、特定のリリース（例：13.0）のマイルストーンを受け取るべきではありません。これはまた、Issue に workflow::ready for development のラベルを付けるべきではないことも意味します。
  • プロダクトの承認は、Issue が workflow::planning breakdown に移行することで表されます。
  • エンジニアリングの承認は、その複雑さを測定する Issue ウェイトで表されます。

Issue の分解またはプロモーション

Issue の複雑さに応じて、Issue を分解またはプロモートする必要がある場合があります。いくつかのサンプルシナリオを示します:

• 他のことを行う前に、デザインの発見を行う必要があります。“Discovery:” Issue は、デザインの思考と議論をそこに含め、最終結果を “Implementation:” Issue に引き渡すのに最適です。これらのプレフィックスは、親 Issue やエピックにリンクされている場合に Issue の種類を整理するのにも役立ちます。
• 作業のスコープが予想より大きく、さらに分解する必要があります（例：現在のウェイトが 5 を超えている）。その Issue をエピックにプロモートし、提案された機能全体を提供するために必要な異なるイテレーションまたはフェーズを列挙するより小さな Issue に分解することが適切かもしれません。
• 作業のスコープは明確ですが、1つの Issue では少し扱いにくいです。すべての人に会話とアクティビティを見えるようにするために現在の Issue をそのまま保持しつつ、特定の Issue のより細かい進捗を追跡するために別の子デザイン、バックエンド、またはフロントエンド Issue を作成することが意味をなす場合があります。

上記のいずれも該当しない場合、Issue はおそらく現状のままで問題ありません！その場合、この Issue のウェイトはおそらく低く（例：1〜2）なっています。

Issue における議論、情報、決定、アクションアイテムの管理

Issue の分解またはプロモーションの一部として、特定の Issue には大量のスレッドやコメントがあることに気づくかもしれません。

Issue に参加するすべての関係者にとって、提案の詳細、保留中のアクションアイテム、決定が容易に見えるようにすることは非常に重要です。したがって、Issue の説明を最新の状態に保つか、上記のセクションに従って分解またはプロモートすることが最優先事項です。

見積もり

Issue の作業を開始する前に、予備調査の後に見積もりを行うべきです。

特定の Issue の作業範囲が複数の分野（ドキュメント、デザイン、フロントエンド、バックエンドなど）に及び、それらにわたる大きな複雑さがある場合は、各分野の別々の Issue を作成することを検討してください（例参照）。

ウェイトのない Issue には “workflow::planning breakdown” ラベルを割り当てるべきです。

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

見積もりの一部として、エンジニアが取り組み始めるのに適切な状態だと感じる場合は、“workflow::ready for development” ラベルを追加してください。あるいは、まだ定義すべき要件や回答すべき質問があってエンジニアが容易に解決できないと感じる場合は、“workflow::blocked” ラベルを追加してください。workflow::blocked ラベルの Issue は計画ボードの独自の列に表示され、さらなる注意が必要であることが明確になります。workflow::blocked ラベルを適用する場合は、コメントを残し、ブロックされた Issue の DRI と担当者を ping して/ブロッキング Issue をリンクして可視性を高めてください。

実装アプローチ

エンジニアは、Issue を ~workflow::planning breakdown から移動させる際に実装アプローチを作成することができます。提案された実装アプローチは必ずしも従う必要はありませんが、記録されたウェイトを正当化するのに役立ちます。

workflow::planning breakdown の DRI として、監視の終わりと Issue がスケジューリングに移行する準備ができていることを示すために以下の例に従うことを検討してください。すでに分解されているより簡単な Issue はより短い形式を使用するかもしれませんが、計画は少なくとも常に見積もりの背後にある「なぜ」を正当化するべきです。

以下は https://gitlab.com/gitlab-org/gitlab/-/issues/247900#implementation-plan からの実装アプローチの例です。これは Issue を作業の各部分のより小さな Sub-Issue に分解すべき可能性が高いことを示しています:

### Implementation approach

~database

1. Add new `merge_requests_author_approval` column to `namespace_settings` table (The final table is TBD)

~"feature flag"

1. Create new `group_merge_request_approvers_rules` flag for everything to live behind

~backend

1. Add new field to `ee/app/services/ee/groups/update_service.rb:117`
1. Update `ee/app/services/ee/namespace_settings/update_service.rb` to support more than just one setting
1. *(if feature flag enabled)* Update the `Projects::CreateService` and `Groups::CreateService` to update newly created projects and sub-groups with the main groups setting
1. *(if feature flag enabled)* Update the Groups API to show the settings value
1. Tests tests and more tests :muscle:
1. Create a seed script to generate data

~frontend

1. *(if feature flag enabled)* Add new `Merge request approvals` section to Groups general settings
1. Create new Vue app to render the contents of the section
1. Create new setting and submission process to save the value
1. Tests tests and more tests :muscle:
1. Update storybook stories for new and existing components

DRI が Issue を workflow::scheduling に移動させる前に、Issue が複数の分野（例：バックエンドとフロントエンド）にまたがる場合は、関連するカウンターパートまたはドメインエキスパートに ping することを強く推奨します。これにより、ドメインエキスパートが実装計画を承認したり、作業開始前に潜在的な落とし穴や懸念点を挙げる機会が得られます。

Issue が見積もられると、マイルストーンが割り当てられる workflow::scheduling に移動でき、最終的に workflow::ready for development になります。

計画

私たちは製品開発タイムラインに従い月次サイクルで計画します。このタイムラインを守ることは個々のグループの裁量に委ねられています。典型的な Optimize の計画サイクルは次のようになります:

• 4日までに、プロダクトは次のリリースのために Optimize Group Admin プロジェクトにグループの計画 Issue を作成します。
  • この Issue には、リリースの暫定的な計画と、マイルストーンの提案作業を示すボードへのリンクを含める必要があります。
  • Next 1 - 3 releases マイルストーンでフィルタリングされたボードは、今後の Issue を把握するために使用されます。
  • ステージ戦略にとって特に重要な Issue は direction でマークされるべきです。
• 12日までに、次のリリースのために提案されたすべての Issue はエンジニアリングによってウェイトが割り当てられ（workflow::ready for development）見積もられるべきです。
  • キャパシティプランニングを支援するため、エンジニア 1人あたりのキャパシティを 10 ウェイトから始め、休暇、チームデー、オンコールスケジュール、その他の活動に基づいて削減します。EM は計画 Issue で予想されるキャパシティを記録します。
  • 前のリリースからスリップすることが判明している Issue は、残りの作業のために再ウェイト付けされ、次のリリースに再スケジュールされるべきです。
• 15日までに、プロダクトとエンジニアリングは Next 1 - 3 releases ボードの Issue リストを並べ替えます。
  • 利用可能かどうかに応じて、プロダクトまたはエンジニアリングがキャパシティを考慮し、各タイプカテゴリのトップ Issue を次のリリースに割り当てます。
  • エンジニアリングマネージャーは、コミットされた作業に ~Deliverable ラベルを割り当てます。
  • 計画プロセス全体は非同期で行われますが、プロダクトとエンジニアリングが追加の協力を必要とする場合、最終リリーススコープをレビューするための同期ミーティングはオプションです。

Deliverable と Stretch の Issue

Deliverable ラベルが付いた Issue は現在のマイルストーンにスケジュールされています。これらは最優先事項と見なされ、リリース時に完了することが期待されます。

Stretch ラベルが付いた Issue は、現在のマイルストーンでの提供のストレッチ目標です。これらの Issue が現在のリリースで完了しない場合、次のリリースで強く検討されます。

コミュニティコントリビューション

以前に合意され Community contribution のラベルが付けられた Issue は、以下のものが揃っているかどうかを確認するためにトリアージされるべきです:

• 明確な実装計画。
• 適切なウェイト見積もり。
• Seeking community contributors ラベルが割り当てられている。

トリアージが完了したら、Issue は backlog に追加して未割り当てのままにできます。Issue を割り当てることは、担当者が積極的にその Issue に取り組んでいることを示しますが、コミュニティメンバーが持つコードベースへの親しみやすさのレベルや時間的制約を考えると、MR が進行中になってから Issue を割り当てるのが最善です。

Issue をより早く処理する必要が明確な場合は、適切な優先度ラベルを割り当てて optimize チームメンバーが計画できるよう、マイルストーンに Issue をスケジュールすることを検討してください。

コミュニティメンバーが Issue を引き受けることに興味を示した場合、関連する Optimize チームメンバーは Issue の説明と実装計画が正確で最新の決定を反映していること、すべてのラベルが最新であることを確認し、コントリビューターが追加の支援を必要としているか続けることができなくなった場合に備えて進捗を監視すべきです。

セルフアサインメント

計画中、EM は意味があると感じた場合に個々のエンジニアに Issue を割り当てる場合がありますが、一般的に Issue は未割り当てのままにして、計画が確定したらエンジニアが自ら割り当てることができるようにします。

役割別の期待:

• EM: 計画 Issue が確定したらエンジニアに ping する。
• エンジニア: リリース開始前に Issue をセルフアサインする。
• EM: 週次チームコールで未割り当ての Issue を強調する。

リリース中

• キックオフ後にリリースに Issue が追加される場合、未計画の作業を考慮するために同量のウェイトを削除する必要があります。
• Issue が見積もられてウェイトが付けられる前に開発を開始すべきではありません。
• 15日までに、エンジニアリングのマージリクエストはマージされるべきです。言い換えると、15日以降にマージされたコードはリリースに含まれないと想定します。これにより、リリースを確定し、関連するリリースポストを 17日までにマージする時間が確保されます。（これは 13.11 から始まる実験です。）

リリースポスト

より詳細に発表する必要がある Issue については、Issue を使用してリリースポストを自動的に作成できます。 Issue の計画中、またはデザインや開発中に、 リリースポストアイテムジェネレーターを使用して、リリースポストを作成し、関連するすべての人に通知することができます。

Issue にリリースポストが必要ない場合は、Issue にリリースノートセクションがないこと、または release post item:: ラベルを使用していることを確認してください。

概念実証 MR

私たちはイテレーションと小さな単位で価値を提供することを強く信じています。イテレーションは難しい場合があります。特にプロダクトのコンテキストが不足していたり、コードベースの特にリスクが高く/複雑な部分で作業している場合はそうです。Issue を見積もるのが難しかったり、実現可能かどうか判断できない場合は、最初に概念実証 MR を作成することが適切かもしれません。概念実証 MR の目標は、計画中の主要な仮定を排除し、初期フィードバックを提供することで、将来の実装のリスクを軽減することです。

• PoC: というプレフィックスを付けた MR を作成します。
• MR の説明で PoC MR が解決しようとしている問題を説明します。
• タイムボックスを設定します。2〜3日以内に実現可能性または計画を決定できますか？
• この期間の終わりにフィードバックを提供するレビュアーを特定します。
• MR をクローズします。PoC から学んだこと（プロダクトとパフォーマンスへの影響を含む）の要約を元の Issue で提供します。
  • 実装を進めることができるかどうかを述べます。
  • Issue はクローズしないでください。

概念実証 MR の必要性は、コードベースやプロダクトの一部が過度に複雑になっているサインである可能性があります。将来この手順を回避する方法について議論できるよう、レトロスペクティブの一部として MR を必ず議論してください。

Issue トリアージ

私たちは一般的にIssue トリアージガイドラインに従います。

役割別の期待:

• PM は type::feature の DRI
• EM は type::bug の DRI
• UX は UX、Deferred UX、SUS の Issue の重大度ラベルに関する決定をサポートします
  • UX の重大度と PM/EM の重大度が異なる場合、二者のうちより高い重大度を採用します。
• エンジニアの参加を奨励します

週次で、できるだけ多くの Issue をトリアージすることを目指します。トリアージが必要な Issue に完全なトリアージを実行するよう努めます。

スケジュールされていない Issue への取り組み

GitLab の全員は、結果を測定し時間を測定しないため、自分の裁量で作業を管理する自由があります。その一部として、定期的な月次リリースの一部としてスケジュールされていないアイテムに取り組む機会があります。これはハンドブックの他の場所にある内容の繰り返しが多く、それらを明示するためにここに記載しています:

1. 私たちは人々が自分自身のマネージャーであることを期待し、自分たち自身で GitLab を使用します。重要だと思うことを見つけた場合、スケジューリングを要求したり、自分で提案に取り組むことができます。ただし、他の優先事項を念頭に置いてください。
2. 時々、issue bash などの GitLab チームメンバーが参加できるイベントがあります。誰でも参加できます。

何か取り組むものを選ぶ際は:

1. 標準的なワークフローに従い、自分に割り当てます。
2. 透明性を促進するために #g_plan_optimize で共有します。

その他の考慮事項

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

計画中、各マイルストーンで成果物の作業にチームのキャパシティの 100% を計画しません。代わりに、調査とスコープ作業のためにより多くの時間を確保するために、チームメンバー 1人あたり 15% のバッファを確保します。

ドキュメント

ドキュメントは完了の定義の重要な部分です。テクニカルライティングが必要な変更については、documentation ラベルを追加します。documentation ラベルはバックエンド/フロントエンドラベルに加えて使用されるべきです。機能が別々のバックエンドとフロントエンドの Issue を正当化する場合、applicable であれば documentation ラベルをそれぞれの Issue に適用すべきです。Issue は、技術的な部分とドキュメントの変更の両方がマージされた場合にのみ解決されます。

データシードスクリプト

Optimize のスコープ内の機能は、機能を確認して開発中にテストするために適切なデータが必要です。データシードスクリプトは開発プロセスの一部として作成/更新されるべきです。

データシードスクリプトの考慮事項:

• 関連する場合にグループまたはプロジェクト ID を指定できるようスクリプトをパラメーター化する
• スクリプトが失敗せずに繰り返し実行できるようにする

フィーチャーフラグ

私たちは、顧客にエンタープライズレベルのユーザーエクスペリエンスを提供するために必要に応じてフィーチャーフラグを使用します。不必要なフィーチャーフラグを避け、導入時にその目的が明確で、ロールアウトの依存関係とタイムラインが更新され続けることを確保します。可能な限り長期的なフィーチャーフラグを最小化し、変更を伝達するよう努めます。

私たちが所有するフィーチャーフラグに関連する以下の役割と責任があります:

• DRI の割り当て
  • フィーチャーフラグを導入する作者がそのフィーチャーフラグのロールアウトの DRI です。
• 監査とクリーンアップ
  • EM はステージ内で所有するフィーチャーフラグの監査の DRI であり、フィーチャーフラグ DRI と協力してクリーンアップをスケジュールします。
• プロセス改善
  • 誰もがプロセス改善に貢献することが奨励されます。

ミーティング

非同期コミュニケーションに傾倒していますが、同期ミーティングは必要であり、コミュニケーションガイドラインに従うべきです。Manage で定期的に行われるミーティングの一部を以下に示します:

一度限りのトピック固有のミーティングについては、常にこれらのコールを録画して共有することを検討してください（または公開されているドキュメントにメモを取ります）。

アジェンダドキュメントと録画は、唯一の情報源として共有 Google ドライブ（内部のみ）に保存できます。

1対1や機密トピックをカバーするもの以外のミーティングは、Manage 共有カレンダーに追加されるべきです。

すべてのミーティングは、少なくとも 12時間前にアジェンダを準備する必要があります。そうでない場合は、ミーティングへの出席は義務付けられません。ミーティング開始時点でアジェンダがない場合は、ミーティングはキャンセルされたとみなします。

グループメンバー

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

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

リンクとリソース

• マイルストーンレトロスペクティブ
• Slack チャンネル
  • Plan:Optimize #g_plan_optimize
  • 日次スタンドアップ #g-optimize-engineers-standup
• Issue ボード
  • Optimize build ボード と refinement ボード
• Optimize グループの計画とビジョンについての詳細はグループページを参照してください。

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