検証Iは、筆者が講師を務めたレビューのセミナーにおいて、受講者の ITエンジニアに協力してもらい実施した。手順は次のようなものだ。
まず5人のチームを合計四つ（甲・乙・丙・丁）作った。その際、レビューのスキルがなるべく均等になるようにチームを分けた。全員からITエンジニアとしてのキャリア年数を聞き、四つのチームでレビューアーのキャリア年数がほぼ同じになるように割り振った。
甲・乙の2チームは、観点を絞り込まない前提でレビューを行う。一方、丙・丁の2チームは、定性的に観点を絞り込みレビューをする。
レビュー対象として用意したのは、イベント管理システムの要求仕様書である（図1）。このシステムは無償のSaaS（Software as a Service）として、誰でもWebブラウザーから利用できるようにすることを想定している。コンサートやパーティーなどの主催者がイベントを登録し、それに対して参加希望者が予約を申し込むためのものだ。
実際のプロジェクトで作成された要求仕様書（テスト工程で見つかった不具合に対する修正を反映した完成版）をベースに、誤字脱字や「パスワードを暗号化せず保存してしまう可能性がある」といった、SaaSのシステムにおける重大な欠陥を複数埋め込んだ。
2チームずつ条件を変えてレビュー
観点を絞り込まない甲・乙の2チームは、「いつものやり方」という条件（これを（A）と表す）でレビューを行った。両チームとも、まずはレビューアー各自が要求仕様書に一通り目を通し、その後は車座になって指摘事項を一つずつ挙げていった。筆者は横で見ていたが、チームで観点を設定するという動きはなく、気づいた問題をどんどん挙げていくという感じだった。そうして挙がった指摘事項は全て、あらかじめ配布した指摘票にレビューアーが記入した。レビューの制限時間は40分で、その時点で指摘票を回収した。
一方の丙・丁の2チームに対しては、レビューを始める前に筆者から条件を説明した。チームで話し合ってコスト効果の大きい観点に絞り込む、その観点に沿った指摘を挙げる──という2点がその条件である（これを（B）と表す）。
丙・丁の2チームはそれぞれ、どういう観点にするかを話し合い、どちらも「セキュリティ」を観点に設定した注1。対象システムはSaaSでありインターネット上で公開するので、セキュリティが問題になりやすい。その意味で適切な観点といえる。
その上で、丙・丁の2チームはそれぞれ指摘を挙げ始めた。観点に沿わない指摘を挙げるレビューアーもいたが、おおむねセキュリティに関する指摘に絞ろうという意識が見て取れた。
レビューでは表1のような指摘が挙がった。条件（A）（B）の結果は第1回の図3の通りで、全指摘件数（平均値）は、観点を絞り込まない（A）が35件であるのに対して、観点を絞り込んだ（B）は20.5件だった。しかし重大な指摘に着目すれば、（B）は8.5件であり（A）に比べて約1.4倍だった。特にセキュリティに関する重大な欠陥は、ほぼ全てを指摘できた。
（B）の丙・丁の2チームは、セキュリティに観点を絞ったことで視野は狭くなったかもしれないが、その分、セキュリティの重大な欠陥だけは見逃さないようにしようと集中できたようだ。その結果、（A）の2チームよりコスト効果の高いレビューになった。
