この連載記事の目次へ

不具合の修正は影響範囲を意識

 適切な計画を立案して,混乱させることなくプロジェクトを遂行することに主眼を置くプロジェクト管理や構成管理に対し,プロジェクトが混乱に陥った場合に復活する手段として使えるのが不具合管理である。不具合の修正漏れや修正ミス,不具合修正の進捗が見えないといった問題に対処するための技術である。品質データの可視化にも有効だ。

この記事は,「日経エレクトロニクス」と「日経バイト」が刊行した別冊『組み込みソフトウエア2006---品質管理と開発技法の実践的改革A to Z』の掲載記事を抜粋したものです。別冊の詳細はこちらをご覧下さい

 不具合管理の難しさは,不具合の量に起因する。ソース・コード1000行当たり2件の不具合というのは,かなり品質が高いプロジェクトといえる。それでも,ソース・コードが10万行になると200件,100万行になると2000件の不具合が現れることになる。混乱しているプロジェクトでは,この値が10倍にも20倍にもなってしまう。

 さらに,変更管理との関係もある。不具合を修正する場合,ソース・コードに手を入れる。つまり,利害関係者に影響を与える可能性を持った変更を実施することになる。変更の判断のための委員会を設置するという考え方が出てくるくらい,変更には大きなリスクが伴うのである。大量に発生する不具合の1つ1つについて変更を適切に管理するためには,コンピュータを使った自動化が必要になってくる。

 不具合の発見に伴う変更のフローは,各社ともそれほど大きく変わらないだろう(図6)。重要なのは,変更の影響範囲をいかに特定するか,という点である。変更の可否を検討する構成管理委員会によって,他のどの部分に影響を与えるのか,それも修正する必要があるのか,などを十分に議論しなければならない。この水準まで不具合管理を実施している企業は,現時点ではほとんどないだろう。

不具合の修正フローを明確にする
図6 不具合の修正フローを明確にする
発見した不具合だけを考えて修正を加えると,別の部分に不具合を生じさせる可能性もある。修正だけでなく,その修正が及ぼす影響を見極める作業フローを定義しておかなければならない。

 ここでは,不具合レポートの内容を的確なものにする努力が欠かせない。これを怠ると,変更の可否を適切に判断できなくなってしまう。不具合レポートに変更レビューの必要性の有無を明記したり,変更レビューの議事録を不具合レポートに追加したりすることが必要になる。このほか,変更の影響範囲を調べるテスト結果を不具合レポートに追加するというルールを設けるのも手である。

 不具合管理をコンピュータ化すれば,そこにデータが揃う。不具合の出方と修正の進捗状況,サブシステムごとの品質などのグラフが得られるようになる。構成管理のステータス&アカウンティングと同様に,状態を適切に管理することが,作業状況の統計的な把握を容易にするというメリットをもたらす。

(連載のこの章終わり)

(福井 信二=オムロン インダストリアルオートメーションビジネスカンパニー コントロール機器統轄事業部 技術部 技術開発グループ 技術専門職)