
			・レビューでは「なぜ」「どうして」を聞くようにしている・レビュー対象だけでなく、上位の入力となる成果物も持ち出している・コードレビューでは、変更前と変更後のソースコードの差分を見て確認している・不具合の発見に注力する

　表面的な問題点やポカミスを指摘することも当然必要ですが、十分検討された成果物をレビューするわけですから、奥底に潜む不具合を指摘することは容易ではありません。そのためには最初の意見にあるように、「なぜ」「どうして」というような理由・根拠に関して重点を置くことが必要です。

　また、要求、仕様などの上流工程のレビューでは、どう作るのかに目が行きがちですが、「誰のために」「何のために」に注意すると、不具合発見の確率が高まります。また、レビュー対象だけではなく、その対象への入力情報と比較しながら確認することも有効です。

　レビューの現場でよく見かける光景として、議論が白熱していることがあります。それは不具合の指摘と併せて解決策を検討しているからです。レビューではまず、不具合の発見に専念し、解決策の検討は別途実施するのがよいでしょう。

　レビューを実施するに当たって、「気付きを促すためにチェックリストを作成している」との意見が、参加者の半数近くからありました。以下にチェックリストに関する意見を紹介します。


			実施するレビューごとにチェックリストを作成している


			チェックリストには詳細な部分まで記述するのではなく、着眼点のみを書いている


			成果物のテンプレートに記述のガイドラインを記し、それに着目してレビューしている

　チェックリストを作成すると、視野が狭くなるので否定的な意見も聞かれますが、人に依存しないよう組織としてレベルアップしていくためには、作成することが望ましいと思います。そして、実施するレビューごとに対象が異なるので、当然チェックリストもそれぞれ用意しておくのが通常です。

　それぞれのレビューでの観点を大まかに見てみましょう。

　このような点を考慮し、自分たちの製品、組織にマッチしたレビューチェックリストを作成してみてください。

　チェックリストの作成は、スキル依存を脱却するためには有効です。そのほかにも、レビュー活動で要員を育成するための工夫として、以下の意見が挙がりました。


			過去の経験を管理し、知識の交換も目的として経験のある人を参加させる。さらに、そのエリアに経験がない人も参加させ、新たな視点（斬新）で見るようにする