これからちょっとずつFFの社内の開発の様子や利用しているツールについて紹介していきます。 公開することで何かフィードバックが得られたりしたらうれしいなと言うことで。

そんなわけで今回は社内で利用しているバグトラッキングシステム（以下BTS）について。

Bug Tracking System

BTSとは何かと言うと、バグ(Bug)をトラッキングする(Tracking)システム(System)です。 そのまんまですからわかりやすいですね。 そうでもありませんか。すみません。

Bugzillaなどに代表されるBTSはバグのレポートを記録し、その対応状況を追いかけるためのツールです。 誰か（顧客や開発者自信やまたは通りすがりの人など）がバグを見つけたらBTSに登録しておき、開発者はそのバグの状況に応じて順次対応していきます。

要はウェブインタフェースを持ったバグデータベースなのですが、これがソフトウェア開発を運用していくにおいては非常に強力なツールです。

我々開発者がどこからともなく湧き出で襲い掛かるバグどもに冷静に対処できるのもこのツールあってのことです。

BTSを使うメリット

BTSを使うといいことだらけですよ。奥さん。

いいことリスト
- 最新の情報を共有できる
- 更新の通知
- 対応履歴の管理
- 対応の効率化
- 対応漏れがなくなる

最新の情報を共有できる

多くのBTSはウェブインタフェースを持つソフトウェアになっており、複数の人間が同時に同じバグデータベースにアクセスできます。

つまり誰でもいつでも新しいレポートをポストでき、リプライを付けられます。 またそれらのレポートが更新された次の瞬間には他の人間がそれを見ることができます。

これはBTSを使い慣れた人間には当たり前に聞こえますが、BTS以前の方法でバグを管理しているのと比べると格段の進歩ではないでしょうか。

エクセルやワード、もしくはメールベースでのバグの管理に戻れといわれたら私はきっと書置きを残して旅に出てしまうと思います。

更新の通知

多くのBTSにはバグレポートが更新されるとメンバーにメールを飛ばしたり、RSSで通知したりといった機能があります。

それによってレポートが更新されたのにそれを見逃して対応の遅れを招いたりといったリスクをなくすことができます。

対応履歴の管理

バグ対応の過程を含めた記録が残るので、バグが再発したときや似たようなバグが出たときに参照して参考にできます。

バグ発生の背景や、原因、対応方法などをしっかり書くような運用にしておくと一層幸せになれるかもしれません。

対応の効率化

バグの深刻度や緊急性に応じて優先度をつけて順序よく対応することができます。 たくさんのバグに囲まれてどれから対応すべきか右往左往して時間を浪費しまうといったことがなくなります。

またBTSをバグ受付の窓口にできますので、ゾーンに入っている開発者の作業をバグ報告で中断させる無駄が最小限に抑えられます。

対応漏れがなくなる

未解決のバグはリストに居残り続けますので、バグをうっかり対応忘れのまま放置してしまうといったことがなくなります。

正確には誰かがチェックしないと放置バグが出てくることはありますが、そのチェック自体が簡単にできます。

いろいろなBTS

世の中にはいろいろなBTSがあり、先にあげたBugzillaのほか、 Mantisや Tracなど様々なものがあります。 TracはWikiとSubversionのリポジトリブラウザも統合されているので、ドキュメントを含めたプロジェクト管理に非常に便利なツールとなっています。

FFではBTSとしてRubyで書かれた 影舞を使っています。 操作がシンプルでわかりやすく、項目のカスタマイズが簡単かつ柔軟にできるというのが理由です。

Tracにも心惹かれるものがあるのですが、 こちらのウノウラボの記事でも言われているようにリリース前の確認待ちのステータスがないので移行は進みませんでした。 最近はどうなっているのかちょっと追いかけてないので、また暇を見てチェックしてみたいと思います。

と、なんだかBTSの概説だけで長くなってしまったので、実際の運用面に関しては次回で。 しょっぱなから続きものですみません。