チケット管理の流れ

今回はバグの報告を例にチケットの流れをみていこう。

例えば、あるプロジェクトで、カタカナの文字が化けるというバグを発見したとする。その時にそのバグをTracのチケットを使って報告する。

その場合、タイトルに「カタカナの文字化け」、分類は不具合をあらわす「defect」、バグの詳しい再現方法などを書く。バグを直す担当者が決まっている場合には、担当者の欄も入力する。そして、そのチケットを登録する。これでバグの報告が完了となる。

登録されたチケットは、画面上部の「チケットを見る」で確認することが可能だ。「チケットを見る」では登録したチケットの属性に合わせて、情報を取り出すことができる。

今登録したばかりの「カタカナの文字化け」チケットは、まだ解決していないので「{1} 未解決チケット」でみることができる。このチケットのページを開くとチケット画面が表示される。

この画面では、チケットに関するコメントを書いたり、属性変更を行うことが可能だ。コメントを書くとチケット画面の「チケットの履歴」の中に追加される。これに対して担当のプログラマがコメントすることもできる。

担当者は画面下部の「操作」を「newのまま更新しない」から「チケットに着手する」へ変更し作業に入る。以後チケット画面を見ると現在のチケットの担当者が表示される。

担当者はチケットに関する作業が終わった場合、画面下部の「操作」を「解決にする」にし、更新すると作業完了となる。

全体の把握

「チケットを見る」画面の中に「{4} 担当者別アサイン済みチケット」という項目がある。これは現在着手されているチケットの一覧を表示することができ、全体を把握する場合に利用する。

メーリングリストなどで対応していると、「現在着手済みの作業が何で、どれが終わっていないのか」という管理が難しく、作業の取りこぼしが起こりやすくなってしまう。しかし、このチケット管理を使うことで、常にすべての情報を把握していなくても、リストをみるだけでプロジェクトの現状が掴めるようになる。

また、これらのチケットの履歴はRSSやメールでの配信も行うことができる。特に複数のプロジェクトを抱えており、毎日プロジェクトのTracを見ない場合でも、情報共有が行えるようになっているのだ。

このように、チケット管理と言うのは非常に簡単な仕組みである。バグや作業の内容を書いて登録し、その上でコミュニケーションを含めて完結させることで、情報の分散を防ぎ、一覧性を確保することが可能だ。

しかし、実際にこれを運用してみると思ったほどうまく行かないのである。その理由はどこにあるのだろうか？ 次のページ