「組込み制御ソフトウェア」開発では、要求仕様の設定から、設計、コード作成、テストなど、一連の作業工程があります。これらの作業工程の中で、どの作業工程の負荷を減らす事が出来ると、最も嬉しいでしょうか？ ある程度複雑で規模が大きい「組込み制御ソフトウェア」の開発を、何度か経験した事のある人であれば、おそらく同じ考えを持つと思いますが、やはり開発工程の「最終フェーズのテスト工程」を、出来るだけ短期間で終わらせたい事でしょう。
開発の上流工程である要求仕様の設定が遅れる事や、開発の下流工程でソフトウェア作成がある程度進んでいる状況で、要求仕様が変更される事はよくあるでしょう。それにより、現場のソフトウェア開発者には、予定された開発の締切りが迫る中で、急いで開発を終了させなければいけないという、大きなプレッシャーが掛かります。そういった状況の中、最終テストで発生した「不具合」をなかなか修正できず、ずるずると開発期間が延びてしまう事は、とても辛いものです。最悪の場合、開発の時間や資金が底をついて、開発自体を諦めないといけなくなるかもしれません。新規システム開発の場合、もしかすると作りたての組込みハードウェアに問題があるかもしれませんが、一般に最初に不具合を疑われるのは、いつも組込みソフトウェア側です。組込みソフトウェアの開発者は、「不具合」の原因がソフトウェアで無いことを明確に示す事が出来なければ、開発が成功しなかった場合に、全ての責任を取らされるかもしれません。
ということで、本サイトは、「組込み制御ソフトウェア」の開発では、“最終テストで発生する「不具合」を効率よく修正する”事が、最も重要な事として取り上げ、その対策について考えていきます。
ちなみに、本記事では、「バグ」という表現を使うことは避け、その代わりに「不具合」という表現を使います。これは、私の個人的な好みになりますが、「バグ」という表現を使うことは、とても無責任に感じるからです。期待通りの挙動が得られない原因は、仕様に問題がある場合もあれば、設計に問題がある場合もあり、コーディングミスがあるかもしれません。単純に、「組込みハードウェア」へ実装するもの（テストするもの）を間違えているだけかもしれません。そもそも、「組込みハードウェア」自体に「不具合」があるかもしれないのです。従って、「不具合」の原因を見つけなければというプレッシャーがかかる中で、「不具合」の原因を積極的に曖昧にしてしまう「バグ」という表現は、許容しがたいのです。
