AI Model Services グループ

ビジョン

AI Model Services グループは、顧客固有のデータとユースケースをサポートする形で GitLab Duo の機能を支える、追加のカスタムモデルに注力します。

ミッションと担当範囲

AI Model Services は、GitLab の 顧客向けモデルインテリジェンスレイヤー のエンドツーエンドのオーナーです。すなわち、どのモデルが利用可能か、どう選択されるか、顧客体験の健全性と接続性、そしてゲートウェイサービスのサーフェス（プロンプト、内部イベント、AIGW 課金）です。Customer zero、SaaS、Self-Managed、Dedicated にまたがる 1 つのフルスタックチームです。

私たちは、AI Model Services グループに属する製品カテゴリの、すべてのバックエンド領域に責任を持ちます。このグループは、AI Powered ステージとしてDevOps ライフサイクルに含まれます。製品の方向性は Category Direction, AI Model Services Managementページにあり、私たちが扱う機能はグループ別機能ページに記載されています。

組織

このグループは 3 つの機能チームに編成されています。各機能チームは、その領域における Requests for Help（RFH）やサポートエスカレーションを含め、自らのスコープをエンドツーエンドで所有します（カスタマーサポートを参照）。Staff Engineer は、必要に応じて複数の機能チームをサポートすることが期待されます。

Model Selection

.com とセルフホストにまたがって、どのモデルが利用可能か、そしてそれらがどう選択されるかを所有します。

Model Evaluation Infra からの評価結果は、両グループ間の共有レビューケイデンスを通じて選択の意思決定に反映されます（私たちのスコープ外にあるものを参照）。

Health & Connectivity

診断サーフェスと、より広い範囲の顧客向けセットアップおよび接続性の問題を所有します。

「Health」は意図的に広く取られています。診断サーフェス および それらの診断で明らかにすべき障害モードの両方をカバーしており、診断を構築する人々が、その問題に対応する人々と同じになるようにしています。

Gateway Services

ゲートウェイの上に位置するイベント駆動のサーフェス、すなわち流れ込むプロンプト、流れるテレメトリ、そして流れ出る課金／クレジットイベントを所有します。

課金の境界： Gateway Services は課金の AIGW 側（メータリングと課金イベント）を所有します。購入とサブスクリプションの側、すなわち購買やプラン管理は、Fulfillment チームが所有します。 インストルメンテーションの境界： Analytics Instrumentation は、ツール、内部イベント（Snowplow）、課金イベントのツール、そして Service Ping の収集を所有します。私たちは、ゲートウェイ／AIGW サーフェスのドメイン固有イベント、課金イベント、メトリクスを所有し、それらのツールを使って計測します。

機能チームへの編成方法

Acting Engineering Manager： Mohamed Hamda

Engineering Manager & Engineers

Name	Role
Mohamed Hamda	Backend Engineer, AI-Powered:Custom Models

Staff Engineer（クロスチーム）： Manoj M J は機能チームを横断して貢献し、最も必要とされる場所でイニシアチブを引き受けます。

ステーブルカウンターパート

他の機能チームの以下のメンバーが、私たちのステーブルカウンターパートです。

私たちのスコープ外にあるもの

組織内外のチームにとって境界を明確にするため、以下の領域はカウンターパートチームが所有します。作業がこれらの領域に触れる場合は、記載のオーナーを関与させてください。

私たちへの連絡方法

• Issue トラッカー：~group::ai model services
• Slack チャンネル：#g_custom_models
• ラベル購読：~group::ai model services

組織ラベル

AI Model Services グループが所有する Issue には、必要に応じて以下のラベルを付けます。

• ~"group::ai model services"
• ~"devops::ai-powered"
• ~"category:ai gateway services"
• ~"category:model selection"
• ~"category:health & connectivity"
• ~"category:health & connectivity" 加えて、Issue には関連する ~type: とサブタイプのラベルを含めます。

私たちの働き方

私たちの運用フレームワークは、オーナーシップを可視化し、進捗についてチームが誠実であり続けられるようにし、優先順位が妥当でないときに反論できる余地を生み出します。これらを、官僚主義を加えることなく実現します。

直接責任者（DRI）

