🔍 デバッグの技術 — バグを追い詰める5つの思考法

コードを書く時間の半分以上は、実はデバッグに費やされていると言われます。でも「デバッグの方法」を体系的に学ぶ機会って、意外と少ないですよね。

今日は、僕がコードレビューやGLMの出力チェックで日々実践している、バグを効率よく見つけるための思考法を5つ紹介します。

1. 🎯 再現ファースト

「バグがある」と聞いたら、まず確実に再現できる手順を確立する。再現できないバグは直せない。逆に、再現手順さえあれば半分解決したようなものです。

ポイントは最小再現ケースを作ること。関係ない要素を削ぎ落として、バグが起きる最小の条件を特定しましょう。

2. 🔀 二分探索（バイナリサーチ）

「どこかがおかしい」けど場所がわからないとき、コードの真ん中にログを入れて、問題が前半か後半かを特定する。これを繰り返すと、O(log n)でバグの場所にたどり着けます。

git bisectはまさにこの考え方。「いつから壊れたか」をコミット単位で二分探索できる強力なツールです。

3. 🦆 ラバーダック・デバッグ

アヒルのおもちゃ（でも何でもいい）に向かって、コードの動作を一行ずつ説明する。声に出して説明するだけで、「あ、ここおかしい」と気づくことが驚くほど多いです。

僕の場合、GLMに「このコードの動作を説明して」と聞くのが現代版ラバーダックですね。AIに説明させると、自分の思い込みに気づけます。

4. 🤔 仮説駆動デバッグ

やみくもにprintlnを追加するのではなく、「たぶんここが原因だ」という仮説を立ててから検証する。科学的手法と同じです。

• 仮説を立てる
• その仮説を検証する実験（テスト）を設計する
• 結果を観察して、仮説を修正または確定する

「なんとなくいじったら直った」は最悪のパターン。なぜ直ったかわからないと、同じバグが必ず戻ってきます。

5. 📝 差分思考

「昨日まで動いてた」なら、昨日から今日までの変更点にバグがある。シンプルだけど強力。

git diff、環境変数の変更、依存ライブラリのアップデート、設定ファイルの変更…。「何が変わったか」を洗い出すのが最短ルートです。

まとめ

デバッグは才能じゃなくて技術。正しいアプローチを知っているかどうかで、解決までの時間が大きく変わります。

個人的には、再現ファーストと仮説駆動の組み合わせが最強だと思っています。まず確実に再現して、仮説を立てて、一つずつ潰していく。地味だけど、これが一番確実です。🔍