QR ORDER / STAFF SCREENS スタッフUI 全画面

セルフオーダーだけを作るなら、要るのはメニュー・注文・厨房ボードの3つです。 ところが実店舗に入れると、そこで止まりません。 品切れを誰が押すのか、時価の魚はいくらで打つのか、レシートはどこに積むのか、 月末に税理士へ何を渡すのか——注文の前後にある仕事が全部ついてきます。

このページはその全部です。画像を押すと拡大できます。 ほかの飲食店向けシステムと違うのは、 仕入れ・在庫・原価と税理士に渡す画面が同じアプリの中にあることです。 注文が売上になり、売上と仕入れが原価率になり、それがそのまま仕訳になる—— この道が途中で切れていないことが、この作品でいちばん見てほしいところです。

営業中、ずっと開きっぱなしになる3画面です。 焼く人と運ぶ人では、見たいものが違います。 焼く人が知りたいのは「次に何を焼くか」、 運ぶ人が知りたいのは「どの卓がいま何を待っているか」。 だから厨房ボードは品ごと、ホール・会計は卓ごとに並べました。

3枚目は卓ごとの伝票です。注文の履歴を読む、品を取り消す、 会計へ進む——この3つが1枚に載ります。 近い作業に見えて押したあとに起きることは別なので、モーダルではなくページにしました。 まだ提供していない品があるときは、会計の前に帯で知らせます。

3枚に共通して気をつけたのは、情報量・見やすさ・押しやすさの釣り合いです。 詰めるほど一度に見えますが、字が小さくなり、押す的も小さくなります。 押す的は48px角を下回らないと先に決めて、そこから載せる量のほうを削りました。

この4画面のうち、厨房ボードだけは一度作り直しています。上の1枚目を見ながら読んでください。

店員が持つスマホから注文を受ける画面です。お客さまのQR注文と中身は同じで、 入口だけ変えました。お客さまはQRを読んで卓が決まり、店員は番号を押して卓が決まる。 そこから先のメニュー・品選び・かごはお客さま側のものをそのまま使っています。

流用したのは前職での出来事が理由です。卓にタッチパネルを入れたとき、 機械が使えないお客さまに「口頭で頼みたい」と言われ、 バイトの子が「できません」と答えてトラブルになりました。 代わりの手順が紙で受けて厨房の端末に入れ直すという、普段やらないものだったからです。 だから店員の画面は覚えることを増やさない形にしました。 自分がスマホで注文したときと同じ手順で、そのまま受けられます。

卓に入ったあとは、画面の上に卓名を貼り付けたままにしました。 店員は卓を渡り歩くので、品を選んでいる最中に「これはどの卓だったか」が 分からなくなるのが、この画面でいちばん起きやすい事故です。送信の直前にも必ず目に入ります。

飲食店はフードとドリンクを合わせると、100品を超えます。 それを載せ替える画面です。触るのは店主で、月に何度かの作業。 手順を覚えなくても間違えない形に寄せました。 大分類は打ち込ませず選ばせます——打ち間違えるとメニューのタブが割れるからです。 必須が埋まるまで「掲載する」は押せませんが、 途中でやめても「下書きのまま保存」で残せます。

一覧では状態を見る場所と変える場所を同じにしました。 掲載中・品切れはその場で押して止められます。ただし書きかけだけは押せません。 価格やカテゴリが空のまま、お客さまのメニューに並んでしまうからです。 原価を登録していない品は赤い枠で出します。 この画面では「赤＝消える」に「赤＝気づかせる」が加わっています。

並べ替えは見え方だけで、お客さまのメニューに出る順番には触れません。 混ぜると「原価率順に並べたらメニューまで原価率順になった」が起きます。 つまんで動かす並べ替えも、この一覧からは外しました。全カテゴリが混ざるので隣の行が同じカテゴリとは限らず、 落とした位置の意味が決まらないからです。

