朝 6時半に店を開けるところがある。テストに付き合ってくれている店の1つで、通りに面した小さな売り場だ。開店から 8時までのあいだに、だいたい 40件の会計がある。その 40件は、2か月のあいだずっと、前の日の売上として数えられていた。
KAZENA Order はレジだ。日次の締めがある。店を閉めるとき、その日の会計を合計して、手元の現金と突き合わせる。画面の見出しには「今日の売上」と出る。その見出しの「今日」が誰の今日なのかを、私は決めていなかった。
サーバは UTC で動いている。こちらは UTC+8 だ。だから現地の 0:00 から 8:00 までは、サーバの暦ではまだ前の日になる。開店が 6時半の店なら、6時半から 8時までの 90分が、毎日そのまま前の日に落ちる。
気づいたのは店のほうが先だった。閉めたあと、レジの合計を紙の帳面に写してから金庫を閉める習慣がある。2週間で、合わないと言われた日が 9日あった。差額はいつも朝の分で、足してみるとぴったり朝の会計と同じだった。
私は時刻の表示を一度直したことがある。画面に出る時刻は現地時間に直していて、レシートにも正しい時刻が出ていた。だから表示は正しく見えていた。直していなかったのは、日付をどこで切るかのほうだ。見えるところを直して、数えるところを置いていった。
もっと静かに効いていたのは月の締めだった。月が替わる日の朝の会計が、前の月の合計に入る。10月1日の朝に売れたものが、9月の数字を動かす。月に一度だけ、合計がわずかに動く。見ていて気持ちのいいものではなかった。
直しの芯は、2つのものを分けて持つことだった。会計の時刻は、どこから見ても同じ1つの瞬間として保存する。それとは別に、その会計がどの営業日のものかを、店の時間帯で切った暦日として持つ。合計は後ろのほうだけを見る。
分けてみると、もうひとつ出てきた。店によって「1日」の終わりが違う。深夜 1時まで開けている店は、0時を過ぎた分を前の日の売上として数えたい。だから営業日の始まりを店ごとに設定できるようにした。既定は 0:00 で、0:00 から 6:00 のあいだで選べる。
すでにある記録は数え直した。7か月分で、会計は 23,400件ほどある。営業日が動いたのは 1,880件、日次の合計が動いた日は 142日あった。金額が変わった会計は 0件だ。どの日に属するかだけが変わった。
数え直したあと、店の紙と画面をもう一度突き合わせてもらった。次の 2週間で、合わないと言われた日は 0日になった。朝の分が朝の日に入るようになっただけで、店の手順は何も変えていない。
学んだことを1つの文にすると、瞬間は世界のもので、暦日は場所のものだ、ということになる。瞬間はどこから見ても同じ瞬間だが、それが何日なのかは、見ている場所が決める。ソフトはこの2つを1つの値で持っていて、1つの値が持てるはずのないものを持っていた。
KAZENA 側のエンジニアにも送った。向こうは UTC+7 で、ずれ方がこちらと1時間ちがう。同じ処理で両方そろうから、営業日の設定もそのまま使えるという返事だった。1つの製品を国をまたいで使うなら、こういう形の間違いは 1か所で直すほうが安い。
半日で終わると見積もって、5日かかった。日付の切り方を替えるのは 2時間で済んだ。残りは、7か月分を数え直し、営業日の始まりを店ごとに入れ、動いた 142日の数字を店と一緒に見る時間だった。見積もりを外した理由は、以前に表示を直したという記憶そのものだったと思う。一度さわった場所は、もう直っていると思い込む。