成果物の性質に応じてレビューアーが観点を切り替える戦術
成果物の性質に応じてレビューアーが観点を切り替える戦術
コードレビューにおいて「何を見ればよいか」は、レビュー対象（成果物）の性質によって大きく異なる。
全てのPRに対して同じテンプレートのような観点で接していては、重要な問題を見逃し、一方で些末なスタイル指摘に時間を使うという非効率が生じる。
このマニュアルでは、レビュー対象の性質を分類し、それぞれに適した観点・質問・注意点をレビューアーが切り替えて運用する方法を構造化して解説する。
1. なぜ観点を切り替える必要があるのか
レビュー対象には多様な「性質」がある。例えば以下のようなコードは、それぞれ全く異なる目的と失敗リスクを持つ。
| 成果物の例 | 主目的 | 主な失敗リスク |
|---|---|---|
| ユーティリティ関数 | 汎用性と安全性 | エッジケース未対応、型不整合 |
| UIコンポーネント | 表示と動作の整合性 | レンダリング不具合、アクセシビリティ欠如 |
| バッチ処理 | 自動化と安定性 | リトライ不能、スケジューリング漏れ |
| DBマイグレーション | スキーマの整合 | データ損失、ロールバック不能 |
これらに一様な観点でレビューしてしまうと、リスクの本質を見逃す可能性がある。
たとえば、UIコンポーネントに対してはユーザー操作の流れやARIA属性などの非機能要件が重視される一方で、ユーティリティ関数では型安全性と入力制約の網羅性こそが重要になる。
2. 成果物をどう分類するか：レビュー対象の5分類
レビューアーが観点を切り替えるためには、まずレビュー対象の性質を見極める必要がある。ここでは実務で頻出する5種類の成果物を定義する。
(1) ロジック・ユーティリティ系
- 目的：抽象度が高い汎用関数・変換処理
- 例：
parseDate(),calculateTax(),normalizeString()
ユーティリティ関数とは、特定の業務文脈に依存しない、再利用可能な補助的処理ロジックを指す。
(2) UIコンポーネント・表示系
- 目的：ユーザーに情報を提示し、操作を受け付ける
- 例：
UserCard.vue,Button.tsx,Tooltip.js
(3) 非同期・外部I/O系
- 目的：API連携やファイル操作など、外部環境とやり取りする
- 例：
fetchUserData(),uploadFile()
(4) バッチ・バックグラウンド処理系
- 目的：定期実行、自動処理の安定性と運用性
- 例：夜間集計処理、メール送信バッチ、キュー処理
(5) データベースマイグレーション・DDL系
- 目的：スキーマやデータの構造変更、永続化の制御
- 例：
add_column_users.sql,20240501_migrate_orders.rb
3. 分類別レビュー観点チェックリスト
(1) ロジック・ユーティリティ系：再利用性と安全性を中心に
function toUpperTrim(input: string): string {
return input.trim().toUpperCase();
}
@Reviewer空文字やnullが入力された場合の挙動が未定義です。型で制約するか、ガード節が必要ではないでしょうか。
(2) UIコンポーネント系：視覚とインタラクションの整合を重視
<button onClick={submitForm}>
提出
</button>
@Reviewer`button`タグですが、`type="submit"`や`aria-label`などがなく、フォームの意図やスクリーンリーダー対応が不足しています。
(3) 非同期・I/O系：例外・不安定性への備えが主眼
async function loadItems() {
const res = await fetch("/api/items");
return await res.json();
}
@Reviewer`res.ok`やステータス判定がなく、失敗時に`await res.json()`で例外が発生します。明示的なエラーチェックを推奨します。
(4) バッチ・バックグラウンド系：運用時の障害予防に注目
function sendDailyReport() {
const report = buildReport();
email(report);
}
@Reviewer`email()`関数が複数回呼ばれた場合、同一レポートが重複送信される懸念があります。呼び出し状況に応じた制御が必要です。
(5) DBマイグレーション系：不可逆性と影響範囲への配慮が重要
ALTER TABLE users ADD COLUMN email TEXT UNIQUE;
@ReviewerNULLが既存行に混入していた場合、UNIQUE制約でマイグレーションが失敗する可能性があります。事前クレンジング処理が必要です。
4. 成果物が混在するPRへの対応戦術
現場のPull Requestは、1つの成果物だけに閉じているとは限らない。
典型的には以下のような「複合型PR」が提出されることが多い。
- UIコンポーネント + バリデーションユーティリティ
- DBマイグレーション + バッチ処理
- APIエンドポイント + ロギック修正 + テスト追加
問題点：一つの観点で全体を評価してしまう
@Reviewer: UIは問題なさそうですね！このようにUIの表示が意図通りかどうかだけを見て「OK」とするレビューは、裏側で起きているバグや型の不整合、スキーマの破壊に目が向いていない可能性がある。
解決策：PR説明と変更ファイルを照らし合わせ、分類・観点を分ける
- 新UI`ProductCard`を追加しました（ARIA対応済）
- 数量入力にバリデーションユーティリティ`validateCount()`を新設しました
- `products`テーブルに`stock_level`を追加しました（nullable）@Reviewer: `validateCount()`は空入力やマイナス数値に対する処理が含まれていますか？単体テストとUI連携のテスト両方確認させてください。このように成果物ごとに分類し、それぞれのリスク・観点に基づいたコメントを残すことで、「どこをどう見たか」が明確になる。
5. レビューアーの思考戦術：成果物別「着眼点」の構造化
観点を切り替えるためには、「何を見よう」と意識しなければならない。以下に、成果物の性質別にレビューアーが取るべき着眼点の切り替え思考を構造化する。
このように、「どの観点でレビューしているのか」を明示的に意識することが、レビューアーとしての力量を高める。
6. 成果物タイプとバグ傾向の対応表
各成果物タイプがどのようなバグを起こしやすいかを明文化しておくことで、レビュー時の「気づき」を増やすことができる。
| 成果物タイプ | 起こりやすいバグ傾向 | 想定される深刻度 |
|---|---|---|
| ユーティリティ関数 | 型不一致、null処理漏れ、負荷劣化 | 中〜高 |
| UIコンポーネント | 描画崩れ、操作不能、アクセシビリティ欠如 | 高 |
| バッチ処理 | 非冪等化、例外時に止まらない、過剰リトライ | 高 |
| マイグレーション | データ破壊、再実行不能、性能劣化 | 極めて高 |
| 非同期I/O | タイムアウト、await漏れ、意図しない並列処理 | 中〜高 |
7. 実務対策：観点切替をレビュー文化として定着させるには
レビューアー個人が努力して観点を変えるだけでは限界がある。組織としてレビュー観点の共有文化を作ることで、「属人性の排除」と「レビュー品質の平準化」が可能となる。
施策1：PRテンプレートに成果物タイプ記入欄を設ける
- [x] ユーティリティ関数
- [x] UIコンポーネント
- [ ] バッチ処理
- [ ] DBマイグレーション
- [x] 非同期処理→ レビュワーがどの観点で確認すべきかが明確になり、初動が早くなる。
施策2：レビュー観点マトリクスをチーム内で共有
[UIコンポーネント]
- 表示が意図通りか
- 操作不能パスはないか
- ARIA属性とDOM構造の整合
[ユーティリティ関数]
- 入力エラー耐性
- 型と境界の堅牢性→ 経験の浅いレビューアーでも見落としが減る
施策3：レビューコメントのログ蓄積と観点の抽出
- 高品質なレビューコメントを定期的に収集
- 「この指摘はUI系」「これは非同期系」などの分類付け
- 新人レビューアーへの教育資料として再利用
8. 観点の切替がレビューの再現性を生む
「どこを見るか」は属人的であってはならない。観点の切替を成果物の性質に応じて構造的に整理しておくことで、レビューの再現性・品質を標準化できる。
また、観点の切替はレビュワーの判断の説得力を高める。「なぜここにコメントをつけたのか」が説明できるレビューは、指摘された開発者にも納得感が伝わる。
@Reviewer: この関数は汎用的に使われるため、入力チェックとnull安全を保証することが将来的なバグ予防になります。このようなコメントが増えると、コードレビューが単なる指摘から設計の思考共有へと進化していく。
9. まとめ：観点切替は「プロの技術」そのものである
コードレビューとは「コードに潜む危険性と設計の意図を見抜く作業」である。
そのためには、成果物の性質に応じて自らの視点を切り替え、適切な観点で適切な深さで評価する能力が求められる。
本マニュアルでは、以下の3点を主軸に構造化した：
- 成果物タイプを5分類で定義
- 各タイプに応じたレビュー観点・バグ傾向を明示
- 実務での観点切替方法とチーム内の運用戦術を整理
これらを活用し、レビュワー自身が観点を「切り替えられる人」であることを意識することが、
高品質で実務に強いレビューを生み出す土台になる。