[Frontend Replace] エコシステム設計篇

こんにちは。FE チームの Maple です。
あなたは今、フロントエンド開発の迷宮で道に迷っていませんか？ライブラリの選定、アーキテクチャ設計、テスト戦略...様々な選択肢に囲まれ、何を選べば良いのか頭を抱えていることでしょう。

私たちのチームは、まさにそんな迷宮を抜け出すための"地図"を手に入れました。今回は、私たちが新しいフロントエンド環境の刷新にあたって辿り着いた、理想的なエコシステム設計についてお伝えします。

なぜエコシステム設計が重要なのか

フロントエンド開発は、単に React や Vue といったフレームワークを選ぶだけでは終わりません。

真の開発効率と持続可能性は、これらのツールをどう組み合わせ、どう連携させるか——つまり「エコシステム」の設計にかかっています。適切なエコシステム設計により、チームの生産性は飛躍的に向上し、長期的なメンテナンス性も確保できるのです。

今回の記事では、私たちが何百時間もの議論と検証を経て辿り着いた、最適なフロントエンドエコシステムの全貌を共有します。

フレームワーク選定

• フレームワーク: Next.js
  • SSR/SSG/ISR など多様なレンダリング戦略をサポート
  • App Router によるファイルベースのルーティング
  • React Server Components のネイティブサポート
  • 選定理由: エコシステムの成熟度と、多様なレンダリング戦略の柔軟性が決め手でした。特に SSG と ISR によるパフォーマンス最適化が、私たちのプロダクトに必要だったのです。また、大規模コミュニティによるサポートと、Vercel による継続的な進化も魅力でした。Svelteと最後まで悩みましたが、成熟度が決め手でした。

基本構成

ビルド・パッケージ管理

• パッケージマネージャ: bun

  • 選定理由: npm 比で約 3 倍の高速インストールを実現しつつ、npm 互換性を保っている点が決め手でした。また、ビルド・テスト・実行の統合環境としての可能性も評価しています。（今回はランライムでは不採用です）

• ランタイム: Node.js

  • 選定理由: 安定性と互換性を重視し、現時点では最も広くサポートされている Node.js を採用しました。

スタイリング

• CSS: CSS Modules + Sass
  • コンポーネントに閉じたスタイリング
  • 学習コスト低く、デザイナーとの協業が容易
  • プリプロセッサとして Sass を採用
  • 選定理由: Tailwind CSS や CSS-in-JS も検討しましたが、CSS Modules は学習コストが低く、既存の CSS 知識をそのまま活かせる点が決め手でした。また、デザインシステムとの連携や、デザイナーとの協業もスムーズです。特に Sass による変数や関数の活用で、効率的なスタイリングが可能。

コンポーネント管理

• UI カタログ: Storybook
  • @storybook/addon-designs で Figma との連携
  • デザインシステムとの同期性を確保
  • 選定理由: コンポーネントの開発・テスト・ドキュメント化を一元管理できる点が最大の魅力です。特に Figma との連携により、デザイン → 実装のギャップを最小化できます。また、VRT の基盤としても活用できる点も評価しました。

テスト戦略

• 単体テスト: Vitest

  • 小さなコンポーネントや関数の動作検証
  • 選定理由: Jest 互換でありながら、Vite の高速ビルド基盤を活かした実行速度が魅力でした。設定の簡易さと、ESM 対応の柔軟性も評価ポイントです。

• E2E テスト: Playwright

  • 実際のユーザー操作を検証
  • 選定理由: マルチブラウザ対応、自動待機機能、強力なデバッグ機能などが決め手でした。特にトレースビューワーによる失敗の分析がしやすい点が、チーム全体の効率を高めています。

• VRT: storycap-testrun × reg-suit

  • UI の視覚的変更を自動検出
  • 選定理由: Storybook との連携が簡単で、低コストで導入できる点を評価しました。有料サービスではなく OSS で構成できる点も、コスト面で優位でした。

データ処理

• API Schema 生成: Orval

  • OpenAPI からの型・クライアント自動生成
  • 選定理由: OpenAPI スキーマから TypeScript の型定義と API クライアントを自動生成できる点が魅力です。バックエンドとの型連携が確実になり、開発効率と安全性が向上します。（Swaggerの記載がない部分はどんどん追加していってます！）

モニタリング

• エラー監視: DataDog
  • ソースマップ設定で詳細なエラー情報取得
  • RUM は導入しない
  • 選定理由: リアルタイムでのエラー検知と詳細な情報取得が容易な点が決め手でした。特にソースマップ連携により、本番環境でも正確なエラー位置の特定が可能になります。

状態管理

• 標準の React フックで十分な場合が多い
• 必要に応じて後から追加検討

まとめ：迷宮を抜けて見えた光景

膨大な選択肢の海から、私たちが慎重に選んだこのエコシステム。それは単なるツールの寄せ集めではなく、互いに補完し合い、強化し合う有機的な仕組みです。

Next.js の柔軟なレンダリング戦略、Vite の爆速ビルド性能、CSS Modules のスコープ管理、Storybook のコンポーネント管理...これらが互いに連携することで、私たちの開発体験は現状劇的に向上しました。

次回は、新アーキテクチャについて解説を行おうと思っています！

質問やフィードバックがありましたら、コメントでお気軽にどうぞ。みなさんのフロントエンド開発における迷宮攻略のヒントになれば幸いです。