Co-Create プログラム

概要

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

提供する内容

1. テクニカルイネーブルメントワークショップ: 顧客が GitLab Development Kit（GDK）をセットアップし、GitLab のアーキテクチャを理解できるようサポートするインタラクティブなセッション
2. オンサイトエンジニアリングサポート: 1 名の GitLab エンジニアが 1 週間オンサイトに常駐し、ペアプログラミングを通じて共創をキックオフ。少なくとも 1 件のマージリクエスト完了が目標
3. 法務サポート: Corporate Contributor Agreement やオープンソースポリシーへの対応支援
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 のアーキテクチャを深く理解することで、社内での GitLab 活用が向上します
4. コミュニティでの認知: コントリビューターはリリースノートとコミュニティで称賛されます

GitLab 向け:

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

フェーズ 1: 適格性評価と計画（2〜4 週間）

活動

1. 申し込みのレビューと顧客の適格性評価
2. アカウントチームと顧客ステークホルダーとの初回ディスカバリーコール
3. 貢献機会の特定
4. プロダクトマネージャーとの貢献スコープのアラインメント
5. 法務文書のレビューと締結

成果物

1. 締結された Corporate Contributor Agreement
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. Issue の解決とエスカレーション管理

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 セットアップドキュメント）を開発

Technical Lead: Raimund Hook @stingrayza

GitLab Engineering

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

Coordinator: 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 Issue
5. GitLab の Corporate Contributor Agreement
6. 貢献に関する FAQ
7. GitLab Community Discord

連絡先

サポートチャンネル

プログラムに関する質問および GitLab 社内の問い合わせ用:

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

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

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

顧客およびコミュニティ向け:

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

チームの連絡先

1. プログラムマネージャー: Wesley De Vrient - @wdevrient-ext
2. Technical Lead: Raimund Hook - @stingrayza
3. マネージャー、Developer Relations プログラム: Isa Huerga Ayza - @ihuerga
4. ディレクター、Contributor Success: Nick Veenhof - @nick_vh
5. Engineering Coordinator: Shekhar Patnaik - @shekharpatnaik
6. 一般的な問い合わせ: [email protected]

プレイブック

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

プロジェクト管理とトラッキング

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

プロジェクト構造

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

ステータスの維持

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

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

注: プログラムステータスを正確に保つため、ウィークリーシンクや OKR レポーティングの前には必ず GitLab プロジェクトを更新してください。

エンゲージメントの実行

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

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

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

1. プロダクトマネージャーが貢献スコープを承認
2. 必要に応じて Corporate Contributor Agreement を開始
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 Pipelines に移動
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. Issue に対処してパイプラインを再実行

結果の使用

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 を作成します」）

返答例:

「ご紹介ありがとうございます！ [顧客] は良いフィット感がありそうですね。トラッキング Issue を作る前に、Ultimate であることと、顧客側で誰が興味を持っているかを確認できますか？アプローチについてアラインメントを取るために短い通話をスケジュールしてもよいです。」

タイミングを考慮した確認

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

• この顧客に関するアクティブなエスカレーションや繊細な状況がありますか？
• 別途新しいミーティングをスケジュールするのではなく参加できる、既存の定例コールはありますか？
• 認識しておくべき近々の更新や拡大の話はありますか？

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

トラッキング Issue の作成

基本情報が確認できたら、Co-Create プログラムプロジェクト で Initial Engagement Issue を作成します。

1. Company Name - Initial Engagement テンプレートを使用
2. 自分と CSM をアサイン
3. 適切な顧客エピックに追加（必要であれば Contributor エピック の下に作成）
4. Strategy Programs::Co-Create ラベルを適用
5. コメントでアカウントチームメンバーをタグし、次のステップを共有

進める道筋を決定

集めた情報に基づいて、適切な次のステップを選びます。

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

アカウントチームと連携してディスカバリーコールをスケジュールします。ミーティング構造については「ディスカバリーコールのアジェンダ」を参照してください。

参加者:

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

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

トラッキングの更新

