漏れ、誤り、曖昧さを制約とする defect-based reading

レビューが難しい理由の1つは自由度が高いことだと思っています。何でも自由にやれるから問題ないよねと思ってしまいがちですが、自由度が高いことは必ずしもいいことばかりではありません。本エントリのタイトルは3種類の着眼点を制約とすることにより、自由度を少し制限してレビューアが立ち戻ったり現在の状況を顧みることで、結果として網羅的な欠陥の発見につなげようというものです。

「漏れ、誤り、曖昧さ」は本エントリ末尾の論文に読み進め方のシナリオとして記載されています。後にDefect-based readingと呼ばれるようになった手法です。3つについて細かくみていきます。私のお勧めは1. 漏れ、2. 誤り、3. 曖昧さの順で計3回レビュー対象をみるやり方です。

1. 漏れ
   本来書かれているべきものでありながら書かれていないものです。追加機能があるのに削除機能がない等です。
2. 誤り
   外部の定義または内部の定義との不整合です。たとえば住所を登録するシステムであれば外部の定義には郵便番号が該当します。また、内部の定義の例にはデータベース定義とデータエントリの追加情報が統一されていないことが挙げられるでしょう。
3. 曖昧さ
   解釈する人によって解釈の仕方が異なるような表現を曖昧と呼びます。たとえば「しばらくして再度試みる」と書いたときの「しばらく」はどのくらいの時間か人によって解釈が異なる場合が多いでしょう（もちろん前後の文脈から一つに定まることもありますので、その場合は問題ありません）。

Perspective-based readingやDefect-based readingは、制約を与えることによってレビューアが欠陥検出に集中できるようにするための技法です。もしレビュー終了後の欠陥リストをみて「あー、いろんな欠陥が出まくってて結局意味あるのか・・。支離滅裂だなぁ」となってしまうようならば、試す価値があると思います。

読み進め方の技法としてリーディングテクニックがあります。リーディングテクニックは@ITの記事「“読み方”を知って、レビューをもっと効果的に」でも紹介していますので参考にしてください。

Defect-based readingの出典: A. Porter, L. Votta and V. Basili, “Comparing Detection Methods for Software Requirements Inspections: A Replicated Experiment,” IEEE Transactions on Software Engineering, Vol. 21, No. 6, pp. 563-575 (1995)

このエントリをtweetする