デリバリー3.0は何を目指したのか？

デリバリー3.0の開発エピソードを伺いたいのですが、3.0があるということは1.0や2.0も存在するのですか？

山下：まずデリバリーシステムの前提知識についてお話しします。出前館では、お客さまからの注文が入ると、その情報を受け取った加盟店が調理を開始し、同時に加盟店の近くにいる配達員へと配達のオファーが送られます。配達員がオファーを受け入れると、加盟店や注文内容、お届け先などが閲覧できるようになります。この配達完了までの一連の流れを管理しているのがデリバリーシステムです。

今回のインタビューではデリバリー1.0と2.0、3.0の説明をしていきますが、実はさらに古い旧差配システムと呼ばれるものがあります。これは、オペレーターがシステムを操作してオファーを配達員に割り当てるシステムであり、他のデリバリーシステムと並行稼働する形で、2020年まで使用されていました。

この自動化を目指した第一歩がデリバリー1.0で、2019年11月にリリースしました。デリバリー1.0の利用数は徐々に増えていきましたが、それに伴ってシステムが負荷に耐えられないという課題が表出しました。そこでシステム改善を行い、パフォーマンス向上とともに、配達効率を良くすることを目指したのです。

もともとデリバリー1.0では、加盟店の近くにいる配達員全員にオファーを送り、早い者勝ちでオファーを受ける仕組みでした。しかし、それでは慣れていない人がほとんどオファーを受け取れず、効率的に稼働できる人とそうでない人の差が開いてしまいます。

そこで、配達員全員へ一斉にオファーを送るのではなく、AI・機械学習を活用して最適な配達員にオファーを送ることを目指したのがデリバリー3.0です。しかし、システムの開発にはかなりの時間がかかりそうだったため、まずは他社が提供する配車サービスのSaaSを活用して、注文と配達員とのマッチングを改善しようと始まったのがデリバリー2.0でした。

丸山：デリバリー2.0は、小規模なPoC（Proof of Concept：概念実証）としてプロジェクトをスタートしています。ですが、実際に検証してみたところ、それほど配送効率を向上させられませんでした。さらに、他社が提供する配車サービスのSaaSでは、それなりの額の利用料がかかります。これらの点を鑑みて内製するほうがいいという話になり、デリバリー2.0はお蔵入りになりました。

デリバリー3.0が目指したことをお話しください。

山下：まず先ほど述べた通り、デリバリー3.0はAI・機械学習を活用して最適な配達員マッチングの実現を目指しました。デリバリー1.0ではオペレーターによる運用が多かったため、人件費がかかり作業の遅延やミスも発生していましたので、可能な限りすべての作業を自動化することも、デリバリー3.0の目標でした。

丸山：デリバリー3.0では、AIを活用することで適切な待ち時間をお客さまに表示したり、配達員に向けて「どの場所ならば効率的に稼げそうか」という需要予測を出したりといったサービスの提供も目指しました。お客さまや配達員のユーザー体験を向上させることも、デリバリー3.0の大きな目標でした。

3.0と1.0を並行稼働させるためのアーキテクチャ

デリバリー3.0をどのようなシステムアーキテクチャにしましたか？

丸山：このプロジェクトで特徴的なのは、デリバリー3.0とデリバリー1.0のシステムが並行稼働していることです。プロジェクトを進める方針として、デリバリー3.0のシステムをすべて作りきった後に移管するのと、まずはデリバリー3.0の必要最低限の部分を作ってデリバリー1.0と共存させ、徐々にデリバリー3.0の開発を進めるという2つの選択肢がありました。前者を選択するとシステム移管までに数年がかかりそうだったことから、より早期にビジネス目標を達成するために、私たちは後者を選びました。

デリバリー3.0とデリバリー1.0とのシステム連携の流れをご説明ください。

丸山：まずお客さまの注文の情報が、出前館内部のシステムを経由してデリバリー1.0に入ってきます。するとAmazon Kinesisのメッセージング処理によって、その情報をデリバリー1.0からデリバリー3.0へと非同期的に連携します。

注文情報がデリバリー3.0に受け渡されると、機械学習関連の処理を行うコンポーネントに問い合わせを行い、配達員の優先度情報を受け取ります。この優先度の順序に基づいて、オファーをデリバリー3.0から配達員に送っていきます。機械学習系の処理を実装しているのはLINEのData Scienceセンターのメンバーであり、出前館側からその機能を呼び出して使っています。

配達員が加盟店に着いたとか、配達員がお客さまに料理を配達完了したといった配達状況のデータは、デリバリー3.0に蓄積します。デリバリー1.0でも配達状況を把握する必要があるのですが、その情報をデリバリー3.0からデリバリー1.0へと連携する際にも、先ほどと同様にAmazon Kinesisによる非同期的なメッセージング処理を行います。こうした設計にすることで、デリバリー3.0とデリバリー1.0との相互のデータのやりとりを可能にしました。

山下：さらに、もうひとつ開発において重視したことがあります。配達員向けのアプリや加盟店向けのアプリをデリバリー1.0用とデリバリー3.0用とで分けてしまうと、アプリを使う方々が混乱してしまいます。それに、利用するアプリの種類を間違えて、トラブルが起きてしまうかもしれません。

そこで私たちは、アプリでログインした時にユーザーの所属情報を取得し、デリバリー1.0が適用される地域ならば1.0モードで、デリバリー3.0が適用される地域ならば3.0モードでアプリが起動するようにしました。ユーザー側は何も意識せずアプリを使うことができ、サーバー側が自動的に判断して1.0と3.0を切り替える構造です。

また、このハイブリッド構造を実現することとデリバリー1.0の技術的負債を解消する目的から、デリバリー3.0のプロジェクトが始まったタイミングでアプリを完全に作り直しました。使用する要素技術も変えており、現在は配達員向けのアプリと加盟店向けのアプリのいずれもFlutterで開発しています。

