こんにちは、@zaq1tomo （ざきとも、と読みます）です。

Chompy でよく注文するお店は「カリーカイラス」さんで、サクサクのカツが入ったボリューム満点「カツカリー」がおすすめです。

普段は、フードデリバリーサービス Chompy のユーザーアプリ（注文するお客さま向けのアプリ）のサーバー・クライアントの開発や、この記事で書いている「らくとく便」という機能の配達ロジック周りの開発などを担当しています。

Chompy に入る前は、Gunosy、Mercari、LINEなどで企画・開発・分析などを行っていました。

この記事では、先日のプレスリリースでお知らせした「らくとく便」という機能ができるまでの経緯についてご紹介します。

Chompy にちょっとでも興味あるという方にもっと Chompy のことを知ってもらえれば、これから新しくサービスを立ち上げようというエンジニア・PMの方々の参考に少しでもなれば、と思ってこの記事を書いています。

なかなかの文量になってしまいましたが、結構赤裸々な内容を書いていますので、最後までお楽しみいただけると幸いです。（6500字超え...。）

（2021/01/28更新 : Chompy Open Tableで下記内容の最新状況
を発表したのでよろしければご覧ください！）

「らくとく便」で解決したい課題

＜ユーザー・配達員の課題＞

Chompy は、食を通じて日常の暮らしを豊かにすることを目指して作られたサービスです。

より多くの人の日常に「おいしい」をお届けするべく、日々サービス開発をしていますが、従来のフードデリバリーの仕組みでは、構造的に配達コストを下げることが難しく、多くの人にとっては日常利用しにくいという課題がありました。

そんななか、先日リリースされた「らくとく便」は、1時間前までに注文するだけで何店舗でも送料無料で注文できるという機能です。（めちゃお得！）

らくとく便

従来のフードデリバリーでは「1注文・1配達」が一般的ですが、「らくとく便」では中継地点を設けたハブアンドスポーク方式の配達によって必要な配達員の数を削減しています。これにより、配達員の一人当たりの報酬は下げることなく、送料無料という UX が実現できています。

ハブアンドスポークのイメージ

現在は一部のエリア限定で機能を開放していますが、順次拡大予定ですので、エリア外の方は今しばらくお待ちを...！

＜飲食店の課題＞

また、「らくとく便」はユーザーや配達員だけではなく、飲食店の方々にもメリットがある仕組みです。

一般的な飲食店では、席数やスタッフ数は固定されているため、ユーザーの需要があっても捌ける注文数には限りがあり、多くの機会損失が発生しているという課題がありました。

「らくとく便」のように、ピークタイムを避け、アイドルタイムにまとめて調理することができれば、オペレーションコストの削減・売り上げの向上が可能になります。

＜まとめて注文・まとめて配達による解決＞

このように Chompy では、ユーザー・配達員・飲食店の三者にとって使い勝手の良い「まとめて注文・まとめて配達」の仕組みを様々な角度から提供することで、持続可能な形で配達コストを削減し、より多くの人の日常に寄り添うサービスになることを目指しています。

「まとめて注文・まとめて配達」というコンセプトでは、「らくとく便」の他に「グループ注文」という機能もあるのですが、こちらに関しては後日、別のメンバーに記事を書いてくれるみたいなのでお楽しみに。

「まとめて注文・まとめて配達」の機能例

（2020/09/15更新 : グループ注文の記事が公開されました！）

初期のターゲットはオフィスランチ

実は「まとめて注文・まとめて配達することで安く届ける」というのは創業前からあったアイデアで、初期のターゲットはオフィスランチでした。

＜LTV観点での仮説＞

自分自身が渋谷や六本木のオフィスビルに勤めていたときも、ランチタイムのエレベーターはいつも行列、近隣の飲食店はどこも満席で、毎日のランチ選びに大きな課題を感じていました。

この記事を読んでくださっている人の中にも同様の課題を感じたことのある方が、少なからずいるのではないでしょうか。

時短ニーズが強く日常的に外食することが多いオフィスワーカーに対して、使い勝手の良いランチサービスを提供することができれば、根強い習慣利用に繋がるのではないかという仮説がありました。

＜CAC観点の仮説＞

また、オフィスはバイラルが効きやすい環境です。

同僚という濃度の高いネットワークがあるオフィスという環境で、毎日社内の誰かしらが使っているようなサービスを作れれば、口コミ経由で効率的なユーザー獲得を行えるのではないかという仮説がありました。

<リーンな立ち上げによる検証>

とはいえ、ハブアンドスポーク方式で一般の飲食店の料理を運ぶというようなモデルで成功しているサービスはグローバルでも前例がなく、ユーザーに受け入れられるのか、オペレーションがスケールするのか、ビジネスとして成り立つのか、不確実性が高いものでした。

