バグの対応ガイド【心構えとアプローチ】

イントロダクション

開発を行っていると、バグに遭遇することは珍しくありません。それもそのはずで、経験豊かなプロフェッショナルが開発したシステムであってもバグは発生しています。至って普通なエンジニアの多くにとってはシステムの不具合を伝える良き隣人のようなものだと思っています。そのため、バグは非難するのではなく、快く受け入れその原因や問題を解決することに集中すべきと考えています。

この投稿では、私がバグ対応における心構えや対応手順についてポイントをいくつか共有します。開発の現場でバグに遭遇した時などに参考になれば幸いです。

1. 心構え

まずは、パニックにならないことが重要です。パニックはパフォーマンスを低下させる原因になるので、まずは落ち着きましょう。まずは、冷静な状態で対処すべき領域を探り、その問題解決の道筋を立てることに集中します。これはバグに遭遇するとテンションが上がるちょっと変わった人であれば簡単だと思うのですが、そうでないなら難しかったりします。人を頼ったり（事前に頼れる人を知っておくと良いです）、リラックスできる行動を取ったりして、まずは落ち着きましょう。実際に研究で短期間の休息が認知機能をリフレッシュし、問題解決能力を向上させることがわかっています。リラックスする行動として、個人的にはコーヒーブレイクがおすすめです。精神的なリフレッシュと、カフェインの効果で集中力を高めます。

2. バグに関するデータ収集

ErrorやWarnが発生していたり、コンパイルが失敗していたりすると、大抵のシステムは運用時の問題を検知する為に、ログや監視ツールを使用しそのデータを残しています。「ログファイル」「スタックトレース」「イベントロガー」など事前にデータから教えてもらえることは把握しておくことで、バグ対応に要する調査時間の削減ができます。原因となったプログラムや動的な値はもちろん、ユーザーの操作やその環境をしっかり抑えておくのも大事です。迅速に取得できるデータを収集した上で意識的にはシステムの運用への影響や、ユーザーのフォロー、仕様の整合性といった人間が取り組むべき問題に集中力を向けられると良いと思います。

3. バグの再現

バグは再現できないと、そのバグが修正できたかどうかを知ることは難しくなります。「テストケース」、「バグレポート」、「リグレッションテスト」などを用いて、再現とその修正を行います。その為にバグに関するデータの収集はシステムの構築やプログラミングの段階で意識しておくと良いと思います。自分の書いたコードをあまり過信せず、バグの原因を特定できるようなメッセージや動的な値をログに残すようにすると良いかもしれません。

また、バグの再現はその手順を理解することで、解決のヒントを得られることがあります。例えば「数値型の値を入力する想定のフォームに、アルファベットを入れた」などはとてもわかりやすいヒントです。データの型の制約が真面目なプログラミング言語では、キャストや代入時にエラーになりがちです。

4. エラーメッセージを理解する

バグに関するデータ収集と少し内容が被りますが。バグの解決にあたってすぐにコードを読み始める前に、エラーメッセージを理解するようにしましょう。　たくさんのコードを読み、バグの解決にあたるよりも。まず、数行のエラーメッセージやそのエラーコードなどをきちんと理解することで、問題の特定や絞り込みの助けになります。そして、特にそのフレームワークやプログラミング言語固有のエラーには注意をしましょう。大抵の場合それは英語のメッセージですが、メッセージと実際の原因があってないことがある可能性があります。この可能性に対処するために、主要なQ＆Aサイトなどで検索しておくと良いと思います。

5. デバックを行う

「ブレークポイント」、「ステップスルー実行」など、デバックの便利機能を活用してデバックを行いバグに至るまでの経緯を確認します。引数、変数などでプログラムが保持している値がどんなものかを知り、それがどのようなプログラムを通って、時にはその値の型や値そのものの変更を経て、どのコードじでバグが発生しているのかを確認します。確認には値であれ、問題のコードであれ二分探索が便利です。

6. バグを特定し理解する

バグを特定し、その内容を理解しましょう。理解度の基準としては自分以外の誰かにきちんと原因を伝えられるレベルで理解していると良いと思います。その基準で理解することで、周りを頼りやすくもなります。自ら周囲に共有し、どのように修正を行うべきか他の開発メンバーやマネージャなどに相談すると対処の質や速度の向上が見込めます。

7. 二次災害を起こさない

バグの対応を行う時は、その対応が他の部分に影響が出ないかきちんと調査することも重要です。単にバグの発生箇所だけに目を向けていると、二次災害を引き起こしがちです。近視眼的にならず問題を俯瞰して修正を行う必要があります。その為に、コードレビューのフローやインテグレーションテストの環境を整備したり、仕様の整合性を意識したり、第三者の視野を借りたりすると良いと思います。

8. 解決策をレポートする

もし、バグの対応後に余裕があればレポートを作成すると、今後の対応がより迅速に行えることがあります。レポートでは、上記で紹介したようなポイントの対応をまとめてみたり、問題となったコードが対象範囲であったテストや設計などを確認してみたりして、今後同じバグを生み出さないために解決策をまとめると良いと思います。レポートとしてアウトプットすることで、バグを対応した経験の定着やプロジェクトへの貢献となることがあります。

以上、バグの対応ガイド【心構えとアプローチ】でした！
参考になれば幸いです。