●昨日の不思議
昨日、不思議な現象が起こったとかで、その原因を調べようとしましたが、皆目見当がつかない状況になっていました。
しかし、考えられるテストを行い、その結果から事実を積み重ねて、解決へと進むことが出来ました。
●教育不足
私の部下たちはまだまだなんやなぁって気がしました。
教え方がまずかったんだろうなぁ

部下たちに何が足らなかったかと言うと、プログラムを使っている現場の人たちが、何の関連もない別プログラムが変な動作をしたからと言って、同時期に改修したプログラムが原因ではないかと苦情を申し入れてきたことをそのまま鵜呑みにしてしまったことです。
現場の方の言う事を鵜呑みにしてはいけない・・・とまでは言っていません。
現場の方の言う事で、事実と推量を切り分けて聞き取りを行わなければならないと言う事です。
でなければ、原因追及をするうえで、要らぬ回り道をする羽目になってしまう・・・と言う事です。
●結局、原因は?
と、言う事で、今回の原因はマスターデータの不備によるものでした。
プログラムを改修した時に、ちょうどいいタイミングで別プログラムが不具合を発生しました。
その原因がマスターデータの不備にあったのですが、あまりにも絶妙なタイミングなので、現場の人は会衆プログラムが原因だろうと推量し、別プログラムの不具合を申し入れてきて、原因となる改修プログラムを元に戻してくれと言ってきていました。
●意地悪な不具合発生タイミング
そして、それを鵜呑みにした我が部下は、改修したプログラムを元にもどし、その後別プログラムを動作させると、その時はマスターデータの不具合を発生させる不備のあるレコードを使っていなかったので不具合が発生せず、さも改修プログラムを元に戻したから別プログラムの不具合が発生しなくなったと誤認したわけです。
これをもとに問題追及を始めたものですから、まず改修プログラムのどこに不具合の原因があるのか突き止めようとしましたが、もともと不具合の原因が無いのだから見つかるはずもありません。
そこからは泥沼です。
まずは、改修プログラムが原因でないことを証明するところから始めました。
本来はする必要のない工程でしたが

そして、別プログラムは改修していないのだから、そのプログラムのバグとは考えにくく、すると処理データか、アクセスするマスターデータのどれかに不備があるはずだと断定し、徹底的に調査させました。
すると1時間足らずで原因が特定でき、解決となりました。
●めでたしめでたし
今回のようなトラブルの原因追及は、論理的な思考が一番ゴールへの近道を見つけ出すことが出来る良い例でした。
1人1人の経験になればいいんですが・・・

【このカテゴリーの最新記事】
-
no image
-
no image
-
no image
-
no image
-
no image