【不具合調査で考えていること】第5回：原因を一つに決めつけず、仮説を立てて確認する

不具合の原因になりそうな箇所を見つけると
「きっと、ここが原因だろう」
と考えたくなります。

経験から原因を予想することは、調査を進めるうえで役立ちます。

しかし、最初に思いついた原因が正しいとは限りません。
一つの原因に決めつけず、複数の仮説を立てて確認することが大切です。

同じ現象でも、原因は一つとは限らない

たとえば、保存ボタンを押しても完了画面へ進まない不具合が発生したとします。

この現象からは、次のような原因が考えられます。

• 入力データに問題があった

• 保存処理でエラーが発生した

• データベースへの登録に時間がかかった

• 外部システムから応答が返らなかった

• 保存後の画面更新に失敗した

• 同じボタンが続けて押された

画面だけを見れば、どの原因でも「完了画面へ進まない」という同じ現象になる可能性があります。

最初に見つけたエラーログだけを原因だと考えると、それ以外の可能性を見落とすことがあります。

事実をもとに仮説を立てる

思いつく原因を無制限に挙げればよいわけではありません。
これまでに確認できた事実をもとに、可能性のある原因を考えます。

たとえば、次の事実が確認できたとします。

• 保存ボタンを押した記録がある

• データベースにはデータが登録されている

• 保存処理のエラーは記録されていない

• 完了画面を表示した記録がない

この場合、保存処理そのものよりも、保存後の画面更新で問題が起きた可能性が高そうです。

ただし、この時点ではまだ仮説です。

「保存後の画面更新に失敗した」と断定するのではなく、追加のログや再現確認によって確かめます。

仮説ごとに確認方法を決める

仮説を立てたら、それが正しいかを判断するために何を確認するのかを決めます。

• 入力データが原因なら、同じデータで再現するか

• 利用者の権限が原因なら、別の権限ではどうなるか

• 通信が原因なら、通信ログに失敗や遅延がないか

• 画面更新が原因なら、処理完了後の動作がどこまで実行されたか

このように仮説と確認方法を組み合わせると、ただログを眺め続けるよりも、調査の目的が明確になります。

確認した結果、仮説と合わなければ、その可能性を下げるか、別の仮説へ切り替えます。

仮説に合わない情報が出てきたときに、無理に説明をつけて最初の考えを維持しないことも重要です。

可能性の高いものから確認する

すべての仮説を同時に調べるのは難しいため、順番を決めます。
主に、次の点を見て優先順位を考えます。

• 確認できた事実と合っているか

• 過去に同じような事例があったか

• 短時間で確認できるか

• 影響が大きく、先に確認すべきものか

可能性が高いものだけでなく、影響が大きいものを優先する場合もあります。

たとえば、データの欠損や二重登録につながる可能性があれば、発生確率が低そうでも早めに確認する必要があります。

まとめ

不具合調査では、経験から原因を予想することが役立ちます。

ただし、その予想を最初から答えとして扱うと、ほかの可能性を見落とすことがあります。

• 確認できた事実から複数の仮説を立てる

• 仮説ごとに確認方法を決める

• 可能性や影響を考えて確認する順番を決める

• 結果が仮説と合わなければ見直す

原因を当てにいくのではなく、仮説を一つずつ確かめながら可能性を絞っていく。

それが、思い込みに引っ張られずに不具合調査を進めるために大切なことだと考えています。

おすすめの一冊

既存コードの動作を確認し、安全に修正する考え方を学ぶなら、マイケル・C・フェザーズ著の『レガシーコード改善ガイド』が参考になります。

Kindle Unlimitedなら無料で読める本も

対象の技術書であれば、Kindle Unlimitedなら追加料金なしで読めます。

まだ利用したことがない方は、初回30日間無料体験もあるので、この機会に試してみるのもおすすめです。

※対象書籍は時期によって変わるため、利用前にご確認ください。

※上記はAmazonアソシエイトを利用しています。