検証IIでは、定量的にレビューの観点を決めることのコスト効果を測定した。東芝デジタルメディアエンジニアリングの協力を得て、映像や音声などのデータ処理ソフト（Xとする）の開発プロジェクトにおける内部設計書をレビュー対象とした。このプロジェクトでは、開発済みのソフト（Yとする）を派生させてソフトXを開発する。
検証は、定量的に観点を決めることから始めた。その際、ソフトXの元になったソフトYの新規開発・派生開発プロジェクトにおけるテストの不具合管理票350件を、実績データと見立てて用いた。不具合管理票は「サブシステムカテゴリー」「開発担当者」「原因種別」「検査種別（テスト種別）」といった属性項目を備えているほか、「不具合の内容」、発生した「修正工数」などが記録されている。
この実績データを基に、数個の観点を設定する。そのために属性項目に着目した。属性項目ごとの、不具合の出現頻度（全不具合の何％が該当するか）、修正工数、修正工数のバラツキ度合い（標準偏差）という三つの尺度が、観点決めのヒントになる。例えば「検査種別＝異常系」の不具合の出現頻度が高かったら、異常系のテストで見つかる欠陥種別を観点にすればよい。
この検証ではさらに深く実績データを分析するために、属性項目を組み合わせた約1万7000件の出現ルール（例えば「開発担当者ID＝15」かつ「検査種別＝異常系」）を設定し、各ルールについて出現頻度、修正工数、修正工数のバラツキ度合いという三つの尺度を算出した。それらの出現ルールから、三つの尺度のいずれかの数値が突出して高いものを合計で数十件抜き出し表にまとめた（図1左）。
この出現ルール表を基に、ソフトX・Yに詳しい有識者のITエンジニアが話し合い観点を決めた。例えば「検査種別＝異常系」を含むルールが目立ったので、異常系に深く関係する「例外処理」「特殊入力」を観点にした。このようにして、例外処理・初期化・特殊入力・排他処理・ユースケースという五つの観点を設定した（図1右）。
レビュー工数が半分で済む効果も
実際のレビューではまずITエンジニア5人のチーム（C）を編成し、観点を設定せずにソフトXの内部設計書のレビューを行った。一人ひとり個別に内部設計書を読み、指摘事項を管理票に記入した。レビューは1人当たり約72分間かかり（レビュー工数は6人時＝72分×5人）、コスト効果の見積もり値は合計で7人日だった。
これとは別に、前出の五つの観点に絞り込んだレビューを行うITエンジニア3人のチーム（D）を編成した。3人にはそれぞれの得意分野を考慮し、五つの観点を割り当てた。1人目は例外処理・初期化・ユースケース、2人目は特殊入力・初期化・排他処理、3人目は例外処理・排他処理という具合である。レビューアー3人は割り当てられた観点に沿って、個別に内部設計書をレビューし、指摘事項を管理票に記入した。レビューは1人当たり約60分間で終わり（レビュー工数は3人時＝60分×3人）、それらのコスト効果の見積もり値は合計で16人日に上った（図2）。
結果を比較すると、定量的に観点を絞り込んだ（D）では、（C）に比べてコスト効果が約2.3倍に高まった。しかも、レビュー工数は半分で済んでいる。正確には（D）における観点設定の工数も考慮する必要があるが、実質的には無視できるレベルである。
筆者の実感では、観点の定量的な絞り込みの効果は、定性的な絞り込みより格段に大きい。ただし定量的な絞り込みを実現するには、組織的に不具合管理票という実績データを綿々と整備し続け、それらを基に重大な欠陥の種別を推測して観点を設定する必要がある。そのため、定性的な観点絞り込みのほうが実践しやすいだろう。皆さんの現場でも、可能な範囲でレビュー観点の絞り込みを実践してみてはいかがだろうか。
