冒頭の例話：同じ「売上1,000万円」なのに、会議が荒れる日

ある飲食企業が、M&Aで店舗数を一気に増やしました。
AブランドはPOSベンダーX、BブランドはPOSベンダーY、Cブランドは券売機系でZ。
本部は「全店の売上を同じダッシュボードで見たい」と言い、各店舗から日次データを集めて、BIで横串のレポートを作り始めました。

最初の1週間は、見た目はうまくいっているように見えました。
UI（画面）は整っている。グラフも綺麗。店舗も「見やすい」と言う。

ところが、月末の役員会で事件が起きます。

• 店長が言う「レジの日計」と、BIの「日次売上」が合わない
• 経理が言う「会計の売上」と、BIの「売上」が合わない
• さらに厄介なのが、店舗によってズレ方が違う

「BIが間違ってるのか？」「いやPOSが違うからだ」「経理の締め処理のせいだ」
会議は“犯人探し”になり、誰も得をしない空気だけが残る。

ここで気づくべき本質は、こうです。

画面（UI）を揃えても、標準化は進まない。
本当に揃えるべきは、トランザクションの意味解釈＝集計ロジックである。

---

なぜUIではなく「集計ロジック」が本丸なのか

飲食の現場で日々起きている取引（トランザクション）は、見た目以上に“クセ”があります。
しかも、そのクセはPOSベンダーや店舗運用によって、平気で変わります。

たとえば、同じ「値引き」でも、

• 商品単位の値引き（明細に紐づく）
• 伝票全体の値引き（小計に対して）
• クーポン値引き（販促費扱いにしたい場合もある）
• サービス料を値引きするのか、しないのか

同じ「取消」でも、

• オーダー取り消し（キッチンに行く前）
• 会計取消（締め直前のVoid）
• 返品（Refund：締め後のマイナス取引）

同じ「税」でも、

• 内税・外税
• 端数処理（切り捨て／切り上げ／四捨五入）
• 店舗単位で処理するのか、伝票単位で処理するのか

こういう“意味の違い”が、最終的な売上や客単価の差になって表れます。

つまり、標準化とは「項目名を揃えること」ではなく、

何を売上に含め、何を除外し、
どの時点の取引を採用し、
どう丸め、どう分類するか

…という集計の定義（ルール）を揃えることです。

---

“標準化が進まない”最大の理由：議論の焦点がズレている

業界の標準化議論は、どうしても以下に寄りがちです。

• 「このカラム名は何にする？」
• 「このフォーマットはCSVかJSONか？」
• 「どの画面で見せる？」

もちろん必要です。が、これは標準化の“最後の工程”です。
UIやフォーマットは、いわば「翻訳後の文章の体裁」にすぎません。

翻訳の辞書（意味）が揃っていなければ、どれだけ綺麗な文章に整えても、内容がズレます。

---

集計ロジックとは何か：ざっくり定義すると「KPIの作り方の憲法」

ここで言う集計ロジックは、単なる計算式ではありません。
飲食のKPIを作るための「採用ルール」「分類ルール」「補正ルール」のセットです。

例：よくズレる論点（これが標準化の核心）

• 売上（Sales）は何を指す？
  税抜？税込？サービス料込み？割引前？割引後？
• 値引き（Discount）の扱い
  売上のマイナスとして扱う？販促費として別建て？
• 取消（Void）と返品（Refund）の区別
  オペミスなのか、顧客都合なのか、締め後なのか
• 支払（Tender）の扱い
  現金・カード・QR・ギフト・ポイント充当…をどう分類する？
• 売上日（Business Date）の定義
  25時の会計は当日？翌日？
  営業日締めの境界をどう置く？

---

OFSCで“やるべき標準化”はこれ：共通の集計定義（＝共通言語）を策定する

OFSC（そしてOFSCゲートウェイ）が本気で価値を出すなら、次が王道です。

1) 共通の「取引モデル」を定義する（イベントの骨格）

最低限、以下が矛盾なく表現できるモデルが必要です。

• 伝票（Transaction）
• 商品明細（Line Items）
• 調整（Adjustments：割引、サービス料、クーポン、税）
• 支払明細（Tenders：現金、カード、QR、ポイント、ギフト等）
• 状態遷移（作成→更新→取消→返品…）

ここが「標準フォーマット」の真の意味です。
“列を揃える”ではなく、“取引の構造を揃える”。

2) KPIごとに「算定の定義」を明文化する（ここが本丸）

そして、ここからが重要です。
KPI（売上、客数、客単価、値引率、取消率…）は、**式よりも前に「採用ルール」**が必要です。

---

すぐ使える形に落とす：KPI標準化のチェック表

KPI	“式”より先に決めるべきこと	ここがズレるとどうなる？
売上	税・サービス料・割引・クーポン・ポイント充当の扱い	店舗ごとに売上が合わない／前年差が歪む
客数	伝票の人数？明細の数量？テイクアウトの扱い？	客単価が崩壊する／繁忙分析が嘘になる
値引率	値引きを売上控除にするか、別費目にするか	“施策の効果”評価が逆転する
取消率	VoidとRefundを分けるか、営業日を跨ぐ扱い	不正検知や教育指標が使い物にならない
支払構成	QR・ギフト・ポイント・売掛の分類	決済手数料や資金繰り予測がズレる

この表に入る論点を、OFSCとして「共通定義」にしていく。
これが、標準化の“仕事”です。

---

じゃあTEAL Gateway／OFSCゲートウェイは何をするのか

ここまでの話は「思想」ではなく、実装に落とせます。
むしろ、実装まで落とした瞬間に標準化は強くなる。

TEAL Gateway（およびOFSCゲートウェイ）が担う役割は、シンプルに言うと：

POSごとのRAW（生データ）を、
共通の取引モデルに翻訳し、
共通の集計ロジックで再計算して、
誰が見ても同じ数字を出す

つまり「翻訳機＋検算機」です。

UIはその“結果”として自然に揃います。
順序が逆なんです。UIから揃えようとすると崩れます。

---

結論：標準化とは「見せ方」ではなく「意味」を揃える作業

飲食のデータ標準化は、言い換えると「同じ言葉で会話できる世界を作る」ことです。
ここでの“言葉”とは、カラム名ではなく、数字の意味です。

• 売上とは何か
• 客数とは何か
• 値引きとは何か
• 取消とは何か
• 営業日とはどこで区切るか

これが揃ったとき、初めて“業界で使える標準”になります。
そして、その標準を実装として配れるのが、ゲートウェイの価値です。