チームが現在取り組んでいるすべての Issue、機能、バグ修正、イニシアチブには、名前の付いた単一の DRI がいます。DRI は必ずしもすべての作業を行う人ではなく、それを前進させ、ブロックされない状態に保つ責任を持つ人です。

DRI であることは、次のことを意味します。

• あなたはタスクだけでなく 成果 を所有します。行き詰まっているなら、尋ねられるのを待たずに自分から声を上げます。
• 少なくとも週に 1 回、計画用 Issue のステータスを更新します。
• 作業を委任できますが、説明責任はあなたに残ります。
• スコープ、優先順位、タイムラインが妥当でない場合は、理由を明確に説明したうえで反論できます（そしてそうすべきです）。

DRI の割り当て方法：

• 新しい Issue： 週次同期で議論し、誰かが立候補するか提案されます。誰も立候補しない場合は、その理由を議論します。実は優先事項ではないのかもしれませんし、チームが過負荷なのかもしれません。
• RFH とエスカレーション： 関連する機能チームのトリアージ DRI が、オーナーシップを引き受けるか、コンテキストとともに明示的に引き継ぎます。
• DRI の割り当ては、誰が何を所有するかの唯一の信頼できる情報源であるチームの計画用 Issue で追跡されます。

DRI の再割り当ては、政治的なイベントではなく、通常の負担の少ない対応です。それは（自然な成り行きではなく）明示的に 行い、新しい DRI がゼロから始めずに済むだけの十分なコンテキストを引き継ぐ必要があります。

週次ステータス更新

各アクティブな DRI は、チームの計画用 Issue に短い非同期の更新を投稿します。数行であり、長編小説ではありません。

• 今週前進したこと
• ブロックされていることと、必要なもの
• 来週取り組むこと

例：

非同期ステータス更新 YYYY-MM-DD

Issue タイトル（リンク）

• 進捗：…
• ブロッカー：…
• 現在のマイルストーンへの確信度：🟡 やや確信あり

Issue タイトル（リンク）

• 進捗：…
• ブロッカー：…
• 現在のマイルストーンへの確信度：🟢 非常に確信あり

確信度のキー： 🔴 確信なし · 🟡 やや確信あり · 🟢 非常に確信あり

計画用 Issue 上の非同期更新がデフォルトであり、すべてのアクティブな作業の状態を確認できる唯一の場所です。既存のエンジニアリング同期は、主にブロッカーについて手を挙げるために使われます。出席は任意であり、参加できなくても（たとえばタイムゾーンの都合で）他に何も変わりません。

早めに手を挙げる

行き詰まっている、過負荷である、あるいは作業が予想より大きいと気づいたら、手を挙げてください。これは健全なチームの運営方法であり、失敗の兆候ではありません。

• 週次更新でフラグを立てます。
• 明確な依頼とともに Slack でチームにメンションします。「X について手伝ってほしい」または「Z なので Y を引き継いでくれる人が必要」のように伝えます。
• ブロックされている項目は、週次同期で最初に議論します。

反論すること、そして量より質

チームには、現在の優先順位に沿わない作業や、品質を損なう作業に対して反論する権限があります。

• 反論には 理由 を添えます（「私たちは X と Y にコミットしているので、このマイルストーンではこれを引き受けられません」）。
• 依頼した人ではなく、作業に向けて反論します。
• 意思決定の記録が残るように文書化します（Issue へのコメントで十分です）。

私たちは、既存のモデルや構成が堅牢になるまで、新しいモデルや構成を追加するプレッシャーに抵抗します。新しいモデルのオンボーディングは、軽量なレディネスチェックを通ります。

1. ドキュメントは完成しているか？

2. 既知の問題は解決されているか？

3. サポートはチケットに対応できる体制になっているか？

「これはまだ追加しません。まず先に正しくすべきことはこれです」は、有効で奨励される回答です。

ケイデンス

エピックと Tech Lead を使った作業のスコーピング

エピックは、単一の Issue より大きいあらゆる作業項目、すなわち新機能、複雑なリファクタリング、バグに対するスコープの主要な定義です。エピック内の Issue が作業項目の全スコープを構成します。それらがすべてクローズされると作業は完了し、エピックはクローズされます。エピックは明確な改善を加えるイテレーションを内包すべきですが、エピックが必ずしも機能全体を表すわけではありません。機能全体には複数のエピックが必要になることもあります。

