たぶん愚痴。
２〜３ヶ月前にちょっとしたリリースがあって、その前後でバグが発覚し、いろいろとごたごたしていた。いや〜な時間に電話がかかってきたり、いや〜な時間に出社したりと、よくあるトラブルに見舞われていたが、今は（一見）普通に動いているので平穏に過ごしている。良かった良かった…
それはさておき、リリースのたびによく思う、「果たしてバグをゼロにできるんだろうか？」と。答えはもちろんNoだ。そんなことはできるわけがない。
でも、クライアントはバグがないことを暗黙のうちに要求しているし、プロジェクトでもバグゼロを要求している。（明言はしないけど、彼らが言っている「高品質」とはイコール「バグゼロ」のように思える。だって明確な基準がないし）
「バグが出てもしょうがない」という姿勢だと実際に出ると考えているので*1、仕事として「バグゼロ」を目標にすることや、出たバグに対して危機感を持つのは良いことだと思う。
が、あんまり厳格だとそのうちミニクジラを探す羽目になる。追加テスト、強化テストの雨あられでバグが存在しないこと証明することになる。
大量のテストを駆動するのはリスクだが、定量化できないリスクの量は無限大になる。（だからこの言葉は嫌いだ）駆け引きやら精神状態やらその日の天気やらでテストの量が決まり、「ま、ま、こんなところで…」でテストが完了する。
サーバ機のお祓いをしないのはなぜなんだろう？幽霊に取り付かれて不具合の原因になるかもしれないのに。それは、リスクの発生に対してかかるコストが見合わないからだろう。大量のテストとお祓いの間にはコストの直線があって、誰かがどっかで線引きをしているらしい。
ストレスとか健康とか精神状態とかを支払っているけど、そのコストは見合っているんだろうか？見合っているんだろうな…たぶん。
バグが発生しても建設的に作業をしたいと思って「バグを制御する」という言葉を思いついたけど、やり方はさっぱりわからない。僕はそろそろ負債を支払えなくなりそうだ。
*1:他の事例だと締め切りを延ばすと作業時間も延びていく、とか
