CSVを開いた瞬間に、会議が“無音”になるやつ

これ、飲食の本部あるあるだと思うんですが。

「全店の売上を統一して見たい」
「M&Aもしたし、ブランド増えたし、POSもバラバラだし」
「だからBIで一本化しよう」

…ここまでは、誰もがワクワクします。

で、担当者がPOSから出てきた生データ（RAW）のCSVを開く。
列名は略号だらけ、行数は無限、仕様書は無いか、あっても実態とズレている。

そして数分後、会議室に訪れる“あの沈黙”。

「……これ、何が書いてあるのか分かりません」
「どこが売上で、どこが取消で、どこが値引きなのか…」

ここで多くの会社はこうなります。

「じゃあ日計（集計済み）でいいか」
「とりあえず画面だけ作って、見られるようにしよう」

でも僕は、これをやった瞬間に“統一”が終わると思っています。
なぜなら、日計は“結果”であって、“原因”が消えているからです。

---

僕が最初にぶつかった壁：「POSのRAWは、会社ごとに“別言語”」

ティールを始める前、僕は飲食の経営者としてずっと同じ苦しみにハマっていました。

• 管理会計の数字と、財務会計の数字が合わない
• 店舗別にズレ方が違う
• 「原因」を掘ろうとすると、データが粗すぎて追えない

そして気づきます。
問題はBIの画面じゃない。レポートの体裁じゃない。

そもそも、POSのデータが“統一”できるように作られていない。

もっと言うと、POSはメーカーごとに、

• データの持ち方
• 計算の仕方
• キャンセル／取消の計上の仕方
• 値引きの扱い
• 時刻や営業日の考え方

ありとあらゆるポイントが違う。

さらに厄介なのは、同じ言葉なのに意味が違うこと。

「総売上」「純売上」
この“超基本語彙”ですら、メーカーによって中身が違う。
「入店時間」なんて、定義が違うどころか“概念がないPOS”もある。

つまり、POSのRAWは「データ」じゃない。
現場で起きた出来事を、各社が勝手な方言で記録したログなんです。

---

なぜエンジニアが詰むのか：能力の問題じゃなく、前提が違う

ここで誤解が起きやすいので先に言います。

これは「エンジニアがダメ」という話じゃありません。
むしろ逆で、普通のエンジニアが詰むのは当たり前です。

なぜなら、POSのRAWを読む作業は、

“データを見る”作業ではなく
“現場のシーンを復元する”作業

だからです。

たとえば「取消」。

• オーダー前の取消なのか
• 会計直前のVOIDなのか
• 締め後の返品なのか

この違いは、テーブルの上では似た記号で出てくる。
でも現場の意味はまるで違う。

「値引き」も同じです。

• 明細値引き
• 伝票値引き
• クーポン
• サービス料の調整
• ポイント充当（“値引き”に見えるが実態は別）

現場では、どれも“値引きっぽいこと”として処理される。
でも管理会計での意味は違う。財務でも違う。施策評価では致命的に違う。

この“意味”の違いを読み違えた瞬間、統一集計は崩壊します。

だから僕はよくこう言います。

「POSのRAWは、現場が分からないと解けない」
「データだけ見ても解けない」

---

じゃあ、なぜ僕が解けたのか：データを見ると“店の映像”が浮かぶから

ここがこのコラムのタイトルの核心です。

僕は最初、この解読作業をエンジニアにお願いしました。
でも、誰もできなかった。これは責められない。理由がある。

エンジニアはデータだけを見て、論理的に推測しようとする。
でもPOSのRAWは、推測が通らない世界です。現場運用の癖が混ざるから。

一方で僕は、データを見ると、

• その時、店で何が起きたか
• スタッフがどの画面で何を押したか
• 締めのタイミングで何がズレたか
• どこで“事故”が起きやすいか

そういう現場のシーンが映像みたいに浮かぶ。

これが、決定的な差でした。

だから僕は、データベース言語（SQLみたいなやつ）を独学で勉強して、
自分で解読を始めました。

この話、努力自慢に聞こえるかもしれませんが、違います。
大事なのは「努力した」じゃなくて、

現場の文脈があると、解読できる
現場の文脈がないと、解読が不可能になる

という構造の話です。

そしてこの構造こそが、飲食・小売の“データの闇”の正体だと思っています。

---

ここからTEAL Gatewayが生まれた：僕らがやっているのは「翻訳」＋「検算」

こういう背景があって、僕らはTEAL Gatewayを作りました。

やっていることを一言で言うと、

「各社バラバラのPOSのRAWを、共通の意味に翻訳する」

です。

でも翻訳だけだと、世の中には“それっぽい変換”が溢れる。
変換はできても、数字が合わない。運用に耐えない。

だから僕が絶対に譲らなかったのが 検算 です。

• POSから直接取った数字
• 変換後にこちらで再計算した数字

これを突き合わせて、誤差を潰す。
つまり「翻訳」だけではなく「正しさを保証するゲート」を作る。

この工程を毎日回して初めて、複数POS・複数ブランドでも
“同じ基準の数字”が出せるようになります。

---

業界が長年ハマってきた“地獄”も、ここに原因がある

ここも避けずに言います。

飲食・小売の世界では昔から、
売上管理システム側が“独自フォーマット”を乱立させてきました。

その結果、POSメーカーは導入先ごとに「謎フォーマット」変換を強いられ疲弊し、
飲食店側は粒度が粗く不正確なデータしか手に入らない。

誰も幸せにならない開発コストが積み上がってきた。

これが、いわゆるベンダーロックインを生み、
「POSを自由に選べない」構造を固定化してきたと僕は見ています。

---

だから僕はOFSCでやる：これは1社の技術で終わらせちゃダメ

最後に、これを“ティールの商売話”で終わらせたくない理由があります。

この問題は、1社が頑張っても業界全体は変わりません。
「標準」が必要です。しかも紙の仕様書ではなく、実装を前提にした標準が。

だからOFSCと組む。
ここは単なる“お墨付き”ではなく、業界としてのルール作りに踏み込む。

僕の感覚では、ここから先は、

• POSベンダーが個別開発の悪夢から解放される
• 飲食店が自由にPOSを選べるようになる
• その結果、データ連携が前提のイノベーションが増える

こういう未来につながります。

---

まとめ：この話のポイントは「僕がすごい」じゃない

このコラムで一番伝えたいことは、ここです。

• POSのRAW解読は、純粋なエンジニアリング勝負ではない
• 現場の文脈×データ構造が合体したときにだけ解ける
• だからこそ、飲食の現場を知る人間が“標準化の当事者”になる必要がある

次回は、この続きとして
「同じ“売上”という言葉が、なぜ会社やPOSによって別の数字になるのか」
（総売上／純売上／税／値引き／金券／ポイント／取消／返品）
ここを具体例で分解して、“統一集計”の腹落ちまで持っていきます。

---