Content last updated 2026-09-29

AI Section のプロダクト開発フロー

部門横断のプロダクト開発ワークフロープロセス、オーナーシップ、およびラベリング。

概要と哲学

GitLab の AI 組織における Engineering、Product、Design は、アイデアを顧客価値に変えるために協働します。私たちのコラボレーションは、3 つの原則によって導かれます。

私たちは、チームを小規模かつ部門横断に保ち、短いサイクルで進め、初稿に高い基準を設けることで、品質を犠牲にせず速く出荷します。Customer 0 とデザインパートナーが、広範にロールアウトする前に品質を検証します。

私たちは、オーナーシップのマインドセットで運営します。作業に最も近い人が意思決定を行い、機能を構築したチームはロールアウトから本番運用まで責任を持ち続けます。

私たちは、顧客にとっての成果、すなわち採用、継続利用、信頼性、そして節約された時間とインパクトによって測定される価値で成功を測定します。

顧客成果

すべてのチームの作業は、4 つの顧客成果のいずれかにつながります。これらは GitLab AI が提供するものを定義し、優先順位付けとロードマップの意思決定を導きます。

より高い品質と速度で出荷する: 開発者はすでに使っているツールの中でより生産的になり、出荷するものもより良くなります。
自信を持って自動化する: ユーザーは長時間実行されるエージェント型ワークフローを開始し、監督なしでも確実に完了すると信頼できます。
キャパシティを拡張する: AI は、継続的な分析、包括的なレビュー、以前は手作業が必要だった定型タスクなど、チームがこれまで手を付けられなかった作業を引き受けます。
構築し組み合わせる: 顧客とパートナーは、自分たち固有のコンテキストに合わせて構築し、GitLab を自分たちのスタックにつなげることができます。
信頼して運用する: 顧客は、実行されるものを信頼し、何が起きたかを理解し、予測可能なコストと品質でスケールできます。

価値シグナル

顧客成果が実現されているかどうかは、4 つのシグナルで測定します。ブロックされている顧客は、それらすべてにおいて否定的に表れます

採用: 顧客が私たちの出荷した機能を取り入れて使用します。
継続利用: 顧客が時間の経過後もそれを使い続けます。
価値実現までの時間: 顧客が成功した成果に素早く到達します。
信頼性: 機能が本番環境で予測可能に振る舞います。

ファンクショナルチームの構成

AI ファンクショナルチームは小規模で、範囲を狭く定めます。各チームは Engineering、Product、Design のパートナーシップです。

PM は、課題、JTBD（Jobs-to-be-Done）、成功基準、顧客関係を所有します。
EM は、納期、依存関係、技術戦略およびアーキテクチャを所有します。
Design は、体験を所有します。

PM、デザイナー、エンジニアは最初に成果について認識を合わせ、その後は独立して動きます。ほとんどの意思決定は、それを所有する人がその場で行います。3 者は、意思決定が私たちの構築するものの形を変える場合に、意図的に連携します。

チーム構成、Slack チャンネル、そしてそのチームのミッション、顧客成果、成功指標、スコープ、現在の重点施策を説明するチーム憲章へのリンクは、製品カテゴリのハンドブックページで確認できます。

私たちがどう協働するか - ワークフロー

