TOPシステム開発> 【バグ管理の作法】Trac徹底活用!> 第2回:なぜTracの導入に失敗するのか? (1/3)

【バグ管理の作法】Trac徹底活用!

【バグ管理の作法】Trac徹底活用!

第2回:なぜTracの導入に失敗するのか?

著者:masuidrive

公開日:2007/12/13(木)

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にはさほど大きなデメリットがないといえる。次にチケット管理の流れを解説していこう。 次のページ




masuidrive
著者プロフィール
masuidrive
最近は風呂の人と呼ばれるが、別にいつも風呂で仕事なわけじゃない。喫茶店が好きでMacBook proを持って、あちこちのお店で仕事してる。でも良い喫茶店が見つからず、マクドが多いのが残念。
http://masuidrive.jp/


INDEX
第2回:なぜTracの導入に失敗するのか?
Tracの導入現場の今
  チケット管理の流れ
  単純だが難しいチケット運用