最終回　飲食業の発注はAIで変わる｜なぜ飲食業SaaSはうまくいかないのか―発注管理はパッケージ化できない―

このシリーズ「飲食業の発注はAIで変わる」では、飲食業における需要予測と発注管理のあり方を、現場の業務構造から考えてきました。第1回では飲食業が自前で需要予測システムを作れる時代になったことを、第2回では需要予測に使われるデータの構造を、第3回では需要予測より難しい「発注管理」の設計を、そして第4回ではExcelを使った発注管理システムの実装を、それぞれ取り上げています。

ここまで読んでいただいた方の中には、こう思った方もいるかもしれません。

「それなら、飲食業向けのSaaSがたくさんあるのだから、それを導入すればよいのではないか」と。

確かにその通りです。POS、在庫管理、発注管理、需要予測など、飲食業向けのクラウドサービスは数多く存在します。しかし現実には、多くの飲食業の現場では、最終的にExcelと経験者の判断によって発注が行われています。高度なクラウドシステムが存在するにもかかわらず、です。

今回の補足回では、その理由を現場の業務構造から整理します。結論を先に述べると、飲食業のSaaSが定着しにくいのは、SaaSの品質が低いからではありません。飲食業の発注管理業務そのものが、標準化やパッケージ化に向いていない構造を持っているからです。

この記事の要点

• 飲食業の発注管理は標準化しにくい
• 需要予測だけでは発注は自動化できない
• 現場は商品ではなく食材単位で動いている
• 発注には計算だけでなく判断が必要
• そのためExcelが現場に残りやすい

飲食業DXがうまくいかない理由

飲食業のDXは、しばしば「システムを入れれば解決する」という前提で語られます。しかし、現場ではSaaSを導入したものの定着しなかった、あるいは結局Excelに戻ってしまったという声が少なくありません。これは飲食業に限った話ではありませんが、飲食業では特に顕著です。

その背景には、飲食業の業務そのものが持つ構造的な特性があります。会計ソフトや勤怠管理のように、どの企業でもほぼ同じフローで動いている業務であれば、SaaSは非常にうまく機能します。開発側が一つの標準モデルを作り、多くの企業がそれを使うことで、コストを抑えながら高機能なサービスを提供できるからです。

しかし飲食業の発注管理は、この前提が成り立ちません。店舗ごとにメニューが異なり、レシピが異なり、仕込みの方法が異なり、仕入先も納品タイミングも異なります。つまり、業務そのものが店舗ごとのオーダーメイドになっているのです。

たとえば、同じ居酒屋チェーンであっても、駅前の繁華街にある店舗と郊外のロードサイド店では、売れ筋メニューの構成が異なります。仕入先の配送ルートも違えば、冷蔵設備の規模も違う。当然、発注のタイミングや量の決め方も異なってきます。こうした店舗ごとの差異を「設定画面でカスタマイズできます」という範囲で吸収しようとしても、現実の業務の多様性には追いつけないことが多いのです。この点を理解しないまま「飲食業DX」を進めようとすると、システムと現場のあいだに大きなギャップが生まれます。

飲食業の業務は標準化されていない

SaaS、すなわちクラウド型の業務ソフトウェアは、基本的に「同じ業務、同じフロー、同じデータ構造」を前提として設計されます。会計処理であれば、仕訳の構造は企業ごとに大きくは変わりません。給与計算も、法定の計算ルールに基づいて処理される以上、基本的な流れは共通しています。こうした業務は標準化されているため、パッケージとして提供しやすいわけです。

ところが、飲食業の現場を見ると、この標準化の前提が根本から揺らぎます。

まずメニューが違います。和食の店とイタリアンの店では、扱う食材も調理工程もまったく異なります。同じジャンルの店であっても、レシピは店舗ごとに違うのが普通です。仕込みの方法も、前日に仕込むのか当日朝に仕込むのかで発注のタイミングが変わりますし、仕入先が卸売市場なのかメーカー直送なのかによって、発注ロットや納品リードタイムも異なります。在庫の持ち方にしても、冷蔵庫の容量や食材の回転率によって店舗ごとに方針が違います。

同じ「飲食業」というカテゴリに属していても、実際の業務オペレーションはまったく別物であることが珍しくないのです。SaaSにとって、この多様性は非常に大きな壁になります。標準的なテンプレートで対応しようとすると、どうしても現場の実態からずれてしまうからです。

需要予測より難しい「発注管理」

飲食業DXの話題では、「AI需要予測」という言葉がよく使われます。AIが来客数を予測し、売上を見積もり、発注を最適化するというイメージです。確かに需要予測そのものは重要な技術であり、本シリーズの第1回・第2回でも詳しく扱いました。