ステップ	担当	説明
1. ビジョンと計画	Product、3 者とともにキュレーション	各チームは、自分たちが解決している課題について単一の信頼できる情報源を維持し、それぞれを 4 つの顧客成果のいずれかに紐づけます。チームが作業に着手するとき、何が起きていて、それがどのように成果へつながるかが明確であるべきです。変化に反応できる柔軟性は重要ですが、私たちはこれらの顧客成果を常に提供していることに対して自分たちに説明責任を課します。
2. 優先順位付け	Product、3 者からのインプットを含む	Design と Engineering は、それぞれのバックログを機能作業と並べて優先順位付けに持ち込みます。各計画サイクルの前に、Design は品質ギャップを顧客成果に紐づけ、そのリストを計画に持ち込みます。Engineering も保守と技術的負債について同じことを行います。各マイルストーンの固定 15% をそれぞれに確保し、どちらのバックログも時間とともに膨らまないようにします。バグは、組織全体の Issue トリアージ SLO ガイドラインに従い、重要度で優先順位付けします。`~severity::1` と `~severity::2` のバグは、アクティブなリスクがあるため、15% の割り当てに関係なく SLO のタイムラインに従います。SLO 違反がない低重要度のバグ（`~severity::3` と `~severity::4`）は、15% の保守／技術的負債プール内で計画できます。Design と Engineering はインプットを所有し、ロードマップは所有しません。
3. デザインサイクル	Design、3 者はコラボレーター	計画済みの各機能の開始時に、3 者はデザインセッションを実施します。参加者は 1 名の PM、1 名のデザイナー、Engineering です。これは作業開始前に体験の方向性を合わせるための 30 分の作業ミーティングです。PM は事前に作成し検討した仕様書または概要書を持参します。Design はリードし、体験の方向性を所有し、出荷されるものの望ましさとクラフトに責任を持ちます。Engineering と PM は、技術およびプロダクトのインプットを持ち込むコラボレーターです。アウトプットは 3 者が合意した計画であり、多くの場合、構築前にそれを検証するためのプロトタイプが続きます。Engineering のインプットはレビュー時ではなく、サイクルの開始時であるここで行われます。 2 種類の作業はデザインセッションをスキップします。可逆的でリスクの低い変更、および探索的な POC または実現可能性スパイクです。POC が優先順位付けされた機能に昇格した場合、その時点でデザインセッションに入ります。各チームは、何が可逆的または低リスクに該当するかをチーム憲章で定義します。
4. マイルストーン計画	Product と EM	マイルストーンキックオフの前に、3 者はコミット済みスコープ、その作業における可逆的および不可逆的な判断（ステップ 6 を参照）、成功基準、開発前にデザインが必要な機能について合意します。Engineering は、マイルストーン開始前にそのマイルストーンで出荷する意図のあるものにコミットします。PM はそのスコープを守ることに合意します。出荷予定の Issue には `~Deliverable` ラベルを使用します。作業は、3 者が「準備完了」にサインオフした場合にのみマイルストーンへ入れます。
5. 開発	Engineering	作業は、デプロイとロールバックが容易な小さな単位で進み、チームが構築しながらドッグフーディングできるようフィーチャーフラグの背後で出荷されます。PM が Minimum Lovable Product の基準を満たしていることを確認し、Design がサインオフするまで、顧客には何も出荷しません。MLP は、顧客に対して私たちがコミットするものを定義する品質基準です。AI はコード生成、テスト、一次レビューをますます担うようになっています。エンジニアは、人間の判断が必要なところに関与します。
6. レビューと意思決定プロトコル	3 者全体で共有	重要な意思決定は、レビュー期間が始まる前に可逆的または不可逆的として分類されます。私たちはスピードを重視し、合意ではなく意思決定を最適化します。可逆的 - MR 上で通知し、関連レビュー担当者にタグ付けして出荷します。チャンネル投稿や固定期限は不要です。不可逆的 - DRI はレビュー期間を開始する前に、それを 2 つの階層のいずれかに分類します: - Tier 1（低リスク）: 48 時間の期間。DRI は同意する内容を取り込み、採用しない内容を文書化し、出荷します。 - Tier 2（法務、コンプライアンス、経営層の可視性、または大きなユーザー影響）: 3 日間の期間。必須レビュー担当者には直接通知します。DRI は、未解決の反対意見を記録したサインオフ記録とともに出荷します。迷った場合は、デフォルトで Tier 2 とします。各チームの階層定義と意思決定権限は、チーム憲章にあります。
7. デリバリー説明責任	EM がデリバリーを所有し、PM がスコープを守る	成果物はマイルストーン計画中に合意され、文書化されます。EM は、コミット済み作業を出荷すること、リスクがある場合に早期に伝えること、作業が自然に完了するのを待つのではなく緊急性を持って進めることに責任を負います。私たちは、予測可能性の尺度として、コミットしたものと出荷したものの比率である say/do を追跡します。スコープ変更、エスカレーション、アドホックな依頼はマイルストーン Issue に文書化し、方向転換のコストが見えるようにし、レトロスペクティブで利用できるようにします。
8. 顧客検証	Product 主導、3 者は招待	顧客検証は、SDLC 全体の複数ステップに入力を与える継続的なフライホイールです。 - PM は月に少なくとも 10 社の顧客と関わることを目標とし、デザイナーとエンジニアを招待して一次情報に基づくインサイトを得ます。 - 新機能は、より広範なロールアウトの前に Customer Zero にロールアウトし、前提、ユーザー体験、目的への適合性を検証します。Customer Zero へのコミュニケーションは Product 主導で、リリース投稿と似ています。Customer Zero からのフィードバックを収集するためにフィードバック Issue を作成し、顧客に愛される品質の基準が達成されない場合は、より広範なロールアウトに投資しないことを選択できます。
9. ステータス共有	ステータスは IC Engineering、利用状況とフィードバックの共有は Product	ステータスは Issue 上に存在し、週次で更新され、可視性のために Slack に要約されます。リーダーと PMM は、AI 組織の実行状況ダッシュボードを利用して、ワークストリームのリアルタイムステータスを確認します。利用データと顧客フィードバックは 3 者に戻り、次の計画サイクルに反映されます。

