Tracを使い始めて2年近くなりますが、バグトラックとしての使い道以外に、タスク管理の観点からTracの利用を推奨する記事もちらほら見かけたります。
実際に利用していると、タスク管理で使った方が便利であることも多かったりします。
または、ナレッジ管理のような側面で使うのもありかなとか。
保守・運用の中で使うTrac
開発の現場においては、構築する機能やモジュール単位、テストフェーズでのバグの報告とその対応などに使われたりもしますが、開発後の保守・運用のフェーズに入ると業務の内容ががらっと変わるために、そういう使い方もあまりしなくなります。
構築というよりは、機能の改善や運用の中で見つかった不具合への対応などが中心になってきますので、必然的にその要望や対応時のタスクの管理というものが色濃くなったりします。
後述しますが、保守・運用の中で業務の役割も違ってくるので、チケットの粒度もまた違ってくることにもなったりします。
開発メンバーであれば、システムの詳細な仕様について書いてくる人もいれば、ヘルプデスクチームからはユーザーからの要望や問い合わせなどがチケットにあがることもあるでしょう。
で、そのタスク管理の側面を延長していくと、今度はナレッジ管理の観点が生まれてきたりします。
一つのチケットとタスクがイコールになると、そのタスクを完了したプロセスがその中に含まれてきますので、その後に似たようなタスクが発生したときに参照することで業務の効率化ができたり。
保守・運用フェーズに入ってくると、そういう似たようなタスクというものが繰り返し出てくることがありますからね。
マスタとなる詳細な手順を書いたチケットをそこにリンクしておけば、他の要員でも対応がやりやすくなったりもするわけです。
チケットの粒度がそれぞればらばらになってくるということを気にする人もいたりしますが、あまりそこは気にしなくても良いような気がします。
先に書いたことをまとめると、Tracの役割は大きく2つあると思ってて、
1. 対応ステータスと対応者を明確にする（タスク管理）
2. 対応時のプロセスを後で参照可能にする（ナレッジ管理）
というところにあるので、それが管理できていれば問題ないのではないのかなと。
それぞれのタスクやナレッジ管理の観点でチケットの粒度がそろわないこともあるでしょう。
バグのトラックでも、改善の要望でも、ユーザーからの問い合わせでも、最終的にはそれを何らかの対応を決定しなくてはならないわけで（対応しないという決定も含めて）、あまり細かく管理するとタスクの管理が煩雑になり、ざっくり管理しすぎるとプロセスが見えにくくなったり、細かなタスクを見落とす危険性もあったりしてきます。
チケットは関連性を持たせやすいので、担当チームで分解して対応するというのも良いでしょうしね。
どういう単位でプロジェクトやマイルストンを分けるかは結構重要
チケットの粒度以上に気を使うのが、マイルストンの扱いだったりします。
開発から保守・運用のフェーズまで、システムのライフサイクルで業務を行うのであれば、1つのプロジェクトの中でマイルストンを切ってやっていくことができます。
マイルストンのきり方は何も、開発・保守・運用などの区切りでなくとも、開発のフェーズで分けたり、ウォータフォール的に「要件定義」や「設計」などの分け方でも良いかと思います。
ただ、保守・運用になってくるとそういうマイルストンの区切りが付けにくくなったりします。
保守・運用という業務は、そのシステムのライフサイクルが終焉を迎えるまで永続的に続くものですからね。
なので、どちらかというと業務的な観点でマイルストンをきっていった方が良いかなと感じたりしています。
機能改善対応や監視業務の中で発見した不具合や報告、ヘルプデスクによるユーザー側からの問い合わせなど、各々の業務やチームで切ってタスクをそれぞれに登録していくというようなやり方です。
こうすることで、それぞれの業務の中でどれだけのタスクが発生していて、進捗はどうなっているのかということが見やすくなったりします。
プロジェクトに関しては、システムの単位や、根本的にそのシステムの保守・運用業務とは異なるところで使いたいという場合に分けることがあります。
Aシステム用のプロジェクト、Bシステムのプロジェクトといった具合や、チームごとにタスク管理に課題管理などをしたいというような場合です。
ただ、Tracでプロジェクトを分けてしまうと、DBも分かれてしまうのでプロジェクトの横断的な情報の検索というものができなくなります。
タスク管理の観点では、AシステムのタスクとBシステムでのタスクは分かれるでしょうから、あまり問題にならない（似たようなタスクでも別々にチケットを作ってしまえばよい）ですが、ナレッジ管理の観点からは参照したい情報がばらばらになってしまうと、管理しづらくなることがあります。
あのタスク、過去にやったことあるけど、どのシステムでやったんだっけな・・・、みたいな。
また、課題管理もそのチーム内でクローズするようなことであればいいですが、他のチームと共有する必要があったり、その課題を昇華して保守・運用の業務と絡めたチケットに関連性を持たせようとすると、管理が面倒になるので、そのプロジェクトの中のマイルストンとして設定した方が良い場合もあると思います。
（こうすると逆に課題全体を管理しづらくなりますが）
まとめ
保守・運用の業務が多いことから、その観点から書いて見ましたが、開発するにしろTracを使う場合は、それを使う人がTracの存在を強く意識しておかなくてはならなくなります。
後でチケットをあげればいいやと、先にタスクに取り掛かるとそのステータスが見えなかったり、面倒になってプロセスが省略されたり、そもそも登録し忘れたり、ということになると意味を成さなくなってきます。
チケット駆動開発なんて言葉もありますけど、それは自分のやるタスクをわかりやすくするということだけでなく、他人に何をやっているのか示したり、後人のために対応方法を示しておこうという意識も必要になってくるんだなと思います。
関連記事
バグトラッキングシステム「Trac」インストール
Tracの使い方 - trac-adminの使い方、チケットの管理とロードマップの確認 -
Tracの使い方 - プロジェクトの追加・削除 -