トライアルのオーナーシップとコラボレーションのフレームワーク

概要

このページでは、GitLab のトライアル業務について 誰が何を所有するか、そして関係するチームがどのように協力するかを定義します。概念的なオーナーシップモデル（トライアル体験のどの部分について、どのチームが説明責任を負うか）と、CustomersDot のような共有コードベースにコントリビュートするための実践的な意思決定フレームワークの両方を扱います。

トライアルは常に複数のコードベース（GitLab と CustomersDot）にまたがり、複数の顧客状態（新規見込み客と既存の有料顧客）に対応してきました。長年にわたって変化してきたのは、どのチームがどの部分を所有するか です。また、ある時期には 1 つのチーム内に十分明確に収まっていたため、文書化されたモデルは不要でした。現在はそうではありません。オーナーシップは Growth と Fulfillment/Monetization に分かれ、トライアルのコードベースは Fulfillment/Monetization のもとに集約されつつあります。これにより、新規と既存のすべてのトライアルタイプが 1 か所にまとめられます。このページでは、その境界を明確にします。

このフレームワークは、CustomersDot でのトライアル業務において Growth の自立性を実現する取り組みを基盤としています（エピック #20063を参照）。その目標は、Growth が所有するトライアルのエントリーポイントで迅速に動けるようにする一方で、Fulfillment/Monetization が基盤となるトライアルコードベース、請求、プロビジョニングインフラストラクチャを所有し、維持することです。

概念的なオーナーシップモデル

オーナーシップは、単一のリポジトリに沿ってではなく、チームが何について説明責任を負うか に沿って分割されます。オーナーシップは、トライアル体験の レイヤー（エントリーポイントかコードベースか）と、顧客状態（新規見込み客か既存の有料顧客か）という 2 つの観点で決まります。

中核原則: エントリーポイントとコードベース

Growth は、トライアルを開始する薄い CustomersDot エントリーレイヤーを含め、関心をトライアル開始につなげること に説明責任を負います。Fulfillment/Monetization は、トライアル開始後に トライアルが実際に機能すること、すなわちエントリーポイントの背後にあるプロビジョニング、エンタイトルメント、請求、ライフサイクルのシステムと、そのコードの長期的な健全性に説明責任を負います。

CustomersDot 内の境界線は深さです。Growth はトライアルの エントリーエンドポイントと基本コントローラー を所有します。リクエストがトライアル作成、プロビジョニング、エンタイトルメント、請求、共有サービスのいずれかに入った時点から、Fulfillment/Monetization の所有になります。変更が境界線のどちら側にあるか判断に迷う場合は、以下の 意思決定フレームワークを使用してください。

このオーナーシップの分割は、エントリーレイヤーを 構築すること に適用されます。Growth が構築または変更する可能性がある薄いエントリーレイヤーを含め、CustomersDot 全体の運用サポート、インシデント、オンコールは Fulfillment/Monetization が引き続き担当します（エンジニアリングエクセレンスと継続的な保守のオーナーシップを参照）。

より深いトライアルコードベースを Fulfillment/Monetization のもとに集約することで、オーナーシップを複数のチームに分散させるのではなく、新規見込み客向けトライアル、有料顧客向けのアドオン／拡張トライアル、将来のあらゆるトライアルのバリエーションを含む、すべてのトライアルタイプの 実装 を 1 つのチームが所有します。特にトライアルの エンタイトルメント は、すべてのトライアルのエンタイトルメントを支援する Fulfillment の Entitlements 領域に属します。

顧客状態: 新規見込み客と既存の有料顧客

トライアルは 2 つの異なる顧客状態に対応し、歴史的にはそれが Growth と Fulfillment の業務を分ける境界線でした。

• 新規見込み客向けトライアル — まだ有料顧客ではないユーザーや組織が、トライアルを通じて GitLab を評価します。Growth はエントリーポイント（獲得、申し込み、アクティベーション、有料プランへの転換）を所有します。トライアルをプロビジョニングして実行するトライアルコードベースは、Fulfillment/Monetization が所有します。
• 既存の有料顧客向けトライアル — 既存の有料顧客が、アドオン、上位ティア、追加機能を試用します（たとえば、有効なサブスクリプションに加えて機能を試用する場合）。ここでのエントリーポイントは、プロダクト内の拡張やアップグレードの接点に近くなります。プロビジョニング、エンタイトルメント、請求への影響は Fulfillment/Monetization が所有します。

