Tweet
Tweet

Slide 1

Slide 1 text

出前館のマルチプロダクト戦略を支える アーキテクチャ 〜技術的負債を解消しながら事業を多角化する〜

Slide 2

Slide 2 text

About me • 阿部将久（TechPM） • LINEヤフー → 出前館（出向） • 1児の父 / block chain • @osaguild

Slide 3

Slide 3 text

突然ですが、皆さんの会社ではいくつ プロダクトを開発していますか？

Slide 4

Slide 4 text

ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] SaaSの市場規模とプロダクト数は増え続けている

Slide 5

Slide 5 text

ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] SaaSの市場規模とプロダクト数は増え続けている

Slide 6

Slide 6 text

ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] コンパウンド戦略/バーティカルSaaSによる未開拓の領域を狙う企業

Slide 7

Slide 7 text

マルチプロダクトの時代

Slide 8

Slide 8 text

明日からマルチプロダクトを開発をすること になったらどうしますか？ 我が社も事業 を多角化する 今の開発だけで も精一杯なのに…

Slide 9

Slide 9 text

悩みは尽きない…. どんなプロダクト 作るの？ 今のAssetはどれだ け流用できるの か？ 開発リソース増や せるの？ ゼロイチなの？ 今のプロダクトど うするの？ とても手放せる状 態では… いつまでにリリー スするの？ リスク高くない？

Slide 10

Slide 10 text

マルチプロダクト化のトレンドは突然 出前館にもやってきた 出前館もプロダ クト増やすのだ ※ここから先は、出前館がマルチプロダクト化を成し遂げたかのお話

Slide 11

Slide 11 text

Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）

Slide 12

Slide 12 text

Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）

Slide 13

Slide 13 text

