要件定義書や設計書のチームレビューを実施したとき、誤字脱字のような「軽微な指摘」ばかりが挙がり、テスト工程になってから修正工数の大きい不具合がいくつも見つかったという経験はないだろうか。
一般的なシステム構築プロジェクトでは、要件定義書や設計書のレビューに費やせる時間は限られている。多くの場合、その時間は十分とはいえないだろう。レビューで軽微な指摘に時間をかけてしまっている状況は、決して好ましくない。
本来レビューで注力すべきは、「重大な指摘」を数多く挙げることである。ここでいう重大な指摘とは、一般的な意味と異なり、レビューで見逃しテスト工程になって検出した場合に修正工数・コストが膨らむものを指す。致命的な欠陥であっても、テスト工程で検出して修正すれば十分なものへの指摘は含まないことに注意してほしい。なお、重大な指摘と軽微な指摘のどちらでもない中間的なものは「グレーな指摘注1」と呼ぶことにする。
観点を絞り込めば重大な指摘が増加
コスト効果をもたらす重大な指摘を数多く挙げる方法の一つとして、筆者はレビューの観点を絞り込む方法を提唱している。例えば、他のシステムとの連携に関して技術リスクが高いプロジェクトでは、「他のシステムとの連携に関する問題の検出に注力する」という意識を持ってレビューを行う。その場合、絞り込んだ観点から外れた問題は見逃してしまうので逆効果だと思うかもしれない。それでも軽微な指摘に費やす時間を減らして観点に沿った重大な指摘が増えるので、トータルで見てレビューのコスト効果が高まる、という考えである。
では実際に、レビューの観点を絞り込むことで、重大な指摘やコスト効果がどれだけ増えるのか。これを調べるために、二つの検証を実施した（図1、図2）。先に結果を示すと、一つ目の検証Iでは重大な指摘の件数が約1.4倍になった（図3）。二つ目の検証IIでは、コスト効果が約2.3倍に増えた。
これら検証IとIIの概要を説明しよう。検証Iはレビューアーのチームで“定性的に”観点を絞り込むというもの。この定性的にというのは、レビューアーの経験やセンスに基づいて、という意味である。レビュー対象のシステム要求仕様書の内容を基に、レビューアー同士でどういう観点に絞り込むべきかを話し合った上で、その観点に沿って指摘を挙げた。さらに、別のレビューアーチームに、観点を絞り込まないまま同一のシステム要求仕様書をレビューしてもらい、重大な指摘の件数がどれだけ違うのかを調べた。
もう一つの検証IIでは、レビューの観点を“定量的に”絞り込むことのコスト効果を調べた。定量的にとは、レビューアーの経験やセンスだけに頼らずデータを活用することを表す。レビュー対象はデータ処理ソフトの内部設計書である。それ以前に実施した関連プロジェクトにおけるテストの実績データから、どういう不具合で大きな修正工数（コスト）が生じたのかを調べ、そのデータを基にレビューの観点を絞り込んだ。こうして定量的に絞り込んだ観点に沿ってレビューをしたチームと、観点を絞り込まずにレビューをした別のチームで、指摘のコスト効果がどう変わるのかについて調査した。
次回から、これら二つの検証の内容と結果を詳しく紹介する。また、観点の単純な絞り込みルールを設定した場合のレビューの検証も行ったので、併せて取り上げる。