しかし、現場の発注業務に関わったことのある方であれば、問題の本質は予測の精度ではなく、その先にあることをご存じでしょう。それは「予測された売上を、どうやって具体的な発注量に変換するのか」という問題です。

たとえば、ある日の来客数が100人と予測できたとしましょう。しかし、それだけでは発注量は決まりません。100人の来客のうち、何人が唐揚げ定食を注文し、何人がカレーを注文し、何人がサラダを追加するのか。そしてそれぞれのメニューに対して、どの食材が何グラム必要なのか。この変換ができなければ、来客予測がいくら正確でも、発注量には落とし込めないのです。

この「売上予測から食材需要への変換」こそが、飲食業の発注管理の核心であり、第3回で詳しく論じた「発注管理の設計」が難しいと言われる最大の理由です。需要予測SaaSの多くは、この変換プロセスを十分にカバーできていません。なぜなら、変換のルールは店舗ごとに異なるからです。

厨房は商品ではなく食材で動いている

ここでもう一つ、飲食業の発注管理を難しくしている構造的な問題に触れておきます。それは、POSデータと厨房の管理単位がまったく異なるという問題です。

POSデータは、商品単位で記録されます。「唐揚げ定食15食、親子丼10食、カレー12食」という形です。しかし厨房では、商品単位ではなく食材単位で在庫を管理しています。「鶏肉が何キロ残っている」「玉ねぎがあと何個ある」「米の在庫があと何日分か」という考え方です。

つまり、POSの商品データを食材データに分解する工程が必要になります。これは製造業でいうところのBOM（Bill of Materials＝部品表）と同じ構造です。製造業であれば、ある製品を1台作るのに必要な部品のリストと数量がBOMとして管理されています。飲食業でも同様に、たとえば唐揚げ定食1食を作るには「鶏肉120g、キャベツ50g、米200g、片栗粉15g、揚げ油適量」というレシピ構造が存在するわけです。

問題は、このレシピ構造（＝BOM）が店舗ごとに完全に異なるという点です。同じ唐揚げ定食であっても、鶏肉の使用量はレシピによって違いますし、付け合わせの内容も店ごとに異なります。さらに、唐揚げ定食、唐揚げ単品、唐揚げ弁当という3つのメニューがあれば、同じ鶏肉を使っていても必要量や付け合わせの構成はそれぞれ違います。こうした食材展開の複雑さを、標準的なSaaSのテンプレートで吸収するのは極めて困難です。

発注は計算ではなく判断である

仮にレシピ構造を正確にシステムに登録し、売上予測から食材需要への変換がうまくいったとしても、実際の発注業務にはさらに多くの判断が介在します。

まず発注ロットの問題があります。たとえば鶏肉の必要量が計算上8.2kgだったとしましょう。しかし仕入先からの購入単位が1kgであれば、8kgか9kgかを選ばなければなりません。0.8kgの余剰を許容して9kg発注するのか、不足リスクを取って8kgに抑えるのか。翌日以降にも鶏肉を使うメニューがあるならば余剰分は繰り越せますが、使い切りの食材であれば余剰はそのまま廃棄コストになります。ここには単純な計算では導けない判断が入ります。

次に廃棄ロス率の問題があります。食材は仕入れた量がそのまま使える量になるとは限りません。野菜であれば皮をむいたり芯を取ったりする歩留まりがありますし、肉類でも筋や脂を除去する工程があります。このロス率もまた、食材の種類や仕入先の品質によって変わりますし、季節によっても変動します。

さらに、仕込みのタイミングと納品タイミングの整合も考慮しなければなりません。翌日の朝に仕込みを始める食材であれば、前日の夕方までに納品されている必要があります。しかし仕入先によっては、発注から納品まで2日かかる場合もあります。こうしたリードタイムの管理も、発注業務の一部です。

加えて、天候やイベント、曜日による売上変動の見込みを発注量に反映させる作業があります。台風が来るなら来客は減るでしょうし、近隣でイベントがあれば増えるかもしれません。こうした要素は、データとして定型化しにくく、現場責任者の経験に基づく判断に頼らざるを得ない部分が残ります。

つまり、飲食業における発注とは、計算だけで完結する業務ではなく、複数の変数と例外を考慮した「判断」を含む業務なのです。

なぜ現場ではExcelが使われ続けるのか

ここまでの議論を踏まえると、飲食業の現場でExcelが根強く使われ続けている理由が見えてきます。

SaaSは標準化・単純化・自動化を基本方針としています。多くのユーザーに共通する業務フローを一つのパッケージにまとめ、スケールメリットを出すのがSaaSのビジネスモデルだからです。しかし飲食業の発注管理は、店舗ごとに業務が違い、例外が多く、現場の判断が不可欠であるという、SaaSが最も苦手とする性質を併せ持っています。

