Product Development Flow

概要と哲学

GitLab のプロダクトミッションは、ユーザーが愛し、価値を見出す製品と体験を一貫して生み出すことです。このミッションを果たすには、アイデアを顧客価値を提供するものに変えるための、明確に定義され、再現可能なフローを持つことが重要です。なお、より広い GitLab コミュニティからのオープンソースのコントリビューションを、プロセスのどの時点でも許可することも重要です。これらは必ずしもこのプロセスに従うわけではありません。

このページは、私たちがクロスファンクショナルな開発チームにどのように働いてほしいと期待しているかについての進化し続ける記述であり、現在活用されているワークフローを反映しています。このページのすべての必須アクションまたは成果は、以下のように示されます。

プロダクト開発フローの必須の側面を示します。

機能開発は、指定された成果を達成するためにすべてのフェーズを通過することが期待されますが、残りのワークフローはベストプラクティス、ツール、推奨事項のセットとみなすべきです。特定のプロダクト改善がすべてのフェーズを通過する必要がないユニークなケースがあることを認識しています。私たちは、プロダクトマネージャーがデザインおよびエンジニアリングチームとの足並みを揃えながら、最善の判断を使うことを信頼しています。このページの目標は、各フェーズで目指すべき必要な 成果 を明らかにするとともに、チームがこれらの成果を達成するために採用できる戦略/戦術、活動 を共有することで、チームのワークフローを支援することです。さらに、このページは、トラッキング、検索、クロスファンクショナルなコラボレーションの面でプロダクトシステムを効率的に保つために、すべてのフェーズで必要となる、ラベルなどの 最小限の 必須アクションのセットを明確にすることを目指しています。明確さを保ち混乱を避けるため、このページにはオプションのアクションは記載していませんが、このページで言及されていなくても、チームは計画用のラベルなどの追加のアクションを採用することを選んでもかまいません。

チームがプロダクト開発フローを活用する中で、特定の戦略/戦術が成功に向けてチームに役立っていることに気づくかもしれません。そのため、顧客にとって価値ある機能を構築するための選択肢の堅牢なプレイブックを作成できるよう、このページへの MR を歓迎します。すべてのチームメンバーは、ベストプラクティスを共有するために、このページの変更プロセスに従うことが推奨されます。

でも待って、これってウォーターフォールじゃないの？

いいえ。このページで説明されているフェーズは独立していて直線的に見えますが、そうではありません。簡潔さとナビゲーションのしやすさのためにこのように示されています。GitLab では、直線的に作業することを推奨していません。プロダクト開発ライフサイクルのフェーズは重なり合ったり、並行して発生したりすることがあります。

私たちは、後続のフェーズのリスクを減らすために、各フェーズで重要な成果を達成することを目指しています。しかし、プロダクト開発フローは、フェーズを通過する順序や、各フェーズに費やす時間を指示するものではありません。チームが自分たちの方向性に高い自信を持っているときは、確信の向上に寄与しないフェーズをスキップしたり短縮したりする力を持っていると感じるべきです。

例:

• エンジニアリングチームが技術レビューを実施する一方で、他のチームメンバーが Validation フェーズの活動を行います。チームはその後、自分たちの改善が顧客にとって良いものであり、技術的に実現可能であるという高い確信を持って、Build フェーズに迅速に移行できます。

• GitLab の顧客からバグが報告されます。プロダクトマネージャーがバグをテストし、その存在を確認します（Problem Validation）。チームはソリューションに非常に自信があるため、Design と Solution Validation は不要です。バグは即座に Build に移されます。

ワークフローの概要

このページを通じて、DRI が言及されるとき、参照される人物はフェーズによって異なる場合があり、また複数いる場合もあります。 DRI が誰であるかについては、Product Development Roles and Responsibilities ページを参照してください。

私たちは、Issue の状態を効率的に伝えるために Issue ステータスを使用します。これらのステータスを使用することで、チームを横断したコラボレーションが可能になり、Issue の現在の状態が伝わります。