ここがこのシステムのもう半分です。 レシートは写真を撮って送るだけ。スマホならカメラが直接開き、 APIが読んでデータにします。 機械が苦手でも入力できる形にして、そこから原価率と在庫を出しています。 数字を出すときは、その数字が欠けている理由も同じ画面に書くようにしました。

ただし発注の判断はシステムに渡していません。 前職で「仕入れと在庫から売上を予測する」システムを外注しましたが、当たりませんでした。 長年いるスタッフの読みのほうが正確だったからです。 だからここは予測をやめ、決めた残量を下回ったら、下回ったと出すだけにしています。

飲食店の利益構造はほぼ型が決まっています。 FL（食材＋人件費）で6割、賃料で1割、光熱費と雑費が1割ずつ。 残りの約1割が営業利益です。だから売上画面は金額を並べるのをやめて、 この目安と今月の実績を上下に並べ、差だけを赤で出します。 店主が知りたいのは金額そのものではなく、いまの経営が型からどれだけずれているかです。 型が決まっているので、実績を並べるだけでそれが読めます。

同じ画面に「注文されている商品」も並べました。 どの品がどれだけ出ているかが分かれば、店主はそこから売上目標を立てられます。 その目標から逆算して仕入れが決まるので、前の節の発注はここが起点です。 新しい品を考えるときも、どんな品がどれだけ出ていたかがそのまま手がかりになります。

注文が始まる場所です。QRは卓ごとに発行して紙に焼きます。 一度刷って貼ってしまうと直すのが大変なので、 印刷する前に気づけることを優先しました。

QRには、お客さまのスマホが開くURLを焼き込みます。 ここを設定し忘れると、そのパソコンの中だけで通じるアドレスが入ったまま印刷されます。 やっかいなのは、店のパソコンで試すと普通に開くことです。刷る側は気づけません。 貼って、開店して、お客さまがスマホをかざした瞬間に初めて分かります。 だからこの画面は、URLが直っていないときだけ帯を出して知らせます。

QRの再発行は、いちばん下に離しました。 押すとその卓の合言葉が変わり、席に貼ってあるQRは読めなくなります。 新しい紙を刷って貼り替えるまで、その席からは注文できません。 紙を貼り替えるという物理の作業まで発生するので、取り返しがつかないからです。

月末に税理士へ渡すための5画面です。店が記録するのは 「食材を8%で買った、インボイスは無かった」という事実で、 会計ソフトが欲しいのは「仕入高／課対仕入(軽)8%・80%控除」という言葉です。 この翻訳をアプリの中でやり切るところまで作りました。 税理士のログインは店のスタッフとは別で、左のメニューもこの5画面だけになります。

インボイスにも対応しています。自分の店の登録番号（T＋13桁）と、 仕入先が領収書に登録番号を印字していたかを別々に持ちます。 同じ食材の8%でも、登録番号のある仕入れは全額控除、無い仕入れは経過措置で80%。 証憑の一覧では「登録番号なし」だけを拾えるので、判断が要る分をまとめて見られます。

店の立場も、「課税か免税か」と「登録番号を持っているか」を別の項目にしました。 ひとつの真偽値では課税事業者だがインボイスに登録していない状態が表せません。 納めるけれど、こちらが出す領収書では相手が控除できない——という店が実際にあります。 既定は「未設定」です。免税を既定にすると、何も設定していない店に 「消費税を納めなくてよい」と表示されてしまうからです。

税理士は店の外の人です。月末の帳簿に要るのは売上と仕入れの金額だけで、 品ごとの原価やレシピ、まだ出していない商品までは要りません。 そこは店が外に出したくない情報です。漏れれば作り方も値付けも読まれます。 そこで税理士には専用のロールを割り当てました。この3つには到達できません。 店長だけは税理士画面も見られます。 何を渡しているか自分で確認できないと、外に出す責任が持てないからです。

店に置いたあと、誰も見ていない時間を支える画面です。 この4つが無いと、動いてはいても預けられません。