Trac や Redmine のような ITS も一般的な業務アプリケーションと捉えると、開発という業務にマッチした入力画面を定義し、ユーザーである開発者にデータをエントリーしてもらうものです。例えば販売システムの受注データに相当するのが チケットと考えればいいでしょう。
チケットのクエリーで作られる各種レポートは、開発業務の状況を把握し意思決定に用いるための帳票です。正確なレポートを得るためには、入力項目を開発者が使いやすいように設定して精度の高い情報を登録してもらうことが重要です。
どのような入力項目が相応しいかは、開発チームの志向性やプロジェクトの状況によってかなり異なるというのが実際のところです。同じ業種の業務アプリケーションでも企業によって入力画面の仕様が異なるのと同じです。また、チケットの状態遷移は、開発の業務フローを反映しています。これもまたチームやプロジェクト事情で決まります。
さて、Trac はもともと(紙やスプレッドシートで Issue 管理するような)古びたやり方で開発をしているチームに最低限の支援をするという目的の元に開発されました。素の状態でも開発にまつわる問題の追跡には十分役立つだろうという入力項目とチケットフローが備わっています。逆に言うと、Trac で標準的に提供されているレベルの管理を実施していないプロジェクトは危険な道を突き進んでいると言えるでしょう。
ITS を導入する前に、その設計思想や想定している開発フローなどと現状を比較して見るのがよいでしょう。業務パッケージを導入する際、自社の業務との Fit/Gap を分析して評価するのと同じですね。自チームのやり方(自社業務のやり方) をパッケージに合わせるのか、パッケージをカスタマイズするのか。 導入までにユーザー検証を経て、既存のやり方を調整して・・・と真面目に考えるとかなり手間暇です(まあ、ITS は所詮ツールなのでそこまで大変じゃないですが)。
だからチケットにあれもこれも入れようとしてカスタムフィールドを追加しまくったり、Issue 解決までに多段階の承認ステータスを作ったりして頑張ろうとすると残念な感じになることが多いです。エントリーする開発者の負担ばかりかかってタイムリーに情報が登録されなくなり、プロジェクトの状況把握を行えなくなって行きます。
人間は自覚しているより遙かに怠惰な生き物です。シンプルこそが継続性の源泉です。そして継続性はプロジェクト成功の必要条件です。
Trac 標準の項目だって思い切って捨ててしまってもよい場合があります。優先度の調整とかイテレーション開始時の計画でやってしまえば、チケットの優先度がわりとどうでもよくなったりします。不要なフィールドであればデータを消してしまいましょう。Trac では優先度でもコンポーネントでも、データの入っていない項目は表示されなくなります。用途不明のフィールドなどノイズでしかありません。分かりやすさを第一義にしましょう。
シンプルさを保つには用途に応じて Trac プロジェクトを変えるようにするのがよいでしょう。多目的な用途には Trac はシンプルすぎます。Trac プロジェクトを跨るチケットは InterTrac リンク機能で関連付けることが可能です。機能追加・仕様変更管理用やバグ管理用などプロジェクト局面に応じて適宜追加して行くと良いでしょう。
