ある習い事教室の、入退室のお知らせの仕組みを、数年前に作った。子どもが教室に着くと、タブレットで名前を押す。すると家族のスマホに、着きましたと届く。帰りも同じ。小さな仕組みだが、毎日使われている。
その仕組みが、少しずつ遅くなってきた。朝、タブレットで生徒の一覧を開くと、出てくるまでに一呼吸、長いときは数秒かかる。作った当初は一瞬だった。数年分の記録が溜まった今、その一瞬が、待ち時間に変わっていた。
なぜ、そこに表計算を使っていたか
最初、データの置き場にはクラウドの表計算を選んだ。理由ははっきりしている。オーナー自身が中身をそのまま見られるし、無料で始められる。行を一つ足せば生徒が一人増える。専用のデータベースを用意するより、ずっと手軽だった。
小さいうちは、この選び方で正しかったと思う。生徒が数十人、記録が数百行のうちは、何の不満もなく動いていた。手軽さは、立ち上げの時期にはそれ自体が価値だった。
便利さの裏で、少しずつ重くなる
引っかかりは、規模が育ってから出てきた。クラウドの表計算は、一覧を読むたびに、ネットの向こうまで取りに行く。行が増えるほど、その往復が重くなる。
数十行なら気づかない。けれど数百行、数年分となると、その重さが待ち時間としてはっきり顔を出す。仕組みは何も壊れていない。壊れていないのに遅い。器が、用途の大きさに合わなくなってきた、ということだった。
この重さは、ある日突然やってくるのではない。毎日ほんの少しずつ延びていく。だから気づきにくい。ふと、昔はもっと速かったな、と感じたときには、もう体感ではっきり分かるほどになっている。ゆっくり進む不便は、こうして見過ごされやすい。だから、気づいたそのときに手を打つと決めた。
「遅い」は、いつか信用を削る
入退室の記録は、その場ですぐ出てほしい。子どもが名前を押して、家族に届くまでの数秒。管理画面を開いて、今日の出席が見えるまでの数秒。短くても、その待ちは使う人の「本当に動いているのか」という小さな不安になる。
速さは、機能の一つだと考えている。遅くても動けばいい、とは思わない。毎日触るものだからこそ、待たせないことが、静かな信頼になる。だから、この遅さを放置しないことにした。
器だけを、入れ替えると決めた
やることは決まった。中身の作りや画面はそのままに、データの置き場だけを、表計算から本来のデータベースへ移す。使う人から見れば、何も変わらない。裏の器だけを、こっそり差し替える引っ越しだ。
引っ越しには、鉄則がある。荷物の中身を、勝手に変えないこと。次の回は、その引っ越しでいちばん大事にした約束、画面を一つも変えないという縛りについて書く。