対象試験と出題頻度
レビューは、基本情報技術者・応用情報技術者の午前問題で繰り返し出題される定番テーマです。
「ウォークスルー」「インスペクション」「ピアレビュー」など複数の手法の違いを正確に区別できるかが問われます。ソフトウェアテストと並ぶ品質保証の柱として押さえておきましょう。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「レビューって要するに見直しのこと？テストとどう違うの？」と混乱しがちです。
レビュー（Review）とは、一言で言うと
「設計書やソースコードなどの成果物を複数人で点検し、欠陥や問題点を早期に発見する品質保証活動」
のことです。
イメージとしては、「学校の作文の相互添削」です。
自分一人で書いた作文には誤字脱字や論理の飛躍があっても気づきにくいものです。クラスメイトや先生に読んでもらうことで、初めて「ここが分かりにくい」「ここに矛盾がある」と指摘してもらえます。
レビューも同じで、作った本人には見えない欠陥を、第三者の目を借りて早い段階で見つけ出す活動です。
📊 レビューの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Review |
| 分類 | 静的検証（プログラムを実行せずに行う検証） |
| 主な対象 | 要件定義書、設計書、ソースコード、テスト仕様書 |
| 代表的な種類 | ウォークスルー、インスペクション、ピアレビュー、ラウンドロビンレビュー |
解説
ソフトウェア開発では、欠陥を発見するタイミングが遅れるほど修正コストが跳ね上がります。
要件定義段階で見つかれば数分の修正で済むものも、リリース後に発覚すれば数百万円規模の損失になることがあります。
そこで、プログラムを動かしてテストする前の段階から、成果物そのものを人の目で点検して欠陥を潰す活動が必要になります。これがレビューです。
レビューの代表的な4つの種類
試験で問われる主要な4種類を整理します。それぞれ「進行役」「目的」「形式の厳密さ」が異なります。
| 種類 | 進行役 | 特徴 |
|---|---|---|
| ウォークスルー | 作成者本人 | 作成者が成果物を順を追って説明し、参加者が問題点を指摘する。比較的非公式で柔軟 |
| インスペクション | モデレータ（第三者） | 事前に役割分担し、チェックリストに沿って厳密に欠陥を検出する公式な手法 |
| ピアレビュー | 同僚（peer） | 同じ立場のメンバー同士で行う相互レビュー。コードレビューが代表例 |
| ラウンドロビン レビュー |
参加者全員が交代 | 参加者が順番に司会・指摘役を担う。全員参加を促し、教育効果も高い |
図解：ウォークスルーとインスペクションの違い
試験で最も問われるのが、この2つの違いです。「進行役が誰か」を軸に整理します。
🚶 ウォークスルー
✅ 作成者が成果物を読み上げる
✅ 参加者がその場で疑問・指摘
✅ 非公式で気軽に実施
✅ 早期の問題発見が目的
🔍 インスペクション
✅ 第三者（モデレータ）が進行
✅ チェックリストで体系的に検証
✅ 公式・厳密な手続き
✅ 欠陥の網羅的検出が目的
▲ 「誰が司会を務めるか」がこの2つを見分ける最大のポイント
レビューの効果：欠陥の早期発見によるコスト削減
欠陥は発見が遅れるほど、修正にかかる費用が指数関数的に増加します。
レビューを導入する最大の理由はここにあります。
📈 工程別 欠陥修正コストの目安（要件定義時を1とした相対値）
| 要件定義 | 設計 | 実装 | テスト | 運用 |
|---|---|---|---|---|
| ×1 | ×3 | ×10 | ×30 | ×100 |
▲ 運用開始後に発覚した欠陥の修正コストは、要件定義段階の約100倍。上流でのレビューがコスト削減の鍵
レビューとテストの違い
初学者が混同しやすいのが、レビューとテストの関係です。両方とも「品質を高める活動」ですが、性質が異なります。
| 観点 | レビュー | テスト |
|---|---|---|
| 検証方法 | 静的検証（実行しない） | 動的検証（実行する） |
| 対象 | 仕様書・設計書・ソースコード | 動作するプログラム |
| 実施タイミング | 各工程の終了時（上流〜下流） | 実装後 |
| 発見できる欠陥 | 論理矛盾、仕様の抜け漏れ、可読性 | 実行時の不具合、性能問題 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 レビューの核心を3行で
・成果物を複数人で点検し欠陥を早期発見する静的検証活動
・代表的な手法はウォークスルー（作成者主導）とインスペクション（モデレータ主導）
・上流工程での欠陥発見はコスト削減に直結する
試験ではこう出る！
レビューは、FE・APの午前問題で各レビュー手法の特徴を見分ける問題として頻出しています。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP H29春 午前 問46 |
インスペクションの説明として正しいものを選ぶ問題。 | ・「モデレータが進行役」「公式な手続き」がキーワード ・ウォークスルーや机上デバッグの説明がひっかけ |
| FE H30秋 午前 問48 |
ウォークスルーの特徴を選ぶ問題。 | ・「作成者が主導」「比較的非公式」が決め手 ・第三者主導の選択肢はインスペクションを指す |
| AP R元秋 午前 問46 |
ラウンドロビンレビューの特徴を問う問題。 | ・「参加者が持ち回りで司会・記録を担当」が正解 ・他のレビュー手法との混同を狙う構成 |
| FE R3春 午前 問46 |
デザインレビューの目的を問う問題。 | ・「設計工程の成果物に対する欠陥検出」が正解 ・進捗管理・要件定義の選択肢はひっかけ |
📝 IPA試験での出題パターン
パターン1：「各手法の特徴を選べ」
ウォークスルー・インスペクション・ラウンドロビンレビューの説明文が並び、指定された手法に該当するものを選ぶ形式。「進行役が誰か」「公式か非公式か」が見分けの鍵。
パターン2：「インスペクションの特徴」一本釣り
「モデレータ」「チェックリスト」「公式な手続き」というキーワードを含む選択肢が正解。最も体系化された手法であるため、出題者が好んで取り上げる。
パターン3：「デザインレビュー」の目的
設計工程の成果物に対するレビューを指す用語として出題される。実装後ではなく設計段階で行う点に注意。
深追いは不要です。各手法の「進行役」と「公式度」だけ押さえれば得点できます。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発における「インスペクション」の説明として、最も適切なものはどれでしょうか？
- A. モデレータと呼ばれる第三者が進行役を務め、チェックリストに基づいて成果物の欠陥を体系的に検出する公式なレビュー手法。
- B. 成果物の作成者自身が司会となり、参加者に内容を順に説明しながら問題点の指摘を受ける、比較的非公式なレビュー手法。
- C. 参加者が持ち回りで司会と記録を担当し、全員が均等に意見を述べる機会を持つレビュー手法。
正解と解説を見る
正解：A
解説：
インスペクションは、モデレータと呼ばれる第三者が進行役を担い、事前に役割分担とチェックリストを準備したうえで欠陥を網羅的に検出する、最も体系化・公式化されたレビュー手法です。
選択肢Bはウォークスルーの説明です。作成者本人が司会を務め、非公式に進める点がインスペクションとの大きな違いです。選択肢Cはラウンドロビンレビューの説明です。参加者が役割を順番に交代する点が特徴で、教育効果を狙う場面で用いられます。
よくある質問（FAQ）
Q. レビューの参加者には誰を呼ぶべきですか？
対象成果物に応じて変わります。設計書のレビューであれば、上流の要件定義担当者（仕様の妥当性確認）、下流の実装担当者（実現可能性の確認）、テスト担当者（テスト容易性の確認）を呼ぶのが定石です。インスペクションでは、これに加えてモデレータ・記録係・読み手といった役割を事前に割り当てます。一方、ピアレビューは同じ立場のエンジニア同士で行うため、役割分担は緩やかです。
Q. コードレビューとインスペクションは同じものですか？
広い意味では重なりますが、運用の厳密さが違います。コードレビューは現場で日常的に行われるピアレビューの一形態で、GitHubやGitLabのプルリクエスト機能を使った非同期のレビューも含まれます。インスペクションはチェックリストや役割分担を伴う公式な手続きで、安全性が重視される業界（医療機器・航空宇宙など）で採用されることが多い手法です。
Q. デザインレビューと設計レビューは違いますか？
同じ意味で使われます。デザインレビュー（DR）の「デザイン」は意匠デザインではなく「設計」を指す英語です。基本設計DR・詳細設計DRのように、設計工程の節目で実施されるレビューを指します。FE R3春 午前問46で「デザインレビュー」が出題された際も、設計成果物の欠陥検出を目的とする活動として問われました。
Q. レビューで指摘が多すぎて作成者が落ち込みます。改善策はありますか？
レビューは「人を評価する場」ではなく「成果物を改善する場」だという文化を組織で共有することが重要です。指摘は人格ではなく成果物に向けるルールを明文化し、肯定的なフィードバックも含めるよう運用します。また、レビューの目的を「欠陥検出」に絞り、設計判断の議論や教育は別の場（モブプログラミングやペアプロ）で行うと、レビュー時間が短く建設的になります。
Q. 静的解析ツールはレビューの代わりになりますか？
補完関係であり、代替にはなりません。静的解析ツール（SonarQubeやESLintなど）は構文ミス・コーディング規約違反・既知のバグパターンを機械的に検出できますが、仕様の妥当性や設計判断の良し悪し、業務ロジックの抜け漏れは判定できません。ツールで機械的に検出できる部分はツールに任せ、人間は本質的な議論に集中する分業が現実的です。
