EC刷新は、現状の棚卸し、移行要件の定義、RFP作成とベンダー選定の順に進めると、売上を守りながら刷新できます。
アセスメントで現状を把握し、移行要件を決め、RFPで各社に同じ条件を示すと、提案を比べやすくなります。全体像はEC刷新の完全ガイドもご覧ください。
▼全体ガイドの記事
・EC刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
アセスメント：EC刷新前の現状分析と資産棚卸し
アセスメントでは、最初に現行ECサイトの実態を把握します。現状（AS-IS）が見えていなければ、刷新後の要件は定義できません。
ECサイトは決済代行や配送、在庫など多くの外部システムと連携します。そのため、構成を漏れなく見える形にすることが、要件定義の質を左右します。
要件定義・業務棚卸しだけを切り出す場合、費用相場は200万円から500万円程度が目安です。この投資は、刷新全体のコストとリスクを抑える役割を果たします。
データ量・外部連携・ピークトラフィックの棚卸し
現行ECに長年蓄積されてきた貴重なデータ資産は、アセスメントの最初に棚卸しします。
- データ資産：商品・会員データ、受注履歴、ポイント残高、クーポン、定期購入の契約状態、レビュー
- 外部連携：配送・WMS・ERP、メール配信・MA、レビュー・チャット
- ピーク時の状況：最大同時アクセス数、秒間リクエスト数、想定伸び率
決済代行も外部連携の対象です。そのため、クレジットカード・コンビニ決済・後払い・ID決済など、利用中の手段を漏れなく確認します。
データは項目や件数、品質を整理し、他システムとの参照関係も洗い出します。たとえば、会員数が数十万件規模か、受注履歴を何年分移すかが見えないと、工数や期間を見積もれません。
連携先ごとに、API・バッチ・ファイル授受・Webhookのどの方式か、どのくらいの頻度かを洗い出します。そのうえで、各連携を維持・再構築・廃止のどれに当たるかを判断できる状態にします。
ECならではの論点が、ピークトラフィックの把握です。特に、大型セールやテレビ・SNSでの紹介時には、アクセスが集中します。過去の実績からピークを把握しておけば、刷新後の性能要件を現実的な数値で定められます。
富士通の「ソフトウェア地図」のように、アプリケーションの複雑度や依存関係を見える形にするツールも、ブラックボックス化した構成の把握に役立ちます。
現状KPI（CVR・客単価・離脱率）の把握
システム面と同じく、事業面の現状KPIも刷新前に計測し、記録しておきます。改善指標を定めるときの基準になるからです。
- 購買指標：コンバージョン率（CVR）、客単価、カゴ落ち率
- サイト利用指標：直帰率、ページ表示速度、回遊率、リピート率
カゴ落ち率が高い場合は、決済の導線とカート機能が要件の中心になります。また、表示速度が遅く離脱率が高い場合は、性能要件とフロントエンド刷新が優先課題になります。
数値があれば、「古いから新しくする」という説明にとどまらず、どの指標をどこまで改善する投資なのかを経営層に伝えられます。刷新後も同じ指標を計測し、効果を検証します。
ここまでの結果は、現行構成図やデータ一覧を中心とした資料にまとめます。解決したい課題は、課題マップとして整理します。課題のうち、事業上もっとも深刻なものを経営層と共有しておくと、後続の要件定義やRFPで投資の優先順位を決めやすくなります。
アセスメントは、現状を把握するだけの工程ではなく、刷新の方向性と投資判断の土台を築く戦略的な工程です。
EC刷新の要件定義：カート移行・決済再連携・物流連携・SEO/URL移行・データ移行
現状を把握したら、刷新後のあるべき姿（TO-BE）を要件として定義します。その際、一般的なEC機能と同じ重みで、移行要件も扱います。
要件定義では、カートと決済、物流と会員のほか、SEO/URLやデータ移行も扱います。EC刷新では、どれも必ず論点になります。
カート移行と決済再連携（トークン移行・PCI DSS）
購入機能と継続課金を維持するため、発注側と開発会社は、カートの機能差、決済情報の移行可否、セキュリティと動作検証の要件を決めておきます。
- カート機能：商品・在庫・受注・会員の移し方と追加開発の要否
- 決済情報：トークンの移行可否とカード再登録の要否
- 決済方式：非保持化を前提とした画面連携方式
- 動作検証：全決済手段、返金、キャンセルのテスト
パッケージ型からクラウド型SaaSへ、またはオープンソースから商用プラットフォームへ移る場合、再現できる機能が変わります。このため、独自機能やカスタマイズのひとつひとつについて、標準機能で実現できるかを確認します。
EC刷新でもっとも神経を使うのが、決済の再連携です。カード情報はトークン（カード番号を直接保持しない代替文字列）として保管されます。新環境への引き継ぎ可否は、決済代行会社の仕様次第です。
引き継げない場合は、会員にカードの再登録を依頼することになります。継続課金中の顧客には離脱や解約の恐れがあるため、早い段階で移行可否を確認します。
PCI DSS（クレジットカード業界のセキュリティ基準）への準拠も必要です。さらに、リダイレクト型、JavaScript型、トークン型のなかから、決済画面の方式を決めます。テスト環境では、全決済手段に加えて返金とキャンセル処理も検証できるよう、要件に明記します。
物流・在庫連携と会員・パスワード移行
出荷業務と会員のログインを保つため、物流・在庫の連携範囲と、会員情報・パスワードの移行方法を決めておきます。
- 物流連携：倉庫、WMS、配送会社へ受注データを連携
- 在庫管理：複数倉庫や実店舗の在庫を一つにまとめ、リアルタイムで連携
- 会員データ：ID、氏名、住所、購入履歴、ポイント、お気に入り
- ログイン継続：パスワード移行、再設定、告知とサポート
出荷指示や送り状発行、在庫引き当て、入荷反映まで、新カートでも連携を途切れさせません。連携が乱れると出荷遅延や欠品、過剰販売を招きます。そのため、現行の仕様を正確に引き継ぎます。
会員の移行も、慎重に設計する必要があります。パスワードは通常ハッシュ化して保存されるため、現行と新基盤でハッシュ方式が異なると、そのまま移行できない場合があります。
その場合は、初回ログイン時に再設定を促すなど、会員の負担を抑える導線を用意します。告知とサポート体制も設計します。
会員がログインできなければ購入の機会を失います。したがって、移行方式と移行後の対応を、あわせて要件に盛り込みます。
SEO/URL移行（301リダイレクト設計・構造化データ）
検索流入と売上を守るため、URL転送と構造化データを中心に、メタ情報や内部リンクの引き継ぎも要件にします。
- URL転送：旧URLから新URLへの301リダイレクト（恒久転送）を漏れなく設計
- 検索情報：構造化データ、サイトマップXML、メタタグ、canonical
- サイト構造：内部リンクのつながりを維持
プラットフォームを変えると、URLの構造が変わることがあります。旧URLを放置すると検索評価が引き継がれず、リリース後に検索流入や売上が落ちる場合があります。まず、商品、カテゴリ、特集ページなど、検索流入の多いページから優先して、対応表にまとめます。
構造化データは、schema.orgで商品情報や価格、在庫、レビューなどを示します。検索結果の見え方に関わるため、刷新後も同等以上のマークアップを維持します。
SEO移行は、リリース後に取り返しがつきにくい領域です。そのため、専門的な観点を要件定義に加え、リダイレクトの漏れがない計画を立てます。
データ移行要件と並行稼働の方針
切り替えと並行稼働は、EC刷新の重要な要件です。移行中も販売を続ける方針と、移行するデータの範囲を決めます。
- 移行対象：商品・会員・受注・ポイントの範囲と精度
- データ整備：移行前のデータ品質確保
- 段階移行：機能ごとの移行順序とマイルストーン
- 切り替え条件：許容ダウンタイムと切り戻しの基準
古い退会会員や使われていないキャンペーン情報まで移すと、コストと品質リスクが高まります。そのため、移すデータと移さないデータを線引きします。また、データマッピング（旧項目と新項目の対応づけ）とクレンジング計画は、要件定義の段階で具体化します。
ECは停止すると売上に響きます。一度に入れ替えるビッグバンアプローチはリスクが高いため、新旧を並行稼働させて機能単位で移すストラングラーパターンが推奨されます。
移行要件はRFPにも記載して、ベンダーの移行設計力を評価します。手順や条件を事前に決めておくと、移行時の混乱と売上機会の損失を防げます。
RFP作成：ECベンダーに提示すべき項目とカットオーバー要件
要件はRFP（提案依頼書）にまとめ、ECベンダーに提示します。共通の仕様書として各社に示すことで、同じ条件で提案と見積もりを得られます。
要件が曖昧だと、提案内容が各社でばらつき、比較が難しくなります。さらに、決済と物流、移行、SEOなどEC固有の論点も盛り込みます。
RFPに盛り込むべき項目（現行構成図・移行対象データ・移行後KPI）
EC刷新のRFPには、必須の項目を漏れなく記載します。現行環境とデータ規模、性能を、各社に同じ形で示します。目標と契約条件も、あわせて書き添えます。
- 現行環境：システム構成図と決済・物流・在庫・基幹の連携先
- 移行対象：商品・会員・受注・ポイントの一覧と件数
- 性能・成果：ピーク時の同時アクセス数と目標応答時間を数値で記載し、移行後KPIを示す
- EC固有要件：301リダイレクトと構造化データの引き継ぎ
- 進行・運用条件：体制、スケジュール、予算範囲、保守運用、提案形式
移行後のKPIには、CVRや客単価、ページ表示速度などの改善目標を示します。構築だけでなく成果を意識した提案を、ベンダーから引き出せます。RFPを丁寧に作り込むほど、各社の提案の質がそろい、比較と意思決定を進められます。
カットオーバー方式とダウンタイム許容の明記
RFPには、カットオーバー（本番切り替え）の方式と許容ダウンタイムを明記します。
- 停止時間：許容できるダウンタイムと完了方法
- 切り替え案：深夜の低アクセス帯や段階移行など、停止時間を抑える方法をベンダーに問う
- 事前準備：当日のリハーサルとデータ最終同期
- 障害対応：切り戻しの判断基準と手順、注文の引き継ぎ方式
ECは24時間365日稼働します。切り替えで長時間停止すると売上を失うため、許容範囲内で完了する方式を、ベンダーに提案してもらいます。
基幹システムの切り替え障害で、商品の出荷が全面的に止まった失敗事例もあります。特に、計画が不十分だと深刻な業務停止を招きます。
注文の二重処理や取りこぼしを防ぐ方法も、具体的に問います。そのうえで、リスク対策の提案から、移行設計力の高いパートナーを見極めます。
ベンダー選定の評価観点（EC固有）
RFPへの提案が集まったら、価格や見栄えだけで決めず、客観的な基準で選びます。一般的な刷新の基準に、EC固有の観点を加え、最後までやり遂げられるパートナーを見極めます。
EC実績・段階移行設計力・品質認証のチェックポイント
移行の実行力と運用の継続性を見極めるため、実績と切り替え設計、保守、品質・セキュリティを確認します。
- EC実績：同業界・同規模の刷新、カート移行、決済再連携
- 移行設計：段階移行、停止時間の見積もり、短縮策、切り戻し計画
- 安定稼働の保守：24時間365日の体制と障害への即応
- 品質・セキュリティ：ISO9001、ISO27001などの認証
- 連携・SEO：決済代行や物流との実績、SEO移行の知見
ECは深夜や休日も稼働するため、トラブルへの備えが事業継続に直結します。また、決済や個人情報を扱うので、セキュリティの担保も欠かせません。
段階移行では、ビッグバンを避けたストラングラーパターンを設計できるかを確認します。
評価の客観化と発注後の体制づくり
提案の評価は、担当者の主観に任せず、客観的に行います。
- 評価方法：観点ごとの配点、評価シート、複数名での採点
- 評価項目：提案の具体性とコミュニケーションの質
- 進行体制：定例会議、課題管理、意思決定の責任者
- 業務部門の参加：商品登録、受注、在庫、サポート担当者が継続参画し、仕様確認やテストに主体的に参加
価格の安さだけで選ぶと、移行品質や保守体制で後悔する場合があります。一方で、総合評価なら、社内合意や稟議でも判断の根拠を説明しやすくなります。
ベンダーへの丸投げは、失敗の典型的な原因です。そのため、発注側が主導する形で進めます。
要件定義とRFPで固めた内容は、発注後も発注側が責任を持って確認します。上流工程への投資を成果につなげるためです。
まとめ
EC刷新は、アセスメント、要件定義、RFP作成、ベンダー選定の順に準備します。アセスメントでは、データ、外部連携、ピークトラフィックを棚卸しします。
CVRや客単価、離脱率などのKPIも把握します。刷新後に同じ指標を測り、効果を検証するためです。
要件定義では、カート移行と決済再連携を定めます。トークン移行やPCI DSSへの対応も含みます。さらに、物流連携、会員・パスワード移行、SEO/URL移行も扱い、301リダイレクトと構造化データを引き継ぎます。
データ移行と並行稼働も、機能要件と同じ重みで定めます。移行要件をしっかり固めることが、売上を守ることにつながります。
RFPには、現行構成と移行データ、性能を記載し、移行後KPIやSEO要件も示します。加えて、カットオーバー方式と許容ダウンタイムも明記します。
ベンダーは、EC実績や段階移行の設計力、停止時間の見積もりで評価します。24時間365日の保守体制やISO認証なども確認します。
要件定義・業務棚卸しだけを切り出す場合の費用相場は200万円から500万円程度です。上流工程が刷新の成否を左右するため、発注側が主体的に固めます。
アセスメントの段階から伴走できるパートナーへの相談も、候補に入れてみてください。
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。