![見出し画像](https://assets.st-note.com/production/uploads/images/144570939/rectangle_large_type_2_a2afb80fffb2d7eb2dc5a6aa81fe5f16.png?width=1200)
不具合調査の心得 効率アップのために押さえるべきポイント
みなさんこんにちは!ワンキャリアでテックリードをしています、宇田川(X:@Ryoheiengineer)です!
直近、新卒メンバーの不具合調査をサポートする機会があり、その際に調査方法をもっと効率的にできるのではないかと感じました。
せっかくの機会なので、この記事を通じて私が不具合調査時に意識しているポイントを共有したいと思います。
不具合調査時だけではなく実装時にも通じる考え方ですので、ぜひご一読ください。
不具合調査とは?
不具合調査とは、システムに発生した問題や欠陥を調査して原因を探るプロセスのことです。
エンジニアであれば、日常的に不具合の調査に取り組んでいるのではないでしょうか。調査方法を間違えると、時間がかかってしまうことも多いでしょう。私自身も初めの頃は、なかなか解決に至らず、時間を費やしてしまうことが何度もありました。
最近では、そうした経験を踏まえて、少しずつ効率的に不具合を調査できるようになってきました。そこで、私が不具合調査の際に心がけていることをいくつか共有させていただきます。
私が意識していることは3つです。
事実と仮説を整理する
最短経路で仮説を確かめる
確認したことを記録する
意識していること1: 事実と仮説を整理する
不具合調査の依頼が来たときに、まずやるべきことは何でしょうか?
私が最初に取り組むのは、事実と仮説を整理することです。
事実とは、実際に起こっていることを指します。具体的な現象や状況を正確に把握することで、問題の全体像を明確にします。
一方、仮説とは、まだ証明されていないものの、ある現象を説明するために立てられた仮定のことです。仮説を立てることで、検証するべきことは何かがきまります。
では、事例を元に事実と仮説を整理する方法を見ていきましょう!
![](https://assets.st-note.com/img/1718785705335-zDih98pXZ1.png?width=1200)
![](https://assets.st-note.com/img/1718785705367-XHyeEOdAdS.png?width=1200)
ここでの事実と仮説はなんでしょうか??
ここで重要なのは、事実を正確に見極めることです。
単に「ファイルアップロード時に403エラーが出た」とするのではなく、「社員が10:30頃にファイルをアップロードした際に403エラーが発生した」という事実を正確に捉えることが大切です。
このような細かな違いを見逃すと、誤った仮説を立ててしまい、問題解決のスピードが遅くなる可能性があります。
事実と仮説を整理したあとは何をするべきでしょうか?
意識していること2: 最短経路で仮説を確かめる
事実と仮説を整理した次にすべきことは、仮説を確かめることです。
ここで大切になってくるポイントが以下の2つです。
一番確率が高い仮説から確認すること
確認コストが低い方法を選択すること
特に「2.確認コストが低い方法を選択すること」はすごく重要です。
確認方法を誤ると、時間が無駄に消費されてしまう可能性があります。確認方法の選択肢を広げるためにも、使用しているツールやその使い方をしっかり把握しておきましょう。適切なツールを効果的に活用することで、迅速かつ正確に仮説を検証できます。
では、事例を元に最短経路で仮説を確かめてみましょう。
![](https://assets.st-note.com/img/1718785783742-CANPOWVyHC.png?width=1200)
今回は仮説の一つである「ファイルアップロード機能が壊れてる?」を検証していきましょう。仮説を検証するための最速の方法は何でしょうか?
私の場合、まずSentry(エラー監視ツール)を確認し、その後ローカル環境で再現できるかを確認します。
今回の検証結果では、Sentryにエラーメッセージは通知されておらず、ローカル環境でも同じエラーを再現することはできませんでした。
意識していること3: 確認したことを記録する
仮説を検証した後は、仮説で検証した内容を記録しましょう。
記録する目的は主に以下の2つです。
事実と仮説を再整理するため
他の人に何をやったかを説明できるようにするため
特に2つ目の目的は非常に重要です。検証の記録があると、他の人がサポートに入ったときに迅速にキャッチアップでき、その後の調査を効率的に進めることができます。
では、何を記録すべきか?私は以下の内容を記録しています。
仮説の検証結果からわかった事実と、そこから立てられる新たな仮説
仮説の検証方法
使ったツールのURL
検索時に使ったクエリ
仮説の検証方法を記録することは、多くの人が見落としがちですが必ず実施したほうがよいです。検証方法が間違っている場合に、他の人がそのミスに気づきやすくなるためです。これらの記録を丁寧に行うことで、問題解決のスピードが向上し、精度も高まります。
おわりに
事例の原因はシステムの不具合ではなく、AWS WAFの誤検知でした。
GenericLFI_BODYルールがファイル内のランダムな文字列に反応し、攻撃と誤認するケースがあるようです。一時的にWAFの該当ルールを解除することで問題を解決しました。
今回は不具合調査で意識している以下の3つのことを事例を用いて、紹介しました。
事実と仮説を整理する
最短経路で仮説を確かめる
確認したことを記録する
実装で詰まったときも、このような意識を持つことで解決スピードが上がります。
この記事を読んだことで、皆さんの不具合調査の時間が少しでも短くなることを願っています。ご一読いただき、ありがとうございました。
▼ワンキャリアのエンジニア組織のことを知りたい方はまずこちら
▼カジュアル面談を希望の方はこちら
▼エンジニア求人票