バグとの付き合い方を見直す

現在バグの管理には、バグ管理システムを利用するケースが多い。しかし、本連載ではバグ管理のツールとして「Visual Studio Team System 2008 Team Foundation Server（以下、TFS）」を取り上げたい。TFSは、ソフトウェア構成管理やプロジェクト管理を含めた開発インフラストラクチャである。ではなぜ、バグ管理でTFSなのか。今回は「バグとの付き合い方」について改めて考え、なぜバグ管理にTFSを取り上げるのかを紐解いていきたい。

さて、ソフトウェアにはバグがつきものとはいえ、特に開発の中盤以降に大量発生する予測できないバグは、プロジェクト管理者だけではなく、開発者、そしてテスト担当者も悩ます共通の「敵」である。しかしながら、バグとは今までも、そしてこれからも付き合っていくことになる。なぜならば、バグは決してなくならないからだ。

とはいえ、今までと同じようになんとなくズルズルとバグと付き合っていたのでは、現状維持が関の山である。その現状を打破するには、バグとの付き合い方を見直す必要がある。

一言で「バグとの付き合い方」といっても、そんなに簡単なものではない。なぜなら、バグは状況によって、さまざまな形に変化するからだ。バグと関わる関係者も多種多様であり、それぞれの立場によって把握したいバグの状況も異なってくる。

バグとの付き合い方を見直すためには、バグがどこからやってきて、どう駆除されていくのかを改めて整理する必要がある（本連載では、バグが修正され、問題が解決することを駆除とする）。すなわち、バグのライフサイクルの整理だ。

まず、バグに関わる関係者を洗い出してみよう。バグは、ソフトウェアの利用者やテスト担当者、そして開発者とも関わってくる。また、バグ総数や進捗の状況を把握しなければならないプロジェクト管理者や製品の品質担当者もあげられる。このように、開発チームだけでなく、外にも多くの関係者がおり、それぞれが自らの目的を達成するためにバグと向き合っているのである。

バグは、形を変えながらライフサイクルを終える

バグはそのライフサイクルにおいて、さまざまな形態に変化していく。例えば、バグが発見されるきっかけは、ソフトウェアの使用者からの電子メールや電話による問い合わせかもしれない。あるいは、開発チーム内での打ち合わせや、口頭による報告かもしれない。

その後、それらはバグ票と呼ばれる一定の書式で起票され、はじめてバグとして認知される。バグ票は紙ベースであったり、バグごとにテキストファイルやMicrosoft Excel（以下、Excel）のシートを作成するであったりするだろう。

開発チームでは、そのソフトウェアのバグの全容を把握するため、バグ票のすべての情報を把握できるバグ管理台帳のような一覧を作成する。これもまた紙ベースやExcelで作成される。

さらにバグの駆除を担当する開発者は、自分の担当しているバグだけを一覧にして、日々の作業リストを別に作成する可能性もある。さらに、ソースコードの変更箇所を記録するレポートを求められ、別途作成することもあるだろう。

さまざまな媒体に分散しながら寄生していくバグたちと、うまく同期を取りながら、駆除や検証、リリースを迎えるわけである。これらの情報の整合性を確保しつつ、かつできる限りリアルタイム性を維持していくには、バグの駆除を行うのと同じかそれ以上の神経を費やす必要がある。 次のページ