基本原理

　レビューの基本原理を以下に示します。これは、レビューの重要性や認知的不協和のわなからの脱出の必要性を理解した後、「2. ピアレビュー」で説明する内容です。

　まず、作業成果物のレビューであるということです。作成者のレビューではなく、成果物のレビューであることを意識してください。

　2つ目が、レビュー目的に応じて、方法を変更するということです。例えば、問題摘出が目的であるならば、問題点の摘出に集中する（ピアレビュー）べきですし、対策検討が目的であるならば、解決策の検討に集中します。

　3つ目が効率的にピアレビューを実施できるように事前準備するということです。役割分担を明確にすること、実施計画を立てる、ピアレビュー会議の前に事前レビューを行うことなどがあります。

　4つ目が開始時間と終了時間を守るということです。時間内に、予定のレビュー範囲を見終わるようにします。

　一番大切なことは、最初の項目の「作業成果物のレビューを行う」こと、つまり作成者のレビューではないということだと思います。第1回の「図1：よく見かけるレビュー活動の課題」でも説明しましたが、レビューのやり方が悪いと、「いつもけんか腰」「責めたり責められたりで雰囲気最悪」といったよくない状態になることがあります。これは、成果物のレビューではなく、作成者のレビューになっているパターンの1つです。

　「開始時間と終了時間を守る」ことも、ぜひ実践してください。議論が深みにはまると、1～2時間はあっという間に過ぎてしまいます。本当に議論すべきことであればじっくり時間をかけて実施すべきです。ただし、ピアレビューは作業成果物を対象に「欠陥や改善を洗い出すことが目的」ですので、限られた時間を最大限有効に活用する必要があります。ピアレビューの実績を蓄積していけば、時間あたりにレビューできるステップ数やページ数の基準が設定できます。この基準値を参考にして、レビュー対象とする成果物量をもとにレビュー計画を立案し、効率的なレビューの実践を目指してください。

ピアレビューのプロセス

　図2にピアレビューのプロセスを示します。これは、「2. ピアレビュー」のセッションで使うスライドです。

　最初に、開発計画を立案する段階でレビュー計画を立案してください。このタイミングでは、詳細な計画は立案できませんので、詳細で具体的な計画を立案しようと思いすぎないように注意してください。時期、成果物、回数、出席者などを計画しておくことが大事です。

　ピアレビューの結果は必ず記録として残します。一般に以下のような情報を残していることが多いと思います。

・プロジェクト情報
・レビュー対象成果物の種類とボリューム（コード行数、ペース数など）
・事前レビューの記録
・レビュー出席者とレビュー実施時間
・指摘された欠陥と欠陥レベル

　欠陥レベルとしては、以下の高、中、低の3段階程度で分類するのが運用上実施しやすいと思います。

高：この欠陥が残ると、後工程／リリース後に大きな影響を及ぼすもの
中：大きな影響はないが、修正／確認が必要なもの
低：見栄え、誤ったメッセージ、スペルミスなど

　図2では、ピアレビューの終了判定を「欠陥があるか？」どうかで判断しています。以下は、ピアレビュー対象とした成果物の終了判定の判断方法の事例です。

　「承認」はフォローアップの必要がない場合の判定です。「条件付き承認」は欠陥レベルが「中」もしくは「低」の欠陥が発見された場合、これらの欠陥修正後、チームリーダの検証を受ける場合の判定です。「否認」は欠陥レベルが「高」の欠陥が発見された場合、再度ピアレビューを実施する場合の判定です。