京都での検証作業中に発生した課題

前編のインタビューではデリバリー3.0の構想やシステムアーキテクチャの概要、プロジェクトマネジメントの方針などを話していただきありがとうございました。後編では、デリバリー3.0のリリース後のエピソードについて伺います。

丸山：前回のインタビューでは「2022年1月より、実証実験としてデリバリー3.0を一部の地域から徐々に導入していった」という話をしました。具体的には「実店舗での検証→京都での検証→東日本展開→西日本展開→全国展開」という順でリリースをしていったのです。しかし、京都での検証を実施していたところ、加盟店が内容を確認する前に自動でキャンセルされてしまう注文の割合が、増加してしまいました。

なぜ、そのような事態になったのでしょうか？

丸山：デリバリー3.0は、デリバリー1.0と比べて運用フローそのものが変わっています。デリバリー1.0では加盟店が受注確認をしなくても配達員がマッチングされるため、配達員が注文品を受け取りに店舗に足を運ぶことで加盟店が注文に気づくといったように、人力でカバーされていた部分がありました。ですが、デリバリー3.0では加盟店が受注確認をしてから、配達員がマッチングされる仕組みに変わったため、注文に気づかなかった場合はキャンセルになってしまうことが原因でした。

また、別の要因も考えられました。デリバリー3.0では加盟店側で使うアプリも作り直しているのですが、どうやらそのアプリで注文を受けた際に、通知音が鳴っていない可能性があったのです。

しかし、店舗で使っている同じ端末を取り寄せて社内で検証してみましたが、どうしても事象の再現ができません。そこで、開発チームと企画チーム、運用チームのメンバーが京都の店舗に赴き、オペレーションの流れや注文を受けた際のアプリの挙動などを現場で確認しました。

そうした検証を通じて不具合を発見することができ、加盟店側のアプリのバージョンアップを行うことで解決したのです。最終的には、キャンセル率がデリバリー3.0のリリース前の水準で落ち着き、OKが出て次のステップである東日本展開に進むことができました。

京都での検証からどのようなことを学びましたか？

丸山：たとえ、どれほど入念にQAテストをしても、やはり実店舗での運用をしなければ見えてこないことがあります。店舗に足を運んでわかったのは、同じアプリを提供していても使用する環境が多種多様だということでした。

出前館から貸し出している端末を使っている店もあれば、自前で用意した端末にアプリをインストールしている店もあります。Wi-Fiの電波の強弱だけでなく、端末をいつも厨房に置いている店もあれば、端末が店のバックヤードにあって注文があったときだけ取り出す店というように、運用の方法や環境がバラバラです。すべてのユースケースをカバーするには、店舗で実際に運用してアプリを改善する工程が必須だと実感しました。

デリバリー3.0のリリースにより事業KPIを達成

デリバリー3.0をリリースしたことで実現した成果を教えてください。

Bon：出前館は事業KPIとして「注文からお届けまでにかかる時間」を設定しており、もともと平均30分以上かかっていたのが、リリース後には30分を切ることができました。注文と配達員の最適なマッチングを実現するためにシステムを刷新したので、この結果に安心しています。また、全体的にアーキテクチャを変更したことで、機能の追加や変更が以前よりも容易になりました。

また別の改善点として、このプロジェクトではデリバリー関連のシステムだけではなく、配達を管理するコントローラーと呼ばれる機能も修正しています。その施策に加えてデリバリー3.0で各種機能の自動化を推進したことにより、コントロールセンターへの負担が格段に減りました。現在では、システムのモニタリングがメインで、トラブル発生時しか手作業が発生することはありません。

丸山：前回のインタビューにも通じますが、デリバリー1.0では配達員が注文を早い者勝ちで取る仕組みになっており、配達に慣れている人は効率良く稼働でき、不慣れな人は非効率的になってしまう状況がありました。それを改善するため、機械学習を用いた配達員のマッチングの仕組みや需要予測、インセンティブなどの仕組みを導入し、配達員のUXを向上させることができたのも、デリバリー3.0の大きな成果だと思います。

山下：オペレーションや配達の自動化・効率化以外にも、デリバリー3.0で改善している機能があります。出前館ではお客さまが現金で会計をした場合、配達員がお客さまからお金を受け取り、出前館に渡します。そのため、過去のシステムでは配達した当日や翌日に、配達員が近隣の出前館の拠点へと足を運ぶ必要があったのですが、この作業はかなり面倒で、配達員から不満が寄せられていました。

