b-shock. Fortress

トラックナンバーという言葉がある。
ソフトウェア業界でよく使われる言葉で、「ある開発プロジェクトで、その人達全員が抜けたらプロジェクトの存続が不可能になるという、キーマンの人数」を意味する。この数字が少ないほどプロジェクトが属人的であることを意味し、一般に、プロジェクトとしてのリスクが高い状態にある。
「トラックに轢かれたら困る人の人数」に由来しているそうで、なんというか、大変悪趣味な例えだなと。（ちゃんと調べてないけど、これ、多分日本人の発想じゃないね）

などと、本題と全く関係ないトリビアはともかく。
今月のWEB+DB PRESSで紹介されていた、tracを導入してみた。

trac公式
スクリーンショット ※コードブラウザが絶品

のっけからの脱線で恐縮だけど、ほんとの名前はtrac？それともTrac？
公式サイトでも二つの表記が混在しているし。サイト自体は小ぎれいなデザインだけど、名前に対するこだわりというか愛情をあまり感じないなぁ。
まぁ、一番大きなロゴが "trac" 表記なので、以後tracと呼ばせて頂くことにする。

気を取り直して本題に戻すと、tracはPython言語で記述されたバグ追跡システム（BTS）のひとつ。
ユーザーやβテスターからバグ修正や機能追加のリクエストを受け付け、開発者から対応や進捗状況を回答するという、典型的なフローがソフトウェア開発にはあるが、BTSはこうした一連の作業を支援する為の一種のタスク管理ツールだ。（掲示板やメーリングリストで代用されることも多い）

試験的に影舞を使ってみたことはあった。Rubyアプリらしくシンプルで、導入も簡単ななかなかの優れものだったが、Subversionによるソースコード管理と併用すると少しばかり煩わしかったりした。
バグ対応で、ソースコードの一部を修正したとする。併用の運用では、Subversionと影舞の双方に修正を報告する必要があり、しかも大抵の場合は似た様な報告をすることになるわけで、イヤでも「あぁ、この作業は生産的ではないな」と感じてしまう。
シンプルな単機能のツールというのは本来理想的な形のひとつだが（ツールキットアプローチ）、BTSとソースコード管理に限っては、連携していたほうが良いと強く感じた。

その意味でtracのSubversion対応は、まさにぼくが探していたものだった。ソースコードの修正をSubversionに登録すると、修正内容がtrac側にも自動的に反映する。
ほかにも「ロードマップ」なるマイルストーン単位での進捗管理機能とか、タスクのRSSフィードとか、自由入力用のWiki機能とか。

FreeBSDなら、日本語版がportsコレクションに含まれている。（japanese/trac）Subversion, Python（あともちろんApache2）といった、比較的大きなパッケージに依存しているから時間こそかかるが、導入上、とくに難しいところはなかった。

目下の悩みは、ちょっと重いこと。CGI版は重過ぎるので、実運用にあたってはFastCGIかmod_pythonか、いずれかの方法で高速化することになる。
ぼくはFastCGI版でやってみたけど（Railsで推奨してることもあって、最近再評価されてるよね＞FastCGI）、大した効き目はなかった。Python環境の構築からやり直さなきゃいけなくなりそうだけど、いずれmod_python版も試してみたい。

BTSの運用を始めたからといって、ソフトウェアの品質に即反映するわけではないだろうだけど、履歴管理はいずれにしても必要。使いやすいコミュニケーションツールが、間接的に品質を向上させることもあるかもしれない。
以前展示会で見たSourceForge Enterprise Editionもすごくいい感じだったけど、きっと素晴らしいお値段だろうし、当面はtracを仕事に役立てていこうと思っている。