現場で役立つ 実践デバッグ手法

「基板に電源をいれたら全く動かない。」「プログラムを実行したら誤った動作をしている。」など、トラブルが発生した瞬間は「えっ、そんなはずはない」「ちゃんと見直しもしたし、正しく動くはず。なんでなんで・・・どこにバグ（問題）あったの？」っと、あせってしまい頭が真っ白になってしまいます。
みなさんならこんな時どうしますか？ まずは上司、チームリーダに報告？

先ほどの例のように「○○がおかしい。」「○○が動いていない。」など、曖昧な報告は避けてください。曖昧な報告で作業を進めてしまうと、その後の確認事項のやり取りや想像での作業が増えて、余計に時間がかかってしまうことがあります。
バグ（問題）が見つかったことを早く報告したいという気持ちもわかりますが、あせってもいいことはないので、まずは深呼吸をして落ち着いてから、デバッグ（問題解決）プランを考えていきましょう。

・まさに今デバッグを行っていて、この記事を読んでいる人
・ここまでの記事を読んで、昔の記憶がよみがえった人

心を落ち着けるために、一度深く深呼吸してからこの後の記事に進んでみましょう。

上司も確認していましたが、的確な報告を行うには、まずバグ（問題）の発生状況について以下の確認が必要です。外部に確認依頼を出すにしても、最低限これらの具体的な情報が必要です。

これらの情報はあって困ることはないので、これ以外にも必要だと思ったものは積極的に確認を行ってください。ここまでまとめられたら報告を行いましょう。

電源ICでトラブルがあった場合の例ですが、当社では以下のような確認を行っています。

報告が終わってひと段落したら、今度はその情報を再確認します。いきなり問題点に踏み込んでいくのではなく、すぐにわかることから調査を始めましょう。下記は確認項目の一例ですが、確認項目の洗い出しには、「もし○○という問題だったとしたら・・・」と仮説を立てて、進めていくとアプローチ方法がいろいろと出てきます。

この確認時は「何を・何回やって・どういう結果になったのか」を必ず記録につけましょう。記録方法は「星取表」を使うと、確認回数や確認項目漏れを防ぐことが出来て便利です。
この記録は作業の整理や発生頻度の再確認に役立ちます。

ここまでくるとある程度、問題の再現方法やその時に発生する現象がしぼれてきますので、ここからはその現象が発生する原因の仮説とその確認方法を考えてみましょう。
ここでは“LCDが映らない”問題を例に考えてみましょう。

事象：機器に電源を入れてもLCDが表示されない。映ってもノイズがのる。

よくある間違いはこれまでに電源やクロックをチェックしているので、もうHWは大丈夫と判断してしまい、いきなり表示用のデバイスの設定をチェックし始めることです。
そうしてしまうと表示用のデバイスとLCDパネル間に問題があった場合には、ほぼ見つけることは不可能でどんどんデバッグの深みにはまってしまいます。
この項目でのポイントは問題が起きているところから順に現象（信号）を逆に追っていくことです。

仮説①：LCDパネルが壊れているかもしれない。
仮説②：本体とLCDパネル間のケーブルが断線しているかもしれない。
仮説③：LCDモジュールに入力している映像信号がおかしいのかもしれない。
仮説④：表示用のデバイスが出力している映像信号がおかしいのかもしれない。
仮説⑤：表示用のデバイスの設定がおかしいのかもしれない。

いろいろと仮説を立てて検証を行っても、なかなかバグ（問題）が見つからないときは、次のことを試してみてください。

デバッグに行き詰ったときの最終手段です。

「一度、リフレッシュしましょう。」

ここまでやってもなかなか成果が出ない場合は、リフレッシュすることで新しい気持ちで最初からデバッグに取り掛かれます。そのことで新たな発見の手助けにもなります。

ただし、本当に休んでしまう前に最後にもうひと踏ん張りして、次にスムーズにデバッグを開始できるように準備をしておきましょう。

今回はみなさんが一度は経験したことがあるデバッグのあれこれについて紹介しました。バグ（問題）が見つかった時、そのデバックに行き詰った時にどうすればいいか。意外にそういう時の考え方、デバッグの方法って知られてないよね。ということで記事にしてみましたが、我々の社内のエンジニアのノウハウが、少しでも皆さんのお役に立てればうれしく思います。