Upgrade to Pro — share decks privately, control downloads, hide ads and more …

出前館アプリ進化論 アーキテクチャと組織のリアルな変⾰の舞台裏

出前館アプリ進化論 アーキテクチャと組織のリアルな変⾰の舞台裏

Avatar for 株式会社出前館

株式会社出前館

November 21, 2025
Tweet

More Decks by 株式会社出前館

Other Decks in Technology

Transcript

  1. © Demae-can Co., Ltd. Agenda 01 ⾃⼰紹介 02 ⽼舗サービスの歴史と変⾰の背景 03

    変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 04 変⾰フェーズⅡ: リアーキテクチャ 05 次の10年に向けて 2
  2. © Demae-can Co., Ltd. ⾃⼰紹介 • 所属 • LINEヤフー株式会社 京都開発室

    • 株式会社出前館 出向 • これまでの業務経験 • ~2021年 Web Frontend (React/Vue/BFF) • 2021年~ 出前館に参画 (React Native, Flutter) • その他 • JBA公認C級コーチライセンス 🏀 • 2児のパパ 植松 啓誠 株式会社出前館 プロダクト本部コンシューマ部 アプリ開発グループ 4
  3. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 • オンプレミス中⼼で運⽤ •

    システムの⼤半がオンプレ上で稼働 • データセンターの物理限界でスケールが困難 • サービス特性に合わせたインフラ構成でない • フードデリバリーは昼⾷・⼣⾷にピーク • ピークに合わせたリソース • 運⽤の属⼈化 • 知識・オペレーションの属⼈化 インフラ 23
  4. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 • オンプレミス中⼼で運⽤ •

    システムの⼤半がオンプレ上で稼働 • データセンターの物理限界でスケールが困難 • サービス特性に合わせたインフラ構成でない • フードデリバリーは昼⾷・⼣⾷にピーク • ピークに合わせたリソース • 運⽤の属⼈化 • 知識・オペレーションの属⼈化 インフラ クラウド移⾏⽅針 24
  5. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 バックエンド • サポートが終了したフレームワーク

    • セキュリティ上の懸念 • モノリシックな構造で責務が混在 • 結合度が⾼く、多くの機能ドメインが絡み合う • 開発速度や品質に⼤きな影響 • ⼀つの巨⼤なデータベース • アーキテクチャの中⼼に巨⼤な共有データベース • 800を超えるテーブルが存在 • 単⼀障害点に 25
  6. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 バックエンド • サポートが終了したフレームワーク

    • セキュリティ上の懸念 • モノリシックな構造で責務が混在 • 結合度が⾼く、多くの機能ドメインが絡み合う • 開発速度や品質に⼤きな影響 • ⼀つの巨⼤なデータベース • アーキテクチャの中⼼に巨⼤な共有データベース • 800を超えるテーブルが存在 • 単⼀障害点に 責務の切り分け・Microservices 26
  7. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 • Controllerの肥⼤化 •

    巨⼤な1ファイルにロジックが集約 • 7000⾏以上 • 多くのDead Code • 多くのビジネスロジックがclientに点在 • アプリ・Webでコピペロジックが多数点在 • 保守性・ロジックの⼀貫性に課題 • 既存の技術に関する知識・リソース不⾜ • PHPのエンジニア不⾜ Web Frontend 27
  8. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 • Controllerの肥⼤化 •

    巨⼤な1ファイルにロジックが集約 • 7000⾏以上 • 多くのDead Code • 多くのビジネスロジックがclientに点在 • アプリ・Webでコピペロジックが多数点在 • 保守性・ロジックの⼀貫性に課題 • 既存の技術に関する知識・リソース不⾜ • PHPのエンジニア不⾜ Web Frontend Web Server全体をフルリプレイス 28
  9. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 アプリ • 開発体制・プロセス

    • アウトソース中⼼の開発 • コード管理 • 属⼈化 • コード品質 • Clientによったビジネスロジック • ビジネスロジックの重複・分散 • テストがない 29
  10. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 アプリ • 開発体制・プロセス

    • アウトソース中⼼の開発 • コード管理 • 属⼈化 • コード品質 • Clientによったビジネスロジック • ビジネスロジックの重複・分散 • テストがない ドキュメント整備・コツコツ改修 30
  11. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 アプリ • 開発体制・プロセス

    • アウトソース中⼼の開発 • コード管理 • 属⼈化 • コード品質 • Clientによったビジネスロジック • ビジネスロジックの重複・分散 • テストがない ドキュメント整備・コツコツ改修 31 当時のGithubのlabel
  12. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 各コンポーネントの課題 ⽼舗ITサービスのモダナイズに取り組みはじめたLINEエンジニアたちの挑戦! 出前館の改善について和⽥卓⼈さんが聞いた (2021.02.10)

    https://hatenanews.com/articles/2021/02/10/103000 出前館アプリ開発における体制変化に伴う取り組み React Nativeを活⽤した継続開発のためのルール作成 (2021.12.15) https://logmi.jp/brandtopics/325608 32
  13. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 • サービスの理解とシステム全体像の理解

    • それぞれのチームで仕様/設計のドキュメント化 • ナレッジの蓄積・共有 • 次の段階に向けて愚直に改善 • リファクタリング • 責務分離 • 分散しているコードの共通化 • ライブラリ、フレームワークのアップデート • 環境の移⾏ • APIのinterface変更への対応 35
  14. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 • サービスの理解とシステム全体像の理解

    • それぞれのチームで仕様/設計のドキュメント化 • ナレッジの蓄積・共有 • 次の段階に向けて愚直に改善 • リファクタリング • 責務分離 • 分散しているコードの共通化 • ライブラリ、フレームワークのアップデート • 環境の移⾏ • APIのinterface変更への対応 変⾰フェーズⅠ: まずは変⾰のために各コンポーネントで課題把握と改善 36
  15. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ 当初(2021年ごろ)のアプリ⽬線の超概略アーキテクチャ DB でっかいAPI Server

    でっかい DB API for app Cache Web REST REST 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … REST Web Server App 40
  16. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ 当初(2021年ごろ)のアプリ⽬線の超概略アーキテクチャ DB でっかいAPI Server

    でっかい DB API for app Cache Web REST REST 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … REST • 運⽤が複雑 • コミュニケーションパス • 多段cacheなどで仕様が不明確 Web Server アプリ⽬線 App 41
  17. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ 当初(2021年ごろ)のアプリ⽬線の超概略アーキテクチャ DB でっかいAPI Server

    でっかい DB API for app Cache Web REST REST 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … REST • 運⽤が複雑 • コミュニケーションパス • 多段cacheなどで仕様が不明確 Web Server アプリ⽬線 • ⼊り⼝が複数 • ログの分散 • 攻撃リスク • 運⽤負荷が⾼い • DBが⾼負荷でサービス全体に影響 • 責務の混在 • 様々な場所からDB書き込み サービス⽬線 App 42
  18. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ 現在(未来も含む)のアプリ⽬線の超概略アーキテクチャ BFF Microservices Web

    GraphQ L gRPC 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … • ⼊り⼝を⼀つに • ログの⼀元性 • 認証認可の整合性 • 運⽤負荷軽減 • 責務を明確に • 独⽴性 • スケール • データの所在 • ビジネスロジックがBFFに集約 • (ほぼ)JSON⾊付けがかりに専念 • GraphQLでApp/Webで 最適なデータ取得 アプリ⽬線 サービス⽬線 App 43
  19. © Demae-can Co., Ltd. App 変⾰フェーズⅡ: リアーキテクチャ Webのリアーキテクチャ DB でっかいAPI

    Server でっかい DB REST REST 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … REST Web Server API for app Cache Web 44
  20. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ Webのリアーキテクチャ API for app

    Cache Web CodeIgniter BFF Web Next.js • 技術 • PHP -> Typescript • フルサーバーレンダリング -> Single Page Application 47
  21. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ Webのリアーキテクチャ API for app

    Cache Web CodeIgniter BFF Web Next.js • 技術 • PHP -> Typescript • フルサーバーレンダリング -> Single Page Application • ⽬的 • メンテナンス性の向上 • エンジニアリソースの最適化 • BFFへのビジネスロジックの移⾏ 48
  22. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ Webのリアーキテクチャ API for app

    Cache Web CodeIgniter BFF Web Next.js • 技術 • PHP -> Typescript • フルサーバーレンダリング -> Single Page Application • ⽬的 • メンテナンス性の向上 • エンジニアリソースの最適化 • BFFへのビジネスロジックの移⾏ • 移⾏ • 100以上の画⾯を移⾏ • 段階的にユーザーフローごとに切り替え • ClientのビジネスロジックをBFFへ • AppもWeb側の移⾏完了後にBFF経由へ移⾏ 49
  23. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ Webのリアーキテクチャ • メンテナンス性 •

    BFF/Webのコードの混在 • スケーラビリティ • 台数調整などが個別にできない • BFFはアプリからも参照されている • デプロイ/ロールバック時の切り離し • 両⽅同時にリリース/ロールバック BFF Web Apollo Server Next.js BFF(API Routes) Web Next.js 51
  24. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ Webのリアーキテクチャ BFF Web Apollo

    Server Next.js • BFFの役割の変化 • As-is • Cacheの共有 • To-be • App/Webのビジネスロジックの共通化 • 各Microservicesのオーケストレーション • 後⽅互換性の吸収 • 認証・認可の集約 • 組織の変化 • BFF: Web Team => BFF Team 52
  25. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ Webのリアーキテクチャ API for app

    Cache Web BFF Web Apollo Server Next.js CodeIgniter BFF Web Next.js 53 出前館Webリプレイスで直⾯した技術的課題と解決 (2023.04.25) https://engineering.linecorp.com/ja/blog/web-replace-demaecan
  26. © Demae-can Co., Ltd. REST App Web Server API for

    app Cache Web 変⾰フェーズⅡ: リアーキテクチャ バックエンドのリアーキテクチャ REST REST DB でっかいAPI Server でっかい DB 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … 54
  27. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ バックエンドのリアーキテクチャ DB でっかいAPI Server

    でっかい DB 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … Microservices 55
  28. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ バックエンドのリアーキテクチャ Ph1. データとロジックのオーナーシップの確⽴ DB

    でっかいAPI Server でっかい DB 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … 56 Ph2. 独⾃DBへの移⾏
  29. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ バックエンドのリアーキテクチャ DB でっかいAPI Server

    でっかい DB 店舗・商品 注⽂・決済 クーポン 会員情報 広告 クーポンDB 57 Ph1. データとロジックのオーナーシップの確⽴ • 800を越えるテーブルのオーナーシップ整理 • 新規マイクロサービス⽴ち上げ • データアクセス経路の切り替え
  30. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ バックエンドのリアーキテクチャ DB でっかいAPI Server

    でっかい DB 店舗・商品 注⽂・決済 クーポン 会員情報 広告 Ph1. データとロジックのオーナーシップの確⽴ • 800を越えるテーブルのオーナーシップ整理 • 新規マイクロサービス⽴ち上げ • データアクセス経路の切り替え Ph2. 独⾃DBへの移⾏ クーポンDB • サービス間の結合を物理的に切る • スケール戦略がしやすい • APIのInterfaceさえ守れば破壊的な変更も可 58
  31. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ バックエンドのリアーキテクチャ DB でっかいAPI Server

    でっかい DB 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … Microservices 59
  32. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ バックエンドのリアーキテクチャ DB でっかいAPI Server

    でっかい DB 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … Micro Services ⼤規模レガシーシステムのマイクロサービス化における 0→1 ではない-1→1 の新規開発 https://techblog.demae- can.co.jp/entry/20250805/1754383768 60
  33. © Demae-can Co., Ltd. API for app Cache Web Web

    Server 変⾰フェーズⅡ: リアーキテクチャ リアーキテクチャに伴うアプリ開発⽬線の変化 REST でっかいAPI Server 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … App 62
  34. © Demae-can Co., Ltd. API for app Cache Web Web

    Server 変⾰フェーズⅡ: リアーキテクチャ リアーキテクチャに伴うアプリ開発⽬線の変化 REST でっかいAPI Server 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … App 7 0 1 0 80以上のAPI • 多くのoverfetch/underfetch • Clientで重複したビジネスロジック 改修コストも⾼いしなんとかしたい 63
  35. © Demae-can Co., Ltd. API for app Cache Web Web

    Server 変⾰フェーズⅡ: リアーキテクチャ リアーキテクチャに伴うアプリ開発⽬線の変化 でっかいAPI Server 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … App BFF • BFFに移⾏されたAPIから徐々に移⾏ • overfetch/underfetchも少しずつ解消 • Microservice化もBFF層で吸収だ! BFF誕⽣ 徐々に移⾏ 全てBFF経由に移管 64 GraphQL
  36. © Demae-can Co., Ltd. API for app Cache Web Web

    Server 変⾰フェーズⅡ: リアーキテクチャ リアーキテクチャに伴うアプリ開発⽬線の変化 でっかいAPI Server 店舗・商品 注⽂・決済 クーポン 会員情報 広告 App BFF Microservices • 極⼒BFFで吸収 • 責務の整理でinterfaceが変わる • 負債を残さない • V2, V3… 何を移⾏して何を移⾏してないんだ …? 65 GraphQL Microservices
  37. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ リアーキテクチャに伴うアプリ開発⽬線の変化 BFF Micro Services

    GraphQ L gRPC 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … App めでたしめでたし(まだ終わってない) 66
  38. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ リアーキテクチャに伴うアプリ開発⽬線の変化 BFF Micro Services

    Web GraphQ L gRPC 店舗・商品 注⽂・決済 クーポン 会員情報 広告 … App 組織としてステークホルダーが明確に 67
  39. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 変⾰フェーズⅡ: リアーキテクチャ • プロダクト

    • 変更に強い構造 • 改善サイクルの⾼速化 • 組織 • 責務とオーナーの明確化 • 意思決定と開発速度の向上 70
  40. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 変⾰フェーズⅡ: リアーキテクチャ • プロダクト

    • 変更に強い構造 • 改善サイクルの⾼速化 • 組織 • 責務とオーナーの明確化 • 意思決定と開発速度の向上 • 未来への基盤 • 継続的な改善が可能なサービスに進化 • “変化し続けられる” 体質 71
  41. © Demae-can Co., Ltd. 変⾰フェーズⅠ: 各コンポーネントでの課題把握と改善 変⾰フェーズⅡ: リアーキテクチャ • プロダクト

    • 変更に強い構造 • 改善サイクルの⾼速化 • 組織 • 責務とオーナーの明確化 • 意思決定と開発速度の向上 • 未来への基盤 • 継続的な改善が可能なサービスに進化 • “変化し続けられる” 体質 72 “事業成⻑を⽌めずに” 徐々に アーキテクチャを移⾏し、変化に強いアーキテクチャ
  42. © Demae-can Co., Ltd. 変⾰フェーズⅡ: リアーキテクチャ 余談: アプリのリアーキテクチャ • ReactNative

    -> Flutter へ移⾏ Ask the Speaker or 出前館ブース でお話ししましょう!! https://techblog.demae-can.co.jp/entry/20250826/1756184068 出前館の⼤変⾰:React NativeからFlutterへの⼤胆な移⾏戦略 73
  43. © Demae-can Co., Ltd. 次の10年に向けて • 根幹 • ミッションの実現: テクノロジーで時間価値を⾼める

    • ビジョンの実現: 地域の⼈々の幸せをつなぐライフインフラ 75
  44. © Demae-can Co., Ltd. 次の10年に向けて • 根幹 • ミッションの実現: テクノロジーで時間価値を⾼める

    • ビジョンの実現: 地域の⼈々の幸せをつなぐライフインフラ • 開発プロセス:より速く、より安定した開発 • いかにユーザーへ価値を素早く届けるか • 事業成⻑を⽌めずに回しるづけられるプロセス 76
  45. © Demae-can Co., Ltd. 次の10年に向けて • 根幹 • ミッションの実現: テクノロジーで時間価値を⾼める

    • ビジョンの実現: 地域の⼈々の幸せをつなぐライフインフラ • 開発プロセス:より速く、より安定した開発 • いかにユーザーへ価値を素早く届けるか • 事業成⻑を⽌めずに回しるづけられるプロセス • ドキュメントと経緯を残し続ける • ⼀番効いた負債が「なぜこうなっているかわからない」状態 • 仕様だけではなく意思決定の経緯も残す 77
  46. © Demae-can Co., Ltd. 次の10年に向けて • 根幹 • ミッションの実現: テクノロジーで時間価値を⾼める

    • ビジョンの実現: 地域の⼈々の幸せをつなぐライフインフラ • 開発プロセス:より速く、より安定した開発 • いかにユーザーへ価値を素早く届けるか • 事業成⻑を⽌めずに回しるづけられるプロセス • ドキュメントと経緯を残し続ける • ⼀番効いた負債が「なぜこうなっているかわからない」状態 • 仕様だけではなく意思決定の経緯も残す • 質の⾼いコードと、技術負債との付き合い⽅ • “ゼロ負債”ではなく、“コントロールされた負債”を⽬指す • 継続的に技術負債を減らす 78