iAEONの段階的リアーキテクト戦略 イオンスマートテクノロジー株式会社 iAEON開発チーム 渡邉 大樹 

自己紹介 イオンスマートテクノロジー株式会社 iAEON開発チーム 渡邉 大樹 【会社の仕事】 iAEONアプリの開発 【家の仕事】 生き物のお世話 - レオパ、カニ、ドジョウ、カブトムシ、クワガタ など - 米（稲）、ひまわり、ヘチマ など 自己紹介 

3 iAEONアプリについて 

4 iAEONアプリについて 

• なぜ、今iAEONアプリのリアーキが必要なのか？ • どのように進めるか？〜段階的移行戦略〜 • リアーキ後のiAEONアプリはどうなるのか？ • まとめ 5 本日のアジェンダ 

なぜ、今 iAEONアプリのリアーキが必要なのか 

7 なぜ、今 iAEON アプリのリアーキが必要なのか iAEONアプリは、 「Ionic + Cordovaフレームワークを採用したWebViewベースのハイブリッドアプリ」 です。 現状のアプリでは、以下3つの視点で課題を抱えています。 UX（ユーザー体験） アプリの「もたつき」など、体感 品質が構造上の限界に DX（開発者体験） 「変えたくても変えられない」構 造が開発の足かせに アーキテクチャ 現行の技術基盤が、ビジネス成長 における制約の一因に これらの課題を解決し、今後も成長し続けるために、iAEONアプリのリアーキを現在進行中 

8 UX（ユーザー体験） アプリの「もたつき」は、構造上の限界から来ている - WebViewを用い、Webコンテンツをアプリ内で表示する設計のため、ネイティブと比較し、もっさりとする - WebレイヤーとNativeレイヤーの間の処理が増え、レスポンス遅延が発生する - UX改善が部分対応に留まり、根本的な改善が困難 なぜ、今 iAEON アプリのリアーキが必要なのか 

9 DX（開発者体験） 開発チームも課題を感じていた。。。 「変えたくても変えられない」構造に悩んでいた。 なぜ、今 iAEON アプリのリアーキが必要なのか 

10 DX（開発者体験）悩み〜その１〜 密結合構造により、変更時の影響範囲が大きい なぜ、今 iAEON アプリのリアーキが必要なのか 

11 DX（開発者体験）悩み〜その２〜 テストコードが書けない構造により、品質担保に不安、リファクタも大胆にできず なぜ、今 iAEON アプリのリアーキが必要なのか 

12 DX（開発者体験）悩み〜その３〜 従来の技術スタックにより、エンジニア採用の選択肢に制約があった なぜ、今 iAEON アプリのリアーキが必要なのか 

13 DX（開発者体験）悩み〜その４〜 技術負債によって、開発スピードと品質が低下し、悪循環に陥る なぜ、今 iAEON アプリのリアーキが必要なのか 

14 アーキテクチャ 現行の構成は、将来的な拡張やスピード向上の観点から、改善する価値がある - Ionic + Cordova は現行でも安定稼働している一方、将来の拡張を見据えた構成の見直しのタイミングにきている - 最新OS・セキュリティ対策への追従コストが年々増大 - ビジネス成長を前提とした技術基盤になっていない 現行アプリの構成 Webアプリ（Angular / TypeScript） Ionic + Cordova ＝継続利用に伴う制約が増加 WebView iOS / Android（OS） なぜ、今 iAEON アプリのリアーキが必要なのか 

どのように進めるか？ 〜段階的移行戦略〜 

16 方針：ビッグバンリリースはしない サービスを止めずに、既存アプリの中身を段階的に置き換える - 新機能開発・改善が常に並行して進んでおり、全面作り直し（ビッグバンリリース）は現実的でない - 既存のWeb資産を活かしながら、画面・機能単位で順次置き換えていく - ユーザーから見える変化は最小限に。でも中身は確実に新しくなっていく 現在：旧基盤 過渡期：新旧が混在 完了：すべて新基盤へ どのように進めるか？ 〜段階的移行戦略〜 

17 3つのフェーズで段階的に進める 「新基盤構築 → 段階的置換 → 旧基盤全削除」の順に、リスクを抑えながら確実に進 める Phase 1 新基盤構築 Cordova から Capacitor へ基盤 を移行し、Nativeを組み込める土 台を構築 見た目・UXの変化はなく、基盤のみ を移行 Phase 2 段階的置換 画面・機能単位で Native / ミニ プログラムへ順次置き換え 起動速度・主要画面のUX改善を順次 体感可能に Phase 3 旧基盤全削除 旧WebView関連モジュール・ Capacitorを完全削除 完全Native基盤が完成 既存アプリを活かしながら進化させ、サービスを止めずに完全Native基盤へ どのように進めるか？ 〜段階的移行戦略〜 

