UX 分析13分で読めます

ダイニー(dinii)UX構造分析 — QRモバイルオーダーから飲食店OSへ、2,000万ユーザー・解約率0.5%未満を築いた「来店客のスマホ起点」設計の解剖

テクラル研究所 編集部

テクラル研究所 編集部

テクラル研究所

#ダイニー#モバイルオーダー#飲食店DX#バーティカルSaaS#UX分析#LINEミニアプリ#セルフオーダー#店舗OS#収益化設計
ダイニー(dinii)UX構造分析 — QRモバイルオーダーから飲食店OSへ、2,000万ユーザー・解約率0.5%未満を築いた「来店客のスマホ起点」設計の解剖

ダイニー(dinii)が2,000万ユーザー・解約率0.5%未満を築けた最大の要因は、「来店客のスマホを店舗データの入口にした」一点に集約される。テーブルのQRコードを読むだけで、専用アプリのダウンロードも会員登録もなしに注文が始まり、その瞬間に客は店舗の顧客データへ取り込まれる。注文という「客が必ず行う動作」をデータ収集の起点に変えたことで、ダイニーはモバイルオーダー単体のツールから、POS・CRM・決済・勤怠・経営管理を束ねる「飲食店OS」へと拡張する土台を得た。本稿は、この設計判断を縦(バーティカル)SaaSの観点で解剖し、自社プロダクトに転用できる原理を抽出する。

対象読者は、飲食をはじめとする店舗向けSaaSを設計する事業者・PdM、あるいは店舗DXを企画する新規事業担当者である。ダイニーの「アプリを作らない」「注文を起点にする」「単機能から面を取りに行く」という三つの判断は、特定業種に閉じず縦SaaS全般に展開できる。数字はシリーズBの調達情報・公開インタビュー・App Store情報に基づく。

ダイニーとは何か — モバイルオーダーから飲食店OSへ拡張した縦SaaS

ダイニーは、飲食店向けに「ダイニーモバイルオーダー」と「ダイニーレジ(POS)」を軸に、顧客管理・キャッシュレス決済・勤怠・経営管理までを統合する飲食店向けSaaSである。結論から言えば、ダイニーの本質はモバイルオーダーの会社ではなく、来店客のスマホ起点で集めたデータを店舗運営の全機能に流し込む「店舗OS」を志向している点にある。

数字で見ると、ダイニーモバイルオーダーの累計利用者は2024年10月時点で2,000万人を突破した。2024年9月にはBessemer Venture PartnersとHillhouse Investmentを共同リードに、Flight Deckなど海外投資家のみからシリーズB総額74.6億円を調達している。解約率は0.5%未満、売上高は2024年に約20億円規模まで成長しており、2023年の約6.8億円から急拡大している。店舗網も拡大しており、決済サービス「ダイニーキャッシュレス」だけでも2025年初頭に4,000店舗を超えたと公表されている。

注目すべきは拡張の順序だ。多くの店舗向けプロダクトはPOS(レジ)という「店の中核業務」から入って周辺機能へ広げる。ダイニーは逆に、来店客が触る「注文画面」という末端のUXから入り、そこで集めたデータを武器にPOS・CRM・決済へと面を広げた。末端から中核へ攻め上がる経路を選んだ点が、この縦SaaSの設計上の特徴である。

ダイニーの機能レイヤー図。来店客向けQRモバイルオーダーを起点に店舗レジ・経営管理・決済・顧客管理・勤怠が1つの面につながる飲食店OSの構造

示唆:縦SaaSで「面(OS化)」を取りに行くとき、最初に押さえるべきは中核業務の機能とは限らない。客が必ず触る末端のUXを起点に、そこを通る全データを握れる設計なら、後から中核業務へ拡張する正当性が立つ。

なぜ専用アプリを作らなかったのか — QRとLINEミニアプリで「ダウンロード障壁ゼロ」を選んだ判断

ダイニーが専用アプリを作らず、QRコード+LINEミニアプリで注文体験を組んだ判断は、来店客の離脱を最小化するための合理的選択だった。飲食店の店内注文は「席に着いてから数分以内に注文したい」という極端に短い時間軸のUXであり、ここでアプリのダウンロードや会員登録を挟むと、客の大半が離脱する。専用アプリを配るほど来店客は使わない、というのがこの業態の構造的な制約である。

