MAPRISE は現在のフロントエンドを将来的により保守性の高いアーキテクチャへ段階移行する計画です。「リライト」ではなく「段階置換」を選んだ理由、そしてどのような順序で進めるかの判断を、設計思想の共有として公開します。
MAPRISE は現在、軽量なフロントエンド構成で本番運用しています。シンプルな構造で本番に到達し、機能を継続的に追加してきましたが、サービスの成長に合わせて、将来的により保守性の高い次世代アーキテクチャへ段階移行する計画です。
この記事では、なぜ「リライト」ではなく「段階置換」を選んだのか、移行をどのような順序で進めるかの設計思想を、エンジニア視点で共有します。次に参画してくださる方への設計意図の予告でもあります。
なお、ベースとなるフレームワーク自体(Next.js)は特に秘匿すべき情報ではありませんが、その上に組む周辺ライブラリの具体的な組み合わせや実装詳細は本機能の競争力に関わる部分があるため、現時点では概念的な選定方針のみ記載します。
段階置換を選ぶ理由
段階置換は、古いシステムを動かし続けながら、周辺から新しいシステムに置き換えていく方法です。一括リライトと比較した時の最大の利点:
- 本番サービスを止めない: 1 機能ずつ置換するため、いつでも片方に切り戻せる
- 小さく頻繁にリリースできる: 数ヶ月の big-bang リリースより、1〜2 週の小リリースの方が品質が高い
- 学習を反映できる: 移行中に得られた知見を、次の置換に即反映可能
- 創業初期のリソース制約に適合: 集中的なフルリライト期間を確保しづらい段階に向く
MAPRISE は すでに既存コードベース内で「自己完結モジュール」のパターン を確立しています。新規追加した機能群はそれぞれ独立性が高く、他の機能に影響を与える共有の状態(グローバル状態)への依存が最小化されています。これが段階移行の地盤になります。
技術選定の方針(概念レベル)
周辺ライブラリの具体的な組み合わせは伏せますが、以下の方針で選定を進めています。
| 観点 | 方針 |
|---|---|
| フロントエンド | 型安全な静的解析が前提のモダンフレームワーク |
| 地図ライブラリ | 現行と互換性があり、コミュニティでの実績が豊富なもの |
| 状態管理 | UI 状態とサーバ状態を責務分離した二層構造 |
| UI コンポーネント | アクセシビリティ準拠の primitive + 軽量な拡張パターン |
| テスト | 単体・E2E・視覚回帰の三層で網羅 |
| 開発環境 | モノレポでパッケージを分離管理 |
商用ライセンスを必要としない / 直近の主要バージョンが業界標準として浸透している / 創業期の小規模チームでも保守可能、を共通の選定基準としています。
移行の段階構成
移行戦略の核心は「どの順序で進めるか」です。MAPRISE では以下の段階で計画しています。
段階 1: 基盤整備
- モノレポ構成のセットアップ
- 既存機能が壊れていないかを機能単位で確認するテスト(boundary test)の追加
- 型システムの整備
段階 2: 周辺 UI からの置換
ランディング側は既に新アーキテクチャで稼働中です。アプリ側についても周辺 UI から段階的に置換していき、地図コアは現行構成で温存します。リスクの少ない箇所から始めるのが鉄則です。
段階 3: 地図コアの分離
分割画面同期コアの再実装、レイヤーカタログの構造化、地図ライブラリ統合。最大のリスク箇所であり、ここで段階 1 で整備したテストが威力を発揮します。
段階 4: AI チャット置換
AI チャット UI の再構造化、ストリーミング応答処理、セッション復元・履歴ナビゲーション。
段階 5: 旧コード削除
旧構成のファイル群を削除し、新構成で完全置換。型システムの strict 化と最終ドキュメント更新。
期待効果
| 観点 | 現状 | 移行後 |
|---|---|---|
| 初期 HTML サイズ | 大きめ | 大幅に削減 |
| 機能追加リード時間 | 1 機能 1-2 週 | 1 機能 数日 |
| 新メンバー学習コスト | 暗黙知が多い | 型と構造で自然に理解 |
| テスト網羅率 | 限定的 | 単体 + E2E 網羅 |
| 開発者体験 | 補完が限定的 | 静的解析で支援 |
既知のリスクと緩和策
- メモリリーク: 地図 canvas を再マウントする際の管理を厳密化
- 同期無限ループ: 分割画面の状態同期で参照等価性を保証する仕組みを採用
- 配布ファイル(bundle)の肥大化: パッケージ追加時のサイズ解析を必須化
- SEO 退行: 既に実証済のパターンを流用
まとめ
MAPRISE のアーキテクチャ移行は「リスクを最小化しながら、確実に技術的負債を解消する」段階置換戦略です。小規模チーム + AI 活用での実行可能性、創業者持分の保護、新メンバー受け入れの容易さを全部両立させる設計だと考えています。
それまでは現行構成で PMF 検証と顧客獲得を続けます。
エンジニア参画の相談、設計判断への議論、改善提案は info@maprise.jp までお気軽にどうぞ。
並行して、本日 (5/24) 同時公開の event 記事「よかとこビジコン応募」 もご覧ください。
タグ: #アーキテクチャ #設計判断 #MAPRISE
他言語のシェアテキスト (例外運用向け)
通常は上の Quick share をご利用ください (X 系は日本語、LinkedIn は英語に固定)。下の 4 ペインは「英語記事を X で日本語紹介したい」「日本語記事の LinkedIn 投稿を日本語で出したい」等の例外運用に使えます。各テキストはコピー編集してから投稿することも、そのまま投稿画面を開くこともできます。
📝 次世代アーキテクチャに向けた段階移行 — リライトを選ばなかった理由 MAPRISE は現在のフロントエンドを将来的により保守性の高いアーキテクチャへ段階移行する計画です。「リライト」ではなく「段階置換」を選んだ理由、そしてどのような順序で進めるかの判断を、設計思想の共有として公開します。 https://maprise.jp/ja/blog/phase7-nextjs15-design/ #アーキテクチャ #設計判断
🆕 新しいブログ記事を公開しました。 《次世代アーキテクチャに向けた段階移行 — リライトを選ばなかった理由》 MAPRISE は現在のフロントエンドを将来的により保守性の高いアーキテクチャへ段階移行する計画です。「リライト」ではなく「段階置換」を選んだ理由、そしてどのような順序で進めるかの判断を、設計思想の共有として公開します。 👉 詳しくはこちら: https://maprise.jp/ja/blog/phase7-nextjs15-design/ #MAPRISE
📝 Phased Migration to a Next-Generation Architecture — Why We're Not Rewriting MAPRISE is planning a phased migration of its front end toward a more maintainable next-generation architecture. We share the design philosophy behind… https://maprise.jp/en/blog/phase7-nextjs15-design/ #architecture #design
🆕 New on the MAPRISE blog. 《Phased Migration to a Next-Generation Architecture — Why We're Not Rewriting》 MAPRISE is planning a phased migration of its front end toward a more maintainable next-generation architecture. We share the design philosophy behind picking 'phased replacement' over 'rewrite,' and the order in which we'll proceed. 👉 Read the full post: https://maprise.jp/en/blog/phase7-nextjs15-design/ #architecture #design #MAPRISE