レストランにおける分散システムの構築と改善.pdf

Transcript

1. レストランにおける分散システムの構築と改善
 株式会社フードテックキャピタル 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
 テクノロジーで
 外食を持続可能に
 新しい価値を創造し、
 日本から世界へ

4. 4
 レストランにおける分散システムの構築と改善
 本日のテーマ

5. 5
 分散システムパターンの勘所を掴む
 1. 登場人物の把握
 ◦ ユースケース(ワークフロー)を理解する
 2. システムによる代替可能性を探る
 ◦ 誰をどの機械で代替するのか？を考える
 3. システム代替によるワークフローの変化と改善を繰り返す
 ◦ システム同士のコミュニケーション設計
 ◦ システム境界のトレーサビリティ向上
 ◦ 継続的な改善

6. 6
 レストランを取り巻く環境
 前提

7. 7
 レストランの多種多様なシステム
 同じ機能でも ①通信プロトコル ②データ構造 ③インターフェースが レガシーかつ大きく異なる
8. 8
 レストランでは多くの制約が存在する。 • 場所に余裕がない(特に物価が高い都心など) • ネットワーク環境が悪い • 汚れやすい • 雑音が多い • 忙しい → 使いやすい&トレースしやすいハードウェアシステム群の構築が必要 レストランの制約を理解する

9. 9
 サービス紹介
 delico (デリコ) は、複数のデリバリー／テイクアウトプラットフォームサービスの 
 オーダーを一元管理するサービスです。 
 一枚のタブレットで受注、印字し、売上の管理やメニューの更新などができ、 
 飲食店のデリバリーにおける、生産性向上と収益増加の両方を実現させることができます。 

10. 10
 ドメインを理解し、重要な課題を網羅する レストランスタッフのワークフローを洗い出す

11. 11
 自社システムで解決できる範囲を特定する 基本的にはリーチできるターゲットの範囲内 システムで解決できる範囲を特定する

12. 12
 1. 注文に気づくこと → 音声による通知&サーマルプリンター 2. 注文内容を把握し調理できること →サーマルプリンター 重要な課題の発見と対応するハードウェア

13. 13
 delicoの初期のシステムフロー
 店舗によって最適な方法を選べる状態に。
14. 14
 Pros/Cons
 delico運用上のLAN方式とBLE方式の比較 ※通信方式ではなく運用上の比較
15. 15
 ソフトウェアはナマモノ。
 システム化による影響を評価し、改善を行っていく。
 評価と改善には、定量化と仮説が必須である
 ソフトウェアの継続的な改善

16. 16
 【サーマルプリンターの役割】 • 注文に気づかせること • 調理する内容を把握させること 【当時の課題】 • プリントするべき注文(プリントジョブ)をタブレット側が判断(BLE) ◦ 予約注文に気づきたいタイミングは、「予約が入った時点」と「調理が必要な時点」だ が、ロジックはアプリ側が持っておりアプリ申請が必要、浸透も難しい。 • BLEのエラーによりプリンターが印刷されないことがある ◦ ログの仕組みがなく、発生ベースでの確認になっていたため影響範囲が不明。(定量化 できていない) • (LAN配線の設置コスト: エンジニア以外の設置が難しかった(約0.5-1時間/店舗)) 過去のシステムフローにおける課題をたてる

17. 17
 プリントジョブの管理を考える
 プリントジョブはエッジ側ではなく、バックエンド側で管理する • プリントするべき注文がDB上に残りトレーサビリティが向上する ◦ BLEのエラーログも監視ツールに送る • プリントするべき注文のロジックが申請なしにデプロイ出来る • 実行したプリントジョブは端末から完了通知を送り消しこむ。
18. 18
 今後は1つの店舗で複数のプリンターを利用する可能性がある • 居酒屋ではドリンクとフードを別々のプリンタに出すことがある。 ◦ 商品毎のプリンター出し分けロジックをアプリ側に置くのは地獄。 • BLEのみの場合、複数台をタブレットから遠距離におけない。 ◦ 物理的制約が強い場所はLAN配線によるオプションも提供できる。 未来のビジネスユースケースを想定する

19. 19
 delicoの現在のシステムフロー
 Before) 注文情報からプリントジョブを抽出し、印刷指示を実施 After) プリントジョブをそのまま印刷指示へ。ジョブも削除。
20. 20
 トレーサビリティの向上 • 問題発生時に即座に検知/判断出来た。 • 影響範囲が定量的に把握出来た。(CSコミュニケーション) バックエンドのみでプリントジョブを生成できた • 気づいて欲しい注文(キャンセル、エラーなど)をバックエンド側で組める。 複数プリンターへの対応コストの削減 • 商品毎のプリンター振り分けを低コストで実現できる汎用的基盤が出来た システム改善によるインパクトを振り返る

21. 21
 まとめ
 1. ユースケースを把握し、システム化するべき箇所を特定する。
 2. 分散システムでは、運用コストを考えた設計にする。
 3. IoTデバイスのログは必ずクラウドに同期する。