なぜTracの導入に失敗するのか？

Tracの導入現場の今

「第1回：なぜバグ管理システムを使うのか？」 でも紹介したように、TracはSubversionと連携するオープンソースのバグ管理システム（BTS：Bug Tracking System）だ。Ruby on Railsなど多くのオープンソースプロジェクトで利用されており、最近では商業開発でもっとも多く使われているツールの1つになっている。

その一方で、Tracの導入効果が出ていないケースも多々ある。それはなぜだろうか？

Tracの肝は「チケット管理」の運用にある！

Tracにはコンテンツを管理するシステムとしてのWiki、Subversionなどのバージョン管理システムのファイルをWebから閲覧す るための「リポジトリブラウザ」、バグ報告や作業などのチケットの作成・変更や閲覧を行うための「チケット管理」の機能が標準で提供されている。

これらのTrac機能の中でもっとも重要なものは「チケット管理」である。このチケット管理を使いこなせるか、つまり運用方法がTrac導入の効果に非常に深く関係している。実際にTracの導入に失敗した理由の多くはココにあるのだ。

そこで本連載の第2回では奥深いチケット管理について解説し、導入の際に注意すべき点とその対応策を紹介する。

チケットとは

チケットとはプロジェクトのタスク、機能追加の要望、バグ報告、ソフトウェアサポートのQAなど、独立した1つの作業単位をあらわしたものである。Tracのチケットには、

という属性（内容）が記載されている。作業をチケットという単位で細切りにし、それをチケット管理システムというデータベースで管理することで、さまざまなメリットが生まれる。

Tracのメリット

まずは「作業の見える化」だ。作業はチケットという形で明文化されているため、作業状態を誰でも把握することができる。次に、「作業の分散化」 があげられる。作業を人ではなくチケットに振るため、担当者が不在や対応不可能な状況でも、知識を持った他の人がいれば作業を行いやすい。またチケットに コミュニケーションの履歴も残るため、チケットの途中で引き継ぎも行いやすくなる。

最後に「作業履歴の保持」だ。チケットはすべて保存されているので、自動的に明文化された作業履歴が残っていく。また検索も可能で、過去の対応なども容易に調べることができる。

では、Tracにはデメリットはないのだろうか？

Tracのデメリット

Tracも万能ではないためデメリットはある。まず、チケットは口頭やメールに比べて書くことに「時間がかかる」という点だ。しかしこれはメリットに比べて低いデメリットであるといえよう。

次に、Tracのチケットには作業時間や工数を管理する仕組みがないため、「工数管理は別の方法で行う必要がある」点があげられる。しかし、現在はプラグインの導入で対応が可能なため、これも大きなデメリットではない。

こうしてみると、Tracにはさほど大きなデメリットがないといえる。次にチケット管理の流れを解説していこう。