EC刷新のアセスメント/要件定義/RFPについて

ECサイトの刷新は、カートシステムやECプラットフォームの移行、決済・物流連携の再構築、長年蓄積した会員データの引き継ぎといった、通常のシステム刷新以上に繊細で停止できない工程が連続します。ECサイトは止めれば即座に売上を失うため、刷新の成否は開発が始まる前の「アセスメント・要件定義・RFP（提案依頼書）」という上流工程の精度でほぼ決まります。現行カートの仕様が把握できていなかったり、移行すべきデータの全体像が見えていなかったりすると、移行段階で想定外の作業が次々に発生し、リリースが遅延したり、最悪の場合は売上に直結する障害を招きます。

本記事では、EC刷新に固有のアセスメント（現状分析）から要件定義、RFP作成・ベンダー選定までの流れを、カート移行・決済再連携・SEO/URL移行・データ移行といったEC特有の論点に絞って実践的に解説します。現状KPIの把握から、301リダイレクト設計、移行後KPIの設定、ECベンダーを客観的に評価するチェックポイントまでを整理しました。EC刷新の全体像を先に押さえたい方は、EC刷新の完全ガイドもあわせてご覧ください。発注前の準備を固めることが、見積もりの精度を高め、刷新の成功率を大きく引き上げる鍵となります。

▼全体ガイドの記事
・EC刷新の完全ガイド

アセスメント：EC刷新前の現状分析と資産棚卸し

EC刷新の最初のステップは、現行ECサイトの実態を正確に把握するアセスメントです。刷新の要件は「今の状態をどう変えるか」を起点に決まるため、現状（AS-IS）が見えていなければ要件は定義できません。とくにECサイトは、決済代行・配送・在庫・基幹・マーケティングといった多数の外部システムと連携しているため、現状の構成を漏れなく可視化することが要件定義の質を左右します。要件定義・業務棚卸しのみを切り出して実施する場合の費用相場は200万円から500万円程度が目安で、この投資を惜しまないことが結果的に刷新全体のコストとリスクを抑えることにつながります。

アセスメントでまず行うべきは、現行ECに蓄積されたデータ資産の棚卸しです。商品データ・会員データ・受注履歴・ポイント残高・クーポン・定期購入の契約状態・レビューなど、ECサイトには長年蓄積された貴重なデータが存在します。これらのデータ項目・件数・品質・他システムとの参照関係を整理し、移行の対象とボリュームを早期に把握することが重要です。会員数が数十万件規模なのか、受注履歴が何年分あるのかといった具体的な件数が見えていないと、移行の工数も期間も見積もれません。

次に、外部連携の一覧化が欠かせません。決済代行（クレジットカード・コンビニ決済・後払い・ID決済）、配送・物流システム、WMS（倉庫管理）、在庫・基幹システム（ERP）、メール配信・MA・レビューエンジン・チャットサポートなど、ECは想像以上に多くの外部サービスとつながっています。連携先ごとに連携方式（API・バッチ・ファイル授受・Webhook）と連携頻度を洗い出し、刷新後にどの連携を維持・再構築・廃止するかを判断できる状態にします。

さらにEC固有の論点として、ピークトラフィックの把握があります。大型セールやテレビ・SNSでの紹介、タイムセールの開始直後など、ECサイトはアクセスが瞬間的に集中する特性を持ちます。過去の最大同時アクセス数・ピーク時の秒間リクエスト数・想定の伸び率を現状データから把握しておくことで、刷新後の性能要件を現実的な数値で定義できます。アプリケーション資産の複雑度や依存関係を地図のように可視化する富士通の「ソフトウェア地図」のようなツールも、ブラックボックス化した現行システムの依存関係を解きほぐすうえで有効です。

EC刷新のアセスメントでシステム面と同じくらい重要なのが、事業面の現状KPIの把握です。コンバージョン率（CVR）・客単価・カゴ落ち率・直帰率・ページ表示速度・回遊率・リピート率といった指標を刷新前に正確に計測し、現状値として記録しておきます。これらの数値は、刷新で何を改善したいのかという目的を明確にし、後の要件定義における優先順位づけの根拠となります。

