レビューは全量・目的明示で実施する

ルール

レビューを実施する際は以下を守る：

1. 全量レビュー：サンプリングでなく全成果物をレビューする。「重要でなさそうな部分」ほど見落とし欠陥が潜む
2. レビュー目的の事前明示：レビュー開始前に「このレビューの主目的は何か」を参加者全員で共有する（欠陥検出 / 知識共有 / 設計確認 等）
3. ルールの明文化と周知：レビューの観点・優先度分類・通過基準・フィードバックの作法をチームで合意し文書化する
4. W字モデルの活用：テスト設計を開発工程と並行して行い、テスト設計がそのまま成果物のレビューとして機能させる

理由

目的が不明確なレビューでは参加者の視点が定まらず、同じ成果物でも何人でレビューしても同じ種類の観点しか得られない。「このレビューは知識共有が目的なので、バグ探しより設計意図の理解に集中してほしい」と明示することで、レビュー効果が上がる。

全量レビューを「工数がかかる」と敬遠すると、選択的レビューになり、見逃し欠陥の温床になる。チェックリストと静的解析の組み合わせで全量を効率的にカバーする仕組みが解決策になる。

例外

• 極めて小さな変更（typo修正・変数名変更等）は簡易レビュー（1名・チェックリストのみ）で可
• 緊急ホットフィックス：リリース後に正式レビューを必ず実施することを条件に、事後レビューを許容する
• 自動化で代替できる観点（コーディング規約・型エラー等）は静的解析に任せ、人手のレビューは人間の判断が必要な観点に集中する

出典

ソフトウェア品質保証の極意 — 第4章 4.5「レビューのマネジメント」（極意34・35・36）、Column「W字モデル」