インスペクションを自在にカスタマイズ
カスタマイズが必要な理由
組織内のすべてのソフトウエア開発プロジェクトを画一的に扱い、唯一の手順、技法、開発方法論だけではプロジェクトを成功に導くことはできません。個々のプロジェクトへの手順、技法のカスタマイズは必須であり、インスペクションについても同じことが言えます。
本記事ではドイツフラウンホーファ実験的ソフトウェア工学研究所（IESE）がこれまでに実践、発表しているインスペクションに関する学術論文[文献1][文献 2]の内容をもとに、同研究所テスティング＆インスペクション部門の責任者Frank Elberzhagerと国立大学法人 奈良先端科学技術大学院大学情報科学研究科の森崎 修司が相談しつつ本記事の読者用に作成したものです。なお、本記事は奈良先端科学技術大学院大学とフラウンホーファ実験的ソフトウェア工学研究所の国際連携であるWorking Group of International Research Cooperation on Software Inspections
(http://www.software-inspection-wg.org/) に基づくものであり、日本語訳は森崎が担当しています。
開発プロジェクトによって事情が異なる
個々のソフトウエア開発プロジェクトによって事情が異なるため、単純にほかのプロジェクトのインスペクションの成功事例を丸写しするだけでは必ずしも同じように成功するわけではありません。プロジェクトごとにリスク、ソフトウエアに求められるもの、かけられる工数も異なるでしょう。これまでのIESEでの経験では、プロジェクト事情を勘案したテーラリング（プロジェクトの特性や事情を考慮し、インスペクションをカスタマイズすること）をしなかったときのインスペクションの効率は低くなりやすいことを確認しています。
現在使われている主要な読み進め方としてチェックリストを使ったものがあります。チェックリストはなるべく多くのプロジェクトやソフトウエアにあてはまるよう抽象的な書き方をされていることが一般的です。筆者らの経験では、チェックリストがプロジェクトごとにカスタマイズされることはほとんどありませんが、実際にはプロジェクトに応じてカスタマイズする必要があることが多いです。
アーキテクト、プログラマー、テスタ、顧客をはじめプロジェクト関係者へのメリットを理解してもらう必要があります。プロジェクト関係者が、インスペクションを非生産的な追加の活動と考えているうちは、期待する効果が出ないどころかかえって効率が下がります。
もし、積極的な意見を出せないメンバしかインスペクションに参加しなければ、単に他人が作成したドキュメントを最初から最後まで目で追う会議になります。例えば、要求仕様書のインスペクション会議では、単に正しい文章が書けているかどうかをチェックするだけでなく、最終形であるシステムのどの構成要素（サブシステム）でおのおのの要求を実現するか、また構成要素間ではどのようなやりとりがあるかを想定しながらでないと効率的な欠陥指摘は難しいでしょう。
