Co-Createプログラム

概要

Co-Createプログラムは、新機能の開発、既存機能の拡張、バグ修正に必要なサポートを提供することにより、エンタープライズ顧客をGitLabのアクティブなコントリビューターへと変革します。ワークショップ、ペアプログラミング、継続的なガイダンスを通じて、顧客はGitLabエンジニアと直接協働し、GitLabコミュニティ全体に利益をもたらす意義のある改善にコントリビュートします。

私たちが提供するもの

1. テクニカルイネーブルメントワークショップ: GitLab Development Kit (GDK) のセットアップとGitLabのアーキテクチャ理解を支援するインタラクティブなセッション
2. オンサイトエンジニアリングサポート: 1名のGitLabエンジニアが1週間オンサイトでペアプログラミングを通じてコクリエーションを開始し、少なくとも1件のマージリクエスト完了を目指します
3. 法務サポート: 企業コントリビューター契約とオープンソースポリシーに関する支援
4. 継続的なメンタリング: Contributor Successチームによる長期的なコントリビューション成功のための専任サポート

プログラムの目標

1. 製品開発の加速: コミュニティコントリビューションは、社内開発単独を超えるスピードと規模で、顧客検証済みの機能を提供します
2. 顧客維持と拡大: 深い技術的エンゲージメントは、顧客組織内の新しいペルソナとの関係を開き、追加のユースケースと成長機会を明らかにする一方で、プラットフォームへの投資を通じて維持率を高めます
3. 競争上の差別化: 競合評価においてGitLabのシェアオブボイスを高めるエンタープライズの支持者を育み、従来のベンダー関係と比較して当社独自の協働モデルを実証します
4. マーケティングの増幅: 顧客アドボカシーキャンペーン向けの本物で参照可能な顧客の声と成功事例を生成します

プログラムのヘルスメトリクス

プログラムの成功は、カスタマージャーニー全体で複数のメトリクスを通じて追跡されます。詳細な追跡方法と現在のパフォーマンスについては、Co-Create成功メトリクス をご覧ください。

ターゲットオーディエンスと基準

適格性要件

1. PremiumまたはUltimateティアの顧客（CSMがリードするアカウント）

理想的な顧客プロファイル

組織特性

1. PremiumまたはUltimateティアの顧客（CSMがリードするアカウントが必要）
2. コントリビュートに時間を割く余力のあるエンジニアリングチーム
3. オープンソース経験またはOSPOを持つ組織（望ましいが必須ではない）
4. GitLabロードマップに沿った特定のプラットフォーム拡張を求める企業

エンジニアリングチーム属性

1. 学び、技術スキルを開発することに意欲的な好奇心駆動のエンジニア
2. オープンソースと協働開発への情熱
3. Ruby、Go、Vue.jsを学ぶ意欲（事前の経験は不要）
4. ペアプログラミングとコードレビュープロセスへのコミットメント

応募プロセス

顧客は Co-Createランディングページ から応募できます。応募は以下に基づいて評価されます:

1. コントリビューションの目標とGitLab製品の方向性の整合
2. 顧客チームの準備状況と可用性
3. 現在のGitLab利用状況とエンゲージメントレベル
4. 長期的なコントリビューション関係の可能性

構造とコンポーネント

プログラムの利点

顧客にとって:

1. メンテナンス負担ゼロ: GitLabがすべてのコントリビューションをメンテナンスし、チームを継続的な維持作業から解放します
2. 機能提供の加速: 直接コントリビュートする方が、従来の機能リクエストよりも高速です
3. プラットフォーム知識の向上: GitLabアーキテクチャへの深い理解により、社内利用が改善されます
4. コミュニティでの認知: コントリビューターはリリースノートとコミュニティで認知されます

GitLabにとって:

1. 製品開発の加速: 社内キャパシティを超えた顧客検証済みの機能
2. 顧客維持: 深い技術的エンゲージメントとプラットフォームへの投資の増加
3. 競争上の差別化: 従来のベンダーとは異なる独自の協働モデル
4. マーケティングの増幅: 本物の顧客の声と成功事例

フェーズ1: 適格性確認と計画 (2〜4週間)

