BTS

BTS = Bug Tracking System。プログラムを開発・保守していく上で切っても切れない作業であるバグ管理をサポートする環境を指す。バグの発生から、対処して確認するか棄却するまでのライフサイクルを管理できる。有名どころでは、BugzillaMantisといったところか。Webインタフェースを用いるものが多い。

なんでこんなこと書いてるかというと、単にいま使っていて、実に具合が良いからである。

BTSは、主にオープンソースコミュニティで、遠隔地にいる開発者同士でバグ情報を効率よく管理するために使用されているが、別に会社内でのローカルな開発でも十分に使える。

旧来のやり方は、MS-Excelにバグ管理表(呼び方は多々ある)を書き起こし、これをファイル共有してみんなで更新するものである。他にもいろんな管理方法があるだろうが、まぁ五十歩百歩であろう。この場合、最新版のファイルの所在がわからなくなる、自分の更新が他人の更新で上書きされて消えてしまう、ファイルを更新しても見ていない人間がいる、といったありがちな問題が起きがちである。

しかし、BTSはまず実体が一つしかないので情報が複数箇所に散るということがない。また、排他制御もシステムが面倒を見てくれる。さらに、誰がいつどこを更新したのかすぐにわかるし、情報が更新されたら関係者に自動的にメール配信する、RSSフィードを発行して更新を追いかけられるようになる、といったたくさんの恩恵がある。インタフェースも使い慣れたWebなので大抵の場合は容易で、遠隔地同士での情報共有も楽勝。

これまでは、BTSのこうした利便性を知りながらもなかなか導入できずにいた。なぜなら、現場の開発では、納品物に試験項目書なりバグ管理表なりが含まれることが多いからである。BTSはバグ情報をデータベースで管理するので、そのまま書類にできないのだ。今の仕事では自社開発でやり方を自由に選択できるので入れることができた。

影舞というBTSを使っているのだが、機能的に今ひとつ物足りないものの、実に扱いやすい。ノーストレスで、しっかりとバグ情報を管理できる。従来のやり方がまどろっこしくてあほらしく感じる。無理矢理にでも導入する価値があると思う。書類の作成など、それをするプログラムを自分で書けばよいのである。JavaでもPerlでも、MS-Officeのファイル形式にエクスポートするためのライブラリがある。

ラッキング対象をバグに限定せず、「やるべきこと」という大枠で扱うITS = Issue Tracking Systemというものも存在する。使ったことはないが、BTSの有用性を鑑みるに、結構良いものかもしれない。