第3回：バグが開発者と開発チームメンバーをツナグ！ (2/3)

バグ管理での作業の進捗と品質のチェック

それでは、バグ管理ではどうか。バグは共通の関心ごとであり、バグのライフサイクルを通じて、ソフトウェアの品質とプロジェクトの進捗を知ることができることは前回に説明した。このことから、開発者が実施するバグの駆除作業の品質と進捗の把握もバグ管理下で行うことができると言える。これが行えれば、開発者間および、プロジェクト管理者をはじめとする他のロール間でも情報のやり取りを同じ粒度で行えるようになるのではないだろうか。

これを実現するためには、バグと実際にバグを駆除したソースコードとの関係を保持しておくことが条件となるだろう。なぜならば、バグの情報にはソースコードの詳細な情報やソースコードの構成についての情報が含まれていないからである。またバグ管理の情報とソースコードの情報の乖離が起きる可能性もあるだろう。すなわち、バグ管理とソースコード管理の関連付けがカギを握っているといえる。

この関連付けには非常に意義がある。バグ管理の観点からすると、バグと関連するソースコードの関係をレビューすることで、例えばリリースビルドで確かにそのバグが駆除されているかといった詳細まで追跡ができるようになる。

ソースコード管理の観点からも、1つ1つのソースコードのバージョンがどのバグを駆除するために行われたのかを把握することができるし、複数のソースコードへの変更であってもバグを基点にし、すべての関連するソースコードのバージョンを特定することでもできるようになるだろう。

変更セット

バグと各ソースコードのバージョンを関連付けることは、非常に意義があるが、実はまだ複雑な要素を含んでいる。ソースコードの各バージョンというのは、ソースコード管理システムとしては必須で持っていなければならないものである。しかし、開発者にとって必ずしもなくてはならないものではない。

なぜならば、開発者にとって最も把握したい単位は「今回のバグの駆除作業で作成や変更したソースコードの一式」だからだ。必ずしも、個々のソースコードの詳細なバージョン番号を1つ1つ把握している必要はないのである。そこまで注意深く認識しなければならないのでは、開発者の負担を増加しているにすぎない。

そこで変更セットである。変更セットとは、先に述べた自分の作業で作成や変更したソースコードの一式（正確には個々のソースコードのバージョンの一式）である。いわば、バグの駆除作業のトランザクションと言えるものである。

変更セットでソースコードの構成を把握できると、開発者は自分の作業の単位で、それ以外の開発チームのメンバーはバグという単位でものごとを把握でき、さらにバグと1対1で関連付けられた変更セットでより詳細なソースコードの情報へも追跡できるようになる。 次のページ