提案の資料は一式そろっていた。企画提案書、システム要件定義書、概算見積、それらを束ねた統合資料。地域の商工団体へ出す、まちぐるみのスタンプラリーの提案だった。参加する店はおよそ百二十。真冬の一か月あまりのあいだに、異なる五つの店で印を集めると一回応募でき、抽選で百名に賞品が当たる。紙は整っていた。それでも、これで決まる気がしなかった。
紙の上では、誰も操作しない
読む側は、書かれていないところを想像で埋める。この企画で埋められてしまうのは、参加者が店頭でどう動くかという一番肝心なところだ。符号を読むまでに何回タップするのか、印は何秒で入るのか、五つ集まったあと応募の画面はどう出るのか。ここを各自の想像に任せると、決まったあとで「思っていたのと違う」が必ず出る。そのときの手戻りは、渡す前に動くものを用意する手間より、はるかに大きい。だから、そろった資料一式に、触れるものを添えることにした。
外してはいけない前提が、二つあった
要件定義書には、設計を変えるときも守る前提を二つ書いた。位置情報を取得しないこと。店舗スタッフの操作を前提にしないこと。
位置情報は、便利に見えて割に合わない。求めた時点で拒否する人が出るし、端末によっては使えない。拒否した人だけ機能が違う作りにすると、店頭で「私だけ進めない」が起きる。取れば取ったで、預かった情報の保管責任が生まれる。取らないと決めるだけで、この三つが同時に消えた。
店員の操作も同じだった。暗証番号を打ってもらう案も、日替わりの合言葉を口頭で伝える案も、机の上では成立する。けれど百二十の店に手順を配り、繁忙の合間に覚えてもらい、担当が休んだ日も回す、という話になった瞬間に破綻する。店にお願いするのは、指定の掲示物を貼ることだけにした。あとは何もしなくていい。この一行を守るために、仕組み側が全部引き受ける設計になった。
認証が要るのは、二つの行為だけ
店の一覧も、商品も、お知らせも、メッセージアプリを使っていない人が見られるようにした。認証が要るのは、印を取ることと、応募することの二つだけだ。集客のために作る道具が、入口で人を選ぶ道具になってはいけない。参加はしないけれど店は知りたい、という人を締め出す理由がない。
触れる形にして渡す
作ったのは四つの画面だった。誰でも見られる公開のポータル、参加者が印と応募を扱う画面、運営が店と応募を管理する画面、そして店が自分の店の情報だけを直して公開を申請する画面。要件定義書に並べた必須要件を、そのまま指で確かめられる形にした。
見せるときはカメラの代わりに操作パネルから店を選ぶ。ただし、そこで読み込む文字列は、実際に印刷する符号に焼くものと同じ署名付きのものを使っている。見た目だけ似せた張りぼてにすると、その先の議論がまるごとあてにならなくなるからだ。経路が本物なら、動いた事実がそのまま設計の裏づけになる。
決まる前に、作る
提案が通る保証はない。通らなければ、この一式は使われずに終わる。それでも先に作ったのには理由が二つある。ひとつは、要件定義書に並べた必須要件が、本当に矛盾なく同時に成り立つのかを自分の手で確かめたかったこと。書いた時点では両立するつもりでも、実装すると衝突する条件はいくらでもある。もうひとつは、決まってから作り始めると、決められない論点が最後まで居座ることだ。動くものがあれば、論点は「どちらがよいか」に変わる。
次の回は、店頭に貼るだけの札に、どうやって鍵をかけたかを書く。