はじめに
高校3年生のとき（1年半ほど前）、文化祭のたい焼き屋で使うために、スプレッドシートとApps Scriptで簡易的なPOSのような仕組みを作りました。
今振り返ると、この経験は「技術で現場を良くする面白さ」を知るきっかけであると同時に、ITを導入すること自体が目的になってはいけないと痛感した経験でもありました。
今回は、そのとき何を作ったのか、なぜ作ったのか、実際にどうだったのか、そして何を学んだのかを書きます。
背景
文化祭で私たちのクラスは、たい焼き屋を出していました。
当時、現場には少し特殊な事情がありました。
夏場だったこともあり、たい焼きの材料を屋台の近くに長時間置いておくのは食中毒リスクがありました。
そのため、材料は調理室の冷蔵庫で管理し、調理も基本的には調理室側で行い、屋台では「焼く作業」に絞るよう学校側から指示されていました。
つまり、屋台側と調理室側で情報の連携が必要だったわけです。
ここで私が考えたのが、以下のような仕組みでした。
- 屋台側で何が何個売れたかを記録する
- 調理室側から在庫状況をリアルタイムで確認する
- 補充が必要な商品を、都度の連絡なしで把握できるようにする
最初の発想は、分析というよりも連絡の手間を減らすための効率化でした。
作ったもの
Googleスプレッドシート上に、Apps Scriptと関数を組み合わせて簡易POSを作りました。
実装した機能は大きく分けて次の4つです。
- 商品ボタンを押すと合計金額が表示される
- 購入確定で在庫が更新される
- いつ・何が・いくつ売れたかを記録する
- 現在の合計売上を確認できる
レジ画面、在庫確認・補充画面、履歴保存用シートのように役割を分けて管理していました。
画面イメージ
レジ画面
- 商品を選択するボタン
- 合計金額表示
- 確定ボタン
- リセットボタン
- カート／処理履歴の簡易表示
在庫管理画面
- 現在在庫の確認
- 追加する数の入力
- 送信ボタンで在庫反映
履歴画面
- 商品名
- 売上額
- 売り上げ時刻
- 現在の合計売上額
私の立場
文化祭当日の役割としては特別な役職があったわけではなく、普通に販売もしていました。
一方で、この仕組みについては私が提案し、設計から実装まで担当しました。
当時はほぼゼロ知識に近い状態から始めていて、スプレッドシートの関数やApps Scriptも手探りでした。
なぜ作ったのか
最初の目的はかなり明確でした。
屋台側と調理室側の連携を、口頭連絡に頼らずに回したかったからです。
「今どの商品がどれだけ減っているのか」
「何を補充するべきか」
これをリアルタイムで見られれば、連絡の回数が減り、現場がスムーズになると考えました。
そこから発想が広がって、
- 合計金額の自動表示
- 購入ログの保存
- 売上の可視化
も入れていきました。
また、文化祭は2日間あったので、1日目の売れ行きを2日目に活かせるかもしれない、という考えも少しありました。とはいえ、今振り返ると分析が主目的だったわけではなく、あくまで効率化が中心でした。
実際に役立ったこと
完全に無意味だったわけではありません。
実際に役立った点もありました。
1. 補充判断がしやすくなった
何がいくつ減っているかを見れば、調理室側で補充を判断しやすくなりました。
連絡なしである程度回せたのは、この仕組みの狙い通りでした。
2. 合計金額のミスがなかった
会計を自動化したことで、少なくとも金額計算のミスは防げました。
うまくいかなかったこと
一方で、問題もかなりありました。
1. Apps Scriptの遅延
処理がワンテンポ遅れる場面があり、文化祭の忙しい現場では地味にストレスでした。
2. 入力そのものが手間になった
学園祭レベルの会計なら、金額は暗算でも十分対応できる場面が多いです。
そのため、POSへの入力作業が逆に追加タスクになってしまいました。
3. 使い方の説明コストが高かった
自分が作った仕組みなので自分には自然でも、他の生徒にとってはそうではありません。
短時間で全員に運用ルールを浸透させるのは難しく、説明コストが思った以上に大きかったです。
4. 「なんのために使うのか」が共有されていなかった
これが一番大きかったです。
目的の説明が不十分だったため、
「暗算でできるから暗算でやったよ」
という運用が実際に起きました。
結果として、POSに入力されない販売が発生し、在庫にずれが出て、最終的には手動で数値を直す場面もありました。
仕組みそのものより、運用の前提共有が弱かったわけです。
一番の反省
今振り返ると、当時の私は
「ITを入れれば無条件で効率化できる」
と思っていた部分がありました。
でも実際はそうではありませんでした。
文化祭の出し物は、そもそも
- 販売期間が短い
- 会計が単純
- 運用メンバーが一時的
- 現場スピードが重要
という特徴があります。
この条件だと、仕組みを増やすことが、そのまま現場改善にはつながりません。
むしろ、
- 入力の手間
- 共有にかかる時間的コスト
- 運用ルールの統一
- トラブル時の手戻り
といった新しいコストが発生します。
一部では効率化できた一方で、全体としては混乱も生みました。
つまり、「作れるかどうか」と「入れるべきかどうか」は別問題だったということです。
今なら、導入前に何を考えるか
この経験を通して、今なら少なくとも次の3点を先に決めるべきだと思います。
1. 目的
何を解決したいのか。
連絡の削減なのか、会計ミス防止なのか、売上把握なのか。
2. 現場で本当に回るか
短期間で全員が使い方を理解できるか。
忙しい現場でも入力が負担にならないか。
3. 伝え方
「何のためにこの仕組みを使うのか」を、短く明確に伝えられるか。
ここが曖昧だと、使われません。
技術的に作れることよりも、現場にとって意味があるか、運用できるかのほうが重要だと分かりました。
この経験で得た学び
この体験から得た学びを一文でまとめるなら、こうです。
単にITを導入するだけではダメで、目的・運用・現場との相性まで設計して初めて意味がある。
これは文化祭レベルの小さな話ですが、業務改善やDX全般にもそのまま当てはまる考え方だと思っています。
「紙をデジタル化した」
「システムを入れた」
「自動化した」
それだけでは不十分で、
なぜ導入するのか、導入した結果何が良くなるのか、現場は本当に使いこなせるのか
まで考える必要があります。
高校生の頃の私は、そこまで見えていませんでした。
でも、だからこそこの失敗はかなり印象に残っています。
余談：この経験は、AIコーディングに興味を持つきっかけにもなった
ちなみに、この簡易POSは当時のChatGPTなどのAIも使いながら作っていました。
ただ、2024年当時は、今ほど「そのまま動くコード」が安定して出てくるわけではありませんでした。実際には、
- 出力されたコードをそのまま使う
- エラーになる
- 使える部分だけ抜き出す
- 自分で直す
- またエラーと格闘する
ということをかなり長時間繰り返していました。
ほぼゼロ知識から始めて、必要に迫られて調べながら直していく中で、
「AIに全部やってもらう」のではなく、AIを補助輪として使いながら自分で理解して直す感覚を初めて知りました。
この体験は、その後AIコーディングに興味を持つきっかけにもなりました。
おわりに
高校生のときは、正直かなり浅い考えで
「とにかくDXっぽいものを入れれば良くなるはず」
と思っていました。
でも実際にやってみて、技術の導入には必ず目的が必要で、現場に合わない仕組みはむしろ負担になることを知りました。
この経験は、単なる文化祭の思い出ではなく、今でも自分の中で「技術を使うときの基本姿勢」を考える原点になっています。
もし興味がある方がいらっしゃるようでしたら、当時のAIコーディングの話も別で書こうと思っています。