「全部書き直す」をしない選択 ー 巨大SPAと同居しながら小さく始めるフレームワーク移行 ー / We Chose Incremental Refactoring Over a Complete Rewrite

Transcript

1. 「全部書き直す」をしない選択 2026年2月12日 株式会社コドモン 吉田 芳明 ー 巨大SPAと同居しながら小さく始めるフレームワーク移行 ー
2. 15年ほどSIerで情報通信・Web関連のエンジニアしてました。 中2娘と4歳息子の父。 好きな 牛乳で固まるデザート はフルーチェ。 吉田 芳明 （よしよし） 2022.09 コドモンに入社 ストリームアラインドチームに所属 2024.05 イネイブリング/機能横断系のチームへ 負荷対策、基盤改善、チーム伴走 etc. @yoshi4c4c CoDMON 自己紹介
3. コドモンのフロントエンド事情
4. コドモンのフロントエンド事情 CoDMON • メインプロダクト ◦ 10年前の技術で構成されたSPA ◦ モバイルアプリ: Vue + Capacitor • マイクロサービス・新規事業 ◦ React
5. コドモンのフロントエンド事情 CoDMON • メインプロダクト ◦ 10年前の技術で構成されたSPA ◦ モバイルアプリ: Vue + Capacitor • マイクロサービス・新規事業 ◦ React 本日の内容
6. 10年前の技術で構成されたSPA 概ね
7. 10年前の技術で構成されたSPA CoDMON 複雑なフラグの条件分岐/イベント/非同期の嵐 変更→フルリロード5秒待って動作確認 書くのも動かすのも時間かかる割に壊れやすい スタイルを変えると別画面が壊れる 少しずつ違う似たコード リロードで反映 UIテストはE2E グローバルなCSS コピペ量産 手続き型 概ね
8. 10年前の技術で構成されたSPA CoDMON リロードで反映 UIテストはE2E グローバルなCSS コピペ量産 手続き型 複雑なフラグの条件分岐/イベント/非同期の嵐 変更→フルリロード5秒待って動作確認 書くのも動かすのも時間かかる割に壊れやすい スタイルを変えると別画面が壊れる 少しずつ違う似たコード 影響範囲 が読みづらく 不安 がつきまとう 開発結果の フィードバック が 遅い 概ね
9. 近年のWeb/フレームワークの進化 CoDMON リロードで反映 UIテストはE2E グローバルなCSS コピペ量産 宣言的UI HMR (Hot Module Replacement) Componentテスト, Playwright Scoped CSS など コンポーネント指向 手続き型
10. よし、これらの技術で 全部書き直そう！
11. よし、これらの技術で 全部書き直そう！ とはならない
12. 「全部書き直す」をしない選択 CoDMON • 巨大ゆえ、フルリプレイスは年単位 ⇨ 完了日ではなく 届け始められる日 を最短に • 市場/組織/技術動向は常に変化する ⇨ ”方針固めてやりぬく覚悟”より 変化の柔軟性 “完了する頃にはもう時代遅れ” 問題
13. "小さく" 始め、一歩ずつ進みたい
14. 選ばなかった選択肢: 外につくり段階移行 CoDMON 現行ページ 新しい フレームワークで つくったページ /feature_new /feature 別URLで新サイトをつくり、 URL単位で切り替える
15. • 初期コスト・二重管理コスト大 ◦ 最初につくるものが多い → ヘッダ/ナビゲーション、グローバルステート etc. ◦ 全機能の移行完了まで二重にメンテし続ける必要がある • SPAの体験への影響 ◦ 比較的ロードが ”重厚” なSPAなため、段階移行の ページの行き来でロードが頻発して体験が損なわれる 選ばなかった選択肢: 外につくり段階移行 CoDMON 現行ページ 新フレームワークで つくったページ /feature_new /feature
16. "小さく" 始め、一歩ずつ進みたい 再掲
17. そこで...
18. 「同居」 ー マルチフレームワーク アプローチ ー
19. 「同居」 - マルチフレームワーク アプローチ - CoDMON Webアプリケーション SPA ルーティング (動的な表示切り替え) 通常はひとつのフレームワークで 作ることが多い
20. Webアプリケーション 「同居」 - マルチフレームワーク アプローチ - CoDMON SPA ルーティング (動的な表示切り替え) 一部を別フレームワークで開発する
21. 「同居」 - マルチフレームワーク アプローチ - CoDMON • 開発初期コストが小さい ◦ 共通部品/インフラ/デプロイフローすべて変更なし • ユーザ体験がほぼ変わらない // ルータのページ遷移時の hook const app = createApp(component, { params }); app.mount(container); // divにマウント // ページ離脱時に app.unmount() を呼び出す SPAルータのページ遷移hookでマウント処理を差し込むだけ
22. 入居 にはトラブルがつきもの
23. トラブルを避ける よりよい 入居 のポイント やりとりは仲介業者をはさむ / プライベート空間を確保する レガシーとの
24. やりとりは 仲介業者 をはさむ CoDMON 新環境 レガシー レガシーな モデル レガシーな 仕組み 大家さんとの直接取引で大丈夫? 新環境側に「レガシー対策コード」が そのつど増えて共通化につながらない 改善するとき、新環境も影響を受ける
25. 中間層 やりとりは 仲介業者 をはさむ CoDMON 新環境 レガシー レガシーな モデル レガシーな 仕組み 中間層 を用意し、“腐敗防止層”とする 中間層1 レガシー構造の変換 中間層1の内容を Vueに仲介 (provide() etc.) 中間層2 主要部分はフレームワーク非依存 →Pure TS で書く 新環境はレガシー側の変更に影響をうけず、 IFが明確になることでテストもしやすくなる
26. プライベート空間 を確保する CoDMON .alert_content { margin: 0; // bootstrap 打ち消し } h1 { font-size: 30px; } h2 { font-size: 24px; } h3 { font-size: 16px; } ... タグ指定 同居人でも、過度に 干渉しない ことは大事 グローバルCSSの「打ち消し」が横行 同居する側も既存スタイルを 考慮したCSSを書くの? 部品単位でスタイル確認しづらい
27. プライベート空間 を確保する CoDMON Shadow DOM により新旧の CSSを隔離 社内デザインシステムも CSS汚染によるデザイン崩れを 気にせず安心して導入 const MyCustomElement = defineCustomElement(vueComponent, { configureApp }); customElements.define('my-custom-element', MyCustomElement); VueでWeb Components化はとても簡単↓
28. CoDMON ポイントは「フレームワーク非依存」であること 将来的なフレームワーク変更・メジャーver.UP対応でも おなじ手段による 漸進的「引越し」ができる
29. 「同居」のデメリット
30. 同居のデメリット CoDMON • 依存のバンドルサイズが増える ◦ もともとページ単位のLazyloadであり、サイト全体は影響軽微 • 新旧で依存ライブラリの複数バージョン混在 ◦ そもそも新旧で重複するライブラリが少なく影響軽微 ◦ 今後、グローバル/DOM関連でバッティングする場合は要対処 • 認知負荷増 〜 どっちのフレームワークで動いてるの? 〜 ◦ あえて「ページ」単位の移行のみに限定 ◦ SPAルータを見ればどちらかわかる
31. この環境で得たもの
32. CoDMON 影響範囲 が読みづらく 不安 がつきまとう 開発結果の フィードバック が 遅い リロードで反映 UIテストはE2E グローバルなCSS コピペ量産 手続き型 この環境で得たもの
33. CoDMON 影響範囲 が読みづらく 不安 がつきまとう 開発結果の フィードバック が 遅い リロードで反映 UIテストはE2E グローバルなCSS コピペ量産 手続き型 この環境で得たもの 宣言的UI HMR (Hot Module Replacement) Componentテスト, Playwright Scoped CSS コンポーネント指向 影響範囲が限定されたことによる 開発者の 安心 + AIとの 親和性 開発結果の 迅速 な フィードバック
34. まとめ
35. まとめ CoDMON • 巨大SPAのリプレイス ◦ ”完了する頃にはもう時代遅れ” 問題 ◦ 「同居」は小さく始める 現実解 になりうる • 入居時のポイント ◦ 中間層の設置とCSS分離でレガシーの影響を最小化 ◦ ↑をフレームワーク非依存で実現すると将来の「引越し」の 備えにもなる • レガシーだから...と進化をあきらめなくてもいい！
36. CoDMON コドモン採用ページ コドモンでは、ともに課題を紐解き、一歩一歩前に進んでいく 仲間を募集しています！ 開発チームX