Tabelog Tech Blog

食べログの開発者による技術ブログです

食べログオーダーが推進する飲食店DX

はじめに

こんにちは。食べログオーダーチーム開発エンジニアの高山です。

食べログオーダーは食べログが取り組むモバイルオーダーサービスです。
2022年にサービスローンチし、おかげ様で多くの店舗様にご利用いただいております。
まだリリースしてから日が浅いということもあり、食べログオーダーの認知度はまだまだ高いとは言えない状況です。
そこで、私はいち開発エンジニアという立場ではありますが、なぜ食べログがモバイルオーダー事業を始めたのか、 食べログオーダーを通じて目指す世界観、そして開発体制や技術スタックなどについてご紹介させていただきます。

目次

なぜモバイルオーダーなのか

店舗の売上に直結するDXとしてのモバイルオーダー

私たちは、店舗様の利益を向上させ、お客様に新しい外食体験をしていただくという基本理念の元で飲食店DXを推めています。
そして飲食店DXで店舗の利益を上げるために徹底すべき鉄則として以下を掲げています。

  • 店舗の売上に直結するDXから考える
  • 店舗の売上に直結するDXを起点に全体最適化する
  • 導入にあたってオペレーション変更までやりきる


ここで店舗の売上に直結するDXとしてフォーカスされたのがモバイルオーダーです。
モバイルオーダーにフォーカスしている理由としては以下になります。

これはモバイルオーダーにフォーカスしている理由を説明した画像です。


私たちは、今後5年でモバイルオーダーはネット予約に次ぐ飲食業界のスタンダードになると考えています。
なぜなら、店舗様とお客様の両者の課題を解決し、また先行している国では既にスタンダートとなっているからです。
ここまでが私たちがモバイルオーダーをセレクトした背景になります。

モバイルオーダーを起点としたDXの全体最適化

次に店舗の売上に直結するDXを起点に全体最適化を考えていくことが重要であると私たちは考えます。
その一例として、売上を上げることを目的とした際に、特に重要となる予約受付⇒予約管理⇒注文⇒会計という流れを例に、 全体最適できている状態とできていない状態を紹介致します。

以下は私たちが店舗様とお話しする中でよく目にする全体最適化できていない例です。 これは全体最適化できていない例を説明した画像です。

上図では予約受付から会計までそれぞれの領域ではしっかりとITツールを導入しデジタル化できていますが、 データや業務の連携が分断されている。という状態を表現しています。
この状態だとどうなるかというと、例えばお客様が来店された際には、まずオンライン台帳を見て予約が入っていないかを確認して来店登録をし、 その後ハンディ端末で注文を受ける際にもどの席の注文かを登録するというような対応になります。
データが連携できていないので店舗スタッフが突き合わせを行う必要があります。
また、オンライン台帳と予約受付が連携されていないため、グルメメディア毎に予約受付の管理が必要になり、結果ネットでの予約は部分的にしか実施できないようになります。
SNSでの予約もピーク時間に電話で予約連絡がきたりDMで予約連絡きたりと手間がかかります。 このようなお客様は私たちがお話させていただく中でもかなり多いと感じています。

これが最適化された状態になりますと以下のようになります。
予約受付から会計までデータや業務の連携ができている状態になります。 これは全体最適化できている例を説明した画像です。

オンライン台帳は各種グルメサイトやSNSに載せているネット予約と連携されているため、自動的に配席まで取り込めるようになっています。
お客様が来店されたときには、ハンディ端末へ予約情報が連携されているので、いちいち予約台帳を確認することなくハンディだけ見てご案内できます。
ご予約のないお客様が来店された場合にも、ハンディで配席して注文を受け付けることで、オンライン予約台帳を操作せずとも自動的に配席状態にできます。

オンライン台帳を少し具体的に見てみましょう。 これはオンライン台帳を説明した画像です。

仮に今が19時だとしますと、この黄色く塗っている時間と座席はまだお客様がご案内可能という状態になるので、この座席を少しでも埋められるように、この座席が自動的にグルメサイト/SNSでネット予約受付できるように自動更新されます。
そうすることで、二回転目含めてお客様を最大限集客することが可能です。
今回は予約受付⇒予約管理⇒注文⇒会計という流れについての説明でしたが、このように全体最適でDXをする場合、例えばネット予約に関しては『管理をする』という概念はほぼ発生しなくなります。
営業時間中は予約台帳や各社の管理画面はほとんど見なくてよくなります。これが全体最適でDXされたときの効果になります。

目指す世界観

私たちは食べログオーダー並びに食べログプロダクト群をお使いいただくことで、お客様及び店舗様にシームレスな顧客体験を提供することを目指しています。
グルメサイトは食べログのサービスを。オンライン台帳は食べログノートのサービスへと連携することで、全体最適化されたDXをスムーズに提案できるようになります。

以下はお客様視点での顧客体験を表す世界観になります。 これはお客様視点での顧客体験の世界観を説明した画像です。

また、以下は店舗様視点での顧客体験を表しています。 これは店舗様視点での顧客体験の世界観を説明した画像です。

冒頭での説明が長くなりましたが以上がなぜモバイルオーダーなのか、そしてモバイルオーダーを起点とした飲食店DXのビジョンとなります。

食べログオーダーの誕生

