レビューは直訳で「批評」「見直し」という意味を持ち、システム開発・ソフトウェア開発などのIT分野では成果物の品質を検証・討論する場の事を指します。

JSTQBでは、静的テストのレビュープロセスとして、プログラムやシステムを動かさずにできる品質検証方法の一つとして解説されています。

レビューは複数の人がチームを組んで実施します。

チームに参加している各個人にはそれぞれ重要な役割があります。

一般に、以下の5つの役割を持つ人が存在します。

　・マネージャ

　・モデレータ（ファシリテーター）

　・作成者（レビューイ）

　・レビューア

　・書記（記録係）

次項でそれぞれの役割を解説していきます。

1.マネージャ

プロジェクトの全体スケジュール及び進捗状況をもとに、レビュー実施のスケジュールを作成する人。

2.モデレータ（ファシリテーター）

レビューの進行管理を行い、場を取りまとめる人。

3.作成者（レビューイ）

成果物を確認してもらう人。基本的には成果物の作成者の事を指す。

4.レビューア

成果物を確認する人。

5.書記（記録係）

レビューにおける議事録やとりあげられた事項を記録する人。

レビューの種類は以下の4つがあります。

　・非形式的レビュー

　・ウォークスルー

　・テクニカルレビュー

　・インスペクション

次項でそれぞれの内容を解説していきます。

1.非形式的レビュー

非形式的レビューは、一番くだけたやり方です。

ここでいう「形式的」とは、規定のプロセスに則り、スケジュール調整などの手続きを踏み報告書などの成果物を作成することを指します。

したがって「非形式的」レビューは、何もルールが決まっておらず、いつどのように始めても構いません。

例えば同じチームの同僚などに、フランクに「ちょっと見てください」「時間があったら確認して」というような形で声をかけて、すぐ始まりすぐ終わる。

そういったものを非形式的レビューと呼びます。そのため、時間や工数をかけずに簡易に実施できる技法ですが、進行者不在で、運営プロセスなどもない状態で行われるのが特徴です。

参加者は作成者、レビュアーの2種類となり、他のレビューと比べて最も参加者の少ないレビュー形式となります。

2.ウォークスルー

ウォークスルーとは、作成者がレビューしてほしいタイミングで自らレビュアーを集めて実施するレビューのことです。

基本的には成果物の欠陥の検出を目的としていますが、参加者にソフトウェアの処理などに関する内容を学習させ、仕様を理解してもらう事も目的としています。

参加者は基本的に作成者、レビュアー、書記の3種類ですが、状況に応じて書記は作成者が兼任したり、関係者が増える場合もあります。

3.テクニカルレビュー

テクニカルレビューは、レビューを取りまとめるモデレーターが進行役となり行われます。

同僚や技術のエキスパートがレビュアーとして参加し、欠陥の検出だけでなく代替案、解決案の掲示も行います。

参加者は作成者、レビュアー（技術エキスパート）、モデレータ、書記の4種類ですが、モデレータ不在で技術エキスパートとのみ行う場合もあります。

4.インスペクション

テクニカルレビューと同様モデレーターが進行役となりますが、他の3つのレビューよりも厳格にルールやプロセスが定められており、多くのメンバーが参加し、時間をかけて実施します。

成果物の欠陥を見つけるだけでなく、潜在的な欠陥の検出、品質の評価、関係者の学習、根本原因分析による将来的な類似欠陥の防止など、様々な効果が期待できる最も公式性の高いレビュー形式となります。

参加者は作成者、レビュアー（技術エキスパート含む）、モデレータ、書記の4種類ですが、各々の役割が厳格に決まっていて兼任ができないため、レビューの際の成果物を読み上げる「読み手」を用意する場合もあります

インスペクションには6つのステップがあります。

ここからは、計画からフォローアップまでのステップに基づいて、どのようにインスペクションが成り立っているのかを説明していきます。

1.計画

計画においてはどのようにインスペクションを行うのか、その内容を決めていきます。

レビューの基準を定義し、どういった人が必要なのかという人選、そしてどの役割をそれぞれに割り当てるのかということを考えます。

また開始条件、終了条件というものを定義し、今回のレビューターゲットがドキュメントのどの部分であるかというところを決めていきます。

2.キックオフ

計画で選ばれたメンバーを集めてミーティングを行います。

計画での決定事項をドキュメントにして配布し、その内容をメンバーに説明します。

「あなたは○○に詳しいから、このドキュメントのこの部分について○○の観点でしっかり見てほしい」などというように、メンバー一人ひとりにどのような役割が与えられているのかを明確に把握してもらうことがキックオフの大切なポイントです。

3.個々の準備

各担当者が役割と責任を果たすために必要な準備を行います。

行う作業としては、配布された資料を読み、内容を理解しておく必要があります。

そして問題点、質問、コメントをまとめたり、レビューミーティングで利用するチェックリストを作成します。

このとき、静的解析ツールによる問題点の洗い出しや、過去事例および関連する標準類などの調査を行います。

4.レビューミーティング

準備で作成したコメントをもとに、モデレータ、作成者、レビューアで議論します。

書記が議事録を作成します。

レビューミーティングの参加者は欠陥について意見を述べ、欠陥の扱いをどのようにするか意見を示し、どう扱うかについて認識が一致するように努めます。

5.再作業

作成者は、レビューミーティングで作成された課題の一覧をもとに、成果物の修正を行います。

作成者は、修正を行う前に課題を再度検討して、修正が必要な欠陥であるかどうか判断します。

課題については、修正の要否にかかわらず欠陥追跡ツールに登録します。

これによって課題の対処漏れを防ぐ事ができ、将来修正が必要になった時に備える事ができます。

対処不要と判断した理由も欠陥追跡ツールに入力しておくと、将来対応になったときの参考になります。

修正が必要である欠陥は修正を行い、課題の一覧に修正済みと記録します。

6.フォローアップ

修正済みの欠陥については、修正結果の確認をする必要があります。

作成者が課題を正しく理解できない可能性や、欠陥に正しく対処できない可能性は当然あります。

フォローアップは、修正を行った担当者以外の人（たいていはモデレータおよびモデレータが指名した担当者）が、課題及び欠陥を正しく対処したかを検証します。

フォローアップを任された担当者（検証者）は、修正の内容を検討しながら、修正内容の難易度および修正量を勘案しつつ再度レビューが必要であるかの判断も行います。

また、メトリクスの収集も実施し、品質データとします。