プログラム作成者が行った作業のミス。
見つかった時点でバグと言う。バグを見つけるのも、バグを取るのも大変だが失敗を生かすのがもっと大変だと言われる。
元々の意味は、虫による不可抗力的エラーの意味。
真空管を部品に使っていた頃、コンピュータ内部に蛾のような昆虫が入り込み回線に触れてショートを起こすような事態があった。それによって発生したエラーのみを本来はバグと呼んでいた。プログラマーのプログラミングミスはそのまま人為的ミスとして障害報告しなければならなかった。
しかし、あまりにもプログラミングミスが多い場合、査定にも関係するので、障害報告の際にはバグに責任転嫁する慣習が生まれた。これは技術的なことは何も知らない上層部には通用したが、同じプログラマー間では、バグ=プログラマーの人為的ミスと言う隠語的定義が成り立っていった。
余談でも触れているが、エドガー・ダイクストラは「バグと呼ぶなミスと呼べ」と言っている。これは、プログラムのミスは明らかに人為的なものであるにも関わらず、バグと呼んだ場合あたかもそれが自然発生したような印象を与えるからであり、プログラマーの職業意識を高める役には立たないからである。
あるプログラムのバグの含有量は、プログラムの長さに比例する。
バグの含有量を下げるには、プログラムを短くすればいいことになる。
すなわち、よいプログラムとは短いプログラムのことである*1。
プログラマーは短く簡潔にプログラムを記述せよ。
人間は失敗をする物だ。しかし、その失敗をバグという言葉で、あって当然と思ってしまったら進歩は無くなる。回路設計者が作るハードウェアの試作製造が高価だった頃は最悪失敗作を作りましたと言っていた。
いつのまにやら、ハードウェアの試作が再プログラミングできるASICになると、ハードウェアエンジニアさえもバグと言うようになった。利用者がバグというのは良いとしても、技術者がバグという言葉を使っちゃいけないと思う。間違い、ミス、考慮不足、予防策不足、フロー設計ミス、エラー処理設計ミス、要求定義ミス・・・そういう風に正しく理解しなくては失敗を生かす為に必要だと思われるがいかがだろう。
デバッグは対策ではない。デバッグは対処です。そしてまた、バグのある製品がユーザーの手に・・
ウィルス、仕様、セキリティホール、脆弱性、不具合
デバッグ、テストファースト、XP、仕様書、要求定義、事故調査、原因解明、ミス、ブラックボックス、プログラミング
*1:出てくる結果が同じである限りは