Create

こんにちは

私たちは Create ステージです。DevOps 部門内のチームグループです。GitLab プロダクト内の3つの領域で構成されています。

ミッション

何をしていますか？

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

誰のために作っていますか？

以下のためのツールを構築しています:

• ソフトウェア開発者
• DevOps エンジニア
• 開発チームリード
• プロダクトマネージャー
• プロダクトデザイナー

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

プロダクトビジョンのハンドブックページでは、各タイプの GitLab ユーザーへのサービス提供方法の具体的な例が提供されています。

ビジョン

以下の領域が今年の方向性として定義されています:

• 高速で信頼性が高く、容易に管理できる Git ストレージ
• バイナリファイルのワークフロー
• 快適なコードレビュー
• OSS 内および大規模組織全体での多くのチーム間のより良いコラボレーション
• 編集エクスペリエンスの統合
• より良い統合

プロフェッショナル開発

各チームメンバーはスキルと知識の向上に積極的に取り組むことを奨励されています。

スキルセットを成長させることは GitLab プロダクトへのより洞察力のある貢献につながります。専門知識が成長するにつれて、プロダクトと会社への影響も大きくなります。GitLab では、チームメンバーのプロフェッショナル開発に投資することが重要です。

興味を持って詳しく学びたい領域がある場合は、マネージャーに相談してください。希望する領域で成長できる環境を提供します。以下のリソースが推奨されます:

エンジニアリングマネージャー

• 推薦図書
• トレーニング資料

個人貢献者

• プロフェッショナル開発
• 推薦図書
• トレーニング資料
• 個人貢献者からマネージャーへの移行
• スキップレベルミーティング
• イテレーション

作業方法

各チームは、プロダクトとチームのニーズに最も合う方法で作業します。

• Create エンジニアリングマネージャー
• Remote Development チーム
• Code Review チーム
• Source Code チーム バックエンド、フロントエンド

プロダクトとデザインとの協力

可能な場合はプロダクト開発フローに従います。

プロダクトマネージャーとエンジニアリングマネージャー間の週次コールは、各グループの共有カレンダーに記載されています。誰でも参加でき、これらのコールはグループに影響する障害、懸念事項、ステータス更新、成果物、またはその他の考えを議論するために使用されます。

月次マイルストーン計画 Issue は、次のマイルストーン開始の1週間前に作成されるようトリガーされます。PM（プロダクトマネージャー）、EM（エンジニアリングマネージャー）、PD（プロダクトデザイナー）が協力してマイルストーンを計画します。プロダクトデザイナーの責任:

• 2週間ごとに UX バグをトリアージする: Create の プロダクトデザインマネージャーが各チームの PD に、2週間ごとにスケジュールされていないバグのリストを確認するよう通知します。このエクササイズを30分以内に収め、各 Issue を1つずつ開くのではなく、リストをスキャンして気になるものがあるか確認することをお勧めします。デザイナーは、トリアージされた Issue に severity と bug::ux ラベルを割り当てます。デザイン提案の追加などの追加作業はこのプロセスのスコープ外です。
• 各マイルストーンに少なくとも5件の UX バグおよび/または UX 改善を推奨する: 定期的な Issue バックログのレビューに加えて、UX バグと Issue 改善のレビューにはこの GLQL Wiki ページを使用することを検討してください。マイルストーン前の1週間で、PD は優先すべき最もインパクトが大きく重要な少なくとも5件のバグおよび/または UX 改善のリストを計画 Issue に追加する必要があります。PD はこれらのアイテムを支持してそれらの優先順位付けのために協力する必要がありますが、最終的な決定はチームのキャパシティ、実現可能性/ブロック状況、その他の優先事項（高度な深刻度のバグとインターロックアイテム）に依存します。

プロダクトとの完成の定義

ビルドトラックでは、Issue またはエピックの説明内で、定量的または定性的な成功メトリクスで成功の測定基準を文書化します。プロダクトマネージャーとプロダクトデザイナーがこれらのメトリクスを提案し、エンジニアリングと協力してそれらを実装・検証する責任があります。

クロスチームの計画とリファインメント

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

計画のブレークダウン

Planning Breakdown 段階で回答すべき主な質問:

• リクエストの意図を理解するのに十分な要件が明確か？
• 実施する作業の境界は分かっているか（例: 別のチームが維持するコード）？

いずれかの回答が「いいえ」の場合、DRI のリクエストへの理解を向上させるためにディスカッションが続きます。

エンジニアリングの出力:

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

リファインメント

Issue をリファインメントするために割り当てられたエンジニアは、Issue に成功したリファインメントと実行に必要な情報が不足している場合に質問し、押し返すことが奨励されます。

リファインメントガイドライン