プロトタイピング

注記

誰でもプロトタイプを構築できます。各プロトタイプは、名前付きの問いと、その問いに答えが出た時点でテスト完了を宣言する名前付きの DRI から始まります。目標は完璧な成果物ではなく、意思決定です。作業がアイデアから機能するプロトタイプへ進むにつれて、詳細が明確になります。

プロトタイプには 2 種類があり、昇格パスが異なります:

コンセプトプロトタイプ: GitLab コードベースの外で構築されます（例: Figma、Claude artifacts）。安価で速い一方、そのまま出荷することはできません。検証済みのコンセプトは、広範なロールアウトの前に実際の機能として再構築されます。
動作するプロトタイプ: 関連する GitLab リポジトリ内のブランチで、実際の API とデータを使って構築されます。これはより重い作業であり、通常は Engineering が推進します。本番基準（テスト、規約、セキュリティレビュー）を満たせばそのまま出荷できますが、多くの場合は先に洗練されます。

どちらのタイプを使うかは、テストによって異なります。UI の意思決定、初期のコンセプト検証、ほとんどのユーザビリティテストには、コンセプトプロトタイプが適しています。技術的実現可能性や高忠実度の顧客テストには、ツリー内プロトタイプが必要です。

テスト	終了基準	DRI
ユーザビリティテスト: そのインタラクションは実際の利用に耐えるか？	チームが、そのインタラクションが機能するかどうかについて明確な可否の判断を得ている。	Design
UI の意思決定: どのパターンを前に進めるか？	1 つのパターンが選択され、その理由が示されている。	Design
顧客検証: Customer Zero でテストしたとき、このコンセプトは顧客の課題を解決するか？	Customer Zero がコンセプトを確認または却下している。	3 者
前提テスト: 私たちの仮説は成り立つか？	アイデアが証明されているか、反証されている。	3 者
技術的実現可能性: 妥当な作業範囲内でこれを構築できるか？	Engineering が、大まかな工数見積もりとともに実現可能性を確認または否定している。	Engineering

プロトタイプ検証で「可」となっても、そのコードが本番対応済みであることを意味しません。コンセプトが検証された場合、チームは広範なロールアウトの前に、それを実際の機能として再構築します。

