デバッグって何？よく聞くけどあまりわからない…
プログラミングなどでよく用いられる「デバッグ」という単語。曖昧過ぎてよくわかってはいない人も多いのではないでしょうか。
今回はそんな「デバッグ」について、ご説明していこうと思います。
皆さんこんにちはいかがお過ごしでしょうか、Jinです。
ふと最近思うのがデバッグの重要性で、同好会の後輩にもよく「デバッグするぞ！」と言って首を傾げられることがあり、一度記事に起こすことにしました。
こちらの記事でも少しデバッグについて紹介していますので、是非ご覧いただければと思います。
今回の記事はJLCPCBにご提供いただいています。併せてご覧ください！！
バグとは
まずはデバッグの言葉から解析していきましょう。英語ではDe-Bugという単語で表されるのがデバッグです！と言っても何が何だか分かりませんよね…
頭に来る単語を接頭辞と言いますが（キレているわけではない）、Deという接頭辞は日本語では非～、反～などのように語の意味を反転させたり除去させるという意味があります。
では次にBugです。これがデバッグの醍醐味になります。バグという単語を聞いたことのない人は少ないのではないでしょうか。
Bugとはその言葉通りバグであり、プログラムに限らずものづくり全般においてバグとは、想定していたものとは予期せぬ動作を引き起こす原因となるものを指します。
ここで（ ＾ω＾）おっ！となる人は鋭いと思います。
ものづくりとは常に予想と確認の積み重ねであり、その予想と確認を地点として考えると、予想から確認に向かう矢印そのものがものを作るという行為であり、この間にバグが発生し、動作を確認して発覚できます。
そしてこのバグも挙動を予想して修正しフィードバックすることにより、どんどんと目的の動作に近づけていくことになります。そしてここで断言しておきます。
バグは消えません！！
なので完璧に目的の動作にすることはほぼ不可能です。しかしバグを放置することは危険です。ほとんどバグのないものを生み出して初めて妥協ポイントに到達できます。
つまりバグとは、地上からどれだけ消そうとしても消えないゴキブリのような存在であり、ものづくりではこのバグを極限にまで減らした状態に近づけて初めてものが完成します。
そしてもうお分かりかもしれませんが、debug”デバッグ”とはバグを打ち消す、除去するものづくりの段階であり、どのような分野のものづくりでも最終的にはこのデバッグに通ずのです。
解析とは
デバッグの意味とバグについて理解を深めたところで、実際にデバッグをしてみましょ～！となったときあなたはどうしますか？
本質的な理解が出来ているのであれば、あなたはまず倒すべきゴキブリ、潰すべきバグの原因を見つけて来ようとするはずです。小さな規模のプロジェクトならどうでしょう、バグの原因はすぐに見つかると思います。
あなたは今エルチカをしている電子工作初学者だと思ってください。ここで「私は電子工作を～年もやっているProだぞ！」なんていうプライドは捨ててくださいね。マイコンのプログラムでGPIOピンをOn/Offすることによって制御しており、その信号をLEDに伝えているとします。
しかし、LEDは点灯したままで点滅には至りません。どうしてでしょうか？
こうなった時にまずはプログラムの適切な位置に点滅を制御する処理が記述されているか。又は回路で適切な位置にGPIOピンの出力が繋がれているか。を確認することでしょう。
その確認の手段を言い換えると、バグの原因を発見するといったことになり、先ほど説明した動作の予測に当てはまりますね。この予測の手段を「解析」と言い、デバッグで一番重要な要素となります。
小さなプロジェクトなら簡単に見つかるバグの原因も、規模が拡大するにつれてどんどんとその発見が感覚では難しくなっていきます。そのために解析という手順が存在しています。
静的な解析
では、デバッグを行うためにバグの原因を発見するために解析するための手順を話していきましょう。解析には次の2種類あります。静的な解析と動的な解析です。それぞれについて説明していきます。
静的な解析はエロい意味ではなく、静かだということです。静かというのは動きが無いということ、つまりいちいち動かさずにバグを発見していくということになります。
具体的な手法としてはバグの挙動から特定の機能に目星をつけ、その機能が含まれる箇所の回路図やプログラムを読み、回路であれば電圧や電流値を、プログラムであれば変数の値や関数の挙動を完全に予測して問題の箇所を発見します。
動的な解析
次に動的な解析です。静的とは逆に、作ったものを実際に動作させて値を確認することができます。これは上の方で紹介した「確認」の手順に当てはまりますね。
実際に動かして分かるなら動的解析のみで良さそうだと思うかもしれませんがそれは間違いです。まず、確認するには確認するための予測をする必要があり、その過程で必ず静的解析を行うためです。
例えばプログラミングで動的解析を行うとき、デバッガというツールを利用することがあります。デバッガでは予め設定したところ（ブレークポイント）で処理をとめて変数の値やメモリの使用量など様々なものを確認できます。
それでは静的解析を行わないとして、このブレークポイントをどこに置けばいいですか？と聞いた時にあなたは答えられるでしょうか。
またハードの解析で高電圧を扱っていて、大きなバグがある状態で動かすと非常にリスクの高くなる危険な状況などでは、動的解析自体がそもそも不可能な場合もあります。
このように実際の解析では適当な箇所で静的解析と動的解析を使い分けて解析を行う必要があり、一概にどっちかを行うことはありません。
課題解決を極めよう
解析とはバグの原因を徹底的に究明する手段です。
これをより大きく論理的な思考法そのものに当てはめて考えてみるとどうでしょうか。バグの原因と結果、予測と確認の因果関係はものづくりだけではなく論理的な考え方そのものであると捉えることが可能です。
論理的プロセスで課題を解決するとき、一番重要になるのは正しくその原因を究明できるかというところにあります。つまり解析の手順がデバッグにおけるすべてを制しているといっても過言ではないのです。
解析した問題に対して対処するデバッグそのものはものを作ることと全く同じことであり、デバッグ≠ものづくりという考え方は間違っています。
課題解決を極めるために、原因と結果、予測と確認を対応付けて意識し、日常生活に潜む様々なバグへのデバッグにどんどんと挑戦していってください！！
さいごに
いかがだったでしょうか。今回、デバッグとその根底にある解析そのものについて非常に簡易的にではありますが説明させていただきました。
案外ものづくりという狭い視野の中で様々な事を捉えてしまいがちになりますが、実はものづくりもこの人間を形作る社会の一つの分野に過ぎず、ありとあらゆることを論理的な考え方が支配しているのです。
その論理的な思考法をつかさどることが、様々な課題に向けて解決していくことのできる人間になる第一歩なのではないかと、思います。
このブログで紹介できるのはそのちっぽけな一つの分野のみになってしまいますが、今後ともよろしくお願い致します。
またご提供いただいているJLCPCBも是非チェックしてみてください。
それではまた！GoodBye！！