その結果、SaaSを導入した現場では「この店のやり方に合わない」「細かい設定ができない」「結局Excelのほうが早い」という声が上がりやすくなります。これはSaaSの品質が悪いのではなく、業務構造とSaaSのアーキテクチャのあいだに構造的な不一致があるために起こる現象です。

一方、Excelには次のような特性があります。店舗ごとに自由にシートを設計できること、レシピ構造（BOM）を自由に組めること、発注ロットの丸め処理やロス率の係数を個別に設定できること、そして現場の判断を数式やセルの上書きで柔軟に反映できることです。つまり、Excelはオーダーメイドの業務構造に対応できる柔軟性を持っている。これが、飲食業の現場でExcelが残り続ける合理的な理由です。

実際、多くの飲食業の現場では、POSからデータを取り出し、Excelで加工し、現場責任者の経験を加味して発注量を決定するという運用が行われています。この「POS＋Excel＋経験」の組み合わせは、一見するとアナログに見えますが、業務の構造を考えれば、実はかなり合理的な仕組みと言えるでしょう。

AI時代はむしろ自作システムが増える

ここで、もう一つ重要な変化について触れておきます。それはAIの普及がもたらす、業務システムのあり方の変化です。

これまで、自社の業務に合ったシステムを構築しようとすれば、プログラミングの知識が必要であり、外注すれば高額な開発費がかかりました。だからこそ、多少の不一致を我慢してでもSaaSを使う、という選択が合理的だったわけです。

しかし現在では、AIを活用することで、Excelやスプレッドシートをベースにした業務システムを、専門知識がなくてもかなり高度なレベルで構築できるようになっています。本シリーズの第4回で紹介した「Excelで発注管理システムを作る」という方法は、まさにこの流れの中に位置づけられます。

需要予測のモデルを組み、レシピ構造を登録し、発注ロットやロス率を反映した発注量の自動計算を行う。こうした仕組みを、高額なシステム開発費をかけずに、自社の業務に完全にフィットする形で構築できる。これはAI時代だからこそ可能になった選択肢です。

しかも、自作のシステムであれば、業務の変化にも柔軟に対応できます。メニューが変わればレシピ構造を修正すればよいですし、仕入先が変わればロットや納品条件を書き換えればよい。SaaSでは設定変更にベンダーへの問い合わせが必要になる場合がありますが、Excelベースのシステムであれば、現場の担当者が自分で修正できます。この「自分で直せる」という特性は、日々変化する飲食業の現場においては極めて重要な要素です。

特に飲食業のように、店舗ごとの業務の個別性が高い業界では、「汎用的なSaaSを導入する」よりも「自分の業務に合わせたシステムを自作する」ほうが、結果的に定着しやすく、コストパフォーマンスも高くなる可能性があります。もちろん、POSや会計のように標準化に向いた領域ではSaaSが適していますし、SaaSの全体を否定するつもりはありません。重要なのは、業務の性質に応じてツールを使い分けるという視点です。

まとめ

飲食業向けSaaSが現場で定着しにくい理由は、技術の問題でもSaaSの品質の問題でもありません。飲食業の発注管理という業務そのものが、標準化やパッケージ化に向いていない構造を持っていることが根本的な原因です。

店舗ごとにメニューもレシピも異なり、POSデータは商品単位であるのに対して厨房は食材単位で動いており、発注には数量計算だけでなくロット調整やロス率の見積もり、天候やイベントなどを考慮した現場の判断が不可欠です。こうした業務構造は、SaaSが前提とする標準化モデルとは本質的に噛み合いにくいのです。

だからこそ、飲食業の現場ではExcelを中心とした柔軟な運用が残り続けてきましたし、AI時代を迎えた今、その延長線上に「自社の業務に合わせた半自作システム」という現実的な選択肢が生まれつつあります。

では、実際にExcelで「売上予測→食材需要→発注量」の変換をどのように設計すればよいのか。次回の第4回では、その具体的なモデル構造を紹介します。飲食業の発注業務をどう構造化し、どのようにシステムに落とし込むのか、実践的に見ていきましょう。

シリーズ：飲食業の発注はAIで変わる

• 第1回　飲食業は自前で需要予測システムを作れる時代になった
• 第2回　需要予測はどんなデータでできているのか
• 第3回　需要予測より難しい「発注管理」の設計
• 第4回　AI需要予測を現場で使う―Excelで発注管理システムを作る
• 最終回　なぜ飲食業SaaSはうまくいかないのか（この記事）