定期的に商品を届けるD2C型のECサイトは、独自に作られたPHPとSmartyのフレームワークで長く稼働していました。この仕組みを、Laravelで構築したバックエンドと管理画面、Next.jsで構築した公式サイトへ段階的に置き換えています。移行期間中は既存のフロントと新しいバックエンドが同じMySQLを参照し、テーブル定義の変更権限をLaravel側に限定しました。旧システムにも分析基盤（BigQuery）へのデータ連携、非同期ワーカー、購入導線のE2Eテストを後から追加し、新しいフロントにはテスト、エラー監視、カバレッジ計測といった品質の仕組みを最初から組み込んでいます。
- 売上に直結する機能を止めない順序
- 注文や決済といった止められない機能は旧システムで動かしたまま、管理画面と公式サイトのように切り分けやすい部分から新基盤へ移しています。
- データベースの所有者を一つに
- 新旧が同じデータベースを使う期間でも、構造を変更できるのは新側だけと決め、二重管理から生じる不整合を防いでいます。
- 旧システムへの後付け投資
- 刷新が決まった旧システムにもE2Eテストと分析基盤への連携を追加し、移行中も購入導線の安全性と指標の継続性を確保しました。
- 新フロントは品質の仕組みを初期から
- コミット規約、ユニットとE2Eのテスト、コンポーネントカタログ、エラー監視、カバレッジ計測を最初から備え、追加開発を重ねても品質が落ちない土台を作りました。
- 旧フロントと新バックエンドの同居
- 移行期間中は独自フレームワーク製の既存フロントと、新しく作ったLaravelのバックエンドが同じMySQLを参照します。両者が併存する前提で、参照と更新の責務を分けた構成にしました。
- 非同期ワーカーを旧側にも追加
- 刷新の対象である旧システムにも非同期ワーカーを後付けし、時間のかかる処理を画面の応答から切り離しました。移行が完了するまでの期間も運用を成立させるための投資です。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
移行の前後で指標を比較できる状態を先に作る
刷新の効果を後から評価するには、移行前の売上や顧客行動の指標を同じ基準で測れている必要があります。旧環境の注文や行動のデータを分析用の基盤へ取り込む経路を刷新に先立って整え、移行の各段階で数字の変化を追えるようにしておくと、切り替えの判断を感覚ではなくデータで下せます。分析基盤は刷新後も残る資産であり、マーケティングや商品開発の意思決定にも使えるため、早い段階での投資が二重に効きます。
決済まわりの移行は最も慎重に
決済の処理は、途中での離脱や二重送信、決済事業者側の遅延といった失敗の型が多く、検証環境で再現しにくい領域です。決済サービスが提供する検証用の環境で、購入完了までの流れを自動テストとして固定し、本番へ切り替える前後で注文の記録に食い違いがないかを照合する段取りを用意します。定期購入契約や保有ポイントといった過去から引き継ぐ仕組みは、旧環境で作られた契約が新環境でも正しく動くことを、実際に近い規模のデータで確かめておく必要があります。
関連するサービス
関連するインサイト
- レガシーコードのモダナイズ — 全面リプレイスか段階移行か古くなったシステムを作り直すべきか、少しずつ置き換えるべきか。全面リプレイスと段階移行の比較、ストラングラーパターン、データ移行、テストのないコードへの向き合い方を経営者向けに整理します。
- 技術的負債との付き合い方 — 返済の優先順位を決める技術的負債はゼロにするものではなく、管理するものです。意図的な負債と無自覚の負債の違い、負債の可視化、事業インパクトと変更頻度による優先順位の付け方、開発計画への組み込み方を経営者向けに整理します。
- プロダクトのKPI設計とダッシュボード — 見るべき指標を絞る北極星指標を起点に先行指標・遅行指標へ分解し、PMF前後のフェーズに応じて見るKPIを絞る考え方と、意思決定に使えるダッシュボードの設計、計測の信頼性、やりがちな失敗を整理します。
他の開発事例
監修: フィリット・コンサルティング株式会社公開