目次
① なぜ各段階でDRを行うのか？
DR（設計レビュー）は、
不具合を“後工程”に流さないための仕組み
です。
開発では、
- 要求定義
- 基本設計
- 詳細設計
- 実装
- 試験
と段階が進みます。
後工程で見つかるほど、修正コストは指数的に増加します。
(一般に、後工程になるほど修正コストは5〜10倍に膨らむと言われています。)
例：
- 要求段階での修正 → 数時間
- 試験段階での修正 → 数日〜数週間
👉 DRは「出戻り削減」が最大目的。もう一つの目的は「設計の妥当性を客観視すること」です。
② DRの本質は「責任追及」ではない
ここは重要です。
DRは責任を分散する場ではなく品質を上げる場
です。
「連帯責任」という表現は実務では適切ではありません。
③ 正しい考え方
✔ 作成者は説明責任を持つ
✔ レビュアーは指摘責任を持つ
✔ 最終承認者は承認責任を持つ
責任を曖昧にするのではなく、
役割ごとの責任を明確にする
これが正解です。
承認者は「問題があった場合の最終判断責任」を持つ。
④DRで見るべきポイント
要求レビュー
- 要求は曖昧でないか
- 受け入れ基準は明確か
- 前提条件は定義済みか
設計レビュー
- 異常系は網羅されているか
- インターフェースは整合しているか
- 拡張性はあるか
- 制約条件は守られているか
- 想定外の使用条件（ワーストケース）は検討されているか
実装レビュー
- ネストが深すぎないか
- 未初期化変数はないか
- 割込み競合はないか
- 可読性は確保されているか
⑤出戻りをなくすための具体策
① チェックリスト化
② レビュー前に自己レビュー実施
③ レビュー記録を残す
④ 指摘事項を必ずクローズする
⑥ DRは心理的安全性が重要
良いレビュー文化は：
- 個人攻撃しない
- 事実ベースで議論
- 設計にフォーカス
- 感情を入れない
良いレビュー文化は、品質を上げるだけでなく、組織の成長にもつながる。