18 現行：従来基盤への依存 アプリのすべての画面が、従来基盤上に構築されており、柔軟な改善が難しい構造 現行 Phase 1 Phase 2 Phase 3 アプリ画面（Web資産：TypeScript / Angular） Ionic / Cordova（従来基盤） iOS / Android（OS） アプリ全体が従来基盤に依存し、UX（ユーザー体験）とDX（開発者体験）の両方を制約 どのように進めるか？ 〜段階的移行戦略〜 

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 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 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 Phase 1：データ移行 Webストレージ上のデータを、種類に応じたNative標準のストレージへ移行 - Native 移行後はWebストレージのデータへアクセスできなくなるため、事前の移行が必要 - Nativeストレージへ移すことで、WebViewとNativeの双方からデータを利用可能に データの種類 iOS Android 認証情報（トークン など） Keychain Keystore + DataStore JSON・配列などの大きめのデータ SQLite（GRDB.swift） SQLite（Room） フラグ・設定値などの軽量なデータ UserDefaults DataStore どのように進めるか？ 〜段階的移行戦略〜 

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 Phase 2：2つの実装方式を使い分ける 現行WebViewの画面を徐々に縮退させ、特性に応じた方式で置き換える Native実装（Swift / Kotlin） 特徴 高速・滑らかな操作性、デバイス機能をフル活用 移行方針 ホームなど、UX品質を重視する画面から先行してNative化 適用例 ホーム / 支払い・会員証 / 起動処理・共通UI など リリース ストア審査が必要（リードタイムが発生） ミニプログラム実装（WebView + React） 特徴 Reactベースのアプリ。CMSに登録したミニアプリを必要 なタイミングでダウンロードして利用 移行方針 A/Bテストなど、アプリリリースを伴わず変更したい画面 から先行して移行 適用例 会員登録 / ログイン / お知らせ / マイページ など リリース ストア審査不要で、即時リリース・迅速な改善が可能 移行が進むにつれて現行WebViewの画面は縮退し、Phase 3で完全に削除する どのように進めるか？ 〜段階的移行戦略〜 

25 Native実装のアーキテクチャ設計方針 疎結合でテスタブルな「MVPアーキテクチャ」を採用 - UIとビジネスロジックを疎結合に分離し、iOS / Androidで共通の設計思想を実現 - Modelのユニットテストを必須化し、CIでPull Request時に自動実行 - ロジックがUI（WebView / Native）に依存しないため、画面の置き換え時も流用可能 View UI表示・入力受付 Presenter ViewとModelの仲介 Model ビジネスロジック・データ ユニットテスト必須・CIで自動実行 どのように進めるか？ 〜段階的移行戦略〜 

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 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 Phase 3：旧基盤の全削除 Phase 2が完了次第、旧基盤を完全に削除し「完全Native基盤」が完成する - 旧基盤（Capacitor）と（旧）WebView関連モジュールを全削除 - 従来資産の整理により、メンテナンスコストと技術的負債を解消 Phase 2完了時点 Native / ミニプログラム Capacitor（残存） （旧）WebView関連モジュール Phase 3：完全Native基盤 Native / ミニプログラム 旧基盤・Capacitorを完全削除 WebView関連モジュールを全削除 どのように進めるか？ 〜段階的移行戦略〜 

リアーキ後のiAEONアプリは どうなるのか？ 

30 リアーキが実現するiAEONアプリの未来 ビジネスの成長を支える開発基盤が整う 体感的に速く、ストレスのないUX 「もたつき」を意識させない、快適な操作性を実現 変化に強く、ビジネスの成長を加速できるプロダクト 小さな改善を素早く・継続的に届け、顧客の声をタイムリーに取り込む 品質を保ちながら、持続的に進化できる開発基盤 テストによる品質担保とモダンな技術スタックで、人と組織が成長し続けられる環境へ リアーキ後のiAEONアプリはどうなるのか？ 

まとめ 

32 まとめ - 課題：従来の技術基盤が、UX（ユーザー体験）とDX（開発者体験）の両方を制約していた - 方針：ビッグバンリリースはせず、サービスを止めずに3つのフェーズで段階的にリスクを抑え ながらリアーキを進める - 目標：速く・変えやすく・持続可能なiAEONアプリへ リアーキは「コストではなく投資」— 成長し続けるための技術基盤の再構築 まとめ 

以上、ご清聴ありがとうございました！