Co-Create プログラム

概要

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

私たちが提供するもの

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

プログラムの目標

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: Isa Huerga @ihuerga

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

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

Co-Create and Community Engineering

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: #co-create-and-community-engineering

顧客向け

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

連絡先

サポートチャンネル

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

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

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

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

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

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

チームの連絡先

1. Co-Create ストラテジーリード： Isa Huerga Ayza - @ihuerga
2. テクニカルリード： Raimund Hook - @stingrayza
3. Demand Generation and Advocacy： Rachel Lurie - @rlurie
4. フィールドリード： Jess Perry - @jperry
5. 一般的なお問い合わせ： [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. 継続的なサポートのために顧客を Co-Create and Community Engineering に接続
3. Product Marketing とケーススタディの作業
4. 学んだ教訓を記録
5. 四半期ごとのフォローアップを計画
6. SFDC の顧客レコードを更新

OKR 更新プロセス

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

データの場所

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

更新パイプラインの実行

1. DevRel Engineering 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 チャンネルで尋ねる
• ガイダンスのために Co-Create and Community Engineering チームに連絡

ステップ 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. 第三に： Co-Create and Community Engineering リーダーシップのガイダンスのために #co-create-and-community-engineering で提起

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

• 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-CUSTOMERNAME
3. 招待: CSM、SA、AE、@ihuerga、@stingrayza
4. 顧客ステークホルダーとのディスカバリーコールをスケジュール

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

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

FAQ

ディスカバリーコールでよくある質問

このセクションでは、初回の会話で見込み顧客から最もよく寄せられる質問をまとめています。ディスカバリーコールの準備に使用し、一貫したメッセージングを確保してください。

プログラムの基本

Q: Co-Create では具体的に何を行いますか？

A: GitLab は、GitLab へのコントリビューションを対象に、顧客チームとペアプログラミングを行うためにエンジニア 1 名を 1 週間オンサイトへ派遣します。その前に、GitLab Development Kit (GDK)をセットアップし、アーキテクチャを説明するバーチャルワークショップを実施します。その後、Co-Create and Community Engineering チームがマージリクエストのレビュー進行中に継続的なメンタリングを提供します。

Q: これはコンサルティング契約ですか？費用はかかりますか？

A: いいえ。コントリビューションは有償の作業ではなく、オープンソースです。GitLab はオープンソースコラボレーションへのコミットメントの一環として、追加費用なしでエンジニアとサポートを提供します。これはプロフェッショナルサービス契約ではありません。

Q: 機能リクエストを出すことと、どう違いますか？

A: 機能リクエストは、タイムラインが不確実な製品の優先順位付けに入ります。Co-Create では、GitLab のエンジニアのガイドを受けながら、チームが今必要なものを開発できます。GitLab はコントリビューションを長期にわたって維持するため、新しいリリースが出てもチームが保守する必要はありません。

Q: 何か条件があるのですか？なぜ GitLab はこれを行うのですか？

A: GitLab はオープンコア企業であり、コミュニティからのコントリビューションは製品を構築する方法の一部です。顧客のコントリビューションは、実際のユースケースで検証された機能によってロードマップを加速させます。また、エンジニアリングレベルでプラットフォームを理解している顧客との、より深い関係を築きます。これは一方的な取り決めではなく、真のパートナーシップです。

スコープと Issue の選定

Q: 取り組みたいものに何でも取り組めますか？

A: コントリビューションは GitLab の製品の方向性と整合する必要があります。事前承認済み Issue のキュレートされたリストを管理していますが、特定の案がある場合は、担当の Product Manager と適合性を評価します。この承認はオンサイトを確約する前に行われるため、想定外のことはありません。

Q: 関心のある内容がキュレートされたリストにない場合はどうなりますか？

A: これはよくあることです。ディスカバリーコールに Issue またはアイデアを持ち込み、担当の Product Manager と整合性を評価します。特定の Issue が適合しない場合でも、チームに価値をもたらす関連項目を一緒に見つけます。

Q: 1 週間で現実的にどのようなコントリビューションができますか？

A: 一般的なエンゲージメントでは、少なくとも 1 件のマージリクエストが作成されます。過去の例は、UI の改善（Thales は数時間で空のプロジェクトページを簡素化）から、より複雑な機能の作業（Scania は複数のイテレーションを通じて Conan パッケージレジストリのサポートを前進）まで幅広くあります。生産的な 1 週間となるよう、計画段階で適切にスコープを設定します。

Q: 新しい機能を開発する代わりに、長く困っているバグを修正したい場合はどうなりますか？

A: バグ修正は Co-Create に非常によく適合します。Issue を直接経験している顧客は、多くの場合、それを解決するのに最適な人です。引き続き Product Manager との整合は必要ですが、PM は通常、顧客主導のバグ修正に非常に前向きです。

チームと時間のコミットメント

Q: 何人のエンジニアを専任にする必要がありますか？

A: オンサイトの 1 週間には 4 〜 8 名のエンジニアを推奨しますが、より小規模なグループでも成功したエンゲージメントがあります。また、事前に GDK セットアップワークショップのための 2 〜 3 時間が必要です。重要なのは、参加するエンジニアがオンサイトの週に専用の時間を確保することであり、通常のスプリント作業と競合させないでください。

Q: エンジニアには Ruby または Go の経験が必要ですか？

A: いいえ。GitLab のエンジニアがチームとペアプログラミングを行い、作業を進めながら教えます。どのプログラミング言語でも経験があれば十分です。Thales、Scania、その他の組織の過去の参加者の中には Ruby の経験がなくても、成功裏にコントリビュートした人が複数います。

Q: エンジニアを通常の仕事から 1 週間外すことを、どう正当化できますか？

A: エンジニアリングリーダーシップに響く観点をいくつか示します。

1. Harvard Business School の研究では、コントリビュートする企業は、使用するオープンソースソフトウェアから最大 2 倍の生産的価値を得ることが示されています
2. GitLab はコントリビュートしたものすべてを維持します。継続的な保守負担がゼロになるため、かなりの社内エンジニアリング時間を相殺します
3. スキル移転は即時かつ実践的です。Scania のあるエンジニアは、Co-Create を通じて得た Ruby の知識を、数週間後に社内のアップグレード Issue のトラブルシューティングに活用しました
4. 直接コントリビューションは、従来の機能リクエストプロセスよりも高速です
5. エンジニアは、組織全体での GitLab の使用方法を改善する、プラットフォームに関する深い知識を得ます

Q: 最初の会話からオンサイトまでの全体的なタイムラインはどのくらいですか？

A: 通常、エンドツーエンドで 6 〜 8 週間です。適格性確認と計画（PM の承認と法務を含む）に 2 〜 4 週間、イネーブルメントワークショップに 1 〜 2 週間、その後にオンサイトの 1 週間を要します。主な変数は、法務とスケジュール調整が顧客側でどれだけ早く整うかです。

法務と IP

Q: 当社の法務チームがオープンソースへのコントリビューションに懸念を持っています。

A: これは、特に規制産業では非常によくあることです。技術業界全体で使用されている標準の企業コントリビューター契約に加えて、ライセンス互換性ガイドがあります。詳細を法務担当者に説明するため、当社の法務専門家との通話を手配できます。金融サービス、防衛、自動車の組織はいずれもこのプロセスを完了しています。

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

A: コントリビューターはコントリビューションに関する権利を保持します。詳細は DCO/CLA FAQと企業コントリビューター契約に記載されています。

Q: 社内 IP はどうなりますか？コントリビューションで専有情報が公開される可能性はありますか？

A: コントリビューションは GitLab のコードベースを対象とします。顧客の社内システムを共有するのではなく、GitLab を改善します。作業する Issue は、エンゲージメントが始まる前に定義・合意されます。エンジニアは本番インスタンスではなく、GDK 環境内で GitLab のコードに取り組みます。

技術環境

Q: 環境にネットワーク制限がある場合や、ローカルで GDK を実行できない場合はどうなりますか？

A: オンサイトの週の前に行うイネーブルメントワークショップで対応します。チームに最も適した解決策を見つけるために協力します。

Q: 顧客側ではどのような技術的セットアップが必要ですか？

A: 参加するエンジニアには、GDK を実行できる開発マシン（Linux、macOS、または WSL2 を備えた Windows）が必要です。オンサイトの 1 〜 2 週間前に行うイネーブルメントワークショップで、完全なセットアップを説明します。ローカルインストールに企業の制限がある場合は、GitLab Workspaces やコンテナ化された GDK セットアップなどの代替案を検討します。

オンサイト後

Q: 1 週間が終わった後はどうなりますか？

A: マージリクエストは GitLab の標準レビュー工程に進みます。Co-Create and Community Engineering チームは、そのサイクルを通じて継続的なサポートを提供します。その後、多くの顧客は独自にコントリビュートを継続します。より広いコミュニティのサポートのため、チームを GitLab Community Discordにもつなげます。

Q: 構築したものを誰が維持しますか？

A: GitLab が維持します。これは中核的なメリットの 1 つです。コントリビューションは GitLab リリースに含まれ、GitLab のエンジニアリングチームが将来のすべての保守を担います。リリース変更が発生しても、チームは保守から解放されます。

Q: 再び参加して、さらに取り組むことはできますか？

A: もちろんです。再参加する顧客は、多くの場合、新しいチームや機能領域へと拡大します。Scania は小さな変更から始め、時間をかけて大規模なパッケージレジストリ作業へと進みました。また、複数チームに参加を拡大したい大規模組織には、ハッカソン形式も検討します。

Q: コントリビューションはどれくらい早く GitLab リリースに含まれますか？

A: マージリクエストが承認・マージされると、次の GitLab リリースに含まれます。GitLab は毎月リリースするため、比較的迅速に反映されます。オンサイトの週から本番環境まで 2 か月未満だったコントリビューションもあります。

参加の公表

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

A: はい、推奨しています。共同ブログ投稿、カンファレンス発表、事例研究をサポートできます。多くの顧客は、Co-Create への参加をオープンソースプログラムオフィスの取り組みの一部として活用しています。顧客側で必要な承認プロセスについても協力します。

Q: これを行った他社の例はありますか？

A: はい。公開されている例には次のものがあります。

1. Thales: GitLab の空のプロジェクト UI を改善し、3,000 万人のユーザーに向けた SSH/HTTPS 設定を簡素化
2. Scania: Conan パッケージレジストリのサポートを前進させ、17.8 リリースで GitLab MVP として認定
3. Kitware: ハイパフォーマンスコンピューティングのユースケース向けに OAuth2 デバイス認可グラントフローを追加

ディスカバリーコール中またはその後に、詳細と Co-Create ブログ記事を共有できます。

アカウントチーム向け

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: 素晴らしい！継続的なメンタリングのため Co-Create and Community Engineering チームと接続します。多くの顧客が長期的なコントリビューターになります。

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