以下の図は、新しい Issue が各ステータスをどのように移動するかを示していますが、適切な場合には状態をスキップできます。このドキュメントの残りの部分では、各ワークフローステップを詳細に説明します。

stateDiagram-v2
    [*] --> ValidationBacklog: New issue created

    ValidationBacklog: Validation backlog
    ProblemValidation: Problem validation
    ReadyForDesign: Ready for design
    Design: Design
    SolutionValidation: Solution validation

    ValidationBacklog --> ProblemValidation
    ProblemValidation --> ReadyForDesign: (Optional) Needs design
    ProblemValidation --> SolutionValidation
    ReadyForDesign --> Design
    Design --> SolutionValidation

    PlanningBreakdown: Planning breakdown
    Scheduling: Scheduling
    Refinement: Refinement
    ReadyForDev: Ready for development
    InDev: In dev
    InReview: In review
    Verification: Verification
    Complete: Complete
    Blocked: Blocked
    Security: Awaiting security release

    SolutionValidation --> PlanningBreakdown: PM signals intent to prioritize
    PlanningBreakdown --> Scheduling: (Optional) Awaiting scheduling
    PlanningBreakdown --> Refinement: (Optional) Needs refinement
    PlanningBreakdown --> ReadyForDev: Has type label & weight. Prioritization requires milestone, and Deliverable label.
    Scheduling --> ReadyForDev: Milestone assigned
    Refinement --> ReadyForDev
    ReadyForDev --> InDev
    InDev --> InReview: MRs ready for review
    InReview --> Verification: MRs merged
    Verification --> Complete: Verified in staging/prod

    InDev --> Blocked: Blocked by dependency/question
    Blocked --> InDev: Block resolved

    InReview --> Security: Waiting for monthly security release
    Security --> Verification: MRs merged and released in security update

    Complete --> [*]

唯一の信頼できる情報源 (SSOT) としての Issue の説明

Issue の説明は、常に唯一の信頼できる情報源として維持されなければなりません。

コントリビューターが現在の状態を理解するために Issue 内のすべてのコメントを読む必要があるのは、効率的ではありません。

• Issue の説明の正確性は、各フェーズを通じて DRI によって維持されるべきです。しかし、すべてのコラボレーターは、不一致や必要な更新を見つけたときに、コントリビュートでき、すべきです。

ワークフローラベルからステータスへの移行

GitLab は、プロダクト開発フローの進捗を追跡するために、スコープ付きワークフローラベル（workflow::*）の使用から Issue ステータスの使用へと移行しました。以下のマッピングは、各旧ワークフローラベルに相当するステータスを示しています。

ステータスは、バリューストリームを通じた Issue の進捗を追跡する、よりクリーンで統合された方法を提供します。

チームは、対応するワークフローラベルの代わりにステータスを使用するようにワークフローを更新すべきです。ワークフローラベルは 2026-02-27 以降サポートされなくなります。フィードバック Issue でヒントを共有し、フィードバックを残してください。

優先順位付け

何を、どのように優先順位付けするかに関するガイダンスは、以下で扱われています。

1. R&D Interlock
2. Cross-functional Prioritization
3. Customer Issues Prioritization

Validation トラック

顧客の問題がよく理解されていない場合のために、プロダクトマネージャー (PM) と User Experience Department (UXer) は、Build トラックに移行する前に、協力して新しい機会を検証すべきです。Validation トラックは、常に動き続ける Build トラックから独立したトラックです。PM と UXer は、Build トラックが常に十分に検証されたプロダクトの機会を着手できる状態にしておけるよう、協力して少なくとも 2 か月先行すべきです。マイルストーンの作業は、一部のマイルストーンが他のものよりも多くの検証努力を含むかもしれないという理解のもとで優先順位付けすべきです。バグ修正、よく理解されたイテレーティブな改善、小さなデザイン修正、技術的負債のようなものには、Validation サイクルは不要かもしれません。

