出前館とLINEヤフーそれぞれの強みを活かす

「クイックマート」のサービス説明やプロジェクト発足の経緯を聞かせてください。

倉井：「クイックマート」は日用品や食料品、医薬品といった商品を、近くの加盟店から最短30分でお届けするサービスであり、「Yahoo!ショッピング」内でサービスが展開されます。他社の提供する即配サービスとの差別化は、出前館とLINEヤフーそれぞれが持つ事業アセットを活かしている点にあります。

出前館にはこれまでフードデリバリーのサービスで築いてきた圧倒的なデリバリー網があります。また、LINEヤフーは「LINE」「Yahoo! JAPAN」といったメディアでの広告・集客や「PayPay」を用いた決済、「Yahoo!アカウント」を用いたユーザーのアカウント管理などを実施できます。

もともと「Yahoo!ショッピング」ではダークストア型の「Yahoo!マート by ASKUL」というサービスを提供していました。このサービスでは商品の仕入れ・販売の仕組みを自前で構築していたのですが、想定よりも事業展開が難しく、ラストワンマイルに強い出前館と組んではどうだろうということになり、プロジェクトが発足しました。

プロジェクトを進めるうえで、制約や前提条件などはありましたか？

向田：まず、出前館とLINEヤフー間でのシステム連携の制約がありました。出前館側のシステムは、LINEのプライベートクラウドである「Verda」内に構築しています。一方、ヤフー側は自社のインフラ内でシステムを運用しているので、両システム間で連携するためにネットワークをまたがなければならないのが、大変な点でした。LINEヤフーが合併してからまだ1年も経っていないので、ノウハウがほぼない状態からのスタートでした。

倉井：私からは制約というより、直前に進めていたプロジェクトが「クイックマート」にプラスになった点をお話しします。実はこのプロジェクトの前に「出前館」全体のシステム刷新のプロジェクトが動いていまして、出前館のテックリードたちが集まってどのような設計方針で進めるかの議論を重ねていました。

結局は「出前館」全体を刷新することにはならなかったのですが、「クイックマート」用のインフラを構築するにあたり、この刷新プロジェクトで議論したアーキテクチャや推奨技術などを使えたため、技術的な土台ができた状態からのスタートでした。

イベントドリブンで疎結合なアーキテクチャを実現

具体的には、どのような技術を採用していますか？

倉井：マイクロサービスアーキテクチャを取り入れており、注文・店舗・商品・カテゴリ・在庫など取り扱うドメインごとにサービスが分離されていて、それぞれ別のサーバーで動いています。いま挙げたようなサービス群がcoreと呼ばれる部分で、リテールにおける中心の機能です。

「Yahoo!ショッピング」側と情報を連携するところは、別のサービス群が動いています。他にも、既存の「出前館」のシステムに追加開発をして「クイックマート」用の機能を実装したサービスもあります。

向田：また、イベントドリブンな設計になっていることも大きな特徴です。たとえば、「注文を入れる」という機能のAPIが呼び出されると、それを起点にリテールのcoreシステムがイベントを発行し、それを各々のコンポーネントがサブスクライブして処理を連携していきます。イベントベースの設計であるためシステム間が疎結合であり、システムの拡張が容易で障害発生時のリトライなどもしやすいアーキテクチャになっています。

開発において工夫した点を挙げるなら、イベントのメッセージに持たせる情報の設計ですね。大きく分けると、メッセージのなかに多種多様な情報を詰める方法と、IDだけを持たせてデータが必要になればその都度APIを呼び出して情報を取得するという方法があります。今回は後者の設計にして、毎回最新の情報を取ってくるというアプローチを用いました。

「クイックマート」で採用した設計では、基本的にイベント処理の順序を保証しない方針を選んでいます。そのため、イベントが処理される順番によっては「特定のサービスに受け渡されたメッセージの情報が、必ずしも最新の情報ではない」というケースも起こり得るんです。古い情報をもとに処理を進めてしまわないように、とにかく最新のデータを使うという設計にしています。

ただ、この「順序を保証しない」という設計をすべてのケースで適用できるかというと、そうではないのが難しいところでした。たとえば「注文」に関するイベントは、注文が入って、受注可否の判断をして、注文された商品を用意して、というように順序が重要なので、「順序保証をすべき処理・そうでない処理」のそれぞれをどうさばくかが、アーキテクチャ構築において難しい部分でした。