この改善のために、コンビニなどを通して配達員が受け取ったお金を出前館に渡せる仕組みも作りました。これも配達員のUX向上に寄与していますね。それ以外にも、配達員や業務委託の配達業者などへの報酬の支払いも、かつて手作業で行っていた箇所の一部をシステム化しました。

3.0と1.0を並行稼働させる方針を選んだのは正解だった

この移行プロジェクトでは、デリバリー1.0とデリバリー3.0のシステムを並行稼動させる方針を選びました。その方針をとった利点は何でしょうか？

丸山：やはり、デリバリー3.0を早期にリリースし、現場での運用や事業KPI、UXの改善を実現できたことに尽きると思います。デリバリー3.0を完全に作り切ってから移行するプランもあり得ましたが、なるべく早い段階で各種の業務を改善するためには、今回の案が正解でした。そして現在は中西さんが、デリバリー1.0に残された各機能を移行するためのプロジェクトに携わってくれています。

中西：少し昔の話をすると、デリバリー1.0はもともと配達機能がメインでそれ以上の機能はほぼ含まれていなかったのですが、運用を続けていく過程で運用チームや企画チームからの機能要望が出てきたため、それに基づいてシステムの変更をしてきました。

デリバリー3.0ではその中から配達機能だけを切り出して移行したような形ですので、他の機能はまだデリバリー1.0側に残っています。これらの機能を移行していくにあたり、データの再設計や処理フローの整備、仕様の再検討などが必要になるため、かなり大変な作業ではあります。ですが、この移行を成功させれば出前館がより良いサービスになっていくので、前向きな気持ちで取り組めています。

出前館のアーキテクチャをさらに改善し、事業貢献していく

今後の事業やシステムの展望を聞かせてください。

丸山：フードデリバリーから始まった出前館のサービスですが、、現在は日用品などの即時配達までサービスを拡大しています。今後もサービスを充足させ、より良いサービスをお届けしていきたいと考えています。

それから出前館のデリバリーは、配達機能を持たない加盟店の代わりに配達員が配達する「シェアリングデリバリー®️」という形態と、加盟店が雇用する配達員の配達形態に分かれており、両者は完全に別のシステムで動いています。今のところデリバリー3.0は前者にしか対応していませんが、将来的には後者にも対応したいです。

山下：配達員の方々にとっては、働いた報酬をなるべくすぐにもらえるほうが便利です。しかし、現在の出前館の報酬支払い日は月に2回です。報酬に関する処理も自動化していけば、支払いのスパンも短くできるはずです。最終的には、働いた翌日くらいに報酬を支払えるようになればと考えています。

それから、配達員として働きたい人が稼働開始までにかかる時間を短縮したいです。今はWebフォームから申し込んだ後、各種必要書類の提出と審査を経て、稼働できるまでに約1～2週間がかかります。人の目による確認作業も含んでいるためなのですが、これをeKYCによる自動判定に変えていき、最短で申し込みの当日から働けることを目指しています。

Bon：デリバリー3.0で柔軟性の高いシステムを設計・実装してリリースしたことにより、さまざまな好影響が出ています。私と山下さんは現在プラットフォーム部という部署に移っており、デリバリーシステム以外でもこうしたアーキテクチャ刷新と業務改善を実現できるように動いています。デリバリー3.0は非常に良い成功事例なので、これを他のシステムでも実現していきたいです。

中西：先ほど述べたように私はデリバリー1.0の各機能をデリバリー3.0に移行するためのプロジェクトを推進しており、これからはシステムのマイクロサービス化なども実現する見通しが立っています。システムの設計を改善し、より機能の追加・変更がしやすくなっていくと、出前館をさらに良いプロダクトへと進化させられると思います。

デリバリー1.0以前のシステムでは、システムの仕様や設計がかなり複雑になっていました。ドメイン知識も求められたため、新しいメンバーが開発チームに参画しても、システムの詳細をキャッチアップするまでにかなりの時間を要してしまう状態でした。

しかし、デリバリー3.0でアーキテクチャ刷新をしたことをきっかけに、その状況が変わってきています。より良い仕様のあり方について、開発チームが自発的に提案するような流れが組織内にでき、システムを改善する好循環が生まれています。エンジニアとして、これからどんな風にデリバリーシステムを進化させていけるのかがとても楽しみです。