それに対し「1注文・1配達」でのオンデマンドなフードデリバリーサービスは国内外含めて先行事例も多く、比較的確度が高いモデルです。

そこで開発としては、オンデマンドなフードデリバリーサービスはアプリである程度作り込んでからリリースすること、オフィスランチ向けのサービスは Web で最小限かつ最速でリリースし早く検証すること、そして、これらを疎結合な状態で作り、ある程度の仮説検証ができた段階でアプリに統合することを決めました。

MVPによる立ち上げ

オフィスランチ便

最小限かつ最速でリリースしようという背景からできたサービスが、上記の「オフィスランチ便」です。

＜MVPは二週間で実装＞

当時の開発メンバーが自分一人だけだったこともあり、①自分が慣れていて実装に時間がかからないこと、②インフラはマネージドで出来る限り気にする必要がないこと、③頼れる部分は外部のサービスに任せること、この三点を意識し、アーキテクチャは下記のようになっています。

オフィスランチ便のアーキテクチャ

フロントエンドは Vue.js ＋ TypeScript で書かれていて Firebase Hosting で配信されています。デザインは BootstrapVue が軽く当たっただけの簡素なもので、画面も会員登録、店舗一覧、商品一覧、決済、注文履歴など、必要最小限なものだけでした。

バックエンドは Go で書かれた API が Cloud Run の上で動いています。当時はちょうど Cloud Run に東京リージョンが追加されたくらいの時期でまだ GA ではなかったのですが、試してみたらとても使い勝手が良かったので、そのまま採用されています。Dockerfile を書くだけで任意の環境をサクッと構築でき、デプロイも高速なので個人的には結構お気に入りです。

データベースはほとんどのデータが Cloud Firestore 、商品画像など一部のデータが Cloud Storage に保存されています。自動で Firestore のドキュメントを BigQuery にエクスポートしてくれたり、Storage の画像を自動でリサイズしてくれたり、Firebase Extensions が便利な Function をたくさん用意してくれているので快適です。

認証は Firebase Authentication を使っています。フロントエンドはFirebaseUI for Web ほぼそのままで、バックエンドは Go がトークンの検証を行っています。企業が増えるつれて様々なセキュリティ要件が出てきたのですが、FirebaseUI だと小回りが効きにくかったので、フロントは最初から自前で実装しても良かったかもなと思っています。

その他、外部のサービスとして、決済に Stripe、メール配信に SendGrid を使っています。どちらも Go の SDK が充実していたので、シュッと導入することができました。

git log を遡ると、開発スタートから二週間弱で必要な機能が大体動く状態にはなっていたようです。

当時は一時的なトライアルを担うためだけのシステムだと思って実装していたのですが、結局一年以上運用し続けられており、一度動き始めたシステムは思ったよりも長生きするということを学びました。

＜裏側は人力＞

また、この段階では飲食店側や配達員側のシステムはほぼ何も実装していません。

毎朝両手に配達バッグを持って六本木のオフィスから渋谷にバスで移動し、社員やインターンメンバーが徒歩で配達を行うという日々。

毎日時間になったら注文一覧をスプレッドシートで吐き出して飲食店に電話で発注し、支払いは現金で行っていました。

ランチタイムだけでも真夏の炎天下のなかパンパンになったバッグを持って配達を行うのはかなり大変で、日々配達を行ってくださっている配達員の方々への尊敬の念が深まりました。

泥臭い毎日ではありましたが、今振り返ると良い思い出の一つです。

オペレーションの自動化

ユーザーが注文できる、それだけ。ハリボテのシステムではありましたが、リリースしてみると継続購入率や平均購入回数など、主要な KPI は想定していた水準よりもかなり高く、ご利用いただいた方からはたくさんの満足の声をいただきました。

オフィスランチ便利用者の声

福利厚生が効くいくつかの企業では破格の値段で人気店の料理が食べられるということもあり、これまでは全くなかった、新しい UX が提供できていたと思います。サービス導入10日後に10回利用している人がザラにいるなど、強烈に「刺さった」感覚がありました。

次に検証するべきは、スケールし得るのか、そして、ビジネスとして成立し得るのか。矢継ぎ早に飲食店数や企業数を増やすことになりましたが、人力のままでは早々にオペレーションが回らなくなることは明らかだったため、ボトルネック箇所から徐々に自動化を行っていきました。

まず行ったのは配達ルート生成の自動化です。

オフィスランチ便は、配達コスト削減のため一人の配達員が複数の飲食店を回り、可能な限り少ない人数で配達を行うことを目指しています。

初期は、当日の注文一覧を見ながら人力で配達ルートを考えていたのですが、注文数・店舗数が増えるにつれて、数十店舗を効率良く回るルートを人が考えるのは限界になってきたため、これを下記のようなシステムで自動化しました。