各やり取りの後、Initial Engagement 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 のラベルでステージ／グループのヒントを確認（例: ~devops::package、~group::pipeline authoring）
• #product Slack チャンネルで尋ねる
• ガイダンスのために Contributor Success チームに連絡

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

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

Co-Create に対応可能

• ✅ 明確な問題ステートメント
• ✅ 定義されたスコープ／受け入れ基準
• ✅ アサインされたマイルストーン（Backlog だけではない）
• ✅ 重みが見積もられている
• ✅ オープンな技術的議論がない

先に作業が必要な可能性

• ⚠️ Issue が「problem validation」または「solution validation」フェーズにある
• ⚠️ 競合する複数の技術的アプローチが議論されている
• ⚠️ マイルストーンがアサインされていない
• ⚠️ 最近スコープに大きな変更があった
• ⚠️ 他の Issue にブロックされている

Issue の準備が整っていない場合: 顧客が待てるか検討するか、Issue を Co-Create に対応可能にするために何が必要か PM と議論してください。

ステップ 3: PM を巻き込む

会話の場所

別スレッドを始めるのではなく、既存の会話に PM を巻き込みます。

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

PM をタグするときに含める内容

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

PM が評価する内容

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

ステップ 4: 返答への対応

PM が「はい」と言った場合

1. 感謝を伝え、~co-create ラベルを追加するか確認（または自分で追加するか尋ねる）
2. オンサイトエンジニアに伝えるべき特記事項があるか尋ねる
3. PM 承認日と注意事項でトラッキング Issue を更新
4. 顧客の適格性評価に進む

PM が「はい、ただし先に作業が必要」と言った場合

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

質問する重要な点: 「これが Co-Create 対応可能になるには何が必要で、現実的なタイムラインはどのくらいですか？」

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

これは必ずしも「いいえ」を意味するわけではありません - さらに探りましょう。

1. 具体性を求める: 「理由を理解する助けになりますか？アプローチですか、タイミングですか、それとも機能そのものですか？」

2. 代替案を探る: 「同じようなニーズに対応し、より適合する関連 Issue はありますか？」

3. 柔軟性を確認する: 「顧客がアプローチを調整する用意があれば、状況は変わりますか？」

確固たる「いいえ」の場合:

• PM の時間に感謝する
• フィードバックを持ってアカウントチームに戻る
• 顧客向けに代替の貢献機会を特定する助けをする

PM が「この Issue は早すぎる」と言った場合

「problem validation」段階にあるか、明確な技術方向性のない 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）と、クローズが理にかなうことを確認した
• 「revisit later」の日付があるか、確実なクローズかを確認した

クローズを急がない - 機会によっては、もっと時間が必要なだけのこともあります。ただし、無期限に放置しないようにしてください。

ステップ 2: クローズタイプの判定

ステップ 3: 会話を優雅にクローズ

顧客が明示的に辞退した場合

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

顧客が静かになった場合

アカウントチームを通じて最終チェックインを送ります。それでも反応がない場合は、そのままにしてかまいません。「クローズします」という正式なメッセージは不要 - 押し付けがましく感じることがあります。

資格を満たさない場合

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

• 独立して貢献したい場合は 標準の貢献リソース を案内
• 状況が変われば（ティアアップグレード、アカウント拡大など）、いつでも連絡してよいことを伝える

AE や他のチームメンバーがリードを浮上させた場合は、結果を彼らにも共有します。

ステップ 4: 適切な場合は代替案を提示

すべてのクローズが最終である必要はありません。次を検討してください。

強制しないこと - 代替案に興味がなければ、それでよいです。

ステップ 5: トラッキングの更新

クローズを反映するためにトラッキング Issue を更新します。

• クローズの理由を記録
• ハードクローズか revisit-later かを示す
• revisit-later の場合、いつフォローアップするかを記録
• 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. 顧客ステークホルダーとのディスカバリーコールをスケジュール

エンジニアリング向け: オンサイトのベストプラクティス

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: Corporate Contributors 向け互換性ガイド があり、当社の法務専門家との相談を手配できます。Corporate Contributor Agreement は、オープンソース貢献を行うテック企業全体で標準的なものです。

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.