Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
出前館のマルチプロダクト戦略を支えるアーキテクチャ 〜技術的負債を解消しながら事業を多角化する〜
Search
株式会社出前館
November 26, 2024
Technology
1
210
出前館のマルチプロダクト戦略を支えるアーキテクチャ 〜技術的負債を解消しながら事業を多角化する〜
アーキテクチャconferenceの登壇資料です
株式会社出前館
November 26, 2024
Tweet
Share
More Decks by 株式会社出前館
See All by 株式会社出前館
出前館を支えるJavaとKotlin
demaecan
0
280
滑らかなユーザー体験も目指す注文管理のマイクロサービス化〜注文情報CSVダウンロード機能の事例〜
demaecan
0
270
Yahoo!クイックマート管理画面でNext.js + static exportsを選んだ理由
demaecan
0
39
出前館アプリにおけるFlutterアプリ設計とそれを支えるCICD環境の進化
demaecan
0
820
新卒1年目の自分に伝えたかったエンジニアの成長に役に立つ話
demaecan
0
1.8k
新卒エンジニアが0からNon-BlockingなgPRCサーバーを作った話
demaecan
1
560
出前館におけるFlutter活用事例
demaecan
0
580
出前館アプリにおける Flutterアプリ設計
demaecan
2
980
プロダクト本部紹介資料
demaecan
0
14k
Other Decks in Technology
See All in Technology
金融システムをモダナイズするためのAmazon Elastic Kubernetes Service(EKS)ノウハウ大全
daitak
0
120
toittaにOpenTelemetryを導入した話 / Mackerel APM リリースパーティ
cohalz
1
440
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
17k
RDRA3.0を知ろう
kanzaki
2
410
Microsoft Season of Agent AI エージェントの使用開始
takas0522
0
120
What's Next in OpenShift Q2 CY2025
redhatlivestreaming
1
460
AIエージェントデザインパターンの選び方
almondo_event
0
120
KMP導⼊において、マネジャーとして考えた事
sansantech
PRO
1
190
データプレーンプログラミングとは? DPU&スイッチASICの開発経験から語る
ebiken
PRO
0
110
ローカル環境でAIを動かそう!
falken
PRO
1
150
それでもぼくらは貢献をつづけるのだ(たぶん) @FOSS4GLT会#002
furukawayasuto
1
260
CSS polyfill とその未来
ken7253
0
130
Featured
See All Featured
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
1
70
Optimising Largest Contentful Paint
csswizardry
37
3.3k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
Raft: Consensus for Rubyists
vanstee
137
7k
Building Adaptive Systems
keathley
41
2.6k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.4k
Typedesign – Prime Four
hannesfritz
41
2.6k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
740
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.5k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
14
1.5k
YesSQL, Process and Tooling at Scale
rocio
172
14k
Transcript
出前館のマルチプロダクト戦略を支える アーキテクチャ 〜技術的負債を解消しながら事業を多角化する〜
About me • 阿部将久(TechPM) • LINEヤフー → 出前館(出向) • 1児の父
/ block chain • @osaguild
突然ですが、皆さんの会社ではいくつ プロダクトを開発していますか?
ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] SaaSの市場規模とプロダクト数は増え続けている
ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] SaaSの市場規模とプロダクト数は増え続けている
ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] コンパウンド戦略/バーティカルSaaSによる未開拓の領域を狙う企業
マルチプロダクトの時代
明日からマルチプロダクトを開発をすること になったらどうしますか? 我が社も事業 を多角化する 今の開発だけで も精一杯なのに…
悩みは尽きない…. どんなプロダクト 作るの? 今のAssetはどれだ け流用できるの か? 開発リソース増や せるの? ゼロイチなの? 今のプロダクトど
うするの? とても手放せる状 態では… いつまでにリリー スするの? リスク高くない?
マルチプロダクト化のトレンドは突然 出前館にもやってきた 出前館もプロダ クト増やすのだ ※ここから先は、出前館がマルチプロダクト化を成し遂げたかのお話
Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り(成功談/失敗談)
Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り(成功談/失敗談)
出前館について - 2000年にデリバリー総合サイト「出前館 」をオープンし、以来25年にわたりシングルプロダク トで事業を展開。 - 2016年にLINE株式会社(現LINEヤフー株式会社)と資本業務提携。 - コロナ禍でフードデリバリー事業が大躍進。現在はノンフード領域の拡大、新規事業の創出を 通じて事業拡大を目指す。
ref: Demaecan recruitment [https://recruit.demae-can.co.jp/discover-our-business/]
出前館のプロダクトについて consumer 1.注文 order 2.注文内容伝達 merchant delivery 3.集荷指示 4.集荷 5.お届け
ユーザー 配達員 加盟店
ノンフード領域の拡大という課題
2024/8にYahoo!クイックマートをリリース
クイックマートについて consumer 1.注文 order 2.注文内容伝達 merchant delivery 3.集荷指示 4.集荷 5.お届け
ユーザー 配達員 加盟店
Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り(成功談/失敗談)
出前館 クイックマート
出前館 クイックマート Consumerが違うだけ
違いに気づいた直後の自分 Yahoo!ショッピングと 出前館を繋ぐだけで、 何も作らなくてよいの では?
そんな簡単な話ではなかった
課題1:ドメインの違い(フード/ノンフード) フード ノンフード 医薬品 - ◯(規約同意/アンケート) 免許 酒 薬/酒/タバコ 在庫管理
△(欠品のみ) ◯(商品数の管理) ピッキング - ◯ ドメイン特定の違いにより、ユースケース/機能に大きな違いが発生する
出前館では数年前からフードのシステムの刷新を進行中。 - システム刷新とノンフード開発を同一componentで行うことに よる難易度が上がる - 技術負債をクイックマートが引き継いでしまう 課題2:フードのシステム刷新
(非採用)フード/ノンフードを共通化した構成 merchant delivery ユーザー 配達員 加盟店 consumer フード ノンフード consumer
order
(採用)フード/ノンフードを分離した構成 Merchant (Food) delivery ユーザー 配達員 加盟店 consumer consumer Order
(Food) Order (non-Food) Merchant (non-Food) フード ノンフード 機能差分が少なかったため、 deliveryは共通化
Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り(成功談/失敗談)
構成も決まったのでいざ開発へ! しかし….開発するcomponentが多い
None
None
None
None
2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動
2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動
理由1:アクター/ユースケース/ドメインが多い
理由2:ドメインの解像度が高く、マイクロサービスの経験が豊富 • フードの開発でドメイン知識をキャッチアップできていた。 • 出前館では4年前からマイクロサービス化を進めており、マイクロ サービスの開発経験が豊富だった
2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動
イベント駆動を採用した注文をキャンセルのフロー Order Y!shopping link Merchant link Delivery Y!shopping Actor User
cancel Merchant Delivery
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のエラーハンドリング
Event Sourcingを採用にすることでサービスの依存関係を逆転し疎結合にすることができた。 Order Y!shopping link Merchant link Delivery Y!shopping Actor
User cancel Merchant Delivery produce consume Queue consume consume protobufでIF定義
決済失敗による結果整合性も補償トランザクションでシンプルに実装できた。 Order Y!shopping link Merchant link Delivery Y!shopping User Merchant
Delivery error consume Queue consume 決済失敗 consume produce
これらの取り組み + エンジニアの頑張り で4ヶ月でなんとか開発できました。
Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り(成功談/失敗談)
成功1:agilityの高さ リリース直後にサービスのCoreスペックを変更することに。 → 約1日で開発してリリース フードとノンフードを分離することで、スピード感と柔軟性を持って プロダクトを改善することができた。
成功2:IF起因のバグが少なかった マイクロサービスでありがちな、サービス間のIFに起因するバグが少 なかった イベント駆動のアーキテクチャを採用し、gRPC/protobufでIFを定義し たことでバグの温床を未然に防ぐことができた。
成功3:フードの障害があっても動く 出前館でマルウェア感染が原因で長時間サービスが止まった → クイックマートは止まらなかった
失敗1:すべてのIFをgRPC/protobufで定義できなかった gRPC/protobufに統一できたのは、出前館内のIFだけで、Yahoo!ショッ ピングとのIFはRESTで定義した。 IFの認識合わせに多くの時間を使った。テストで苦戦したものRESTで 定義したIF。
失敗2:ノンフードのドメイン特性の理解不足 1リクエストで10,000件近い商品がノンフードでは登録されるという 事実が発覚 (フードでは多くても100件程度) 同期的処理として設計していた。急遽、非同期処理に作り変えること に。 ドメイン特性の違いによる機能影響は整理できていたが、非機能影響 の整理が不十分だった。
失敗3:フード/ノンフードを完全に分離できなかった ID体系をNumeric → ULIDに変更したらうまくいかなかった → 共通componentはNumeric型しか受け付けないため 結果、ノンフードでNumeric、ULIDの2種類のIDを採番して利用するこ とに。
まとめ 1. 出前館のような歴史のある企業でも、新プロダクトを短期間で開 発することはできる。 2. 既存サービスの水平展開の場合であっても、ドメイン特性が異な る場合は新規開発することによるメリットが大きい。 3. マイクロサービスはゼロイチで有効な選択肢になる。
We are hiring 出前館ではエンジニアを積極採用中です!