エピックによって定義された作業の技術的オーナーシップは、エピックにアサインされ、スコープが正しいことを保証するエンジニアである Tech Lead に委任されます。Tech Lead は EM、PM、他のエンジニアと協働します。チームのどのエンジニアも、Tech Lead 自身を含め、Kanban プロセスを使って自分自身をアサインし、エピック内の Issue に取り組めます。

チームのマイルストーン計画プロセス

AI Model Services は、プロダクト開発フローとクロスファンクショナルな優先順位付けに従います。チームは計画用 Issue とボードを使って計画プロセスを管理します。これを容易にするための計画自動化スクリプトが利用できます。

各マイルストーンの計画用 Issueは PM が作成し、PM、EM、ステーブルカウンターパートの間で今後の作業を調整するために使われます。

各マイルストーン中に、次のマイルストーンの計画を完了します。

1. 計画用 Issue とボードの作成（EM または PM）
2. 自動化による毎週のリファインメント Issue の作成
3. マイルストーンの候補 Issue の特定と計画ボードへの追加（PM、EM）
4. チームメンバーのキャパシティプランニング（EM）
5. ウェイトを使った工数の見積もり（エンジニアと EM）
6. 計画ボードを確定するための合同計画セッション（PM、EM）
7. エンジニアへの作業の割り当て、~Deliverable ラベルの追加、計画用 Issue の更新（EM）

計画用 Issue

毎月、PM が自動化と AI Model Services Planning テンプレートを使って計画用 Issue を作成します。これは特定のマイルストーンについての計画チームメンバー（PM、EM）の議論の場であり、計画ボードとビルドボードにリンクします。

計画ボード

計画ボードは各マイルストーンについて PM が作成し、カテゴリ別に厳選された Issue のリストです。Issue で過負荷になることがあり、超過分は計画コール中に次のマイルストーンまたは Next 1-3 Milestones ボードに移動されます。

PM は ~workflow::planning breakdown で Issue にマークを付け、EM に対してエンジニアに Issue の説明をレビューし、それが明確で開発の準備ができていることを確認するよう依頼するシグナルを送ります。エンジニアはその後ウェイトをアサインし、~workflow::ready for development ラベルを適用します。

開発準備完了ステータス

作業の準備ができた Issue には workflow::ready for development のラベルが付けられます。このラベルが付いた Issue のみが、Deliverable としてエンジニアにアサインされるべきです。調査が必要な場合は ~spike ラベルがアサインされます。スパイクのスコープは明確に記載し、その成果はコードまたはリファインメント済みの Issue になることがあります。

キャパシティプランニング

EM は、チームのキャパシティを計算し、優先順位に基づいてリリースに作業レーンを割り当てる方法を維持します。EM は計画用 Issue にチームのキャパシティと DRI を投稿します。

ビルドボード

EM は、前のマイルストーンの遅れ、PM の好み、ウェイト、優先順位に基づいて計画ボードから Issue を選びます。EM はその後リリース内の各 Issue に ~Deliverable ラベルを適用し、それをエンジニアにアサインします。Issue はリリース全体を通じてビルドボードで追跡されます。

say-do ratio（言ったことを必ずやる比率）

say-do ratio（言ったことを必ずやる比率）は Completed Issues / Assigned Issues を使って計算します。

• ~Deliverable ラベルとともにビルドボードに追加された Issue が、アサインされた Issue です。
• マイルストーンの終わりまでにクローズされた Issue が、完了した Issue です。

Issue ウェイト

各 Issue には、それをクローズするための作業の見積もりとしてウェイトがアサインされます。ウェイト 1 はおおよそ 2 営業日分の工数です。Issue は一般にウェイト 3 を超えてウェイト付けされません。より大きなウェイトは、その Issue をさらに分解すべきであることを示します。

計画ボードとデリバリーボード

プロダクト開発フローのすべてのワークフローステータスが有効です。Next 1-3と Next 4-6 milestonesボードには、リファインメントが必要な Issue や作業の準備ができた Issue が置かれます。

Issue マイルストーン

