プロローグ
それは、ある真夏の蒸し暑い日の事でした。
その日はひと気の少ないオフィスで、退職した前任者から引き継いだシステム(Rシステムと言います)の資料を確認したりと気怠い時間を過ごしていました。
私はその会社の情シスで社内SEをやっております。小さな会社なのでヘルプデスクやサポート専任者などはおらず、SEと言ってもユーザーサポートも受けるような立場です。
(あ、別にその事に不満はありませんよ?)
時刻は11時頃だったでしょうか... そこに、Rシステムのユーザーさんが心なし青い顔をしながら現れたのです。
ユーザー曰く...
ユーザーさん:Rシステムの年度集計の数字が、どうも合わないんだよね...
私は手元のPCでシステムの問題の画面を開き、別途資料に残されていた集計SQLを流して画面の数字と見比べてみました。
特に問題はないようです。
その事をユーザーさんに伝え、ユーザーさんPCでも一緒に問題がない事を確認しました。
ユーザーさん:変だなぁ...さっきは合わなかったんだよなぁ...
納得いかない感じでしたが今出ている数字で問題がないとの事なので、私は自席に引き上げました。
念のため年度集計のコードを眺めて動かしてみましたが、やはり問題なく動いています。
その日は釈然としない気持ちを抱きながらも帰途に就きました。
しかし次の日も...
同じような時分に昨日のユーザーさんが現れました。
ユーザーさん:やっぱり年度集計の数字、合わないんだよ...今度はスクショも取ったよ。
私は昨日同様、問題の画面と集計SQLの数字、スクショの数字を突合しました。
確かにスクショの数字だけが不足しています。
VisualStudioで問題のコードを表示します。
昨日も眺めましたが、まぁ端的に言ってク〇コードです。
必要な関数分離がされておらず不要な関数分離がされていて、まるでコードのジャングルを彷徨っている気分になります。
昨日も彷徨っておいたお陰で集計条件のコードに辿り着きました。
//期初から現在までのデータを集計
// 期間キーは西暦4桁+月2桁の計6桁
string where = "期間キー >= '"
+ nendoTextBox.Text + "'04' AND 期間キー <= '"
+ DateTime.Now.ToString("yyyymm") + "'";
//(where付けてSQL実行)
横で話を聞いていた情シス同僚登場
事情を聞いていた同僚さんも横からコードを覗き込みます。
3人の顔が、モニタに照らされて青白く染まっています。
そして暫くして...
同僚さん:あっ...!?
(ナレーション)
お気付きになっただろうか...(効果音:キャー...)
同僚が指をさした先は...
DateTime.Now.ToString("yyyymm")
同僚さん:日時形式文字列の"mm"は分の2桁表現、月の2桁表現は"MM"だね...
DateTime.Now.ToString("yyyyMM")
エピローグ
いやぁ~実に怖いですねぇ!
8月なら"2023/04~2023/08"で検索している積もりが
×時5分に検索すると"2023/04~2023/05"で検索していたなんて!
0~3分の間の検索結果は0件だったんだね!
×時ぴったりから数分間だけ発生する不具合とか、とってもサポート泣かせ!
そして数年の月日が流れ、Rシステムは新しいシステムにリプレースされました。
新システムではプログラマ(=私です)が直接日時形式文字列を書かなくて良いようにToYearMonthString()のような拡張メソッドを整備、同じ惨劇を繰り返さないように対策が打たれました。
しかしRシステムは過去データ参照用に今もひっそりと動いています。
いつ新たな惨劇が襲いかかって来るのか判りません。
果たしていつか、私がこの恐怖から逃れられる日は訪れるのでしょうか...
蛇足
この物語は実話を基にしたフィクションです。
Rシステムは実在しますが、新システムに移行した今はそんなに恐怖に怯えてはいません(エピローグ盛りました...)
皆様もホラーエピソード、是非投稿してみて下さい!