iAEONの段階的リアーキテクト戦略 / iAEON's_Gradual_Re-architecture_Strategy

2026年6月18日開催「【止められないサービスを止めずに作り直す】大規模モバイルアプリ リアーキテクチャの最前線｜AEON TECH HUB #26」の登壇資料です

Transcript

1. iAEONの段階的リアーキテクト戦略 イオンスマートテクノロジー株式会社 iAEON開発チーム 渡邉 大樹
2. 自己紹介 イオンスマートテクノロジー株式会社 iAEON開発チーム 渡邉 大樹 【会社の仕事】 iAEONアプリの開発 【家の仕事】 生き物のお世話 - レオパ、カニ、ドジョウ、カブトムシ、クワガタ など - 米（稲）、ひまわり、ヘチマ など 自己紹介
3. 3 iAEONアプリについて
4. 4 iAEONアプリについて
5. • なぜ、今iAEONアプリのリアーキが必要なのか？ • どのように進めるか？〜段階的移行戦略〜 • リアーキ後のiAEONアプリはどうなるのか？ • まとめ 5 本日のアジェンダ
6. なぜ、今 iAEONアプリのリアーキが必要なのか
7. 7 なぜ、今 iAEON アプリのリアーキが必要なのか iAEONアプリは、 「Ionic + Cordovaフレームワークを採用したWebViewベースのハイブリッドアプリ」 です。 現状のアプリでは、以下3つの視点で課題を抱えています。 UX（ユーザー体験） アプリの「もたつき」など、体感 品質が構造上の限界に DX（開発者体験） 「変えたくても変えられない」構 造が開発の足かせに アーキテクチャ 現行の技術基盤が、ビジネス成長 における制約の一因に これらの課題を解決し、今後も成長し続けるために、iAEONアプリのリアーキを現在進行中
8. 8 UX（ユーザー体験） アプリの「もたつき」は、構造上の限界から来ている - WebViewを用い、Webコンテンツをアプリ内で表示する設計のため、ネイティブと比較し、もっさりとする - WebレイヤーとNativeレイヤーの間の処理が増え、レスポンス遅延が発生する - UX改善が部分対応に留まり、根本的な改善が困難 なぜ、今 iAEON アプリのリアーキが必要なのか
9. 9 DX（開発者体験） 開発チームも課題を感じていた。。。 「変えたくても変えられない」構造に悩んでいた。 なぜ、今 iAEON アプリのリアーキが必要なのか
10. 10 DX（開発者体験）悩み〜その１〜 密結合構造により、変更時の影響範囲が大きい なぜ、今 iAEON アプリのリアーキが必要なのか
11. 11 DX（開発者体験）悩み〜その２〜 テストコードが書けない構造により、品質担保に不安、リファクタも大胆にできず なぜ、今 iAEON アプリのリアーキが必要なのか
12. 12 DX（開発者体験）悩み〜その３〜 従来の技術スタックにより、エンジニア採用の選択肢に制約があった なぜ、今 iAEON アプリのリアーキが必要なのか
13. 13 DX（開発者体験）悩み〜その４〜 技術負債によって、開発スピードと品質が低下し、悪循環に陥る なぜ、今 iAEON アプリのリアーキが必要なのか
14. 14 アーキテクチャ 現行の構成は、将来的な拡張やスピード向上の観点から、改善する価値がある - Ionic + Cordova は現行でも安定稼働している一方、将来の拡張を見据えた構成の見直しのタイミングにきている - 最新OS・セキュリティ対策への追従コストが年々増大 - ビジネス成長を前提とした技術基盤になっていない 現行アプリの構成 Webアプリ（Angular / TypeScript） Ionic + Cordova ＝継続利用に伴う制約が増加 WebView iOS / Android（OS） なぜ、今 iAEON アプリのリアーキが必要なのか
15. どのように進めるか？ 〜段階的移行戦略〜
16. 16 方針：ビッグバンリリースはしない サービスを止めずに、既存アプリの中身を段階的に置き換える - 新機能開発・改善が常に並行して進んでおり、全面作り直し（ビッグバンリリース）は現実的でない - 既存のWeb資産を活かしながら、画面・機能単位で順次置き換えていく - ユーザーから見える変化は最小限に。でも中身は確実に新しくなっていく 現在：旧基盤 過渡期：新旧が混在 完了：すべて新基盤へ どのように進めるか？ 〜段階的移行戦略〜
17. 17 3つのフェーズで段階的に進める 「新基盤構築 → 段階的置換 → 旧基盤全削除」の順に、リスクを抑えながら確実に進 める Phase 1 新基盤構築 Cordova から Capacitor へ基盤 を移行し、Nativeを組み込める土 台を構築 見た目・UXの変化はなく、基盤のみ を移行 Phase 2 段階的置換 画面・機能単位で Native / ミニ プログラムへ順次置き換え 起動速度・主要画面のUX改善を順次 体感可能に Phase 3 旧基盤全削除 旧WebView関連モジュール・ Capacitorを完全削除 完全Native基盤が完成 既存アプリを活かしながら進化させ、サービスを止めずに完全Native基盤へ どのように進めるか？ 〜段階的移行戦略〜
18. 18 現行：従来基盤への依存 アプリのすべての画面が、従来基盤上に構築されており、柔軟な改善が難しい構造 現行 Phase 1 Phase 2 Phase 3 アプリ画面（Web資産：TypeScript / Angular） Ionic / Cordova（従来基盤） iOS / Android（OS） アプリ全体が従来基盤に依存し、UX（ユーザー体験）とDX（開発者体験）の両方を制約 どのように進めるか？ 〜段階的移行戦略〜
19. 19 Phase 1：Capacitorへ基盤のみを移行 Web資産（TypeScript / Angular）をそのまま活かし、基盤だけをCapacitorへ移行する 現行 Phase 1 Phase 2 Phase 3 アプリ画面（Web資産） TypeScript / Angular をそのまま利用 Capacitor（新基盤） NativeとWebViewの層を分離 iOS / Android（OS） 見た目やUXは何も変わらない — リスクを抑えて、基盤だけを安全に置き換える どのように進めるか？ 〜段階的移行戦略〜
20. 20 Phase 2：Native・ミニプログラムへ段階的に移行 UX改善を進めたい機能からNativeへ、リリースを伴わず変更したい画面はミニプログ ラムへ 現行 Phase 1 Phase 2 Phase 3 Native Swift / Kotlin・UX改善したい機 能から順次移行 ミニプログラム 必要に応じてDLして利用 現行Web資産 徐々に縮退 Capacitor（基盤） iOS / Android（OS） Phase 2から、起動速度や主要画面のUX改善をユーザーが順次体感できる どのように進めるか？ 〜段階的移行戦略〜
21. 21 Phase 3：完全Nativeへ移行 移行を完了し、Capacitorと旧Web資産（Ionic / Cordova、TypeScript / Angular）を削除す る 現行 Phase 1 Phase 2 Phase 3 Native Swift / Kotlin ミニプログラム React Capacitor / Ionic・Cordova / TypeScript・Angular すべて完全削除 iOS / Android（OS） 完全Native基盤が完成し、既存の技術資産はゼロに どのように進めるか？ 〜段階的移行戦略〜
22. 22 Phase 1：データ移行 Webストレージ上のデータを、種類に応じたNative標準のストレージへ移行 - Native 移行後はWebストレージのデータへアクセスできなくなるため、事前の移行が必要 - Nativeストレージへ移すことで、WebViewとNativeの双方からデータを利用可能に データの種類 iOS Android 認証情報（トークン など） Keychain Keystore + DataStore JSON・配列などの大きめのデータ SQLite（GRDB.swift） SQLite（Room） フラグ・設定値などの軽量なデータ UserDefaults DataStore どのように進めるか？ 〜段階的移行戦略〜
23. 23 Phase 1：Capacitor化（基盤の移行） 既存のWebリソースを活かしたまま、アプリの基盤のみを Cordova から Capacitor へ移 行 - Nativeへ直接移行すると既存資産を捨てるビッグバンリリースになるため、まず基盤のみを移行 - 基盤のみの置き換えのため、UI / UX に変化はなく、ユーザーへの影響はない As-Is：Cordova - Web主体で動作するハイブリッドアプリ前提 の設計 - Swift / Kotlin を直接扱えない（JS⇔Nativeブ リッジが前提） - ネイティブ主体への移行が困難 To-Be：Capacitor - 既存のIonic / Cordovaプラグインや、Webで 実装されたリソースをそのまま利用できる - NativeとWebViewの層を分離して管理 （Nativeプロジェクトを直接編集・拡張でき る） - 段階的なNative移行が可能に どのように進めるか？ 〜段階的移行戦略〜
24. 24 Phase 2：2つの実装方式を使い分ける 現行WebViewの画面を徐々に縮退させ、特性に応じた方式で置き換える Native実装（Swift / Kotlin） 特徴 高速・滑らかな操作性、デバイス機能をフル活用 移行方針 ホームなど、UX品質を重視する画面から先行してNative化 適用例 ホーム / 支払い・会員証 / 起動処理・共通UI など リリース ストア審査が必要（リードタイムが発生） ミニプログラム実装（WebView + React） 特徴 Reactベースのアプリ。CMSに登録したミニアプリを必要 なタイミングでダウンロードして利用 移行方針 A/Bテストなど、アプリリリースを伴わず変更したい画面 から先行して移行 適用例 会員登録 / ログイン / お知らせ / マイページ など リリース ストア審査不要で、即時リリース・迅速な改善が可能 移行が進むにつれて現行WebViewの画面は縮退し、Phase 3で完全に削除する どのように進めるか？ 〜段階的移行戦略〜
25. 25 Native実装のアーキテクチャ設計方針 疎結合でテスタブルな「MVPアーキテクチャ」を採用 - UIとビジネスロジックを疎結合に分離し、iOS / Androidで共通の設計思想を実現 - Modelのユニットテストを必須化し、CIでPull Request時に自動実行 - ロジックがUI（WebView / Native）に依存しないため、画面の置き換え時も流用可能 View UI表示・入力受付 Presenter ViewとModelの仲介 Model ビジネスロジック・データ ユニットテスト必須・CIで自動実行 どのように進めるか？ 〜段階的移行戦略〜
26. 26 MVPアーキテクチャの全体像 各レイヤーの責務を明確に分離し、テスタビリティと保守性を確保する View UI表示と入力の受付 WebView Webで生成したUIを表示 （JS Bridge経由） Native View SwiftUI / Jetpack Compose ユーザーアクション 表示指示 Presenter ViewとModelの仲介役。 Modelからの結果を、表示す るViewに応じた形式に変換 する 処理を要求 結果を返却 Model Domain Layer（UseCase） ビジネスロジックを担当。ユースケース毎のア プリケーション仕様を実現 Data Layer（Repository） システムロジックを担当。API実行や、データの 取得 / 更新処理を行う ViewがWebViewでもNativeでも、Presenter以降の構造は共通 — ロジックを流用できる どのように進めるか？ 〜段階的移行戦略〜
27. 27 MVPアーキテクチャ：Data Layerの構成 Repositoryがデータソースへのアクセスを抽象化し、UseCaseは取得元を意識せずに Entityを扱える Repository データアクセスの窓口 Native API（カメラ・位置情報 など） SDK 3rd Party Library（Firebase / Adjust / NewRelic など） REST APIs Firestore Local Storage Entity アプリ内で扱うデータモデルへ変換 データソース データソースの差し替えや追加があっても、影響はData Layer内に閉じる どのように進めるか？ 〜段階的移行戦略〜
28. 28 Phase 3：旧基盤の全削除 Phase 2が完了次第、旧基盤を完全に削除し「完全Native基盤」が完成する - 旧基盤（Capacitor）と（旧）WebView関連モジュールを全削除 - 従来資産の整理により、メンテナンスコストと技術的負債を解消 Phase 2完了時点 Native / ミニプログラム Capacitor（残存） （旧）WebView関連モジュール Phase 3：完全Native基盤 Native / ミニプログラム 旧基盤・Capacitorを完全削除 WebView関連モジュールを全削除 どのように進めるか？ 〜段階的移行戦略〜
29. リアーキ後のiAEONアプリは どうなるのか？
30. 30 リアーキが実現するiAEONアプリの未来 ビジネスの成長を支える開発基盤が整う 体感的に速く、ストレスのないUX 「もたつき」を意識させない、快適な操作性を実現 変化に強く、ビジネスの成長を加速できるプロダクト 小さな改善を素早く・継続的に届け、顧客の声をタイムリーに取り込む 品質を保ちながら、持続的に進化できる開発基盤 テストによる品質担保とモダンな技術スタックで、人と組織が成長し続けられる環境へ リアーキ後のiAEONアプリはどうなるのか？
31. まとめ
32. 32 まとめ - 課題：従来の技術基盤が、UX（ユーザー体験）とDX（開発者体験）の両方を制約していた - 方針：ビッグバンリリースはせず、サービスを止めずに3つのフェーズで段階的にリスクを抑え ながらリアーキを進める - 目標：速く・変えやすく・持続可能なiAEONアプリへ リアーキは「コストではなく投資」— 成長し続けるための技術基盤の再構築 まとめ
33. 以上、ご清聴ありがとうございました！