支店を出すたびに、本店の中身が漏れてきた — 同じコードから別のアプリを作って2か月で7回踏んだ混線 — 制作日誌 #30

同じ生地から、パンと饅頭を作るように、1つのアプリのコードから別のアプリを作っている。

元になっているのは、自分で作って公開しているタスク管理アプリ「the task」だ。ここからカレンダー専用の「THE CALENDAR」、経路検索の「the route」、推し活の「THE OSHI」を出した。画面の部品、ログイン、同期、通知の仕組みは全部共通で、どのアプリとして組み立てるかを1つの切り替えで選ぶ。

作るのは速い。経路検索のアプリは、ゼロから書けば数か月かかる部品を最初から全部持っていた。

その代わりに払ったのが、この記事の中身だ。7月末から9月末までの2か月で、本家の中身が別のアプリへ漏れ出す事故を7回記録した。

例えで言うと

本店のレシピ帳を丸ごと写して、支店を出したと思ってほしい。

レシピ帳を写すと、本店でしか意味のない書き込みまで一緒に写る。付箋で「この支店では出さない」と断っていても、付箋は付けた支店の分しか無い。3軒目を出した瞬間、3軒目には付箋が1枚も無い。

そして予約台帳は、支店と本店で共通だ。同じ人が両方の店を使うので、支店のレジからも本店の予約が見えてしまう。

7回の記録

並べると、症状はばらばらだ。画面に出た、データが増えた、道具が本家を指した、通知が鳴った。けれど追いかけてみると、原因の形は3つしかなかった。

型1：名指しで逃がす分岐は、3つ目を素通りさせる

8月17日の件で、原因の書き方がはっきり見えた。ホーム画面を決める部分は、言葉にするとこうなっていた。

カレンダーのアプリなら、カレンダー画面へ飛ばす。それ以外なら、タスク一覧を出す。

2つしかアプリが無かった頃は、これで正しかった。経路検索のアプリは「それ以外」に落ちて、タスク一覧を描いた。7月30日にカレンダーのアプリで同じ症状を直したときも、直したのはカレンダーを名指しで逃がすことだったので、3つ目のアプリは守られなかった。

同じ書き方を数えると、カレンダーの名指しだけで17か所以上あった。設定画面に5か所、最初の案内、使い方ガイド、更新を促す画面、ほかにも散らばっていた。

厄介なのは、壊れ方が静かなことだ。組み立ては通る。型の検査も通る。起動もする。気づけるのは、実機で開いた人間だけだった。

特に重かったのは2つある。1つは最初の案内で、経路検索のアプリを初めて開いた人は全員、タスク管理の説明を9枚めくらされる状態だった。もう1つは使い方の案内で、指し示す対象が画面に無いので暗幕がかかったまま固まる上に、例としてタスクを勝手に1件作る作りになっていた。

直し方は、条件を反転させることだった。

the task の時だけ、タスク一覧を出す。それ以外は、そのアプリのホームへ。

こうすれば、4つ目のアプリを足しても既定で守られる。この日、全部を洗い直して次のように振り分けた。

判定には、できるだけアプリの名前を使わないようにした。「最初の案内の中身が用意されているか」「ストアのページがあるか」のように、中身の有無で決める。名前で決めると、また名簿の書き足し忘れが起きる。

型2：写したのは画面だけでなく、初期値と道具もだった

8月23日の空の「メイン」は、画面の問題ではなかった。

the task には「新しく来た人に、最初の箱を1つ用意する」決まりがある。経路検索のアプリはこの決まりまで写していた。経路検索には箱を見る画面が無いので一度も使われないのに、同期がその箱を共通のサーバーへ押し上げ、本家の側に中身0件の箱として現れた。

8月26日と9月27日は、アプリでなく道具が本家を指していた。

配信や設定の道具は、どのアプリの設定を読むかを1つの切り替えで決めている。切り替えを付けずに叩くと、どの作業場所から叩いても本家になる。8月26日は読むだけだったので、27分前の本家の配信が返ってきて「おかしい」と気づけた。9月27日は書き込みだったので、本家の課金の設定を推し活のアプリの値で上書きした。

この書き込みは無言で成功した。直前に一覧を読んだときも本家の値を読んでいたので、「推し活のアプリに本家の値が入っている」と逆向きに読み違えていた。すぐに報告して元の値に書き戻し、一致を確かめた。公開中のアプリには届いていない。そのまま配信していたら、本家で有料プランが買えなくなるところだった。

型3：反転を済ませても、新しい経路からは漏れる

9月28日の通知の件は、型1を直した後に起きた。

アカウントが共通なので、推し活のアプリの中にも the task のタスクが同期で入ってくる。8月31日に、時刻で鳴る通知だけは止めてあった。けれど、タスクから何かを出す経路はほかにもあった。

この日は指摘が2件来た。「推し活のアプリのカレンダーに the task の予定を入れないで」と、「推し活と経路検索のアプリで、まだ the task の通知が鳴っている」。

さらに調べると、逆向きの被害もあった。通知を掃除するとき、本家以外のアプリでも「予約済みの通知を全部消す」を呼んでいたので、推し活のアプリ自身の通知まで消していた。

ここで直し方を変えた。経路を1本ずつ塞ぐのをやめて、タスクに触る処理は、本家以外では入口で空にする。通知、場所、秒読み、カレンダー、どこから入っても最初に空になる。通知を消すときも全部ではなく、印を見て本家の分だけを消す。

同じ日に、推し活のアプリが本家専用の共有の置き場所を持った状態で組み立てられていたことも分かった。組み立ての設定が、全部のアプリに本家の置き場所を足していたからだ。ここも「そのアプリが自分の置き場所を持っていれば足さない」に直した。

数えてみて分かったこと

7回を並べて一番はっきりしたのは、付箋を足す直し方は、必ず次の支店で漏れるということだった。

1回目は名指しで逃がした。2回目で反転させた。それでも、後から足した通知の経路は、反転の外側にあった。最終的に効いたのは、漏れる場所を1つずつ探すのをやめて、入口に1枚だけ関所を置くことだった。

今は、新しいアプリを立てる手順書に「本家の名前で分岐している箇所を機械的に洗い出す」「本家の初期データを用意する処理を棚卸しする」「道具を叩く前に、どのアプリを指しているか名前で確かめる」を入れてある。3つ目の支店で踏んだことを、4つ目の支店の開店前の点検表にした形だ。

同じコードから複数のアプリを出す作り方は、速さの代わりに、こうした混線を抱え込む。混線はどれも、組み立ても検査も通り、開いた人間だけが気づく壊れ方をした。だから点検は、コードではなく、実際に開いた画面と鳴った通知で締めることにしている。