はじめに

システム開発においては、要件定義をきちんと行ない、基本設計＝システム設計、詳細設計を行なった上で、実装＝コーディングを行なった後に単体テストを行なうという流れになります。

その単体テストにおいて不具合が出た場合、不具合の原因を調べて修正する作業が必要になります。これを一般的にデバグと呼んでいます。

この記事ではデバグとは？デバグでの問題解決の仕方等について現場に即した解説をしたいと思います。

そもそもバグとは何？

”バグ”とは、その機能の不備を生むプログラム内の不具合を指す言葉です。また、不具合とは、プログラムが仕様書、設計書通りに動かないことです。

プログラムの中に（害）虫（英語でバグ）がいるというイメージからバグという言葉が使われるようになりました。

つまり、思った通りに動かないプログラムが有る場合、「バグがあってうまく動作しない」といった使い方をします。

ソフトウエアの実装においては、プログラム設計書をもとに、設計書通りに動くようコーディングしていきます。

しかし、コーディングする人も人間ですので、コーディング誤りというのは少なからず発生します。それがバグというわけです。

バグが発生するのはコーディングの時だけではない

前項で、バグは、ソフトウエアの実装＝コーディングのときに発生すると解説しましたが、実はソフトウエアの実装の時だけではありません。

要件定義、基本設計、詳細設計における不具合でも動作不具合は生じます。このようにソフトウエア実装の前段階での不具合もバグということになります。

デバグとは？

バグを取り除く作業のことです。英語ではde-bugと書きます。deという接頭語は”無くす”といった意味がありますので、まさに”バグを無くす”　”バグを取り除く”作業になります。

良くある勘違いが、テストのことをデバグという人がいます。私も新入社員時代組み込み開発に初めて関わったとき、テストをすることがデバグだ、と言われたことがあります。

全く間違って言うわけではないのですが、正確にはテストして、そこで不具合が出た場合に、不具合の原因を調べて修正することを”デバグ”というわけです。

デバグを職人技で行なわないこと！

不具合が出たときにデバグをするわけですが、まさにデバグに取り組んでいるときはその作業に没頭してしまうことが多いです。

不具合の原因を調べる際に、様々な試行錯誤をしても問題が解決出来ないと言うことはありがちです。

中々問題が解決出来ないと、焦りもあって、感情が高ぶり、徹夜して直そうとするといったことが良くありがちです。もちろん納期が決まっていて、明日までに必ずお客様にシステムを納めなければいけないという状況で致命的なバグが有る場合は、徹夜もするというのが昭和のやり方でした。

しかしながら、そういう問題が起きたときこそ冷静になることが重要です。

作業者一人でプロジェクトを行なっている場合はあまりないと思いますので、プロジェクトメンバーとも不具合原因を議論するなど、作業者一人に問題解決を任せないようにすることが非常に大切です。

まとめ

今回はシステム開発におけるデバグに関して、基本的なことと、仕事の取り組み方について解説しました。別の記事では、テストの仕方や具体的なデバグの方法などについても解説したいと思います。

無料相談会希望

関連記事

⇓

システム開発において要件定義、設計と共に重要なテスト計画、テストの進め方について