インスペクション(いんすぺくしょん)情報マネジメント用語辞典

inspection / 検査 / ソフトウェアインスペクション

» 2011年11月07日 00時00分 公開

 最も公式なソフトウェアレビュー(注1)。ソフトウェア中の問題を検出するために、事前に定められた観点で第三者が厳密にレビュー対象を点検して欠陥の指摘と認定を行い、その結果に基づいて対象の修正と開発プロセスの評価・改善を行う。

 インスペクションは、事前に定められた手順とチェックリストに従って第三者がレビューを行う、最も形式的なレビュー手法である。

 レビュー対象にはソースコードのほかにプロジェクト計画・要求定義・基本設計・詳細設計の各フェイズにおける各種成果物が含まれ、上流工程から実施可能な欠陥未然防止技法になっている。

 インスペクション活動の中で指摘された欠陥や問題点はすべてエラーログとして記録され、その集計結果はプロジェクトや組織にフィードバックされる。レビューを行う際の観点や役割、ミーティング運営やリーディング法、指摘や意見の記録法、欠陥測定項目などが明確に定められており、認定された欠陥が修正されたかを確認するフォローアップのプロセスも定義されている。

 インスペクションは“モデレーター”という責任者を中心に行われる。モデレータは“オーナー”の依頼に基づいてインスペクション活動をスタートする。オーナーとはソフトウェアの設計者や開発者など、レビューを受ける側である。

 モデレータはインスペクション開始基準に照らして、インスペクションの実施の可否を判定する。実施する場合は、評価者である“インスペクター”を選出し、スケジュールの調整を行う。インスペクターはレビュー対象について詳しい知識を持つ専門家だが、オーナーと同じプロジェクトに属していない、別フェイズの担当者であるというように第三者の立場で参加する。

 準備ができればモデレータはキックオフミーティング(オーバービューミーティングともいう)を開催し、インスペクターに期待する役割を説明すると同時に(あるいは直後に)レビュー対象となるソース成果物と文書や評価方針、チェックリストなどをインスペクターに配布する。インスペクターは次回のミーティングまでに、1人で対象成果物を査読する。

 数日後にインスペクションミーティング(ロギングミーティングともいう)を行う。このミーティングの目的は欠陥の発見であり、欠陥除去や責任追及を議論する場ではない。インスペクターの指摘をオーナーが採用すれば、欠陥として認定される。欠陥指摘・改善提案の情報はオーナーに渡され、修正・解決が行われる。モデレーター(ないしは別に任命された検証者)は、その修正が実際に行われたかどうかを追跡し、これも記録する。

インスペクション参加者の役割
名称(別称) 人数
役割の内容
オーナー(オーサー、レビューイ) 1名
対象成果物を作成者。インスペクションを依頼する(ほかの役割を兼任できない)
モデレーター(インスペクションリーダー、司会、進行役) 1名
インスペクション全体を統括する。参加者の選出、スケジュールの作成、チェックリストの作成・改訂、欠陥状態のフィードバックなどを行う
インスペクター(チェッカー、レビューア、指摘者) 3〜4名
オーナーと異なる視点で対象成果物の問題検出を行う
プレゼンター(リーダー、読み手) 1名
ミーティングで資料を参加者に説明する
スクライブ(レコーダー、記録係、書記) 1名
ミーティングで提起された問題や欠陥を記録する。この記録は修正確認やプロセス改善、ソフトウェアメトリクスに使われる

 インスペクションには“チームによる成果物レビュー”という側面のほかに、その成果をソフトウェア開発プロセスやインスペクションプロセスの改善に利用するという活動がある。モデレーターは、検出した不具合情報や欠陥発生率などを分析して「インスペクション実施報告書」を作成し、改善のための“指標”をレポートすることも役割である。

 インスペクションは欠陥防止を目的とした活動であり、欠陥数などを人事評価に利用することはつつしまなければならない。こうした仕組みを導入すると、インスペクションで収集するデータは不正確なものとなるだろう。これはミーティングについても同様で、インスペクションミーティングに管理者(部下の業績評価や査定を行う立場にある役職者)を参加させてはならないとされる。

 インスペクションは1976年、IBMキングストン研究所のマイケル・E・フェイガン(Michael E. Fagan)がIBM Systems Journal誌に掲載した「Design and Code inspections to reduce errors in program development」で公開された。このことからインスペクションは「フェイガン・インスペクション」ということもある(「inspection」は検査・調査という意味の“単語”である)。

 フェイガンはインスペクションによって発見されたエラーは、そのソフトウェアで見つかったエラーの82%を占めたとし、さらにインスペクションは開発リソースの約15%のコストが掛かるが、トータルで開発コストを25〜30%低減すると述べた。

 インスペクションの導入効果は大きいとする意見や資料は多いが、大掛かりで組織的に実施する必要のある“重量級レビュー手法”であるため、カジュアルに導入することは困難だ。インスペクション・コンサルタントのトム・ギルブ(Tom Gilb)は成果物が少しできた段階でごく一部をサンプリングして欠陥の計測を行い、最終的な品質を予測する「アジャイルインスペクション」を提案している。

(注1)http://www.atmarkit.co.jp/aig/04biz/review.html

参考文献

▼『ソフトウェアインスペクション』 トム・ギルブ、ドロシー・グラハム=著/伊土誠一、富野壽=監訳/構造計画研究所/1999年8月(『Software Inspection』の邦訳)

▼『ピアレビュー ――高品質ソフトウェア開発のために』 カール・E・ウィーガーズ=著/大久保雅一=監訳/日経BPソフトプレス/2004年3月(『Peer Reviews in Software: A Practical Guide』の邦訳)

▼『コードコンプリート ――完全なプログラミングを目指して』 スティーブ・マコネル=著/石川勝=訳/アスキー/1994年8月(『Code Complete: A Practical Handbook of Software Construction』の邦訳)

▼「Design and Code Inspections to Reduce Errors in Program Development」 マイケル・E・フェイガン=著/IBM System Journal, Vol.15, No.3, July 1976. pp.182-211[PDFPDF


Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