[の] のまのしわざ

毎日毎日バグトラッキングシステムでのやりとりで一日を過ごしています。転職して驚かされたのはこの業界、まだまだバグトラッキングの基礎が認知されていないこと。プロセスエンジニアリングも同様にまだまだで、原始的なやり方が故にデスマーチ（ビューティフルドリーマー）を繰り広げてます。

Joel on Software - やさしいバグトラッキング

良いバグレポートのルールを覚えるのは簡単だ。すべての良いバグレポートに必要なものは正確に3つだ。

1. 再現する手順、
2. 期待されること、そして
3. その代わりに観察されたこと。

ということで基礎に立ち返って。まずこの３点が最も重要です。こんなに簡素な言葉で言い表せるんだから、英語って凄い（原文が）。

6. あなたがプログラマで、テスタにバグデータベースを使ってもえらずに困っているのなら、他の手段によるバグレポートの受け取りを拒めばよい。テスタがバグレポートをemailで送ってよこすなら、「emailを整理しきれないのでバグデータベースのほうに入れてください」という簡単なメッセージとともに送り返せばよい。

これもナイス。毎日繰り広げられたバグ報告と機能確認のやりとりのメールがDB化されることで追跡と検索が容易になります。

ただ問題はDBに入るために「忘れる」というワザが使えなくなる点。closeされないチケット（バグを登録したもの）は永遠に残ってしまいます。そういうのを避けるためにある時点、たいていは出荷時（公開時）に won't fixとして FAQや制限事項で対応してしまうこと。すでに再現手順が分かっているバグはバグではない、仕様（制限事項）だと言い切るわけです。

バグのないソフトウェアは存在しません。品質が良いソフトウェアを目指して日々チケットと格闘してます。

バグトラッキングシステム：
- trac
- bugzilla
- FogBUGZ

Ben(Ben Trott, Co-founder and CTO, Six Apart)がなぜかFogBUGZのページでオススメしてる(^^; 最新版、日本語が通らないという噂があるんですけど・・・

なお、このエントリーは家族、特に息子のために書いてます。毎日ねんねしに会社に行っているわけではないんだよ＞息子