両方の状態に共通するルールは、Growth がトライアルを開始するエントリーポイントを所有し、Fulfillment/Monetization がそれを実現するコードベースを所有する ことです。

エンジニアリングエクセレンスと継続的な保守のオーナーシップ

ユーザー向けの機能ではないものの、トライアルシステムを健全に保つ業務、すなわちトライアルコードベース内の 可観測性、監視、パフォーマンス改善、信頼性、技術的負債、リファクタリング は、コードベースオーナーである Fulfillment/Monetization が所有します。これは、そのコードに最後に機能をリリースしたチームに関係なく適用されます。

実際には、以下のようになります。

• Fulfillment/Monetization は、トライアルのエントリーエンドポイントと基本コントローラーを含む、CustomersDot のトライアルコードベース全体の運用可能性と長期的な保守性（計測、アラート、ダッシュボード、パフォーマンス、インシデント対応、オンコール）に対する DRI です。
• エントリーレイヤーを含め、CustomersDot のあらゆる部分に関するサポート Issue、バグレポート、インシデントは、Fulfillment/Monetization がトリアージして所有します。Growth は依頼された場合にエントリーレイヤーの詳細について支援しますが、サポート DRI ではありません。
• Growth は、所有するエントリーポイントの プロダクトアナリティクスと実験トラッキング を計測します。これらのイベントが共有コードから発生する場合でも同様です。Growth は配置とレビューについて Fulfillment/Monetization と調整します。
• Growth がトライアルコードベースに機能をコントリビュートすると、Fulfillment/Monetization がそのコードの継続的な保守とサポートのオーナーシップを引き継ぎます（以下の意思決定フレームワークを参照）。そのため、Growth のコントリビューションは、コードベースオーナーの品質、テスト、可観測性の基準を満たす必要があります。

トライアルリクエストのライフサイクル: 各段階のオーナー

このモデルを適用する最も明確な方法は、トライアルリクエストを最初から最後までたどることです。オーナーシップは、コードが存在する リポジトリではなく、各ステップの 機能（トライアルの開始か実現か）に従います。判断に役立つ目印は、トライアルを開始するための GitLab から CustomersDot への アウトバウンド呼び出しは Growth のエントリーポイントである一方、結果をプロビジョニングするための CustomersDot から GitLab への インバウンド呼び出しは、そのプロビジョニングコードが GitLab 内で実行される場合でも Fulfillment/Monetization に属することです。

要約すると、Growth は UI/UX と、CustomersDot にトライアルを送信する行為（ステップ 1～3）を所有します。Fulfillment/Monetization は、申請によって発生するすべての処理、すなわち作成、エンタイトルメント、請求、GitLab の名前空間／ライセンスを更新するプロビジョニングコールバック（ステップ 4～6）に加え、そのすべてのサポート（ステップ 7）を所有します。

オーナーシップの判断と従うべきステップを組み合わせたエンドツーエンドの実例については、以下の 実例を参照してください。

意思決定フレームワーク

上記の概念的なオーナーシップモデルは、説明責任 を定義します。この意思決定フレームワークは、共有コードベースへのコントリビューション（主に CustomersDot）における実践的な適用方法です。Growth が直接コントリビュートできる場合と、コードベースオーナーである Fulfillment/Monetization に関与を求める必要がある場合を示します。Growth が直接コントリビュートする場合でも、マージされたコードの継続的な保守のオーナーシップは Fulfillment/Monetization に残ります。

Growth が独立してコントリビュートする

Growth のチームメンバーは、トライアルのエントリーレイヤー、すなわち GitLab アプリケーションのトライアル接点と、CustomersDot の薄いトライアルエントリーエンドポイントおよび基本コントローラーに限定され、プロビジョニング、エンタイトルメント、請求、共有システムに及ばない変更に直接コントリビュートできます。

Growth が所有する変更の例:

