月曜の朝、会計士の方から短いメッセージが届いた。同じ請求書に番号が2つある、と書いてあった。添付されていたのは画面の写真で、一覧に出ている番号と、PDF に印刷された番号が違っていた。
番号の作り方は決めてある。支店のコード、年、そして連番。連番は年が変わったところで 1 に戻る。紙に書けば一行で済む規則で、実際、仕様書でも一行だった。
ところがその一行が、ソフトの中では2か所に書かれていた。1つは伝票を保存するところ。もう1つは一覧と CSV を組み立てるところ。前者は組み立てた番号をそのまま持っていて、後者は毎回、部品から組み直していた。
先月、書類の種類を分けるために、番号の真ん中に2文字の記号を足した。私が直したのは保存するほうだけだった。一覧のほうは、足す前の規則のまま動き続けた。
エラーは出ない。どちらの番号も、形としては正しいからだ。片方は新しい規則で、片方は古い規則で、どちらも同じ自信で表示される。気づいたのは会計士の方で、6日後だった。
影響していたのは 43件。金額そのものは合っていて、ずれていたのは番号だけだった。それでも、番号がずれた請求書は照合できない。会計の仕事は、金額を見るより先に番号で並ぶ。
直しはじめて、もっと悪いものを見つけた。連番を 1 に戻す規則も2か所にあった。保存するところは年で戻していて、抜け番を埋める夜間の処理は戻していなかった。今年はまだその処理が動いていなかっただけの話で、運が良かった。
直し方は2つあった。2か所を両方直すか、2か所を1か所にするか。前者は 30分、後者は2日かかる。1回目はたいてい 30分のほうを選びたくなる。今回は2日のほうにした。番号を作る場所を1つにして、一覧はそこが作った番号を読むだけにした。
言い訳をひとつも書けない類の失敗だ。同じ規則が2か所にあることは、置いた本人なので知っていた。知っていて、そのときは急いでいた。何を急いでいたのかは、もう覚えていない。
KAZENA 側のエンジニアに経緯を送ったら、同じ形をした場所がもうひとつある、と返ってきた。領収書の番号だ。こちらではまだ症状が出ていないが、出るのを待つ理由はない。今週、そちらも1か所にまとめる。
規則が2か所にあるあいだは、どちらが本物かを人間が覚えていないといけない。人間は覚えていない。私は3週間で忘れた。ソフトのほうは忘れないかわりに、古いほうを忠実に実行し続ける。
事務所の壁に、いま「この値はどこで作られるか」と書いた紙を貼っている。増やしたい類の紙ではないが、43件を照合し直した週の記念に、しばらく貼っておくつもりだ。