25年耕した大地と向き合う Oisixが描く、 豊かな収穫のための次世代基盤

アーキテクチャ Conference 2025 (https://architecture-con.findy-tools.io/2025) での発表資料です。

Oisixを25年以上支えたシステムは巨大な技術的負債となりました。2018年開始の第二世代刷新は、守りを重視した結果停滞し、理想と現実のギャップを痛感。この失敗から「負債解消は短期決戦」と学び、アプローチを180度転換しました。
現在は、売上貢献ドメインから攻める第三世代プロジェクトを推進。クラウドネイティブ技術で挑む道は産みの苦しみを伴いますが、LLM活用APIなど未来への光も見えています。ビジネス中心から攻める戦略的判断と、挑戦から得られた学びを共有します。

Transcript

1. 25年耕した⼤地と向き合う Oisixが描く、 豊かな収穫のための次世代基盤 アーキテクチャConference2025 1
2. サービスの紹介 • 今年で25周年 • ⾷品の定期宅配ECサービス • モバイルアプリとブラウザー対応 • 毎週⽊曜⽇に商品が⼊れ替え 2
3. 今⽇話すトピックの範囲 Subscription Inventory Shipping Shopping Support Customer Recommend ation Promotion Analytics Payment … 3
4. 今⽇のトピック • どんな対応をしてきたか？ ◦ 2回のリアーキテクチャ ◦ オンプレからCloud移⾏ • どこで成功したか？ • どこで失敗したか？ 25年⽬ともなるとレガシーに対応せざるを得ません 4
5. Platform Engineer - Manager モラー・ミカエル Mollard Michael 2016年〜2025年： フランスの⾦融業界で開発者 2025年3⽉〜： オイシックス・ラ・⼤地 ⼊社 趣味：カラフルな壁から落ちること！ 5
6. 6 クライミングと仕事の意外な共通点
7. レガシーとは？ そのコードって 去年私が書いたやつじゃ ん、、、 ここはレガシーの部分だから、 0から作らなきゃ・・・ 私 7 ※私の過去の経験です ビクッ！
8. レガシーとは？ レガシー ＝ 遺産 レガシー ＝ プロダクト レガシー ＝ 愛 8
9. ・・・⼊社してたった半年なのに、もう⽂句？ 決して文句ではありません 過去を少し掘り下げて歴史を学ぼう！ 9
10. ⽬次 1. Oisix誕⽣・第⼀世代の姿 2. 移⾏・成功・失敗と学び a. 第⼆世代 b. Cloud移⾏ 3. 第三世代のはじまり 10
11. 第X世代とは？ 第⼀世代：OisixECの最初のアーキテクチャ 中⾝の更新は何回もあったが今も稼働中！ 第⼆世代：⼀番⽬のリアーキテクチャ 第三世代：⼆番⽬のリアーキテクチャ 11
12. Oisix誕⽣・第⼀世代の姿 12
13. Oisixが誕⽣した2000年 13 Linkin Park リンキン・パーク
14. 14 当時のUI
15. 第⼀世代の姿 15
16. 第⼀世代の良かったところ • アーキテクチャを⼤きく変えずとも20年の開発（事業成 ⻑）を⽀えた • アプリケーションとコンテンツが分離しており、毎週変わ るコンテンツの差し替えが容易 • 構成がシンプルで、⼿動のデプロイ作業に便利だった 16
17. 第⼀世代の問題点 コンテキストロス メンバーの転職・退職で 徐々に記憶が消えていく アンチパターン Lava Layer Dead code 運⽤が難しい スケーリングは⼿動 設計による問題 フロントとDBが接続している セッションがステートフル 17
18. 2025 2024 移⾏・成功・失敗と学び 2021 2020 2017 第三世代 Cloud移⾏ 第⼆世代 18
19. 第⼆世代：全ての問題を同時に解消する 19
20. 第⼀世代の問題点へのアプローチ コンテキストロス メンバーの転職・退職で 徐々に記憶が消えていく →移⾏の際に機能⾃体を整理し直す アンチパターン Lava Layer Dead code →移⾏の際に機能⾃体を整理し直す 運⽤が難しい スケーリングは⼿動 →バッチ処理をスケール可能化 →キャッシュでDBの負担を防ぐ ＋オンプレミスからクラウドへ 設計による問題 フロントとDBが接続している セッションがステートフル →フロントとDBを切り離す →セッションレスAPIを作成する 20
21. 当時の移⾏の⽅針＝「守り」 21 • 「⼈気が⾼く、ユーザーへの影響が⼤きい売り場にはすぐ ⼿を⼊れない」という⽅針 • 移⾏はエラーが出てもお客様に影響がでない機能からス タート 例：商品のレビュー ⽬標： 新システムを導⼊しながら経験を積み、その“新世代”を育てた うえで、他の領域にも段々と広げていくこと
23. 第⼆世代・当時の期待→全て解決 23 第⼆世代移⾏で全て解決！と思いきや・・・
24. 第⼆世代・実際の結果 成功 • 定期受注作成のバッチにかかる時間を半分にできた ※定期受注＝Oisix全会員の定期配達ボックス作成 • 新機能が⽣まれました（例：商品レビュー） • DBへの負担をある程度キャッシュでカバー 24
25. 2025 2024 第⼆世代・実際の結果 2021 2020 2017 第三世代 AWS移⾏ 第⼆世代 25
26. 第⼆世代：実際の結果 失敗理由についての考察１ 同時に導⼊する技術が多すぎて開発が複雑になったのではないか 26 ⾔語：Java→Kotlin フレームワーク：独⽴→Spring アプリ：テンプレ→API インフラ： オンプレ→Azure VM→Kubernetes Oracle→MySQL 結果： 学習によるプロジェクト延⻑ 刷新を担当したチーム以外の⼈は 開発不可能
27. 第⼆世代：実際の結果 失敗理由についての考察２ 移⾏済・未移⾏の機能が混在し新機能開発コストが増えた 27 問題： 移⾏されていない部分があると、 その機能の改善・追加時に、移⾏ を含めて予算を⽴てなければいけ ない 結果： 社内での基盤のイメージが悪化する
28. 第⼆世代：実際の結果 失敗理由についての考察３ ⼈間も⽔も抵抗の少ない⽅へ流れる 28 問題： まだ移⾏されてない機能を触る時 に、移⾏コストで予算が増⼤！ ＋ 新しい基盤での開発は難しそう 結果： 第⼀世代で開発を⾏う
29. Cloud移⾏ 29
30. 2024 AWS移⾏ 2021 2020 2017 第三世代 Cloud移行 第二世代 2025 30
31. 優先度 31 問題があるのはソフトウェア開発では⽇常 どのように優先度を決めよう？ 売上アップ・コスト削減も⼤事ですが 囲碁で⾔う「⼤場より急場」 ＝重⼤リスクにつながる箇所から優先的に取り組む⽅針
32. 理由 32 ＋DBのストレージ障害 ユーザー数の増加
33. Oisix誕⽣・第⼀世代の姿・問題点 コンテキストロス ⼈が転職・退職したり 時間が経つだけでも、記憶が消えたり アンチパターン Lava Layer Dead code 運⽤が難しい スケーリングは⼿動 設計による問題 フロントとDBが接続している セッションがステートフルになちゃいった 33
34. 34 AWS移⾏前
35. 35 AWS移⾏後
36. AWS移⾏の結果 36 コスト⼀時増加 採⽤⼒アップ 可⽤性の改善 ⽣産性アップ その代わりに得たもの
37. 第三世代のはじまり 37
38. 第三世代でのアプローチ • フロントエンドとバックエンドの開発を同時に⾏う • できるだけ「⼩さく早く」リリースする • 第三世代のシステムが独⽴して動くようにする ◦ 第三世代が第⼀世代から呼ばれるのではなく、第三世代が 直接クライアントのリクエストに答える *必要に応じて第三世代から第⼀世代を呼ぶ設計へ • チームがすでに理解している技術 を活⽤ 38
39. ⽅針＝「売上貢献ドメインから攻める」 39 • 多くのユーザーが利⽤し、更新頻度の⾼い箇所から移⾏を スタート • 移⾏する際はページ全体を丸ごと新しい仕組みに置き換え る⽅針を採⽤ ⽬標： 売上貢献ドメインが移⾏すれば、今後の新機能開発は新基 盤上で進められる状態を実現する
40. 第三世代の姿 40
41. まとめ 41
42. 世代移行で学んだこと 第⼀世代：シンプルさの価値 • 20年間ビジネスを⽀えた安定性 • アプリとコンテンツ分離の恩恵 第⼆世代：理想と現実のギャップ • 全問題同時解決の複雑さ • 新技術⼀⻫導⼊の学習コスト • ビジネス価値優先の重要性 42
43. 今日のまとめ • レガシーは悪いものではなく向き合って学ぶ • 事情に合わせて計画を柔軟に変更しよう • 失敗を恐れずにトライし続ける • 過去から学んで未来に⽣かす 43
44. ご清聴ありがとうございました 44