Validation スペクトラム

Validation トラックで必要となる活動のタイプと調査の深さは、私たちが顧客の問題とソリューションをどれだけよく理解しているかによって異なります。

Validation の目標と成果

いつ: 提案された問題またはソリューションに対する私たちの確信が高くないとき。例えば、問題がかなりの数のユーザーにとって重要であること、またはソリューションが理解しやすく使いやすいことを合理的に確信できていない場合。

誰が: Product Manager、Product Designer、UX Researcher、Product Design Manager、Engineering Manager

何を:

✅ 私たちが解決しようとしているユーザーの問題を 理解する。

✅ ビジネス目標と、成功を判断するための主要指標を 特定する。

✅ 仮説を 生成し、調査/実験/ユーザーテストを行う。

✅ MVC と潜在的な将来のイテレーションを 定義する。

✅ 定性的・定量的分析によって、価値、使いやすさ、実現可能性、ビジネスの実行可能性に対するリスクを 最小化する。

成果: 提案されたソリューションが 1 つ以上の Product KPI にポジティブな影響を与えるという確信があります。例外には理由があり得るので、その場合チームは明確にし、私たちの KPI にマッピングし直さなくても依然として重要であることを正当化できる必要があります。

MVC や成功がどのようなものかに確信が持てない場合は、Build トラックに移行する前に Validation サイクルを続けるべきです。

Validation フェーズ 1: Validation backlog

ステータス: Validation backlog

説明

ワールドクラスの製品の成長は、よく維持されたバックログから構築されます。プロダクトマネージャーは、検証の機会がカテゴリの方向性、ステージ、および/またはセクションレベルの戦略に沿ってスコープ設定され優先順位付けされるよう、グループのバックログを洗練する責任があります。バックログは、ステークホルダーがあなたのグループを理解し関与するための唯一の信頼できる情報源でもあります。バックログ内の Issue の位置は、それらの Issue の説明、ディスカッション、メタデータとともに、ステークホルダーを最新の状態に保つために必要な重要なデータの一部です。

成果と活動

Validation フェーズ 2: Problem validation

ステータス: Problem validation

説明

正しいソリューションが提供されるよう、チームは検証された問題から作業を始めなければなりません。これは多くの形を取り得ます。

問題が文書化され、よく理解されている場合は、ユーザーの問題に関する既知のデータを文書化することで、このフェーズをすばやく通過できるかもしれません。文書化された問題は、ユーザーからの直接のフィードバックによる既存の体験、または複数のユーザーが問題を経験していることを確認するユーザーエンゲージメントを持つ Issue として分類できます。よく理解された問題とは、顧客インタビューからの一連の文書化された定性調査があるもの、問題を確認するさまざまなセンシングメカニズムを三角測量するもの、または既知のデータを使用するものです。既知のデータの例には、Customer Request Issues や、過去の調査からの既存の Actionable Insights が含まれます。問題がよく理解されていることを文書化するには、既知のデータと顧客コールを関連する Issue やエピックにリンクしてください。

問題が微妙であるか、まだよく理解されていない場合は、ユーザーと適切に検証するのにより長い時間がかかる可能性が高いです。このフェーズの主要な成果は、問題の明確な理解と、さまざまなステークホルダーに問題を伝えるためのシンプルで明確な方法です。オプションですが、個人が問題をよりよく理解し、さまざまなステークホルダーに伝えるのに役立つツールとして、Opportunity Canvas の使用を推奨します。Opportunity Canvas は、新しいリソースの要求を含む新しいカテゴリの作成を推奨するためにも使用できます。

成果と活動

Validation フェーズ 3: Ready for Design

ステータス: Ready for design

説明

Problem validation を完了した後、デザイン作業が必要な Issue は「Ready for Design」状態に移すべきです。この状態はデザインチームのキューとして機能し、問題が適切に検証され文書化された後にのみデザイン作業が始まることを確実にします。このフェーズは、プロダクトマネジメントとデザインチームの間のハンドオフを調整するのに役立ち、デザイナーがソリューションのアイデア出しを始める前に、必要なすべての文脈と検証された問題ステートメントを持てるようにします。

