バグがツナグ！開発者と開発チームメンバー

バグと変更セットの関連付けにより、ソースコード中心に作業をしている開発者と、ソースコード中心ではない他の開発チームメンバー間の橋渡しをバグが行ってくれることになる。開発者は、普段通りのバグの駆除作業に注力し、バグのステータスを「作業中」などから「解決済み」に遷移させるだけで、バグを基点として開発チームメンバーに情報を提供することができるようになる。すなわち、開発者からバグの詳細報告や、それらの問い合わせへの負荷を軽減することができることをあらわしている。

開発者間においても、例えば過去に駆除したものと似たようなバグの駆除を行う場合は、過去に駆除した際の変更セットを見ることでその方法を知ることができるかもしれない。また、ソースコード上の気になる記述方法があったときに、その記述をしたのはなぜかを知りたい場合は、その変更セットと関連づけられているバグをたどれば、動機を知ることもできるだろう。

しかしならが、まだ困難な点がある。多くのバグ管理システムとソースコード管理システムが独立しているということだ。今まで述べてきた事柄は、この2つのシステムが関連づけられることが前提となっている。これら2つのシステムを何らかの形で、データ連携をさせるか、もしくは1つのシステムでこれらを実現できると目的を達成しやすいことがわかるだろう。2つのシステムを連携する場合は、連携のための操作が煩雑でないことや、システムの運用や保守が複雑すぎないことなど、求められる条件も多岐にわたる。また、ソースコード管理においては、変更セットをサポートしているものも限られている。

Team Foundation Serverによるバグとコードの一元管理

Team Foundation Server（以下、TFS）では、バグ管理を包含しているだけではなく、ソフトウェア構成管理（ソースコード管理を含む）も包含している（TFSではソース管理と呼ぶ）。TFSでは、これらのバグやソースコードをSQL Serverで一元管理するため、関連付けが容易に行える。それだけではなく、バグからもソースコードからもこの関連付けを追跡することができ、関連付けの設定から追跡まで簡潔な操作で実施することが可能である。

TFSでは、変更セットもサポートしている。ソースコードを結合（共有）することをチェックインと呼ぶが、チェックインを行うと自動的に変更セットが作成され、複数のソースコードのバージョン一式を識別できるようになる（変更セットにはID番号が付与される）。チェックインの際には、バグとの関連付けを行うこともできる（バグとの関連付けを必須にし、関連づけないとチェックインが行えないようにすることもできる）。関連付けを行うと、バグのステータスを自動的に「解決済み」などに遷移させることもできる。

ソースコードのバージョン履歴はすべて変更セットで識別できるため、1つのソースコードだけではなく、複数のソースコードにまたがった変更も過不足なく把握することができる。また、個々のソースコードにおいては注釈つきで閲覧することができる。これによりソースコードのどのブロックがどの変更セットで作成／変更されたのかを横断的に見ることもできる。この変更セットがバグと関連付けられていれば、バグの情報まで追跡できてしまうのだ。

TFSは、Visual Studioなどの統合開発環境との親和性も高いため、開発者はバグの確認やバグの駆除作業、ソースコードの管理をすべて使い慣れた統合開発環境の中で実施できるのも見逃せない点である。

さて、次回の最終回では、バグを極力作らないために、開発者が行えること、すなわち、開発者による品質の作りこみについて解説する。