ダイニーの注文フローは、テーブルのQRコードをスマホのカメラで読み取ると、LINEミニアプリ上に店舗のメニュー画面が立ち上がり、そのまま注文できる。アプリのインストールも、メールアドレスやパスワードの新規登録も発生しない。日本でほぼ全世代が日常的に使うLINEの基盤に相乗りすることで、「初回の客でも数タップで注文が完了する」状態を作っている。実際、導入店舗では来店客の約8割がモバイルオーダーを利用すると公表されており、専用アプリ方式では到達しにくい利用率に届いている。

この判断には二重の利得がある。第一に、来店客側のダウンロード障壁がゼロになり、初回注文の完了率が上がる。第二に、注文と同時にLINE IDと紐づくため、店側は何の追加操作もなく顧客データ(来店頻度・注文履歴)を蓄積できる。「客にとっての手間の少なさ」と「店にとってのデータ取得」が、同じ一つの設計で同時に達成されている。

ダイニーレジアプリのApp Store掲載画面。店舗スタッフ向けの会計・売上管理・レジ精算の画面

裏を返せば、これはプラットフォーム依存というリスクも抱える。LINEのミニアプリ仕様や手数料体系が変われば影響を受ける。それでもダイニーがこの経路を選んだのは、自前アプリの普及コストとダウンロード離脱の損失が、プラットフォーム依存のリスクを上回ると判断したからだと読める。

観点 専用アプリ方式 ダイニー(LINEミニアプリ起点)
来店客の初回ハードル DL・会員登録・ログインの3段 QR読み取りのみ(DL不要)
注文までの離脱 入口で発生しやすい 入口の摩擦が小さい
顧客データの取得 アプリ会員のみ LINE IDに自動で紐づく
立ち上げコストの負担者 自社でDL獲得 LINE基盤を活用し軽い
想定利用率 限定的 導入店舗で約8割

示唆:来店・店頭のような「滞在時間が短く再訪頻度が読めない」接点では、専用アプリは資産ではなく障壁になりうる。既存の認証基盤(LINE・Apple/Google)に相乗りして摩擦をゼロに近づけ、自社は「その上に乗るデータと業務ロジック」で差別化する設計を検討する価値がある。

注文を起点にしたデータループ — 「客が必ず行う動作」をCRMの入口にする設計

ダイニーの収益化を支える中核は、注文という動作をそのままCRMの入口に変換するデータループにある。結論として、ダイニーが単なる注文ツールに留まらないのは、注文のたびに「誰が・いつ・何を・何回目に」頼んだかが自動で蓄積され、それが販促・接客・経営判断へ循環する構造を組んだからである。

ループはこう回る。客がQRから注文する → LINE IDで店舗に紐づく → 注文・来店データが顧客ごとに蓄積される → 来店頻度や注文履歴でセグメント配信される → 再来店が促される → また注文データが増える。注文という最も頻度の高い動作をループの起点に置いたことで、店側が能動的にデータ入力をしなくてもCRMが育つ。

ダイニーの注文起点データループ図。QR注文→LINE IDで顧客紐づけ→注文データ蓄積→セグメント配信→再来店と循環する構造

ここで重要なのは、データ入力の「主体」を客に移している点だ。従来のCRMは店員がレジで会員カードを尋ね、客が登録する手間を負わせる設計が多かった。ダイニーは注文という客が必ず行う動作にデータ取得を埋め込み、店員のオペレーション負荷も客の登録負荷もかけずにデータを集める。これがデータ量と継続率の両方を押し上げている。

示唆:CRMやデータ基盤を設計するとき、「誰にデータ入力をさせるか」は継続率を左右する。ユーザーが目的のために必ず行う高頻度の動作(注文・予約・チェックイン等)にデータ取得を埋め込めれば、追加の入力作業を求めずにデータが育ち、解約の主因である「入力が面倒」を回避できる。

「推しエール」——来店客のスマホを店舗の収益・人材装置に変えた設計

ダイニーが注文画面に組み込んだ投げ銭機能「推しエール」は、来店客のスマホを単なる注文端末から「スタッフへの送金装置」に変えた象徴的な設計である。モバイルオーダーの注文画面に出勤中のスタッフと投げ銭ボタンが表示され、来店客はその場でスタッフにチップを送れる。

