たとえるなら
楽譜の写し間違いのようなものです。作曲家の頭の中では正しい曲でも、楽譜に一音写し間違えれば、オーケストラは間違った音をそのまま演奏してしまいます。コンピューターも、書かれた指示のとおりに忠実に「間違って」動くのです。
もう少しくわしく
バグ（bug）は英語で「虫」の意味で、プログラムに入り込んだ誤りや、それによる不具合を指します。昔、コンピューターの中に本物の蛾（が）が入り込んで故障を起こした、という有名な逸話が語源のひとつとして知られています。「ボタンを押しても反応しない」「合計金額の計算が合わない」「特定の操作をすると画面が固まる」——こうした症状はみなバグと呼ばれます。
大事なのは、コンピューターは壊れているのではなく、書かれた指示のとおりに忠実に動いているということです。人間が書いた指示のどこかに考え漏れや書き間違いがあると、それがそのまま不具合として現れます。ソースコードは膨大で、利用者の操作パターンは無数にあるため、どんなに優秀なチームでもバグをゼロにすることはできません。
バグが生まれる場所は、単純な打ち間違いばかりではありません。むしろ多いのは「そうなるとは思っていなかった」という考え漏れです。氏名欄に記号を入れる人がいる、送信ボタンを2回続けて押す人がいる、月末の日付だけ計算が合わない、他の機能を直したら関係ないはずの画面が壊れた——こうした「想定していなかった組み合わせ」から不具合は生まれます。
見つけ方は主に3つあります。作った本人以外が指示書（ソースコード）を読み合うコードレビュー、決めた手順で動かして仕様どおりか確かめるテスト、そして公開後に利用者から届く報告です。前の段階で見つかるほど直す手間は小さく、公開後に見つかるほど影響も手間も大きくなります。だから現場は、早い段階で見つけることに力を注ぎます。
直すときは、いきなりソースコードをいじりません。まず同じ症状をもう一度起こせるか（再現）を確かめ、次に原因の箇所を突き止め、直したうえで、本当に直ったかと他を壊していないかを確認します。この一連の流れをデバッグと呼びます。再現できないバグは原因の特定が難しく、報告時に「どの画面で・何をしたら・どうなったか」が書かれているとありがたがられるのは、このためです。
見つかったバグをすべて同時に直すことはできないため、現場では優先度をつけます。判断の軸は「困っている人の多さ」と「困りかたの深刻さ」です。お金の計算が合わない、ログインできないといったものは最優先。見た目が少しずれている程度なら、次の機会にまとめて直す、という具合です。
だからこそ現場では、バグを「あってはならない失敗」ではなく「見つけて直していく前提のもの」として扱います。テストで早めに見つける、報告の仕組みを整える、直した記録を残す。バグとの上手な付き合い方そのものが、開発チームの実力と言えます。
現場での使われ方
「本番でバグが見つかったので、急ぎ調査します」
利用者が実際に使っている環境で不具合が発覚した、という報告。影響の大きさによっては最優先の対応になります。
「それ、バグじゃなくて仕様です」
不具合に見えるかもしれないが、意図してそう作っている、という現場の定番フレーズです。
「再現手順を教えてもらえますか？」
同じ症状を手元でも起こせないと原因を追えないため、どう操作したらそうなったかを尋ねています。責めているわけではありません。
「このバグの優先度は低めで、次のリリースに回しましょう」
影響が小さいので、今すぐではなく次の機会にまとめて直す、という判断です。すべてを同時に直すことはできません。
よくある質問
バグと仕様の違いは何ですか？
「どう動くべきか」の取り決め（仕様）どおりに動いていないものがバグ、取り決めどおりに動いているものは（不便でも）仕様です。ただし「仕様自体が良くなかった」というケースもあり、その場合は仕様の見直しが議論されます。
バグのないソフトウェアは作れますか？
現実的にはほぼ不可能とされています。そのため、テストで事前に減らす工夫と、見つかったときに素早く直せる体制の両方を整えるのが現場の考え方です。
バグとエラーは同じ意味ですか？
少し違います。エラーは画面やログに出る「異常が起きたという知らせ」で、バグはその裏にある原因のほうを指します。エラーが出ずに、静かに間違った金額を表示し続けるバグもあります。むしろエラーが出てくれるほうが、気づけるぶん親切です。
デグレとは何ですか？
今まで動いていた部分が、別の修正をきっかけに動かなくなってしまうことです。「先祖返り」とも呼ばれます。直したはずの場所が元に戻ってしまうこともあり、これを防ぐために、変更のたびに広い範囲を確認するテストを行います。
バグを見つけたら、どう報告すればいいですか？
「いつ・どの画面で・何をしたら・どうなったか、本来どうなるはずだったか」を書くと、調査がとても速くなります。エラー画面のスクリーンショットがあれば添えます。原因の推測は無理に書かなくて構いません。事実をそのまま伝えるのが最も役に立ちます。
