PR

インスペクションを自在にカスタマイズ

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

カスタマイズが必要な理由

 組織内のすべてのソフトウエア開発プロジェクトを画一的に扱い、唯一の手順、技法、開発方法論だけではプロジェクトを成功に導くことはできません。個々のプロジェクトへの手順、技法のカスタマイズは必須であり、インスペクションについても同じことが言えます。

 本記事ではドイツフラウンホーファ実験的ソフトウェア工学研究所(IESE)がこれまでに実践、発表しているインスペクションに関する学術論文[文献1][文献 2]の内容をもとに、同研究所テスティング&インスペクション部門の責任者Frank Elberzhagerと国立大学法人 奈良先端科学技術大学院大学情報科学研究科の森崎 修司が相談しつつ本記事の読者用に作成したものです。なお、本記事は奈良先端科学技術大学院大学とフラウンホーファ実験的ソフトウェア工学研究所の国際連携であるWorking Group of International Research Cooperation on Software Inspections
(http://www.software-inspection-wg.org/) に基づくものであり、日本語訳は森崎が担当しています。

開発プロジェクトによって事情が異なる

 個々のソフトウエア開発プロジェクトによって事情が異なるため、単純にほかのプロジェクトのインスペクションの成功事例を丸写しするだけでは必ずしも同じように成功するわけではありません。プロジェクトごとにリスク、ソフトウエアに求められるもの、かけられる工数も異なるでしょう。これまでのIESEでの経験では、プロジェクト事情を勘案したテーラリング(プロジェクトの特性や事情を考慮し、インスペクションをカスタマイズすること)をしなかったときのインスペクションの効率は低くなりやすいことを確認しています。

 現在使われている主要な読み進め方としてチェックリストを使ったものがあります。チェックリストはなるべく多くのプロジェクトやソフトウエアにあてはまるよう抽象的な書き方をされていることが一般的です。筆者らの経験では、チェックリストがプロジェクトごとにカスタマイズされることはほとんどありませんが、実際にはプロジェクトに応じてカスタマイズする必要があることが多いです。

 アーキテクト、プログラマー、テスタ、顧客をはじめプロジェクト関係者へのメリットを理解してもらう必要があります。プロジェクト関係者が、インスペクションを非生産的な追加の活動と考えているうちは、期待する効果が出ないどころかかえって効率が下がります。

 もし、積極的な意見を出せないメンバしかインスペクションに参加しなければ、単に他人が作成したドキュメントを最初から最後まで目で追う会議になります。例えば、要求仕様書のインスペクション会議では、単に正しい文章が書けているかどうかをチェックするだけでなく、最終形であるシステムのどの構成要素(サブシステム)でおのおのの要求を実現するか、また構成要素間ではどのようなやりとりがあるかを想定しながらでないと効率的な欠陥指摘は難しいでしょう。

静岡大学

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

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

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

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

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