この機能が効くのは、入口がLINEミニアプリで決済まで地続きだからだ。専用アプリのDLや別途の決済登録が必要なら、チップを送る摩擦が高すぎて成立しない。注文・決済・スタッフ表示が同じ面に乗っているからこそ、来店客の約1割が推しエールを使い、その多くが次回来店でも使うという継続利用が生まれる。1ヶ月で64,900円を獲得したスタッフの事例も公開されている。

ダイニーモバイルオーダーのLINEミニアプリ注文画面とテーブルQR→注文→投げ銭のフロー。来店客向けの注文体験

事業者目線で見ると、推しエールは「店舗の人手不足・離職」という別の経営課題に対する打ち手でもある。スタッフのモチベーションと定着に直接効く機能を、来店客の注文体験の中に自然に埋め込んでいる。注文UXの設計が、店舗の人材課題まで射程に入れている点が示唆的だ。

示唆:収益化の機会は、必ずしも「機能の有料化」ではない。既に作った接点(注文画面)の上に、摩擦なく置ける新しいお金の流れ(チップ)を載せられないかを問う。地続きの決済基盤があるほど、新しい収益装置を後から足しやすい。

解約率0.5%未満を支える構造 — スイッチングコストと拡張戦略

ダイニーの解約率0.5%未満という数字は、単機能の使い勝手だけでなく、店舗業務に深く食い込んだスイッチングコストで説明できる。結論として、客の入口(注文)から店の出口(経営判断)まで一気通貫で握っているため、ダイニーを外すと店舗オペレーション全体を組み直す必要が生じ、乗り換え障壁が高い。

ダイニーがモバイルオーダーから飲食店OSへ面を広げられたのは、「注文に隣接する業務」を一つずつ畳み込む順序設計が効いている。いきなり全機能のスイートを売るのではなく、来店客のスマホ起点で得たデータと信頼を足場に、注文 → POS → 顧客管理 → 決済 → 勤怠・経営管理へと隣接領域を順に取り込んだ。各レイヤーは前のレイヤーで集めたデータを再利用する関係にあり、注文データがあるからPOSの精度が上がり、注文と紐づく顧客データがあるからCRMが機能し、注文・原価・人件費が一基盤に乗るから経営管理が成立する。各機能が独立した「寄せ集めスイート」ではなく、注文起点のデータを共有する「層」として積み上がっている点が、横並びの多機能ツールとの違いである。

ダイニーの拡張順序図。注文→POS→顧客管理→決済→勤怠・経営管理へと隣接業務を畳み込む縦SaaSの拡張タイムライン

モバイルオーダー単体なら他社へ乗り換えられても、ダイニーの場合は注文・POS・顧客データ・決済・販促が同一基盤に乗っている。解約は「注文ツールを替える」ではなく「店舗の業務システム全体を入れ替える」になる。OS化が進むほど、外すコストが上がる。

要素 一般的なモバイルオーダー単機能ツール ダイニー(飲食店OS型)
来店客の利用開始 専用アプリDL・会員登録が必要な場合あり QR読取+LINEミニアプリ、DL・登録不要
カバー範囲 注文・決済中心 注文・POS・CRM・決済・勤怠・経営管理
データ蓄積の主体 店員の手入力に依存しがち 注文動作に埋め込み自動蓄積
解約時の影響 注文ツールの差し替え 店舗業務システム全体の入れ替え

注:機能範囲はダイニー公表情報および公開情報に基づく整理であり、競合各社の実装は個別に異なる。

示唆:解約率を下げる最も強い構造は「機能の良さ」ではなく「外したときの再構築コストの高さ」である。単機能で勝負するうちは価格と機能で比較され続けるが、業務フローの複数工程を一基盤で握れば、比較の土俵そのものが「乗り換えコスト」へ移る。縦SaaSでOS化を狙う意味はここにある。

縦SaaSとして見たダイニーの収益化構造 — どこで稼ぐ余地が生まれるか

