トラブルから学ぶ

しかし、システムトラブルはなかなかなくならないものである。

今日も一つ発生した。

『改修したパラメータファイルをサーバーにアップして、クライアントがログインし直すと、そのファイルが各クライアント端末に一律に反映されるしくみ』があるのだが、担当のＳＥが古いバージョンのファイルに修正を加えたために、端末側のファイルが古いバージョンに戻ってしまい、不整合を起こして一部の機能が動かなくなってしまったのだ。

あきらかに人的ミスだ。
今回のトラブルの原因を解析すると、ざっと以下となる。

・クライアント側のファイルは部署毎に頻繁に書き換えられており、サーバー側のファイルとはかなりの乖離が発生していたこと

・クライアント側がサーバーからの自動配信のしくみを知らなかったこと

・担当ＳＥがそれを理解していなかったこと

・改修作業前に作業プロセスを明確に確認しなかったこと

いわば、コミュニケーション不足なのだが、各自が『当然そうなっているだろう』とか、『きっとこうしてくれるだろう』と思い込んでいると、なかなか発見できないのだ。

そう、思い込みは大敵なのだ。

では、どうしたらよいのか？

テスト項目表や手順書などマニュアルをきっちり作成し、プロセスをお互いにチェックできるように見える化すること。

それは、当たり前なのだが、究極には『猜疑心と気づきのアンテナを張り巡らす』しかないような気がする。

つまり、システムの検証に於いては、性悪説に乗っ取って何事も疑ってかかることだ。

自動車教習所に例えれば、「だろう運転」ではなく「かもしれない運転」である。

ショーンさん流にいうと、「ＴＶに向かって一人突っ込みを入れる」感覚だろうか。

これを繰り返し、習慣化して、陥り易く危なそうな箇所について、゛勘どころ゛を養う必要がある。

とにかく、トラブルや失敗には必ず原因があり、原因があれば対策もあるから、事前に予想できるのである。

あとは、トラブルが起きてしまった場合に、最悪のシナリオだけは絶対に避けるべきだ。

データのバックアップだけはしっかり取得しておきたい。

さて、今日の結論。

『当たり前のことを当たり前にやること。しかし、これを遵守することが一番難しいと認識すること』