Content last updated 2025-12-19

Create:Code Review BE チーム

Create:Code Review BE チームは、Create ステージの Code Review グループに含まれるプロダクトカテゴリーのバックエンド側面のすべてを担当しています。

チームのビジョンとミッション

これらのプロダクトの現在の戦略と 1 年計画については、Code Review Workflow と GitLab CLI のカテゴリー方針を参照してください。

主要な責務

Create:Code Review BE チームは、DevOps ライフサイクルの Create ステージに属する Code Review グループのプロダクトカテゴリーのバックエンドに関するすべての側面を担当します。

グループメンバー

以下のメンバーが Create:Code Review グループの恒久的なメンバーです。

NameRole
François RoséFrançois RoséEngineering Manager, Create:Code Review
Sincheol (David) KimSincheol (David) KimSenior Backend Engineer, Create:Code Review
Eugenia GrieffEugenia GrieffSenior Backend Engineer, Create:Code Review
Gary HoltzGary HoltzSenior Backend Engineer, Create:Code Review
Marc ShawMarc ShawSenior Backend Engineer, Create:Code Review
Patrick BajaoPatrick BajaoStaff Backend Engineer, Create:Code Review
Phil HughesPhil HughesStaff Fullstack Engineer, Create:Code Review
Safwan AhmedSafwan AhmedBackend Engineer, Create:Code Review
Stanislav LashmanovStanislav LashmanovStaff Frontend Engineer, Create:Code Review
Thomas RandolphThomas RandolphSenior Frontend Engineer, Create:Code Review
Backend EngineerBackend EngineerBackend Engineer, Create:Code Review

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

他の機能チームから、以下のメンバーが私たちのステーブルカウンターパートとなっています。

NameRole
André LuísAndré LuísSenior Engineering Manager, Create:Source Code, Create:Code Review
Kai ArmstrongKai ArmstrongPrincipal Product Manager, Create:Code Review
Michael LeMichael LeStaff Product Designer, Create:Code Review

共通リンク

よく監視している Issue リスト

メトリクスと KPI

ダッシュボードはこちらにあります。

私たちの働き方

Code Review メインページの作業セクションを参照してください。

私たちのチームと協働する

注目度の高いいくつかの機能 — マージリクエストページ、承認ルールなど — の管理者として、私たちは多くの問い合わせや、それらの機能・依存機能に関する支援や情報提供のリクエストを受け取ります。私たちはコラボレーションと結果の観点からこれらを歓迎し、迅速な応答に努めますが、同時に効率性の価値ともバランスを取らなければなりません。

私たちの目標は、入ってくるリクエストに 2 営業日以内に応答することですが、チームメンバーの状況、経験、ワークロードによっては、それより早く応答することが多々あります。

GitLab で Code Review BE チームに連絡するには、@code-review-be ハンドルを利用できます。

お知らせ Issue

チーム内に情報を行き渡らせ、透明性を高めるため、チーム全体への発表には Slack ではなくお知らせ Issue を使用しています。これらの Issue は固定の頻度ではなく、必要に応じて発信されます。

お知らせ Issue は ~Announcements ラベルが付き、通常はバックエンドエンジニアとエンジニアリングマネージャーを対象とします。お知らせ Issue テンプレート では、プロダクトマネージャーやステーブルカウンターパートにも通知するオプションを選べます。

このフォーマットを使ってお知らせを共有することは、チーム内の誰でも行えます。軽微な内容や繰り返しのお知らせは、引き続き Slack で送ることもあります（例: PTO のマイルストーンリマインダーなど）。

フォローアップ Issue

リリースで何かに取り組んだ結果、技術的負債、フィーチャーフラグの展開や削除、その Issue のためのブロッキングしないタスクなどが残ることがあります。これらに対しては、少なくとも次の 2 つの方法で対処できます。

  • フォローアップ Issue に適切な将来のマイルストーンを設定し、ウェイトと、この Issue に取り組む重要性についての良い説明を付ける。
  • Issue を、関連するプランニング Issue に追加する。

