ストーリー

レビュープロセスの全体像

interface ReviewProcess {
  // 1. レビュー依頼
  request: {
    author: string;
    reviewers: string[];    // 必須レビュアー
    optionalReviewers: string[]; // 任意レビュアー
    deadline: string;
    priority: "urgent" | "normal" | "low";
    estimatedReadTime: string; // 読了時間の目安
  };

  // 2. レビュー実施
  review: {
    format: ReviewFormat;
    checklist: string[];
    feedbackLevels: FeedbackLevel[];
  };

  // 3. フィードバック反映
  revision: {
    responseDeadline: string;
    resolvePolicy: "author_decides" | "consensus" | "approver_decides";
  };

  // 4. 合意形成
  consensus: {
    quorum: string;      // 最低承認数
    vetoPolicy: string;  // 拒否権の扱い
    escalation: string;  // 合意に至らない場合
  };
}

type ReviewFormat = "async_written" | "sync_meeting" | "hybrid";

interface FeedbackLevel {
  label: string;
  description: string;
  actionRequired: boolean;
}

フィードバックの標準化

レビューコメントにラベルを付けることで、意図を明確にします。

## フィードバックラベル

### BLOCKER（対応必須）
重大な問題。対応しないとApproveできない。
> [BLOCKER] このAPIはN+1問題を引き起こす。DataLoaderの導入が必要。

### CONCERN（懸念）
重要な懸念。対応するか、対応しない理由の説明が必要。
> [CONCERN] Elasticsearchのバージョンアップ時の互換性は考慮済みか？

### SUGGESTION（提案）
改善案。採用は著者の判断に任せる。
> [SUGGESTION] ここはStrategy Patternを使うと拡張しやすくなるかも。

### QUESTION（質問）
理解のための質問。回答があればOK。
> [QUESTION] CDCの遅延が5秒を超えた場合のフォールバックは？

### NIT（些末な指摘）
文法ミスやスタイルの問題。対応は任意。
> [NIT] 図のラベルが一部英語と日本語が混在しています。

設計レビューのチェックリスト

const designReviewChecklist = {
  architecture: [
    "単一責任の原則に従っているか",
    "コンポーネント間の依存関係は適切か",
    "障害の影響範囲が限定されているか",
    "スケーラビリティのボトルネックはないか",
  ],
  api: [
    "RESTful の原則に従っているか",
    "エラーレスポンスの形式は統一されているか",
    "バージョニング戦略は明確か",
    "レート制限は考慮されているか",
  ],
  data: [
    "データモデルは正規化されているか（適切に）",
    "インデックス戦略は定義されているか",
    "データの整合性はどう保証するか",
    "バックアップとリカバリの計画はあるか",
  ],
  security: [
    "認証・認可は適切に設計されているか",
    "入力バリデーションは実装されるか",
    "機密データの暗号化は考慮されているか",
    "SQLインジェクション等の対策はあるか",
  ],
  operations: [
    "モニタリングとアラートは計画されているか",
    "ログは十分に出力されるか",
    "ロールバック手順は明確か",
    "パフォーマンスの目標値は定義されているか",
  ],
};

レビュー会議の運営

非同期レビューだけでは解決しない場合、同期的なレビュー会議を開きます。

## 設計レビュー会議のアジェンダ（60分）

### 事前準備（会議の前に）
- 全員がRFCを読了済み
- コメントは事前に非同期で投稿済み
- 未解決のBLOCKER/CONCERNを整理

### 会議
1. **著者による概要説明（10分）**
   - 変更点のサマリー（前回レビューからの修正）
   - 未解決の論点の提示

2. **BLOCKER の議論（25分）**
   - 各BLOCKERについて議論し、解決策を合意
   - 合意に至らない場合はApproverが判断

3. **CONCERN の議論（15分）**
   - 優先度の高い懸念から議論

4. **アクションアイテムと次のステップ（10分）**
   - 修正事項の確認
   - 次のレビューの日程（必要な場合）
   - Accept/Rejectの判断

### ルール
- 新しい論点は会議後に非同期で投稿する
- タイムキーパーを指名する
- 議事録を残す

レビュー文化の構築

まとめ

チェックリスト

• レビュープロセスの4段階を説明できる
• フィードバックラベルの使い分けを理解した
• 設計レビューのチェックリストを把握した
• レビュー会議の運営方法を学んだ

次のステップへ

次は演習です。実際にADRとRFCを書いてみましょう。

推定読了時間: 25分