ホワイトペーパー：“目的”のない不具合管理を続けていないか？ -04-
自社の現状によって 異なる施策
不具合管理を導入もしくは更なる有効活用を目指すにあたっては、まずどの程度不具合管理ができているのか現状を把握し、この先何を目指すのかを明確にする必要がある。
図２は不具合管理状況とそれに応じた施策を５段階でまとめたものだ。現在の状況に応じて施策や目指すべき目標は違ってくる。
図２ 不具合管理状況とその施策
- Lv.1
- 不具合管理の規約やルールもない状態。規約やルールの整備も必要であるが、意識改革こそが最も必要となる。
- Lv.2
- 不具合管理の規約やルールが存在しており、発生した不具合情報を共有化し、管理されている状態。
- Lv.3
- 発生した不具合事象への対応だけでなく、不具合発生原因を調査し、類似不具合の再発防止に努めている状態。ただし、再発防止策は当該製品のみとなり再発防止策もテストなどの事後防止策となる。
- Lv.4
- 類似不具合の再発防止策を製品ファミリー群に適用している状態。不具合が発生した製品だけでなく、同一もしくは類似不具合が発生しうる製品に対しても再発防止策を講じている。
- Lv.5
- 発生した不具合情報を全社的に共有し、再発防止に努めている状態。再発防止策もテストなどの事後防止策ではなく、不具合を作りこまないためのナレッジやレビューといった事前防止策となる
先ほどの不具合管理のステップと合わせると、Lv.1～2は不具合事象の管理、Lv.3～4は再発防止、Lv.5は情報の活用を目指すこととなる。
では、不具合管理導入及び活用のポイントを先の３つのステップ、不具合事象の管理、再発防止不具合情報の活用、に沿って紹介しよう。
STEP1 不具合事象の管理
このステップについては書籍やWEBなどでも情報が非常に多いため、ここではポイントとして以下の2点を挙げておくこととする。
- 意識改革
- 運用／定着の推進
「意識改革」とは、開発に携わる関係者全員が不具合管理の有用性や重要性を理解することである。不具合事象の管理ができていない原因の多くは、プロジェクトマネージャや現場の開発者が不具合管理の有用性や重要性を理解できていなかったり、疑っていることである。規約やフローの整備よりも、まずは有用性や重要性を再認識することが必要となる。
「運用／定着の推進」とは、不具合管理の規約やフローを一度決めただけで、見直しや改善を実施せず、不具合管理が定着していないケースにおいて必要な対策となる。不具合管理の規約やルールは一度決めればそれで終わりではなく、都度、業務や組織にフィットするよう改善を続けることが求められる。
もしあなたの会社で不具合事象の管理ができていない、定着していないならば、大抵上記のいずれかに該当すると考えられる。
STEP2 再発防止
このステップにおいて効果が出ていないケースの多くは、なぜなぜ分析などの真因分析に時間をかけているが、効果のある対策に結びついていないというものだろう。というのも、ソフトウェア開発は人に依存する部分が非常に多く、真因を分析することや効果のある対策を立てることは非常に難しいのである。ここでは真因分析する際の簡単なポイントを紹介する。
不具合の原因としては、発生原因と流出原因の２つがある。図３を見ていただきたい。
図３ 原因分析のフレームワーク例
発生原因とはなぜ不具合を作りこんでしまったのかという発生側の原因である。それに対し流出原因とはなぜ検証の際に不具合を検出できなかったのかという原因である。本来は発生させなければ流出はしないので、まず発生原因を分析することが好ましいが、発生原因の分析や発生原因に対して効果的な打ち手を出すことは非常に難しい。一方流出原因の多くはテストケースの漏れとなるため、比較的打ち手が実施しやすい。
また、発生原因にしても流出原因にしても、作りこんだフェーズと検出すべきフェーズを明確にすべきである。問題となったフェーズを明確にしなければ同じ過ちを繰り返す可能性は非常に高くなってしまう。本来、単体テストにて検出すべき不具合だったのか、総合テストにて検出すべき不具合だったのか、ということを実績として重ねていくことにより、単体テストにおけるテストケース量の妥当性や不具合検出量の妥当性など、大きなレベルでの再発防止策にも繋がるのである。
STEP3 不具合情報の活用
最後のステップである不具合情報の活用であるが、過去の不具合情報をナレッジ化し共有化することは重要だ。だが不具合情報の多くは当事者にしか分からない内容であり、仮に内容を理解しても別の開発では役立たない情報であるというケースがほとんどであろう。不具合情報をナレッジ化することは非常に難しく、運用コストも非常にかかるのである。単純に何らかのパッケージを導入すれば実現できるものではない、ということをご理解いただきたい。
不具合情報を活用する上でのポイントとしては２点が挙げられる。
- 導入の進め方
- 不具合情報項目
まずは下の図４を見ていただきたい。不具合情報を活用する上での進め方を表したものだ。
図4 進め方のポイント
通常の業務の流れに沿って「不具合事象の把握」⇒「不具合原因の追求」⇒「不具合情報の活用」という検討順で進めてしまいがちだが、逆方向で検討する方がよい。業務順で検討順で行うと、「不具合事象の把握」「不具合原因の追求」で入力できる情報ありきで、入力された情報のみを対象とした「活用」を検討することになってしまう。
業務の流れと反対に「不具合情報の活用」⇒「不具合原因の追求」⇒「不具合事象の把握」の順序で検討するならば、「不具合情報の活用」する際に必要な情報は何か、その情報を「不具合原因の追求」「不具合事象の把握」で入力できるか、という検討ができる。
不具合情報の「活用」ができてないという事例は、この検討順が間違っていることが多い。まずは活用したい情報とは何かということを決めることが大事でなのである。
不具合情報の項目を検討するには、以下の図のように不具合項目は「見るための情報」なのか「探すための情報」なのかに分けて検討するとよい。
不具合情報の活用においては、有効な情報を探せない、探せても見たい情報ではない、という状況が、必ずといっていいほど発生してしまう。
こういった状況に陥らないために、情報を「見るための情報」「探すための情報」の情報に分けて検討するのである。
「見るための情報」とは、情報を見て開発に活用するための情報である。例えば、不具合事象であったり、原因、対策内容などが該当する。
それに対し「探すための情報」とは、不具合管理などで検索キーなどとして利用し、「見るための情報」をヒットさせるための情報である。例としては類似製品であったり類似機能であったり、使用を検討しているモジュールの名称などが該当する。
不具合情報の項目と一緒くたに考えるのではなく、見たい情報は何か、その情報を何によって検索するのか、を整理して検討することで、探すことができない、探せても使えないという状況を防ぐことができる。
>>-05- まとめ
PDFファイルをダウンロードしてまとめて読む【ダウンロード申込】
─ Index ─
-01- はじめに
-02- 不具合情報入力は大変だが効果が出ない不具合管理
-03- いきなりナレッジデータベースを構築するのは失敗のもと
-04- 自社の現状によって異なる施策
-05- まとめ
- Copyright 2010 Nextech Corporation, All Rights Reserved.
- このドキュメントに記載された内容は情報の提供のみを目的としており、明示、黙示または法律の規定にかかわらず、これらの情報についてネクステック株式会社はいかなる責任も負わないものとします。 お客様は著作権に関する法律を遵守する必要があります。このドキュメントのいかなる部分も、ネクステック株式会社の書面による許諾を受けることなく、その目的を問わず、どのような形態であっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての手段を含みます。ただしこれは、著作権法上のお客様の権利を制限するものではありません。 すべての商標は、その所有者に帰属します。