Definition of Done の一部であるフォローアップ作業は、原則として自分で引き受けるべきです。できれば元の作業と同じマイルストーン、または直後のマイルストーンで行うのが望ましいです。これがかなりの量の作業になる場合は、スケジュール判断に影響する可能性があるため、マネージャーに知らせてください。

フォローアップ Issue が多くなる場合は、エピックの作成も検討してください。

バックエンドとフロントエンドの Issue

多くの Issue ではバックエンドとフロントエンドの両方の作業が必要ですが、それらの作業量は同じとは限りません。Issue には 1 つしかウェイトを設定できないため、こうした場合はスコープラベル ~backend-weight::<number> と ~frontend-weight::<number> を代わりに使います。

何に取り組むか

取り組むべきことの主な情報源は、現在のイテレーションサイクルの Code Review Release ボードで、 このサイクルにスケジュール済みの Deliverable と Stretch の Issue がすべてリストされています。

リストはプロダクトマネージャーとエンジニアリングマネージャーが、チームや他のステークホルダーからのインプットを踏まえてマイルストーンプランニングプロセスに従って作成します。 イテレーションサイクルは、その月の第 3 木曜日の前の月曜日に始まり、リリース予定の GitLab バージョンによって識別されます。

Code Review backend アサインメント Issue ボードもあります。これも同じ Deliverable と Stretch の Issue を表示しますが、アサイン先別にグループ化されており、左端のリストは現在どのバックエンドエンジニアにもアサインされていない Issue を表示します。

まず何に取り組むか

Deliverable は最優先と位置づけられ、月の第 3 木曜日の前の金曜日に終わるイテレーションサイクル内に完了することが期待されます。これは、月次リリースに間に合わせるためです。

これらの最優先 Issue はマイルストーン開始時かそれ以前にエンジニアにアサインされ、エンジニアはそのサイクル内に最善を尽くして完了させ、成功を妨げる事態が生じた場合はエンジニアリングマネージャーに知らせる責任があります。 自分にアサインされた Issue は Code Review backend アサインメント Issue ボードで確認できます。

1 ヶ月の間にはさまざまなことが起こり、Deliverable がサイクルの終わりまでに実際には完了しないという結果になることがあります。これは通常、エンジニアリングマネージャーがその Issue のウェイトの見積もりに楽観的すぎたか、エンジニアの他の責任が想定より時間を要した、ということを示すものですが、それでもエンジニアリングマネージャーにとってサプライズであってはなりません。

この潜在的な結末が早く予測・共有されるほど、Deliverable のスコープを縮める、まだ着手されていない Deliverable をより時間のあるエンジニアにバトンタッチするなど、それを防ぐためにできることを探る時間が増えます。 それでも回避できず Deliverable がサイクルを跨いでしまう場合は、単に次のサイクルに移して仕上げ、エンジニアとエンジニアリングマネージャーは振り返りを通じて学ぶ機会とします。

一般に、Deliverable はその月の作業時間の約 75% を占めることが期待されます。残りの 25% は、コードレビュー、コミュニティのマージリクエストへのコーチング、Slack で人を助ける、Issue でディスカッションに参加するなどのその他の責務、加えてその月の途中で発生してすぐに対応すべき Issue（リグレッション、セキュリティ Issue、お客様の Issue など）に充てられます。

次に何に取り組むか

Deliverable とその他の活動を終えてもまだ余裕がある場合は、残り時間を Stretch Issue に充てることができます。Stretch Issue も同じ Issue ボードにあります。

これらは優先度が低めの Issue で、イテレーションサイクル内に完了することは 求められていません。次のサイクルの Deliverable となる予定なので、事前に進められればボーナスとなります。

Stretch Issue は通常、人に直接アサインされません。ただし、明らかに最適な担当者がいる場合（最近誰かが行った作業に関連する技術的負債やバグ、あるいは以前に始めたが終わらせる機会がなかった Issue など）は例外です。

Stretch Issue がまだ自分にアサインされていない場合は、Code Review Release ボードを絞り込んで新しいものをピックアップできます。

