第2回 技法の分類とテンプレート（基本編）

リーディング技法がなぜ必要か？

　インスペクション／レビューにおける欠陥の指摘は自由度が高いため、本題である欠陥や矛盾の指摘から話がそれてしまうことがあります。例えば、質問ばかりで指摘が全くされない、品質向上につながらない指摘が多い、極端な場合にはインスペクション／レビュー対象のソフトウエアから離れてしまい、ベテランの昔話を拝聴する場や愚痴を言い合う場になることもあります。

　リーディング技法はインスペクタ／レビューアに対する読み方のガイドラインです。ガイドラインは上記のような逸脱をなくすためにあり、インスペクション／レビューを実りあるものにすることを目的としています。その効果は絶大です。また、指摘結果表を手元においておくだけで「何か誤りを指摘しなければ」という気になり、指摘に集中できます。

　ガイドラインは最良のものが画一的に決まっているものではなく、プロジェクトの状況、ソフトウエアに求められる品質、参加メンバに応じて適したものを選びます。チェックリストは非常にメジャーなガイドラインの1つで、多くの方が一度は目にされたことがあるでしょう。

　チェックリストは、これまでの経験や失敗から見逃しがちな欠陥を見つけやすくしたり、スキルをこれから身につけようとしているインスペクタ／レビューアが網羅的に欠陥を見つける際の助けとなってくれたりします。また、同じソフトウエアの機能拡張等を固定的な参加メンバで実施するような場合には、あえて何も指定しないアドホックリーディングが効果的な場合もあります。

　リーディング技法は、大きく、基本形（単一の読み方を複数のインスペクタ／レビューアで共有して実施するもの）、シナリオベース（インスペクタ／レビューアそれぞれに違う読み方を割り当てるもの）の2つに分類することができます。今回は、基本形の代表例として、アドホックリーディングとチェックリストリーディングの2つの技法を紹介するとともに、具体的にこれらの技法を進めるために必要な記録テンプレートを紹介します。

アドホックリーディング

　アドホックリーディングは特にガイドラインを指定しない方法です。プロジェクトの事情やソフトウエアに求められる品質によっては、アドホックリーディングが最も効果的な場合もあります。場に応じて適切な役割を果たすことができるので、日本人には向いている方法だと筆者は思っています。

　欠陥指摘の例は図1のとおりです。指摘結果の具体的な記述内容はリーディング技法に依存するものではありませんので、どのようなリーディング技法を使ってもこのようなものになるでしょう。プロジェクト計画や契約書もインスペクション／レビューの対象になりますが、ここでは代表的な開発工程の成果物のみを対象にしています。

　ただし、欠陥指摘のやり方を特に決めないアドホックリーディングであっても、指摘結果は明示的に記録する必要があります。次ページで具体的な記録テンプレートを紹介します。