Content last updated 2026-05-22

プロダクト手順

概要

ハンドブックのこのセクションは、特定の条件下で従う必要があるプロセスのコレクションです。例えば、変更が行われる場合、または承認のためにリーダーシップに要求が提出される場合などです。

このページの仕組み

「誰もが共創できる」精神に則り、これらの手順はプロダクト部門の誰でも（さらには GitLab の誰でも！）貢献できます。手順のカストディアンはプログラムマネジメントです。このページに貢献することに興味がある場合は、マージリクエストを開き、Natalie Pinto（GitLab ハンドル @natalie.pinto）にアサインしてください。

手順

ステージ、グループ、カテゴリへの変更

ステージ、グループ、カテゴリへの変更方法、および必要な承認に関するドキュメントは、当社の ウェブサイトハンドブックページ にあります。

GitLab が成長するにつれて、新しいグループ、ステージ、カテゴリを作成する必要があります。この移行期間中は、グローバルに最適化する 必要があり、新しいグループの作成中に重要な Issue がブロックされないようにする必要があります。

これらの移行期間に遭遇する可能性のある一般的なシナリオは 3 つあります:

  • ステージを複数のグループに分割する
  • ステージ内のカテゴリを変更する
  • 新しいステージを追加する
  • 新しいグループを作成する
  • 既存のカテゴリを別のグループに移動する

上記の各シナリオでは、グループが将来のグループの Issue とバックログの責任を一時的に負う可能性があります。この間、責任あるグループは、ユーザーと組織のニーズのバランスをとり、共通のバックログ全体で優先順位を付ける必要があります。

上記のすべてのシナリオでは、新しいラベルを正しく追跡するために Engineering Metrics ダッシュボードを更新する必要もあります。 ラベルの変更は Issue とマージリクエストの両方に影響します。ステージとグループのラベルは、Quality と GitLab Insights ダッシュボードの可視化と指標を駆動します。 Triage Ops で label-change.md テンプレートを使って新しい Issue を作成してください。

新しいグループの作成

ステージで作業するグループが規模を拡大するにつれて、グループのサイズを管理可能なままに保つために新しいグループを形成する必要があるかもしれません。例えば、現在 Manage には単一のグループがありますが、control と framework の新しいグループが作成されました。

複数のグループの作成を準備するには、次のことを行うべきです:

  1. categories.yml と stages.yml を更新し、各グループにカテゴリのセットを割り当てる
  2. すべての Issue がステージ名（例: devops::manage）でラベル付けされ続けることを確認する
  3. すべての Issue にグループラベル（例: Control や Framework）もあることを確認する
  4. 新しいグループが形成される前に、PM と EM が共有された devops::manage バックログに優先順位を付ける

最初の PM または EM が雇用されたら、新しいグループを形成すべきです:

  1. 他の PM/EM は両方のグループを横断して作業を続ける必要があります。例えば、バックエンド EM が雇用された場合、フロントエンド EM と PM は追加の雇用が行われるまで両方のグループを横断して作業を続けます。
  2. EM とエンジニアは協力して、既存のエンジニアリングチームを Control と Framework などの新しいグループに配属するよう分割すべきです。理想的には、各グループに少なくとも 2 人のバックエンドエンジニアがいるべきですが、それが常に可能とは限りません。
  3. 新しいグループメンバーを反映するように stages.yml と team.yml を更新します。_categories.erb の末尾にメンバーを追加する必要があるかもしれません。
  4. 各グループ用の Slack チャンネル（例: #g_control と #g_framework）を作成し、以前の Slack チャンネル（例: #g_manage）を閉じます。

残りの EM/PM が雇用されると、彼らはそれぞれのグループでその役割を引き継ぎます。

注: 以前はこれをグループを「分割する」と呼んでいました。しかし、グループメンバーに対して、彼らが新しい独立したグループを形成しており、独立して新しい規範とプロセスを自由に作成すべきであることを強調することが重要なため、調整しました。

ステージを複数のグループに分割する

ステージで作業するグループが規模を拡大するにつれて、グループのサイズを管理可能なままに保つために新しいグループを形成する必要があるかもしれません。例えば、現在 Manage には単一のグループがありますが、control と framework グループに分割されます。

ステージを複数のグループに分割する準備をするには、次のことを行うべきです:

  1. categories.yml と stages.yml を更新し、各グループにカテゴリのセットを割り当てる
  2. すべての Issue がステージ名（例: devops::manage）でラベル付けされ続けることを確認する
  3. すべての Issue にグループラベル（例: Control や Framework）もあることを確認する
  4. Triage Ops で「Label change」Issue を作成し、エンジニアリングダッシュボードに変更が遡及的に反映されるよう影響を受けるラベルをリストアップする。
  5. 新しいグループが形成される前に、PM と EM が共有された devops::manage バックログに優先順位を付ける

