これ、うちの店用にできひん？
三崎ドライブインの現場で出てくる困りごとを、
AIと一緒に整理し、
専用POSシステムとして実際の営業で使える形まで育てていったプロジェクト。
三崎ドライブイン／POSシステム
発端
レジだけあったら、ええんやろか？
必要なのは、注文を取って会計するための「レジ」だけではなかった。
現金とPayPay。 番号札。 商品の在庫。 予約。 厨房への注文伝達。 商品の受け渡し。 キャンセルや返金。 営業が終われば、レジ締めと日報。
店が小さいから、仕事も少ないわけではない。
むしろ限られた人数で営業するキッチンカーでは、ひとつひとつは小さな作業でも、それが同じ時間に重なる。
市販のPOSを探せば、会計はできる。
でも、
「うちでは番号札をこう渡したい」 「予約の商品は先に作り始めたい」 「厨房では、この順番で見えた方がいい」 「営業が終わったら、ここまで一気につながってほしい」
使い始める前から、三崎ドライブイン独自の仕事がいくつもあった。
だったら、
仕事をPOSに合わせるんじゃなく、POSを自分たちの仕事に合わせたらええんちゃうか。
そこから、タカシとチャッピーの試行錯誤が始まった。
そして実際に店で使う純子も加わり、
「これで営業できるか？」を基準に、少しずつ形にしていった。
このプロジェクトでやったこと
- 注文と会計を、三崎ドライブイン専用のPOSにした
- 在庫・予約・番号札を、ひとつの流れにつないだ
- 注文内容を厨房へリアルタイムで共有できるようにした
- 営業前の出店準備まで、チェックできるようにした
- キャンセル・返金・レジ締め・日報まで営業全体へ広げた
店に合わせて、道具を育てる。
CHAPTER 01
レジをつくる。……だけでは終わらない。
01-1
「POSを作る」って、どこまでの話？
キッチンカーで注文を受けて、金額を出して、現金かPayPayで会計する。
まずはそれができれば、レジとしては使える。
でも、実際の三崎ドライブインの営業を順番に並べてみると、すぐにそれだけでは足りないことが分かった。
営業前には、その日に売る商品を決める。 在庫を確認する。 開始時の現金を用意する。 番号札を何番から使うかも決める。
営業が始まれば、通常注文だけではない。 予約も入る。 商品ごとにオプションも違う。 売れれば在庫も減る。 注文を受けたら、厨房にも正しく伝えないといけない。
そして商品を渡したら、それで終わりでもない。
キャンセルや返金が発生することもある。 営業終了時には現金とPayPayを照合する。 最後は日報として残す。
つまり必要だったのは、
「会計するためのレジ」ではなく、営業そのものをつなぐ仕組みだった。
01-2
先に作ったのは、画面より「仕事の順番」
「POS作って」
と丸投げしたわけではない。
先にやったのは、三崎ドライブインの仕事を順番に並べることだった。
営業前 ↓ 注文 ↓ 会計 ↓ 厨房 ↓ 予約 ↓ 受け渡し ↓ 修正・キャンセル・返金 ↓ 営業終了 ↓ 日報
こうして並べてみると、
「この情報は次の画面でも必要やな」
「ここで在庫を減らさなあかん」
「番号札は注文と一緒に管理せなあかん」
と、仕事同士のつながりが見えてくる。
タカシが担当したのは、
実際の現場では何が、どの順番で起きるのかを言葉にすること。
チャッピーが担当したのは、
その仕事を、画面・データ・処理の流れへ置き換えること。
人間の仕事をそのままコードにしたのではない。
一度、
「この店では、仕事がどう動いているのか」
を分解してから、システムへ翻訳していった。
01-3
一つの画面ではなく、一つの営業をつくる
商品マスター。 本日の提供メニュー。 在庫。 通常注文。 現金とPayPay。 待ち番号。 予約。 厨房へのリアルタイム表示。 キャンセル。 返金。 レジ締め。 日報。
あとから見ると、ずいぶん大きなシステムに見える。
でも最初から、
「全部入りのPOSを作ろう」
と考えていたわけではない。
ひとつの仕事を見て、 その前後を見て、 つながっている仕事を追加する。
その繰り返しだった。
そして、この段階で一番大きく変わったのは、システムではなかった。
自分たちの仕事の見え方だった。
普段は無意識にやっていることでも、システムにしようとすると、
「いつやってる？」 「誰が判断してる？」 「何を見て次へ進んでる？」 「失敗したらどう戻す？」
まで決めないと動かない。
POSを作り始めたことで、三崎ドライブインの営業そのものを、初めて細かく言葉にして見ることになった。
01-4
そして、使ってみる。
「これなら使えるやろ」
と思った。
画面もできた。 注文も入る。 会計もできる。 厨房にもつながる。
でも、現場へ持っていくと、また別のことが見えてきた。
作る前には見えなかった仕事が、使った瞬間に見えてくる。
次の問題は、そこから始まった。
CHAPTER 02
使ってみたら、欲しいものが増えていった。
02-1
「使える」と「現場で使いやすい」は、ちょっと違う
注文できる。 会計できる。 在庫も動く。 厨房にも注文が届く。
ここまで来ると、一度は思う。
「もう、だいたいできたんちゃう？」
でも、実際の営業で使い始めると、すぐに別のものが見えてきた。
システムが動かないわけではない。
ちゃんと動く。
ただ、
「ここ、もう一歩こうなったら楽やのに」
という小さな違和感が、営業のたびに出てくる。
これは、机の前で考えているだけでは分からなかった。
02-2
店を開く前から、もう仕事は始まっている
「出店準備もチェックできたらええよな」
という話だった。
キッチンカーは、店へ着いてから営業が始まるわけではない。
商品。 食材。 仕込み。 ポータブル電源。 発電機。 かき氷機。 その日に必要な機材。
忘れ物をしたら、現場へ着いてからでは遅い。
最初は単純なチェックリストでもよかった。
でも、考えていくと、
その日のメニューによって、持っていくものも違う。
ハンバーガーを売る日と、かき氷を売る日では準備が違う。
そこで出店チェックを、「本日のメニュー」と連動させた。
その日に販売する商品に必要な項目だけを表示する。
共通で必要な機材は常に出す。
仕込みが必要なものは、To doとして表示する。
チェックした状態はその日のブラウザに残る。
POSの外にあった準備作業まで、少しずつシステムの中へ入っていった。
02-3
厨房では、「注文が入った」だけでは足りなかった
注文カードが表示される。
最初は、それで十分に思えた。
でも、実際に複数の商品を同時に作り始めると、
「この注文の、どの商品まで作った？」
が分からなくなる。
一つの注文に、
ハンバーガーとホットドッグとドリンク。
全部が同じタイミングで完成するとは限らない。
そこで、注文全体ではなく、商品ごとに調理状態を持たせることにした。
未着手。 調理中。 調理終了。
厨房で商品を触るたびに、状態を変える。
間違えたら戻せる。
これで、
「注文は入っている」
だけだった画面が、
「今、どこまでできているか」
を見る画面へ変わった。
02-4
予約は、お客さんが来てから始まるわけではない
受取時間が決まっているなら、
お客さんが来てから全部作り始める必要はない。
先に作れる商品は、少し前から準備した方がいい。
そこで予約商品も、来店前から商品単位で
未着手 ↓ 調理中 ↓ 調理終了
を記録できるようにした。
そして、お客さんが来店して予約を通常注文へ切り替えても、
それまでの調理状態をそのまま引き継ぐ。
来店した瞬間に、
「さっきまで何作ってたっけ？」
に戻らない。
現場で起きている仕事の途中経過を、そのまま次の処理へ渡す。
これも、最初から設計図にあった機能ではなかった。
実際に使ったから出てきた要望だった。
02-5
システムを作っていたというより、仕事を拾っていた
出店チェックも、 商品ごとの調理進捗も、 予約の事前調理も、
最初の目的だった「レジ」とは少し離れて見える。
でも現場では、全部つながっている。
忘れ物をせずに出店する。 注文を受ける。 厨房で作る。 予約時間に間に合わせる。 お客さんへ渡す。
だから、
「POSの機能を増やそう」
と考えて追加したわけではない。
営業中に、
「ここ、困るな」
「これ、見えたら楽やな」
「この作業もつながった方がええな」
と出てきた仕事を、一つずつ拾っていった。
タカシと純子が現場で気づく。
チャッピーと相談する。
必要なら作る。
次の営業で使う。
そこでまた違和感が出る。
その繰り返しで、POSは少しずつ三崎ドライブインの仕事に近づいていった。
02-6
ただし、機能が増えると別の怖さも出てくる
注文を直せば、 在庫へ影響する。
予約を直せば、 厨房にも影響する。
厨房の状態を変えれば、 その後の処理にもつながる。
機能が増えた分、
「ここだけちょっと直して」
が、本当にそこだけで済むとは限らなくなってきた。
次に必要になったのは、
新しい機能を作ることではなく、
壊さずに直すための考え方だった。
CHAPTER 03
「そこだけ直して」が、いちばん怖い。
03-1
機能が増えると、「そこだけ」がなくなっていく
最初の頃なら、
「このボタンの動きだけ変えたい」
「ここに表示を一つ追加したい」
で済んでいた。
でも、注文、在庫、予約、厨房、返金、レジ締め、日報までつながってくると、
一か所の変更が、本当に一か所だけで終わるとは限らない。
通常注文は、売上だけではなく在庫や待ち番号にもつながっている。
予約は、在庫確保や支払い、厨房にもつながっている。
厨房では、通常注文と予約の両方を扱い、調理状態、修正、キャンセル、返金まで持っている。
レジ締めを触れば、売上、返金、照合、出店費用、日報に影響する。
だから、
「ここだけ直して」
という一言が、だんだん怖くなった。
03-2
チャッピーが早いからこそ、止める必要があった
「ここをこう変えたい」
と伝えれば、すぐに修正案が出てくる。
これは強い。
でも、早いことと安全なことは同じではない。
ある部分を直した時に、
「それ、厨房にも影響せん？」
「予約から通常注文へ変わる時は？」
「レジ締めの数字は？」
と、タカシ側で止める場面が増えていった。
AIは、言われた修正を形にするのは得意。
でも、
その変更が、現場のどの仕事までつながっているか
は、必ずしも最初から全部分かっているわけではない。
だから途中から、
「まず直す」
ではなく、
「まず影響が出るところを見る」
へ順番を変えた。
03-3
修正する前に、見る
まず、今の仕様を見る。
次に、変更する画面だけではなく、
* Firestoreのデータ
* 在庫
* 予約
* 厨房
* 返金
* レジ締め
* 日報
まで、どこにつながっているかを見る。
対象の文字列や関数が何か所にあるのかも確認する。
想定より多かったら、一度止める。
それから、
必要なところだけを、最小範囲で直す。
「ついでに、ここもきれいにしとこ」
はやらない。
動いている業務システムでは、
ついでの親切が、別の場所を壊すことがある。
03-4
直したら、終わりではない
ソース上で、狙ったところだけが変わっているか確認する。
buildする。
ビルド後のファイルにも反映されているか見る。
本番へ反映する。
そして、実際の端末で動かす。
売上や在庫、返金、日報に関係する変更なら、
画面が動いたかだけではなく、保存されたデータまで見る。
ここまでやって、初めて
「今回の修正は大丈夫」
と言える。
実際、注文完了後のレシート表示を追加した時も、
変更は注文画面とその周辺だけに限定されているかを先に監査した。
認証、厨房、予約、レジ締めなどに意図しない変更がないことを確認してからbuildし、本番へ反映した。
その後、現金注文とPayPay注文を実際に入れ、レシート表示だけでなく、厨房へ従来どおり注文が届くところまで確認している。
03-5
AIに任せる範囲も、仕事の一部になった
「チャッピーに何を頼むか」
だけではなく、
「どこで人間が止めるか」
も、仕事の一部になった。
AIに全部任せるのでもない。
人間が全部コードを読むわけでもない。
タカシが現場と仕様を見て、
「ここまで影響するかもしれん」
と範囲を決める。
チャッピーが調べ、修正案を出す。
タカシが止める。
また確認する。
buildする。
本番で使う。
この往復を繰り返す。
結果として必要になったのは、
AIを速く動かすことではなく、AIと安全に仕事を進めるためのルールだった。
CHAPTER 04
100円合わない。それも、現場では事件になる。
04-1
数字が合わない。原因は、システムではなく現場だった
レジの現金を数える。
POS上の売上と照合する。
本来なら、
「差額 0円」
で終わるはずだった。
ところが、ある時、
数字が合わない。
売上計算がおかしいわけではない。
注文も残っている。
現金も数え直した。
それでも合わない。
そこで現場の動きを一つずつ追っていくと、原因が分かった。
出店費用を、営業中のレジ現金から払っていた。
POSから見れば売上は正しい。
でも、実際のレジの中からは、その分だけ現金が出ている。
つまり、
システム上の「正しい計算」と、 現場にある「実際の現金」が、
同じルールでは動いていなかった。
04-2
出店費用は、売上ではない。でも現金は減っている
営業終了時の現金から、営業開始時の現金を引く。
普通なら、その差額が現金売上になる。
でも途中で出店費用をレジから払っていた場合、
そのままでは現金売上が少なく見える。
だから照合時だけ、
出店費用を足し戻す。
計算は、
現金照合額 ＝ 終了現金 − 開始現金 ＋ 出店費用
とした。
出店費用を売上へ足すわけではない。
あくまで、
「レジから出ていった現金を、照合するときだけ戻して考える」
ための処理。
そして別に、
出店費用控除後売上 ＝ 売上合計 − 出店費用
も持たせた。
同じ「出店費用」でも、
現金照合では足す。
売上を見る時は引く。
この違いも、実際の店の金の動きを知らないと出てこない。
04-3
300円払ったら、レジに300円足りないのは当たり前
開始現金 30,000円。 現金売上 1,000円。 出店費用 300円。 終了現金 30,700円。
という状態で確認した。
単純に終了現金から開始現金を引けば、
700円しか増えていない。
でも、
途中で300円を出店費用として払っている。
そこで300円を照合時に足し戻すと、
現金照合額は1,000円。
POSの現金売上と一致する。
差額0円。
照合OK。
さらに、
売上1,000円 − 出店費用300円で、
出店費用控除後売上は700円。
実際の営業で起きていることと、POS上の数字がようやく一致した。
04-4
「0円返金待ち」という、変な状態も出てきた
注文をキャンセルした時の返金処理。
普通なら、
お金を受け取っていた注文をキャンセルする。
↓
返金が必要。
↓
返金待ちにする。
これは分かりやすい。
ところが、
返金額が0円のキャンセルでも、返金待ち状態が残る
ケースが出た。
実際には返すお金がない。
でもシステム上は、
「返金待ちがあります」
となる。
しかも返金待ちが残っていると、
営業終了処理を止める仕組みになっていた。
つまり、
返すお金は0円なのに、返金待ちのせいで店を締められない。
現場から見ると、完全におかしい。
04-5
正しいルールは、現場で決める
返金額が1円以上なら、返金待ち。
返金額が0円なら、
返金待ちは作らず、そのままキャンセル完了。
さらに、すでに残っていた0円返金待ちについては、
完了処理できる救済経路も用意した。
これで、
「返金が必要な注文だけ止める」
という、現場の感覚に合う動きになった。
04-6
一般的な正解ではなく、この店の正解
POSには、
「一般的にはこうする」
だけでは足りないということだった。
出店費用をどこから払うか。
キャンセルした時、実際に返金が必要なのか。
営業終了時に、何をもって数字が合ったとするのか。
それは店によって違う。
AIは計算式を作れる。
コードにもできる。
でも、
その計算式が現場に合っているかどうかを決めるのは、人間。
タカシと純子が、
実際の営業で
「これ、数字おかしくない？」
と気づく。
チャッピーと一緒に原因を追う。
現場のルールを言葉にする。
それをシステムへ戻す。
この繰り返しで、
POSは少しずつ、
「一般的なPOS」ではなく、
三崎ドライブインの仕事そのもの
に近づいていった。
04-7
それでも、まだ終わらない
返金処理も直った。
営業終了まで流れた。
ここまで来ると、
また思う。
「今度こそ、だいたい完成やろ。」
でも、次の営業でまた小さな違和感が出てきた。
注文を確定した直後。
次のお客さんへ進んだあと。
ふと、
「さっきの注文内容、もう一回見たい。」
そんな一言から、
また一つ修正が始まった。
CHAPTER 05
完成してからも、完成しない。
05-1
「もう使える」は、完成ではなかった
注文できる。 会計できる。 在庫も動く。 予約も扱える。 厨房にも届く。 返金もできる。 レジ締めもできる。 日報も残る。
かなり使えるシステムになっていた。
実際の営業でも動いている。
大きな不具合も減った。
ここまで来ると、
「もう完成でええやろ」
と思いたくなる。
でも、現場で使い続けると、
大きな機能ではなく、
ほんの小さな不便が気になり始めた。
05-2
注文を確定したあと、もう一回見たい
注文を確定したら、すぐ次のお客さんへ進む。
混雑している時ほど、
一件ずつ立ち止まってはいられない。
でも、確定した直後に、
「さっき何頼まれたっけ？」
「預かりいくらやった？」
「お釣り、何円やった？」
と確認したくなることがある。
特に高額紙幣を預かった時は、
釣銭を渡す直前に、もう一度数字を見たい。
ところが、
注文はすでに確定済み。
画面は次の注文へ進んでいる。
厨房には注文が飛んでいる。
わざわざ過去注文を探しに行くほどではない。
でも、
今この瞬間だけ、さっきの注文を見たい。
そんな小さな困りごとが出てきた。
05-3
「次の注文」画面に、直前のレシートを残す
注文確定後のレシート表示。
注文番号。 商品明細。 オプション。 数量。 値引き。 合計。 支払方法。
現金なら、
預かり金額と、お釣りも表示する。
PayPayなら、
現金用の「お預かり」「お釣り」は出さない。
必要なのは、
正式な紙レシートではない。
「さっきの注文を、もう一度だけ確認できる画面」
だった。
05-4
大きく作り直さず、必要なところだけ足した
システム全体を作り直したわけではない。
注文登録時にすでに持っているデータを使って、
そのままレシートを描画した。
追加でFirestoreを読み直す処理も入れていない。
注文の保存タイミングも変えない。
厨房カードが出るタイミングも変えない。
Firestoreに保存する項目も変えない。
現金入力欄やテンキーも触らない。
つまり、
必要な不便だけを直して、他の流れは変えない。
CHAPTER 03で決めた、
「最小範囲で直す」
というルールが、ここでも効いている。
05-5
本当に使えるかは、営業と同じ条件で見る
画面に出たからOK、
では終わらせなかった。
現金注文では、
ハンバーガー500円。 学割50円引き。 合計450円。 1,000円預かり。 お釣り550円。
この条件で、レシート表示を確認した。
PayPay注文では、
支払方法がPayPayと表示され、
現金用の「お預かり」「お釣り」が出ないことを確認した。
さらに、
レシートを追加したせいで、
厨房への注文連携が壊れていないかも確認した。
両方とも、従来どおりリアルタイムで厨房へ表示された。
05-6
改善は、大きな機能追加だけではない
機能一覧だけ見れば小さい。
でも、
実際に営業する側からすると、
この小さな違いが大きい。
忙しい時に、
探さなくていい。
思い出さなくていい。
一度戻らなくていい。
その場で確認できる。
システム開発というと、
新しい画面を作るとか、
高度な機能を追加するとか、
大きな変更に目が行きやすい。
でも現場では、
「あと一手減らせたら楽」
という改善の方が効くことも多い。
05-7
「完成」は、人がOKを出した瞬間だけ
最初から完成形が見えていたわけではない。
作る。
使う。
困る。
直す。
また使う。
そして、
また別の小さな困りごとが出る。
その繰り返しだった。
タカシと純子が現場で違和感を見つける。
チャッピーと一緒に整理する。
必要なところだけ直す。
実際の営業で確かめる。
この往復がある限り、
POSは仕事と一緒に変わっていく。
だから、
完成してからも、完成しない。
それは欠点ではない。
むしろ、
現場で本当に使われている道具だからこそ、まだ育つ。
三崎ドライブインPOSは、
「完成品」ではなく、
三崎ドライブインの仕事と一緒に育つ道具
になった。
システムを作ったんじゃない。仕事の進め方を変えた。
最初から完成形があったわけではない。
現場で困る。 タカシと純子が気づく。 チャッピーと整理する。 必要なところだけ直す。 また営業で使う。
その繰り返しで育ってきた。
AIが全部を決めたわけでもない。
現場の正解を決めるのは人間。 それを仕組みに変えるところを、AIが支える。
このプロジェクトで変わったのは、
POSそのものより、
「困りごとを、仕組みに変えていく」
という仕事の進め方だった。
三崎ドライブインPOSは、今も完成品ではない。
仕事が変われば、また直す。
仕事に合わせて、道具を育てる。
あなたの仕事にも、 「ずっとこうしてるけど、もっとやりようあるんちゃう？」 という作業はありませんか？