1. トライアルのエントリーエンドポイントと基本コントローラー: プロビジョニング、エンタイトルメント、請求の動作を変更しない限り、トライアルリクエストを受信してルーティングする CustomersDot のエンドポイントと基本コントローラーに対する変更
2. トライアル開始時の適格性チェック: ダウンストリームでのエンタイトルメント付与方法とは別に、エントリーポイントでトライアルを 開始できる 対象を制限するエントリーレベルのゲート（たとえば、ドメイン制限、ユーザー属性、地域制限）
3. トライアル UX とエントリーフロー: トライアル申し込みフロー、オンボーディング体験、トライアルから有料プランへの転換の接点
4. トライアルのトラッキングとアナリティクス: トライアル開始時と転換時の動作に関する計測、アナリティクスイベント、実験トラッキング
5. トライアル開始時のメッセージング: トライアル開始に関連するコピー、メールテンプレート、アプリ内メッセージング
6. トライアルのフィーチャーフラグ: トライアルのエントリーポイント機能や実験を制御するフィーチャーフラグ

変更がエントリーレイヤーから始まっても、より深い動作が必要な場合（たとえば、プロビジョニングで適用する必要がある新しい適格性ルールや、トライアルのプロビジョニング方法に影響する期間変更）は、コードベースオーナーの領域に入ります。コードベースオーナーに関与を求めるを参照してください。

独立したコントリビューションのプロセス:

1. 標準の GitLab コントリビューションガイドラインに従う
2. 適切なラベルを適用する: devops::growth、group::activation（または関連する Growth グループ）、CustomersDot
3. 周知のため #s_fulfillmentで Fulfillment/Monetization に通知する
4. CustomersDot のコードベースに触れる場合、コードレビューに Fulfillment/Monetization のメンテナーを含める

コードベースオーナー（Fulfillment/Monetization）に関与を求める

Growth は、請求、サブスクリプション、プロビジョニングインフラストラクチャ、または有料顧客に影響する共有システムに関する変更について、Fulfillment/Monetization のトライアルコードベースオーナーに関与を求める必要があります。

コードベースオーナーが所有する変更の例:

1. 請求統合: Zuora 統合、決済処理、請求書生成に対するあらゆる変更
2. サブスクリプションのプロビジョニング: サブスクリプションの作成、アクティベーション、管理方法の変更
3. ライセンス生成: ライセンスキーの生成、検証、配布に対する変更
4. Zuora 統合: Zuora API 呼び出し、データ同期、請求ワークフローに関するあらゆる業務
5. 共有インフラストラクチャ: データベーススキーマ変更、複数システムで使用される API エンドポイント、CustomersDot の中核サービス
6. コンプライアンスとセキュリティ: PCI コンプライアンス、データプライバシー、セキュリティコントロールに影響する変更

Fulfillment/Monetization に関与を求めるプロセス:

1. 適切な受付テンプレートを使用し、fulfillment-metaプロジェクトで Issue を作成する
2. #s_fulfillmentで連絡し、リクエストについて話し合う
3. アプローチとタイムラインを合わせるため、必要に応じて同期ミーティングを設定する
4. コードベースオーナーの プロジェクト管理プロセスに従う
5. DRI として Fulfillment/Monetization のチームメンバーと実装について協力する

判断と相談

変更が Growth の領域に属するか、Fulfillment/Monetization の関与が必要か判断に迷う場合は、相談するほうを選びます。以下の要素を検討してください。

以下の場合は Fulfillment/Monetization に相談する:

1. 変更が請求の正確性や収益認識に影響する可能性がある
2. 変更の「影響範囲」（影響を受けるユーザー／システムの数）が不明である
3. 変更にプロビジョニング、ライセンス、請求に固有のドメイン知識が含まれる
4. 変更が有料顧客や本番システムに影響する可能性がある
5. 変更が共有コードパスやインフラストラクチャを変更する

相談方法:

1. Issue のリンクと簡単な説明を #s_fulfillmentに投稿する
2. 関連する Fulfillment/Monetization のチームメンバー（その領域に詳しい PM、EM、エンジニア）をタグ付けする
3. アプローチについて話し合うため、必要に応じて短時間の同期ミーティングをリクエストする
4. 今後の参考のため、決定を Issue に記録する