たとえば「カゴ落ち率が高い」という現状が見えていれば、決済導線の改善やカート機能の刷新が要件の中心になります。「表示速度が遅く離脱率が高い」のであれば、性能要件とフロントエンドの刷新が優先課題になります。現状KPIを定量的に把握しておくことで、刷新を「なんとなく古いから新しくする」のではなく、「どの数値をどこまで改善する投資か」として経営層に説明できるようになります。刷新後に同じ指標を計測して効果を検証するためにも、刷新前のベースラインを正確に残しておくことが不可欠です。

アセスメントの成果物としては、現行システムの構成図・データ一覧・外部連携一覧・ピークトラフィックの実績値・現状KPIをまとめた資料に加えて、刷新で解決したい課題を整理した課題マップをまとめておくとよいでしょう。この段階で「どの課題が事業上もっとも深刻か」を経営層と共有しておくことで、後続の要件定義やRFPで投資の優先順位を判断しやすくなります。アセスメントは単なる現状把握の作業ではなく、刷新の方向性と投資判断の土台を築く戦略的な工程です。

EC刷新の要件定義：カート移行・決済再連携・物流連携・SEO/URL移行・データ移行

アセスメントで現状を把握したら、次は刷新後の「あるべき姿（TO-BE）」を要件として定義します。EC刷新の要件定義では、商品・受注・会員といった一般的なEC機能の要件に加えて、EC固有の移行要件を機能要件と同等の重みで定義することが決定的に重要です。ここでは、カート移行・決済再連携・物流連携・会員移行・SEO/URL移行・データ移行という、EC刷新で必ず論点となる6つの観点を整理します。

カート移行の要件定義では、現行カート（ECプラットフォーム）から新カートへ、商品・在庫・受注・会員の各機能をどう移し替えるかを定義します。パッケージ型カートからクラウド型のSaaSへ、あるいはオープンソースから商用プラットフォームへといった移行先によって、再現できる機能と作り込みが必要な機能が変わります。現行で使っている独自機能やカスタマイズがある場合、新カートで標準機能として実現できるのか、追加開発が必要なのかを切り分けることが、見積もりの精度を左右します。

EC刷新でもっとも神経を使うのが決済の再連携です。クレジットカード決済では、定期購入やサブスクリプションの継続課金に使われるカード情報がトークン（カード番号を直接保持しない代替文字列）として決済代行会社に保管されています。プラットフォームを移行する際、このトークンを新環境へ引き継げるかどうかは決済代行会社の仕様次第であり、引き継げない場合は会員にカード再登録を依頼することになります。継続課金中の顧客に再登録を求めると離脱や解約を招くため、要件定義の早い段階で決済代行会社と移行可否を確認することが欠かせません。

あわせて、PCI DSS（クレジットカード業界のセキュリティ基準）への準拠も必須の要件です。カード情報を自社で保持しない非保持化の方式を前提に、決済画面の連携方式（リダイレクト型・JavaScript型・トークン型）をどう設計するかを定義します。決済はECの売上を直接受け止める最重要機能であるため、移行後にテスト環境で全決済手段の動作と返金・キャンセル処理まで検証できるよう、要件として明記しておくことが重要です。

物流・在庫連携の要件定義では、受注データを倉庫やWMS、配送会社のシステムへどう連携するかを定義します。出荷指示・送り状発行・在庫引き当て・入荷反映といった一連の連携が新カートでも途切れず動くことを保証する必要があります。複数倉庫や実店舗在庫を持つ場合は、在庫の一元管理とリアルタイム連携の方式も論点になります。物流連携が乱れると出荷遅延や欠品・過剰販売を招き、顧客の信頼を直接損なうため、現行の連携仕様を正確に引き継ぐことが要件の核となります。

会員移行も慎重な設計が求められる領域です。会員ID・氏名・住所・購入履歴・ポイント残高・お気に入りといったデータを新基盤へ移すと同時に、パスワードの扱いが課題になります。パスワードはハッシュ化して保存されているのが通常で、現行と新基盤でハッシュ方式が異なると、そのままでは移行できません。移行できない場合は、初回ログイン時にパスワード再設定を促す導線を用意するなど、会員に過度な負担をかけずログインできる方式を要件として定義します。会員がログインできなくなれば購入機会を直接失うため、移行方式とあわせて移行後の告知・サポート体制まで設計しておくことが大切です。