アクティビティ

1. 応募レビューと顧客の適格性確認
2. アカウントチームと顧客ステークホルダーとの最初のディスカバリーコール
3. コントリビューション機会の特定
4. プロダクトマネージャーとのコントリビューションスコープの整合
5. 法務文書レビューと実行

成果物

1. 署名済みの企業コントリビューター契約
2. 定義されたコントリビューションスコープと目標
3. スケジュール済みのテクニカルイネーブルメントワークショップとオンサイト週の日程
4. アサインされたGitLabエンジニア

フェーズ2: テクニカルイネーブルメント (オンサイトの1〜2週間前)

アクティビティ

1. GDKセットアップワークショップ（バーチャル）
2. コントリビューション領域に関連するGitLabアーキテクチャの概要
3. コントリビューションワークフローとテストフレームワークの紹介
4. 環境検証とトラブルシューティング

成果物

1. 参加エンジニア向けの機能するGDKインストール
2. GitLab開発リソースとドキュメントへのアクセス
3. 継続的なコミュニケーション用のSlackチャンネル

フェーズ3: オンサイトコラボレーション (1週間)

アクティビティ

1. GitLabエンジニアとの毎日のペアプログラミングセッション
2. コード開発、テスト、ドキュメント作成
3. リアルタイムのコードレビューとフィードバック
4. マージリクエストの提出

成果物

1. テストとドキュメントを伴う完全なマージリクエストの提出

フェーズ4: フォローアップと長期的成功 (継続中)

アクティビティ

1. マージリクエストのレビューとイテレーション
2. Developer Relations Engineeringチームからの継続的なメンタリング - 詳細
3. 広範なGitLabコミュニティとの接続

成果物

1. マージされたコントリビューション
2. 顧客の声と成功事例
3. ケーススタディの作成（オプション）
4. リリースノートでの認知

役割と責任

Co-Createプログラムマネージャー

1. プログラム全体の調整と実行
2. 顧客コミュニケーションと期待管理
3. 進捗追跡とレポート
4. 継続的なプログラム改善
5. 問題解決とエスカレーション管理

DRI: Wesley De Vrient @wdevrient-ext

アカウントチーム (AE/SA/CSM/As)

1. 顧客ベース内でのCo-Create候補の特定
2. プログラムの紹介と初回会話のファシリテーション
3. 法務文書プロセスのサポート
4. エンゲージメント全体を通じた顧客関係の維持
5. Co-Create参加拡大の機会特定（追加チーム、後続のコントリビューション）
6. ビジネス拡大機会の特定（追加ユースケース、機能採用、シート増加）

Contributor Success

1. テクニカルイネーブルメントワークショップ（GDKセットアップ、アーキテクチャ概要）の実施
2. コントリビューターへの継続的なメンタリング
3. コントリビューターをGitLab Community Discordおよび関連コミュニティチャンネルに接続
4. Co-Create固有のイネーブルメント資料（ワークショップガイド、GDKセットアップドキュメント）の開発

テクニカルリード: Raimund Hook @stingrayza

GitLab Engineering

1. エンジニアリングの取り組みを精緻化し、コントリビューションスコープをProductと整合させる
2. オンサイトアサインメントに適したエンジニアの特定
3. オンサイト週中の深い技術的専門知識の提供
4. コードレビューの実施とフィードバックの提供
5. コントリビューションが品質基準を満たすことを確認
6. 知識移転とメンタリング
7. Co-Createプログラム用にキュレートされたIssueリストの維持

コーディネーター: Shekhar Patnaik @shekharpatnaik

Product Management

1. コントリビューションと製品ロードマップの整合性を検証
2. コントリビューションのための戦略的コンテキストを提供
3. Co-Createプログラム向けの適切なIssueをキュレート
4. Engineeringと連携して最終的なコントリビューションスコープを承認

リソースとサポート

アカウントチーム向け

1. Co-Createランディングページ
2. 応募フォーム
3. 顧客の成功事例
4. Co-Createピッチデッキ
5. 顧客向けドキュメント
6. プログラムトレーニング録画 (社内のみ)
7. 社内トレーニングデッキ (社内のみ)
8. Slack: #devrel-cocreate-program

