事故記録帳

FIELD ENGINEERING / 外食の一人情シス

現場で踏んだ罠と、 直し方。

店長と SV を10年以上。いまは外食企業の情シスとして、現場に入って仕様を書き、作り、使われるところまでひとりで回しています。

このサイトは、その途中で踏んだ罠の記録と、頼めることの一覧です。

申請一覧.xlsx
受付番号申請者内容状態
2R-0412店舗 A備品の移動受付
3R-0413店舗 Cシフト交代受付
4R-0414店舗 B釣銭の補充受付
5R-0415店舗 B釣銭の補充受付

01

進め方

頼まれたものを作るより先に、何が起きているかを見に行きます。

  1. A — OBSERVE

    現場を見る

    話を聞く前に、実物を見ます。紙の帳票、Excel、レジの画面、毎朝の手作業。店長と SV をやってきたので、どこで手が止まるかは見当がつきます。取れるデータと取れないデータは、自分の手で確かめます。

  2. B — SPEC

    仕様を書く

    元の帳票を分解して、画面・データ・権限・例外を書き出します。技術と業務の両方の目で読み直し、決めきれない論点は、選択肢をつけて決める人に返します。

  3. C — BUILD

    作る

    スプレッドシート、GAS、BigQuery、Python。手元にあるもので、まず動くものを出します。数字の検算は、必ず正本と突き合わせます。

  4. D — RUN

    使われるまで回す

    使われ始めてからが本番です。止まった、合わない、使いにくい。現場の声を拾って直し、手順書と引き継ぎまで残します。

CASE

店舗の数字を、毎月の手集計から画面へ

依頼
店舗ごとの売上と商品の動きを、毎月 Excel で手でまとめていた。
観た・書いた
レジのデータの出し方を実際に確かめ、取れる項目と取れない項目を整理した。画面の要件と、検算のやり方を仕様に書いた。
作った
レジのデータを BigQuery に集め、店舗・商品・時間帯で見られる画面を作った。数字は元の帳票と突き合わせて検算した。
回した
検算の途中で、資料ごとに食い違っていた数字を見つけ、正しい値にそろえた。その後も、使う人の要望に合わせて見方を足している。

02

記録

起きたこと・原因・直し方の順に書いています。題名を押すと開きます。

  1. 起きたこと
    重い処理の途中で、画面が先に「応答なし」を出した。利用者がもう一度押し、同じ申請が二件できた。
    原因
    サーバー側は数十秒かけて処理を続けていた。画面の待ち時間が、それより短く決め打ちされていた。
    直し方
    書き込みに受付番号を持たせ、同じ番号の二度目は捨てる。画面の待ち時間は、処理の実測に合わせる。
  2. 起きたこと
    集計を見ると、前月の末日だけがきれいに抜けていた。毎月、同じ日だけ。
    原因
    日次の取込が「今月のフォルダ」だけを見ていた。末日の分は翌月一日にしか取れないが、その時点で新しいフォルダはまだ無い。
    直し方
    直近の数日を毎回取り直して、まるごと置き換える。月の境目を気にしなくてよくなる。
  3. 起きたこと
    画面に出る名前を少し整えただけで、絞り込みと結合が一斉に外れた。
    原因
    画面に出す文字列を、そのまま結合のキーにも使っていた。
    直し方
    表示用と識別用の列を最初から分ける。表示は変わる前提、キーは変えない前提で持つ。
  4. 起きたこと
    コードを直して保存したのに、利用者の画面では古い動きのままだった。
    原因
    GAS の Web アプリは、特定のバージョンに固定されて公開されている。保存しても公開中の URL は変わらない。
    直し方
    「デプロイを管理」から新しいバージョンで上げ直す。この一手を、手順書の最後に必ず書く。
  5. 起きたこと
    エラーは出ていないのに、合計が明らかに小さかった。
    原因
    GROUP BY に集計軸でない単価の列を足したため、同じキーで複数行が返るようになった。受け側はそれを代入で受け、最後の一行しか残っていなかった。
    直し方
    受け側は加算で集める。SQL の列を足したときは、件数と合計を元の値と並べて確かめる。
  6. 起きたこと
    取込を流したら、商品名が一つ残らず読めない文字になった。
    原因
    UTF-8 だと思い込んで読んでいた。実際の CSV は別の文字コードで、区切りもカンマではなかった。
    直し方
    取得したら、まず生のファイルの先頭のバイトを見る。文字コードと区切りを決めてから読む。
  7. 起きたこと
    人のマスタを全件同期した翌朝、最初に作った管理者アカウントでログインできなくなった。
    原因
    マスタに載っていない形で作ったアカウントだったため、同期処理が「退職した人」と判定した。
    直し方
    守るアカウントの一覧を持ち、同期の対象から外す。同期の設計を書くときに、最初に決めておく。
  8. 起きたこと
    定期ジョブのログが、同じ権限エラーで埋まっていた。
    原因
    権限が足りないエラーを握り潰して、次へ進む作りにしていた。止まらないので、誰も気づかない。
    直し方
    持っている権限を記録しておき、権限の無い機能は最初から呼ばない。失敗が分かっている呼び出しは繰り返さない。
  9. 起きたこと
    外部のサービスでは処理が済んでいたのに、自分の側の記録は「未実行」のまま。次の実行で、同じ処理を二度走らせた。
    原因
    行をロックしたトランザクションの中から外部の API を呼んでいた。時間切れで巻き戻ったのは、自分の側だけだった。
    直し方
    外部を呼ぶ前に「実行中」を先に確定させる。外部の呼び出しは、トランザクションの外に置く。
  10. 起きたこと
    画面の合計と内訳の合計は一致していた。それでも、元の帳票とは合わなかった。
    原因
    検算が、同じ処理から作った数字どうしを比べていただけだった。上流で間違えば、両方そろって間違う。
    直し方
    検算は必ず正本と突き合わせる。元の帳票か、元データに直接投げた集計と比べる。

03

頼めること

どれも、上の「進め方」の四つの段階で進めます。

使う道具　Google スプレッドシート / Apps Script / BigQuery / Looker Studio / Python / Claude Code / Cloudflare

04

AI の使い方

道具の名前より、誰が何に責任を持つかを先に決めます。

  1. 全員に開いて、作る役は絞る

    使うこと自体は全員に開きます。ただ、共有して長く使う仕組みを作る役は、少人数に集めます。誰も直せない仕組みが社内に増えるのを防ぐためです。

  2. 会議の記録を、議事録の形まで

    録音と資料から、決まった書式の議事録を作ります。人がするのは、最後の確認だけです。

  3. ひとりで、開発チームを持つ

    仕様を書く、作る、見直す、確かめる。役割を分けて AI に任せ、判断と責任は自分が持ちます。このサイトも、その形で作りました。

05

経歴

外食企業で、情シスとデータ基盤と社内システムの内製を、ひとりで受け持っています。

会社
グループ全体で店舗 200 以上、年商 100 億円以上の外食企業
前歴
店舗の店長、複数の店を見る SV として10年以上
担当
情シス、データ基盤、社内システムの内製、IT 統制への対応、AI 活用の推進
相手
店舗、本部、経理、人事、外部の開発会社
体制
ひとり。必要なときは外部の会社と組みます

会社名と細かい数字は出していません。記録に書いているのは、ほかの現場でも起きる話だけです。

06

ご相談

ご連絡は X のメッセージか、メール（hello@jikokiroku.com）へ。内容を拝見のうえ、お返事します。

X@k_josys