管理画面を1つ開いて、見て、閉じて、次を開く。2日のあいだに、それを 600回やった。数えていたのは、合計が間違っている注文が何件あるかだ。数え終わる前に、数えた分から全体を見積もって、店主の方に「150件くらいです」と伝えた。本当は 38件だった。今日はその話を書く。
何が起きていたのかを先に書く。KAZENA Order では、客が自分の電話から注文して、注文はそのまま厨房に流れる。流れたあとで数量を変えられるようにしてある。3個と押してしまった客が店の人に言って、店の人が 2個に直す。そういう直しが、1日に何度か起きる。
その日の売上の合計が、変える前の数量を見ていた。注文の中には、最初に入った数量と、あとで変わった数量の2つが残っている。合計を出すところが、前のほうを読んでいた。だから直した注文があった日は、売上が多めに出る。そこを直すのは 2時間で済んだ。残ったのは、もう閉めてしまった日のほうだ。
店主の方に聞かれたのは2つだった。何件あるのか、合計でいくら多いのか。どちらも、過去を数えないと答えが出ない。私は管理画面を開いて、数え始めた。
数え方はこうだ。注文を1件開くと、変更の履歴が見える。数量が変わっているものを見つけて、その注文の合計がどちらの数量で出ているかを見る。1件に 15秒から 20秒かかる。3店ぶんで、2か月のあいだの注文は 5,120件あった。
2日で 600件まで見た。該当したのは 18件。600件で 18件なら、5,120件では 150件くらいになる。その足し算をして、電話でそう言った。数えた 600件と、数えていない 4,520件を、同じ口調で喋ったことになる。
読み取りで数え直した。注文と、数量の変更の履歴と、その日の合計を、1つの問いとしてまとめて読む。書くのに 1時間かかって、答えは 4秒で出た。38件、合計で 1,870ペソ多かった。目で数えるのに使った 2日は、この 1時間の前では何も生んでいない。その時はそう思った。
見積もりが 150件になった理由は、割合の計算ではなかった。該当する注文が、2か月のあいだに散らばっていなかったからだ。数量を変える操作を使っていたのは3店のうち1店で、しかもその店が集中して使ったのは、人の入りが多かった 6日間だった。私が開いた 600件は、新しいものから順に並んだ一覧の上のほうで、その 6日間はそこに入っていた。いちばん変わった週を見て、2か月を語った。
ただ、最初に書いた読み取りも間違っていた。1回目の答えは 212件だった。条件が、変更のあとでまた元の数量に戻された注文まで拾っていた。戻ったものは合計も合っているので、直すものではない。
それに気づけたのは、手で数えた 20件を控えてあったからだ。読み取りの答えと、その 20件を突き合わせたら、合わないものがあった。条件を直して 38件になり、もう一度突き合わせて、20件は全部一致した。目で数えた2日は、答えを出すためには無駄で、答えを確かめるためには要るものだった。
店主の方には、数を訂正する電話をかけた。150件と言ってから 3日後だ。多いほうに外していたので、相手は思ったより軽いという受け取り方をしてくれた。逆に外していたら、同じ電話はもっと重い。外したこと自体より、見積もった数を、確かめた数と同じ言い方で出したのが間違いだった。
変えたのは2つだ。1つは合計の読み先で、これは 2時間で終わっている。もう1つは、その問いを管理画面に置いたことだ。合計が合っていない注文を、日付と番号と差額で一覧に出す。店主の方が自分で開いて、自分で数えられる。今は 0件と出る。KAZENA 側のエンジニアにも渡した。同じ問いは向こうでも出るので、持っていけるのは、数を人に数えさせないという形のほうだ。
私が取り違えていたのは、数えるという作業が何のためにあるかだ。人が目で数えると、数えているあいだに規則が揺れる。200件目と 500件目で、履歴の読み方が同じだったとは言えない。そして数え終わらなければ、残りは推測になる。読み取りは、同じ問いに同じ答えを返す。何件あるかという問いは、人ではなくデータに向けるものだった。今は、その問いに私は口で答えない。画面を開いて、一緒に見る。