はじめに
こんにちは、Gakken Leap のフロントエンドエンジニアの日下です。
近年、Web アプリケーションの開発手法は多様化し、フロントエンド・バックエンド分離型の SPA（Single Page Application）が主流になりつつあります。一方で、Rails 7 から Hotwire が正式に採用され、従来のモノリシックなアプローチに新たな選択肢が加わりました。
今回はとあるプロジェクトで直面した、「SPA で新規に作るか、Hotwire でモノリシックに作るか」という技術選択について、比較検討した内容を共有したいと思います。
背景
現在、既存の Rails で実装されている toB 管理画面の機能拡充が必要となっています。新機能の追加にあたり、いくつかの選択肢がありました：
- 新規の SPA を作り、フロントエンドとバックエンドを分離する
- Rails 7 の Hotwire を活用してモダンな UX を実現しつつモノリシックに構築する
それぞれのアプローチにはメリット・デメリットがあるため、要件に照らし合わせて慎重に検討する必要がありました。
検討対象の技術選択肢
SPA アプローチ（フロントエンドとバックエンドの分離）
SPA アプローチでは、フロントエンド（React/Vue.js 等）とバックエンド（Rails API）を完全に分離して開発します。
特徴:
- フロントエンドとバックエンドが独立したコードベース
- API を介したデータのやり取り
- クライアントサイドでのルーティングとレンダリング
- JSON ベースの通信
Hotwire アプローチ（モノリシック）
Hotwire は、Rails 7 から正式に採用された技術スタックで、Turbo と Stimulus を組み合わせたアプローチです。
特徴:
- サーバーサイドでの HTML レンダリング
- Turbo による DOM 部分更新
- Stimulus によるクライアントサイドの動作拡張
- 単一の Rails アプリケーション内での開発
比較検討
実際の選定作業では、以下の観点から比較検討を行いました。
1. 提供したい機能の実現性
SPA アプローチ（機能実現性）
- 複雑な UI/UX: ✅ 高度なインタラクションやリアルタイム更新に強い
- レスポンス: ✅ ページ遷移が高速で、初期ロード後はサーバーと JSON のみやり取り
- カスタマイズ性: ✅ UI コンポーネントの自由度が高い
- オフライン対応: ✅ Service Worker との組み合わせで実現しやすい
Hotwire アプローチ（機能実現性）
- 複雑な UI/UX: ⚠️ 中〜低程度の複雑さは対応可能、非常に複雑なものは実装難度が上がる
- レスポンス: ✅ Turbo による部分更新で従来の Rails より高速
- カスタマイズ性: ⚠️ HTML ベースで一定の制約あり、ただし Stimulus で拡張可能
- サーバーサイドレンダリング: ✅ SEO や初期表示が重要な場合に有利
当プロジェクトの管理画面の機能としては、非常に複雑なインタラクションは限定的であり、Hotwire でも十分対応可能と判断しました。また、管理画面のため、SEO やオフライン対応の優先度は低いという点も考慮しました。
2. 開発完了までのリードタイム
SPA アプローチ（リードタイム）
- 学習コスト: ⚠️ フロントエンドフレームワーク、状態管理、ビルドツール、API のセキュリティなど多くの技術スタックを理解する必要がある
- 開発工数: ⚠️ フロントエンド/バックエンド両方の開発+API インターフェース設計が必要
- テスト工数: ⚠️ フロントエンド/バックエンドでの複数レイヤーのテストが必要
- 既存資産の活用: ❌ 既存の Rails ビュー、ロジックは再実装が必要
Hotwire アプローチ（リードタイム）
- 学習コスト: ⚠️ Rails 開発者であれば Hotwire の学習は比較的容易、FE は Rails の仕組みから学ぶ必要がある
- 開発工数: ✅ 単一のフレームワーク内で開発可能、API 設計不要
- テスト工数: ✅ 統合テストで機能を検証可能
- 既存資産の活用: ✅ 既存の Rails ビュー、ロジックを段階的に改善可能
リードタイム短縮の観点では、Hotwire アプローチが優位と判断しました。特に既存の Rails 資産を活用できる点は、時間的制約がある中で大きなメリットとなりました。
3. 運用保守のしやすさ
機能追加のしやすさ
- SPA アプローチ: ⚠️ フロントエンド/バックエンド両方の変更と連携が必要、小さな変更でも両方のデプロイが発生することも
- Hotwire アプローチ: ✅ 単一のコードベースで変更可能、機能追加の難易度が低い
ドキュメント・レポジトリ管理
- SPA アプローチ: ⚠️ フロントエンド/バックエンド/API 仕様など複数のドキュメントやレポジトリが必要
- Hotwire アプローチ: ✅ 単一のドキュメントやレポジトリで管理可能
パッケージ管理
- SPA アプローチ: ⚠️ npm/yarn と Ruby gem の両方を管理する必要あり
- Hotwire アプローチ: ✅ 主に Ruby gem のみ（一部 JS パッケージも使用するが比較的少ない）
運用保守の観点では、Hotwire アプローチの方がシンプルで管理しやすいと判断しました。特に長期的なメンテナンスを考えると、単一のコードベースで変更を加えられる点は大きなメリットです。
4. 安定性と将来性
- SPA アプローチ: ⚠️ フロントエンドフレームワークの進化が速く、数年後にはメジャーバージョンアップや移行が必要になる可能性が高い。React 18, Vue 3 など、大きなバージョンアップごとに破壊的変更がつきもの。
- Hotwire アプローチ: ✅ Rails は長期的に安定したエコシステムを持ち、バージョンアップも比較的穏やか。Hotwire は Rails 7 から標準装備となり、長期サポートが期待できる
長期運用を考えると、フロントエンド技術の移り変わりの速さを考慮すれば、より安定したエコシステムを持つ Hotwire アプローチが有利と判断しました。
5. 人材とチーム構成
- SPA アプローチ: ⚠️ フロントエンド/バックエンド両方の技術スタックを理解できる人材の確保が必要。また、チームが分かれると連携コストが発生する
- Hotwire アプローチ: ✅ Rails エンジニアがフロントエンド開発もカバーできるため、少人数チームでも効率的に開発可能
当社の現在のチーム構成と採用状況を考慮すると、Hotwire アプローチの方が人材リソースを効率的に活用できると判断しました。
6. 開発プロセスとコラボレーション
- SPA アプローチ: ✅ フロントエンド/バックエンドで完全に独立して開発が可能。並行開発のしやすさがある。
- Hotwire アプローチ: ⚠️ ビュー開発がコントローラー開発に依存しているため、FE がコントローラーも開発するか、密なコミュニケーションが必要
開発プロセスについては、SPA アプローチの方が分業化しやすいというメリットがありますが、当社ではエンジニアの多能工化を推進していることと、チームのコミュニケーションが密であることから、Hotwire アプローチの制約は大きな障壁にはならないと判断しました。
選定結果と理由
総合的に検討した結果、Hotwire アプローチを採用することに決定しました。主な理由は以下の通りです：
- 機能要件の充足: 管理画面程度の複雑さであれば、Hotwire で十分対応可能
- 開発リードタイムの短縮: 単一のフレームワーク内での開発により、開発効率が向上
- 運用保守の容易さ: シンプルな構成で長期運用がしやすい
- 学習コストの最適化: Rails 単一のエコシステムで学習コストを抑制可能
- 既存資産の活用: 既存の Rails コードベースを最大限活用できる
Hotwire を採用する場合の課題として、ビュー開発がコントローラー開発に依存している点が挙げられますが、チームの多能工化を推進している当社の方針とも合致し、大きな障壁にはならないと考えています。
まとめ
今回の技術選択では、SPA と Hotwire という 2 つのアプローチを詳細に比較検討しました。管理画面のような業務系アプリケーションでは、必ずしも最新のフロントエンド技術を使う必要はなく、開発効率や保守性を重視した選択が重要です。
以下のような条件では Hotwire が有力な選択肢となります：
- 管理画面や内部システムなど中〜低程度の複雑さの UI を要する場合
- 開発スピードと保守性を重視するプロジェクト
- Rails 開発者が主体のチーム構成
- シンプルな構成で長期運用したいケース
- サーバーサイドテンプレートで十分な機能性がある場合
一方、以下のような場合には SPA アプローチがより適している可能性があります：
- 非常に複雑で動的な UI やインタラクションが必要
- オフライン機能が重要
- 将来的にモバイルアプリ等と同じ API を共有したい
- フロントエンド専門のチームがある
- クライアントサイドでの処理が多い
技術選択はプロジェクトの特性、チーム構成、ビジネス要件などを総合的に考慮したトレードオフの判断です。今回のケースでは、短期的な開発効率と長期的な保守性を重視した結果、Hotwire アプローチが最適と判断しました。
しかし、これはあくまでも今回のプロジェクトに対する判断であり、他のプロジェクトや条件では異なる選択が正解となることもあるでしょう。大切なのは、要件とチームの状況を見極めて、最適な技術選択を行うことです。
エンジニア募集中
Gakken LEAP では教育をアップデートしていきたいエンジニアを絶賛大募集しています！！
ぜひお気軽にカジュアル面談へお越しください！！