Content last updated 2026-10-20

Create

Create ステージは、Source Code を含むチームグループです。

こんにちは

私たちは Create ステージであり、DevOps 部門内のチームグループです。私たちは、GitLab 製品内の領域を担当する、以下のチームで構成されています。

チーム	Engineering Managers
Create:Agentic Preview	Daniel Lanthier
Create:Change Record	Daniel Lanthier
Create:Repository Services	Armin Pašalić
Create:Source Code Hardening and Modernization（一時的、2027-09-10 まで）	Vladimir Shushlin
Create:Import	Thiago Figueiró (フルスタック) — レポート先 Oriol Lluch

ミッション

私たちは何をしますか？

Create ステージは、効率とコラボレーションを改善することにより、ソフトウェア開発チームの提供を加速し、サイクルタイムを短縮することを支援します。私たちのステージは、DevOps ライフサイクルの始まりをサポートするツールを提供します。

誰にサービスを提供しますか？

私たちは以下のためのツールを構築します：

ソフトウェア開発者
DevOps エンジニア
開発チームリード
Product Managers
Product Designers

どのようにサービスを提供しますか？

製品ビジョンハンドブックページは、各タイプの GitLab ユーザーにどのようにサービスを提供するかについての具体的な例を提供します。

ビジョン

次の領域は、今年の私たちの方向性として定義されています：

プロフェッショナル開発

各チームメンバーは、スキルと知識の改善に向けて前向きなステップを取ることが奨励されます。

スキルセットの成長は、GitLab 製品へのより洞察に富んだコントリビューションにつながります。専門知識が成長するにつれて、製品と企業への影響も成長します。GitLab では、チームメンバーのプロフェッショナル開発に投資することが重要です。

もっと学びたい分野がある場合は、マネージャーに連絡して、好みの分野で成長できる環境を提供してもらってください。推奨されるリソースは以下のとおりです：

Engineering Manager

個人コントリビューター

私たちの働き方

各チームは、自分たちの製品とチームのニーズに最も適した方法で作業します。

製品とデザインとの協働

可能な場合は、製品開発フローに従います。

Product Manager と Engineering Manager 間の週次コールは、各グループの共有カレンダーにリストされています。誰でも参加でき、これらのコールはグループに影響を与える障害、懸念、ステータス更新、成果物、その他の考えについて議論するために使用されます。

月次マイルストーン計画 Issue は、次のマイルストーンが始まる前の週に作成されるようトリガーされます。PM（Product Manager）、EM（Engineering Manager）、PD（Product Designer）が一緒にマイルストーンを計画します。

Product と完了条件を定義する

ビルドトラック中、Issue またはエピックの説明内で、成功の測定値が定量的または定性的な成功メトリクスで何であるかを文書化します。Product Manager と Product Designer は、これらのメトリクスを提案し、Engineering とコラボレートして計測および検証する責任があります。

クロスチーム計画と精緻化

これらのガイドラインは、クロスチーム依存関係の識別と、早期のコラボレーションを促進することを目的としています。このプロセスは、製品開発フロー、ビルドフェーズ 1: 計画の一部として行われ、エピックおよび/または Issue の実行のスケジュールを設定する前に行う必要があります。

計画の詳細化

Planning Breakdown ステージで回答する主な質問は次のとおりです：

要求の意図を理解するのに十分なほど要件が明確か？
達成する作業の境界を知っているか？（例：別のチームが維持するコード）

どちらかの答えが「いいえ」の場合、DRI の要求の理解を向上させるためにディスカッションが継続されます。

エンジニアリング出力：

未解決の質問またはディスカッションを識別し解決する。
Issue が他のチームに関連する場合に他のチームに関与する（例：共有コードに触れる、API に影響する、ロードマップに影響する）。
説明で他のチームへの依存関係を説明し、EM、PM、安定したカウンターパートに関与し、早期コラボレーションを促進する。
エピックの場合：エピック内に下書きの実装 Issue を作成する。
すべての Issue に Refinement ステータスを適用する。

Issue を精緻化するように割り当てられたエンジニアは、Issue が成功した精緻化と実行に必要な情報を欠いている場合に質問し、反対意見を述べることが奨励されます。

精緻化ガイドライン

