Vue.jsからNext.jsへの移行 - 技術選定の背景と今後の課題

e-dash株式会社が提供する、企業のCO2排出量の可視化・削減を支援するSaaS『e-dash』のリプレイスに伴い、フロントエンドをVue.jsからNext.jsへ移行した際の経緯と技術的背景についてお話します。

Transcript

1. © e-dash Co., Ltd. Vue.jsからNext.jsへの移⾏ 技術選定の背景と今後の課題
2. © e-dash Co., Ltd. 2 • 陳 ⽂⾵（ちん ぶんふう） • ⽇本のアニメが⼤好きで2009年来⽇ • 6歳と4歳娘のパパ • 2015〜2022 ウェブ関連の仕事全般 • 2023〜2024 Freelance Engineer • 2025〜現在 Frontend Engineer at e-dash株式会社 ⾃⼰紹介
3. © e-dash Co., Ltd. 3 e-dash株式会社について • 企業のCO2排出量可視化‧削減の⽀援までのSaaSを開発‧運営 • 三井物産出資のスタートアップ • 2022年設⽴‧本社は⾚坂⾒附付近
4. © e-dash Co., Ltd. 4 プロダクト（e-dash）について
5. © e-dash Co., Ltd. 5 プロダクト（e-dash）の開発チーム
6. © e-dash Co., Ltd. 技術選定の背景‧変遷
7. © e-dash Co., Ltd. 7 Vue.jsからNext.jsへの移⾏タイムライン 2024.04 移⾏⽇ 2023.08 移⾏検討開始 2022. 02 創業 移⾏前（〜 2024/4 外注） 移⾏後（2024/4 〜 内製化） 2025.03 現在
8. © e-dash Co., Ltd. 8 技術選定の背景 - Vue.jsの採⽤理由と廃⽌理由 Vue.jsの当初のメリット デメリットになった理由（Next.jsへの移⾏背景） ⼩規模なチームでも素早く開 発できた ⼤規模開発になると、設計の統⼀やスケーラビリティの確保が難しくなった PHP（Laravel）と親和性が ⾼い PHPの密結合構造が拡張を阻害し、アーキテクチャの柔軟性が低下 学習コストが低く導⼊しやす かった Vue2のEOLでVue3へ移⾏が必要 → APIの違いが⼤きく、移⾏コストが⾼い 状態管理を意識せずシンプル に開発できる 規模拡⼤で管理が複雑化し、型安全なReactの⽅が適していた 外部エンジニアがVueに慣れ ていた 当時社内エンジニアはReactの知⾒があり、技術的な統⼀がしやすかった Vue.jsは⼩規模開発や素早い開発に適していたが、プロダクトの成⻑とともにメンテナンス性‧スケール性に課題が出てきた。
9. © e-dash Co., Ltd. 9 技術選定の変遷 - なぜNext.jsへ移⾏したのか？ 移⾏前（〜 2024/4 外注） 移⾏後（2024/4 〜 内製化） PHP 7.3（2021年内サポート終了） + Vue2（2023年 内サポート終了）。 Go + Next.js（Pages Router）でモダンな技術スタック で再構築。 コード規約が定まっていないため、各画⾯の書き⽅が バラバラ。 コード規約や共通ルールを定め、全画⾯で⼀貫した実 装を実現。 パーツが共通化されていないがゆえに個別に更新が必 要。 パーツをコンポーネント化にし、保守性と更新効率を ⼤幅に向上。 フレームワークやライブラリの使い⽅がバラバラ （Vue2にjQueryが使われた）。 Next.js + TypeScriptを基盤に、状態管理‧データ取得 など⼀貫性のある開発環境を構築。 技術や実装ルールが統⼀されず、変更対応に時間がか かっていた。 社内で技術を統⼀し、ノウハウを蓄積しながら柔軟に 開発できる体制を構築し、お客様の要望にもスピー ディーに対応可能に。 型安全性‧拡張性‧エコシステムの充実度からReactを採⽤し、SSRや開発効率の向上のためNext.jsを選択した。
10. © e-dash Co., Ltd. 現在の技術スタックと選定理由
11. © e-dash Co., Ltd. 11 • ⾔語‧FW： TypeScript、Next.js（Pages Router） • UIライブラリ： Tailwind CSS、Storybook、Material UI • バリデーション： React Hook Form、Zod • テスト： Jest、Playwright • その他： Docker、DevCycle、Lefthook、MSW、Swagger、Sentry 現在の技術スタック
12. © e-dash Co., Ltd. 12 • 安定性を重視 ◦ Pages Routerは⻑年の運⽤実績があり、安定して使える。 ◦ App Routerは仕様変更のリスクが⾼く、導⼊時（2023/8頃）の不確実性があった。 • 既存エンジニアのスキルを最⼤限に活かせる ◦ Pages Routerは従来のReact開発経験と近く、スムーズにキャッチアップ可能。 ◦ App RouterではuseEffectの使い⽅が⼤きく変わるなど、新たな学習コストが発⽣す るため、開発スピードに影響を与える可能性があった。 ➡ 将来的にApp Routerの安定性を確認しつつ、段階的な移⾏を検討 Pages Routerを採⽤した理由
13. © e-dash Co., Ltd. 直近のフロントエンド開発業務
14. © e-dash Co., Ltd. 14 • Zodを⽤いてフォームで受け取るデータのスキー マを定義することで、バリデーションルールと TypeScriptの型を⼀致させることが可能になる。 • React Hook Formでは、@hookform/resolvers パッケージを利⽤して、Zodのスキーマを resolverとして渡すことで、フォーム送信時や⼊ ⼒変更時に⾃動でZodによるバリデーションが実 ⾏される。 RHF + Zod でフォームバリデーションの実装
15. © e-dash Co., Ltd. 15 1. OpenAPI 仕様から⾃動⽣成した型定義 2. ⾃動⽣成した型をResponseの型として使⽤ 3. モックAPIの中⾝を実装 4. handlers をエクスポートし、MSWの設定時 に使⽤可能にする。  ※ このサンプルコードはMSW実装の⼀部を抜粋  したものです。 MSW + OpenAPI でMock APIの実装
16. © e-dash Co., Ltd. 技術的課題や今後の展望
17. © e-dash Co., Ltd. 17 • パフォーマンスの懸念 ◦ 機能豊富な分、ライブラリ⾃体が⼤きく、パフォーマンスやバン ドルサイズに影響が出る場⾯もあった。 • カスタマイズの制約 ◦ デフォルトのスタイルが強く、社内で⼀貫したデザインを実現す るためのカスタマイズが予想以上に⼿間だった。 ➡ 今後は e-dash UI（カスタマイズが容易に出来るradix-uiをベースに開発中）に移⾏予定 Material UIの課題
18. © e-dash Co., Ltd. 18 • 状態管理ライブラリRecoilの開発停⽌ ◦ Meta社が開発していたRecoilは、2025年1⽉に公式リポジトリが アーカイブされ、開発が停⽌しています。 ◦ 今後のアップデートやバグ修正が期待できないため、⻑期的な 運⽤リスクがある。 ➡ 現在も活発に開発が⾏われている Jotai、Zustand、TanStack Query などを候補として検討    ※一部ではReactのContextを継続使用する。 状態管理の最適化に関する課題
19. © e-dash Co., Ltd. 19 今後のe-dashフロントエンド • 社内⼀部のプロダクトでは既にApp Routerを導⼊済みで、安定性を確 認後、e-dashにも導⼊を⽬指す • 社内共通のUIコンポーネントライブラリ（e-dash UI）を構築 • 現在も活発に開発が⾏われている状態管理ライブラリ（Jotai、 Zustand、TanStack Queryなど）への移⾏を検討する
20. © e-dash Co., Ltd. まとめ
21. © e-dash Co., Ltd. 21 Vue.jsからNext.jsへの移⾏の結論と学び • 移⾏の結論 🚀 技術スタックの統⼀により、開発効率と保守性が向上 🚀 内製化により、仕様変更や機能追加に迅速対応が可能 🚀 新機能の追加やシステムの拡張に対応できる柔軟な開発基盤を整備 • 技術選定のポイント ✅ 技術選定は流⾏ではなく、プロダクトの課題解決を最優先に ✅ メンテナンス性と拡張性を意識（EOLやエコシステムの安定性を考慮） ✅ 移⾏を前提とした設計が重要（技術進化が速いため、柔軟な設計を意識する）
22. © e-dash Co., Ltd. 22 募集中のポジション