最初の PM または EM が雇用されたら、新しいグループを形成すべきです:

  1. 他の PM/EM は両方のグループを横断して作業を続ける必要があります。例えば、バックエンド EM が雇用された場合、フロントエンド EM と PM は追加の雇用が行われるまで両方のグループを横断して作業を続けます。
  2. EM とエンジニアは協力して、既存のエンジニアリングチームを Control と Framework などの新しいグループに配属するよう分割すべきです。理想的には、各グループに少なくとも 2 人のバックエンドエンジニアがいるべきですが、それが常に可能とは限りません。
  3. 現在のグループメンバーを反映するように stages.yml と team.yml を更新します。必要に応じて _categories.erb をメンバー名で更新します。
  4. 各グループ用の Slack チャンネル（例: g_control と g_framework）を作成し、以前の Slack チャンネル（例: g_manage）を閉じます。

残りの EM/PM が雇用されると、彼らはそれぞれのグループでその役割を引き継ぎます。

ステージへの新しいカテゴリの追加

ステージ内のカテゴリは、GitLab の方向性と市場状況に基づいて、時間とともに変わります。ステージ内のグループは、Issue が抜け落ちることなく、これらの変更を扱えるようにする必要があります。

カテゴリが変わるとき、次のことを行うべきです:

  1. categories.yml と stages.yml を更新し、すべてのカテゴリがグループに割り当てられていることを確認する
  2. 2 つのカテゴリがマージされる場合、両方の古いカテゴリの Issue に新しいカテゴリラベルを適用する
  3. 新しいカテゴリが追加される場合、新しいカテゴリラベルを作成し、関連する Issue に適用する
  4. Triage Ops で「Label change」Issue を作成し、エンジニアリングダッシュボードに変更が遡及的に反映されるよう影響を受けるラベルをリストアップする。
  5. 新しいラベルとカテゴリを反映するためにカテゴリ戦略を更新する
  6. 古いカテゴリにリンクされている可能性のあるハンドブックや他の資料をレビューする
  7. 古いカテゴリラベルをアーカイブする。これは「Label change」Issue の一環として Developer Experience チームによって行われます。

新しいステージの追加

GitLab がシングルアプリケーション内で追加のニーズに対応することを決定したとき、新しいステージを作成する必要があるかもしれません。例えば、Secure が焦点を当てるものを超えた追加のニーズに対応するため、Software Supply Chain Security が作成される可能性があります。

新しいステージが追加され、そのグループがまだ形成されていないとき、次のことを行うべきです:

  1. 新しいステージのすべての Issue がステージラベル（例: devops::software-supply-chain-security と Software Supply Chain Security）でアサインされていることを確認する。
  2. Triage Ops で「Label change」Issue を作成し、エンジニアリングダッシュボードに変更が遡及的に反映されるよう影響を受けるラベルをリストアップする。
  3. 新しいステージに当初責任を持つ既存のグループ（例: Secure）を特定する
  4. 既存のグループは両方のステージの共通バックログ全体で優先順位を付けます。この例では devops::software-supply-chain-security と devops::secure です
  5. categories.yml と stages.yml を更新し、既存の責任あるグループのメンバーとともに新しいステージをリストする。必要に応じて _categories.erb をメンバー名で更新します。

最初の PM または EM が雇用されたら、ステージのための新しいグループを形成すべきです:

  1. 他の PM/EM は両方のグループを横断して作業を続ける必要があります。例えば、バックエンド EM が雇用された場合、フロントエンド EM と PM は追加の雇用が行われるまで両方のグループを横断して作業を続けます。
  2. EM とエンジニアは協力して、govern などの新しいグループに配属する必要があります。各グループには少なくとも 2 人のバックエンドエンジニアがいるべきです。
  3. 新しいグループが形成されたので、両方のグループはそれぞれのステージに焦点を当てることができます。この場合、Secure は Secure に、Software Supply Chain Security は Software Supply Chain Security に焦点を当てます。
  4. 新しいグループとそのメンバーを反映するように stages.yml を更新します。必要に応じて _categories.erb をメンバー名で更新します。

残りの EM/PM が雇用されると、彼らは新しいグループでその役割を引き継ぎます。

ステージ間の安定したカウンターパートの移動