EC刷新でとくに見落とされがちで、かつ売上に直結するのがSEO/URL移行の要件です。プラットフォームを変えるとURLの構造が変わることが多く、旧URLのまま放置すると検索エンジンからの評価が引き継がれず、リリース直後に検索流入が急減して売上を落とすことがあります。これを防ぐために、旧URLから新URLへの301リダイレクト（恒久的な転送）を網羅的に設計することが必須の要件です。商品ページ・カテゴリページ・特集ページなど、検索流入の多いページを優先的に対応表へ落とし込みます。

あわせて、構造化データ（商品情報・価格・在庫・レビューなどをマークアップするschema.org）の再実装も要件に含めます。構造化データは検索結果での見え方に影響するため、刷新後も同等以上のマークアップを維持する必要があります。さらに、サイトマップXMLの再提出、メタタグやcanonicalの引き継ぎ、内部リンク構造の維持も論点です。SEO移行はリリース後に取り返しがつきにくいため、要件定義の段階でSEOの専門観点を取り込み、リダイレクト漏れがない移行計画を立てておくことが、刷新で売上を落とさないための生命線となります。

データ移行要件では、アセスメントで棚卸しした商品・会員・受注・ポイントなどのデータを、どの範囲まで・どの精度で新基盤へ移すかを定義します。古い退会会員や使われていない過去のキャンペーン情報まで移行しようとすると、移行コストが膨らみ品質リスクも高まるため、移行対象と移行しないデータの線引きを要件として定める必要があります。あわせて、データマッピング（旧項目と新項目の対応づけ）の方針やデータクレンジングの計画も、要件定義の段階で具体化しておきます。

切り替え方式と並行稼働の方針も、ECでは特に重要な要件です。ECサイトは止めれば即売上に響くため、移行中も販売を継続できる設計が求められます。基幹に近いECシステムを一度に入れ替えるビッグバンアプローチはリスクが高いため、機能単位で新旧を並行稼働させながら移行するストラングラーパターンが推奨されます。要件定義の段階で、どの機能から移行するか、移行順序とマイルストーン、許容できるダウンタイム、切り戻し（ロールバック）の条件を定めておくことで、移行段階の混乱と売上機会の損失を防げます。これらの移行要件はRFPにも明記し、ベンダーに移行設計力を問う材料とします。

RFP作成：ECベンダーに提示すべき項目とカットオーバー要件

要件が固まったら、それをRFP（提案依頼書）にまとめてECベンダーに提示します。RFPは、複数のベンダーから同じ土俵で提案と見積もりを得るための共通仕様書であり、ここで要件を曖昧に書くと、提案内容が各社バラバラになって比較が困難になります。EC刷新のRFPには、決済・物流・移行・SEOといったEC固有の論点を漏れなく盛り込むことが重要です。

EC刷新のRFPに必ず含めるべき項目を整理します。1つ目は現行システムの構成図と外部連携一覧で、決済・物流・在庫・基幹といった連携先を示し、ベンダーが移行範囲を正しく把握できるようにします。2つ目は移行対象データの一覧と件数で、商品・会員・受注・ポイントの規模を提示します。3つ目は性能要件で、想定ピーク時の同時アクセス数や目標応答時間を数値で明記します。

4つ目は移行後に達成したいKPIで、CVR・客単価・ページ表示速度といった改善目標を示すことで、ベンダーは単なる構築ではなく成果を意識した提案を行いやすくなります。5つ目はSEO/URL移行の要件で、301リダイレクトと構造化データの引き継ぎを求めます。これらに加えて、プロジェクト体制・スケジュール・予算範囲・保守運用の条件・提案フォーマットも記載します。RFPを丁寧に作り込むことで、ベンダーからの提案の質が揃い、比較検討と意思決定がスムーズになります。

EC刷新のRFPでとくに明確にすべきが、カットオーバー（本番切り替え）の方式とダウンタイムの許容範囲です。ECサイトは24時間365日稼働しており、切り替えのために長時間停止すれば、その間の売上を丸ごと失います。そのため、許容できるダウンタイムを具体的な時間で示し、その範囲内で切り替えを完了する方式をベンダーに提案させることが重要です。深夜のアクセスが少ない時間帯に切り替える、段階的に新サイトへトラフィックを移すなど、ダウンタイムを最小化する手段を問います。

