自社フレームワーク（PHP＋Smarty）で稼働していた定期購入型のD2C ECを、Laravelのバックエンド・管理画面とNext.jsの公式サイトへ段階的に刷新しています。旧フロントと新バックエンドは同一のMySQLを共有し、マイグレーションはLaravel側に一本化しました。旧側にはBigQueryへのETL、非同期ワーカー、E2Eテストを後付けで整備し、新フロントにはテスト・エラー監視・カバレッジ計測などの品質ゲートを初期から導入しています。
- 新旧で同一DBを共有し、マイグレーション権限を新側に一本化
- 旧フロントと新バックエンドが同じデータベースを参照しつつ、スキーマ変更はLaravel側だけが行う規約にすることで、二重管理による不整合を防いでいます。
- レガシー側に後付けのE2EとETL
- 旧システムにもPlaywrightのE2EテストとBigQueryへのETLを後付けし、刷新中も購入導線の動作確認とデータ分析を継続できるようにしました。
- 新フロントは品質ゲートを初期導入
- commitlint、ユニット・E2Eテスト、Storybook、エラー監視、カバレッジ計測を最初から組み込み、機能追加が品質を下げない体制にしています。
- 影響を切り分けやすい領域から着手
- 自社フレームワークのECを一斉に置き換えるのではなく、バックエンドと管理画面、公式サイトから順に新構成へ移す段階的な進め方にしました。旧フロントを稼働させたまま新側を積み上げる形にしています。
- 分析データをBigQueryへ集約
- 旧システム側にもBigQueryへのETLを用意し、刷新の前後で同じ基盤に売上・行動データが集まるようにしました。移行の途中でも指標を同じ場所から参照できます。
この種のシステムで検討する論点（想定例）
以下は同種の案件で一般的に検討する内容の整理であり、上記事例の詳細を示すものではありません。
想定例: ECの刷新で「止められない」部分を守る
稼働中のECを刷新する場合、注文・決済・在庫のような売上に直結する機能は、移行期間中も一切止められません。全面的に作り直して一斉に切り替えるのではなく、旧システムを動かしたまま、管理画面や公式サイトのように影響を切り分けやすい部分から新側へ移す順序が安全です。新旧で同じデータベースを使うなら、スキーマを変更できるのは片側だけに限定し、旧側の画面が壊れないことをE2Eテストで継続的に確認する体制が前提になります。
想定例: 旧システムに後からテストを足す意味
刷新が決まった旧システムに投資するのは無駄に思えますが、移行期間中は旧システムも変更を受け続けます。主要な購入導線をE2Eテストで守っておけば、新側の変更が旧側を壊していないかを毎回自動で確認でき、移行の各段階を安心して進められます。同様に、旧システムのデータを分析基盤へ流すETLを先に整えておくと、刷新の前後で売上や行動の指標を同じ基準で比較でき、移行の効果を客観的に判断できます。
関連するサービス
関連する業種
関連する開発ガイド
- 他社が作ったシステムの引き継ぎ・保守を依頼するときのチェックリスト前の開発会社が作ったシステムの保守を別の会社に引き継ぐときの手順を、資料・アカウント・ソースコード・環境の棚卸しから調査、リスク整理、保守範囲の合意、移行まで、確認項目の表とともに解説します。
- ECサイトの決済導入で知っておきたいことECサイトにオンライン決済を導入するときの基礎知識として、決済代行会社の役割、決済手段の種類、審査、カード情報非保持、API連携、テスト環境での確認、返金や不正利用への運用までを整理します。
- 検収（受け入れテスト）で確認すべきことWebシステムの検収で発注側が確認すべきことを、検収条件の確認、テスト項目の作成、ステージングでの実施、不具合の記録と切り分け、検収書の作成の手順で解説し、契約不適合責任との関係も整理します。
他の開発事例
監修: Unlogical Systems合同会社（杉並区・西荻窪）公開