コードレビューのフェーズとレビューアーの対応技術
コードレビューのフェーズとレビューアーの対応技術
コードレビューは一度きりの作業ではありません。
フェーズごとに異なる焦点があり、それに応じてレビューアーの役割や見るべき観点も変化します。
このマニュアルでは、コードレビューを「設計レビュー」「実装レビュー」「統合レビュー」「運用前レビュー」の4フェーズに分け、それぞれで求められるレビュー技術、レビューアーの判断、実務ノウハウを体系的に整理します。
1. コードレビューを“フェーズで分ける”意味
なぜレビューを段階化する必要があるのか
レビューは単なる「コードの正誤チェック」ではありません。
仕様・設計・実装・統合・運用といった各段階において、レビュー対象の本質は変わります。
- 設計段階 →「作ろうとしているものは妥当か？」
- 実装段階 →「設計どおりに作られているか？」
- 統合段階 →「他モジュールと正しく連携できているか？」
- 運用前 →「プロダクション品質を満たしているか？」
レビューアーは、これらの変化を理解しないと「フェーズに合わないコメント」をしてしまいがちです。
2. フェーズ1：設計レビュー（仕様・責務・設計思想）
主なレビュー対象
- ユースケース仕様（フロー・異常系）
- コンポーネント設計図（クラス/モジュール分割）
- データ構造の設計（型・制約）
- 非機能要件の実装方針（パフォーマンス・セキュリティなど）
レビューアーが身につけるべき視点
| 項目 | 重要な観点 |
|---|---|
| ユースケース設計 | 入力・出力・異常系の網羅性 |
| 責務分担 | 単一責任原則（SRP）に基づく構造化 |
| データ設計 | 型の正確性、制約の適用範囲 |
| 非機能要件 | ボトルネック予測・エラーリカバリ設計 |
オブジェクト指向設計原則のひとつで、「1つのクラス（モジュール）は1つの責務だけを持つべき」とする設計思想。設計レビュー時には重要な観点。
コメント例
@Reviewer: このモジュールの責務が広すぎる印象があります。仕様Aと仕様Bをそれぞれ分けたクラスにできないかご検討ください。3. フェーズ2：実装レビュー（構文・ロジック・パターン）
主なレビュー対象
- 関数・クラスのロジック整合性
- 命名・責務・可読性
- コーディング規約違反
- セキュリティ脆弱性
使用されるレビュー技術・観点
| 技術 | 観点 | 目的 |
|---|---|---|
| 静的解析 | ルール違反、構文誤り | 表面的な品質担保 |
| ロジックトレース | 条件分岐、例外処理 | 意図どおりに動くかの確認 |
| デザインパターン適用 | Singleton, Factory 等 | 構造的な意図の読み取り |
コメント例
+ function processUser(user: User): void {@Revieweruserがnullの場合の処理が抜けていませんか？他の関数と違い明示的なガードが見当たりません。 // 中略
}4. フェーズ3：統合レビュー（API・境界・連携）
このフェーズでは「モジュール間のつなぎ」に注目します。
主な対象
- 外部APIやDBとの接続インタフェース
- 他チームが作成したモジュールとの結合部
- 境界オブジェクトや変換処理
レビュー技術と注意点
- スキーマ整合性の確認（OpenAPI等）
- 境界における null やエラーの処理統一
- 型の不整合やデータの漏れをレビュー対象とする
@Reviewer: このAPIレスポンスが仕様のバージョンとズレています。v2.1の定義では statusCode が enum になっているはずです。- 外部APIの出力形式が微妙にズレている
- 命名変更が他ファイルに波及して不整合を生んでいる
- 小さな仕様変更による“副作用”が生じている
5. フェーズ4：運用前レビュー（本番想定・異常系・エラーハンドリング）
このフェーズでの着眼点
| 観点 | 内容 |
|---|---|
| ログ | 設計思想に合った粒度とフォーマットか |
| リトライ | 想定される失敗に対応できているか |
| モニタリング | アラート・メトリクスの設計有無 |
| エラーハンドリング | 原因追跡可能な構造か |
コメント例
@Reviewer: catch句でログ出力がされていますが、ユーザー側エラーとシステム障害を区別できるようログレベルを分けておくべきかと思います。6. フェーズ別レビュー観点比較表（サマリ）
| フェーズ | 主な対象 | レビュー観点 | 使用技術 | コメントの焦点 |
|---|---|---|---|---|
| 設計 | ユースケース、クラス設計 | 責務分離、網羅性、非機能設計 | UML, SRP, 要件仕様書 | なぜこう設計するのか？意図は明確か？ |
| 実装 | 関数、構文、ロジック | 可読性、一貫性、脆弱性 | Linter, 静的解析, 言語知識 | 設計に沿っているか？変な癖がないか？ |
| 統合 | API, 境界, 外部接続 | 型整合性、失敗処理、変換 | OpenAPI, DB schema, REST原則 | 仕様どおりか？データが壊れないか？ |
| 運用前 | ログ、例外、監視 | 可観測性、安全性、冗長性 | モニタリング設計, ログ基準 | トラブル時に運用が困らないか？ |
7. レビューアーが持つべき「フェーズの読解力」
フェーズごとにレビューの視点を切り替えるには、レビューアー自身が「このPRはいま何フェーズか？」を読み解く力が必要です。
PRタイトルや説明文から推察する
【Feature】新規ログイン画面の追加 → 実装レビューが主
【Refactor】UserServiceの責務整理 → 設計＋実装レビューが主
【Fix】認証トークン未削除バグ修正 → 実装＋統合レビューが主レビューアーは、PRの目的から「必要なフェーズ視点」を自分で補完する判断力が求められます。
8. フェーズに応じて「コメントのトーン」も変える
レビューの目的が違えば、伝えるべき内容やコメントの調子も異なります。
| フェーズ | トーン例 | 理由 |
|---|---|---|
| 設計 | やや抽象的で、背景を聞く | 意図が大切なため、否定的表現を避ける |
| 実装 | 具体的、詳細に | ロジックの精度が問われるため |
| 統合 | 仕様準拠を重視 | 客観性と明確な基準が必要 |
| 運用前 | 厳密で再現性重視 | 運用ミスを防ぐ責任がある |
@Reviewer: この例外の扱い方、設計書の方針と異なるように見えますが、意図して変えたのでしょうか？9. フェーズを横断して確認すべき観点
フェーズ別に注目点が異なるとはいえ、以下の観点はすべてのフェーズで繰り返し確認されるべきです。
-
テストの有無と内容
→ 仕様に対する確認ができるか -
命名の一貫性と責務の明確さ
→ 構造が伝わるか -
エラー処理の有無と意味づけ
→ 本番環境で再現できる情報が残っているか -
副作用の管理（ステート、I/O）
→ 意図しない破壊がないか
10. フェーズレビューでよくある失敗と防ぎ方
フェーズ無視で過剰な指摘
- 設計段階で文法エラーを指摘（まだコードがない）
- 実装段階でUXの是非を問う（仕様確定済）
自分の得意フェーズにだけ注力
- インフラ担当が構文だけを見る
- アプリ開発者が運用設計をスルー
レビューアーは「すべてのフェーズを見る」必要はないが、
“自分が今どのフェーズのレビューをしているか”は理解しておく必要がある。
11. フェーズ分離を意識したレビュー文化をチームに根付かせるには
レビュー文化は個人ではなく、チーム全体の合意形成が必要です。
フェーズ表記を導入する（PRテンプレート）
## レビュー対象フェーズ（複数選択可）
- [x] 設計レビュー
- [x] 実装レビュー
- [ ] 統合レビュー
- [ ] 運用前レビュー観点チェックリストを導入する
## チェック項目（実装フェーズ）
- [ ] ロジックの整合性
- [ ] 命名の一貫性
- [ ] 冗長・重複コードの削除12. まとめ：レビューアーはフェーズごとの“翻訳者”である
コードレビューは、ただコードの誤りを探すためにあるのではなく、
「チームがどの段階で、どこをどう確認すべきか」を分解して支援する知的作業です。
レビューアーは、
- 今、これは何のレビューなのか？
- 誰の観点が必要か？
- どの技術が必要か？
を考えながら、各フェーズの“翻訳者”としての役割を果たしていくことが求められます。
これができるようになれば、レビューアーは「レビューする人」から
「開発フェーズの流れを見通して支える人」へと進化していけます。
その進化が、チーム全体の開発品質を支える大きな礎となります。