たとえるなら
水漏れの原因探しです。天井のシミ（症状）を見つけても、水がどこから漏れているのか（原因）はすぐにはわかりません。配管を一本ずつたどって漏れ場所を突き止めるのが一番大変で、見つかってしまえば直すのは早いことが多いのです。
もう少しくわしく
デバッグ（debug）は「bug（虫）を取り除く」という意味で、バグの原因を突き止めて修正する作業です。プログラムを書く仕事と聞くと新しいコードをどんどん書く姿を想像しがちですが、実際のエンジニアは思いどおりに動かない原因を探す時間にかなりの割合を使っています。書く力と同じくらい、原因をたどる力が問われる仕事です。地道な作業ですが、ここが速い人はチーム全体を助けられます。
デバッグはよく探偵の仕事にたとえられます。まず「どんな操作をすると、何が起きるのか」を正確に再現し、プログラムが残す記録（ログ）や途中の値を調べて、あやしい範囲を半分ずつ狭めていきます。処理を一行ずつ止めながら中身を覗ける専用の道具を使うこともあれば、途中の値を画面に出して確かめる素朴な方法をとることもあります。目的はどちらも同じです。
混同されやすいのがテストとの違いです。テストは問題があるかどうかを見つける作業、デバッグは見つかった問題の原因を探して直す作業です。テストで見つけ、デバッグで直す、という順番の関係になります。似た言葉の「修正（フィックス）」は直す行為そのものを指し、デバッグには原因を探している時間まで含まれるという違いがあります。「デバッグに1日かかった」の中身は、ほとんどが原因探しの時間です。
現場では、利用者や社内からの報告、あるいはテストで挙がった不具合からデバッグが始まります。担当者はまず手元で症状を再現し、再現できたら原因を絞り、直したうえで同じ手順をもう一度試します。影響が大きいものから順に着手するのが基本で、すぐ直せないものは当面の回避策を案内しながら調査を続けることもあります。分かったことは途中でも共有します。見込みが変わったら、そのつど伝え直します。
落とし穴の代表は、原因を確かめずに症状だけ塞ぐことです。表示は正しくなったが根っこは残っている、という直し方は、別の場所で再発します。次に多いのが、再現できていないのに「たぶんここだろう」と直してしまう進め方。直ったかどうかを確かめようがありません。そして、ひとりで長時間抱え込むことも失敗の形のひとつです。抱え込んだ時間は、たいていスケジュールに入っていません。
働きはじめたばかりの人は、時間を区切って助けを求める習慣をつけてください。「30分進まなければ相談する」と決めておくだけで、行き詰まる時間が短くなります。人に説明してみるだけで抜け道が見つかることもよくあります。エンジニアではない立場の人にとっていちばんの貢献は、「どの画面で、何をしたら、どうなったか」を具体的に伝えることです。画面の写真や起きた時刻も添えられると、さらに役に立ちます。
デバッグはどれくらいで終わるかを見積もりにくい作業です。原因の一行が5分で見つかることもあれば、症状が出たり出なかったりするバグで、再現させるだけに何日もかかることもあります。だから「いつ直りますか」と聞かれても即答できないことが多く、現場ではまず調査の時間をもらい、原因が分かった時点で修正の見込みを伝える進め方をとります。原因さえ分かれば、直すのは早いことが多いのです。
現場での使われ方
「いまデバッグ中なので、ちょっと待ってください」
不具合の原因を調査している最中という意味です。頭の中で条件を組み立てている作業なので、話しかけられると振り出しに戻ってしまうこともあります。
「再現手順がわかれば、デバッグが一気に進みます」
その不具合を意図的に起こせる操作手順が分かれば、原因の特定がぐっと早くなるということです。思い出せる範囲で、操作した順に書いてみてください。
「ログが残っていないので、これ以上たどれません」
プログラムの動作記録がないと、何が起きていたのかを後から調べる手がかりがなくなるという説明です。後から足しにくいので、先に考えておく部分です。
「原因は分かったので、あとは直すだけです」
いちばん難しい原因の特定が終わったという報告です。この一言が出れば、多くの場合そこから完了までは早く進むと考えて構いません。残りは手順どおりに直して、確認するだけになります。
よくある質問
デバッグとテストの違いは何ですか？
テストは「問題がないか確かめて見つける」作業、デバッグは「見つかった問題の原因を探して直す」作業です。テストで見つけてデバッグで直す、という順番の関係になります。ただし、見つけて直すまでをまとめて「デバッグ」と呼ぶ現場もあり、境目は厳密ではありません。
デバッグとフィックス（修正）は同じ意味ですか？
少し違います。フィックスは直す行為そのものを指しますが、デバッグには原因を探している時間まで含まれます。実際にかかる時間の大半は原因探しなので、「修正にどれくらいかかるか」を聞かれても、原因が分かるまでは答えられないことが多いのです。見積もりにくい作業だと知っておくと、やりとりが楽になります。
デバッグはなぜそんなに時間がかかるのですか？
症状が出ている場所と、原因のある場所が離れていることが多いためです。画面の表示がおかしい原因が、まったく別の処理にあることもあります。さらに症状が出たり出なかったりする場合は、再現させるだけで何日もかかることも珍しくありません。つながりを一つずつたどる時間が、どうしても必要になります。
再現できない不具合はどうするのですか？
まず再現させる条件を探すところから始めます。使っていた端末やブラウザ、操作の順番、データの状態などを聞き取り、記録（ログ）から手がかりを集めます。それでも再現しない場合は、記録を増やす仕組みを入れて次に起きるのを待つこともあります。分かっている情報は残しておくと、次の手がかりになります。
エンジニアでなくてもデバッグに協力できますか？
できます。しかも効果が大きいのは報告のしかたです。「どの画面で、何をしたら、どうなったか」に加えて、いつから起きているか、毎回起きるのか、使った端末は何かを添えるだけで調査の範囲が狭まります。推測より、見たままを書くのが役に立ちます。画面の写真があるとさらに助かります。
