Tracのチケットは終了基準が大切
TracやRedmineを障害管理に使うことに慣れてくると、会議のアクションアイテムや各自の作業項目をチケットに入れて管理するようになってくる。いわゆるチケット駆動開発により、作業の見える化、効率化を進め、管理負荷の軽減を図るわけだ。何でもチケットに入れて整理しつつ片付けていくと、日々の業務がスムーズに進むようになるメリットは大きいと思う（ゲーム感覚と言う人もいたけど）。
このような形でチケットを使う時に大切なのは、チケットの終了（クローズ）基準だろう。障害管理ならソフトのバグを直してソースコードをコミットし、修正箇所が確認出来れば完了という極めて明確で普遍的なワークフローが存在するけれど、WBSの作業項目をチケットに放り込んで「概要仕様を検討する」なんて言う曖昧な項目を入れてしまうと、各自の認識が実は異なっていて開発途中にその違いが露呈して混乱することが珍しくない。
例えば、仕様を決めたら終わりと思っている人、仕様を決めて仕様書への反映まで行うべきだと思っている人、あるいは仕様の該当箇所を実装することまで含めて考えている人や、具体的成果物は次のチケットで作業すると思っている人もいるかも知れない。「検討する」レベルは各開発者で様々なのだ。
そんな失敗に懲りたので、チケットには必ず終了基準を決めておくようにした。例えば、こんな取り決めだ。
- 概要仕様を検討する
終了基準：検討結果を元に概要仕様書を完成させること。内容は既存の○×と同等レベルであること。 - 問題の取り扱いを検討する
終了基準：関係者を招集して打合せを行い、何もしないことに決まればそのまま終了。アクションが必要になればその項目を別チケットに起票すること。 - ○×を調査する
終了基準：調査結果を取りまとめて報告書を完成させ、打合せ時に報告すること。 - 仕様書を作成する
仕様書を作成してレビューを行い、照査・承認を受けること。 - ○×を作成する
終了基準：該当する仕様書を更新し、ソースコードを作成した後、コードレビューを経てコミットすること。
要するに具体的な成果物、または明確な意志決定がなされれば良いわけだ。実は、この程度のことは組織の中では業務手順のような形で決まっていたりすることが多く、上記のような終了基準は、言ってみればその手順の中での該当範囲（開始：チケット起票、クローズ：終了基準）を決めるようなものだと考えれば分かりやすいと思う。
また、「仕様書を完成させる」等の具体的な成果物の形は、ある程度分類が可能なので、チケットの「終了パターン」を予め幾つか定めておき、各チケットにはその該当する「終了パターン」番号を明記するような形にしておくと手間は削減出来る。チケット駆動開発の導入により、現場がかえって混乱しては意味が無い。作業内容を出来るだけ定型化して、誰でも同じレベルで理解して取り組める仕組み作りが大切だと考えている。
関連