すぐに着手できない事情（質問が未回答、要件が不明瞭など）がある場合は、その Issue を一旦スキップして別の Issue を検討して構いません。ただし、次に取り組むエンジニアがより良い状態で見つけられるように、自分が調べたことや疑問を Issue に書き残してください。

Stretch Issue を取り上げる代わりに、プロダクトや会社全体に大きなプラスのインパクトを与えると信じる別のことに余裕時間を使うことを選んでも構いません。 一般ガイドラインにあるとおり、「インスピレーションは儚いものだと認識しているので、比較的短い時間で大きな成果を生み出せそうなことに熱中している場合は、それに取り組んで構いません」。

私たちはメンバーが1 人のマネージャーであることを期待し、硬直よりも責任を選ぶため、 Issue ボードに無いことに取り組むときに許可を求める必要はありません。ただし、他の責務も忘れずに、Issue が存在し、それが自分にアサインされていることを確認し、#g_create_code-review で共有することを検討してください。

ディープダイブ

The groups in the Create stage organize regular Deep Dive sessions to share our domain specific knowledge with others in the stage, the organization, and the wider community. All existing Deep Dives can be found on GitLab Unfiltered with slides and recordings in the descriptions. For Create specific Deep Dives, there is a different playlist. To find more information on upcoming sessions, or to propose a new topic, please see the epic.

可用性とパフォーマンスの監視

Create:Code Review BE チームは、いくつかの API エンドポイントとコントローラーアクションが利用可能（つまりエラーや 500 を出さない）かつパフォーマンスが目標値以下（つまりレイテンシ目標を下回る）であり続けることに責任を持ちます。

可用性ダッシュボード

私たちは、エラーバジェットや機能利用者に影響する Issue を監視・特定するために、以下のダッシュボードを使用します。

根本原因分析のために、サイト全体やインフラの不安定性が問題を引き起こしていないかを以下の方法で確認します。

監視の自動化

私たちの機能カテゴリーに影響するイベントのアラートは、Slack チャンネル #g_create_code-review_alerts に投稿されます。

  • Prometheus SLO 違反アラート（設定）
  • ユーザーがエラーに遭遇していることを示す Sentry アラート:
    • すべての Code Review Workflow エラー（設定）
    • MR ホームページ API エラー（設定）

毎週月曜日には、過去 1 週間の 7 日エラーバジェットが #g_create_code-review に自動的に投稿されます。

以下のデータベース関連の問題については、Issue が自動で作成されます。

パフォーマンスダッシュボード

エンドポイント / アクションでグループ化し、P90（遅い順）でソートされた Kibana ダッシュボード:

Grafana ダッシュボード:

AI 機能の監視に特化したダッシュボードもあります: Create: Code Review: AI Features（社内のみ）。このダッシュボードは Code Review の AI 機能のパフォーマンスを監視しており、特に Sidekiq と GraphQL の操作の P50（中央値）の所要時間を追跡します。

Issue の特定プロセス

  1. 過去 1 週間の 7 日エラーバジェットが赤の場合、根本原因を特定するための調査 Issue を作成します（例）。
  2. エラーバジェットに大きく寄与しているエンドポイントやワーカーを特定した場合は、Issue を作成し（まだ無ければ）、私たちの深刻度と優先度の基準に基づきラベル付けします。
    • すでに Issue がある場合は、深刻度／優先度の更新が必要かを確認します。
  3. パフォーマンスの Issue は専用の GLQL ビューを使ってプランニング時に自動的に表面化させ、それに応じて優先度を付けます。

エンジニアリングオンボーディング

オンボーディングを開始するには、バックエンドエンジニア向けの Code Review オンボーディングテンプレートを使って Issue を作成してください。

その他の関連ページ

Create:Code Review BE エンジニアリングマネージャーの責務
Create:Code Review BE エンジニアリングマネージャーの責務とリソース一覧
Create:Code Review バックエンドエンジニアリングリソース
Create:Code Review グループのバックエンドチームメンバー向けリソース
最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License