アプリ開発において、他に大切にしていることはあるでしょうか？

山下：可能な限り、ビジネスサイドの意見やアプリを実際に利用する方々の声を拾い上げて、プロダクトに反映させるようにしました。たとえば、配達員がより効率的に稼働できるように、たくさんの注文が入っている地域を表示したヒートマップは、ユーザーから上がった声をもとに導入した機能です。

また、デリバリー1.0のシステムでは配達員がオファーを受けた段階で、受け取れる金額の情報が表示されません。これも、配達員から「オファーを受けた時点で、報酬を表示してほしい」という要望があったため、デリバリー3.0での実装の優先順位を高くし、初期リリースで導入できるように調整しました。

複数の企業やチームが関与する大規模プロジェクト

Bonさんはプロジェクトマネジメントを担いましたが、取り組みの概要について教えてください。

Bon：デリバリー3.0はかなり大規模なプロジェクトになることが見えていたので、開発の混乱を避けるために 他のいくつかのプロジェクトを一時的に止める必要がありました。それには経営陣の承認が必要だったため、デリバリー3.0のスコープや必要な開発期間などを説明し、経営陣との交渉を続けましたね。

開発体制としては出前館と韓国のグループ会社、複数の協力会社 、さらに先ほど名前の出たLINEのData Scienceセンターという、かなりの規模になっていました。時には、ミーティングの参加者が100人を超えるようなこともあり、プロジェクトに関わるステークホルダーと意思疎通をし、同じ方向を向いてプロジェクトを進めていくのは難易度の高いタスクでした。

プロジェクトを円滑に進めるために心がけたことはありますか？

Bon：プロジェクトマネジメントの大原則としては「決して止まらず、進み続けられる状態を保つこと」が重要になります。さらに、仮に進めていたとしても航路の方向を誤ってはいけないので、各ステークホルダーが正しい航路を理解できるように工夫しました。

たとえば、協力会社にシステムの一部の機能について開発を依頼した場合に、「それがプロジェクト全体においてどのような意義を持ち、どのように使われるか」という前提情報を極力伝えていました。もしも、いずれかの企業やチームのパフォーマンスが出ない場合には、進行を阻害している何らかの原因があるため、積極的にメンバーとコミュニケーションを取るように意識していました。

また、各メンバーが各々の役割に集中できるように心がけました。エンジニアの場合は参加するミーティングを極力減らして、開発業務に専念できるようにするなどですね。また、複数の企業・チームと複数の言語・文化のメンバーが混在したプロジェクトであるため、チームとチームを積極的につなぐことに労力を費やしました。

具体例を挙げると、複数の言語・文化のメンバーがうまくコミュニケーションできるように、通訳担当者をかなり増やしました。とはいえ通訳を介したコミュニケーションでは技術的な内容がうまく伝わらないこともあるので、より詳細な情報を伝えたい場合には最小限のメンバー、そして私という構成で、私がエンジニアリングの専門知識をふまえつつ通訳をしていました。

基本的に大規模なプロジェクトにおいては、コミュニケーションの課題を一度に解決することはできません。そこで、現場のメンバーの声を拾い上げつつ、プロジェクトで生じている課題や懸念材料などを理解し、解決するために何をすべきかを地道に考え行動しました。ステークホルダー全員で協力し合いながら、プロジェクトを進めていったのです。

プロジェクト方針の総括

今回のインタビューを総括して、デリバリー3.0のプロジェクト方針についての振り返りをお願いします。

山下：結果的には、デリバリー3.0とデリバリー1.0を並行稼動する方式にして良かったです。2022年1月から、一部の地域で実証実験としてデリバリー3.0を徐々に導入していったのですが、システム切り替え後に予期せぬ不具合や配達効率の低下が発覚しました。

もしもデリバリー3.0とデリバリー1.0を並行稼働する方式にしていなかったら 、こうした不具合によって大損害が生じていたかもしれません。2つのシステムを並行稼動させつつ、まずは部分的にリリースすることで、アルゴリズムのチューニングやアプリの修正をして、プロダクトの品質を高めたうえで全国展開できました。

丸山：山下さんが言ってくれたように、私も並行稼動の方針は正解だったと思います。システム開発における利点だけではなく、現場での運用面での利点もありました。配達員の方々に新システムについての連絡をして運用方法を浸透させるには、それなりの時間と労力がかかります。もしも全国規模でシステムを一気に切り替えていたならば、その運用負担がかなり大きくなったはずです。徐々にリリースする方針を選び、かつ何かあればいつでもデリバリー1.0に切り戻せるという保険をかけたことは、やはり正解だったと思います。

Bon：複数の企業や組織が、"1つのチーム"になっていくことを実現できました。このプロジェクトでは、開発手法や組織の文化、考え方などが違う複数のステークホルダーが集まって、一緒に1つの航路を進みました。これまでも出前館でプロジェクトの成功事例はたくさんありましたが、これほど大規模な案件で新たな実績を作れたのは稀有な事例だと思います。今後もさまざまな案件で、"1つのチーム"になることを目指してプロジェクトを進めていきたいです。

中西：デリバリー1.0の頃には、配達員やお客さまの声を、ビジネスサイドを経由してしか知ることができませんでした。ですが、デリバリー3.0ではユーザーフィードバックの機能を導入したため、ユーザーの意見をエンジニアが直接把握できるようになりました。もちろん、厳しい意見をいただいた際には落ち込みますが、それ以上に感謝の声で励まされることが多いです。これからもユーザーの声を生かしつつ、より良いユーザー体験を提供できるよう、機能開発や改善をしていきたいと思っています。