より大きなプロトタイプ（数日を超える作業量）は、テストが名付けられた時点で 3 者と調整し、コミット済みのマイルストーンキャパシティをひそかに消費しないようにします。

ケイデンス

私たちは同期時間を大切にし、定例式のイベントを以下に限定します:

各ファンクショナルチームごとの週次 30 分同期。Engineering、Design、Product が参加します。EM がコールをリードしますが、すべてのチームメンバーが貢献します。前週に出荷したもの、ブロックされているもの、スコープ変更を扱います。ディスカッション、アイデア出し、デモ、情報共有の余地を残します。
月次マイルストーンキックオフ。45 分でチームのスコープコミットメント、可逆性の判断、成功基準、デザインサイクルに入る作業について認識を合わせます。コールは PM または EM がリードしますが、すべてのファンクショナルチームメンバーが貢献します。
月次レトロスペクティブは、EM が推進する 45 分のファンクショナルチーム同期です。Product、Engineering、Design がすべて貢献します。レトロの実行可能な成果は非同期レトロスペクティブの Issue に文書化され、チーム横断のプロセス改善特定のためにグループレベルへロールアップされます。

同期のベストプラクティス

私たちは、すべてのチームメンバーがコールの少なくとも 12 時間前までにアジェンダへ貢献することを期待します。これにより、チームがアジェンダトピックと参照資料を事前に読み、同期時間を効率的に使えるようにします。
私たちはコールを録画し、AI を使ってメモを取ります。
コールの成果を含む AI 生成サマリーは、ファンクショナルチームの Slack チャンネルに投稿されます。

プロセスの有効性の測定

上記のワークフローは、私たちをより速く、より足並みが揃い、顧客に対してより説明責任を持てるようにすることを意図しています。この目的を満たしていることを確かめるため、私たちは少数のシグナルを観察し、パターンが現れたら見直します。

定性的: チーム横断のレトロスペクティブ、顧客フィードバックループ、ファンクショナルチームメンバーからのフィードバック。
定量的: チーム指標、say/do 達成度、あるマイルストーンから次のマイルストーンへの作業の静かなずれ込みの減少。

組織構造を GitLab ラベルに変換する

AI セクションの組織構造はこちらに文書化されています。このセクションでは、その構造の各レベルに対応するラベルについて説明し、Issue と MR が適切なチームのビューに届くようにします。

組織レベル	ラベル規則	例
セクション	`~section::ai`	`~section::ai`
ステージ	`~devops::<slug>`	`~devops::agent foundations`
グループ	`~group::<slug>`	`~group::agent execution`
ファンクショナルチーム	`~Category:<name>`	`~Category:Agent Tools`

AI 組織のステータスダッシュボード

AI 組織のステータスダッシュボードは、AI セクションが何を出荷しているか、どのように追跡しているかについての信頼できる情報源です。リーダーシップは、週次ビジネスレビューや部門横断同期の事前資料としてこれを使用します。

あなたのエピックがダッシュボードに載る条件

エピックは、両方を持つ場合にダッシュボードに表示されます:

認識されている AI-org ラベルのいずれか（以下のいずれか）。現在のリストはダッシュボード取得処理の ORG_LABELSにあり、以下が含まれます:
- section::ai
- devops::agent foundations
- devops::ai clients
- devops::ai coding
- devops::ai platform
四半期計画ラベル：FY27-Q3、FY27-Q4、FY28-Q1、FY28-Q2。

トラブルシューティングのヒント

エピックに group::* または category:* ラベルだけが付いていて、section:: または devops:: がない場合、表示されません。ダッシュボードにワークストリームが表示されない場合、最初に確認すべきことは、それに上記ラベルのいずれかが付いているかどうかです。

主要なエピックメタデータ

