ソフトウェア基本設計～コーディングの各フェーズにおいて、それぞれ複数の関係者が集まり、成果物（各種設計書やソースコード）の曖昧な点や問題点を洗い出すための討議や評論のこと

【 レビューの目的 】
一般に、ソフトウェアの不具合や矛盾は早く発見されたほうが修正コストが小さくなるといわれており、不具合や矛盾を早い段階で検出することがレビューの目的である。コードレビューであれば、テストよりも早く不具合や問題を検出すること、デザインレビューであれば、コーディングよりも早く不具合や問題を検出することが目的となる。また、実際に修正コストが小さくなる場合がある。
レビューはシステム開発における「要件定義」や「基本設計」などの工程ごとに実施する。成果物が仕様や機能の誤りを抱えたまま、プロジェクトを次の工程に進めることがないよう、チェックする

• デザインレビュー
  デザインレビューは要求定義、外部設計、内部設計などの設計段階で仕様に不備や矛盾がないか確認するための方法
• コードレビュー
  プログラムのミスや問題点を見つけるための方法。

【 レビューの対象 】
国内でレビューというとSIerでは設計書のレビューが、組込み系ではコードレビューを指していることが多いように思う。学術分野ではコードレビューの割合が高いように思う。以下はその代表ではあるが、障害時の対応フローやプリセールス用の資料もレビューの対象となりうる。

• 要求仕様
• 設計書
• ソースコード
• テスト仕様、設計書、テストケース

【 レビューの種類 】

レビューは基本的に、以下の流れで進行する。まずレビューを受ける側が成果物を持ち込む。作り手は成果物の中身を説明。成果物の依頼側はレビュアとして説明に対する質問を投げ、それに作り手が答える。すべての成果物に目を通した結果、成果物に問題がないことを確認できれば、その工程は「完了」となり、プロジェクトは次の工程に進む。 問題が見つかった場合、解決方法をレビューの場で話し合う。検討結果にしたがい対策を講じ、後日再びレビューを開く。すべての問題に解決のメドが立つまで、レビューを繰り返すのが理想だ。

• インスペクション
  最も体系的で、各参加者に特定の役割を与え、多段階のプロセスが存在するなど厳格なレビュー。作成者以外のモデレータと呼ばれる管理者(専門家)が会議を主導し他の参加者と検討する。チェックリストの使用、分析の実施なども行う。
• ウォークスルー
  作成者が作業成果物を開発メンバへ説明し、コメントを求める。開発者自身が手順を追い、仕様書やプログラムを確認しながらミスや問題点を発見しようとする方法。
• チームレビュー
  複数のメンバーが参加し確認。計画され、定義された手順に従って実施される。
• ペアレビュー(ペアプログラミング)
  作成者とレビューア（１人）がペアを組み作業成果物を確認。
• パスアラウンド
  多重且つ同時進行型のチェック。電子メールなどを活用し、作成成果物のコピーを何人かに配布し、複数のフィードバック（コメント）を依頼。
• アドホックレビュー
  計画的なレビューというよりも、必要に応じて対応できる同僚などへ確認してもらう即席レビュー。特に記録を作成するなど管理的機能はない。
• ピアレビュー
  一人で机上で作業成果物の欠陥と改善の機会を探す。

1. 平成23年度春期　問47　　レビュー
2. 平成20年度春期　問46　　レビュー
3. 平成18年度春期　問43　　レビュー
4. 平成14年度春期　問53　　レビュー
5. 平成12年度春期　問64　　ウォークスルー