時に、安定したカウンターパート をあるチームから別のチームに移転する必要があることがあります。このチームメンバーの以前の役割が補充される場合は、部門間の異動プロセス に従ってください。役割が補充されない場合（つまり、役割がチームから別のチームにシフトされた場合）、関連するステージのリーダーが情報を得て、チームメンバーの割り当ての変更を通じてチームをガイドできるよう、次のステップを実行する必要があります:

  1. プライベートプロジェクトまたは 制限アクセス の Google ドキュメントで、次の チーム再編成 Issue テンプレート を使って Issue を作成します。これは再配分の目的を述べ、影響を受けるチーム、影響を受けるリーダー、および組織の残りに通知するコミュニケーションプランの定義を助けます。カバーする主な詳細:
  2. 誰、何、なぜ をリストアップする
  3. チーム変更に関連するアクションアイテムの DRI を特定する
  4. コミュニケーションタイムラインの一部として実行する透明なコミュニケーションプランを定義し、タスクを割り当てる
  5. Issue を再編成の DRI またはタスクを持つ人々に割り当てる
  6. Issue がリーダーシップから承認を得て、影響を受ける関係者がチームメンバーの再配分について認識したら、当社の 透明性 価値観に従って、Issue を公開リポジトリ（Product、www-gitlab-com、またはチームに特化したプロジェクトなど）に移動し、これらの変更をすべてのチームメンバーに対して透明にします。

プロダクトマネージャーが別のプロダクトマネージャーから既存のカテゴリを引き継ぐとき

カテゴリが適切なグループ、ステージ、セクションの一部として反映されるために上記の適切な変更を行うことに加え、次のステップも重要です。

  1. ハンドオフを行う PM は、テンプレート を使って変更のプロセスを詳述する Issue を準備します。
  2. カテゴリを受け取る PM は方向性ページのレビューを開始し、受け取るチームの EM とデザイナーにもページのレビューを依頼します。これにより、チームはすぐに基本的な理解を得ることができます。
  3. PM たちは一緒に DRI を特定し、誰がコミュニケーションを所有するかを明確にします（カテゴリを理解するための質問は、quad チームの他のメンバーではなく PM に行くことが望ましいです。これにより、quad チームの他のメンバーは新しい責務に集中できます）。
  4. より広範な配布のために録画を作成する

Rapid Action

注: Rapid Action プロセスは、エンジニアリング部門全体のさまざまなステークホルダーからの即時の注意を必要とする重要な状況のための Strategic Priority Codes フレームワークに置き換えられました。

Borrow

Borrow は、チームメンバーがあるチームから別のチームに一時的にシフトされるときに使用されます。チームメンバーは作業が完了したらアサインを完了します。Borrow は、取り組みの調整とロジスティクスのために管理構造を単一のグループに整合させることを目的としています。作業を事前に定義し、境界を設けることが重要です。私たちは Borrow をマイルストーン単位にすることを好みますが、一般的に複数のマイルストーンに拡張できます。3 か月を超える Borrow は、スコープを注意深くレビューし、可能な限り最小化すべきです。依頼が 6 か月を超える可能性が高い場合は、通常、代わりに再編成を使用すべきです。

quad のカウンターパートが Borrow を満たすために最初に自分で整合を求めることができることをお勧めします。例として、quad リーダーシップが最も重要なビジネス優先順位ですでに整合しているステージでは、より低いレベルで整合し、決定をドキュメント化するために 軽量版の Borrow テンプレート を使うことで、迅速に動くことができます。この例は、複数のグループが自分自身で整合できる場合、または複数のステークホルダー（例: 異なるレポート構造）が必要だが合意されている場合に、製品グループレベルでも意味があるかもしれません。このテンプレートは、割り当てられたグループ外の作業を引き受ける個々のチームメンバーにも使用できます。効率のため、可能な限りこのアプローチが優先されるべきです。

これが不可能な場合、またはより広範なサポートのため（例: あなたの領域の外を遠く見渡す場合）、EM、PM、Product Design Manager は Borrow リクエストのために この Issue テンプレート を活用します。このテンプレートに従うことで、プロセスが効率的で、よく整理され、適切な承認を受けることができます。Borrow されるグループ／個人の特定は、プライベートな Google ドキュメントまたは制限アクセスプロジェクトで行うべきです。Borrow リクエストが承認されたら、変更をより広く伝えるために、影響を受けるグループ／チームに関する詳細を Issue に追加すべきです。

すべての Borrow には、具体的な成果物のコミットメントが記述されている必要があります。意図は期待を設定し、チームメンバーに期待を明確に理解する機会を提供することです。選択されたチームメンバーの好みは考慮され、これを提供することは、必要なスキルを持つ他の関心のあるチームメンバーが関与する機会にもなります。

特殊分野が必要なとき

アーキテクチャ的および／または重要な技術プロジェクトを実施する必要がある場合、目標を達成するために特定のスキルセットを持つチームメンバーが必要かもしれません。これらの例では、明確な目標、明確に定義されたスキルセット、必要なチームメンバーの数を持つように努めるべきです。

