バグ管理の行うにあたって

12月の特集「バグ管理の作法」の火曜日は「バグ管理のノウハウ」と題して、バグ管理の基本を解説していく。第1回では、バグについての基本事項を押さえていき、第2回以降では運用におけるポイントや管理方法について紹介していく。

バグとは

読者の皆さんもご存じのとおり、バグ（bug）とはソフトウェアに不具合や誤作動を起こすコーディング上のミスや欠陥のことである。世界最初に記録されたバグは、1945年にプログラム内蔵式の計算機である「マークII」に蛾がはさまったことで、計算機が止まったことに由来する。当時、グレース・マレー・ホッパー氏が業務日誌に蛾を貼り付け、「実際に最初に見つかったバグの例」と記している。元々は機械の故障だったが、これが広まり、今日のバグの意味に至る。

また、バグは法的な文書において「瑕疵（かし）」と表現される。瑕疵（かし）とは、欠陥とほぼ同じ意味で、品質や性能が欠如している状態でのことである。

バグはなくならない？

バグのないソフトウェアがもっともよいことは確かだが、近年ではソースコードの分量の多さも手伝って、バグのないソフトウェアはないとえるのが現状である。

もう1つバグの特徴として、「発生しないバグはわからない」というものがある。実際に求められた動作を正常に行っているソフトウェアにバグがあるかどうかを判断することは難しい。どのようなソフトウェア開発でもそうだが、開発段階においてはバグが発生しないようなコーディング手法を用いているだろう。また、かならずソフトウェアの検証を行い、デバッグ（バグを取る作業）を行っているはずだ。しかし、開発者の意図しない動作や、想定外の動作が起きた時にバグは発生する。

ただし、バグのないソフトウェアを作ることは実際に不可能ではない。しかし、現実問題としてソフトウェア開発には期限とコストが存在する。これが、さまざまなバグを発生させるもっとも大きな要因ともいえよう。

バグはなくすのは難しいことは確かだが、バグによる損失は大きく、これまでもさまざまな事件になっている。身近な例をいくつか紹介しよう。 次のページ