Issue の完全性を確認します：
- 該当する場合、UI を含む必要なデザインがある。
- 機能が明確に明示されている。
- 技術的な詳細がアウトラインされており、ディスカッションが解決されている。
- 依存関係が明示されている。
Issue が完全でない場合：
- Issue を完成させるのに役立つ関連する人々をタグ付けし、必要なものをアウトラインする。
- EM と PM をタグ付けし、ブロッカーを認識させる。
Issue が完全に理解されていることを確認します。
- 実装される最終的な説明で Issue の説明を更新する。
- 実装計画で Issue の説明を更新する。

誰かが Issue とその実装を理解するためには、すべてのコメントを読む必要はないはずです。必要な情報は、唯一の情報源として説明に含まれている必要があります。

実装計画

この要求に対処するために更新する必要のあるステップとコードの一部のリスト。実装計画では、他のチームメンバーまたはチームの責任を明示し、関連する Engineering Manager が計画に同意していることを確認する必要があります。

実装計画の目的は、Issue の批判的分析を促し、DRI にアプリケーションのどの部分がタッチされるかを考えさせることです。実装計画はまた、他のエンジニアが Issue をレビューし、依存関係を持つ可能性のあるアプリケーションの領域や、見落とされている可能性のある領域をハイライトすることを許可します。

複雑な変更については、別のエンジニアからのレビューをリクエストし、対象分野の専門家をループに入れることを検討します。

意思決定プロセス

Create のチームが従う、明確で信頼性のある意思決定プロセスを確保するためのワークフローの詳細については、意思決定プロセスを参照してください。

テンプレート

プロセスをより透明かつ効率的にするためにテンプレートを使用します。プラクティスを一度文書化し、頻繁に再利用することは、ステージ全体を通じてガイダンスとサポートを提供します。

Create ステージ運用ダッシュボード

このダッシュボードは、Create ステージ全体で品質と信頼性を維持するための中央コマンドセンターとして機能します。私たちの Quality First マインドセットに沿って、この wiki を使用してシステムと顧客体験の運用上の健全性を追跡、監視、行動します。

私たちのコミットメント

品質と信頼性は交渉の余地がありません。この wiki で主要なメトリクスを追跡し、明確な目標を設定することで、トレンドが間違った方向に動くときに品質と信頼性の懸念事項が、非インターロック機能作業よりも優先されることを保証します。

どのように機能するか

infradev Issue、バグ、エラーバジェット、インシデント、または顧客エスカレーションがネガティブにトレンドしているか、目標を逃している場合、品質と信頼性の問題に対処するために、非インターロック機能からチームキャパシティをすぐにシフトします。これにより、品質と信頼性の問題が優先される運用上の規律が作成されます。

Wiki は infradev Issue とバグ（オープン対クローズ）の週次トレンドを表示
信頼性指標としてエラーバジェットステータス（🟢🔴）を監視
目標に対する期限切れ S1-S4 infradev Issue とバグを追跡
システム信頼性と顧客への影響の測定値として、アクティブインシデントと顧客エスカレーションを追跡
メトリクスが低下したり目標を逃したりした場合、非必須の機能作業を一時停止または遅延させ、品質と信頼性の修復にチームメンバーのキャパシティをリダイレクト

結果

チームが障害や顧客の痛みに反応的にではなく、低下するメトリクスに積極的に対応するため、品質と信頼性が第一優先事項として維持されます。（製品プロセスに従って）
インターロックコミットメント（専用の信頼性イニシアチブを含む）は継続しますが、裁量的機能は品質と信頼性のニーズに譲り、システム安定性、製品の整合性、または顧客体験を損なう技術的負債を決して蓄積しないことを保証します。

バグ解決戦略

私たちは、タイムリーな解決を確保し、バックログの蓄積を防ぎ、定義されたバグバーンダウンサイクルを通じて予測可能なチームキャパシティを維持する、持続可能なバグ管理プロセスに従っています。

バグバーンダウンサイクルの概要

バグバーンダウンサイクルは、システムヘルスを回復し品質基準を満たすために、チームが既存のバグの解決を優先する集中的でフォーカスされた期間です。チームは、バグの負債が重要なしきい値に達したときにこのサイクルに入ります。

終了基準：バグバーンダウンサイクルから離れる

終了するための要件（すべての重大度レベルに適用）

