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

アーキテクチャconferenceの登壇資料です

Transcript

1. 出前館のマルチプロダクト戦略を支える アーキテクチャ 〜技術的負債を解消しながら事業を多角化する〜
2. About me • 阿部将久（TechPM） • LINEヤフー → 出前館（出向） • 1児の父 / block chain • @osaguild
3. 突然ですが、皆さんの会社ではいくつ プロダクトを開発していますか？
4. ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] SaaSの市場規模とプロダクト数は増え続けている
5. ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] SaaSの市場規模とプロダクト数は増え続けている
6. ref: Japan SaaS Insights 2024 [https://onecapital.kit.com/61feb45c15] コンパウンド戦略/バーティカルSaaSによる未開拓の領域を狙う企業
7. マルチプロダクトの時代
8. 明日からマルチプロダクトを開発をすること になったらどうしますか？ 我が社も事業 を多角化する 今の開発だけで も精一杯なのに…
9. 悩みは尽きない…. どんなプロダクト 作るの？ 今のAssetはどれだ け流用できるの か？ 開発リソース増や せるの？ ゼロイチなの？ 今のプロダクトど うするの？ とても手放せる状 態では… いつまでにリリー スするの？ リスク高くない？
10. マルチプロダクト化のトレンドは突然 出前館にもやってきた 出前館もプロダ クト増やすのだ ※ここから先は、出前館がマルチプロダクト化を成し遂げたかのお話
11. Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）
12. Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）
13. 出前館について - 2000年にデリバリー総合サイト「出前館 」をオープンし、以来25年にわたりシングルプロダク トで事業を展開。 - 2016年にLINE株式会社（現LINEヤフー株式会社）と資本業務提携。 - コロナ禍でフードデリバリー事業が大躍進。現在はノンフード領域の拡大、新規事業の創出を 通じて事業拡大を目指す。 ref: Demaecan recruitment [https://recruit.demae-can.co.jp/discover-our-business/]
14. 出前館のプロダクトについて consumer 1.注文 order 2.注文内容伝達 merchant delivery 3.集荷指示 4.集荷 5.お届け ユーザー 配達員 加盟店
15. ノンフード領域の拡大という課題
16. 2024/8にYahoo!クイックマートをリリース
17. クイックマートについて consumer 1.注文 order 2.注文内容伝達 merchant delivery 3.集荷指示 4.集荷 5.お届け ユーザー 配達員 加盟店
18. Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）
19. 出前館 クイックマート
20. 出前館 クイックマート Consumerが違うだけ
21. 違いに気づいた直後の自分 Yahoo!ショッピングと 出前館を繋ぐだけで、 何も作らなくてよいの では？
22. そんな簡単な話ではなかった
23. 課題１：ドメインの違い（フード/ノンフード） フード ノンフード 医薬品 - ◯（規約同意/アンケート） 免許 酒 薬/酒/タバコ 在庫管理 △（欠品のみ） ◯（商品数の管理） ピッキング - ◯ ドメイン特定の違いにより、ユースケース/機能に大きな違いが発生する
24. 出前館では数年前からフードのシステムの刷新を進行中。 - システム刷新とノンフード開発を同一componentで行うことに よる難易度が上がる - 技術負債をクイックマートが引き継いでしまう 課題２：フードのシステム刷新
25. （非採用）フード/ノンフードを共通化した構成 merchant delivery ユーザー 配達員 加盟店 consumer フード ノンフード consumer order
26. （採用）フード/ノンフードを分離した構成 Merchant (Food) delivery ユーザー 配達員 加盟店 consumer consumer Order (Food) Order (non-Food) Merchant (non-Food) フード ノンフード 機能差分が少なかったため、 deliveryは共通化
27. Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）
28. 構成も決まったのでいざ開発へ！ しかし….開発するcomponentが多い
33. 2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動
34. 2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動
35. 理由１：アクター/ユースケース/ドメインが多い
36. 理由２：ドメインの解像度が高く、マイクロサービスの経験が豊富 • フードの開発でドメイン知識をキャッチアップできていた。 • 出前館では4年前からマイクロサービス化を進めており、マイクロ サービスの開発経験が豊富だった
37. 2つの技術的アプローチ 1. マイクロサービス 2. イベント駆動
38. イベント駆動を採用した注文をキャンセルのフロー Order Y!shopping link Merchant link Delivery Y!shopping Actor User cancel Merchant Delivery
39. 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のエラーハンドリング
40. Event Sourcingを採用にすることでサービスの依存関係を逆転し疎結合にすることができた。 Order Y!shopping link Merchant link Delivery Y!shopping Actor User cancel Merchant Delivery produce consume Queue consume consume protobufでIF定義
41. 決済失敗による結果整合性も補償トランザクションでシンプルに実装できた。 Order Y!shopping link Merchant link Delivery Y!shopping User Merchant Delivery error consume Queue consume 決済失敗 consume produce
42. これらの取り組み + エンジニアの頑張り で4ヶ月でなんとか開発できました。
43. Agenda 1. 出前館と新プロダクト 2. 作らない開発を目指したが失敗した話 3. 15のcomponentを4ヶ月で作りきった話 4. 振り返り（成功談/失敗談）
44. 成功１：agilityの高さ リリース直後にサービスのCoreスペックを変更することに。 → 約1日で開発してリリース フードとノンフードを分離することで、スピード感と柔軟性を持って プロダクトを改善することができた。
45. 成功２：IF起因のバグが少なかった マイクロサービスでありがちな、サービス間のIFに起因するバグが少 なかった イベント駆動のアーキテクチャを採用し、gRPC/protobufでIFを定義し たことでバグの温床を未然に防ぐことができた。
46. 成功３：フードの障害があっても動く 出前館でマルウェア感染が原因で長時間サービスが止まった → クイックマートは止まらなかった
47. 失敗１：すべてのIFをgRPC/protobufで定義できなかった gRPC/protobufに統一できたのは、出前館内のIFだけで、Yahoo!ショッ ピングとのIFはRESTで定義した。 IFの認識合わせに多くの時間を使った。テストで苦戦したものRESTで 定義したIF。
48. 失敗２：ノンフードのドメイン特性の理解不足 1リクエストで10,000件近い商品がノンフードでは登録されるという 事実が発覚 （フードでは多くても100件程度） 同期的処理として設計していた。急遽、非同期処理に作り変えること に。 ドメイン特性の違いによる機能影響は整理できていたが、非機能影響 の整理が不十分だった。
49. 失敗３：フード/ノンフードを完全に分離できなかった ID体系をNumeric → ULIDに変更したらうまくいかなかった → 共通componentはNumeric型しか受け付けないため 結果、ノンフードでNumeric、ULIDの2種類のIDを採番して利用するこ とに。
50. まとめ 1. 出前館のような歴史のある企業でも、新プロダクトを短期間で開 発することはできる。 2. 既存サービスの水平展開の場合であっても、ドメイン特性が異な る場合は新規開発することによるメリットが大きい。 3. マイクロサービスはゼロイチで有効な選択肢になる。
51. We are hiring 出前館ではエンジニアを積極採用中です！