Ready for Design フェーズを開始するには、Issue ステータスを Ready for design に設定します。

成果と活動

Validation フェーズ 4: Design

ステータス: Design

説明

問題を理解し検証した後、私たちはダイバージ/コンバージプロセスを通じて、潜在的なソリューションのアイデア出しを開始または継続できます。ただし、Problem validation フェーズの成果が既存のソリューションへの漸進的な修正を自信を持って示唆する場合は、前述のダイバージ/コンバージプロセスをスキップできます。

このフェーズでは、潜在的なソリューションのアイデア出しを行い、単一のソリューションに収束する（コンバージ）前に、さまざまなアプローチを探る（ダイバージ）ことが含まれます。ソリューションは、顧客とビジネスの目標を満たすか、技術的に実現可能か、法的コンプライアンスの考慮事項に沿っているかを判断することで評価されます。チームは、潜在的な欠陥、見逃されたユースケース、潜在的なセキュリティリスク、そしてソリューションが意図した顧客への影響を持つかどうかを判断するために、ステークホルダーと関わることが推奨されます。

DRI は、Legal Risk Checklist（チームメンバーのみアクセス可能）をレビューし、完了する必要があるセクションがあるかどうかを判断する責任があります。チームが提案されたソリューションに収束するか、検証するための少数のオプションを特定した後、Issue は Solution Validation フェーズに移ります。

Design フェーズを開始するには、Issue ステータスを Design に設定します。

成果と活動

Validation フェーズ 5: Solution Validation

ステータス: Solution validation

説明

ビジネス要件を満たし技術的に実現可能な 1 つ以上の潜在的なソリューションを特定した後、DRI は、提案されたソリューションがユーザーのニーズと期待を満たすという確信を私たちが持っていることを確実にしなければなりません。この確信は、Design フェーズ中に行われた作業から得られ、追加の調査（ユーザーインタビュー、ユーザビリティテスト、または solution validation を含む）で補完できます。必要に応じて、このフェーズでは GitLab UX Research プロジェクト内に Solution Validation Issue を立ち上げ、チームが提案されたソリューションを検証するための調査をガイドします。

さらに、機能のあらゆる非機能要件を考慮し文書化する必要があります。これには、アプリケーション制限を導入する必要があるかどうかの評価や、データストレージに関する考慮事項の評価などが含まれます。これらの非機能要件を前もって定義することで、機能のスケーラビリティと長期的な成功を考慮していることが確実になります。この段階で、機能の長期ビジョンに沿った妥当なデフォルト値を特定すべきです。

Solution Validation フェーズを開始するには、Issue ステータスを Solution Validation に設定します。

成果と活動

Build トラック

Build トラックは、MVC を構築し、欠陥を修正し、セキュリティ脆弱性にパッチを当て、ユーザーエクスペリエンスを向上させ、パフォーマンスを改善することで、ユーザーに価値を計画、開発、提供する場所です。このトラックは、私たちがユーザーのために正しいものを作っているかどうかについてのインサイトを得る時間でもあります。チームは MVC を実装するために緊密に協力します。課題が生じた場合、決定はすばやく下されます。私たちは利用状況をインストルメントし、プロダクトパフォーマンスを追跡するので、MVC が顧客に提供された後、次のイテレーションを洗練するための学びのためにフィードバックがすばやく捉えられます。GitLab のさまざまな機能を活用して、Build トラックを流れる焦点を絞った協働的なボードを作成する方法の例については、このビデオをチェックしてください。

Build の目標と成果

いつ: プロダクト開発タイムラインに従って MVC を構築するとき

誰が: Product Manager、Product Designer、Development チーム

何を:

✅ 適切に応じて、顧客のサブセットまたは全セットに リリースする。

✅ UX、機能、技術的パフォーマンス、顧客への影響を 評価する。

