本当に辛い。再現性が低い不具合の調査と対策方針

2020-05-14ソフトウェア開発

この記事は組み込みソフトの開発/設計/テストに関わっている人向けのものです。

「再現性の低い不具合が発生してしまった。できるだけ早く原因を特定して、対策したいと思っているけど、調査が進まない。どうすればいいだろうか？」  

再現性が低い、または、全くない不具合の対策は非常に苦しい仕事ですよね。そういう不具合に限って、ユーザーを困らせるクリティカルなものだったりします。

僕もこれまでの業務で何度か遭遇し、大変な思いをしながら対策をしてきました。その経験から、再現性が低い不具合が厄介な理由と、原因調査の進め方を紹介したいと思います。この方法が一番であるとは言えませんが、誰かの参考になれば嬉しいです。

この記事には次のことを書きました。

何故、再現性の低い不具合が問題になるのか？

先ず、再現性が低い、または、再現しない不具合が厄介な理由を三つ紹介します。

原因調査が進まない

不具合発生時のログ情報から原因が推定できたり、自分たちの環境で同じ不具合を発生させて原因を絞り込むことができたりすれば、対策を完了させるところまでスムーズに進めることができます。

不具合が再現しないため、ログ情報から根本原因が分からない場合、問題がありそうなおおよそしか特定できません。

もし、ロジックにミスがあったとしたら、再現性は高くなるはずなので、ロジックそのものにミスがある可能性は低いです。

原因は何なのか？様々な状況を推定して、不具合に繋がるか検証しなければならなくなってしまます。

対策効果が確認できない

もし原因が分かって対策を行ったとします。

本当に対策できているのか確認したくても、不具合が再現しないため、効果を検証することができない問題が出てきます。

「原因は分かりました。対策も行いました。きっと不具合は出ないはずです」

このような説明をしても納得できる人はいないですよね？きっと？はず？ちゃんと確認してくれよ！とツッコまれるだけです。

「不具合が発生する場合はXXXな状態に陥りますが、対策後はXXXな状態に陥ることはありません。この資料にある通り効果を確認しています」

対策の効果確認を済ませてから、対策できましたと報告したいですよね。

状況を説明できない

不具合が出せず様々な状況を推定した、対策効果が確認できないがソースコードを見る限り問題は無い、この様な状況を他部署に説明するのは非常に難しいです。

原因調査や対策を直接行っているのであれば、曖昧さは含んでいるものの、信頼できる状態にしていると理解できるかもしれませんが、中身がブラックボックスにしか見えない人にとっては怪しさ満点なわけです。

製品の品質を取り扱う部門や営業部門に納得してもらうためにたくさんの説明資料を準備しなければいけなくなってしまいます。それで納得してもらえない場合は考えたくないですね。

再現性の低い不具合の調査方法について

もし再現性の低い不具合が発生してしまったとして、僕が担当するなら、どのように調査をしていくのか？その方針を紹介します。

できるだけ多くの情報を集める

再現性が低い時/高い時どちらであっても関係ないのですが、不具合の調査に取り掛かるときは最初に情報収集を行います。

自分の担当領域に関係ある情報、関係の無い情報、両方とも集めます。たまに、現場の判断で「不具合と関係のありそうな情報だけを抜き取りました」とレポートされることがありますが、必要な情報がこぼれてしまう可能性があるので、僕は取れる情報は全て持ち帰ってくださいとお願いしています。

もし、必要な情報がこぼれていることが分かり、再び情報を収集することになると、たくさんの時間をロスしてしまうので、取りこぼしだけはしないように注意したいですね。

関係しない部分を切り離していく

情報を集めきったら、明らかに不具合と関係のない領域を切り離していきます。怪しいところを抽出するためには、細かいところまでチェックする必要があるので、関係のないところをそぎ落としていく方が楽です。

「残った部分はどれも不具合と関係がありそうだ」とう状態になっていれば、調査は順調に進められていると僕は感じます。

実際は「関係あるかないかよく分からないけど、怪しいから切り離さないでおこう」という部分がたくさん残ってしまう場合が多いので、普段からログに情報をしっかり残しておくようにしましょう。

万が一の状況を考えてみる

怪しそうなところばかりが残っているので、ここからは各領域の担当者たちが並列に調査すると効率的です。

ロジックのミスでない可能性が高いので、普段では考えられない状況が発生した場合を考えて、原因箇所を探っていきます。

メモリ取得に失敗した、デバイス/ストレージにアクセス出来なくなった、通信に失敗した、動作タイミングが普段と大きくずれた、関数呼び出しから長い時間戻ってこなかった等、様々な状況について検討していきます。

不具合担当者以外の意見を募る

万が一の状況が発生する場合を考えるためには、これまでの経験が大切になってきます。

経験不足だと感じる時には、過去の事例や他所で起こった不具合を参考にしてもよいと思います。

資料に残っているということは、原因調査や対策に苦労したものが多いはずですから、参考にできる情報が載っているかもしれません。

自分の手を動かしてみる

様々な状況を想定して調査してみても、原因にたどり着かない状況が続く時は自分の手を動かして、不具合が起こった時と同じ操作、類似の操作をやってみるもの一つの手です。

不具合が再現性しないと言われていたけれど、自分で手を動かしてみたら、再現できてしまったという経験を何度かしてきました。

とにかく回数をこなしたり、不具合発生時とは少し違った操作をしてみた等です。

まとめ

再現性の低い不具合に対する、調査方法の一例について紹介しました。

再現性の低い不具合は粘り強く調査を行っていくことが大切なので、進展なしの日が続いたとしても、めげずに調査・対策を継続していきたいですね。