顧客向け

1. GitLabへのコントリビュート
2. チュートリアル: GitLabへのコントリビューションを行う
3. GitLab Development Kit (GDK)
4. キュレートされたCo-Create Issues
5. GitLabのコントリビューターライセンス契約
6. コントリビューションFAQ
7. GitLab Community Discord

連絡先

サポートチャンネル

プログラム関連の質問とGitLab社内の問い合わせ:

• Slack: #devrel-cocreate-program - プログラムに関する質問、候補者特定、社内調整のための一般チャンネル

アクティブな顧客エンゲージメント:

• 専用Slackチャンネル: 各エンゲージメント用に #cocreate-initiative-CUSTOMERNAME 形式で作成されます
• 含まれるメンバー: 顧客チーム、アカウントチーム（CSM、SA、AE）、プログラムマネージャー、テクニカルリード、GitLabエンジニア

顧客とコミュニティ向け:

• メール: [email protected]
• コミュニティ: GitLab Community Discord

チームの連絡先

1. プログラムマネージャー: Ashley Sezer - @asezer
2. テクニカルリード: Raimund Hook - @stingrayza
3. マネージャー、Developer Relations Programs: Isa Huerga Ayza - @ihuerga
4. ディレクター、Contributor Success: Nick Veenhof - @nick_vh
5. エンジニアリングコーディネーター: Shekhar Patnaik - @shekharpatnaik
6. 一般的なお問い合わせ: [email protected]

プレイブック

プログラムマネージャー向け

プロジェクト管理と追跡

すべてのCo-Create顧客は、Co-Create GitLabプロジェクト を通じて管理されます。

プロジェクト構造

1. エピック: 顧客ごとに1つのエピックを作成し、関連するすべての作業をグループ化
2. Issue: 個々のIssueがCo-Createジャーニーの各フェーズを追跡:
   • 適格性確認と計画
   • テクニカルイネーブルメント
   • オンサイトコラボレーション
   • フォローアップと長期的成功

ステータスの維持

GitLabプロジェクトはエンゲージメントステータスの唯一の情報源として機能します。プログラムマネージャーは以下を実行する必要があります:

1. 新しい顧客がプログラムに参加したときにエピックを作成
2. フェーズ固有のIssueを作成し、顧客のエピックにリンク
3. エンゲージメントが各フェーズを進むにつれてIssueステータスを更新
4. ブロッカー、決定、主要なマイルストーンをIssueコメントに記録
5. フェーズが完了したらIssueをクローズ
6. 高レベルのエンゲージメント概要でエピックの説明を最新に保つ

注意: 正確なプログラムステータスを確保するため、週次同期とOKRレポートの前に必ずGitLabプロジェクトを更新してください。

エンゲージメント実行

ディスカバリーコールのアジェンダ

1. Co-Createの概要と顧客のメリット
2. 顧客の目標と希望するコントリビューション
3. 技術チームの準備状況評価
4. 法的要件の概要
5. 次のステップとタイムライン

プロジェクト計画チェックリスト

1. コントリビューションスコープに対するプロダクトマネージャーの承認
2. 必要に応じて企業コントリビューター契約を開始
3. GitLabエンジニアの特定とスケジュール調整
4. 顧客エンジニアの確認と可用性
5. オンサイト週の日程確定
6. 旅行と物流の手配
7. GDKイネーブルメントワークショップのスケジュール
8. 成功基準の定義
9. コミュニケーション計画の確立

オンサイト週の間

1. Slackを介したGitLabエンジニアとの毎日の同期
2. Slackチャンネルでの進捗監視
3. ブロッカーへの即時対応
4. 学びと成功の記録
5. 顧客の声用の引用やフィードバックの収集
6. オンサイト後のフォローアップ計画

エンゲージメント後

1. 2週間以内に顧客の声のインタビューをスケジュール
2. 継続的なサポートのために顧客をContributor Successに接続
3. Product Marketingとケーススタディの作業
4. 学んだ教訓を記録
5. 四半期ごとのフォローアップを計画
6. SFDCの顧客レコードを更新