✅ 次のイテレーションに情報を提供するため、成功指標に対して MVC を測定するデータを 収集する。

✅ 成功指標が達成され、プロダクト体験が最適になるまで イテレートする。

成果: 私たちの Product KPI および/または Engineering KPI の 1 つ以上を改善する、パフォーマンスの高い MVC を提供します。そうできない場合は、私たちの Efficiency バリュー（低レベルの恥を含む）を尊重し、それを放棄し、正しいソリューションを特定するために Validation サイクルを再開します。

Build フェーズ 1: Plan

必須ステータス

必須ラベル

説明

このフェーズは、エンジニアリングが構築できるよう機能を準備します。機能ではないバグ、技術的負債、その他同様の変更は、このフェーズでプロセスに入ることがあります（または、作業を行うコストが完全な問題の検証を必要とし、作業を行うことが理にかなっているかを確認するために、より早いフェーズで入ることで恩恵を受ける場合があります）。Validation フェーズ 4 に続いて、機能はすでにユーザーの成果を改善するための可能な限り迅速な変更に分割され、エンジニアリングによるより詳細なレビューの準備が整っているべきです。このフェーズ中、DRI はステータスを Planning breakdown に設定することで、マイルストーンで優先する意図のある Issue を浮上させます。この時点で、適切な DRI がエンジニアを割り当て、その作業をさらに分割してウェイトを適用します。トレードオフの決定が下され、機能の Issue は検証ソリューションから、単一のマイルストーンで提供できる明確な MVC へと進化します。すべての決定を必ず Issue に文書化してください。

このフェーズ中、DRI は Legal Risk Checklist（チームメンバーのみアクセス可能）を再訪し、Validation フェーズ 3: Design 中の以前の判断のいずれも改訂が必要ないことを確認しなければなりません。

Build トラックの初めに作業をレビューしウェイトを付けることで、DRI はより良い優先順位付けのトレードオフを行うことができ、エンジニアリングチームはマイルストーンに対して適切な量の作業をスコープ設定したことを確実にできます。Issue が Planning breakdown 状態に入っても、必ずしも次のマイルストーンで優先順位付けされることを意味するわけではありません。DRI はキャパシティと緊急性に応じてトレードオフの決定を下すかもしれません。

作業が Planning breakdown ステップを通過すると、Ready for development ステータス、type:: ラベル、そして今後のマイルストーンが Issue に適用されます。Issue が分割されているが、まだマイルストーンに引き込む準備ができていない場合は、オプションでステータスを Scheduling に設定できます。ただし、この状態では、マイルストーンなしで Ready for development ステータスを持つ Issue は、暗黙のうちに「スケジュール待ち」のステータスを持ちます。DRI は、マイルストーンを持ち Ready for development に設定された Issue に Deliverable ラベルを適用し、そのマイルストーンへの Issue の受け入れを示します。このプロセスはマイルストーン計画の初めに発生します。

このフェーズ中、Application Security Engineer に計画スケジュールへの可視性を持たせるため、彼らに情報を提供し続けることが重要です。これにより、動的テストの計画のための十分な時間が彼らに与えられ、時間/リソースの要件についてプロダクトマネージャーと開発チームに情報を提供し続けることができます。

成果と活動

Build フェーズ 2: Develop & Test

必須ステータス

説明

develop and test フェーズは、ソリューションをローンチする前に、機能を構築し、バグや技術的負債に対処し、ソリューションをテストする場所です。DRI は、バグやメンテナンス作業を含むマイルストーンの全体的な優先順位付けに直接責任を持ちます。ただし、Engineering チームはエンジニアリングワークフローを使った実装に責任を持ちます。Engineering は完了の定義を所有し、それらの要件が満たされるまで Issue は次のフェーズに移されません。多くのチームメンバーが単一の Issue にコントリビュートする可能性が高く、コラボレーションが鍵であることを覚えておいてください。