説明サマリー。 ダッシュボードはエピックの説明を解析し、ステータスダッシュボードで閲覧者にワークストリームの概要を提供するために使用します。このジョブは、以下のヘッダーのいずれかを探しています:
- ## Summary
- ## Release notes / ## Release notes summary
- ## Release post / ## Release post summary
- ## Overview
- ## Problem / ## Problem to solve
リリースマイルストーン。 ワークストリームの想定デリバリー日を示すため、エピックに GitLab のマイルストーンを追加します。（ヒント: 19.5、19.6 のような具体的なマイルストーンを使い、「次の 1 〜 3 マイルストーン」のような一般的な時期は使わないでください）
ヘルスステータス。 進行中のワークストリームについては、GitLab のネイティブのヘルスステータスウィジェット（On track / Needs attention / At risk）でエピックのヘルスを設定します。ヘルスステータスがない場合、Weekly Status コメントが投稿されていても、そのエピックは KPI バーで「Health unavailable」に分類されます。
Weekly Status コメント。 Weekly Status コメントは、ダッシュボード上の各エピックのドロワーに表示される「AI weekly synthesis」セクションの情報源です。通常は AI が生成し、Weekly Status コメントのテンプレートを使用して、エピック上に内部ノートとして毎週投稿します。同じ見出し形式を使って手動で投稿・編集することもできます。手動の編集がダッシュボードに反映される仕組みは、ダッシュボードが変更を取り込む方法を参照してください。
CXO Interest。 この任意ラベルは、CPMO+ がフォローしているエピックをフィルタリングするために使用されます。これらのエピックでは、進行中のワークストリームに対して最も高いメタデータ忠実度が求められます。
PMM Shipping。 任意の pmm-ai-whats-shipping ラベルは、Product Marketing チーム向けにキュレーションされたリリースナラティブを作成するために適用されます。進行中の作業については、CXO と同じメタデータ衛生が期待されます。
リリースターゲット。 作業をどのようにリリースするかを示す適切なリリースターゲットラベルを追加します。選択肢には ~release target::customer zero、~release target::experimental、~release target::beta、~release target::GA があります。

ダッシュボードがあなたの変更を拾う方法

データ更新は、1 時間ごとの CI スケジュールで自動実行されるほか、ダッシュボードの ↻ Refresh now ボタンから必要に応じて実行できます。これにより、エピック、Issue、MR のメタデータ（マイルストーン、ヘルスステータスウィジェットの値、ラベル、階層）が更新されますが、Weekly Status コメントは再読み込みされません。次の項目を参照してください。
Weekly Status コメントは、上記のデータ更新とは別の 2 つの周期で取り込まれます。
- 毎週（月曜日の 12:00 UTC 頃）：スケジュールされたジョブが、進行中のエピックごとに新しい AI 作成の Weekly Status コメントを生成して投稿し、ヘルスステータスウィジェットを更新します。
- 毎日（00:00 UTC）：より軽量な臨時の再走査で、エピックにすでに投稿されている Weekly Status / Status / Async Status Update コメントを再読み込みし、ダッシュボードのキャッシュに統合します。手動で投稿・編集したコメントも、前の月曜日に AI がまとめたコメントも対象です。AI の呼び出しも投稿も行わず、GitLab にすでにある内容にダッシュボードを追従させるだけなので、手動で投稿・編集したステータスは次の月曜日を待たず、1 日以内に表示されます。
いずれの場合も、コメントは次の 1 時間ごとのデータ更新でダッシュボード自体に反映されます。
マイルストーンの遅延の記録：マイルストーンが変更されたエピック（遅延、前倒し、スケジュールへの追加・削除）はすべて、追記のみのスナップショットログに記録されます。遅延は、ドロワーの「Milestone history」セクション、表内のマイルストーン横の (N×) バッジ、および「Items slipped」KPI タイルに表示されます。

質問とフィードバック

一般的な質問は Slack で @amandarueda にメンションし、フィードバック用の Issueにフィードバックを残し、ソースプロジェクトでバグを開いてください。

最終更新 October 28, 2026: Merge pull request #591 from kyama0/translation/batch-2026-10-28-1 (5d840611)

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