OKR更新プロセス

Co-Createプログラムは、定期的な更新を必要とする四半期OKRを追跡します。このプロセスにより、プログラムに深く精通していないPMでもレポートを生成できます。

データの場所

OKRデータは Co-Createメトリクススプレッドシート で維持されます。このデータは自動パイプラインを介して更新されます。

更新パイプラインの実行

1. Contributor Success Toolboxパイプライン に移動
2. “Run pipeline” をクリック
3. 以下の変数を追加:
   • CO_CREATE_TRACKER = 1
   • PERIOD_START_DATE = YYYY-MM-DD (四半期の開始)
   • PERIOD_END_DATE = YYYY-MM-DD (現在の週末または四半期末)
   • DRY_RUN = 0
   • CI_PIPELINE_SOURCE = schedule
   • CO_CREATE_REPORT_SHEET_ID = 1JqhcR2PSpKG3lQRU3Y8llo0K71aWWTrJNFjsjzGQiM4
4. “Run pipeline” をクリックして完了を待つ（通常は数分）
5. “job succeeded” または “job failed” と表示されるまでステータスを監視

パイプラインの失敗のトラブルシューティング

1. パイプラインの “Jobs” タブにアクセス
2. 失敗したジョブを開いてエラー詳細を確認
3. 問題に対処してパイプラインを再実行

結果の使用

1. Co-Create結果ファイル を開くか更新
2. “Calculator” タブに移動
3. Source sheetフィールドをパイプラインで使用した日付（シート名に対応）で更新
4. 計算された結果を使用して以下を更新:
   • 四半期OKR進捗
   • 週末レポート

更新頻度

このパイプラインを四半期中は週次、またはレポート用に必要に応じて実行します。注意: 自動スケジューリングは実装待ちです。現在は手動実行が必要です。

CSM/AEから新しいCo-Createリードを受領した場合

このプレイブックは、アカウントチームメンバー（CSM、AE、またはSA）が潜在的なCo-Create機会を発見した際の、プログラムマネージャーの対応ワークフローを扱います。

トリガー

CSM、AE、またはSAが（通常はSlack経由で）Co-Createに興味のある顧客を伴って連絡してきます。

初期評価 (当日)

アカウントチームが提供した情報を確認します:

ヒント: リードはさまざまな状態で到着します。一部は特定のGitLab Issue（サポートエスカレーションなど）がすでに特定された状態で来ますが、他は探索的です。どちらも有効な出発点です。

アカウントチームへの返信

1営業日以内に以下で返信します:

1. 承認と熱意
2. 上記の評価からの明確化のための質問
3. 提案された次のステップ（通常は: “クイック同期をスケジュールしましょう” または “追跡用Issueを作成します”）

返信例:

“このリードを共有してくれてありがとう! [Customer] は素晴らしいフィットのようです。追跡用Issueを作成する前に、Ultimateであることと、彼らの側で誰が興味を表明したか確認できますか？アプローチについて合意するために短い電話をスケジュールできて嬉しいです。”

タイミングの考慮事項を確認

進める前に、アカウントチームに尋ねます:

• この顧客にアクティブなエスカレーションまたは敏感な状況がありますか？
• 新しいものをスケジュールする代わりに参加できる既存の定例コールはありますか？
• 注意すべき今後の更新または拡大の会話はありますか？

重要な理由: 既存の顧客コール（CSM週次同期など）に参加することは、別の会議をスケジュールするよりも効果的です。アクティブなエスカレーションがある場合、アカウントチームはまずそれを解決する必要があるかもしれません。

追跡用Issueの作成

基本情報が確認されたら、Co-Createプログラムプロジェクト に初期エンゲージメントIssueを作成します:

1. Company Name - Initial Engagement テンプレートを使用
2. 自分とCSMを割り当てる
3. 適切な顧客エピックに追加（必要に応じて Contributorエピック の下に作成）
4. Strategy Programs::Co-Create ラベルを適用
5. 次のステップを含むコメントでアカウントチームメンバーをタグ付け

進むべき道を決定

収集した情報に基づき、適切な次のステップを選択します:

ディスカバリーコールのスケジュール

