たとえるなら
楽譜の写し間違いのようなものです。作曲家の頭の中では正しい曲でも、楽譜に一音写し間違えれば、オーケストラは間違った音をそのまま演奏してしまいます。コンピューターも、書かれた指示のとおりに忠実に「間違って」動くのです。
もう少しくわしく
バグ（bug）は英語で「虫」の意味で、プログラムに入り込んだ誤りや、それによる不具合を指します。昔、コンピューターの中に本物の蛾（が）が入り込んで故障を起こした、という有名な逸話が語源のひとつとして知られています。「ボタンを押しても反応しない」「合計金額の計算が合わない」「特定の操作をすると画面が固まる」——こうした症状はみなバグと呼ばれます。
大事なのは、コンピューターは壊れているのではなく、書かれた指示のとおりに忠実に動いているということです。人間が書いた指示のどこかに考え漏れや書き間違いがあると、それがそのまま不具合として現れます。ソースコードは膨大で、利用者の操作パターンは無数にあるため、どんなに優秀なチームでもバグをゼロにすることはできません。
だからこそ現場では、バグを「あってはならない失敗」ではなく「見つけて直していく前提のもの」として扱います。テストで早めに見つける、報告の仕組みを整える、直した記録を残す。バグとの上手な付き合い方そのものが、開発チームの実力と言えます。
現場での使われ方
「本番でバグが見つかったので、急ぎ調査します」
利用者が実際に使っている環境で不具合が発覚した、という報告。影響の大きさによっては最優先の対応になります。
「それ、バグじゃなくて仕様です」
不具合に見えるかもしれないが、意図してそう作っている、という現場の定番フレーズです。
よくある質問
バグと仕様の違いは何ですか？
「どう動くべきか」の取り決め（仕様）どおりに動いていないものがバグ、取り決めどおりに動いているものは（不便でも）仕様です。ただし「仕様自体が良くなかった」というケースもあり、その場合は仕様の見直しが議論されます。
バグのないソフトウェアは作れますか？
現実的にはほぼ不可能とされています。そのため、テストで事前に減らす工夫と、見つかったときに素早く直せる体制の両方を整えるのが現場の考え方です。