クローズできないチケット

3月末が期限だったtracのマイルストーンをクローズする。「チケットキーパーという存在」として、未解決のチケットについてはマイルストーンの変更（要するに先送りだ）や、担当者にチケット更新の催促を行う。幾つかのチケットはクローズ出来たものの、中にはクローズを認められないものも有る。例えば、こんなチケットだ。

やるやる詐欺型
「次回はレビューを行います」「確実なチェックを実施します」なんて書かれているけれど、今までそんなことが実際に行われて成果を上げているなんて聞いたことがないし、そもそも次回の開発時には、こんな回答すら忘れられていることが多い。だから、作業手順書を改訂する、チェックリストに確認項目を追加する、実際にレビューを行うなど具体的なアクションが完了するまでチケットはクローズ出来ない。
フィードバック欠如型
障害の修正だけで作業が終わってしまい、再発予防策とか未然防止策が実施されていないものもクローズ不可。根本理由を見直していないのなら、次回もまた同じ問題が発生することが明らかではないか。障害の発生予防まで踏み込むためにも、起こった障害を起点として抜本的な対策を取っておく必要がある。
仕様書型
障害の内容や背景状況についてやたらと詳しく書かれていると思ったら、これが仕様書代わりとなっており、本来の仕様書には情報が記載されていないと判明。「不具合が見つかって初めて仕様が分かる」典型的なケースと言える。チケットを仕様書代わりに使うのは禁止。仕様書へのフィードバックを行うべきだ。（こんな指摘をすると「仕様を書いているのだから良いではないか？」と反論されるのだけど、それでは将来の派生開発時にチケットを全て参照して仕様を理解しろと言うのだろうか。ここの細かい背景はチケットを参照する形にしても、要点として仕様書にまとめておく必要はあるはずだ）
謝罪型
「気をつけます」「申し訳ありませんでした」というお詫びの文句が並んでいるけれど、意図的に問題を起こしているわけでもないし、開発者が謝る必要は無いはずだ。障害は障害として粛々と対応すれば良いだけの話であって、頭を下げれば良いというものではない。謝ることでバグが減るのなら永遠に謝り続けて欲しいものだが、残念ながらそんな必要は全くない。誠意を見せるのは大切とは言え、それ以上のことは不要だ。
意味不明型
日本語が並んでいるのは分かるけれど、何度読み返してもその意味が理解できない。理由を考えてみたら、チケットに記載されている文章の主語が無いし、しかも前半と後半で言っていることが矛盾しているように思える。これでは説明になっていないではないか。開発者は技術力を持つのが重要だけど、それと同じくらい日本語力を持つことも必要だ。「まずは日本語の作文から」練習したらどうか。

クローズ出来ないチケットはもちろんのこと、再オープンになったチケットも多数あり、マイルストーンの山を越えるのは大変なのだ。