寿命が3日縮む

10日（木）

1月イベントその1の2日目。

新しい要素がなくもなく、取り扱うデータ数も増加はしたが、

OA室の業務内容としては例年通り。

午前中のデータ入力は問題なく終了。

午後も時間はかかったものの内容的には問題なし。

データ数が多かった影響で、集計レポートの印刷と提出は16時ちょうど。

その後のOA室での待ち時間は、

Iくんは別件の仕事を始め、

私は1月イベントその2のためのAccessの修正作業を開始。

17時半ころ、うちの部長がやってきて言った。

K：「このレポートのここの数字とここの数字がおかしいです。」

私：「…」

一緒に調べ始めた。

が、理由がわからない。

去年と大きく変わった部分はないと思うのに、なぜ数が合わないのだろう。

何十分かあれこれ調べたがわからない。

そのうちに、あの人とかこの人とかその人とか、いろんな人たちがOA室にやってきて、

あれがこうかも、それもおかしいかも、どれがどうなの

と、口々に言う。

部屋に来た人たちは私を責めているわけではないのだろうが、

私がパニックになり始めた。

かつて、

おかしい数字を修正することだけが私の仕事のすべてだった3年間があり、

私は心を病んだ。

今の状況はそれに近い。

とりあえず、いったん全員に部屋から出ていってもらい、

Iくんと2人だけでもう一度該当のレポートのデザインビューを確認し始めた。

該当のレポートにはテキストボックスが横にたくさん並んでいる。

そのそれぞれのコントロールソースは、

松山男C0、松山男C1、松山女C0、…

男の方はC0とC1がある。

女の方にはC0しかない。

Cはわかるけど、0とか1とかって何だったっけ？

!!

私はIくんに言った。

私：「これって、女の方にC1って、あったらダメだよね」

I：「そうですね。ありえないですね」

私：「でも、データ入力の時に間違えたまま気づいてなくて、女なのにC1になってるデータがあるんじゃないかなぁ」

クエリを作って調べてみた。

…!!

正解。

女なのにC1になっているデータが2件含まれていた。

このプログラムは、去年以前、ちゃんとまともに動作していた。

だから、変な現象が生じたとしても、それはプログラムではなくデータのほうがおかしいはず。

下手にプログラムをいじらなくてよかった。

時間はかなりロスして、会議の開始を遅らせてしまったが、原因ははっきりしたので、まあ良かった。

来年は同じことがおこらないように、チェック用クエリをさっそく作った。

その後もなんやかんや、関連の作業の確認や修正を2人でやって、

20:30終了。

20:40退勤。

疲れた。寿命が3日縮んだ。

まぁ、いつ死ぬかはわからないが、

いつ死ぬとしても、あれさえなければあと3年は長生きできたはずなので、

今さら3日縮んでも誤差の範囲内ではある。