初期の配達ルート生成のアーキテクチャ

Cloud Scheduler が定期実行するクーロンジョブ、もしくは、Slack のスラッシュコマンドからのアドホック実行をトリガーに、Python で書かれた最適化スクリプトが動き、その出力が配達員用の Slack に通知される、というのが大まかな流れです。

Slack のスラッシュコマンドは3秒以内に ack を返す必要があるため、HTTP のリクエストを受け取った Cloud Functions が Cloud Task にタスクをエンキューし、最適化問題を解くのは Cloud Run が非同期で行っています。

この段階の最適化スクリプトでは、配達バッグの容量や配達完了時間など、いくつかの制約条件を満たした解を指定回数探索し、最も良いものを近似解とするという、シンプルなアルゴリズムによって実装を行いました。

また、この時期になるとオンデマンドなフードデリバリーサービスの方の開発も進みつつあったので、Chompyのシステムと連携し、現金決済を銀行振り込みに移行したり、タブレット経由で発注を行えるようにしたり、仕分け用シールをプリンター印刷できるようにしたり。配達ルート生成のほかにも、いくつかのオペレーションの自動化を行いました。

アプリ化・らくとく便リリース

ユーザーのニーズがあること・オペレーションがスケールしうることが見え始め、いよいよ拡大という矢先、新型コロナウイルスが発生。

オフィスランチ便を導入していた企業の多くでは、WFHが導入されて出社数が激減し、オフィス向け単体でサービスを拡大させるのは難しくなってしまいました。

とはいえ「まとめて注文・まとめて配達することで安く届ける」というコンセプトが多くのユーザーに刺さった」のは事実。オフィスランチ便で培ったオペレーションの仕組みを転用し、一般のご家庭にお住まいの方にも利用いただける機能として、サービスをリニューアルすることを決めました。

こうして作られたのが、先日リリースされた「らくとく便」です。

このタイミングで、注文インターフェースのアプリ化も実施。バックエンドはオフィスランチ便での知見を活かしながらフルスクラッチでの実装を行いました。

配達ルート最適化サービスのアーキテクチャ

毎日、昼食・夕食時間帯に配達ルートの最適化を行うサービスが動き、その結果を元に配達員アプリにオファーが飛ぶというのが大まかな流れです。

App Engine Cron によってスケジューリングされたタスクをトリガーにして、Cloud Pub/Sub にメッセージが送信され、マイクロサービス的に動いている Cloud Run が対象のトピックを購読することで非同期で最適化の処理を行っています。

Cloud Run では Flask の サービスが動いており、Pub/Sub メッセージの受信をトリガーにして、最適化ソルバを実行して解を生成し、Cloud Storage に保存した後、再度 Cloud Pub/Sub にメッセージを送信します。

App Engine で動く Go の サービスが Cloud Run からの Pub/Sub メッセージの受信をトリガーにして、飲食店→中継地点、中継地点→ユーザーの配達のためのオファーを作成し、配達員の位置情報などを考慮しながらアサインを行っています。

一連の処理の過程で、Slack 通知を用いて、飲食店の死活監視や配達ルートの可視化を行っているのもポイントです。CS チームや中継地点の仕分け担当者が下記のような投稿を元に、日々オペレーションを行ってくれています。

飲食店の死活監視のための Slack 投稿

配達ルートの可視化のための Slack 投稿

最適化ソルバーには、OR-Tools の Routing Model をベースにいくつか制約条件を追加してカスタマイズしたものを使用しています。300行ほどコードを書くだけで、下記のような最適化問題を一瞬で解いてくれるのでとても便利です。

Vehicle Routing Problem のイメージ
（ https://developers.google.com/optimization/routing/vrp より）

Chompyの目指しているところ

共働き世帯の急増に伴い、毎日自炊を行うことが難しくなり、内食中心から中食も活用した食生活へとライフスタイルが大きく変化しているのが、いまの日本です。

また、外食産業に目を向けると、人口減やコロナなどの逆風を受け、多くの飲食店が悲鳴を上げています。

晴（ハレ）というよりは褻（ケ）の食をもっと豊かにしていきたい。

日本が誇るべき食文化を支えたい。

Chompy では、「らくとく便」のような新しいインフラを通じて、多様な食を多様に届けることで、多くの人の日常を豊かにするとともに、日本の食の発展に貢献していくことを目指しています。

最後に

Chompyでは、仲間を大募集中です。

この記事を読んで「面白そうかも！」と思っていただけた方は、自分の Twitter など含めて、お気軽にご連絡ください。

最後までお読みいただき、ありがとうございました。

先日の一周年パーティ。お気に入り