単純だが難しいチケット運用

チケットのそのものの運用に際して主に問題になるのは、

チケットの属性: 「優先度」と「マイルストーン」の設定をどうするのか？
チケットの規模: チケットに書き込む内容はどのようなものが適切か？
チケットを閉じる時: チケットを閉じる作業をどう処理していくのか？

チケット運用時のポイント

の3つだ。これが、Tracを導入したのに効果が出なかった理由である。実際にはこれらに加えて「チケットの運用」と「組織の運用」の齟齬が問題になるケースも多い。これについては次回取り上げる。

ではそれぞれについて解説していこう。

チケットの属性「優先度」と「マイルストーン」

Tracのチケットには複数の属性がある。その中でもわかりにくいのは「優先度」と「マイルストーン」だ。

優先度は初期値で「blocker」「critical」「major」「minor」「trivial」となっている。英語だといまいちピンとこないのでこれは「今すぐやる」「明日までにやる」「普通」「あとでやる」「たぶんやらない」というように、どれぐらいの時間でやるかを具体的に書き換えた方がよい。

もう1つ「マイルストーン」はプロジェクトのマイルストーンよりも短い期間で区切るとよい。定期的な報告会がある場合は、その単位で「2007/12/24 ○○報告会」のようなマイルストーンを作成し、その日までに仕上げなければ行けないタスクをチケットで割り振るようにする。

チケットの規模

まず、例としてユーザ編集画面をAjax化するという作業が発生した場合を考える。

この時にそのまま「ユーザ編集画面のAjax化」というチケットを作成してしまうと問題が発生する。まず、そのチケットに付随する作業が膨大になり、チケットのコメント欄があふれてしまう。また、外部から見たときに、この作業がどこまで進んでいるのかを把握しにくくなるのだ。これはチケット管理のメリットである作業の一覧性が大きく失われてしまい、逆にデメリットになってしまう。

対策として大きな作業のチケットは、小さく分けて登録するとよい。しかしあまり細かくしすぎると、チケットに関する工数が増え、一覧性が悪くなってしまうので注意が必要だ。

目安は、チケット1つに対して1人が3〜4日で終わる範囲で切るとちょうどよい。これ以上かかる規模のチケットであれば、それを複数に分ける。また1つのチケットには1〜2名のみが関わるようにする。これは1枚のチケットにあまり大人数が割り当てられると作業の把握がしにくくなるためだ。

チケットを閉じる時

Tracでは誰でもチケットを解決にして閉じることができる。しかも、閉じたことが他のユーザにわかりにくい。そのため各個人が勝手にチケットを解決にしてしまうと、チケットを見失いやすくなるのである。

筆者が関わったプロジェクトでは、チケットを解決にするのはかならずプロジェクトマネージャーだけに限定して運用している。つまり、作業が終わるとチケットの担当者をプロジェクトマネージャーに変更するのだ。これにより、すべてのチケットは必ずプロジェクトマネージャーを通るため、品質の保持をはかることが可能となる。

これらの点を踏まえてTracの導入を行っていただきたい。その結果、チケットを大いに活用することができ、プロジェクト内の情報を一意的に扱え、見通しが非常によくなるだろう。