Reviewer culture — 何を妥協し何を妥協しないか

学習のねらい

AI が生成したコードを含む Pull Request(PR)のレビューは、人間のレビュアーにとって重要な役割を担います。 しかし、すべての細かい点にコメントすると、レビュアーもコードを書いた人も疲弊してしまいます。 このレッスンでは、PR レビューにおいて「何を厳しくチェックし、何をある程度許容するか」という境界線を明確にし、効率的かつ教育的なレビュー文化を築く方法を学びます。

レビューの粒度 — Nit と Blocker

PR レビューのコメントは、大きく2つの種類に分けられます。

• Nit(Nitpick): 「枝葉末節」や「些細な指摘」を意味します。
  • 例: 変数名のtypo、コメントの追加、フォーマットの微調整、冗長なコードの改善案など。
  • これらは重要ですが、必ずしも修正しないと動かない、というものではありません。レビュアーは提案として伝え、修正は開発者に任せる、あるいは次のPRで修正する、といった柔軟な対応が可能です。
• Blocker: 「マージをブロックする問題」を意味します。
  • 例: バグ、セキュリティ脆弱性、パフォーマンス劣化、設計原則からの逸脱、要件との不一致、テスト不足など。
  • これらはシステムに重大な影響を与える可能性があり、マージする前に必ず修正が必要です。

この区別をチーム内で明確にし、コメントの際に [Nit] や [Blocker] のように明記する習慣をつけると、レビューがスムーズに進みやすくなります。

AI に通すべきレビュー基準

AI が生成したコードは、人間が書いたコードと同様にレビューが必要です。特に AI 出力に対しては、以下の点を厳しくチェックしましょう。

• 要件の充足: 指示通りの機能が実装されているか、意図しない解釈をしていないか。
• セキュリティ: 脆弱性(例: SQLインジェクション、XSS)がないか、安全なコーディングプラクティスに従っているか。
• テストの網羅性: 重要なパスやエッジケースがテストでカバーされているか。
• パフォーマンス: 不要な計算や非効率なアルゴリズムが使われていないか。
• 依存関係: 不要なライブラリが追加されていないか、既存の依存関係に影響がないか。
• 明確性: AI が生成したコードでも、人間が読んで理解しやすいか。

AI は「動く」コードを生成する能力は高いですが、上記の「品質」や「意図」に関する部分は、人間の目による確認が不可欠です。

教育的レビュー — 成長を促すフィードバック

レビューは単にコードの欠陥を見つけるだけでなく、開発者の成長を促す貴重な機会でもあります。

• なぜそのように修正するのかを説明する: 「ここを直してください」だけでなく、「なぜこの方法が良いのか、どのようなリスクを避けるためか」といった背景を説明すると、開発者の理解が深まります。
• 具体的な改善案を提示する: 問題点を指摘するだけでなく、「〜のように修正すると良いでしょう」と具体的なコード例を示すと、開発者は修正しやすくなります。
• 良い点も褒める: 改善点だけでなく、PR の中で「ここが良かった」「良い設計ですね」といったポジティブなフィードバックも忘れずに伝えましょう。モチベーション向上につながります。
• 質問形式で問いかける: 「〜についてはどう考えていますか？」「このケースだとどうなりますか？」のように質問を投げかけることで、開発者自身に考えさせる機会を与えられます。

レビュアーチャーター(Reviewer Charter)の作成

チームで「何を重視し、何を許容するか」を明文化した「レビュアーチャーター」を作成すると、レビューの基準が統一され、属人性が減ります。 このチャーターには、Blocker の条件と Nit の条件を具体的に記述しましょう。

まとめ

効果的な PR レビューは、チームの生産性とコード品質を向上させます。 Nit と Blocker の区別、AI 出力に対する厳格なチェック基準、そして教育的なフィードバックを意識して、レビュー文化を育てていきましょう。