1. Issue の完全性を確認する:
   • 必要なデザイン（UI を含む場合）がある。
   • 機能が明確に説明されている。
   • 技術的な詳細が概説されており、ディスカッションが解決されている。
   • 依存関係が明示されている。
2. Issue が完全でない場合:
   • Issue を完成させるのに役立てることができる関係者にタグ付けし、必要なことを概説する。
   • ブロッカーを認識させるために EM と PM にタグ付けする。
3. Issue が完全に理解されていることを確認する。
   • 実装する内容の最終的な説明で Issue の説明を更新する。
   • 実装計画で Issue の説明を更新する。

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

実装計画

このリクエストに対応するために更新が必要なステップとコードの部分のリスト。実装計画はまた、他のチームメンバーやチームの責任を明示し、関連するエンジニアリングマネージャーが計画に同意していることを確認する必要があります。

実装計画の目標は、Issue の批判的な分析を促し、DRI がアプリケーションのどの部分が影響を受けるかを考え通すことです。実装計画はまた、他のエンジニアが Issue をレビューし、依存関係がある、または見落とされているアプリケーションの領域を強調できるようにします。

複雑な変更には、別のエンジニアからのレビューを要求し、専門家を巻き込むことを検討してください。

意思決定プロセス

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

テンプレート

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

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

このダッシュボードは、Create ステージ全体の品質と信頼性を維持するための中央指令センターです。Quality First の考え方に沿って、このウィキを使用してシステムの運用ヘルスと顧客体験を追跡、監視、対処します。

私たちのコミットメント

品質と信頼性は妥協できません。このウィキで主要なメトリクスを追跡し、明確な目標を設定することで、トレンドが誤った方向に動く場合に品質と信頼性の懸念がインターロック外の機能作業より優先されることを確保します。

仕組み

Infradev の Issue、バグ、エラーバジェット、インシデント、または顧客エスカレーションが負の方向にトレンドしている、または目標を達成していない場合、チームのキャパシティを即座にインターロック外の機能から品質と信頼性の問題への対応に切り替えます。これにより、品質と信頼性の問題が優先される運用規律が生まれます。

• ウィキは Infradev の Issue とバグの週次トレンド（オープン対クローズ）を表示します
• エラーバジェットステータス（🟢🔴）を信頼性の指標として監視します
• S1-S4 の期限超過 Infradev Issue とバグを目標に対して追跡します
• システム信頼性と顧客への影響の測定として、アクティブなインシデントと顧客エスカレーションを追跡します
• メトリクスが低下したり目標を達成できない場合、重要でない機能作業を一時停止または遅延し、チームメンバーのキャパシティを品質と信頼性の改善に向けます

成果

• チームが停止や顧客の痛みに反応的ではなく、低下するメトリクスにプロアクティブに対応するため、品質と信頼性が最高優先度として維持されます。（プロダクトプロセスによる）
• インターロックのコミットメント（専用の信頼性イニシアチブを含む）は継続されますが、任意の機能は品質と信頼性のニーズに譲ります。これにより、システムの安定性、プロダクトの完全性、または顧客体験を損なう技術的負債を積み上げることはありません。

バグ解決戦略

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

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

バグバーンダウンサイクルとは、バグ債務が重大なしきい値に達したときにチームが入るサイクルで、既存のバグの解決を優先してシステムヘルスを回復し品質基準を満たす集中的な期間です。

終了基準: バグバーンダウンサイクルの終了

終了要件（すべての深刻度レベルに適用）

1. SLO コンプライアンス

   • SLO（サービスレベル目標）を達成できなかったバグをゼロにする
   • SLO 違反バグなしで完全な1マイルストーンを達成する

2. マイルストーンの割り当て

   • バグの100%を特定のリリースマイルストーンに割り当てる
   • 「バックログ」ステータスのすべてのバグを排除する
   • 適切な計画とキャパシティ管理のために、現在と将来のマイルストーンにバグを分散する

3. 一貫した週次スループット

   • マイルストーンごとに最低 X 件のバグをクローズする（X はエンジニアリングマネージャーがチームキャパシティと過去のスループットに基づいて決定）
   • 持続可能なペースを示すためにこのしきい値を一貫して維持する

4. 終了後のレビュー

   • バーンダウンサイクルを終了した後、週次コミットメント目標を再評価する
   • 入ってくるバグのレートとチームキャパシティに基づいてコミットメントを調整する

再入トリガー: バグバーンダウンサイクルへの入り方

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

トリガー条件

• 単一マイルストーン内に SLO を達成できなかったバグが2件以上存在する
• バグが**「バックログ」**ステータス（マイルストーンに割り当てられていない）に蓄積し始める
• チームがマイルストーンごとのバグクローズの最低件数のしきい値を下回る

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

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

チーム横断での作業方法

Create ステージのチームは協力して取り組み、共に楽しんでいます。私たちは互いの機能をサポートし補完するために頼り合える幸運があります。クロスチームコラボレーションの例:

• Source Code チームと Gitaly チームは Issue でしばしば協力します
• Gitaly チームメンバーが Source Code チームメンバーに Go プログラミング言語についてメンタリングしてきました

四半期ごとに、クロスチームのボンディング活動「Create Team Day」に参加しています。

価値観の実践方法

エンジニアリングマネージャーは毎日私たちの価値観を実践しています。

エンジニアリングマネージャーが GitLab の価値観をどのように実践しているかについてはこちら

成果の測定方法

• OKR
• ダッシュボード
• Issue ボード
• モニタリング

イテレーションの測定方法

• ログ
• MR レート

生産性の追跡方法

各役割での期待についての明確さを高め、期待の整合性を図るため、Create ステージは MR レート（月間12件以上）などのエンジニアリングパフォーマンス指標を拡張し、各シニアリティレベルの期待をさらに明確にします。

なぜ？

タレント評価において、エンジニアリングマネージャーはチームメンバーのパフォーマンスを全体的なアプローチで評価します。エコシステム全体にわたる相互に関連したメトリクスの多様なセットを考慮し、各職務レベルの期待に対して公正な評価を確保します。これらのメトリクスには以下が含まれます:

• マージされたマージリクエスト
• 実施されたコードレビュー
• メンテナーとインタビュアーのステータス
• 参加したインタビュー数
• メンタリング活動
• マージリクエストのインパクト
• その他多数

この包括的なアプローチにより、エンジニアの貢献と成長を多角的に評価できます。詳細については、タレント評価ページをご参照ください。

期待を明確かつ透明に伝えることが重要だと考えており、全員が何を期待されているかを知り、何を期待すればいいかを分かるようにします。このセクションでは、このトピックに明確さを加え、Create ステージ全体での意識向上を促進しようとしています。

どのメトリクスに注目しますか？

チームパフォーマンスメトリクスの目標は、現実の理解に部分的に貢献することです。なぜなら各メトリクスは単独では不完全かもしれませんが、他のメトリクスと合わせることで、チームおよび/または個人の貢献についてより完全な絵とより良い洞察を提供できるからです。

現在、以下のメトリクスに対して明確な月次期待値を設定しています:

• マージリクエストレート:
  • グループに適用する場合: 分子は一連のプロジェクト（以下のメモ参照）にマージされたマージリクエストの数です。分母はグループ内の人数です。
  • 個人に適用する場合: 一連のプロジェクト（以下のメモ参照）にマージされたマージリクエストの数です。
• レビューレート:
  • グループに適用する場合: 分子は所定の期間（通常1か月）に一連のプロジェクト（以下のメモ参照）にマージされたマージリクエストに行われたコードレビューの数です。分母はグループ内の人数です。
  • 個人に適用する場合: 所定の期間（通常1か月）に一連のプロジェクト（以下のメモ参照）にマージされたマージリクエストに行われたコードレビューの数です。

ダッシュボード

• マージリクエストレート: Tableau ダッシュボード
• レビューレート: Tableau ダッシュボード

注意: Tableau へのアクセスがない場合、直接のマネージャーに希望の期間のスクリーンショットを提供してもらうか、または恒久的なアクセスのためのアクセスリクエストを開いてもらえるか確認してください。

メモ:

1. これらのメトリクスには、プロダクトに影響するすべての MR が含まれます。データセットに含まれる特定のプロジェクトはこのシードファイルに記載されています。
2. メトリクスセットを拡張し、チームの貢献と進化する役割の期待との整合性を確保するためにこれらを改善することで、時間をかけてこのプロセスをイテレーションします。変更はすべてのチームメンバーに明確に伝達されます。

各職務レベルのベースライン目標

以下の表では、シニアリティレベルに関連したメトリクスのベースライン数値を概説しています:

目標はどのように計算されましたか？

既存のチームメトリクスを分析し、ステージのすべてのエンジニアリングマネージャーと協力することで、各役割のPerformingレベルでの通常のキャリブレーションセッション中に設定された期待を正確に反映する目標が定義されました。

これらの目標は私たちの CREDIT 価値観への遵守を念頭に置いて設定されており、野心的かつ現実的です。

目標は何を意味しますか？

チームメンバーが1年の12か月のうち少なくとも6か月は目標を達成しているか、超えていることを期待しています。

個人貢献者にとって、これらの目標は役割とシニアリティの期待と整合したヘルスステータスシグナルを提供できます。

エンジニアリングマネージャーにとって、これらの目標はチームプロセス、計画、または個別ケースを見直してチームメンバーをより適切にサポートするためのシグナルを提供できます。

特定のコンテキストがある逸脱を正当化するチームについては、その追加コンテキストをできる限りチームのハンドブックページに文書化する必要があります。

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