2人以上のレビューアーが、同じような欠陥を指摘するレビューのやり方や手順があれば、重複を減らせるよう、やり方や手順を変更できないか検討します。以下の図2の左側を右側にするようなイメージです。
図2の左側に当てはまるような、レビューアー間の確認内容が重複してしまう典型的な例は、同一のチェックリストやレビューシナリオを全員で確認することがレビューの手順として決まっているケースです。
例えば、同一のチェックリストを3人のレビューアーが確認している場合、チェックリストを3分割して、分担できないか考えます。3人合わせるとチェックリスト全体が確認できるようにします。複数のレビューアーの目で見て確認をより確かなものにしたい場合は、後述する例外の部分を参考にしてください。
レビューアー間で重複する欠陥が検出されやすいやり方、手順がない場合でも、複数のレビューアーが同じような欠陥を検出していないか思い出してみてください。本記事の冒頭のシーンのように、レビュー会議で「あ、それ、私も気付きました」といった発言が多くなっていないでしょうか。
特に識者やベテランといわれるレビューアーが他のレビューアーと同じような欠陥を検出していたら要注意です。その重複を減らすことができれば、効率化につながります。
識者レビューや第三者レビューとして、開発チームに含まれないレビューアーに参加してもらうときも同様です。これらのレビューの目的は、識者や第三者しか持たない知識や経験から欠陥を検出してもらうことにあります。普段のレビューと同じような欠陥が検出されていると実施の効果が薄れます。普段のレビューとは異なる着眼点で見てもらえるよう、どういった欠陥を検出してもらえることを期待しているか、どこを確認してほしいか、普段どういった欠陥を検出しているかを伝えて、検出してもらう欠陥の重複を減らせるようにします。
以上のように、レビューアー間で重複を減らすことは効率化につながりますが、重複を減らさない方がよい例外が2つあります。
1つは見逃しの影響が大きい欠陥です。複数のレビューアーの目によるチェックが欲しいときには、意図的に重複させておきます。重複する欠陥は他のレビューアー任せにならないよう、レビューアー間で重複の目的を合意しておきます。
もう1つは情報共有や教育を目的とした場合です。新しく開発チームに合流したレビューアーに欠陥検出の大まかな方針や方法を知ってもらいたいときや、同一の方針でレビューすることによって教育したい場合にも、意図的に重複させておきます。他のレビューアーがどう欠陥検出しているかを知ってもらうためです。
ここまでが欠陥検出の効率化に向けた基礎的な部分です。次のステップでは、レビューでの検出を省略したり、確認する箇所を減らしたりする方法を紹介します。
Copyright © ITmedia, Inc. All Rights Reserved.