対象試験と出題頻度
デザインレビュー（DR）は、基本情報技術者・応用情報技術者の午前で出題されるテーマです。
ソフトウェア開発工程における品質管理活動として定番化しており、「ウォークスルー」「インスペクション」など他のレビュー手法との違いや、各工程で実施されるレビュー（要件定義レビュー・基本設計レビュー等）の位置づけが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「デザインレビューって、ただの設計会議と何が違うの？」と混乱しがちです。ここをはっきりさせましょう。
デザインレビュー（Design Review：DR）とは、一言で言うと
「各工程の設計成果物を、開発者以外も含む関係者で評価し、欠陥や改善点を早期に洗い出す公式な会議」
のことです。
イメージとしては、「家を建てる前の設計図チェック会」です。
家が完成してから「柱の位置がおかしい」と気付いても、もう取り返しがつきません。だから建築士・施主・大工・電気屋が集まり、図面の段階で「ここに窓は無理」「動線がおかしい」とツッコミを入れます。
デザインレビューも同じで、コードを書く前の設計段階で問題を見つけ、後工程の手戻りを防ぐ活動です。
📊 デザインレビューの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Design Review（DR） |
| 分類 | 品質管理活動／検証技法 |
| 主な実施工程 | 要件定義・基本設計・詳細設計の各完了時 |
| 主な目的 | 設計欠陥の早期発見、品質確保、関係者の合意形成 |
解説
ソフトウェア開発では、上流工程で混入した欠陥ほど発見が遅れるとコストが跳ね上がります。
バリー・ベームの研究では、要件段階で見つければ1の修正コストが、運用後に見つかると最大100倍以上になると報告されています。
そこで、各工程の終わりに設計成果物を関係者で点検し、次工程に欠陥を持ち越さないチェックポイントを設けます。これが今回の主役です。
📈 欠陥発見コストの工程別比較（イメージ）
※ 上流ほど安く直せる。だから設計段階のチェックが重要。
工程ごとに実施されるレビュー
DRは1回だけ行うものではなく、各工程の終わりに段階的に行います。
| 工程 | レビュー名 | 主な確認観点 |
|---|---|---|
| 要件定義 | 要件レビュー（SRR） | 利用者要求の網羅性・実現可能性 |
| 基本設計 | 基本設計レビュー（PDR） | アーキテクチャ・外部仕様・性能 |
| 詳細設計 | 詳細設計レビュー（CDR） | モジュール構造・内部仕様・実装可否 |
図解：DRは工程の「合否判定ゲート」
DRは単なる「工程の区切り」ではなく、次工程へ進めるかどうかを判定する関所のような役割を持ちます。
合格すれば次へ進み、不合格なら前工程に差し戻して修正します。
要件定義書
実現可能性
✅合格で次へ
基本設計書
性能要件
✅合格で次へ
詳細設計書
実装可否
✅合格で次へ
コーディング
❌ 不合格だった場合
▲ DRは工程ごとの「合否判定ゲート」。各DRで見る観点は工程によって異なる
参加者の役割
レビューを機能させるには、役割分担が決まっていることが重要です。
「設計者と上司の二人で見て終わり」では効果が出ません。
| 役割 | 担当内容 |
|---|---|
| モデレータ（司会） | 進行管理。議論が脱線しないよう統制する |
| 作成者 | 設計成果物を作った当事者。質問に回答する |
| レビューア | 第三者視点で問題点を指摘する |
| 記録者 | 指摘事項と対応方針を議事録に残す |
他のレビュー手法との比較
DRは「設計成果物を対象とする公式レビュー」の総称ですが、進め方の違いでさらに細分化されます。試験ではこの分類が頻出です。
| 手法 | 主導者 | 特徴 |
|---|---|---|
| ウォークスルー | 作成者 | 作成者が成果物を説明しながら進める非公式なレビュー |
| インスペクション | モデレータ | 役割分担とチェックリストを使う、最も公式・厳格な形式 |
| ラウンドロビン | 参加者全員 | 参加者が順番に司会・指摘役を回す形式 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 デザインレビューの核心を3行で
・各工程の設計成果物を関係者で評価し、欠陥を早期発見する公式会議
・要件・基本設計・詳細設計の区切りで実施し、後工程の手戻りを防ぐ
・モデレータ／作成者／レビューア／記録者の役割分担で機能する
試験ではこう出る！
FE・APの午前問題では、レビュー手法の比較問題と、DRそのものの目的・観点を問う問題の2系統が出題されています。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H29春 午前 問46 |
デザインレビューを実施する目的として適切なものを選ぶ問題。 | ・「設計上の誤りや問題点を早期に発見する」が正解 ・進捗管理や工数見積もりはひっかけ |
| FE H27秋 午前 問49 |
レビュー手法の説明と名称の組合せを問う問題。 | ・ウォークスルー／インスペクション／ラウンドロビンの違い |
| AP H24春 午前 問50 |
基本設計工程のDRで確認すべき事項を選ぶ問題。 | ・外部仕様・性能要件の充足が正解 ・コーディング規約遵守は詳細設計以降 |
📝 IPA試験での出題パターン
パターン1：「DRの目的を選べ」
選択肢に「進捗の管理」「工数の見積もり」「テストケースの作成」など別工程の活動が紛れ込む。正解は必ず「設計品質の確保」「設計欠陥の早期発見」系の文言。キーワードは「早期発見」「手戻り防止」。
パターン2：「レビュー手法の名称を選べ」
「作成者が説明しながら進める非公式な形式」→ウォークスルー、「モデレータ主導でチェックリストを使う公式形式」→インスペクション、という対応関係を覚えれば解けます。DR自体は「総称」と捉え、混同しないこと。
ここまででOKです。各レビュー手法の細かな手順や記録様式まで問われることはほぼないので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発におけるデザインレビュー（DR）の説明として、最も適切なものはどれでしょうか？
- A. 完成したプログラムを実行し、入力に対する出力が仕様どおりかを確認するテスト工程の活動である。
- B. 各工程で作成した設計成果物を関係者で評価し、欠陥や改善点を早期に発見する公式な会議である。
- C. プロジェクトの進捗状況を関係者に報告し、スケジュールや工数の見直しを行う管理活動である。
正解と解説を見る
正解：B
解説：
DRは設計段階の成果物（要件定義書、基本設計書、詳細設計書など）を対象に、関係者が集まって欠陥や改善点を洗い出す品質保証活動です。コードを書く前に問題を発見することで後工程の手戻りを最小化します。
選択肢Aはテスト（特にブラックボックステスト）の説明です。完成物の動作確認はDRの対象外で、DRはあくまで設計成果物のレビューに限定されます。選択肢Cはプロジェクト管理の進捗会議の説明です。スケジュールや工数の調整はプロジェクトマネジメントの活動であり、設計品質を評価するDRとは目的が異なります。
よくある質問（FAQ）
Q. デザインレビューとコードレビューは同じものですか？
別物です。DRの対象は設計書などの「設計成果物」で、コードレビューの対象はプログラム「ソースコード」です。実施タイミングもDRは設計工程の終わり、コードレビューは実装工程の中で行います。ただし、両者ともレビュー手法（ウォークスルー、インスペクション等）の進め方は共通しているため、IPA試験では手法の知識を流用して解ける場合があります。
Q. レビューで指摘された欠陥は、その場で修正していいですか？
原則NGです。会議の場では「指摘の記録」と「修正方針の合意」までを行い、実際の修正は会議後に作成者が持ち帰って対応します。理由は、その場で議論を始めると進行が止まり、他の指摘事項が漏れるからです。修正後は再レビューまたは修正確認のみを軽く行うのが一般的です。
Q. アジャイル開発でもDRは行いますか？
行います。ただし形式は変わります。ウォーターフォール型では工程末の重厚な会議として実施しますが、アジャイルではスプリントレビューやデイリーでのペアレビュー、プルリクエストでの相互チェックといった軽量な形に置き換わります。「設計を関係者で評価する」という本質は共通です。
Q. レビューの効果を測る指標はありますか？
代表的な指標は「指摘密度（成果物のページ数あたりの指摘件数）」と「レビュー速度（時間あたりのレビュー量）」です。指摘密度が極端に低い場合はレビューが形骸化している可能性があり、逆に高すぎる場合は成果物の品質そのものに問題がある示唆となります。IPAの「ソフトウェア開発データ白書」でも、レビュー指摘件数と残存欠陥の相関データが公開されています。
