前回（第2回～第3回）までの連載で，Tracのインストールと基本的な設定が終わりました。これからの連載では，Tracを上手に運用するためのコツをご紹介していきます。
Tracの主な機能には，Wikiとリポジトリブラウザ，それにチケットによるタスク管理システムがあります。Wikiとリポジトリブラウザは使っていても，チケットは使っていないという方は意外に多いのではないでしょうか。そこで第4回では，チケットの一番の用途である「バグ管理」について説明します。今回の説明には，Trac 0.11（日本語版）が含まれるTrac Lightningのバージョン2.0.4を使用しますが，基本的な考え方は以前のバージョンであるTrac 0.10 にも適用できます。
バグ管理が必要な理由とその課題
そもそも，なぜバグ管理が必要なのでしょうか。ソースコードをSubversionなどの構成管理ツールで管理していれば（もちろん管理していますよね？），いつ誰がどのようにソースコードを変更したのかがわかります。それだけではダメなのでしょうか。
もし，プログラムの規模が小さく，自分一人で作るのであればバグ管理は不要かもしれません。しかし，プログラムの規模が大きくなり，担当するメンバーが増えるとともに，以下のような理由により，地理的，時間的なメンバー間の情報共有が重要になってきます。
- 発見されたがまだ修正が完了していないバグはいくつ残っているのか？
- 以前にも似たようなバグが発生していなかったか？
- そのバグはどのような手順で発生するのか？
- バグへの対処案はいくつかあるようだが，なぜこの対処案で修正したのか？
- このプロジェクトで発生しているバグには，どのような傾向があるのか？
メンバー間で十分にバグの情報が共有されないと，せっかく直したバグを再発させたり，バグの修正を忘れたままソフトウエアをリリースしたりということにもなりかねません。Subversionの変更履歴（チェンジセット）はソースコードを修正した「結果」を示してくれますが，なぜ修正したのかという「プロセス」は示してくれません。プロセスをソースコードのコメントやコミットログに残すこともできますが，バグの再現手順などの詳細を記録するには向いていません。メーリングリストやIRCでの議論もよく使われる手法ですが，記録をまとめて残すという点では問題があります。
このような理由から，バグの発生条件，影響範囲，原因，修正案と採用理由などを「バグ管理票」として記録することになります。しかし，ファイルサーバーとExcelファイルなどで管理しようとすると，しばしばバグ管理票に正しく記入してもらえないという問題が発生します。
- メーリングリストなどでの議論の結果をバグ管理票にまとめることが必要だが，忙しくてついつい後回しになる。
- ソースコードの修正個所をバグ管理票に転記する必要があり，その手間が面倒。
そこで有効なのが，Tracのチケットを用いたバグ管理です。
Tracのチケット機能を使うメリット
Tracのチケットには，以下のような機能があります。
| 機能 | 説明 |
|---|---|
| 属性による分類・集計 | コンポーネントやステータスなどの属性ごとにチケットを分類して表示する |
| 担当者への割り振り | チケットを開発メンバーに割り振って担当者を明確にする |
| Subversionとの連携 | チケットに対応するSubversionのチェンジセットを容易に把握できる |
バグ管理にTracチケットを使うことで，面倒なバグ管理票を楽に作成・管理できるようになり，以下のようなメリットが生まれます。
- バグに関する議論がそのままチケットに記録として残る。
- ワークフロー機能によって，バグのステータス（新規・着手済み・完了）をリアルタイムに管理でき，担当者も明確になる。
- チケットとSubversionのチェンジセットを連携することで，バグ管理簿からソースコードの修正個所をすぐに確認できる。
ポイントは情報を分散させずに1個所で管理することです。TracはSubversionとの連携機能が充実しているので，従来は別々に管理されていたバグ管理簿とソースコードを統一的に管理することができます。Tracのチケットとしてバグを登録し，そのチケットを担当者に割り振り，対処状況をチケットに残していくことで，日常作業の中で自然にバグ管理簿を残していけるようになるでしょう。
