🔧 阿川の電商水電行
=============================================
高三那年（大約一年半前），為了在文化祭的鯛魚燒攤位使用，我用試算表和 Apps Script 做了個簡易的 POS 系統。
回頭看來，這段經驗既讓我知道「用技術改善現場的有趣性」，同時也讓我深刻體會到，導入 IT 本身不能成為目的。
這次會把當時做了什麼、為什麼要做、實際狀況如何，以及學到的事寫出來。
背景
文化祭時我們班經營了一個鯛魚燒攤位。
當時現場有些特殊情況。
因為是夏天，把鯛魚燒的材料放在攤位附近放太久會有食物中毒風險。
因此材料由調理室的冰箱管理，基本上也在調理室那邊完成調理，學校要求攤位方只負責「烘烤作業」。
也就是說，攤位與調理室之間需要資訊連繫。
我當時想到的機制如下：
- 在攤位那邊記錄每樣商品賣了多少
- 讓調理室可以即時確認庫存狀況
- 能在不需逐次通知的情況下，得知哪些商品需要補充
最初的想法不是要做分析，而是為了減少聯絡上的手續、提升效率。
做了什麼
我在 Google 試算表上結合 Apps Script 與函數，做了一個簡易的 POS 系統。
實作的功能大致可分為以下四項：
- 按商品按鈕會顯示總金額
- 確認購買後更新庫存
- 記錄何時、賣了什麼、幾個
- 可以查看目前的總銷售額
我把介面分成收銀畫面、庫存確認／補貨畫面、以及用來保存紀錄的工作表等角色來管理。
畫面示意
收銀畫面
- 選擇商品的按鈕
- 顯示總金額
- 確定按鈕
- 重設按鈕
- 購物車／處理紀錄的簡易顯示
庫存管理畫面
- 確認目前庫存
- 輸入要新增的數量
- 按送出按鈕即反映到庫存
紀錄畫面
- 商品名稱
- 銷售金額
- 銷售時間
- 當前的總銷售額
我的立場
文化祭當天我並沒有什麼特殊職位，也有在負責實際銷售。
不過這個系統是我提出並從設計到實作都負責的。
當時我是從幾乎零知識開始，對試算表的函數和 Apps Script 都還在摸索。
為什麼要做
最初的目的相當明確。
我想要讓攤位和調理室之間不靠口頭聯絡就能運作。
例如：
- 「現在哪個商品減少了多少」
- 「應該補充哪些東西」
如果能即時看見這些資訊，就能減少聯絡次數，讓現場更順暢。
從這個想法延伸出來，我也加入了：
- 自動顯示總金額
- 保存購買紀錄
- 將銷售狀況可視化
另外，文化祭是兩天的活動，所以也有想法是第一天的銷售情況可以用來優化第二天。不過回頭看，分析並不是主要目的，重點還是在效率化。
實際上有幫助的地方
並非完全沒用，實際上有幾點幫上忙。
1. 補貨判斷變得容易
看到哪些商品剩多少，調理室就能比較容易判斷是否要補貨。
能在不用逐次聯絡的情況下運作，達到了這套機制的目標之一。
2. 總金額沒有出錯
會計自動化後，至少避免了金額計算的錯誤。
沒那麼順利的地方
但同時也有不少問題。
1. Apps Script 的延遲
有些處理會慢一拍，在文化祭這種忙碌的場景下會造成些微的使用壓力。
2. 輸入本身成了負擔
在文化祭這種級別，很多情況心算就能處理金額。
因此對 POS 的輸入反而變成了額外工作。
3. 使用方式的說明成本很高
我是開發者，對我來說很直覺，但對其他學生不見得如此。
要在短時間內讓每個人都熟悉操作規則很難，說明成本比預期高。
4. 未能共享「為了什麼而使用」
這是最大的問題。
因為目的說明不夠清楚，實際上出現了「心算就能算所以就心算了」的運作方式。
結果有些銷售沒有輸入到 POS，造成庫存出現偏差，最後還得人工去修正數值。
問題不是系統本身，而是運用前對前提的共享不足。
最大的反省
回頭看，那時候我有一個想法是
「只要導入 IT 就可以無條件提升效率」
但實際上並非如此。
文化祭的攤位本身具有以下特性：
- 銷售期間短
- 會計簡單
- 運作成員是臨時性的
- 現場速度很重要
在這些條件下，增加一個系統不見得會直接改善現場。
反而會帶來：
- 輸入成本
- 為了共享而花的時間成本
- 統一運作規則的成本
- 發生問題時的回復成本
雖然在某些面向有效率化，但整體上也可能造成混亂。
也就是說，「能不能做」和「應不應該導入」是兩回事。
如果是現在，導入前會考慮的事
從這次經驗來看，現在我至少會先決定以下三點。
1. 目的
要解決什麼問題？是要減少聯絡次數、避免會計錯誤，還是要掌握銷售額？
2. 現場是否真的可行
大家能否在短時間內理解使用方式？在忙碌現場輸入是否不會太負擔？
3. 傳達方式
能否簡短明確地說清楚「為了什麼要使用這套機制」？如果這點模糊，系統就不會被使用。
我學到的是：比起技術上能不能做，對現場是否有意義、是否能運用更重要。
從這個經驗得到的學習
如果要用一句話總結這次體驗，就是：
單純導入 IT 不夠，必須把目的、運用方式與現場的相性一起設計，才有意義。
這雖然是文化祭這種小規模的例子，但我認為同樣適用於業務改善或整體的數位轉型（DX）。
「把紙本數位化」
「導入系統」
「自動化」
光做這些還不夠，必須思考：
為什麼要導入、導入後會帶來什麼好處、現場是否真的能用得起來。
高中的我當時還看不清這些。
但也正因如此，這個失敗對我印象深刻。
附帶一提：這次經驗也成了我對 AI 程式撰寫產生興趣的契機
順帶一提，這個簡易 POS 當時也有在做程式時參考包括 ChatGPT 在內的 AI。
不過在 2024 年左右，還不像現在這麼常能拿到「直接就可以跑的程式碼」。實際上經歷了很多次：
- 把輸出的程式碼直接拿來用
- 出錯
- 把可用的部分抽出來
- 自己修正
- 再跟錯誤搏鬥
這樣重複了很長時間。
從幾乎零知識開始、在被需求驅使下邊查邊修的過程中，我第一次體會到不是「讓 AI 全部做完」，而是把 AI 當作輔助輪，在 AI 協助下自己理解並修正的感覺。
這段經驗也促成我後來對 AI 程式撰寫的興趣。
結語
高中時期老實說我曾天真地認為「只要導入看起來像 DX 的東西就會變好」。
但實際操作後我知道，引入技術一定要有明確目的，不適合現場的機制反而會成為負擔。
這段經驗不只是文化祭的回憶，而是至今仍是我思考「使用技術時的基本態度」的出發點。
原文出處：https://qiita.com/Towa_ONGRKL/items/ee5c69831501251a0ec0
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
![![レジ画面]()](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F4321004%2F1a08d1df-2cf7-48c1-89e6-616a9a869c44.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=5ed2f98dc9eaf60c18b223f582e95c54){kind=link}
![![在庫管理画面]()](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F4321004%2Ff2729808-6b13-4cc1-899d-d678789bc32b.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=ebbd75175bd82d759845bb2e38b7429c){kind=link}
![![履歴画面]()](https://qiita-user-contents.imgix.net/https%3A%2F%2Fqiita-image-store.s3.ap-northeast-1.amazonaws.com%2F0%2F4321004%2Fa160257a-3bb9-475a-9c50-01640320b2e8.png?ixlib=rb-4.0.0&auto=format&gif-q=60&q=75&s=3ee12ef30d8123de932873eba3aa9dcf){kind=link}