SLO 遵守
- サービスレベル目標（SLO）を逃したバグがゼロを達成
- SLO を逃したバグなしで完全なマイルストーンを正常に完了
マイルストーン割り当て
- すべてのバグを特定のリリースマイルストーンに割り当てる
- “Backlog"ステータスのすべてのバグを排除
- 適切な計画とキャパシティ管理のために、現在および将来のマイルストーンにバグを分散
一貫した週次スループット
- マイルストーンあたり最低 X 個のバグをクローズ（X はチームキャパシティと過去のスループットに基づいて Engineering Manager が決定）
- 持続可能なペースを示すために、このしきい値を一貫して維持
終了後のレビュー
- バーンダウンサイクル終了後、週次コミットメント目標を再評価
- 受信バグ率とチームキャパシティに基づいてコミットメントを調整

再開トリガー: バグバーンダウンサイクルに入る

次のいずれかの条件が発生した場合、チームはバグバーンダウンサイクルに入ります:

トリガー条件

単一のマイルストーン内で SLO を逃した2 つ以上のバグが存在
バグが “Backlog” ステータス（マイルストーンに割り当てられていない）で蓄積し始める
チームが、マイルストーンあたりのバグクローズの最小 Issue 数しきい値を下回る

継続的な持続可能性プラクティス

発見時にすべての新しいバグをすぐに特定のマイルストーンに割り当てる。

チーム間の働き方

Create ステージのチームは一緒に仕事をし、一緒に遊びます。私たちは互いに依存し、機能をサポートし補完することができて幸運です。クロスチームコラボレーションの例：

Source Code チームと Gitaly チームはしばしば Issue で一緒にコラボレートします
Gitaly チームメンバーは Source Code チームメンバーに Go プログラミング言語のメンタリングを行っています

四半期ごとに、クロスチームのボンディングアクティビティ、Create Team Day に参加します。

私たちの価値観を生きる方法

Engineering Manager は毎日私たちの価値観を生きています。

Engineering Manager が GitLab Values をどう生きているかについて詳しく読む

結果を測定する方法

OKR
ダッシュボード
Issue ボード
監視

イテレーションを測定する方法

ログ
MR 率

生産性を追跡する方法

タレントアセスメント中、Engineering Manager はチームメンバーのパフォーマンスを評価するために包括的なアプローチを取ります。各ジョブレベルの期待に対する公平な評価を確保するために、私たちのエコシステム全体にわたる多様な相互接続されたメトリクスのセットを検討します。これらのメトリクスには以下が含まれます：

マージされたマージリクエスト
実施されたコードレビュー
メンテナーおよびインタビュアーステータス
参加したインタビューの数
メンタリング活動
マージリクエストインパクト
ヘルプ要求と一般的な顧客サポート
クロスチームコラボレーションとリーダーシップ
その他のコントリビューション

このアプローチにより、エンジニアのコントリビューションと成長について均整のとれた評価が可能になります。詳細については、タレントアセスメントページを参照してください。

どのメトリクスに焦点を当てるか？

現在、次のメトリクスについて月次の期待を設定しています：

マージリクエスト率:
- グループに適用する場合：分子はプロジェクトのセットにマージされたマージリクエストの数（以下のメモを参照）。分母はグループの人数。
- 個人に適用する場合：プロジェクトのセットにマージされたマージリクエストの数（以下のメモを参照）。
レビュー率:
- グループに適用する場合：分子は、指定された期間（通常は月）にプロジェクトのセットにマージされたマージリクエストに提供されたコードレビューの数（以下のメモを参照）。分母はグループの人数。
- 個人に適用する場合：指定された期間（通常は月）にプロジェクトのセット（以下のメモを参照）にマージされたマージリクエストに提供されたコードレビューの数。

マネージャーがこれらのメトリクスを使用する方法

マネージャーは以下を行う必要があります：

