デバッグ・トラブルシューティング方法論（仮）

プログラミングにおいてデバッグ・トラブルシューティングは避けて通ることはできない。 自分ももちろん日々プログラムが思い通りに動かなかったり、プロダクトのトラブル報告に向き合っているが、デバッグは人より得意であると自負している。

そこでなんとなく以前から、どのような思考をすればデバッグ・トラブルシューティングが（少なくとも自分水準くらいには）上手になるかということをぼんやり考えていた。 おおよそまとまってきたと思うので一旦ブログとして書き起こしてみる。

デバッグの手順

まずはどういう手順でデバッグしていくかを整理する

1. 情報を集める

最初はどういうバグが起きているのか情報を集めるところから始める

• そのバグはどういう現象なのか、どういう状況で起きたのか
• 関連しそうなエラーメッセージやデバッグログは存在しているか
• プログラムのソースコードはどのようなロジックになっているか
• 同じような現象は過去起きていないか
• 発生時刻に関連しそうなイベントはないか、メトリクスに変化はあるか
• 再現することはできるか

などなど。次のステップを進める前にここを完璧にやる必要は必ずしもなく、大雑把でもよい。

2. 仮説を立てる

ある程度情報が集まってきたらそこからどういうことが起きているのかを仮説を立てる。 「推測するな、計測せよ」という言葉があるが、この言葉は推測そのものを否定するような言葉ではない。 計測は重要だが、どこを計測するかを決めるための推測は重要である。

仮説は１つである必要はなく、複数立てて良い。より多くの仮説を立てたほうが次以降のステップがスムーズになる。 ただし、複数の仮説を立てる場合、最も確からしい仮説はどれかということは意識したほうが良い。

3. より詳細な情報を集める

仮説がいくつか立てられたら、それを裏付ける証拠を掴む。 最初の段階で集めきれなかった情報を仮説に基づいて絞ってより収集するということになる。 情報を集めたら、本当にその情報は仮説のストーリーと矛盾しないかを精査するということも重要だ。 例えば、ソースコードを見てこういう実行パスをたどればこういう現象が起きるはずだ、という仮説を立てた場合、それに対応するデバッグログが矛盾なく出ているかというの確認する、といった具合である。

もしここで、仮説と矛盾する証拠が出てきた場合、その仮説は直ちに修正しなければならない。 その場合は別の仮説を検証したり、１に戻って幅広く情報を集めて仮説を立て直すということが必要になる

4. 検証する

仮説が正しいという確信が持てたらあとは修正してデプロイするだけである。 デプロイ後、本当に修正が正しかったか経過観察することも大切である。修正ができたことを確認する手立てを用意しよう。例えば

• 手動で追試する
• テストを追加する
• メトリクスを観察して、期待される変化が起きているか確認する

などである

デバッグに詰まるとき

デバッグに詰まるときというパターンはそもそも情報が足りなくどういうことが起きているかわからない、ということがまず考えられる。 こういう場合は、そもそも情報を増やすような手立てを増やすことを考えるところから始めるとよい。 例えば、デバッグログを増やす・メトリクスを計測可能にする・デバッガなどのツールを使いこなせるようになる、などである。

次に考えられるのは、仮説の立て方がよくないというパターンだ。 例えば、ネットワークに接続できないといった場合に、実はルーターの電源が抜けているだけなのにクライアント側の設定のみを疑ってしまう、といった具合だ。 これは背景知識や経験が十分でないために、そもそも仮説を立てることができないということである。これはとにかく自分の経験値を貯めて、あらゆる可能性を考えられるようにするしかない。

もうひとつある頻出パターンは、誤った仮説にこだわり続けてしまうという場合だ。1での情報収集が不十分であるために、誤った仮定を置いてしまいそれに気が付かず仮説を立ててしまい、3のフェーズにおいて調査範囲を狭めてしまうと泥沼にハマってしまう。 例えば、このモジュールは正しく動くはずと信じていたのに実はバグっていた、というケースだ。 ３の段階で矛盾した証拠が出てきた場合、あるいはなかなか自分の仮説を裏付ける証拠が出てこない場合に、仮説を見直して捨てることができるかというのが大切だ。 とはいうものの、思い込みを捨てるのは案外難しかったりする。結局は経験を積んで、少しずつ思い込みに気づけるようになることが大事なのだと思う。

まとめ

デバッグ・トラブルシューティングにおける思考をまとめてみた。 手早くデバッグするには、経験値を積んで多くの情報を的確に収集し、あらゆる可能性を考えられるようになることが大切だ。 そうして思考訓練を重ねることで、トラブルシューティングの精度は上がっていくのだと信じている。