ホワイトペーパー：“目的”のない不具合管理を続けていないか？ -02-

不具合情報入力は大変だが効果が出ない不具合管理

近年、組込みソフトウェアは機能拡張や適用範囲が急速に拡大し、社会インフラを担っていると言っても過言ではない。携帯電話やポータブルオーディオ、自動改札機、ETSなど身の回りには、組込み製品があふれている。
こうした状況の中、組込みソフトウェアの不具合がもたらす影響が非常に大きくなっており、組込み製品を開発する企業では組込みソフトウェアの品質確保や不具合管理が重要になっている。
筆者は業務上、多くのソフトウェア開発の現場を訪問し、多くの不具合管理の手法や仕組みを見てきた。
手法として、不具合の再発防止に向けた原因分析を徹底しているケースや過去不具合のナレッジ化に取り組むケース、仕組みとしてBTS（Bug Tracking System）を導入しているケースやMicrosft Excelで運用しているケースなど様々な現場に立ち会った。
だが、その評価を現場の方にヒアリングすると、多くの場合、不具合管理方法に課題があるという。課題の一例をざっと挙げると以下のようなものがある。

  • 不具合情報として入力する項目が多く工数がかかる
  • 不具合対応に追われてしまい、対応が終わってから、不具合管理に結果を登録している
  • 不具合発生時に真因分析を行っているが、効果があると思えない
  • 類似不具合の再発防止のために過去の不具合情報を活用しろと言われるが、有効な情報を探し出せない

こうした課題は、どんな不具合管理システムを利用しているかにに寄るものではない。不具合管理導入の際に、目的を定義していないまま導入してしまったがために発生したものだ。目的を定義しないまま、ツール選定やワークフロー、不具合の項目ばかりを検討していると、利便性や機能の多さでツールを選定したり、何となく必要と思われる項目を列挙したりといったことが行われてしまう。
その結果、工数ばかりかかる過剰な入力項目を設定したり、意味のない承認行為を組み入れたりと、結果として現場の人間にとって“目的”を見失った不具合管理になってしまうのである。
とはいえ、実際に読者が不具合管理に関する情報を集めようとしても、WEBなどに掲載されている情報は「ツール比較」や「不具合ステータス」や「不具合管理フロー」といった仕組みに関する情報ばかりであろう。

そこで本稿では、開発現場で効果の出る“目的”に沿った不具合管理を実現するための方法や、そもそも不具合管理の目的とは何かという点を整理して説明したい。

>>-03- いきなりナレッジデータベースを構築するのは失敗のもと
pdfPDFファイルをダウンロードしてまとめて読む【ダウンロード申込】

─ Index ─

-01- はじめに
-02- 不具合情報入力は大変だが効果が出ない不具合管理
-03- いきなりナレッジデータベースを構築するのは失敗のもと
-04- 自社の現状によって異なる施策
-05- まとめ

公開資料・出版物のご案内