レビュー戦略

定義

ソフトウェア開発におけるレビューとは、成果物（要件書・設計書・コード・テスト計画等）を人間の目で検査し、欠陥・問題・改善点を発見する品質確保活動。レビュー戦略は「何を・誰が・どのように・なぜレビューするか」を体系的に設計すること。

なぜ重要か

レビューはテストより早い工程で欠陥を検出できる（→シフトレフト）。コードレビューが「なんとなく行われている」状態では、目的が曖昧なため参加者の視点が定まらず効果が低い。ルールが明文化されていないと、レビューの品質がレビュアーによって大きくばらつく。

全量レビューの原則

サンプリングではなく全成果物をレビューする。「重要な部分だけ」「時間があれば」という選択的レビューでは、重要でないと思われていた箇所に致命的な欠陥が潜む。全量レビューを品質確保の基盤として位置づける。

ただし「全量」は工数の問題ではなく仕組みの問題。軽量なチェックリストレビュー・静的解析の組み合わせで全量を効率的にカバーできる。

レビュー目的の5分類

レビュー開始前に「今回のレビューは主に何を目的とするか」を明示することで、参加者が適切な視点で臨める。

W字モデル

開発工程：  要件定義 → 外部設計 → 内部設計 → 実装
              ↓           ↓           ↓         ↓
テスト工程：  ST設計   → IT設計   → UT設計   → テスト実行

開発工程とテスト設計工程を並行して進めることで、テスト設計が要件・設計のレビューとして機能する。内部設計が完了してからテストを設計し始めるのではなく、各工程のアウトプットが出たタイミングでテスト設計を同時に開始する。

レビュールールの明文化

ルールのない状態ではレビュアーによって指摘の質・観点・粒度が異なり、不均一な品質になる。プロジェクト開始時に以下を明文化・周知する：

• チェックリスト（観点の一覧）
• 指摘の優先度分類（必須修正 / 推奨 / 提案）
• レビュー通過基準（何があればマージ可か）
• フィードバックのルール（建設的な表現）

適用場面

• コードレビュー：PRレビューの目的を（欠陥検出 / 知識共有）で使い分け、観点を変える
• 設計レビュー：実装前の設計書レビューで要件との整合性を確認する（シフトレフト最大の機会）
• テスト計画レビュー：テスト範囲・完了基準が品質目標と整合しているか確認する

出典

ソフトウェア品質保証の極意 — 第4章 4.5「レビューのマネジメント」（極意34・35・36）、Column「W字モデル」、Column「手戻りコストの1:10:40:100の法則」