プロジェクトでの変化
-
API応答時間PHP比で改善傾向
-
新機能の開発リードタイム短縮
-
リプレイス進捗18ヶ月で計画通り進行
課題
PHP製のモノリシックなSaaSは機能拡張のたびに既存箇所への影響範囲が読みにくく、新機能の見積もりが膨らみがちだった。リプレイス中も機能追加は止められず、新旧の併走運用が必須要件だった。
アプローチ
- 01 画面・APIをドメイン単位で切り、リプレイス順序を優先度付け
- 02 Go (GIN) によるAPI層の再設計と、React + TypeScript への画面移植
- 03 新旧APIをリバースプロキシで切り替える段階的カットオーバー
- 04 Docker / CIによるローカル〜本番までの環境統一
成功要因
- 並行稼働の徹底
- 旧PHP環境と新Go環境を機能単位で同居させ、リバースプロキシで段階的にトラフィックを移した。
- 型定義の新旧共有
- TypeScriptで定義した型を新旧フロントで共有し、移行中の退行を機械的に検出できる状態を保った。
- ドメイン単位での切り出し
- リプレイス順序を画面ではなくドメインで切り、機能拡張を止めずに新基盤へ寄せていった。
- 環境再現性の確保
- Docker / CIでローカル〜本番を同一構成にし、新基盤の検証コストが膨らまないようにした。
ソリューション
リプレイス対象を機能ドメインごとに切り出し、新基盤をGo + React で構築しつつ、既存PHP環境とAPIレベルで併走。フロント側はTypeScript化により共通の型定義を新旧で共有し、移行中の品質低下を抑えた。