外食DXにおけるエンジニアリングデザイン

Transcript

1. 外食DXにおけるエンジニアリングデザイン 株式会社フードテックキャピタル CTO 南里勇気
2. 2 自己紹介 南里勇気｜取締役兼CTO 慶應義塾大学経済学部卒。在学中から株式会社MEDICAでシステム開発、大手調 剤薬局チェーンと共同研究で論文発表。2015年株式会社FiNCに入社してAndroidチ ームマネージャーとしてアプリ改善、GooglePlayベストオブ2018「自己改善部門」大 賞受賞。同年米国シリコンバレーでFiNC Technologies USオフィスを立上げ。2019年 から中国でハードウェアを開発、テックリードとしてプロダクトをローンチ。2020年6月 Bison Holdingsを創業。
3. 3 会社紹介 外食産業でのDXを促進し、テクノロジーを駆使してこの業界を盛り 上げるべく会社を設立致しました。 2022年現在、日本が誇るべき「食」は100年に一度の危機に立たさ れています。 衣食住の一角をなす「なくてはならない産業」でありながら、DX化 に遅れ、さらにコロナ禍による多大な被害は止まるところを知りま せん。 私たちは、外食産業にテクノロジーを提供する先駆者として、新し い価値と食の未来を創出していきます。DXの促進が、日本の食文 化を大きく発展させることに繋がり「食の未来」が明るいものに変 わっていくことを確信しています。 Mission テクノロジーで 食の未来をつくる Creating the Future of “Food Service” through Technologies
4. 4 外食DXにおけるエンジニアリングデザイン 本日のテーマ
5. 5 サービス紹介 delico (デリコ) は、複数のデリバリー／テイクアウトプラットフォームサービスの オーダーを一元管理するサービスです。 一枚のタブレットで受注、印字し、売上の管理やメニューの更新などができ、 飲食店のデリバリーにおける、生産性向上と収益増加の両方を実現させることができます。
6. 6 delicoのシステムフロー
7. 7 1. 注文/売上機能に関わる問題は緊急度/重要度が高い 2. 店舗のオペレーションが多様で課題抽出が難しい 3. 店舗の環境依存の問題 デリバリー管理システムにおけるエンジニアリングの課題
8. 8 • 飲食店舗の注文ピーク時間は11:00-13:00, 18:00-19:00。 • ピーク時は注文数が20-30件/時くることもある。注文機能に関わるバグは売上減 少という大きな機会損失に繋がるため、重要度が高い。 • 店舗によらず1日の限定的な時間に注文が集中するため、問題を極小化しづらく 緊急度が高くなりやすい。 注文/売上機能に関わる問題は緊急度/重要度が高い
9. 9 1. AWSの活用(Multi-AZ)による可用性向上 ◦ タスクはWorker、Scheduler、API ◦ Fargateによる可用性向上と管理コストの削減(※踏み台: EC2) ▪ 注文のスパイクアクセスに対してオートスケールの実行 ▪ 予測しづらい導入店舗増加に対する、サーバー管理のコスト削減 2. Go言語による注文リクエストの処理 ◦ サービス成長に伴い毎秒/分の大量トラフィックが予想される ◦ 秒間あたりの実行処理速度が良いGo言語の活用 ◦ パフォーマンス測定で700req/s インフラ/バックエンドによる可用性の向上
10. 10 アプリの可用性低下はバックエンド/UX起因が多い 1. 運用/IoTシステムを信用しないシステム構築 • 課題: 注文が取得できないことがある ▪ 原因1) アプリを開いていない(運用) ▪ 原因2) ポーリングが停止している(システム) ◦ 対策: ポーリングプロセスの定期起動&バックグラウンド処理の実行 2. UXによる複数の課題解決 • 課題: 注文音がならず、注文に気づけないことがある ▪ 原因) ハードウェアのステートマシン/エラーハンドリングが不適切 ◦ 対策:キッチンプリンターへのレシート印刷(音以外の仕組みでUXを担保) フロントエンドによる可用性の向上
11. 11 1. CSと共通の基準を持つ ◦ SLI/SLOの設定=ProductivityとReliabilityのバランスをとる ◦ Critical User Journeyと定量的な指標(metrics)を持つ 2. 閾値アラートでCSアクションを促す ◦ 外形監視/エラー通知(Datadog/Sentry)による検知 ◦ アプリケーションDB/ログのダッシュボード化とCS側への自動Slack通知。 ▪ 店舗が問題に気づく前にこちら側から通知出来ている 3. Error Budgetの設定による開発アクションの合意形成(予定) ◦ 例えば、バグによるCS問い合わせ数が10倍になった場合、開発側が新規開発を続けるべきか どうか？ ◦ 逆にCSが0.01%の再現率の注文に関するバグを開発に対応させるのか？ 参考) SLA、SLO、SLI の比較: 相違点は何か? CS/開発のシームレスな連携
12. 12 Critical User Journey/SLI&SLOの例 注文周りの具体例 • 注文されたらプリントされる ◦ タブレットは飲食店が忙しいと見ないものとして設計 • 注文に気づく(コア体験) ◦ 料理を作る ◦ 配達する(してもらう) SLI/SLO • システムアーキテクチャに依存 • 注文の成功 ◦ 注文を受けて、データ保存・通知する処理の成功率 ◦ delico注文サーバのレスポンス成功率 ◦ アプリへの注文レスポンス成功率 • 注文の遅延 ◦ Delivery Platform→注文を受けてから、delicoのwebhookに送るまで500msなどのSLAを設ける 参考) Setting SLOs: a step-by-step guide
13. 13 店舗を分類するいくつかの軸が存在する 1. バーチャルレストラン(VR)とゴーストキッチン(GK) (*) ◦ VRはイートイン80%とデリバリー20% / GKはデリバリー100% 2. ブランド ◦ ラーメン屋は席数が少なく、スタッフが全ての業務を担当する。居酒屋は席数が多く、スタッフが 分業制で担当する。 3. 個店舗とエンタープライズ(100店舗以上) ◦ 現場よりも管理本部側のコストが大きく変わってくる ※ バーチャルレストラン(VR) = 実店舗を持つブランドがクラウド上に持つ店舗/ ゴーストキッチン(GK) = 実店舗がないデリバリー専門店 店舗のオペレーションが多様で課題抽出が難しい
14. 14 ペルソナによって開発する機能が大きく違うため軸を決める ペルソナと課題例 • VR → デリバリーだけではなく、イートインも含めてオペレーションを統一したい。 • GK → 複数ブランドを料理するため、レシートからすぐに注文を把握したい。 • 居酒屋 → 分業制(ドリンクとキッチンなど)のため、場所ごとにキッチンプリンターが配置される ことがあり、プリンターごとに出す商品を変更したい。 • ラーメン屋 → 麺が伸びやすいため、生産タイミングや調理時間を管理したい。 • 個店舗 → キッチンプリンターは必要がないがCSには常に電話をとって欲しい。 • エンタープライズ → FCのための販促/メニュー/商品管理などを行いたい。 飲食特有のペルソナの解像度を高め、優先度の軸を持つ
15. 15 店舗の環境依存の問題 1. インターネット環境 • WiFiのネットワークスピードが悪く、数店舗でしか起きない。 • そのため手元で再現せず、解決の見通しが立ちづらい。 2. タブレット(端末モデル/OS) ◦ toBシステムのためMDM端末を提供。 ◦ Androidは固定のモデルを利用。iPadは複数端末/OSが存在するため、特定の端末でのみ問題 が起きることも多い。 3. アプリバージョン ◦ 注文を止めるわけにはいかないため、任意のタイミングで強制アップデートができない。 ◦ 店舗スタッフはアップデートすることが怖いため、なかなかアップデートしない。 ◦ 結果、古いバージョンでバグ報告がきてCSコストが上がっている。
16. 16 IoTデバイスのエラーは汎用的に実装しないと運用に載らないことが多い IoTデバイス間の連携部分のトレーサビリティを高める 結果としてCS対応やお客様の問題解決のリードタイムが伸びてしまう 参考) 分散処理システム(IoT)によるトレーサビリティの向上
17. 17 実際に店舗を訪問する 「百聞は一見に如かず」データから仮説を持つよりも行った方が早いこともある 自社運営店舗 開発オフィス 自社キッチン付き開発オフィス ゴーストキッチン2店舗運営 直営20店舗、FC20店舗 delico協力店舗 19店舗にαリリースし 本番リリース前に2週間運用
18. 18 1. デリバリーDXは可用性を高める施策を打ち続ける 2. ペルソナを明確にすることで開発スピードをあげる 3. 店舗内IoTデバイスのロギングを怠らない まとめ
19. 19 外食DXで飲食店の業務をなめらかに デリバリー・テイクアウト 注文・売上管理 調達・生産管理 ロボティクス シフト・勤怠管理 イートイン注文・ 売上管理 予約管理・CRM