デバッグの勘所！警察の犯人検挙とデバッグの考え方やコツは同じ！

こんにちは！
刑事ドラマと言えば相棒よりもはぐれ刑事の方が思いつくイシヤマです。

今回は、ソフトウェア開発をする時に避けては通れないデバッグの勘所について書いてみようかと思います。

バグを直す作業でしょ？

その通りです。
ソフトウェア開発に携わっている方にとっては知っていて当たり前、テスト工程に入るとデバッグばかりやっていると思います。

では、新人プログラマーやデバッグに興味のある人に説明するとしたら、あなたならどう説明しますか？

僕はデバッグについて聞かれると、「警察が犯人を逮捕するプロセスと似ている作業」と答えるようにしています。

犯人を逮捕するプロセスは大きく分けるとこんな感じになるかと思います。

では、このプロセスに沿ってデバッグとはなんぞやについて説明していきたいと思います。

犯行現場でどんな事件が発生したかを調べ、目撃者から凶器や犯行時刻などの証言を聞き事件の内容を理解する

これが現場検証と聞き込みの目的です。これをデバッグに置き換えると

再現環境（OSや機種など）でどんなバグが発生したかを調べ、評価者から再現方法や条件などを聞きバグの内容を理解する

こうなります。

どちらもまず最初にすることは、一体何が起きているのかという情報を集めて犯人（原因）を特定するための足掛かりを見つけることです。
これをしっかりやらずに情報の見落としや不足があると、バグを再現することが出来なかったり再現条件を見逃してしまうことに繋がります。

碌に現場検証や聞き込みをせずに「犯人はあいつだ！」と言われても「えっ？」ってなっちゃいますよね。

すぐに犯人を特定したがるどこぞの小五郎かと。

たかが内容理解と思うかもしれませんが、これら初期調査はこの後のデバッグ作業の質を高めるとても重要なプロセスなのです。

初期捜査が進むと集まってきた情報をもとに犯人像を割り出していきます。

茶色のジャンバーと黒いGパンを履いた身長約175㎝の３０代男性が怪しい

ここまで素性が割れていると防犯カメラが溢れている現代ならすぐ捕まっちゃいそうですね。
では、デバッグの世界ではどうなるかというと…

DBへの保存と保存結果の変換を行うデータ管理クラスが怪しい

このように、処理を理解している古参な方なら怪しいクラスやメソッド、新人や引き継いだばかりでよく分からない処理ならこんなことをしている箇所などアバウトな当たりを付けることから始めます。

この犯人（原因）予想は一連のプロセスの中で一番面白いところでもあり、一番嵌りやすいところでもあります。

例えば、ログなどを調査した結果「強制終了原因は明らかにこれだ！」と原因予想をしたとします。強制終了の場合、ログに出ているスタックトレース（強制終了した箇所を示す情報）などを見ていれば直接の原因はほぼ間違わないでしょう。

しかし…

XXXXへのNullアクセスで強制終了しているとログに出ています！
なのでNullチェックすればOKなのです！（どやぁ

と、犯人の特定と共に対処方法も言いたくなりますが、そうはうまくいかないことの方が多いのです。

確かに、強制終了を引き起こした実行犯は一人（その場所）かもしれませんが、裏で糸を引いている真犯人がいて、他の実行犯（処理）が同じ犯罪を犯すかもしれないのです。

では、直接手を下さずに裏で原因を作っている真犯人を捕まえるためには何をしなくてはいけないのか？

ズバリ、証拠集めでしょう。

真犯人がこのような指示（処理）をしたせいで実行犯が犯行に及んでしまった、ということを証明することができれば真犯人を逮捕するための足掛かりとなります。
また、真犯人の指示内容（処理内容）がわかれば、その指示を受け取る下っ端の洗い出しもできるようになり、実行犯を一網打尽にできるのです。

ここまでくると、デバッグ作業としてもより具体的な解析をしなくてはいけません。

「たぶんこの辺の処理が怪しい」

といったアバウトなものではなく、

「このクラスメソッドがこの条件の時に限り、本来設定すべきエラー値を設定しないからNullになってしまっている」

というように、ピンポイントでビシッと原因を指摘できるくらいまで調査を進める必要があるのです。

ここまでわかれば、いよいよ犯人達を逮捕する逮捕状請求に踏み切ります。

デバッグの世界ではバグ原因に対する修正を行い、その修正が本当に正しいのかをレビューしてもらう工程となります。

逮捕状の内容、つまり、修正内容が正しいことがレビューで確認できるとようやくその修正がソフトウェアに適用されます。

このレビューをおろそかにすると、別の犯罪者を刺激して違う事件を引き起こしたり（デグレード）、真犯人を取り逃がしてしまい別の場所で同じ事件が起こったり（修正漏れ）といった信用を失ってしまう事態を引き起こしてしまいます。

レビューをしてもらう側は、何か見逃していることがあるかもしれないので細部までチェックしてほしいという受け身の姿勢で、レビューをする方は本当にこの修正が正しいのか、他にもっといい方法があるのではないかといった疑いの目で厳しく見ることが大事です。

このように、デバッグのプロセスというのは警察の犯人逮捕のプロセスと非常に似た流れとなっており、気を付ける点などの類似点も多くなっています。

デバッグを行う際に、そういえば犯人逮捕を例にしていた奴がいたなという程度で構わないので思い出していただき、少しだけ慎重な捜査を行い完璧な逮捕劇を繰り広げていただければ幸いです。