あわせて、切り替え当日のリハーサル計画、データ移行の最終同期の方式、切り戻し（ロールバック）の判断基準と手順もRFPで求めます。基幹システムの切り替え障害で商品の出荷が全面的に停止した失敗事例が示すように、移行計画の甘さは深刻な業務停止を招きます。RFPの段階でカットオーバーのリスクとその対策をベンダーに提案させることで、移行設計力の高いパートナーを見極められます。受注の取りこぼしや二重処理を防ぐための注文の引き継ぎ方式まで具体的に問うことが、EC刷新では欠かせません。

ベンダー選定の評価観点（EC固有）

RFPに対する各社の提案が集まったら、価格だけで判断せず、客観的な評価基準で選定することが重要です。EC刷新のベンダー評価では、一般的なシステム刷新の観点に、EC固有の論点を加えて採点します。提案の見栄えや価格に惑わされず、刷新を確実にやり遂げられるパートナーを見極めるための評価観点を整理します。

EC刷新のベンダー評価で確認すべき観点として、次の5つが挙げられます。1つ目は、同業界・同規模のEC刷新における実績、とくにカート移行や決済再連携を伴うプラットフォーム移行の実績があるか。2つ目は、ビッグバンを避けた段階移行（ストラングラーパターン）を設計できる移行設計力があるか。3つ目は、切り替え時のダウンタイムを現実的に見積もり、その短縮策とロールバック計画を提示できるかです。

4つ目は、ECサイトの安定稼働を支える24時間365日の保守・運用体制があるか。ECは深夜や休日でも稼働しているため、障害時に即応できる保守体制は事業継続に直結します。5つ目は、ISO9001（品質マネジメント）やISO27001（情報セキュリティ）といった品質・セキュリティに関する認証を取得しているかです。決済や個人情報を扱うECでは、セキュリティの担保が特に重要になります。これらの観点に、決済代行会社や物流システムとの連携実績、SEO移行への知見を加えて評価すると、EC刷新に強いパートナーを選びやすくなります。

提案評価は、できるだけ客観化することが重要です。EC実績・移行設計力・ダウンタイム見積り・保守体制・品質認証という観点に加えて、提案の具体性やコミュニケーションの質も評価項目に加えるとよいでしょう。評価を担当者の主観に委ねず、観点ごとに配点を設けた評価シートを用いて複数名で採点することで、社内の合意形成と稟議の説明がしやすくなります。価格が安いという理由だけで選定すると、移行の品質や保守の手厚さで後悔することが少なくないため、総合評価で判断する姿勢が欠かせません。

ベンダーを選定した後も、発注側の関与が成否を分けます。ベンダーへの丸投げは失敗の典型的な原因であるため、定例会議の頻度・課題管理の方法・意思決定の責任者を明確にし、発注側とベンダーが一体となって進める体制を整えます。とくにEC刷新は販売業務に直結するため、商品登録・受注処理・在庫管理・カスタマーサポートを担う業務部門の担当者がプロジェクトに継続的に参画し、仕様確認やテストに主体的に関わる必要があります。RFPと要件定義で固めた内容を、発注後も発注側が責任を持って維持・確認していくことが、上流工程への投資を確かな成果へと結実させる鍵となります。

まとめ

本記事では、EC刷新のアセスメントから要件定義、RFP作成・ベンダー選定までの流れを、EC固有の論点に絞って解説しました。アセスメントでは、データ量・外部連携・ピークトラフィックを棚卸しし、CVR・客単価・離脱率といった現状KPIを正確に把握することが出発点です。続く要件定義では、カート移行・決済再連携（トークン移行とPCI DSS）・物流連携・会員/パスワード移行・SEO/URL移行（301リダイレクトと構造化データ）・データ移行と並行稼働方針という、EC刷新で必ず論点となる観点を機能要件と同等の重みで定義することが、刷新で売上を落とさない鍵となります。

RFPには現行構成図・移行対象データ・性能要件・移行後KPI・SEO移行要件を盛り込み、カットオーバー方式とダウンタイム許容を明確に示します。ベンダー評価では、EC刷新の実績、段階移行の設計力、ダウンタイムの見積り、24時間365日の保守体制、ISO認証という観点で客観的に判断します。要件定義・業務棚卸しの費用相場は200万円から500万円程度ですが、この上流工程への投資がEC刷新全体の成否を左右します。ベンダー丸投げを避け、発注側が主体的に上流を固めるために、アセスメントから伴走できるパートナーへの相談を検討してみてください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。