エラーチェック

　エラーチェックというと、次のようなチェックを思い出す。

「存在チェック」「条件チェック」「範囲チェック」「関連チェック」「タイプチェック」

チェック方法は論理的であり算式や言葉で表現することが可能である。

　多くの「バグ」はこのチェックミスから始まり、その他の処理に感染していく。

間違った処理結果がお客様に届いて「大問題」となる。

「もっとチェックを厳しくしろ！」

上司は「お客様からのお叱り」のはけ口を「部下への罵倒」に求める。

チェックはさらに厳しくなり、いたる所で「チェック・チェック」

そして、チェック内容はプログラム仕様書に記載されない。

　このタイプの「上司」は「緊急プログラム変更」を発する回数が多い。

プログラム修正が入ると「本来の修正」よりもそれによって波及する「チェックロジックの変更」の方が大変な作業になることは珍しくない。

修正プログラムは実行するたびに知らない所（処理）でチェックに引っ掛かる。

「チェックをきびしくしろ！」と言った上司は、

「どこがそんなに大変な修正なんだ？」と疑いの目で見る。

　ある時、お客様のトップから呼び出された。

「今度ベテランの給与計算担当者が退職して、新人が担当する事になったんです」（お客様のトップ）

「とても心配で心配で・・・」

「チェックを厳しくしてミスが起きないようにできないでしょうか？」

「１０円を２０円と入力しても論理的チェックは正しいのでＯＫになります」（筆者）

「これ以上無理ですね」

「そこをなんとか考えてくれませんか？」（お客様のトップ）

お客様の要望は「論理的でないチェックをしてくれ！」と言うのである。

その場では「出来ない」と断ってはみたものの、筆者の心はスッキリしない。

しまいには夢の中にお客様が現れ、「そこをなんとか考えてくれませんか？」

そこで目を覚ます事、数回（己が小心者であることを実感）

　予想通りトラブルが続いた。

お客様は筆者を呼び出し「あなたが何も対処していないからだ！」と激怒。

そう言われても、どうしようもない。

　ところが、日曜日の朝刊のチラシを見てひらめいた。

整形手術の「手術前・手術後」の写真である。

「前月と今月の結果を比較すればいい！」

社員別に前月・今月の給与項目を上下に表示し、さらに前月データと異なっているデータを抽出するフィルタ機能を付加した。

前月と異なっているのは全てエラーではない。

しかし、作業担当者には「何か変だゾ？」という「感性」を呼び起こす。

「コノ人は今月あっちゃいけない手当だヨ」

「アレ、コノ人の手当は他の人と違っているヨ」

シロウトには真似が出来ない「ワザ」である。

作業ミスが「皆無」になったのは言うまでもない。

このプログラムは何もチェックしていない。