出前館について - 2000年にデリバリー総合サイト「出前館 」をオープンし、以来25年にわたりシングルプロダク トで事業を展開。 - 2016年にLINE株式会社（現LINEヤフー株式会社）と資本業務提携。 - コロナ禍でフードデリバリー事業が大躍進。現在はノンフード領域の拡大、新規事業の創出を 通じて事業拡大を目指す。 ref: Demaecan recruitment [https://recruit.demae-can.co.jp/discover-our-business/]

Slide 14

Slide 14 text

出前館のプロダクトについて consumer 1.注文 order 2.注文内容伝達 merchant delivery 3.集荷指示 4.集荷 5.お届け ユーザー 配達員 加盟店

Slide 15

Slide 15 text

ノンフード領域の拡大という課題

Slide 16

Slide 16 text

2024/8にYahoo!クイックマートをリリース

Slide 17

Slide 17 text

クイックマートについて consumer 1.注文 order 2.注文内容伝達 merchant delivery 3.集荷指示 4.集荷 5.お届け ユーザー 配達員 加盟店

Slide 18

Slide 18 text

Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）

Slide 19

Slide 19 text

出前館 クイックマート

Slide 20

Slide 20 text

出前館 クイックマート Consumerが違うだけ

Slide 21

Slide 21 text

違いに気づいた直後の自分 Yahoo!ショッピングと 出前館を繋ぐだけで、 何も作らなくてよいの では？

Slide 22

Slide 22 text

そんな簡単な話ではなかった

Slide 23

Slide 23 text

課題１：ドメインの違い（フード/ノンフード） フード ノンフード 医薬品 - ◯（規約同意/アンケート） 免許 酒 薬/酒/タバコ 在庫管理 △（欠品のみ） ◯（商品数の管理） ピッキング - ◯ ドメイン特定の違いにより、ユースケース/機能に大きな違いが発生する

Slide 24

Slide 24 text

出前館では数年前からフードのシステムの刷新を進行中。 - システム刷新とノンフード開発を同一componentで行うことに よる難易度が上がる - 技術負債をクイックマートが引き継いでしまう 課題２：フードのシステム刷新

Slide 25

Slide 25 text

（非採用）フード/ノンフードを共通化した構成 merchant delivery ユーザー 配達員 加盟店 consumer フード ノンフード consumer order

Slide 26

Slide 26 text

（採用）フード/ノンフードを分離した構成 Merchant (Food) delivery ユーザー 配達員 加盟店 consumer consumer Order (Food) Order (non-Food) Merchant (non-Food) フード ノンフード 機能差分が少なかったため、 deliveryは共通化

Slide 27

Slide 27 text

Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）

Slide 28

Slide 28 text

構成も決まったのでいざ開発へ！ しかし….開発するcomponentが多い

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動

Slide 34

Slide 34 text

2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動

Slide 35

Slide 35 text

理由１：アクター/ユースケース/ドメインが多い

Slide 36

Slide 36 text

理由２：ドメインの解像度が高く、マイクロサービスの経験が豊富 • フードの開発でドメイン知識をキャッチアップできていた。 • 出前館では4年前からマイクロサービス化を進めており、マイクロ サービスの開発経験が豊富だった

Slide 37

Slide 37 text

2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動

Slide 38

Slide 38 text

イベント駆動を採用した注文をキャンセルのフロー Order Y!shopping link Merchant link Delivery Y!shopping Actor User cancel Merchant Delivery

Slide 39

Slide 39 text

REST APIによる同期的なアーキテクチャを採用した場合、リクエストする側が主体となって処理を 進めなければいけない。 Order Y!shopping link Merchant link Delivery Y!shopping Actor User cancel Merchant Delivery API call API call API call - Apiを呼び出す順番 - Api callのエラーハンドリング

Slide 40

Slide 40 text

Event Sourcingを採用にすることでサービスの依存関係を逆転し疎結合にすることができた。 Order Y!shopping link Merchant link Delivery Y!shopping Actor User cancel Merchant Delivery produce consume Queue consume consume protobufでIF定義

Slide 41

Slide 41 text

決済失敗による結果整合性も補償トランザクションでシンプルに実装できた。 Order Y!shopping link Merchant link Delivery Y!shopping User Merchant Delivery error consume Queue consume 決済失敗 consume produce

Slide 42

Slide 42 text

これらの取り組み + エンジニアの頑張り で4ヶ月でなんとか開発できました。

Slide 43

Slide 43 text

Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）

Slide 44

Slide 44 text

成功１：agilityの高さ リリース直後にサービスのCoreスペックを変更することに。 → 約1日で開発してリリース フードとノンフードを分離することで、スピード感と柔軟性を持って プロダクトを改善することができた。

Slide 45

Slide 45 text

成功２：IF起因のバグが少なかった マイクロサービスでありがちな、サービス間のIFに起因するバグが少 なかった イベント駆動のアーキテクチャを採用し、gRPC/protobufでIFを定義し たことでバグの温床を未然に防ぐことができた。

Slide 46

Slide 46 text

成功３：フードの障害があっても動く 出前館でマルウェア感染が原因で長時間サービスが止まった → クイックマートは止まらなかった

Slide 47

Slide 47 text

失敗１：すべてのIFをgRPC/protobufで定義できなかった gRPC/protobufに統一できたのは、出前館内のIFだけで、Yahoo!ショッ ピングとのIFはRESTで定義した。 IFの認識合わせに多くの時間を使った。テストで苦戦したものRESTで 定義したIF。

Slide 48

Slide 48 text

失敗２：ノンフードのドメイン特性の理解不足 1リクエストで10,000件近い商品がノンフードでは登録されるという 事実が発覚 （フードでは多くても100件程度） 同期的処理として設計していた。急遽、非同期処理に作り変えること に。 ドメイン特性の違いによる機能影響は整理できていたが、非機能影響 の整理が不十分だった。

Slide 49

Slide 49 text

失敗３：フード/ノンフードを完全に分離できなかった ID体系をNumeric → ULIDに変更したらうまくいかなかった → 共通componentはNumeric型しか受け付けないため 結果、ノンフードでNumeric、ULIDの2種類のIDを採番して利用するこ とに。

Slide 50

Slide 50 text

まとめ 1. 出前館のような歴史のある企業でも、新プロダクトを短期間で開 発することはできる。 2. 既存サービスの水平展開の場合であっても、ドメイン特性が異な る場合は新規開発することによるメリットが大きい。 3. マイクロサービスはゼロイチで有効な選択肢になる。

Slide 51

Slide 51 text

We are hiring 出前館ではエンジニアを積極採用中です！