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