レビューワークフロー設計
Issue #7: MRレビューワークフロー・報告資料テンプレート設計
1. ワークフロー全体フロー
┌─────────────────────────────────────────────────────────────────────────┐
│ MRレビューワークフロー │
└─────────────────────────────────────────────────────────────────────────┘
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ MR作成 │───>│ 自動チェック │───>│ レビュワー │───>│ レビュー │
│ & 提出 │ │ (CI/CD) │ │ アサイン │ │ 実施 │
└──────────┘ └──────┬───────┘ └──────────────┘ └────┬─────┘
│ │
NG(自動) │
│ ┌───────┴───────┐
v │ │
┌──────────────┐ ┌──────────┐ ┌──────────┐
│ 作成者に │ │ 承認 │ │ FB │
│ 差し戻し │ │ (Approve)│ │ (修正 │
└──────────────┘ └────┬─────┘ │ 依頼) │
│ └────┬─────┘
v │
┌──────────┐ │
│ マージ │ v
│ 実行 │ ┌──────────────┐
└──────────┘ │ 修正 & 再提出 │
└──────┬───────┘
│
┌──────┴───────┐
│ FB回数 │
│ チェック │
└──────┬───────┘
│
┌───────────┴──────────┐
│ │
3回以内 3回超過
│ │
v v
┌──────────┐ ┌──────────────┐
│ 再レビュー │ │ PMへ │
│ │ │ エスカレーション│
└──────────┘ └──────────────┘2. 各フェーズの詳細
2.1 MR作成 & 提出
担当: 開発者（MR作成者）
| 項目 | 内容 |
|---|---|
| 前提条件 | feature ブランチでの実装が完了していること |
| 実施内容 | MRテンプレートに基づき報告資料を記入してMRを作成 |
| 完了条件 | テンプレートの必須項目が全て記入されていること |
作成者の責務:
- MRテンプレートの必須項目を全て記入する
- セルフチェックリストを全項目確認する
- CI パイプラインが通ることを確認してからレビュー依頼する
- レビュワーが報告資料のみでレビュー完了できる粒度で記載する
2.2 自動チェック（CI/CD）
担当: GitLab CI パイプライン（自動実行）
MR作成・更新時に以下が自動実行される:
| チェック項目 | 内容 | 詳細 |
|---|---|---|
| テンプレート準拠チェック | MR説明欄の必須項目が記入されているか | quality-gate.md 参照 |
| コード品質チェック | lint / format の確認 | ESLint, Prettier 等 |
| 自動テスト | ユニットテスト / 結合テスト実行 | Jest, pytest 等 |
| ビルド確認 | ビルドが成功するか | プロジェクト依存 |
| セキュリティスキャン | 秘密情報の漏洩チェック | git-secrets 等 |
自動チェック失敗時:
- MRに失敗理由がコメントされる
- 作成者に自動で差し戻し（マージ不可状態）
- 作成者が修正してプッシュすると再実行される
2.3 レビュワーアサイン
担当: MR作成者 または プロジェクトルール
| 方式 | 説明 |
|---|---|
| 手動アサイン | MR作成者がレビュワーを指名 |
| 自動アサイン（推奨） | GitLab の Code Owners または Review Roulette で自動割り当て |
アサインルール:
- MR作成者自身をレビュワーにアサインしない
- 最低1名のレビュワーをアサインする
- 変更ファイルのCode Ownerが存在する場合は優先的にアサインする
2.4 レビュー実施
担当: レビュワー
レビュー期限: MR提出後 3営業日以内
レビュワーは以下の観点でレビューを実施する:
レビュー基準
| カテゴリ | チェック観点 | 判定基準 |
|---|---|---|
| 機能要件充足 | Issue要件を満たしているか | 実装概要と動作確認結果から判断 |
| コード品質 | 可読性・保守性・設計の適切さ | コードレビュー + セルフチェックリスト |
| テスト充足 | テストカバレッジが十分か | テスト結果セクションから判断 |
| 報告資料の十分性 | 報告内容だけでレビュー完了できるか | テンプレート記入内容の網羅性 |
| セキュリティ | 脆弱性がないか | セルフチェックリスト + コードレビュー |
| パフォーマンス | 性能問題がないか | セルフチェックリスト + コードレビュー |
| 影響範囲 | 影響が正しく把握されているか | 影響範囲セクションの妥当性 |
レビュー結果の記録
レビュワーは以下のいずれかの判定を行う:
| 判定 | GitLab操作 | 説明 |
|---|---|---|
| 承認 (Approve) | MRを Approve | 全基準を満たしている |
| FB (修正依頼) | コメント + 「Changes requested」ラベル | 修正が必要な箇所がある |
| 質問・確認 | コメント（Discussion） | 判断のための追加情報が必要 |
2.5 FB（フィードバック）→ 修正 → 再レビューサイクル
FB発行 修正 再提出 再レビュー
┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐
│FB #1│──(修正)──>│修正 │──(push)──>│再提出│──(review)─>│判定 │
└─────┘ └─────┘ └─────┘ └──┬──┘
│
┌────────┴────────┐
│ │
承認 FB #2
│ │
マージ ... (最大3回)サイクル管理ルール
| ルール | 内容 |
|---|---|
| 最大FB回数 | 3回まで |
| FB回数の数え方 | レビュワーが「Changes requested」を付与した回数 |
| 3回超過時 | PMへエスカレーション（後述） |
| 修正期限 | FB受領後 2営業日以内に修正・再提出 |
| 再レビュー期限 | 再提出後 2営業日以内 |
FB記載ルール（レビュワー側）
レビュワーのFBは以下の形式で記載する:
markdown
### FB種別: [Must / Should / Nit]
**対象箇所:** ファイルパス:行番号
**内容:** 具体的な修正内容
**理由:** なぜ修正が必要か
**提案:** （可能であれば）修正案| FB種別 | 意味 | 修正要否 |
|---|---|---|
| Must | 修正必須。マージブロック | 必須 |
| Should | 修正推奨。今回対応が望ましい | 推奨（理由付きで見送り可） |
| Nit | 軽微な指摘。対応は任意 | 任意 |
修正対応ルール（作成者側）
- Must: 必ず修正する
- Should: 修正するか、見送り理由をコメントで説明する
- Nit: 対応可否を自由に判断。対応しない場合はコメント不要
- 全てのFBに対してコメントで対応状況を返信する（「修正済み」「次回対応」「見送り理由: ...」等）
2.6 エスカレーション
条件: FB回数が3回を超過した場合
| 手順 | 内容 |
|---|---|
| 1 | レビュワーがMRに escalation ラベルを付与 |
| 2 | PMにメンション付きコメントで通知 |
| 3 | PMが状況を確認し、以下のいずれかを判断 |
PMの判断オプション:
| 判断 | 内容 |
|---|---|
| 追加FB許可 | FB回数上限を引き上げて継続 |
| ペアレビュー | 作成者とレビュワーで同期的にレビュー実施 |
| 設計見直し | Issue要件・設計の見直しが必要と判断 |
| 担当者変更 | 実装担当者またはレビュワーの変更 |
2.7 マージ実行
マージ条件（全て必須）:
- [ ] CI パイプラインが全てパスしている
- [ ] レビュワー1名以上が Approve している
- [ ] 未解決の Discussion がない
- [ ] ターゲットブランチとのコンフリクトがない
マージ方式: Squash and Merge（推奨）
3. ラベル運用
| ラベル | 用途 | 付与タイミング |
|---|---|---|
review::ready | レビュー準備完了 | CI通過後、レビュワーアサイン時 |
review::in-progress | レビュー中 | レビュワーがレビュー開始時 |
review::changes-requested | 修正依頼中 | FB発行時 |
review::approved | 承認済み | Approve 時 |
review::escalation | エスカレーション | FB 3回超過時 |
4. 期限管理サマリー
| イベント | 期限 | 超過時の対応 |
|---|---|---|
| レビュー開始 | MR提出後 3営業日以内 | PM通知 → レビュワー再アサイン |
| FB修正 | FB受領後 2営業日以内 | PM通知 → 作成者にリマインド |
| 再レビュー | 再提出後 2営業日以内 | PM通知 → レビュワーにリマインド |
| 全体リードタイム目標 | MR作成から 10営業日以内 | PMエスカレーション |
5. GitLab設定要件
プロジェクト設定
Settings > Merge requests:
- Merge method: Squash and merge
- Merge checks:
- [x] Pipelines must succeed
- [x] All discussions must be resolved
- Merge request approvals:
- Required approvals: 1
- [x] Prevent approval by author
- [x] Remove all approvals when commits are added to the source branchMRテンプレート配置
.gitlab/merge_request_templates/default.mdラベル作成
プロジェクト設定でラベルを事前作成する（上記ラベル運用を参照）。