こんにちは。すうちです。

前回デバッグの際、原因の探り方について触れました。

過去の不具合事例を思い出して書きましたが、原因を大別すると主に３つのパターンになりそうと気づきました。

今回は不具合の要因と対策について、過去の経験を交えて書きたいと思います。

■はじめに

前回に引き続き繰り返しになりますが、デバッグ（Debug）とは、

問題が発生する原因は様々ありますが、以下は抽象度をあげて問題を引き起こす要因を列挙しています。

■不具合の要因と対策

1. 思い込み

新しく導入した機能などで設定を追加したつもりが実際できてなかった。自分の思い込みから起こした不具合の例です。

新しい機能で初期設定ファイルを追加しテストした所、最初のファイル読み込みに失敗。エラーコードは「指定のファイルやフォルダが見つからない」とのこと。

そのファイルは他の初期設定ファイルと同じフォルダにあり、最初はファイルシステムのパス指定の間違い等を疑いましたがそれは問題なし。他のファイルは正常に読めるので、訳がわからず頭に疑問符が並びました。。。

原因は、エラーコード通り対象ファイルがテスト環境になく同じフォルダ構成のバックアップ環境（別の場所）にファイルを置いていたためでした。

答えがわかれば単純な話ですが、過去こういう問題に何時間も使ったことあります（パスは正しいが参照ファイルやライブラリのバージョンが古くて期待通り動かなかった事例もあり）。

最初の思い込みで間違った方向に進んでしまった訳ですが、「ここは問題ない」と決めつけるのではなく、事実確認（例：目的のパスやファイル更新日時は正しいか）することが結果的に不具合を減らせる近道と思います。

2. 確認漏れ・理解不足

特に新しい機能を立ち上げる場合など、連携する関数やライブラリの仕様（使い方）の確認が足りないことで起こる問題です。

自社で作成するコードは当然テストしますが、既存のライブラリなどは意外にテストがおろそかになったり確認不十分で進めて、後でトラブルになるケースがありました。

ライブラリだけでなく外注や別部署（開発担当が違う）のソフトウェアを導入する場合も同様です。

仕様書やドキュメントだけでは細かい動作がわからない場合、設計や実装前に確認するのが大前提です。

その際、いきなり実装するのではなく別の評価環境を作って対象のソフトウェアをテストすることから始めます(必要最低限の期待動作を実現できるか確認)。

極力余剰を排除して、対象部分のみテストすることで、仕様書に書かれてない具体的な使い方や実装時に必要な項目の洗い出しもできます。

手間はかかりますが、一度ワンクッション入れた確認することで結果的に手戻りを防ぐ効果もあると思います。

3. 異常系の考慮漏れ

過去ネットワーク経由で転送されるデータを受信する部分で一定周期で異常な値がくるケースがありました。

原因は通信途中のハードウェアの問題でしたが根本対策は時間的に厳しいという理由で定期的にハードウェアをリセットしたり異常値きた場合の対策を後でソフトウェアに入れたことがあります。

上記のように１と２を十分やったとしても、一部の異常系などは最初から全てを網羅した設計や実装はかなり難しいです。

加えて組込機器はハードウェアと連携したソフトウェア部分も多く、異常時などハードウェアが想定外の動作するので、事前に設計でカバーできないのも理由です。

異常系の不具合は、基本的に結合テストやシステムテストで見つけて対策するのが一つの方法ですが、この場合も対象のハードウェア（ICやセンサ含む）が単体でテストできて、例えばデータの最大最小範囲や動作仕様がわかればそれらを設計に反映します。

仮に単体確認が難しい場合もあらかじめデータの有効範囲や異常時のオーバフロー対策（規定以上の値はカットする）を決めて、有識者や関係者の意見も取り入れてリスクを洗い出したり実装を検討します（レビューは必要に応じて外注先や顧客関係者も含める）。

■最後に

主に組込業界でのソフトウェア開発経験を基に記載しましたが、ソフトウェアの業種や開発担当によっては少し違う部分もあるかもしれません（他のエンジニアの皆さんの経験も聞いてみたい気がします）。

個人的な感触では不具合を起こす要因は１、２の割合が高い印象です。エンジニア個人の場合もありますし、チームで開発する場合、担当者間のコミュニケーションの問題（業務の忙しさや単に伝達不足など理由は色々ですが）で発生することも過去の経験でありました。

３についてもある程度事前の対策はできますが、タイミングで発生する問題などはなかなか対策立てにくいと感じます。

私の場合、特に若い頃から優秀という訳でもなかったので多くの失敗を経験してきましたが、今はそれらの失敗も見方を変えれば自分の財産になっているのかなと思います。

とはいえ、リリース後のトラブルや製品出荷後に顧客から問題報告などは誰でも避けたいと思います。

今回の内容が何かしら参考になれば幸いです。

最後まで読んで頂き、ありがとうございました。