EC更改を成功させられるかどうかは、ベンダーへ発注する前の「準備段階」でほぼ決まります。サポート終了や契約満了という期限に追われ、現状分析を省いて見積もり依頼へ進んでしまうと、移行範囲が曖昧なまま費用が膨らんだり、必要な機能が抜け落ちたりします。EC更改では、現状をアセスメント（現状分析）で可視化し、それをもとに要件定義を行い、RFP（提案依頼書）としてベンダーへ提示するという一連の流れを丁寧に踏むことが、失敗を避ける王道です。
本記事では、EC更改のアセスメント・要件定義・RFPについて、「現状分析で何を可視化するか」「要件定義に何を盛り込むか」「RFPにどんな項目を記載し、どんな基準でベンダーを評価するか」を実務に沿って解説します。あわせて、更改全体の進め方や費用感を俯瞰したい場合はEC更改の完全ガイドもご覧ください。本記事では、完全ガイドでは概要にとどまる「発注前の準備」に焦点を絞り、RFPに含めるべき具体項目とベンダー評価の客観的基準まで踏み込みます。これを読めば、更改を依頼する前に何を整理すべきかが明確になります。
▼全体ガイドの記事
・EC更改の完全ガイド
EC更改のアセスメント（現状分析）で可視化すべきこと
アセスメントは、更改の出発点であり最も重要な工程です。更改が新規構築と決定的に異なるのは、「現行サイトという既存資産」が存在する点にあります。この現行資産の中身を正確に把握しないまま要件定義へ進むと、移行漏れや想定外の追加費用が次々と発生します。更改プロジェクトが炎上する大きな原因のひとつが、現行システムのブラックボックス化による現状分析の不足です。本章では、アセスメントで具体的に何を可視化すべきかを整理します。
現行サイトのAS-IS（現状）を可視化する
アセスメントの第一歩は、現行サイトのAS-IS（現状）を可視化することです。具体的には、現在の機能一覧、システム構成図、外部システムとの連携一覧、データ構造（商品マスタ・会員・受注などのデータ項目）、そして表示速度や同時アクセス数といった非機能の実績値を洗い出します。長年運用してきたサイトでは、当初の設計書が古くなっていたり、追加カスタマイズの記録が残っていなかったりするため、この棚卸しに想像以上の手間がかかります。
複雑化した現行資産を可視化する手段として、システムの複雑度や依存関係を分析するツールを活用するアプローチもあります。富士通が提供する「ソフトウェア地図」のように、アプリケーション資産の複雑度や依存関係を可視化するツールは、ブラックボックス化したシステムの全体像を把握する助けになります。手作業の棚卸しとツールによる分析を組み合わせ、「どこに何があり、何と何がつながっているか」を明らかにすることが、後続の要件定義の精度を大きく高めます。
データ資産と課題・要望を棚卸しする
EC更改のアセスメントで特に重視すべきがデータ資産の棚卸しです。商品マスタ、会員情報、受注履歴、ポイント残高といったデータは、更改後も引き継ぐ必要があり、その量・構造・品質が移行の難易度を左右します。データに重複や欠損、表記ゆれが多いと、移行時にトラブルが発生しやすくなります。アセスメント段階でデータの状態を点検し、必要なら更改前にデータをクレンジング（整理・修正）しておくことが、後工程の手戻りを防ぎます。
あわせて、現場の課題と要望を棚卸しします。運用担当者が日々感じている不便さ、顧客からの問い合わせで多い不満、経営層が更改に期待する成果を、それぞれヒアリングして整理します。アセスメントは単に現状を記録する作業ではなく、「現状の何を解決し、更改後にどんな状態を目指すのか」という目的を明確にする工程でもあります。ここで集めた課題と要望が、次の要件定義の素材になります。
外部連携と非機能の実績も棚卸し対象にする
アセスメントで見落とされやすいのが、外部システムとの連携と非機能の実績です。ECサイトは、基幹システム、在庫管理システム、決済代行、配送業者のシステム、メール配信ツール、外部モールなど、多くの外部システムとつながっています。これらの連携をすべて洗い出し、それぞれの連携方式（API連携かファイル連携か、リアルタイムかバッチか）まで把握しておかないと、移行時に「在庫が反映されない」「受注が基幹に渡らない」といった重大なトラブルを招きます。
非機能の実績値も、アセスメント段階で数値として押さえておきます。ピーク時の同時アクセス数、主要ページの表示速度、過去に発生した障害の頻度や内容などを記録しておくと、更改後の目標値を設定する根拠になります。「速くしたい」「落ちないようにしたい」という漠然とした要望ではなく、現状の数値を起点に「どこまで改善するか」を定められるかどうかが、要件定義の精度を左右します。現状を測れていなければ、更改の効果も測れません。連携と非機能を棚卸し対象に含めることが、抜けのない要件定義への土台となります。
EC更改の要件定義で固めるべき項目
アセスメントで現状と目的を可視化したら、それを要件定義に落とし込みます。更改の要件定義は、ゼロから機能を考える新規構築とは異なり、「現行機能のうち何を引き継ぎ、何を変え、何を新たに加えるか」という差分の整理が中心になります。本章では、要件定義で固めるべき項目を機能要件と非機能要件・移行要件に分けて整理します。
機能要件は「差分」で整理する
機能要件は、アセスメントで作成した現行機能一覧をベースに、各機能を「現行どおり引き継ぐ」「仕様を変えて作り替える」「新たに追加する」「廃止する」のいずれかに分類して定義します。この差分整理を丁寧に行うことで、ベンダーは見積もりの根拠を明確に把握でき、後の認識齟齬を防げます。すべての機能をゼロから書き起こすのではなく、現行を起点に変更点を明示するのが更改の要件定義のコツです。
このとき重要なのが、更改後に達成したいKPI（重要指標）を要件に紐づけることです。たとえば「表示速度を改善する」という要望を、「主要ページの表示を一定秒数以内にする」といった測定可能な目標へ落とし込みます。「カート離脱を減らす」なら、購入手続きのステップ数や入力項目数を要件として具体化します。曖昧な要望のままベンダーへ渡すと、完成後に「思っていたものと違う」というすれ違いが起こります。要件は測れる形で定義することが鉄則です。
非機能要件と移行要件を明確にする
非機能要件は、表示速度・可用性・セキュリティ・拡張性といった、画面に現れない品質を定義する項目です。EC更改では、繁忙期のアクセス集中に耐える同時接続数、許容できるダウンタイム、クレジットカード情報の取り扱いに関するセキュリティ要件などを具体的な数値で定めます。サポート終了を契機とする更改では、セキュリティ要件が最優先になるため、ここを曖昧にしないことが重要です。
更改ならではの項目が移行要件です。どのデータをどの範囲で移行するか、移行のタイミング（一括か段階か）、移行中の新旧サイトの並行稼働の有無、切り替え時に許容できるサービス停止時間、そして万一の際の切り戻し手順までを要件として定義します。移行要件の曖昧さは、本番切り替え時のトラブルに直結します。さらに、URL構造の変更に伴うリダイレクト設定やSEO資産の引き継ぎも移行要件に含め、検索流入を落とさない設計を明記しておきましょう。
EC更改のRFP（提案依頼書）に含めるべき項目
要件定義が固まったら、それをRFP（提案依頼書）としてベンダーへ提示します。RFPは、ベンダーから精度の高い提案と見積もりを引き出すための文書であり、ここでの記載が曖昧だと各社の提案がばらつき、横並びでの比較が難しくなります。本章では、EC更改のRFPに含めるべき項目を整理します。
RFPに記載すべき必須項目
EC更改のRFPには、最低限、次の項目を記載します。プロジェクトの目的と背景（なぜ更改するのか、サポート終了などのきっかけ）、現行システムの構成図と機能一覧、引き継ぐべきデータの概要、機能要件・非機能要件・移行要件、達成したいKPI、希望する更改後の構成や手法の方向性です。とくに更改特有の項目として、現行構成図と移行対象データの提示は欠かせません。これがないと、ベンダーは移行の難易度を見積もれません。
あわせて、サポート終了日や契約満了日といった「動かせない期限」と、希望スケジュール、想定予算の範囲、選定の進め方とスケジュールも明記します。期限を伝えないと、ベンダーは余裕を見込んだスケジュールを提案し、結果として間に合わないリスクが生じます。RFPは「自社の制約をすべて開示し、その制約の中で最適な提案を引き出す」ための文書だと捉えると、何を書くべきかが整理しやすくなります。提案フォーマットを指定しておくと、各社の回答が揃い、比較が容易になります。
ベンダー評価の5つのチェックポイント
RFPへの提案が集まったら、客観的な基準でベンダーを評価します。評価で押さえたいチェックポイントは5つあります。第一に、同業界・同規模のEC更改の実績です。新規構築ではなく「更改・移行」の経験があるかが、更改の難所を乗り越えられるかを左右します。第二に、段階移行を含む移行設計の力です。すでに稼働しているサイトを止めずに切り替える設計ができるかを、提案内容から見極めます。
第三に、本番切り替え時のダウンタイムの見積もりです。切り替えにどれだけサービスが止まるかを具体的に提示できるベンダーは、移行の検討が進んでいる証拠です。第四に、保守・運用体制です。更改後の安定稼働を支える保守体制（対応時間、障害時の対応など）を確認します。第五に、品質・セキュリティの認証です。情報セキュリティや品質に関する第三者認証を取得しているかは、カード情報や個人情報を扱うEC更改で重視すべき客観的な指標になります。この5点を採点表にして各社を横並びで評価すれば、感覚ではなく根拠に基づいた選定ができます。
提案依頼から発注決定までの進め方
RFPを作成したら、それを複数のベンダーへ同時に提示し、横並びで提案を集めるのが基本です。1社だけに相談すると、提示された費用や期間が妥当かどうかを判断する材料がなく、交渉力も働きません。EC更改では、後継パッケージへの載せ替えが得意なベンダー、クラウド型サービスへの移行に強いベンダー、業務改革まで踏み込めるベンダーなど、各社の得意領域が異なります。複数社から提案を受けることで、自社の課題にどの手法・どのパートナーが合うかを比較検討できます。
提案を受けた後は、書面の比較だけで決めず、提案内容についての質疑や、可能であれば対象システムのデモを通じて、ベンダーの理解度を見極めます。とくに更改では、現行サイトの制約や移行の難所をどれだけ正確に把握しているかが、提案の実現性を左右します。期限が決まっている更改では、提案依頼から発注決定までのスケジュールも逆算で組み、ベンダーの回答期間や社内の検討期間を確保しておくことが大切です。準備したRFPの質が高いほど、この比較・選定のプロセスは円滑に進みます。
まとめ
本記事では、EC更改のアセスメント・要件定義・RFPについて、発注前の準備に焦点を絞って解説してきました。アセスメントでは現行サイトのAS-ISを可視化し、機能一覧・構成図・連携・データ資産・現場の課題を棚卸しすることが出発点になります。要件定義では、現行機能を「引き継ぐ・作り替える・追加する・廃止する」の差分で整理し、KPIを測れる形に落とし込み、非機能要件と移行要件を明確にすることが重要でした。RFPでは、現行構成図や移行対象データを含む必須項目と動かせない期限を記載し、5つのチェックポイントでベンダーを客観的に評価します。
EC更改が炎上する大きな原因は、現状分析の不足と要件の曖昧さにあります。期限に追われて準備を省くほど、後工程で手戻りや追加費用が膨らみます。アセスメントで現状を正確に把握し、要件を測れる形で定義し、RFPで自社の制約を開示する。この一連の準備を丁寧に踏むことが、更改の成否を大きく左右します。データのクレンジングやSEO資産の引き継ぎといった更改特有の論点も、準備段階で漏れなく押さえておきましょう。
自社のEC更改で準備を進める際は、本記事のアセスメント・要件定義・RFPの流れを手順書として活用してください。そのうえで、更改全体の進め方や費用感、手法の選択肢を俯瞰したい場合は、完全ガイドもあわせてご覧いただくと、発注前の準備を全体計画の中に位置づけやすくなります。準備の質を高めることが、満足のいく更改への確かな一歩になります。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。