Content last updated 2026-07-22

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

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

概要と哲学

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

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

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

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

顧客成果

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

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

価値シグナル

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

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

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

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

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

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

チーム構成、Slack チャンネル、そしてそのチームのミッション、顧客成果、成功指標、スコープ、現在の重点施策を説明するチーム憲章へのリンクは、Product Categories Handbook pageで確認できます。

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

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

プロトタイピング

注記

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

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

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

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

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

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

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

ケイデンス

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

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

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

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

プロセスの有効性の測定

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

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

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

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

組織レベル	ラベル規則	例
Section	`~section::ai`	`~section::ai`
Stage	`~devops::`	`~devops::agent foundations`
Group	`~group::`	`~group::agent execution`
Functional team	`~Category:`	`~Category:Agent Tools`

AI org status dashboard

AI org status dashboard は、AI section が何を出荷しているか、どのように追跡しているかについての信頼できる情報源です。Leadership は、週次ビジネスレビューや部門横断同期の事前資料としてこれを使用します。

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

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

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

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

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

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

説明サマリー。 ダッシュボードはエピックの説明を解析し、ステータスダッシュボードで閲覧者にワークストリームの概要を提供するために使用します。このジョブは、以下のヘッダーのいずれかを探しています:
- ## Summary
- ## Release notes / ## Release notes summary
- ## Release post / ## Release post summary
- ## Overview
- ## Problem / ## Problem to solve
リリースマイルストーン。 ワークストリームの想定デリバリー日を示すため、エピックに GitLab milestone を追加します。（ヒント: 19.5、19.6 のような具体的なマイルストーンを使い、「next 1-3 milestones」のような一般的な時期は使わないでください）
ヘルスステータス。 進行中のワークストリームについては、GitLab のネイティブ health-status ウィジェット（On track / Needs attention / At risk）でエピックのヘルスを設定します。ヘルスステータスがない場合、Weekly Status comment が投稿されていても、そのエピックは KPI バーで「Health unavailable」に分類されます。
Weekly Status comment。 Weekly Status comment は、ダッシュボード上の各エピックのドロワーに表示される「AI weekly synthesis」セクションのソースです。これらは AI 生成コメントであり、Weekly Status comment templateを使用して、エピック上に内部ノートとして週次で投稿されます。
CXO Interest。 この任意ラベルは、CPMO+ がフォローしているエピックをフィルタリングするために使用されます。これらのエピックでは、進行中のワークストリームに対して最も高いメタデータ忠実度が求められます。
PMM Shipping。 任意の pmm-ai-whats-shipping ラベルは、Product Marketing team 向けにキュレーションされたリリースナラティブを作成するために適用されます。進行中の作業については、CXO と同じメタデータ衛生が期待されます。

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

データ更新 は現在手動です。ダッシュボードは依頼に応じてエピック、MR、Weekly Status comment を再取得します。更新は通常、営業日に 1 日あたり約 3 回行われます。
マイルストーンずれの捕捉: マイルストーンが変更されたエピック（ずれ、前倒し、スケジュール設定、スケジュール解除）は、前方のみのスナップショットログに記録されます。ずれは、ドロワーの「Milestone history」セクション、テーブル内のマイルストーン横の (N×) バッジ、および「Items slipped」KPI タイルに表示されます。
ドロワー内の AI weekly synthesis は、あなたの Weekly Status comment から抽出されます。投稿後、次回更新時に反映されます。

質問とフィードバック

一般的な質問は Slack で @amandarueda に ping し、feedback issueにフィードバックを残し、source projectでバグを開いてください。

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)

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