紙か？ Wordか？ Excelか？ BTSか？

来週からこのプロジェクトのバグ管理をやってくれたまえ

ある日突然上司からこのようにいわれて、「オーケーです！まかせてください！」と2つ返事で引き受けることができるだろうか？

ぼんやりとはわかっていても「実際にバグ管理って何をどう進めればよいのだろうか…」と途方にくれる方もいるだろう。そこで本連載の第2回からは、バグ管理において「いつ」「何を」「どのように」行えばよいのかを解説していく。

まずバグ管理全体の流れからポイントをまとめ、紙、Word・Excel、BTSを比較していこう。

バグの修正を発見された順番に行っていてはダメ

まず、本連載では「バグの管理とは、バグレポートのワークフローを定め、バグの数を把握し、バグに優先順位をつけ、バグのステータスを把握すること」と定義する。

第1回でも述べているように、バグを効率的に管理することは重要である。例えば、あるシステムで100件のバグが見つかったケースを考える。バグを効率的に管理した場合と、そうでない場合で、バグを修正し終えるまでの時間や作業量に違いがあるだろうか？

「トータルでバグ修正にかかる工数は同じはずだから、時間に違いはないのでは」と考えた方がいたとしたら、それは大きな間違いである。

あるバグは長期間放置することで不正なデータを蓄積してしまい、早く修正に着手しなければ対応工数がどんどん膨れ上がってしまう場合もある。また、修正に時間がかかりそうなバグでも、見た目上の問題だけでデータやシステムを使っての実作業に影響が少ない場合もあるからだ。

つまり、「発見したバグを何も考えず、発見された順番に修正作業に着手していては、効率的な作業ができない」のである。

さらに、プロジェクトの規模が大きくなると関係者の数が多くなり、その分バグが発見されるタイミングや場所が多岐にわたるようになる。それらが整理されないまま、次々に修正担当者へ舞い込み、報告も顧客を含むあらゆる関係者からやってきたらどうだろうか？

毎日残業してもバグがなかなか減らず、そもそもどれだけ残件のバグがあるかわからないという状況に陥り、デスマーチ一直線である。

バグは効率的に管理することで、修正のコストやバグ対応の期間をコントロールでき、プロジェクトを健全な状態に保つことができるのである。

では次に、バグ管理全体の流れの中でのポイントを解説する。