ディスカバリーコールをスケジュールするためにアカウントチームと調整します。会議の構造についてはディスカバリーコールアジェンダを参照してください。

出席者:

• プログラムマネージャー（あなた）
• CSM（必須）
• SA（技術的深さが必要な場合）
• 顧客: エンジニアリングリード + マネージャーが理想的

専用Slackチャンネルはまだ作成しない - ディスカバリーコールで相互適合が確認されるまで待ちます。

追跡の更新

各インタラクションの後、初期エンゲージメントIssueを更新します:

• 完了したタスクをチェック
• メモを追加
• 必要に応じてステータスフィールドを更新

一般的なシナリオ

“顧客は今エスカレーションに対処している” タイミングを認識し、待つことを申し出て、2〜3週間後にフォローアップするリマインダーを設定します。メモ付きで追跡用Issueをオープンのままにします。

“顧客はロードマップにない機能を望んでいる” これも検討する価値があります - Co-Create Issueに対するProductの承認を得る プレイブックを参照してください。ディスカバリーコールは、コントリビューションが製品方向性と整合しているかを明確にするのに役立ちます。

“顧客はすでに応募フォーム経由で送信した” フォームの回答を確認し、アカウントチームが提供した情報とマージし、ディスカバリーコールのスケジュール設定に進みます。

Co-Create IssueへのProductの承認取得

このプレイブックは、顧客がキュレート済みのCo-Createリストにまだないissueに取り組みたい場合に、プロダクトマネージャーの承認を確保するプロセスを扱います。

このプレイブックを使用するタイミング

PMに連絡する前の前提条件

連絡する前にこの情報を収集します:

ヒント: 顧客が特定のIssueを持っていない場合、最初に GitLab Issues を検索してください。彼らのニーズに合致する既存のIssueがある可能性があります。

ステップ1: 適切なプロダクトマネージャーを特定

GitLab Product Categoriesページ を使用して、関連領域を担当するPMを見つけます。

クイック検索プロセス:

1. GitLab機能領域を特定（例: “Package Registry”、“CI/CD Pipelines”、“Security Scanning”）
2. Product Categories ページに移動
3. 一致するStage → Group → Categoryを見つける
4. そのカテゴリーに記載されたPMをメモ

どのPMが所有しているか不明な場合:

• Issueラベルでstage/groupのヒントを確認（例: ~devops::package、~group::pipeline authoring）
• #product Slackチャンネルで尋ねる
• ガイダンスのためにContributor Successチームに連絡

ステップ2: Issueの準備状況を評価

PMに連絡する前に、Issueの現在の状態を素早く評価します:

Co-Create対応可能

• ✅ 明確な問題ステートメント
• ✅ 定義されたスコープ/受け入れ基準
• ✅ マイルストーン割り当て済み（Backlogのみではない）
• ✅ 重みが見積もり済み
• ✅ オープンな技術的議論なし

まず作業が必要な可能性が高い

• ⚠️ Issueが “問題検証” または “ソリューション検証” フェーズにある
• ⚠️ 複数の競合する技術的アプローチが議論されている
• ⚠️ マイルストーンが割り当てられていない
• ⚠️ 最近の重大なスコープ変更
• ⚠️ 他のIssueによってブロックされている

Issueの準備ができていない場合: 顧客が待てるかどうか検討するか、IssueをCo-Create対応にするために何が必要かをPMと議論します。

ステップ3: PMをループに入れる

会話を行う場所

別のスレッドを開始するのではなく、既存の会話にPMを参加させます:

これにより、アカウントチームにコンテキストが見えるようになり、断片化された会話を回避できます。

PMをタグ付けする際に含めるべきこと

• Issueへのリンク
• 顧客のユースケースに関する簡潔なコンテキスト
• 顧客がこの特定のIssueに取り組みたい理由
• タイムラインの考慮事項

PMが評価すること

連絡すると、PMは以下を評価します:

ステップ4: 応答の処理

PMが “はい” と言った場合

1. 感謝し、PMが ~co-create ラベルを追加するか（または自分が追加すべきか）を確認
2. オンサイトエンジニアに特に注意することがないか尋ねる
3. PM承認日とメモで追跡用Issueを更新
4. 顧客の適格性確認に進む