このフェーズは、フェーズ 1 で作業が分割され優先順位付けされた後に始まります。作業は、マイルストーンの初めに設定された優先順位順に完了されます。DRI は、機能の構築やバグまたはメンテナンス Issue への対処に責任を持つエンジニアに Issue を割り当てます。エンジニアは、チームのボードの Ready for development キューから次の優先順位順の Issue をセルフサービスで取り上げることもできます。そのエンジニアは、開発プロセスにおけるその位置を示すために Issue ステータスを更新します。

Issue が In review 状態にあるとき、Application Security Engineer はノンブロッキングのアプリケーションセキュリティレビュープロセスを通じてリスク軽減の検証を支援します。

作業のドキュメントは、エンジニアと Technical Writer によって作成されます（Documentation with code as a workflow を参照）。Technical Writer は、開発プロセスの一環としてドキュメントをレビューすべきです。ドキュメントレビュー中に発見された項目は、Issue が次のフェーズに移ることをブロックすべきではありません。これにより、リリース後のドキュメントのフォローオン改善 MR の作成が促されることがあります。

機能コードがマージされた後、Issue は Verification ステータスに移すべきです。 Issue が Verification 状態にあるとき、担当エンジニアは Staging または Production 環境のいずれかで機能を手動でテストします。

注: エンジニアリングによって範囲外または不完全とみなされた作業は、洗練と完了のための再スケジュールのためにplan フェーズに戻されます。

成果と活動

Build フェーズ 3: Launch

Issue ステータス: Closed

必須ステータス

説明

変更が production で利用可能になり、必要な検証が完了したとき、Issue は Complete ステータスに設定され、ステークホルダーがそれに対する作業が完了したことを知れるようにします。その後、DRI は該当する場合にリリース投稿と dogfooding プロセスを調整します。

成果と活動

Build フェーズ 4: Improve

ラベル: n/a

説明

ローンチ後、DRI はプロダクトの利用状況データに細心の注意を払うべきです。これは、AMAU がインストルメントされ、期待どおりに報告されていることを確認することから始まります。そこから、機能が GMAU と SMAU にどのような影響を与えたかを検討します。この時点で、成功指標が達成/超過され、プロダクト体験が十分であるという決定を下せるまで、フォローオンのイテレーティブな改善を導くために顧客フィードバックも求めるべきです。組み合わされた継続的な定量・定性のフィードバックループを作成するため、以下の成果と潜在的な活動を考慮することが推奨されます。

成果と活動

リリースステージのガイドライン

チームは、最初に experimental、beta、limited availability としてリリースする強い理由がない限り、最初から generally available として機能をリリースすべきです。

プロダクト開発チームは、GitLab のユーザーやプラットフォームに重大なリスクや摩擦を生み出す可能性があると考えられる変更を行うことを控えるべきです。例えば、以下のようなものです。

• ユーザーがアクセスする既存の production データの損傷や流出のリスク。
• アプリケーションの他の部分を不安定にすること。
• 高い Monthly Active User (MAU) 領域に摩擦を導入すること。

Experiment 機能

ユーザー向けの experiment の詳細に加えて、experiment は:

• デフォルトで「スコープ」や機能セットではなく、「成熟度」レベルや品質基準でもありません。
• プロジェクトリードが自分の機能を検証するために使えるツールであり、最も一般的には 問題 を検証するためのものです。
• 必須ではなく、スキップでき、実際、問題がすでに（例えばユーザー調査や他の方法で）検証されている場合はスキップすべきです。
• 壊れているものに関するフィードバックを得る方法として使うべきではありません。
• 機能を早期にリリースするために使うべきではありません。
• すべての experiment が GA になることが期待されているわけではありません。
• experiment は科学的方法に従い、テンプレート化された構造を使うべきです。
• 事前に明確な成功/失敗の基準が定義された、答えを必要とするテスト可能な仮説を持ちます。
  • その仮説をテストできる experiment を設計する。
  • experiment を可能な限り短い期間実行する。
  • experiment の結果を報告する（たとえ数行でも）。
  • experiment が成功したかどうかと次のステップを決定する。
  • 理想的には 1 〜 2 マイルストーンのみ続けるべきです。
