仮説を立てて検証せよ
先日、コンピュータシステムのユーザーから、インシデントが報告されました。
「あるデータベース項目(フラグ)の初期値はOnではなかったのか？そう思っていたから、確認せずにデータを確定してしまった。後になって、実際Offになっていることに気がついた。今後は毎回わざわざOnに変更しなければならないのか？」
という趣旨の報告でした。システムの仕様は、「初期値はOnとする」ということでしたので、欠陥の可能性がありました。早速私は、開発兼保守担当に、「事の真偽を明らかにせよ。」と命じました。
本来であれば、ユーザーに操作手順を明らかにしてもらい、再現性を報告してらうのが筋です。が、「覚えていない。」ということでしたので、「可能性を列挙し、このような結果を生んだ一番もっとらしい原因を推測せよ。」という指示を出しました。事実、そのような、「操作手順を忘れた。」という事例は良くあることです。不特定多数の人をターゲットとしたシステムなら別ですが、その操作を専門にしている人しか使わない基幹システムでは、ユーザーの「違和感」は割りと正確です。
数時間を与えて、報告してもらったところ、あまり納得のいかない調査報告が上がってきました。報告の骨子はこうです。
- 結論：機能Aの不具合。
- 調査内容
- 当項目に値を設定する可能性がある機能は、A,B,C,Dの４つである。
- Dのソースコードを確認したが、正しく機能していることを確認した。
- 機能Aを色々な条件で試してみたら、ある条件で同じ現象が起こることを確認した。以上■
これで本人は職責を全うしたと考えています。報告会に参加した新人君は、私同様、唖然とした顔をしています。もっと詳しく伝えてあげれば良かったと後悔しました。彼の調査を活かすとして、私が期待していた報告は、こんな感じです。
- 結論：機能Aの不具合の可能性が最も高い。
- この様な結果になりうる条件：某。
- 原因として考えうる可能性：初期値がOffとなるよう実装している、更新のタイミングで誤ってOffにしている、ユーザが自らOffに変更した、の三通り。
先の担当君の調査は、途中で終わっています。再現しただけで、原因は追求出来ていないからです。結果としては機能Aの不具合なのですが、不具合であると断定する根拠、処理不正がおこる条件、他に処理不正となりうるパスはないのか、など、全く分かりません。仮説を発見したのは素晴らしいことですが、それだけでは意味がありません。仮説を立てたら、それが正しいことを検証するプロセスが必要ですし、また、必要であると認識できていなければなりません。少なくとも、コンピュータプログラムのような融通の利かない、杓子定規のものを扱う人間には、そういうマインドがなければやっていけない、と私は考えます。