PMが “はい、ただしまず作業が必要” と言った場合

一般的なシナリオと対応:

尋ねるべき重要な質問: “これがCo-Create対応になるために何が起こる必要があり、現実的なタイムラインは何ですか？”

PMが “ロードマップと整合しない” と言った場合

これは常に “いいえ” を意味するわけではありません - さらに探りましょう:

1. 詳細を尋ねる: “なぜか理解できますか？アプローチ、タイミング、または機能自体ですか？”

2. 代替を探る: “類似のニーズに対応し、よりフィットする関連Issueはありますか？”

3. 柔軟性を確認: “顧客がアプローチを調整する意欲がある場合、状況が変わりますか？”

確固たる否定の場合:

• PMの時間に感謝
• フィードバックをアカウントチームに戻す
• 顧客のための代替コントリビューション機会を特定するのに役立つ

PMが “このIssueは時期尚早” と言った場合

“問題検証” にあるIssueや明確な技術的方向性のないIssueは、Co-Createの準備ができていません。

尋ねるべき質問:

• 開発の準備ができるのは、どのマイルストーンを期待しますか？
• 顧客のユースケースが明確化に役立つことはありますか？
• それまでの間に機能する可能性のある関連Issueはありますか？

判断ポイント: タイムラインが3か月以上の場合、顧客が待っている間に別のコントリビューション機会を検討することを推奨します。

PMが応答しない (3営業日以上)

1. 丁寧なフォローアップを送信 同じチャンネルで

2. 代替チャンネルを試す:

   • GitLab Issueでタグ付け
   • チームのSlackチャンネルで尋ねる
   • エンジニアリングマネージャーに連絡

3. 必要に応じてエスカレーション (下記のエスカレーションセクションを参照)

ステップ5: エスカレーションパス

エスカレーションは慎重に、以下の場合のみ使用します:

• PMが複数回の試行後も応答しない（5営業日以上）
• PMが拒否するが、理由がGitLabのオープンソース価値観と矛盾しているように思われる
• 顧客機会が時間的に敏感で戦略的

エスカレーションステップ

1. 最初に: グループの関連エンジニアリングマネージャーに連絡
2. 次に: グループプロダクトマネージャー（PMのマネージャー）に連絡
3. 第三に: Contributor Successリーダーシップのガイダンスのために #cocreate-initiative で提起

エスカレーションすべきでない場合

• PMが製品方向性に基づいて合理的な “いいえ” を出した
• Issueが真にコントリビューションの準備ができていない
• タイムラインがうまく合わない
• より良い代替Issueがある

ステップ6: 結果を記録

PMの応答と会話からの関連コンテキストで追跡用Issueを更新します。これにより、アカウントチームと後でエンゲージメントを引き継ぐ人が、議論および決定された内容を可視化できます。

クイックリファレンス: 一般的なシナリオ

顧客が断る、または適格でない - 機会のクローズ

このプレイブックは、Co-Create機会が進行しない場合に、それを丁寧にクローズする方法と、将来のエンゲージメントの扉を開いておく方法を扱います。

このプレイブックを使用するタイミング

クローズの一般的な理由

顧客側の理由

GitLab側の理由

相互の理由

ステップ1: クローズする時間であることを確認

クローズする前に、以下を確実にしてください:

• 沈黙したら2週間以上にわたり少なくとも2回フォローアップした
• 第一希望のIssueがうまくいかなかった場合、代替を探った
• クローズが理にかなっていることをアカウントチーム（CSM/AE）と確認
• “後で再検討” 日があるか、ハードクローズかを確認

クローズを急がない - 一部の機会はもっと時間が必要です。しかし、無期限に放置することもしないでください。

ステップ2: クローズタイプを決定

ステップ3: 会話を丁寧にクローズ

顧客が明示的に断った場合

彼らの決定を認め、扉を開いておきます。チャンネルまたはCSMへの簡潔なメッセージで十分です - 検討してくれたことに感謝し、いつでも再検討できることを伝えます。

