目的を設定して検出のたびに確認するとレビューの結果が安定することを検証(若干堅苦しくなることも確認)
2011年8月に私の研究グループの論文で確かめた内容です。32人のソフトウェア開発の実務者の方に協力いただきました。5, 6人で1班を作り、全部で6班で目的設定のしかたが異なる3つのグループを作りました(1グループあたり2班)。それぞれのグループは以下のとおりです。特定の班に経験年数の高いエンジニアや相対的にスキルの高いエンジニアがかたまらないようにしました。
- 目的設定をしないグループ(1, 2班)
- レビュー開始前に目的設定をしてその目的に沿って欠陥を検出するグループ(3, 4班)
- 開始前に目的設定をし、欠陥を検出するたびに目的に沿っているかを確認しながら検出するグループ(5, 6班)
ここでの目的設定は「どのような欠陥を検出すべきか」という欠陥種別の設定です。3~6班の目的設定はレビュー対象に合わせて各班で相談して決めていただきました。レビュー対象はWebブラウザをクライアントとする架空の会議調整システムの設計書です。
検出欠陥数を計上し分類したところ次のような結果になりました。
1 | 2 | 3 | 4 | 5 | 6 | |
目的に沿った欠陥 | (1) | (2) | 5 | 9 | 6 | 7 |
目的に沿っていない欠陥 | (22) | (10) | 5 | 13 | 0 | 0 |
誤字脱字など軽微な欠陥 | 24 | 11 | 4 | 5 | 1 | 0 |
合計 | 47 | 23 | 14 | 27 | 7 | 7 |
今回の検証では3~6班でセキュリティ上の問題を検出することを目的に設定されましたので、上の表では「目的に沿った欠陥」をセキュリティ上の問題としています。1, 2班のカッコつきの件数は目的設定していないのですが、セキュリティ上の問題に該当する欠陥の件数を示しています。
この表からわかる結果は次のとおりです。
- 目的設定しないほうが検出欠陥数は多かった。
- 目的設定しないと軽微な欠陥の検出数が増えた。
- 開始前に目的設定したとしても、目的に沿っていない欠陥が検出された。
- 開始前に目的設定し、検出のたびに確認すると設定した目的以外の欠陥がほとんど検出されなかった。
検出された欠陥のうち「もしレビューで見逃してテストで見つけて修正したとするならば、修正コストが増加した」といえる欠陥のみに限定し件数を計上したところ次の表のような結果が得られました。
1 | 2 | 3 | 4 | 5 | 6 | |
件数 | 7 | 5 | 9 | 8 | 6 | 6 |
表1, 2からわかる結果は次のとおりです。
- 開始前に目的設定をした班(3, 4班)では、レビューで検出することによって修正コストが小さくなった欠陥の件数が他の班よりも少し多かった。
- 開始前に目的設定し、検出のたびに確認した班(5, 6班)では、検出欠陥のほとんどが目的に沿い、かつ、修正コストが小さくなった。
協力してくださったエンジニアの方にインタビューしたところ、3~6班の方からは、レビューの効果が上がった感じがするという意見が得られました。5, 6班の方からは、効果は実感できたが、ちょっと堅苦しくなったという意見も得られました。
この結果からレビューでの目的設定に効果があると言えそうです。n-foldレビューのように、事前にレビューの目的を変えながら何度かレビューする場合には、5, 6班のようなやり方も適切ではないでしょうか。