チケットの使い分け

クローズできないチケットの続き。チケットをクローズ出来ないとマイルストーンもクローズ出来ないので、この状態が続く限りソフトウェアのリリースが不可能になってしまう。「事情があって未解決のチケットは残るけど、開発作業は全て終了しました」と言うようでは、一体何のためのチケット管理なのか分からなくなってしまう。赤色のバーが残っているJUnitのテスト結果を「問題は完全に解決出来ていませんが、これでOKです」と言うようなものだろう。チケット駆動開発を進める以上、全てのチケットを漏れなくクローズした状態で開発作業を終えたいものだ。

では、どうすべきか？発端となった障害チケットの事後対策が済み、プロジェクト内で直ぐに対策が完了出来るものは、作業が済み次第クローズするようにしている。例えば、再発防止策や、ある程度の事前予防策なら短期間で作業が済むはずだ。

• チェックリストへの項目追加
• 単体テストコードの追加
• テストケースの見直し
• 関連機能の再レビュー
• 仕様書の修正、追記

その一方で、対策には時間や手間、部門の調整が必要になるものもある。例えば、こんな作業だ。

• 作業手順、基準の変更（規約の改定や承認が必要な場合）
• 未然予防策の検討、実施確認（次回の開発時）
• 障害の抜本対策（障害自体は暫定対応）
• 開発プロセスの見直し
• 障害情報や関連知識の横展開

こんな内容については別途チケットを発行して、別のマイルストーンで管理するようにしている。これなら障害対応を素早く行ってチケットをクローズすると共に、少々時間がかかっても抜本対策まで確実にフォロー出来る。当然、相互のチケット間にリンクを貼っておき、トレーサビリティを確保しておく必要があるのは言うまでもない。

但し、これらのチケットは「作業を忘れないようにするためのもの」であって、決して「後回しにして良いもの」ではないことに注意が必要だ。複数の開発プロジェクトが同時に走っているような組織だと、各プロジェクトで類似の障害が相次いで発生する事は珍しくない。開発作業中に本流以外の作業に時間を取られるのは痛いかも知れないが、障害の発生を抑え込むためにも、対策は迅速に取るべきものだと思う。