エスカレーション経路

優先順位の競合が発生した場合や、Growth がコードベースオーナーの現在のキャパシティを超える速度で進める必要がある場合は、以下のエスカレーション経路を使用します。

レベル 1: 直接コントリビューション

使用する状況: Growth に変更を実装する能力はあるものの、コードベースオーナーのレビューと承認が必要な場合。

プロセス:

1. Growth が CustomersDot のコントリビューションガイドラインに従って変更を実装する
2. Fulfillment/Monetization のメンテナーにレビューをリクエストする
3. フィードバックに対応し、必要に応じてイテレーションを行う
4. Fulfillment/Monetization が正確性と潜在的な影響についてレビューする
5. コードベースオーナーの承認を得てマージする

タイムライン: 複雑さに応じて通常 1～2 マイルストーン

レベル 2: リーダーシップレベルでの優先順位の見直し

使用する状況: 業務に Fulfillment/Monetization による実装が必要だが、キャパシティや競合する優先事項によってブロックされている場合。

プロセス:

1. Growth PM が Growth Product Director にエスカレーションする
2. Growth Director が Fulfillment Product Director と優先順位について話し合う
3. ビジネスへの影響と緊急性を共同で評価する
4. Director レベルで優先順位の見直しを決定する
5. Fulfillment/Monetization がマイルストーン計画を適宜調整する

タイムライン: 通常、計画に 1 マイルストーン + 実装時間が必要

レベル 3: リソース配分の調整

使用する状況: 継続的なキャパシティ制約により、チーム構成や責任の構造的な変更が必要な場合。

プロセス:

1. Director が継続的なキャパシティギャップを特定する
2. 一時的なチームメンバーの貸し出し、採用、組織再編という選択肢を評価する
3. 部門横断的なリソース配分が必要な場合は VP レベルにエスカレーションする
4. 合意したリソース調整を実施する
5. 新しい責任と引き継ぎを文書化する

タイムライン: 構造変更には通常 1～2 四半期

コラボレーションプロセス

コミュニケーションチャンネル

1. 主要な Slack チャンネル:

   • #s_growth - Growth チームのチャンネル
   • #s_fulfillment - Fulfillment/Monetization チームのチャンネル
   • 質問、コラボレーションのリクエスト、ステータス更新にはこれらのチャンネルを使用する

2. Issue トラッキング:

   • Growth の Issue: devops::growth ラベルが付いた gitlab-org/gitlab
   • Fulfillment/Monetization の Issue: gitlab-org/fulfillment-meta
   • CustomersDot の Issue: gitlab-org/customers-gitlab-com

定期的な連携

Growth と Fulfillment/Monetization の各チームは、以下を通じて定期的なコミュニケーションを維持する必要があります。

1. 共有 Slack チャンネルでの非同期更新
2. 関連する Issue とマージリクエストでのメンション
3. 四半期ごとの計画調整セッション
4. 複雑な取り組みのため、必要に応じて行う同期ミーティング

コードレビュープロセス

1. CustomersDot のすべての変更には、コードベースオーナーである Fulfillment/Monetization のメンテナーによるレビューが必要
2. Growth のエンジニアは、影響を受ける領域に詳しい Fulfillment/Monetization のチームメンバーにレビューをリクエストする必要がある
3. Fulfillment/Monetization は迅速なレビュー（標準的な変更では 2 営業日以内）を約束する
4. 緊急の変更では、レビューを迅速化するため #s_fulfillmentで調整する

実例

以下の例では、オーナーシップの判断（ライフサイクルのステップに対応）と 実際に行うこと を組み合わせています。エンジニアリングとプロダクトの両方の意思決定を扱います。これらをパターンとして使用してください。新しい状況に明確に当てはまらない場合は、ライフサイクルの表と 意思決定フレームワークに戻ってください。

Growth が独立してコントリビュートする（エントリーレイヤー、ステップ 1～3）

これらはエントリーレイヤーに限定され、プロビジョニング、エンタイトルメント、請求を変更しないため、Growth の領域にとどまります。

