開発者のバグ駆除作業を振り返る

開発者は、バグの駆除を実践する。これは、開発者がバグだけではなく、それと同時に関係するソースコードとも付き合う必要があることを示す。バグを駆除するためには、駆除対象となるソースコードの構成を特定し、取得する必要がある。場合によっては、バグが発見されたときのソースコードの構成を参照することもあるかもしれない。そしてバグの駆除作業を終えて適切な確認を経た後に、バグが駆除されたソースコードの構成を結合（共有）することになる。

この一連のソースコードの扱いは極めて複雑であるが、定型的な作業でもある。そして、手作業で行うと思わぬミスを犯しソースコードの紛失や、バグの再発などを引き起こす危険性もある。開発者にとっては厄介な作業の代表例だ。

このためこれらのソースコードを扱うために、多くのプロジェクトではソースコード管理を行う（本来は、ソフトウェア構成管理について言及すべきであるが、ものごとをわかりやすくするため今回は、ソースコード管理とする）。

ソースコード管理では、格納されたソースコードがそれぞれバージョン制御（リビジョン制御とも言う）される。個々のバージョンでは、そのソースコードについての詳細な情報が格納されている。例えば、いつ誰が変更したか、どのような理由で変更したかなどの情報や、前のバージョンと比較することで何を変更したのかという情報を得ることができる。

ソースコード管理での作業の進捗と品質のチェック

では、バグの駆除作業の進捗や品質（ひいてはソフトウェアの品質やプロジェクトの進捗）をソースコード管理の情報のみから把握するのはどうか。なぜならば、開発者にとってもっとも馴染みがあり、扱いやすいのがソースコードであるからだ。馴染みのあるものでこれらの情報を把握できるのならば、価値があると言える。

しかしながら、開発者以外の開発チームメンバーとの間での報告はどうか。例えば、プロジェクト管理者がバグの駆除作業の最中や終了後の報告として考えてみると、「BankAccount.csのver.1.4などでバグ管理番号101を駆除しました。詳細はソースコードと付随する情報を見てください」と言われたとする。

この場合、プロジェクト管理者はソースコード管理下にアクセスし、同じコメント（おそらく「バグ管理番号101」が記載されているはずであろう）が付加されているすべてのソースコードを識別し、次回のテスト用のベースラインに含まれているのかどうかを確認しなければならない。この作業を「全開発者数×全バグ数」を繰り返し行うことでしか、品質や進捗を推しはかることができないとなると、大きなオーバーヘッドになる危険性があるだろう。

つまり、ソースコード管理のみで、開発チーム全体で品質や進捗を共有するのは難しいということが言えるのではないか。 次のページ