散在するバグ情報による問題点

このようにバグ1件1件にはライフサイクルが確かに存在する。その上、局面に応じてさまざまな形態で取り扱われるのである。

各人が与えられた役割を遂行するために、その目的に応じた表現方法を採用することは、ミスを減らし、効率よく作業を行う上で重要である。

しかしながら、散在するバグに関する情報の同期・不整合が発生しないようなケアを考慮すると、管理が煩雑になり、かえって各人の負担を増加させ、かつプロジェクトの状況を見誤る材料となる危険性がある。たった1つのバグでも、バグ票やバグ管理台帳、各自の作業リストや検証対象リストなど、情報が散在しているとどこに正しい情報が蓄積されているのか不透明になってくるからだ。

例えば、バグのライフサイクル上の状態を示すステータス、例えば「登録済み → 担当者アサイン済み → 作業中 → 解決済み → 完了」といったものは、バグ管理台帳上で管理されているであろう。それぞれのバグの駆除後のソースコードの記録は、担当した開発者独自の作業リストやそれに付随する作業レポート上に記載されているかもしれない。

このような状況だとバグ管理台帳だけを見ても、そのバグの細部にわたる情報を得ることはできない。詳細な情報を入手するには、全員の独自の作業リストを共有し、さらにバグ管理台帳とそれらの同期や関連を記載し、維持管理していく必要がでてくることになる。

バグと効率よく付き合うためのバグ管理システム

バグと効率よく付き合っていくにはバグを一元管理しつつ、各自の要望に応じた見せ方ができることが重要だ。各自には今まで通り、利用者が扱いやすい形式や表現を提供でき、それでいてバグとそれに関連する付随情報をすべて記録し、閲覧する仕組みということになる。

これが、まさにバグ管理システムである。バグ管理システムは通常データベースを用い、すべてのバグの情報をこのデータベースに格納する。バグの情報は、クエリを用いることで、目的に応じた形式で表現できる。例えば、バグの一覧表や1件ごとの詳細な情報である。また、一元管理されていれば、常にリアルタイムに情報にアクセスできるため、同期などに頭を悩ませる必要もなくなる。

バグの情報をそれぞれの目的に応じて提供する際により効果を得るためには、作業のプロセスの中にバグ情報の閲覧や、情報の更新を組み込む必要がある。これらが、作業の外側に存在すると、作業効率の観点から二度手間や非効率化、情報の更新漏れなどを引き起こす事態になるかもしれない。すなわち、バグ管理システムには目的に応じたインターフェースや入力補助支援の機能が求められることになる。 次のページ