プロジェクトでの変化
-
リプレイス対象ECサイト + 管理サイト
-
進行管理計画通りに段階リリース
-
運用切替業務停止を最小化
課題
稼働中のECサイトと管理サイトを同時にリプレイスするため、業務側・運用側それぞれの都合に合わせて切替タイミングを調整する必要があった。フロントとAPI双方で構成が変わるため、影響範囲の把握も重要だった。さらに小売の繁忙期は決まっており、その時期の業務停止は許容されない。リプレイス進行と業務カレンダーの両方を見ながら、段階リリースの順序を組む必要があった。フロントとAPI双方で設計が変わるため、影響範囲を見える化しないと「どこで何が壊れるか分からない」状態に陥りやすい。
アプローチ
- 01 現行サイトの機能を画面・API単位で棚卸し
- 02 React + Redux でフロント、Lumen でAPI層を再設計
- 03 Dockerで開発・ステージング・本番の環境を統一
- 04 業務側と切替計画を握り、段階リリースで影響を局所化
- 05 繁忙期を避けたリリースカレンダーを業務側と合意し、無理のない進行管理
- 06 切替後の運用引き継ぎを意識し、運用ドキュメントとモニタリング項目を設計と並行整備
成功要因
- 画面・API単位の棚卸し
- 稼働中システムを画面・API単位で棚卸しし、リプレイスの影響範囲を見える化した。
- 段階リリース運用
- 現行と並走しながら段階リリースし、業務停止を最小化する切替計画を業務側と握って進めた。
- フロント・APIの責務分離
- React + Reduxのフロントと Lumen のAPIを分離設計し、双方の変更が互いに引き摺らない構造を取った。
- 環境統一による検証速度
- Docker で開発・ステージング・本番の環境を揃え、リプレイス中の検証回数を担保した。
ソリューション
React + Redux のフロントと Lumen ベースのAPIを Docker 上で構築し、現行システムと並走させながら段階的に切り替え。PMとして関係部門との調整を担い、業務影響を抑えながらリプレイスを進めた。業務カレンダーに合わせた段階リリースで業務停止を最小化し、繁忙期前にコア機能の移行を完了。フロント・API双方の責務分離により、リプレイス後の機能追加コストも下がった。