原因調査の手順

はじめに

開発したシステムに対して「項目Xの値が10なのはなぜですか？」という問い合わせや、「テスト結果の検証や不具合調査をする際に。こうしたらよいかもという段取りをまとめてみました。

1. 状況を確認する

確認内容の意図を把握する

「項目Xの値が10なのはなぜですか？」という問い合わせは

• 単純になぜその値になるのかを知りたい。
• 10 ではなく20になるはず。
• 10 になった結果、やりたい作業ができない。

など、様々です。特に３つめのは、項目Xの値が10になることを調査しなくても、やりたい作業ができるようになれば解決します。逆に、項目Xの値が10になる理由が分かっても、やりたい作業ができなければ解決にはなりません。

仕様を確認する

正解が分からない状態で調査しても事実が分かるだけで解決しない場合があります。また、「こうなるはずだ」の思い込みで調査をするのは間違った結果につながる恐れがあり危険です。

前提条件を確認する

「IEでは動作を保証していないのにIEで動かしている」とか「ゲストユーザーでログインしている」とか、そもそもの前提がダメだからできないということが多々あります。
「それ早く言ってよ」とこちらは思うのですが、問い合わせている方は、いつもやっていることなので「そんなの当たり前じゃん」の一言で済まします。

２．データを調査する

結果に影響を与える全てのデータを確認する

源泉となるデータ、条件となるデータなど、結果に影響を与える全てのデータの状態を１つずつ確認していきます。ここで重要なのは、「結果に与える全ての値」が「事実としてどのような状態になっているか」を確認することです。
調査の途中で想定と異なる値が見つかっても、まずは全ての値がどうなっているかを確認してください。想定が間違っていることもあります。思い込みで調査をすると深みにハマると抜け出せなくなります。「こうなっているはず」ではなく「こうなっている」という事実の部分を明確にしてください。

同じように想定と異なっているデータを探す

DBに登録されているデータであるならば、同じように想定と異なっているデータを探します。そして、そのデータに共通点がないかを探します。

• 同じユーザから登録されているデータ
• 同じ条件値のデータ　など

また、これらのデータを想定通りになっているデータと比較することで、どのような条件のデータが想定通りになっていないかを予測できないか検討します。

設定されたタイミングを確認する

不具合が起きた時と現時点では値が変化していることがあります。現時点のデータの状態では想定通りの結果になるが、不具合が起きた時点では、異なる結果になる場合があります。

• 不具合が起きた時は、設定Aの値は別の値だった。
• 不具合が起きた時は、影響を与えるデータが存在していなかった。

ログやバックアップ、データに更新日、更新者、更新機能といった項目を記録している場合もあるので、これらを有効活用しましょう。また、調査を開始するまでの間に他のプログラムが値を変えている可能性がないかも考慮しましょう。

他に結果を影響を与えているデータがないかを確認する

「設定Bがされている場合は、設定Aの値に関係なく項目Aの値は10になる」といった自分が知らない仕様がないかを確認しましょう。仕様書にない後付けルールは意外と多かったりします。

有識者に聞くかプログラムを追う、場合によっては議事録を漁らないと分からない内容ですが、可能性として考慮する必要はあります。お客さんのシステム担当者に聞くと「そういえば、追加要望で特別ルール追加されてますよ」みたいな回答が返ってくることもあります。

３．プログラムを調査する

想定通りに動いているか確認する

プログラムを追えば、なぜそうなっているかは確実に分かります。
但し、検証環境で再現させるまでが大変だったりするので、デバッグ実行での調査は最終手段とした方がよいと思います。デバック実行するにしても、それ以前に仕様の把握やデータの状況を確認しておけば調査はスムーズに進みます。

ここで注意が必要なのは、プログラムの結果は事実であって、想定通りの動作をしていなくてもバグとは限りません。運用直後はともかく、一定期間稼働しているシステムは、その動作で運用が回っています。仕様書のメンテが追い付いていないだけで、何らかの理由で現在の動作をしている可能性も十分考えられるため、安易に修正すると二次災害を招くことになります。

おわりに

調査は、結果が分かってしまえば大した原因でないけれど、その結果を見つける観点に気づかなかったばっかりに膨大な時間を費やすことが多々あります。みなさんの「調査の際の勘所」があれば、ぜひともコメントよろしくお願いします。