バグを弔う技術
製品寿命が伸びてくると登録されたバグの数がどんどん増え手に負えなくなる。
対策として、まずはバグの優先度の解釈が厳密化される。たとえば P3 は「いつかやるかもしれないバグ・新機能」みたいな扱いになる。バリエーションとして「いつかやるバグ」というマイルストーンをセットすることもある。GTD 信者には "someday maybe" といえば通じるだろうか。
症状が進行すると本当にいつかやりたいバグと単に放置されているものの区別がつかなくなる。この段階での対処は色々ある。
たとえば「いつかやるバグ」とは別に「冷凍保存したバグ」というマイルストーンが追加される。「もうやりません」という意思を明示するぶん、ある種のコミットがある。バグを登録した人や新機能を要求した人はその意思を受取り、文句をいったり諦めたりする。
より激しい対処として、一定期間なんのアクティティビティ（コメントなど）が観測されなかったバグを一律 "Obsolete" とマークして閉じる「バグ破産」というアプローチも見たことがある。これはほんとにひどい話だが、よく考えると「バグ破産」で閉じる行為自体がひどいというよりは、そこまで手に負えなくなってしまった事実が問題に思える。
ここまではチームや組織単位での対策。これらとは別に、自分は個人的にバグを弔うやりかたを一つもっている。それは「墓場バグ」をつくること。
どうにもならないが、度々報告される問題がある。自分の仕事だと「遅い」というやつ。わかってる。手も打ってる。良くする計画もある。でも完全には治らない。原因はまちまちだが、はっきりもしない。そういうバグのために自分は「遅いバグの墓場」というバグをつくっている。新しい遅さバグが報告されたら、ログを睨んで何らかの診断を下し、特に新しい情報がない場合（すなわち大半の場合）はその遅いバグを「墓場バグ」の重複報告としてマークする。「遅いバグの墓場」は、遅さの種類に応じて複数個用意してある。
診断をコメントし、ありがとう、がんばってるからよろね、と挨拶してバグを墓場バグに重複登録 (dedup, de-duplicate) する。バグを登録してくれた人も納得するし、バグも成仏するであろう。たぶんね。
「なんか画面の表示が乱れる（がちょっとつつくと直った）」というバグも度々うけとる。これも原因はよくわかっていない。アプリのレイヤではなく OS のバグであることはログから確かなのだが、では OS の何が壊れているのかはよくわからない。こうしたバグは、受け取られるたびに色々な人の間をたらいまわされ、各段階で各人が時間を無駄にする。不毛なので、自分のところに来たときに「いつものやつ」だとわかったら「描画乱れの墓場」に dedup する。
こうした墓場バグがあると、問題のカテゴリに名前がつくおかげですくなくとも「似たような問題前にも見たな・・・」みたいなことが減る。そして既存の類似バグに dedup するよりは後腐れなくていい。コメント欄も荒れにくいし。
これらの墓場バグ自体は、冷凍バグなりなんなりの「やるきはないが閉じないバグ」に所属している。明らかに suboptimal な所作だけれども、生きていくために目をそらしたい現実もある。あのバグたちにはせめて成仏してほしい。
なお遅さバグについては、直す気はあるという意気込みを込めて墓場ではなく動物園と名付けている。"Zoo of the slowness" みたいな。Graveyard だとしょんぼりしちゃうけど、Zoo はなんとなく楽しげでよい。今日も速くしてくぞ！