Co-Create オンサイトエンジニアガイド
概要
Co-Create プログラムでは、顧客が GitLab エンジニアと直接協力し、プラットフォームに機能、修正、改良を貢献できるようにします。これは GitLab がスポンサーするプログラムであり、有償のコンサルティングサービスではありません。オンサイトエンジニアとして、あなたは 1 週間、顧客のエンジニアと密に協力して、彼らの貢献の旅をキックオフし、長期的な協働パターンを確立します。
このガイドは、過去の Co-Create エンジニアの経験に基づき、オンサイトエンゲージメントを成功させるための実践的なアドバイスを提供します。
オンサイト前の準備
技術的な準備
- 貢献スコープを確認する: 取り組む具体的な Issue や機能を理解します
- 顧客のコンテキストに精通する: 彼らの GitLab 利用状況、技術スタック、ビジネス目標をレビューします。利用可能であれば、顧客のプロジェクトリポジトリへのアクセスをリクエストします
- 開発環境を準備する: GDK を素早くセットアップでき、GitLab の開発ワークフローをデモできることを確認します。制限された環境向けに、GDK の代替手段（GDK in a Box、クラウド VM）にも精通しておきます
- 技術的なスパイクを実施する: Issue の複雑さに応じて、自分で小さなスパイクを行い、フォーカスされた方向性を提供できるよう実装計画を準備します
- 潜在的なブロッカーを特定する: 発生しうるセキュリティ、アーキテクチャ、環境の制約を考慮します
- 顧客チームのバックグラウンドを理解する: 彼らがどのプログラミング言語に慣れているか（Ruby/Rails、Go、Java など）を学び、アプローチを調整します
コミュニケーションの準備
- オンボーディングセッションに参加する: オンサイト前の顧客オンボーディングに参加し、自己紹介をして、チームを理解します
- 実用的なコミュニケーションを確立する: 入館、道順、スケジュール変更などの当日の調整のため、顧客チームに合うコミュニケーションチャンネル（WhatsApp グループ、Signal、電話番号など）を設定します
- 旅程を共有する: スムーズな到着と調整のため、連絡先情報と移動の詳細を事前に交換します
- セットアップ要件を早めに確認する: 顧客チームに GDK セットアップ（1〜2 日かかることもある）に十分な時間があることを確認します。オンサイト前の環境準備のための明確な期限を設定します
- コミュニティフォークを作成する: 貢献に必要なコミュニティフォークを事前に作成しておきます
- 期待値をすり合わせる: 週のアジェンダ、目標、成功基準を確認します
- チームのダイナミクスを理解する: 顧客エンジニアの経験レベル、役割、モチベーションのレベルを把握します
オンサイトのベストプラクティス
1 日目: 基礎づくり
- 関係構築から始める: 自己紹介と動機の理解に時間を取ります
- 明確な目標を確立する: 週の成功とは何かを共同で定義します
- 環境セットアップを確認する: すべての顧客エンジニアが動作する GDK インストールを持っていることを検証します（事前に行われていない場合、これにかなりの時間がかかると見込みます）
- アーキテクチャの概要を提供する: GitLab のアーキテクチャと、取り組む特定の機能領域について深く掘り下げます
- GitLab の貢献プロセスをレビューする: マージリクエストワークフロー、コードレビュー基準、コミュニティガイドラインを順を追って説明します
- コントリビューターのプロフィールを確認する: 適切なクレジットのため、顧客のコントリビューターに GitLab プロフィールの Organization フィールドを同期するよう促します
技術的なコラボレーション
- ペアプログラミングを実践する: 遠くから指示するのではなく、横で一緒に作業します
- 「方法」だけでなく「理由」を説明する: 顧客が GitLab のアーキテクチャ的な決定とパターンを理解できるようにします
- 必要に応じて Ruby/Rails の集中講座を提供する: GitLab のコードベース構造、コントローラーの場所などの基本的な概要を提供する準備をします
- 実験を奨励する: GDK では何も壊せないこと - 実験は奨励されることを顧客に思い出させます
- 環境を統一する: 異なる Issue を避けるため、すべての顧客エンジニアが同じ GDK セットアップ（全員ローカル、全員 VM など）を使うようにします
- 積極的な参加者を優先する: 他者をブロックしないよう、クリティカルパスの作業はモチベーションの高いチームメンバーにアサインします
- 学びをドキュメント化する: 将来の参照のため、セットアップ手順、注意点、解決策を記録します
コミュニケーションとファシリテーション
- 異なるスキルレベルに忍耐強く対応する: すべての顧客エンジニアが同じ Ruby/Go の経験を持つわけではありません
- 質問を奨励する: 顧客が理解できないことを何でも尋ねられる安全な環境を作ります
- 指導スタイルを適応させる: やってみることで学ぶ人もいれば、説明から学ぶ人もいる - 柔軟に対応します
- 定期的なチェックイン: 全員が含まれていると感じ、進捗が軌道に乗っていることを確認します
- 将来の貢献を計画する: オンサイトの最終日の前日に、継続的な貢献計画について議論する時間をスケジュールします
- 個人的なつながりを構築する: チームディナーや地域のアクティビティなど、業務時間外のインフォーマルな交流の機会を検討します。これらは関係とコラボレーションを強化します（経費計上可能 - Developer Relations Engineering チームに確認してください）
一般的な課題への対処
技術的な課題
- GDK セットアップの問題: 一般的な環境問題に対するトラブルシューティング戦略を準備します。Windows 環境向けの GDK in a Box や、制限されたセットアップ向けのクラウド VM の代替案に精通しておきます
- 顧客の制限された環境: 政府機関やエンタープライズ顧客は、ロックダウンされたマシン、制限されたインターネットアクセス、特定のセキュリティ要件を持つことが多いです
- コードの複雑さ: 複雑な変更を、より小さく、管理可能なピースに分解します
- パフォーマンスへの懸念: いつ最適化するか、いつ機能性を優先するかを顧客が理解できるようにします
- テスト要件: 顧客が貢献に対する適切なテストを書けるようガイドします
プロセスの課題
- コードレビューフィードバック: フィードバックはコード品質の改善であり、個人攻撃ではないことを顧客が理解できるよう支援します。GitLab のレビュープロセスは、新参者には過度に厳密で気落ちさせると感じられる場合があることに注意します
- レビュータイミングの衝突: Co-Create の同期的な性質は、非同期のレビューと衝突します。オンサイト週中に応答性の高いレビューを確実にするため、メンテナーと調整します
- スケールに関する考慮事項: データベースに精通している顧客には、GitLab.com のスケールが実装上の決定にどう影響するかを説明します。一見単純な修正でもより慎重な検討が必要な理由を示すため、postgres.ai のようなクエリプラン分析ツールを見せます
- 貢献ガイドライン: サインオフ要件とコミュニティ基準を顧客が理解していることを確認します（注: ライセンスは Co-Create PM が扱います）
- タイムラインの期待: レビューサイクルとマージタイムラインに関する期待を管理します。同じタイムゾーンにメンテナーがいることを検討します
コミュニケーションの課題
- 異なる作業スタイル: 顧客チームの好みやコミュニケーションパターンに適応します
- 可変的なエンゲージメントレベル: 参加者は受動的な観察者から非常にモチベーションの高いコントリビューターまで様々 - それに応じてアプローチを調整します
- 技術的な言語の壁: GitLab 固有の用語と概念を明確に説明します
- 政府／エンタープライズの制限: 一部の顧客は Discord、外部チャットツール、画面共有を使えません - 代替手段を準備します
- 物理的なロジスティクス: 政府サイトでは付き添いが必要だったり、限られたランチオプションや会議スペースしかなかったりします - それに合わせて計画します
- リモート対対面のダイナミクス: 一部のチームメンバーがリモートの場合、彼らが完全に含まれていることを確認します
長期的な成功の構築
知識移転
- すべてをドキュメント化する: セットアップ手順、貢献ワークフロー、連絡先情報の明確なドキュメントを作成します
- チャンピオンを特定する: 将来の貢献を推進する人を顧客チームが特定できるよう支援します
- 継続的なサポートチャンネルを確立する: オンサイト後の継続的なコラボレーションのため、GitLab チームメンバーとのコミュニケーションパスを設定します
- フォローアップサポートを計画する: あなたが去った後、顧客がどう支援を得られるかを彼らが知っているようにします
- 訪問後 2 週間、MR レビューと質問のために週 2 時間をコミットします
- オンサイトから 1 週間後にスケジュールに 30 分のチェックインコールを入れます
- MR スレッドでの非同期の質問のため、自分の GitLab ハンドルを提供します
コミュニティの統合
- コミュニティリソースを紹介する: Discord、GitLab フォーラム、ドキュメントの使い方を顧客に見せます
- 関連するチームメンバーとつなげる: 顧客の関心領域のプロダクトマネージャー、エンジニア、その他のコントリビューターを紹介します
- 貢献を称える: 適切なときには、彼らの作業を公に評価します
成功指標とフォローアップ
エンゲージメントの成功を測定する
- 技術的進捗: 書かれたコード、開かれたマージリクエスト、通過するテスト
- 学習成果: 顧客チームの GitLab 開発に対する自信の高まり
- 関係構築: 継続的なコミュニケーションとコラボレーションの強さ
- 将来のコミットメント: 顧客チームの継続的な貢献の計画
オンサイト後のアクティビティ
- レトロスペクティブセッション: 顧客チームと簡単なレトロスペクティブを実施します
- 社内デブリーフ: プログラム改善のため、Co-Create チームと学びを共有します
- 継続サポート: 顧客が最初の貢献を完了するまでの限定的なフォローアップサポートを提供します
- ドキュメントの更新: 新しい学びと経験に基づいて、このガイドを更新します
心に留めておくべき重要な原則
エンパワーメントに焦点を当てる
- あなたの目標は、顧客チームが自立して貢献できるようにすることであり、彼らの代わりに作業することではありません
- 解決策ではなく、問題解決のアプローチを教えます
- 顧客が GitLab の開発文化と価値観を理解できるよう支援します
学習プロセスを受け入れる
- 双方が互いから学ぶことを期待します
- 顧客のドメイン専門知識は、GitLab の開発に貴重な洞察を提供できます
- GitLab のプロセスやツールについてのフィードバックを受け入れます
品質基準を維持する
- 高いコード品質はコミュニティ全員に利益をもたらすことを顧客が理解できるよう支援します
- GitLab の開発基準の背後にある理由を説明します
- 学習機会とコードベース品質の維持のバランスを取ります
リソースと連絡先
オンサイト中
- Co-Create プロジェクトマネージャー: プロセスの質問、スケジューリング、エスカレーションのために利用可能
- プロダクトマネージャー: 機能の整合とロードマップの質問のため
- エンジニアリングマネージャー: 技術的アーキテクチャとコードレビューガイダンスのため
- Developer Relations Engineering チーム: コミュニティと継続的なサポートの質問のため
顧客向け
経験豊富なオンサイトエンジニアからのヒント
“Issue を解決する最適な人は、それを経験している人です。すべてを自分で解決しようとするのではなく、彼らが成功できるようにすることに集中してください。”
Raimund Hook
“あなたの仕事は、MR の世話、人の世話などに変わってしまうかもしれません。フラストレーションを感じないでください。GitLab について、彼らがどう使っているか、どんな課題に直面しているかをできるだけ話すようにしてください。”
Vishal Tak
“スムーズな到着とより良い計画のため、旅程と連絡先情報を事前に共有すべきです”
Siddharth Dungarwal
“レビューが迅速化され、それがオンサイトのチームに確実な影響を与え、もっと貢献するモチベーションになりました。”
Pedro Pombeiro