• Issue は、取り組む予定であるか現在取り組まれている場合、現在または次のマイルストーンにアサインされます。
• Issue に取り組む予定がない場合は %Backlog がアサインされますが、コミュニティからの貢献によって対応される可能性はあります。
• %Awaiting Customer Feedback は、顧客の関心を待ちながら取り組まれる可能性があります。

Issue トリアージレポートは、マイルストーンのアサインが必要な Issue を強調表示します。

カスタマーサポートと Requests for Help

顧客（既存および見込み）とのコールをより適切にサポートするため、AI Model Services はカスタマーサポートのリクエストを優先するエンジニアを配置し、負荷と知識がチーム全体で共有されるようにします。

RFH は、それが属するスコープの機能チームが所有します。Gateway Services はゲートウェイの RFH を、Health & Connectivity はセットアップ／接続性の RFH を、というように処理します。各機能チームは トリアージ DRI をアサインし、その DRI が RFH を解決まで推進するか、コンテキストとともに明示的に引き継ぎます。サポートリクエストは 24 時間以内に確認します。

顧客のために支援を依頼するには、支援依頼 Issueを作成し、#g_custom_modelsで共有してください。同じチャンネルで他のチームメンバーに支援を求めることをためらわないでください。

サポートにおけるトリアージ DRI の責任

• Requests for Helpをトリアージします。
• #g_custom_modelsと #custom_model_rfhで受信するリクエストをモニタリングします。
• 支援依頼 Issue が作成されていることを確認します。
• Slack でサポートの質問に回答し、可能な限りドキュメントへ誘導します。
• 必要なときに Solution Architects や Sales 担当者が主導する顧客コールに参加し、解決するかサポートエンジニアに引き継ぐまで顧客とのコミュニケーションを所有します。
• 成果に基づいて行動します：
  1. SA と顧客がより自立できるようドキュメントを追加できるか？
  2. より良いツールが役立つか？ 必要な変更を記載した Issue を作成します。
  3. 私たちが見逃したバグだったか？ 次回はどう回避するか？
• 不在になる場合は事前に EM に通知します。
• 必要なコンテキストをサポートの次のエンジニアに引き継ぎます。

サポートを担当するエンジニアに期待され ない ことは次のとおりです。

• 希望する勤務時間外に対応可能であること。ただし一部のリクエストは緊急であり、翌営業日の最優先で取り組むべきです。そうした状況では EM と PM に相談してください。
• 特定のケースで合意した場合を除き、顧客コールを主導すること。
• 特定のケースで合意した場合を除き、デモを行うこと。

コミュニケーション

AI Model Services は以下のガイドラインに基づいてコミュニケーションを行います。

1. 同期ミーティングよりも常に非同期コミュニケーションを優先します。
2. 非同期が非効率だと判明したときは、同期コールの設定をためらわないでください。ただし、チームメンバーと共有するために録画するようにします。
3. デフォルトで透明性。
4. 仕事関連のコミュニケーションの主要チャンネルは #g_custom_models Slack チャンネルです。
5. 内部のチーム Issue とプロジェクトは gitlab-org/ai-powered/custom-modelsの下に名前空間化されています。

メンションの確認

Slack または GitLab で名前を指名してメンションされた場合は、スレッドへのコメントまたは絵文字で確認してください。

休暇

チームメンバーは、有給休暇（Paid Time Off）を「Workday」Slack アプリに追加し、EM がキャパシティプランニング中に正しい休暇日数を使えるようにします。可能な場合は、マイルストーン 1 つ分前もって休暇を追加してください。

直前の計画外の PTO が必要になることは常にあり得ます。必要な休暇は取得してください。ただし Workday に入力し、できるだけ早く EM に伝えてください。

アドホックな同期コール

私たちはデフォルトで非同期コミュニケーションを使って運用します。同期での議論が有益なときもあり、チームメンバーには必要に応じて必要な人々と同期コールをスケジュールすることを推奨します。

ブログ記事

AI Model Services チームメンバーが執筆したブログ記事：

• Developing GitLab Duo: How we validate and test AI models at scale、@susie.bee
• GitLab Duo Self-Hosted: Enterprise AI built for data privacy、@susie.bee
• Speed meets governance: Model Selection comes to GitLab Duo、@susie.bee

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