顧客が沈黙した場合

アカウントチームを介して最終チェックインを送信します。それでも応答がない場合は、休ませても構いません。正式な “これをクローズします” メッセージは不要です - それは押し付けがましく感じられる可能性があります。

適格でない場合

適切にリダイレクトします:

• 独立してコントリビュートしたい場合は 標準コントリビューションリソース を案内
• 状況が変わった場合（ティアアップグレード、アカウント成長など）に再度連絡できることを伝える

AEまたは他のチームメンバーがリードを発見した場合、結果を彼らに共有します。

ステップ4: 適切な場所で代替を提示

すべてのクローズが最終的である必要はありません。検討:

無理強いしない - 代替に興味がない場合、それで大丈夫です。

ステップ5: 追跡の更新

クローズを反映するために追跡用Issueを更新します:

• クローズの理由を記録
• ハードクローズか後で再検討かを示す
• 後で再検討の場合、フォローアップ時期をメモ
• Issueをクローズ（または適切なステータスに移動）

顧客Slackチャンネルが作成されていた場合、アーカイブするかどうかをアカウントチームと調整します。

ステップ6: アカウントチームとのデブリーフ

CSM/AEとのクイック同期で:

• 顧客が断った理由について彼らが提供したフィードバックを共有
• 興味を持つ可能性のある顧客の他のチームがいるか議論
• 再検討するか/いつ再検討するかについて合意

これは正式な会議である必要はありません - 通常はSlackスレッドで十分です。

再エンゲージメントトリガー

クローズした機会は再オープンできます。以下に注目してください:

してはいけないこと

• 橋を燃やさない - 今日の “いいえ” は後日 “はい” になる可能性があります
• クローズを過剰に伝えない - シンプルな更新で十分で、正式なクロージャーメールは不要
• 個人的に受け取らない - 多くの要因が制御外
• 宙ぶらりんにしない - 死んでいるなら、パイプラインが現実を反映するようにクローズする

アカウントチーム向け: 候補者の特定

ステップ1: 顧客のフィットを評価

これらのシグナルを探します:

1. 顧客が複数のIssueまたは機能リクエストを作成している
2. エンジニアリングチームがGitLabの高度な機能を積極的に使用している
3. 組織がオープンソース参加履歴を持つ
4. 技術リーダーがGitLabのより深い知識への興味を表明
5. 最近のGitLab使用量の成長または拡大の議論

ステップ2: 初期紹介

この会話フレームワークを使用します:

1. Co-Createを独自のGitLabパートナーシップ機会として紹介
2. 関連する成功事例を共有（Thales、Scania、Kitwareなど）
3. 価値を説明: “あなたのエンジニアが機能をコントリビュートし、GitLabが永久にそれを維持します”
4. 機能リクエストプロセスと比較した提供の加速を強調
5. 興味を測り、技術的ステークホルダーを特定

ステップ3: 接続のファシリテーション

1. 顧客を 応募フォーム に案内
2. Slackチャンネルを作成: #cocreate-initiative-CUSTOMERNAME
3. 招待: CSM、SA、AE、@wdevrient-ext、@stingrayza
4. 顧客ステークホルダーとのディスカバリーコールをスケジュール

Engineering向け: オンサイトベストプラクティス

Co-Createオンサイトエンジニアガイド を参照してください。

FAQ

アカウントチーム向け

Q: どの顧客が適格ですか？

A: CSMサポート付きのPremiumまたはUltimateティア顧客。理想的な候補者は、エンジニアリングキャパシティ、技術的好奇心、プラットフォーム拡張への関心を持ちます。事前のオープンソース経験は有益ですが必須ではありません。

Q: 顧客がコントリビュートしたいがPremium/Ultimateでない場合は？

A: 標準のコミュニティコントリビューションパスを通じてコントリビュートできます。Co-Createプログラムのホワイトグローブサービス（オンサイトエンジニア、専用ワークショップ）はPremium/Ultimate顧客のために予約されています。

Q: 顧客にこれが彼らの時間に値することをどう納得させますか？

A: これらのポイントを共有してください:

