「不具合疑い」と「不具合確定」を同じ表で管理してはいけない理由

はじめに

テスト工程や本番運用が始まると、「バグ管理表」を作る会社は多いですが、そこに利用者からの問い合わせまで一緒くたに記入してしまっているケースをよく見かけます。進捗報告の受け方でも触れた通り、数字を正しく読むためには、まず集計の前提を揃えることが欠かせません。

SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応してきた経験から、バグと問い合わせを分けて管理すべき理由を解説します。

「不具合かどうかまだ分からない」申告は、バグ件数に混ぜない

利用者から「システムの動きがおかしい」という連絡が来たとき、それが本当に不具合なのか、単なる操作ミスや仕様の誤解なのかは、調査するまで分かりません。これをいきなりバグ管理表に記入してしまうと、実際には不具合ではなかったものまでバグ件数としてカウントされ、本来の不具合発生状況が見えなくなります。

まずは「問い合わせ」として受け付け、調査の結果、不具合と確認できたものだけをバグ管理表に転記する、という2段階の運用にすることで、バグ件数の数字に意味を持たせられます。

重要度の判断基準を、テスト工程に合わせて変える

バグの重要度判断は、発見されたフェーズによって基準を変える必要があります。単体テストで見つかった軽微な不具合と、本番運用中に発見された同じ不具合では、緊急度がまったく異なります。

「システムが停止する、データが破損する」レベルは即時対応の「緊急」、「主要機能が使えないが回避策がある」は当日〜翌営業日対応の「高」というように、重要度と対応スピードの基準を事前にメンバー間で合意しておくことで、本番障害発生時にも迷わず動けます。

問い合わせの中にこそ、改善のヒントが眠っている

問い合わせ管理表を独立して運用するもう一つのメリットは、「要望」カテゴリの問い合わせが蓄積されていくことです。不具合ではないものの、利用者が日々感じている不便さや改善要望は、次期フェーズの機能改善における貴重な材料になります。

バグ管理表だけを見ていると、こうした声は記録として残りません。問い合わせを独立して管理することで、不具合対応とは別の軸で、システム改善のヒントを蓄積できます。

まとめ

不具合管理は、「不具合疑いの申告」と「不具合と確定したもの」を分けて管理することから始まります。重要度の判断基準をテスト工程に応じて明確にし、問い合わせの中に眠る改善のヒントも取りこぼさないようにすることで、不具合管理表は単なる記録以上の価値を持つようになります。

実際に使っている不具合管理表・問い合わせ管理表のテンプレートは、noteで配布しています。

執筆者プロフィール：SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応。基幹システム刷新・DX推進プロジェクトに多数従事。