技法の分類とテンプレート（応用編）

シナリオベースのリーディング技法

　シナリオベースのリーディング技法の代表的なリーディング技法として、パースペクティブベースドリーディングを紹介します。シナリオベースのリーディング技法では、インスペクタごとにシナリオを割り当て、それぞれのシナリオに沿って欠陥を指摘する技法です。シナリオベースのリーディング技法全般に網羅的な欠陥指摘ができることが報告されています。

　パースペクティブベースドリーディングはメリーランド大学Basili教授らが提案したものです。「The Empirical Investigation of Perspective-Based Reading」（詳細は参考文献）では、技法の詳細とNASAのSEL（Software Engineering Laboratory）での事例が報告されています。

　パースペクティブベースドリーディングは、インスペクタにシナリオと呼ばれる観点（perspective）を割り当てる方法です。インスペクタの立場と読み方の観点を決めてから、それぞれの観点でインスペクションを進めていきます。

　例えば、設計書インスペクションにおいて、リリースエンジニア、テストエンジニアがそれぞれの観点で、懸念事項や潜在的欠陥を指摘すれば、リリース時に困ることを回避できる方法やテストがやりやすいような設計とすることができます。リリースエンジニア、テストエンジニアといった立場は、必ずしも実際の開発に携わる立場と一致している必要はありません。例えば、開発プロジェクトリーダが顧客の立場を担当し、担当者レベルのユーザーの気持ちになって（観点で）インスペクションを実施することもできます。

　パースペクティブベースドリーディングは、多様な欠陥を網羅的に発見したい場合に使います。特に、大規模ソフトウエアのような欠陥による手戻りが大きい場合や、複数の観点からの指摘が有効に働く場合（例えば、セキュリティーと性能）に適しています。なお、観点どうしがトレードオフの関係にある（パフォーマンスと保守性等）場合には調整が必要になるので、同期型にするほうが効率があがります。

立場と観点の具体例

　図2は立場と観点の例です。立場は組織、プロジェクト、対象ソフトウエアに応じて独自に決めることをお勧めします。図2の例は、ベーシックなパターンで、設計者、顧客、テストエンジニアを立場としています。必ずしも開発プロジェクトにおける実際の役割と一致させる必要はありません。また「セキュリティーのエキスパート」「欠陥指摘のエキスパート」という立場や「経験が多くないプログラマー」のようにスキルの前提を加えることもできます。

　ほかにも、保守を別のメンバに引き渡す場合には保守エンジニアのような立場を追加すると効果的です。観点には、それぞれの立場が自身の作業を進める上で必要となることを記入します。

　図2にあるように、例えば、テストエンジニアはインスペクション対象の仕様書から、テスト設計、テストケース作成が可能かをチェックする、という観点で不備や欠陥を指摘します。また、この作業はテスト工数の見積もりを早期に把握するのにも役立ちます。

　日本人どうしでインスペクションをしていれば、技術系のベテラン、顧客対応のベテラン、中堅、若手のような役割分担が無意識にできあがっていることが多いと思います。

　例えば、技術系のベテランであればタイミング問題やほかのソフトウエアとの整合性を、顧客対応のベテランであれば、顧客が勘違いしやすいこと、仕様書の記述との一致度合いを見ていることが多いでしょう。

　筆者の研究グループで実施した実験においても、特にリーディング技法や観点を指定しなくても、普段プロジェクトマネジャーやリーダとして活動しているインスペクタは、仕様や顧客へのコミットメントとの整合性に注目する傾向に、中堅は例外処理を、若手は正常系を順に追っていく傾向があった事例を確認しています。

　欧米人の研究者や実務者にこのことを話すと「それでうまくいくんだ～」と驚かれることが多く、筆者はこういう日本人のよいところが気に入っています。パースペクティブベースドリーディングは難しいことをやるのではなく、これまで日本人として自然とやってきたことを、明文化してさらなる効果を出すものと考えるとよいように思います。