ストーリー

コードレビューの3つの目的

enum ReviewPurpose {
  QUALITY = "品質保証",     // バグの早期発見、設計の改善
  LEARNING = "学習",       // レビュイーの成長、知識の共有
  ALIGNMENT = "整合性",    // コーディング規約、設計方針の統一
}

// テクニカルリードのレビューはこの3つを同時に達成する
interface ReviewComment {
  purpose: ReviewPurpose;
  tone: "directive" | "suggestive" | "educational" | "appreciative";
  content: string;
}

レビューコメントの書き方

Bad: 否定的で理由がない

// Bad
「この書き方はダメです。直してください」

「なぜPromiseを使わないんですか？」

「この変数名はおかしい」

Good: 建設的で理由がある

// Good - 理由 + 提案
「この関数は引数が5つあるので、オブジェクトにまとめると
呼び出し側でパラメータの意味が明確になります。
例: `function createUser({ name, email, role }: CreateUserParams)`」

// Good - 質問形式で気づきを促す
「ここでN+1クエリが発生しそうですが、
もしユーザーが100人いた場合、何回DBアクセスが発生するでしょう？
DataLoaderパターンが使えるかもしれません」

// Good - 良い点の指摘
「このエラーハンドリングの実装、とてもきれいですね。
Result型を使ったパターンがチーム全体の参考になります」

レベル別レビューの焦点

interface ReviewFocus {
  revieweeLevel: string;
  focusAreas: string[];
  avoidAreas: string[];
  commentStyle: string;
}

const reviewByLevel: ReviewFocus[] = [
  {
    revieweeLevel: "ジュニア（L1）",
    focusAreas: [
      "基本的な命名規則",
      "明らかなバグ",
      "テストの存在確認",
      "コーディング規約の遵守",
    ],
    avoidAreas: [
      "高度なデザインパターン",
      "パフォーマンス最適化",
      "一度に大量の指摘",
    ],
    commentStyle: "具体的な修正例を示す。1PRあたり3-5個に絞る",
  },
  {
    revieweeLevel: "ミドル（L2）",
    focusAreas: [
      "設計の妥当性",
      "エッジケースの考慮",
      "テストの品質",
      "関心の分離",
    ],
    avoidAreas: [
      "好みの問題（フォーマッタに任せる）",
      "些末な指摘が主体になること",
    ],
    commentStyle: "「なぜ」を問いかけ、自分で考えさせる",
  },
  {
    revieweeLevel: "シニア（L3）",
    focusAreas: [
      "アーキテクチャへの影響",
      "チーム全体への波及効果",
      "運用面の考慮",
      "セキュリティの観点",
    ],
    avoidAreas: [
      "実装の詳細への過度な干渉",
      "マイクロマネジメント",
    ],
    commentStyle: "対等な議論。トレードオフについて一緒に考える",
  },
];

レビューの教育効果を高めるテクニック

1. ソクラテス式質問法

答えを直接教えるのではなく、質問で導きます。

## 直接指摘（即効性はあるが学習効果は低い）
「ここはSingle Responsibility Principleに違反しています。
UserServiceからメール送信のロジックを分離してください」

## ソクラテス式（学習効果が高い）
「このUserServiceクラスの責務を数えてみてください。
もしメール送信の仕様が変わった場合、
UserServiceを修正する必要がありますよね。
この責務を別の場所に移すとしたら、どこが適切でしょうか？」

2. 段階的な指導

## 1回目のレビュー: 重要な問題のみ指摘
「このSQLクエリにインジェクションの脆弱性があります」

## 2回目のレビュー: 設計レベルの提案
「この部分、Repositoryパターンを使うとテスタビリティが上がります」

## 3回目のレビュー: 発展的な提案
「ここにキャッシュを入れるとパフォーマンスが改善しそうです」

3. 良い点の指摘を忘れない

## レビューに含めるべき内容の比率
- 問題の指摘: 40%
- 改善の提案: 30%
- 良い点の指摘: 20%
- 質問・議論: 10%

レビュー効率を上げる仕組み

// PRテンプレートの例
const prTemplate = `
## 概要
<!-- 変更の目的を1-2文で -->

## 変更内容
<!-- 箇条書きで -->

## テスト方法
<!-- 動作確認の手順 -->

## スクリーンショット（UIの場合）

## チェックリスト
- [ ] テストを追加/更新した
- [ ] ドキュメントを更新した（該当する場合）
- [ ] セルフレビューを完了した
`;

まとめ

チェックリスト

• コードレビューの3つの目的を理解した
• レベル別の指摘の焦点を把握した
• ソクラテス式質問法を実践できる
• レビュー効率を上げる仕組みを学んだ

次のステップへ

次は「ペアプロ・モブプロの実践」を学びます。レビューよりもリアルタイムで知識を共有する手法を掘り下げましょう。

推定読了時間: 40分