PR

技法の分類とテンプレート(基本編)

2009年3月9日(月)
森崎 修司

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

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

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

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

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

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

アドホックリーディング

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

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

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

静岡大学

2001年、奈良先端科学技術大学院大学 情報科学研究科 博士後期課程修了。情報通信企業において、サービス開発やシステムインテグレーションに従事し、企画、設計、実装、開発管理、品質向上を実践する。奈良先端科学技術大学院大学 情報科学研究科 助教などを経て、2011年4月より現職。不具合情報の分析、ソフトウエアレビュー、ソフトウェア計測、実証的ソフトウエア工学を研究の柱としている。
研究グループのWeb:http://ese.inf.shizuoka.ac.jp

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています