「バグ」という言葉を聞くと、ネガティブな気持ちになるプログラマーは少なくありません。
多くの人にとって、バグ報告は「自分のミスへの指摘」のように感じられ、決して気持ちの良いものではないでしょう。
その結果、バグ報告を躊躇したり、見なかったことにしてしまう心理が働くことも理解できます。

しかし、1人のテストエンジニアとして一貫して思うのは、バグは誰かの「罪」ではなく、単なる「事実（期待結果との差異）」です。
この事実と正しく向き合うための技術こそが「バグ管理」だと考えています。
そして、それを運用するのは感情を持った人間です。

本セッションでは、バグ管理を「(意図的でないにせよ)開発者を責める場」から「チームが前進する場」へと変革した実践事例をお話しします。

バグ管理の本質は「事実」の管理

バグとは「現実で起こっている問題」であり、リスク管理の対象として適切に管理すべき対象です。
バグを全て修正するのではなく、限られたリソースの中で建設的に対処することが必要です。

「バグ」ではなく「チャンス」と呼ぶ

「期待と違う挙動」は、実はプロダクトを良くする機会であることに気づきました。
呼び方を変えるだけで、バグ起票や対処のハードルが下がった事例を紹介します。

重大度を「妖怪」で定義する

重大度という、そのバグが持つ悪い結果を予知するステータスがあります。
これは一般的に「Critical/Major」などの言葉がありますが、私がいたチームでは「座敷童（軽微）」「鬼（重大）」「八岐大蛇（致命的）」と定義しました。
これにより「今週は鬼を退治しよう！」とチームの会話がポジティブに変わりました。

バグ管理は重要です。一方で、嫌な気持ちを放置するのも違います。
バグ管理をハックして、毎日の開発を楽しくしませんか？