トライアル期間または開始時の適格性に関する実験 — たとえば、あるセグメントで 30→60 日のトライアルをテストしたり、エントリーポイントで企業規模に応じてトライアルを 開始できる 対象を制限したりする場合。

• オーナー: Growth（ステップ 1～3）。注意事項: 期間または適格性ルールを プロビジョニング／エンタイトルメント中に適用する 必要がある場合、その適用はステップ 4 です → Fulfillment/Monetization に関与を求めます。セールス／リードのルーティングに影響する可能性がある適格性は判断が必要です。最初に相談してください（以下を参照）。
• 行うこと: 実験計画を含む Issue を作成 → エントリーレイヤーの変更とアナリティクスを実装 → 周知のため #s_fulfillmentに投稿 → CustomersDot の変更について Fulfillment/Monetization のメンテナーにレビューをリクエスト → デプロイして監視。

トライアルフォームにフィールドを追加し、CustomersDot に渡す。

• オーナー: Growth — GitLab UI + 送信ペイロード（ステップ 1～2）と、それを受け入れる CustomersDot のエントリーエンドポイント／コントローラー（ステップ 3）。フィールドが トライアルのプロビジョニングまたはエンタイトルメントの方法を変更する 必要がある場合はステップ 4 が関係します → Fulfillment/Monetization に関与を求めます。
• 行うこと: フォームと送信の変更を実装 → フィールドを受け入れるようエントリーコントローラーを拡張 → メンテナーにレビューをリクエスト → プロビジョニングに影響する場合、ステップ 4 を調整するため fulfillment-meta Issue を作成。

トライアル開始時と転換時にアナリティクス／実験トラッキングを追加する。

• オーナー: Growth — 共有コードからイベントが発生する場合でも、所有するエントリーポイントのプロダクトアナリティクス（ステップ 1～3）。
• 行うこと: GitLab の計測ガイドラインに従ってイベントを実装 → 共有コードに触れる箇所について Fulfillment/Monetization と配置／レビューを調整 → 標準のメンテナーレビュー → イベントが正しく発生することを検証。

Fulfillment/Monetization に関与を求める（コードベース、ステップ 4～6）

これらはプロビジョニング、エンタイトルメント、請求、または GitLab へのプロビジョニングコールバックに触れるため、コードベースオーナーが必要です。

トライアルから有料プランへの転換／サブスクリプション作成フロー。

• オーナー: Fulfillment/Monetization（ステップ 4～5）。サブスクリプション作成と請求に触れ、収益認識に影響する可能性があります。
• 行うこと: fulfillment-metaで Issue を作成 → Fulfillment/Monetization の PM + エンジニアと同期 → 設計に協力 → Fulfillment が実装または綿密にレビュー → 共同テスト → 調整されたデプロイ。

トライアルの名前空間に申請後、正しいアドオン／ティアが設定されない、またはライセンス／シート数やサブスクリプションレコードが誤っている。

• オーナー: Fulfillment/Monetization — GitLab へのプロビジョニングコールバック（ステップ 6）とエンタイトルメント／請求ロジック（ステップ 4～5）は、ステップ 6 が GitLab リポジトリで実行される場合でも完全に所有します。
• 行うこと: Fulfillment/Monetization をコードベース + サポート DRI として割り当て → 問題が引き渡し部分（ステップ 3↔4 の境界）で発生している場合、Growth がエントリーレイヤー／申請のコンテキストを提供。

共有業務 — 境界に沿って分割する

既存の有料顧客が、プロダクト内からアドオンまたは上位ティアを試用する。

• オーナー: 共有。Growth はアドオントライアルを開始するプロダクト内の拡張／アップグレードの接点（エントリーポイント、ステップ 1～3）を所有し、Fulfillment/Monetization はその付与に関するエンタイトルメント、プロビジョニング、請求（ステップ 4～6）を所有します。これは、モデルにおける既存の有料顧客の状態です。
• 行うこと: Growth がエントリーポイント／CTA を実装して計測 → エンタイトルメントとプロビジョニングについて Fulfillment/Monetization に関与を求める → 申請契約（トライアルのエンタイトルメントを付与、追跡、失効する方法）について合意 → 共同レビュー → 調整されたデプロイ。