店舗の売上に直結するDXとして私たちはモバイルオーダーを選択しました。
そこで生まれたのが食べログオーダーになります。
モバイルオーダーの使い方は、主に「店内注文に利用する」か「事前注文に利用する」かの2通りに分かれますが、 食べログオーダーでは現在店内注文においての利用に絞ってサービス改善を進めています。
今後は店外からの事前注文においても対応していく予定です。

来店から注文、会計の利用イメージは以下のようになります。

これは来店から注文の流れのイメージ画像です。

これは会計までの流れのイメージ画像です。

注文や会計手続きが店舗スタッフを介さないため、 店舗様はオペレーション効率が良くなり、お客様は来店から会計までのあらゆる待ち時間を削減できます。

開発したプロダクト

私たちが開発したプロダクトは以下の3つになります。

これは私たちが開発したプロダクトを説明した画像です。

  • ユーザーWeb
    来店したお客様が自身のスマートフォン上でメニューの閲覧・注文操作が可能なWebサービスです。
  • 店舗専用アプリ
    店舗スタッフが利用するiOSネイティブアプリです。
    配席・注文管理を行うハンディターミナルモードと、プリンタへ印刷処理を行うプリンターコントローラモードで構成されます。
  • 店舗管理Web
    店舗スタッフやオーナーがメニュー情報などの設定を行うためのWebサービスです。


ユーザーWebから行われた注文が注文伝票として印字されるまでのフローは以下のようになっています。

これはユーザーWebから行われた注文が注文伝票として印字されるまでのフローを説明した画像です。

Firestoreについては、「FirestoreによるPush型の情報パイプライン設計と運用 in 食べログオーダー」 という題目で過去に本ブログで紹介させていただきました。
こちらも是非ご覧ください。

技術スタック

食べログオーダーで採用している技術スタックは以下です。

Category Technology Stack
Programming Languages/
testing
Web Frontend:
TypeScript, React.js, Next.js, Jest

iOS:
Swift, XCTest

Backend:
Ruby on Rails, RSpec
Infrastructure Google Cloud Platform
Middleware NGINX
Database MySQL, Firestore
Monitoring Prometheus, Nagios, Sentry
Analytics BigQuery, Firebase, AdobeAnalytics
CI/CD CircleCI
Container Orchestration Kubernetes
Task Management Asana

開発体制

食べログオーダーでは以下のように複数のチームに分けて運用しています。
現時点ではミッションや目指すゴールが同じなので、それぞれのチームで同じコンポーネントを変更することが多く、 チーム間のコミュニケーションを以って競合の解決を図っています。

これはオーダーチームのチーム構成を説明した画像です。

これに加えて、BizDev、カスタマーサクセス、セールスに属するメンバーで一丸となった開発体制となっています。
今までは開発エンジニアが結合テストを実施していましたが、結合テストを開発エンジニアから分離し、QAエンジニアがテスト設計・実行を行うようにしました。
QAの立ち上げについては、「食べログオーダー開発チームでQAチームを立ち上げた話」 という題目で紹介させていただきました。こちらも是非ご覧ください。

特に意識していること

私たちの食べログオーダー開発チームでは特に以下の点を意識しています。

  • マルチスタックなエンジニアを目指す
    チームでは要件定義から始まり、ネイティブアプリ、フロントエンド、バックエンドをこなす、いわゆるマルチスタックなエンジニアを推奨しています。
    元々特定の領域のみを担当していたエンジニアでも、他の領域へ染み出せるような環境作りを努めています。

  • 利用者目線での開発・テストを忘れない
    製品をお使いいただく店舗様およびお客様の目線に立ち、要件の定義から結合テストまで実施しています。

  • データ可視化と徹底的な自動化
    データ可視化による課題分析と自動化による効率化で最高の開発体験の実現を目指しています。

  • 日々の外形監視と内部監視そして即修正
    エンジニア持ち回りで毎日外形監視と内部監視のチェックを行なっています。
    異常ログ、スローレスポンスといったチェックを属人化せずに実施しています。
    これにより各エンジニアの解析眼を養いつつ、問題の早期発見、即修正という流れを作っています。

  • アイスブレイクな時間を大切に
    業務はリモートワークがベースですが、ミーティングの中にもアイスブレイクな時間を確保し、コミュニケーションの円滑化や、積極性を発揮できるように努めています。

食べログオーダー開発の今後の見どころ

冒頭でもお話しした通り、食べログオーダーは店舗の売上に直結するDXとして2022年にサービスローンチ致しました。
プロダクトの年齢としてはまだ1歳に満ちません。
今後食べログが持つ飲食店基盤、ユーザー基盤を利用しつつ、飲食店DXのデファクトスタンダートへ育つ過程を体験することができます。

さいごに

拙文ながら食べログオーダーについてご紹介させていただきました。
そんな食べログオーダーでは、これから一番になるようなサービスをつくることに魅力を感じる方、マルチスタックエンジニアになりたい方、 ユーザーからの「ありがとう」を心から嬉しいと感じる方、そんな皆様を歓迎しております。
店舗様の利益を向上させ、お客様に新しい外食体験をしていただくため、是非共に飲食店DXを推めて行きましょう!
気になった方は是非下記の採用リンクをチェックしてみて下さい。

※ QRコードは(株)デンソーウェーブの登録商標です。