そのバグが本当にバグなのかを見極める

設計

今の会社では、カスタマーサポートなど非エンジニアもイシューを上げられるようにしているが、彼らがバグとしてあげてきたイシューには、実は対応が不要なものも多く混じっている。
何から対応するか決めるときには、「バグ」と「仕様の問題」を混同しないように気をつけた方がいい。

  • バグ: 仕様として想定されているのとは異なる動作をするということ。
  • 仕様の問題: 動作自体は仕様の通り。ただしそれが特定のユーザにとって望ましくない可能性がある。

この2つは、その後の意思決定が大きく異なる。バグならもちろんすぐ潰すべきだ。
しかし仕様の問題なら、直そうとすると仕様変更になる。その変更が本当に全てのユーザにとって望ましい変更であるか、その問題はどれほど頻繁に発生しどれほど影響が大きいかなどを考えたうえで、対応するか見送るかを決めなければならない。

また、ごく特別な状況でしか起こらないという場合もありうる。
例えば、特定のブラウザでのみ発生する、特定の時刻でたまたま処理が重くなっていたためにエラーが起きる、などのようなことが実際にあった。このような場合、やはり即時対応はできない。
バグが上がってきた場合、まずはそれが本当にバグとして扱ってよいものかを立ち止まって考える必要があるだろう。