適用結果

　前述のテーラリングしたパスアラウンドレビューを、組織内の1プロジェクトに対して2回適用しました。1回目は2007年11月にソフトウエア開発計画書のレビューに対して、そして2回目は2008年1月にテスト計画書とテスト要項書の大項目に対してです。

　まず、定量的な結果を振り返ってみましょう。ソフトウエア開発計画書のレビュー結果とテスト計画書のレビュー結果を図3に示します。ソフトウエア開発計画書はデザインレビューの対象物となっていますので、当該プロジェクトと過去のプロジェクトのデザインレビュー結果も図3に記載しています。当該プロジェクトにおいては、クロスチェックにおける是正件数は26件、デザインレビューにおける是正件数は0件という大きな差がありました。

　続いて定性的な結果です。当該プロジェクトは管理技術面、すなわちソフトウエア開発計画と進ちょく監視、およびテスト計画とテスト進ちょく監視においてプロジェクトが破たんするようなトラブルはなく、計画通りに完遂しました。

　また、レビュー対象物の修正完了後、作成者からの「お忙しい中ご協力ありがとうございました。いざ実担当者の立場だと楽観視・希望的観測してしまうようなリスク（仕様変更ないだろう、テスト品質よいはず、今の体制でいける、機材不備ないだろう）が抽出できたように思います。予防ができるものは計画、予防できないものはリスクとして監視していきます」というメールによって、作成者自身がレビューの効果を実感している旨がレビューアにフィードバックされています。

効果

　デザインレビューとの是正件数の比較、作成者からレビューアへのフィードバック、プロジェクトの計画通りの完遂から、それまでのレビューと呼ばれる活動と比較して、今回のクロスチェックは効果があったと判断します。また、当該プロジェクトにおける管理技術面のトラブルがなかったことからも効果があったことがわかります。

　次に、既存のレビューと呼ばれている活動との関係について考察します。当該プロジェクトにおいては、機能仕様と非機能仕様、ソースコードを対象に、適宜2～3名によるアドホックなレビューを実施していました。この活動はファイルサーバーに格納した共有ファイルのやりとりであったり、メールや口頭のやりとりであったりしたため、効果を裏付ける記録がありません。しかし、仕様やソースコードなどの開発技術の成果物についていくつかの欠陥を検出することによって、今回の管理技術に関するクロスチェックを補完し、プロジェクトの計画通りの完遂に貢献したものと推測できます。

　ただし、デザインレビューについては、ソフトウエアの管理技術の成果物を精査し欠陥を検出するという目的には適していないことがわかります。これについては、デザインレビューの課題として別途分析と対策が必要です。

　以上、目的の明確化と周知、プロセスの定義と順守、適切なレビューア選定、会議の効率向上、負担感の軽減等の工夫をすることで、欠陥検出を目的としたレビュープロセスを定義し適用することができました。今後は、このレビュープロセスを組織に定着させることと、技術者同士が相互にチェックし合い、助け合い、知識やスキルを補完し合う風土を作るための1つの手段として活用しくことに注力していこうと考えています。

【参考文献】
Karl E. Wiegers 著大久保雅一監訳『ピアレビュー－高品質ソフトウェア開発のために』日経BPソフトプレス（発行年：2004）

Tom Gilb 著 Dorothy Graham 著伊土誠一翻訳富野寿翻訳『ソフトウェアインスペクション』構造計画研究所（発行年：1999）

細川宣啓著「特集1 実装に入る前に勝負をつけろ！手戻り予防の特効薬仕様書の欠陥を検出する上流インスペクション」『ソフトウェア・テスト PRESS Vol.2』技術評論社（発行年：2006）

「日本科学技術連盟　ソフトウェア品質シンポジウム2008　講演資料」（http://www.juse.or.jp/software/pdf/sqip2008/ippan_02_1.pdf）（アクセス：2009/01）