緊急性が必要なシナリオでは、特定のチームメンバーを選択する必要があるかもしれません。これがチームメンバー、チーム、より広い組織に与える影響にも対処すべきです。望ましいスキルを持つすべてのチームメンバーが、機会が平等に利用可能であることを確保するために考慮に含まれるべきです。一方で、影響を受けるチームが合理的に運用できるよう（例: 提供するチームには少なくとも 3 人のエンジニアが残るべきで、最大 1 人のエンジニアまでしか提供できない）、可能な限り連鎖的な影響を避けるようにしてください。

Borrow リクエストが適切でないとき

Borrow リクエストが適切でない状況がいくつかあることを学びました:

  • Borrow リクエストは、他のスケジュールされた作業がすでに行われているときに、sustaining または forced-prioritization アクティビティを完了するためにスコープすべきではありません。Sustaining と forced-prioritization の Issue は、製品グループの必要なアクティビティです。その結果、Borrow リクエストは必要な作業を追加で完了する決定としてフレーミングされるべきです。例えば、Borrow リクエストは、製品グループが機能に取り組んでいる間に security または infradev の Issue を解決するために活用すべきではありません。

成功する Borrow リクエストの方法

Borrow をフレーミングする方法で、より建設的な会話につながる方法を学びました:

  • Borrow リクエストは、特定のグループに対して最も 優先順位の低い作業 にスコープすべきです。これは直感に反しますが、他のチームの取り組みと比較したときに、トレードオフを公平に評価できるよう、最も弱い作業を主張すべきです。ここでの理由は、チーム内のチームメンバーをより高い優先順位の作業に移動できる場合、それが Borrow する最初の場所だからです。
  • Borrow リクエストは OKR を提供するために開始されるべきではありませんが、Borrow リクエストを提案するビジネスニーズを伝える際に OKR を参照できます。Borrow リクエストは優先順位付けされた作業の観点でフレーミングされるべきです。セキュリティ Issue の修正のための OKR ゴールは、現在の作業に基づいて優先度 1 として分類されます。

アクティブな Borrow リクエスト

この ボード には、提案されたすべての Borrow リクエストとアクティブな Borrow リクエストが含まれています。

スコープの再割り当て

スコープの再割り当ては、作業の機能または労力が 6 か月以上 1 年未満かかるが、作業を提供するために永続的にチームを再編成する必要がない場合に使用されます。代わりに、チームのレポート構造は維持され、製品グループは別のグループ、ステージ、またはセクションの製品スコープに取り組むよう指示されます。

スコープの再割り当てでは、製品グループがスコープのどの部分を各グループが提供するかについて整合することをお勧めします。これは、エピックと Issue、および group:: ラベルで行います。

スコープの再割り当て、Borrow、再編成はどう違うか？

スコープの再割り当ては、チーム構造が変わらず、代わりに製品グループが取り組む項目が変わるという点で、Borrow と再編成と異なります。さらに、Borrow は一時的に（6 か月未満）使用され、再編成は永続的です。スコープの再割り当ての場合、製品グループは長期的なチャーターとビジョン／投資レベルを維持しますが、最大 1 年間は別の製品領域のスコープで作業します。スコープの再割り当ての理由は、より多くのヘッドカウントを必要とする戦略的な取り組みを実行しながら、マネージャーとチーム構造の変更のトイルを減らすことです。

GitLab.com アプリ内メッセージ（Broadcast Messaging）

Broadcast Messaging は、製品内からユーザーフィードバックを取得するための優れたツールです。このツールは、一般的な、1 回限りの、重要な発表や、製品内の特定のワークフローとの対話中または対話後にユーザーを募集するためのものです。現在、Broadcast Messaging は URL でターゲット でき、メッセージとレスポンスをパーソナライズするために ユーザー情報を渡す ことができます。

Broadcast Message には 2 つのタイプがあります - バナーと通知です。現在、バナー通知は Git レスポンスにもメッセージを送りますが、これは レビュー中 です。

Broadcast Messaging の使用方法

すべての Broadcast Messaging の取り組みは、GitLab.com にデプロイされるためにすべてのガイドラインに従う必要があります。GitLab.com/Product プロジェクトで Broadcast Messaging テンプレート を使って Issue を作成し、レビューのために @justinfarris と @ampesta に割り当ててください。In App Messaging ボード は、キューおよび進行中のすべてのメッセージに優先順位を付けるために使用されます。

使用ガイドラインについては、Issue テンプレート を参照してください。メッセージがグループに作業を要求する場合（例: バナーメッセージの場合）、より良い可視性のために gitlab/gitlab-org プロジェクトに Issue を作成したい場合があります。

最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License