新しいエントリー体験と新しいプロビジョニングの両方を備えた新しいトライアルタイプ。

• オーナー: 共有 — 業務を分割します。Growth がエントリーポイント（ステップ 1～3）のスコープを定め、Fulfillment/Monetization が作成／エンタイトルメント／プロビジョニング（ステップ 4～6）のスコープを定めます。
• 行うこと: 2 つの部分の間の申請契約について事前に合意 → 両方のバックログにまたがるリンクされた Issue として追跡 → エントリーポイントの変更は通常プロビジョニング側に依存するため、マイルストーンを調整。

判断が必要 — 最初に相談する

セールスワークフローやリードのルーティングに影響する可能性があるエントリーレイヤーの適格性 — たとえば、大企業のトライアルを制限し、直接的なセールス対応を促す場合。

• オーナー: Growth のエントリーポイントに関する事項ですが、ダウンストリームへの影響があります → 構築前に Fulfillment/Monetization（およびセールスのステークホルダー）に相談します。
• 行うこと: 提案を #s_fulfillmentに投稿 → Fulfillment/Monetization の PM をタグ付け → 影響について短時間の同期ミーティング → 決定を Issue に文書化し、その結果に基づいて進める。

Fulfillment/Monetization が全面的に所有する（継続的な保守 + サポート、ステップ 7）

CustomersDot のトライアルエンドポイントで障害が発生している／遅い／アラートが不足している。

• オーナー: Fulfillment/Monetization — Growth が作成したエントリーエンドポイントを含む トライアルコードベースの可観測性、パフォーマンス、インシデント、オンコール（ステップ 7）。エントリーレイヤーのコードにコントリビュートしても、サポート負担は Growth に移りません。
• 行うこと: Fulfillment/Monetization がインシデントと運用可能性の修正を所有し、計測／パフォーマンス業務のスコープを定める → Growth はエントリーポイントのコンテキストやアナリティクスのニーズを共有し、依頼に応じてエントリーレイヤーの詳細を支援 → Fulfillment が実装し、作成されたアラート／ダッシュボードを所有。

顧客から報告されたトライアルの問題（プロビジョニングされない、エンタイトルメントが誤っている、請求の問題）。

• オーナー: エントリーポイントを構築したチームに関係なく、CustomersDot のサポート DRI である Fulfillment/Monetization。
• 行うこと: Fulfillment/Monetization でトリアージ → 根本原因がエントリーレイヤー（ステップ 1～3）にある場合にのみ Growth を関与させる。

リソース

関連ドキュメント

• Provision チームのハンドブック - Provision チームのプロセスとプロジェクト管理
• Growth チームのハンドブック - Growth チームのプロセスと実験ガイドライン
• Growth の実験ガイドライン - Growth が実験を実施する方法
• Fulfillment のプロジェクト管理プロセス - Fulfillment の受付と計画
• Growth-Feature Product Owner のコラボレーションプロセス - Growth の一般的なコラボレーションモデル

技術リソース

• CustomersDot リポジトリ - CustomersDot の主要コードベース
• CustomersDot アーキテクチャドキュメント - 技術ドキュメント
• Provision Tracking System の監視 - PTS 監視ガイド

主な連絡先

• Growth Product Director: Growth チームのハンドブックを参照
• Growth Engineering Director: Growth チームのハンドブックを参照
• Trial Codebase Engineering Manager（Fulfillment/Monetization）: Provision チームのハンドブックを参照
• Fulfillment/Monetization Product Management: Provision のステーブルカウンターパートを参照

フィードバックとイテレーション

このフレームワークは生きたドキュメントです。私たちはコラボレーションから学びながら、これらのガイドラインをイテレーションして改善します。改善提案は、以下を通じて行えます。

1. gitlab-org/fulfillment-metaの Issue
2. #s_growthまたは #s_fulfillmentでのディスカッション
3. Growth または Fulfillment/Monetization のリーダーシップへの直接的なフィードバック

GitLab の イテレーションのバリューに従い、各チームがこのフレームワークを試し、フィードバックを集め、実際の経験に基づいて改善を提案することを推奨します。

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