今回は開発期間がかなりタイトでありリトライの構造などを丁寧に作り込むのが難しかったため、メッセージの状態が不適切であれば特定のイベント処理内でリトライをくり返すという一番シンプルな方法を選びました。

倉井：この設計方針を選んだ成果としては、「クイックマート」をリリースしてから注文フローのバグがほぼ出ていないんですよね。システム全体としてはかなり複雑なシーケンスですけれど、イベントドリブンな設計にしたからこそ想定外の挙動が発生しなかったんだと思います。

複数システム間の連携を円滑に行うために

他にはどのような点を工夫されましたか？

八幡：このプロジェクトでは、インターフェース定義が非常に重要でした。なぜなら、出前館側が「クイックマート」用に新規で作ったシステムと、もともとフードデリバリーの「出前館」で使われていたものに追加開発をしたシステム、「Yahoo!ショッピング」側のシステムという大きく分けて3種類のコンポーネントの連携を実現しなければならないからです。

それぞれのシステムで運用のポリシーが異なっていますから、それぞれの方針に準拠しつつシステム間でうまく連携するには、インターフェースをきちんと定義して通信やデータのやりとりを行うためのルールや仕様を明確化する必要がありました。

倉井：このプロジェクトでは、サービス間の通信方式としてgRPCを採用しており、それがインターフェース定義においてプラスに働きました。protoファイルを用いてリクエストやレスポンスのデータ形式、通信方法、メソッドなどを記述しているので、各サービスの担当者の間で「通信方法やデータ形式の認識が違った」というケースはほとんどありませんでした。

向田：システム間での連携が多いプロジェクトでしたが、採用した技術が功を奏した部分があって開発効率は落ちませんでした。イベントドリブンなので、何かの機能が増えればイベントを増やすことで対応できます。かつ、イベントの中身がProtocol Buffersなので、データの使用方法についての認識齟齬が起こるようなこともありませんでした。

八幡：インターフェース定義を進めるうえで他に大切にしたのは、各コンポーネントの担当者とのコミュニケーションです。プロジェクトを進める過程で、ビジネス職や企画職のメンバーから「こういう機能もほしい」とリクエストが来ることがありました。その際には、影響のあるシステムの担当者をすぐに交えて会話するようにしました。

当たり前ですが、その領域の担当者のほうが私よりも詳しい知識を持っているので、解決案がすぐ出せて意思決定がスピーディーにできました。タイトな開発スケジュールではあったのですが、こういったコミュニケーションを取りつつプロジェクトを進めたことで計画通りにリリースできたのだと思っています。

1→100を存分に楽しめるフェーズ

プロジェクトとしての今後の目標はありますか？

倉井：「クイックマート」はリリースされたばかりということもあり、まだ店舗数が少ないのですが、これからどんどん加盟店を増やして将来的には全国展開をしていきます。システムとしてパフォーマンスを向上させていきたいですね。

向田：開発期間が短く突貫で作った部分もあるので、それらの設計をもっときれいにして、より安定性のあるシステムにしたいです。

八幡：出前館とLINEヤフー両社の強みを、どんどん打ち出していきたいです。たとえば、「Yahoo!ショッピング」では各種のキャンペーンを積極的に実施しているのですが、「クイックマート」ではまだ実現できていないので、うまく組み込めたら良いですね。

最後に「これから出前館への入社を考えている」という方に向けて、「クイックマート」の開発のやりがいや面白さをお伝えください。

向田：商品を配達するサービスであるため、必ず間に人間が挟まります。その不確実さをシステムで解決するのは、エンジニアとして非常に面白い仕事だと思います。

八幡：今回はインターフェース定義の話をしましたが、複数の会社が絡むサービスだからこそ、企業間・サービス間での連携が必ず発生します。目標を実現するためにどのようなアプローチを取るべきかを考えて実現するのが、面白くやりがいにつながります。

倉井：「クイックマート」は出前館とLINEヤフー両社がかなり注力しているサービスであることは間違いありません。これから、事業もシステムもどんどん成長させていきます。0→1のフェーズはすでに終わってしまいましたが、これから1→100を存分に楽しめるフェーズですので、ぜひ出前館で働いていただければと思います。