MR とレビュー率を診断シグナルとして扱い、ハードな生産性目標やノルマとして扱わない。持続的な逸脱は、自動的な判断ではなく、会話のトリガーとなるべきです。
メトリクスを常に文脈で解釈する、以下を含む：
- 作業のタイプ（複雑な機能、リファクタリング、実験、インフラ作業、技術的負債、インシデント）;
- 非コーディング責任（メンタリング、インタビュー、メンテナーシップ、ヘルプ要求 Issue、クロスチーム作業）;
- 一時的な要因（オンボーディング、PTO、インシデント、役割の変更）。
次のことにつながるコーチングまたはインセンティブを避ける：
- MR 数を増やすためだけに作業を不自然に分割する;
- レビュー数を増やすためだけに表面的または急いだレビューをする;
- 複雑で目立たない作業を優先しない（例：マイグレーション、信頼性、他者を可能にすること）。
エンジニア自身のデータを定期的に共有してレビューし、それが何を意味するか、何を意味しないかを説明し、それが本人の作業をどのように反映しているかについて、本人の見解を聞く。
メトリクスの解釈方法に重要な影響を与える場合は、チーム固有のコンテキスト（例：重いインシデント負荷、レガシーオーナーシップ、または大規模なリファクタリング）をチームのハンドブックページに積極的に文書化する。
パフォーマンス決定のための唯一の信頼できる情報源として企業全体のタレントアセスメントガイダンスを使用し、MR とレビュー関連のデータは決定的な要因ではなく、複数の入力の 1 つとして扱う。

ダッシュボード

マージリクエスト率： tableau ダッシュボード
レビュー率： tableau ダッシュボード

注意： Tableau へのアクセスがない場合、直接のマネージャーに連絡して、希望の期間のスクリーンショットを提供してもらうか、該当する場合は永続的なアクセスを提供するためのアクセス要求を開いてもらいます。

メモ：

これらのメトリクスには、製品に影響するすべての MR が含まれます。データセットに含まれる特定のプロジェクトは、このシードファイルにリストされています。
時間をかけてこのプロセスをイテレーションし、メトリクスの範囲を拡張して改善することで、チームの貢献と変化する役割の期待に合うようにします。変更はすべてのチームメンバーに明確に伝えられます。

各ジョブレベルのベースライン目標

下記の表では、シニアリティレベルに関連する各メトリクスのベースライン数値をアウトラインします。これらの数値は、ステージの Engineering Manager とのコラボレーションから導出されました。上記でアウトラインされているように、それらはチームの健全性と個々のワークロードパターンを理解するための 判断材料の 1 つにすぎないもの として扱われます。 それらは生産性またはパフォーマンスの完全な測定値として扱われません が、方向性のガイドとして設定されています。

メトリクス	Associate	Intermediate	Senior	Staff
MR 率	5	5	8	13
レビュー率	3	10	16	16

注意：数値は Source Code Backend、Source Code Frontend、Code Review Backend、Code Review Frontend、Code Creation、Editor Extensions、Remote Development のチームメンバーの過去データを活用して、2024 年 12 月頃に最終更新されました。

これらのベースラインは、Engineering Manager が、作業、責任、ローカルチームの条件のコンテキストでチームメンバーと議論できるトレンドと異常値を浮上させるのに役立ち、常により広範なシグナルセット（例：インシデント対応、アーキテクチャ作業、メンタリング、インタビュー、ヘルプ要求、クロスチームコラボレーション）と組み合わせて使用されます。

私たちの CREDIT 価値観に沿って、バイアスを減らし、倒錯したインセンティブ（MR 分割や表面的なレビューなど）を回避し、顧客のための意味のある成果と持続可能な働き方に焦点を維持するために、これらのベースラインを定期的にレビューおよび調整します。

目標は何を意味するか？

経験則として、明確な文脈的理由（例：延長されたインシデント対応、主要なアーキテクチャ作業、重要なメンタリングまたはリーダーシップ責任、または長期休暇）がない限り、ほとんどのチームメンバーが特定の年の 12 か月のうち少なくとも 6 か月、これらのベースラインに近いまたは上回ることを期待します。

これらの期待は、会話とサポートを促進するためのガイドラインであり、厳密なノルマや自動的なパフォーマンス結果ではありません。チームまたは個人がどのように広く動作しているかを評価するためのキャリブレーション支援として使用できますが、評価は常に完全なタレントアセスメントフレームワークと組み合わせて行われます。

個人コントリビューターの場合、 これらの目標は、本人が従事している役割とシニアリティの期待に合わせたヘルスステータスシグナルを提供できます。

Engineering Manager の場合、 これらの目標は、チームメンバーをよりよくサポートするために、チームプロセス、計画、または個々のケースをレビューするシグナルを提供できます。

逸脱を正当化する特定の文脈を持つチームがある場合、その余分なコンテキストは、可能な限りハンドブックのチームページに文書化する必要があります。

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