1. 研究により、コントリビュートする企業は最大2倍の生産性向上を達成することが示されています
2. GitLabは彼らのコントリビューションを永久に維持します—継続的なメンテナンス負担はゼロ
3. 従来の機能リクエストプロセスより高速
4. 内部GitLab使用を改善する深いプラットフォーム専門知識を構築

Q: 私の顧客の時間コミットメントは？

A: 通常、1〜3名のエンジニアで1週間オンサイト、加えて事前のGDKセットアップワークショップに2〜3時間。エンゲージメント後の時間はマージリクエストフィードバックサイクルにより異なります。

Q: 顧客は望む任意のIssueに取り組めますか？

A: コントリビューションはGitLabの製品方向性と整合する必要があります。事前承認されたIssueの キュレートされたリスト を維持しています。カスタムIssueにはプロダクトマネージャーの承認が必要です。

Q: 法務がコントリビューションを懸念している場合は？

A: 企業コントリビューター向け互換性ガイド があり、法務専門家との相談を手配できます。企業コントリビューター契約は、オープンソースコントリビューションを持つテック企業全体で標準です。

Q: これは機能リクエストとどう異なりますか？

A: 機能リクエストは不確定なタイムラインで製品の優先順位付けプロセスに入ります。Co-Createにより顧客は必要なものをすぐに開発でき、GitLabが長期的にそれを維持します。

顧客向け

Q: RubyやGoの経験が必要ですか？

A: 必要ありません。GitLabエンジニアがペアプログラミングサポートを提供し、コーディング中に教えます。任意のプログラミング言語の事前経験で十分です。

Q: 私たちがコントリビュートするコードは誰が所有しますか？

A: https://about.gitlab.com/community/contribute/dco-cla/#do-i-retain-rights-in-my-contributions を参照してください

Q: コントリビューションが受け入れられない場合は？

A: プロダクトマネージャー承認はオンサイト週前に行われ、整合性を確保します。開発中、GitLabエンジニアが品質基準を満たすようにガイドします。このレベルのサポートで拒否は非常に稀です。

Q: 複数の領域にコントリビュートできますか？

A: はい！リピート顧客はしばしばコントリビューションを拡大します。初回エンゲージメントは通常、自信を構築しプロセスを確立するため1つの領域に焦点を当てます。

Q: 特定のネットワーク設定が必要、またはローカルでGDKを実行できない場合は？

A: 解決策を見つけるためにお客様と協力します。GitLab Workspacesはネットワーク制限を克服するのに役立ちます。イネーブルメントワークショップはオンサイト週前に環境の課題に対処します。

Q: 私たちのコントリビューションはどのくらい早くGitLabリリースに入りますか？

A: タイムラインはコントリビューションの複雑さとレビューサイクルにより異なります。コントリビューションは常にマージリクエスト承認後の次のリリースで出荷されます。

Q: 参加を公表できますか？

A: はい！奨励しています。共同発表、ブログ投稿、カンファレンス発表をサポートできます。多くの顧客がCo-Createを彼らのオープンソースプログラムオフィスイニシアチブの一部として使用します。

GitLabチームメンバー向け

Q: オンサイトエンジニアはどのように選ばれますか？

A: エンジニアリングリーダーシップが、関連するコードベース領域の専門知識、可用性、メンタリングへの関心を持つエンジニアを特定します。エンジニアは通常、これらのエンゲージメントにボランティアで参加します。

Q: コントリビューションが大幅なアーキテクチャ変更を必要とする場合は？

A: これらは適格性確認フェーズで特定する必要があります。プロダクトマネージャーがスコープを評価し、大規模なコントリビューションを小さなイテレーションに分割するか、よりシンプルな関連Issueから始めることを推奨する場合があります。

Q: 計画された作業と競合するコントリビューションをどう扱いますか？

A: コミットメント前にプロダクトマネージャーの整合が行われます。競合が発生した場合、競合を生じない代替コントリビューション機会を見つけるため顧客と協力します。

Q: 顧客がオンサイト週後もコントリビューションを継続したい場合は？

A: 素晴らしい！継続的なメンタリングのためContributor Successチームと接続します。多くの顧客が長期的なコントリビューターになります。

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