• TODO: [DRI が必要] テレメトリ要件をここに追加またはリンクすべきです。
• TODO: [DRI が必要] experiment の UX 要件をここに追加またはリンクすべきです。
• TODO: [DRI が必要] experiment のエンジニアリング要件をここに追加またはリンクすべきです。
• 最小限の摩擦でオプトインする方法を提供します。
• オプトインで GitLab Testing Agreement にリンクアウトします。
• 機能が GitLab Testing Agreement の対象であることを反映したドキュメントを持ちます。
• experiment ステータスを反映した UI を持ちます。
• 社内外のユーザーと関わるためのフィードバック Issue を持ちます。
• リリース投稿でアナウンスされません。
• 必要に応じて、discovery moments を通じてユーザーインターフェースで促進されます。

レビュー基準を満たすすべての実験的機能は、PREP Assessment を開始し、readiness テンプレートの experiment セクションを完了しなければなりません。

Beta 機能

ユーザー向けの beta の詳細に加えて、beta 機能は:

• デフォルトで「スコープ」や機能セットではなく、「成熟度」レベルや品質基準でもありません。
• プロジェクトリードが自分の機能を検証するために使えるツールであり、最も一般的にはソリューションを検証するためのものです。
• 問題がすでに検証され、ソリューションに自信があるが、顧客と検証したいときに使うべきです。
• 必須ではなく、スキップできます。
• 壊れているものに関するフィードバックを得る方法として使うべきではありません。
• 機能を早期にリリースするために使うべきではありません。
• GA になる可能性が高いです。
• プロジェクトリードは、beta ユーザーを募るために Advisory and Executive customer programs や EAP の使用を検討すべきです。
• プロジェクトリードは、外部コントリビューターが beta にどのように参加できるかを検討すべきです。
• beta を実行するプロジェクトリードは、理想的には作業が始まる前に、UX と Engineering との議論の後で、beta の終了基準を定義すべきです。
• TODO: [DRI が必要] テレメトリ要件をここに追加またはリンクすべきです。
• TODO: [DRI が必要] beta の UX 要件をここに追加またはリンクすべきです。
• TODO: [DRI が必要] beta のエンジニアリング要件をここに追加またはリンクすべきです。
• beta ステータスを反映したドキュメントを持ちます。
• beta ステータスを反映した UI を持ちます。
• 社内外のユーザーと関わるためのフィードバック Issue を持ちます。
• 望む場合、beta ステータスを反映したリリース投稿でアナウンスされます。
• 必要に応じて、discovery moments を通じてユーザーインターフェースで促進されます。

レビュー基準を満たすすべての beta 機能は、PREP プロセスに従って、readiness テンプレートの beta セクションまでのすべてのセクションを完了しなければなりません。

公開された機能

公開された機能は以下を満たさなければなりません。

1. レビュー基準を満たす。
2. PREP プロセスを完了する。
3. readiness テンプレートの General availability セクションまでのすべてのセクションを完了する。
4. TODO: [DRI が必要] 利用規約（または他の合意や法務）をここに追加またはリンクする。
5. TODO: [DRI が必要] テレメトリ要件をここに追加またはリンクする。
6. TODO: [DRI が必要] 監査イベント要件をここに追加またはリンクする。
7. TODO: [DRI が必要] Geo（ディザスタリカバリ）要件をここに追加またはリンクする。
8. TODO: [DRI が必要] SLA をここに追加またはリンクする。
9. TODO: [DRI が必要] 顧客が期待できるサポートレベルをここに追加またはリンクする。
10. TODO: [DRI が必要] セキュリティ要件をここに追加またはリンクする。
11. TODO: [DRI が必要] 許可される既知のバグのレベルと数に関する情報をここに追加またはリンクする。
12. TODO: [DRI が必要] スケーラビリティ要件をここに追加またはリンクする。
13. TODO: [DRI が必要] 可用性要件をここに追加またはリンクする。
14. TODO: [DRI が必要] UX 要件をここに追加またはリンクする。
15. TODO: [DRI が必要] 将来の廃止予定のコミットメントをここに追加またはリンクする。
16. TODO: [DRI が必要] プラットフォーム（API など）としての readiness 情報をここに追加またはリンクする。

