事務所から送ったメールに、ファイルが1つ付いていた。私が作った表計算のひな形で、列は7つある。日付、摘要、勘定科目コード、借方、貸方、相手先、参照番号だ。Books に帳簿を移してもらうために用意したもので、2か月のあいだに九人の方に送った。今日書くのは、そのファイルが最初の罠だったという話だ。
誰も白紙から始めない。Books を使い始める方は、たいてい1年か2年ぶんの記録を表計算で持っている。それを手で打ち直させるわけにはいかないので、読み込みの機能を用意して、入れてほしい形をひな形にして配った。形をこちらが決めるのだから、こちらが安全な形にできる。そう考えていた。
日付の列には、見本として 2026-01-05 と打ってある。列の書式は何も指定していない。年、月、日の順に並べる書き方なら、誰が見ても読み方は1つしかない。だからそれ以上は何もしなかった。ひな形の仕事は終わった、と思っていた。
表計算のソフトは、そこに入っているものを日付として扱う。日付として扱ったものは、その機械の設定どおりに表示する。こちらで使われている機械は月/日/年が多くて、日/月/年のものもある。そして CSV として保存すると、画面に見えていたとおりの文字が書き出される。2026-01-05 が 1/5/2026 になって出てくる。ソフトは余計なことをしていない。それがそのソフトの仕事だ。
我々の読み込みは、yyyy-mm-dd と yyyy/mm/dd の2つだけを日付として受け取るようにしてあった。1/5/2026 はどちらでもない。読めない日付の行を、読み込みは落とした。拒否して止まるのではなく、黙って落として先に進んだ。そのうえで画面に「1,336行を読み込みました」と出した。
この画面は、入ったものだけを数えている。入らなかったものは、どこにも数えられていない。だから行が落ちたファイルは、画面の上では、最初から行数の少ないファイルと同じ顔をしている。読み込んだ本人も、こちらも、数が足りないことを知る手がかりを何も持たない。
見つけたのは我々ではない。使い始めて 3か月目に、仕入先の残高を突き合わせていた方が、103,250ペソ足りないことに気づいた。その日に元のファイルを見せてもらった。行は 1,412行あった。読み込みの画面に残っていた数は 1,336行だった。76行が、エラーにもならずに消えていた。
ファイルが丸ごと落ちなかった理由は、行の作り方が2通りあったからだ。古いファイルから貼り付けた行は、文字として貼られて、その列は日付の列にならなかった。だから 2026-01-05 のまま残った。そのあとに手で打ち足した行は、日付として扱われて、月/日/年に変わった。落ちていたのは、手で入力した行だった。
ここが効いた。まとめて貼るのは古い履歴で、手で打ち足すのは直近の月だ。九人ぶんを数え直すと、入れた行は合わせて 11,200行、落ちていた行は 418行あった。そのうち 356行が、それぞれのファイルの直近 3か月に入っている。消えていたのは、いちばん新しくて、いちばん突き合わせに使う部分だった。
直しは2つに分けた。読み込みのほうは、落とすのをやめた。読めない行が1行でもあれば、そのファイルは何も入らない。画面には、ファイルにある行数と受け取った行数を必ず並べて出す。読めなかった行については、何行目か、その欄に何と書いてあったかを、書いてあったままの文字で出す。
ひな形のほうは、日付の列を文字として持つように変えて、見本の行も文字で入れ、見出しの下に書式を書いた。ただ、これで安全になったとは書けない。配ったファイルは、開かれた時点でこちらのものではない。表計算のソフトは、こちらが何を意図したかを知らないまま、そのソフトの仕事をする。規則を、配ってしまったファイルの側に置くことはできない。
私が取り違えていたのはそこだ。入れてほしい形はひな形で決めて、読み込みはその形が来るものとして書いた。形を決める場所と、形を確かめる場所を、同じものだと思っていた。確かめる場所は、データが届く側にしか置けない。ひな形にできるのは、間違いを起こりにくくすることまでで、起きていないことの保証ではない。
半日で終わると見積もって、6日かかった。読み込みを止まるようにするのは 2時間だ。残りは、九人ぶんの元のファイルをもう一度もらって、落ちていた 418行を入れ直す時間だった。二人は配ったあとで元のファイルを書き換えていたので、どの行が入っていないかを一緒に1行ずつ見た。あれから読み込みが丸ごと止めたファイルは 31件ある。黙って落ちた行は 0行だ。KAZENA 側のエンジニアにも送ったら、同じひな形を使っていて、列の書式を文字に変えたという返事が来た。