ダイニーの収益化は、SaaS利用料に加えて、決済手数料という取引連動の収益源を重ねられる構造に強みがある。結論として、注文・決済が同一基盤を通るため、店舗の取引高そのものが収益基盤になり、月額固定だけに依存しない収益の階層を作れる。

縦SaaSの収益化は一般に、(1)月額のSaaS利用料、(2)取引高に連動する決済・手数料収益、(3)蓄積データを使った販促などの付加価値収益、の三層で考えると整理しやすい。ダイニーは注文・POS・決済を束ねているため、(1)に加えて(2)の取引連動収益を取りに行ける位置にいる。決済を自社で握ると、店舗の売上が伸びるほど自社の手数料収益も伸びる構造になり、店舗の成長と提供元の成長が連動する。

さらに、注文起点で溜まる顧客データは(3)の付加価値収益の原資になる。販促配信や来店データの分析は、店舗にとっての売上装置であると同時に、提供元にとっては固定料金の外側で価値を出せる領域である。データを持っているからこそ、価格を機能の対価から成果の対価へ近づけられる。

収益レイヤー 内容 取りに行ける条件
SaaS利用料 モバイルオーダー・POS等の月額 機能を提供していれば成立
取引連動収益 決済手数料など売上に連動 注文・決済を自社基盤に通していること
データ付加価値 販促配信・分析などの上乗せ 注文起点で顧客データを蓄積していること

注:収益レイヤーの整理は縦SaaS一般のフレームに基づく分析であり、各収益の具体的な比率はダイニー非公表のため推定を含まない。

示唆:縦SaaSで収益の天井を上げたいなら、「機能で月額をもらう」だけでなく「取引が自社基盤を通る」状態を作れるかを問うべきである。決済や予約のように顧客の取引そのものを通せる接点を握れば、固定料金の外に取引連動・データ連動の収益層を積める。注文を起点にデータと取引の両方を握ったダイニーは、その典型である。

自社プロダクトへの適用と、テクラル研究所が支援できること

ダイニーの解剖から、縦SaaS・店舗DXを設計する際に転用できる原理は三つに整理できる。第一に、来店・店頭のような短時間接点では専用アプリを資産と見なさず、既存認証基盤に相乗りして摩擦をゼロに近づける。第二に、ユーザーが必ず行う高頻度動作(注文・予約・チェックイン)にデータ取得を埋め込み、入力負荷なしでCRMを育てる。第三に、拡張は機能の数ではなくデータの再利用関係で順序を決め、隣接業務を層として畳み込んでOS化する。この三つは飲食に限らず、店舗・医療・教育・予約など縦の業種SaaS全般に展開できる。

これらは「あとから付け足す」ことが難しい設計判断である。どの動作をデータの起点にするか、どの順序で機能を畳み込むか、決済や取引をどこで自社基盤に通すかは、プロダクトの初期構造で決まる。逆に言えば、初期のUX設計と収益化設計を同時に詰められれば、ダイニーのように「客の摩擦が低く、解約しにくく、収益層が積める」プロダクトを狙える。

テクラル合同会社では、こうした縦SaaS・店舗DXの立ち上げを、UX設計と収益化設計を一体で詰めるところから支援しています。来店客や利用者のスマホを起点にしたデータループの設計、専用アプリを作るか既存認証基盤に乗るかの判断、単機能から面を取りに行く拡張順序の組み立て、決済・取引を自社基盤に通す収益化設計まで、構想段階のMVPから事業としての成長フェーズまで一気通貫で伴走しています。新規事業の構想・既存プロダクトのUX改善・収益化設計の見直しに取り組む事業責任者・PdM・経営者・新規事業担当者の方は、いずれの段階でもテクラル合同会社までお気軽にご相談ください。UX診断やMVP開発のご相談を承っています。

出典

この記事を書いた人

テクラル研究所 編集部

テクラル研究所 編集部

テクラル研究所

テクラル合同会社が運営する「テクラル研究所」の編集部。Web・アプリ・SaaS プロダクトの市場リサーチ、UI/UX 分析、収益化設計を専門領域に、開発会社ならではの「作る側の解像度」で記事と一次リサーチ資料(ホワイトペーパー)を発信しています。MVP 開発、SaaS 構築、AI 機能組み込みの現場知見を活かし、フレームワークと数値で語ることを編集方針としています。

関連レポート