Generally Available

上記の公開基準に加えて、GA 機能は:

1. すべての GitLab プラットフォーム（GitLab.com、GitLab Self-Managed、GitLab Dedicated、GitLab Dedicated for Government）で利用可能でなければなりません。

より早期のアクセスを提供する

私たちのミッションは「everyone can contribute」であり、それは社外の人々が機能を試せる場合にのみ可能です。異なる組織の人々が何かを試すと、より質の高い（より多様な）フィードバックが得られるので、十分な価値があるときには、ユーザーが実験的機能にオプトインできるようにしてください。

可能な場合は、社内のみでテストしたり機能が beta 状態になるのを待ったりするのではなく、実験的機能を社外にリリースしてください。私たちは、機能を長期間社内のみに保つことは、不必要に私たちを遅くすることを学びました。

実験的機能は、人々/組織が experiment にオプトインしたときにのみ表示されるので、ここでは誤りを犯すことが許され、文字どおり実験できます。

Experiment と beta の終了基準

general availability より前のフェーズを可能な限り短くするため、experiment、beta、limited availability の各フェーズには終了基準を含めるべきです。これにより、迅速なイテレーションが促され、サイクルタイムが削減されます。

GitLab のプロダクトマネージャーは、実験的機能と beta 機能にどの終了基準を適用するかを決めるとき、以下を考慮しなければなりません。

• 時間: 機能が generally available になる終了日を定義します。
  • general availability への終了の準備状況を定義する、時間制限のある目標指標の設定を検討します。 例えば、experiment のローンチ後 6 か月にわたって MoM で X 件の顧客を維持する、beta のローンチ以来 3 か月で無料および有料ユーザーが X% 成長する、または同様のものです。
  • 市場投入までの時間、ユーザーエクスペリエンス、体験の豊かさのバランスを取ることに留意してください。 一部の beta プログラムは 1 マイルストーン続き、他のものは数年続きました。
• フィードバック: オンボーディングされインタビューされた顧客の最小数を定義します。
  • フェーズを離れる終了基準としてユーザーフィードバックを使う場合は、時間制限も設定することを検討します。 一定の期間が経過しても十分なユーザーからフィードバックを募れない場合は、general availability より前の状態を維持するよりも、その時点で持っているものを出荷し、generally available としてイテレートするほうがよいです。
• 限定的な機能の完成: general availability に移る前に完成させるべき機能があるかどうかを判断します。
  • 「あともう 1 つ」機能を含めることに注意してください。イテレーションは、より多くのユーザーからのより多くのフィードバックがあるほうが簡単で効果的なので、general availability に到達することが望ましいです。
• システムパフォーマンス指標: プラットフォームが general availability の準備ができる前に示した基準を判断します。 例には、レスポンスタイムや、毎秒特定の数のリクエストを正常に処理することが含まれます。
• 成功基準: すべての機能が generally available になるわけではありません。早期のフィードバックが、別の方向のほうがより多くの価値やより良いユーザーエクスペリエンスを提供すると示す場合、方向転換してもかまいません。機能を製品に入れる価値があるかを決めるために答えなければならないオープンな質問がある場合は、それらをリストアップして答えてください。

AI 機能 の終了基準については、上記に加えて、UX 成熟度要件を参照してください。

このページへのコントリビューション

このページへのすべてのマージリクエストは、Product と Engineering のリーダーシップ（ページの「maintainers」または codeowners を参照）に知らせる必要があります。 文法の修正やタイポなどの更新を行うには、任意の承認者にレビューしてもらいマージできます。

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