はじめに
新卒エンジニアとして開発を進めるなかで、バグ対応をすることがよくあります。
本記事では、改めて効果的にバグの原因を特定するための手順を詳しく解説します。
バグとは
プログラムを実行しているときに何らかのエラーを出して動かなくなってしまったり、動いたとしても自分が想定している挙動をしない場合に「バグが発生している」と言う。バグ（bug）は英語で虫を意味します。
デバッグとは
コンピュータの不具合の原因である「バグ(bug)」を「取り除く(de)」と言う意味で、これらを繋げて「debug(デバッグ)」と呼ばれます。
どう特定するのか
バグ改修をするにあたって、バグ原因を特定するための手順を調べました。
前提：事実を客観的に残す
バグに関する情報を客観的に残すことは重要です。
バグに関する調査をするにあたって、自分が調べたことや判明した事実はどんどんコメントで残していきます。例えば、ログやスクリーンショットです。例えばログの解析を行った際には、仮説とログの調査結果をスクリーンショットでNotionなどの作業メモに貼ります。こういうログが出たから〇〇が原因ではない。など、客観的なデータと一緒に残すことで後で誰かが引き継いだときや思い込みを排除し、頭の中を整理する助けになります。
再現するところから着手する
バグ報告に対して無闇矢鱈に調査してしまいがちです。運が良ければ修正できますが、複数の原因が重なった複雑なバグはそうもいきませんし、よく調べてみたら原因は全く別の箇所だった、ということもあります。
真っ先にバグを改修しにいくのでなく、どのような手順で操作したら、バグが確認するのかをはっきりさせる。その上で、「○○が原因ではないだろうか？」といった仮説を立てます。
再現手順・期待する結果・実際の結果を整理する
バグの原因を調べる前にやっておくべきことは、次の3つの情報を整理することです。
-
再現手順 (Steps)
-
期待する結果 (Expected Result)
-
実際の結果 (Actual Result)
再現手順は、どのようにしたらバグを再現できるかの情報です。再現する環境や、前提条件、操作方法、入力値などを完結にまとめます。
期待する結果は、再現手順を踏んだ結果、どのような結果になるべきかを説明します。修正は、この期待する結果になるように行います。
実際の結果は、再現手順を踏んだ結果、期待にそぐわなず、どのような結果になってしまうかを記述します。
仮説を立て、仮説が原因でないことを立証し続ける
不具合の原因を特定するにあたって、仮説を立て、原因でないことを立証し続けます。（帰無仮説）帰無仮説のプロセスを繰り返していくことで、バグの原因箇所が徐々に限定されていって、最終的に必ずバグの原因が特定できるという考え方です。
帰無仮説
帰無仮説とは、統計学で用いられる概念で、「差がない」または「効果がない」と仮定する仮説のことです。バグ特定のプロセスにこの考え方を応用すると、次のようになります。
仮説の設定：
「この部分がバグの原因ではない」という仮説を立てます。
検証：
その仮説が正しいかどうかを徹底的に調査します。
結果の解釈：
仮説が棄却される（つまり、その部分がバグの原因である可能性が高い）場合、そこに焦点を当てて調査を進めます。
仮説が棄却されない場合、別の仮説を立てて検証を続けます。
この方法の利点は、バグの原因として考えられる要素を一つずつ体系的に排除していくことで、最終的に真の原因にたどり着ける点です。
例：
仮説：「データベース接続がバグの原因ではない」
検証：データベース接続をテスト
結果：接続に問題がなければ、次の仮説へ移行
このプロセスを繰り返すことで、バグの原因を絞り込んでいきます。
まとめ
今回はバグ原因を特定するまでのプロセスや大事なことについてまとめました。
これらの手順を実践することで、効率的な原因特定が可能になります。
重要なのは、バグ対応を単なる作業ではなく、システムや開発プロセスを深く理解する機会として捉えることです。一つ一つのバグ対応を通じて、コードの質を向上させ、より堅牢なシステム開発につなげていくことを意識していきたいです。
この記事で紹介した手法を基に、皆さんなりのバグ対応プロセスを確立し、より効率的で質の高い開発を目指してください！