【くまモビ】圏外の山奥でスタンプを押したら、そのデータはどこへ行くのか

自分のアプリの「弱点」に、自分で気づいてしまう瞬間があります。

昨日、大きな不具合を根本から直して、ほっとひと息ついていました。ところが今日、ふとした瞬間に背筋が冷たくなったのです。

——あれ？ 圏外でスタンプを押したら、その記録ってどうなってるんだ？

僕が開発している熊本の乗り換えアプリ「くまモビ」には、観光スポットをめぐるスタンプラリー機能があります。そして、このアプリの自慢は「オフラインでも動く」こと。阿蘇や天草の、電波の届かない山あいでも経路検索ができるように作ってあります。

でも、その自慢の裏側に、落とし穴が口を開けていました。今日はその発見から解決までの一日を書きます。「動いているように見えるものほど疑え」という、開発の教訓が詰まった一日でした。

この記事のポイント

1. 「動いているように見える」機能の裏で静かに消えていたデータの話
2. ユーザーに我慢させる解決策を選ばなかった理由
3. 「あとで送れるときに送る」仕組みの作り方と落とし穴

7分21秒でわかるまとめ動画

発見：スタンプは押せる。でも、記録は？

くまモビのスタンプラリーは、観光地の近くに行くとスタンプが押せる仕組みです。押した記録は2か所に保存されます。ひとつはスマホの中（だからオフラインでも押せる）。もうひとつはクラウド上のデータベース（どのスポットに何人来たか、という統計のため）。

スマホの中への保存は、オフラインでも当然できます。問題はクラウドへの送信です。圏外では届きようがない。

じゃあ、そのとき何が起きているのか。コードを確かめて、僕は固まりました。

失敗しても、何も言わずに握りつぶす作りになっていたのです。

ユーザーの画面ではスタンプがきれいに押されて、演出も鳴って、完璧に成功しているように見える。でも裏側では、クラウドへの送信がしれっと失敗して、記録はそのまま消えていました。エラー画面も出ない。ログに小さくつぶやくだけ。完全犯罪のような静かな失敗です。

もともとは「送信に失敗してもスタンプの楽しさを止めない」という善意の設計でした。その善意が、データを静かに看取る仕組みになっていたわけです。

最初に考えた案を、自分で却下した

まず頭に浮かんだのは、いちばん素直な案でした。

「スタンプを押すときに通信状態を調べて、オフラインだったら『オンラインにしてください』と促せばいいんじゃないか？」

作るのも簡単です。でも、想像してみました。阿蘇の山道を走って、やっとたどり着いた絶景スポット。旅行者がわくわくしながらスタンプを押そうとしたら、画面に「通信をオンにしてください」。

……興ざめです。

そもそも、くまモビは「オフラインでも動く」を看板にしたアプリです。経路検索は圏外でも動くのに、スタンプだけ「電波をよこせ」と言い出すのは、筋が通りません。しかも通信が必要な理由は、ユーザーのためではなく、運営側の統計のため。こちらの都合で、旅の一番いい瞬間を止めるのか？

答えはノーでした。この案は自分で却下しました。

選んだ答え：「あとで送れるときに、送る」

代わりに選んだのは、郵便ポストのような仕組みです。

圏外でスタンプが押されたら、送れなかった記録をスマホの中の「ポスト」にそっと入れておく。そして、アプリを次に起動したときや、バックグラウンドから戻ってきたときに、ポストの中身を確認して、電波があればまとめて投函する。

ユーザーは何も意識しなくていい。スタンプは今までどおり、圏外でも気持ちよく押せる。記録は、いつか必ず届く。誰にも我慢を強いない解決策です。

ただし、落とし穴が2つあった

作ってみると、この方式には見落としがちな罠が2つありました。

罠その1: 日付がズレる。

記録には「何月何日に訪問したか」が含まれます。ところが従来の作りでは、この日付を「送信する瞬間」に決めていました。つまり、7月26日に圏外でスタンプを押して、翌日27日に電波が戻って送信されると——記録上の訪問日は27日になってしまうのです。

これでは日別の統計が静かに狂います。対策として、日付はスタンプを押した瞬間に確定して、記録と一緒にポストに入れるようにしました。届くのが翌日でも、記録の中身は「26日に訪問」のまま。当たり前のようで、意識しないと必ず踏む罠です。

罠その2: 二重に数えてしまう。

実は、使っているクラウドのデータベースには「オフライン時の送信を自動で預かって、電波が戻ったら送っておいてくれる」機能がもともと備わっています。ありがたい機能ですが、これと自前のポストが両方動くと、同じ記録が2回届いて、訪問者数が水増しされてしまう。

そこで、ポストに入れるのは「送信がはっきり失敗したときだけ」に絞りました。「預かってもらえた」場合はポストには入れない。役割分担をはっきりさせることで、二重計上を防いでいます。

「見えない失敗」がいちばんこわい

昨日の記事で「直したはずのバグがぶり返す」ことの怖さを書きましたが、今日のは種類が違う怖さでした。

そもそも壊れていることに、誰も気づけない。

画面は完璧に動いている。エラーも出ない。でもデータは消えている。もし今日ふと疑問に思わなかったら、正式リリース後もずっと、山あいのスポットの訪問記録だけが静かに欠け続けていたはずです。「熊本市内は人気だけど阿蘇は全然ですね」なんて、間違った分析をしていたかもしれません。

派手にクラッシュするバグは、ある意味で親切です。ちゃんと「壊れてるぞ」と教えてくれるのだから。本当にこわいのは、成功しているふりをする失敗。自分のアプリの「うまく動いている画面」を、たまには疑ってみる。今日はそれを身をもって学びました。

圏外の山奥で押されたスタンプも、これからは麓に降りたとき、ちゃんと届きます。旅人には何も気づかせずに。それがいちばん、このアプリらしい直し方だと思っています。