通販サイトやシステムのリプレイスは、目的と要件の整理、RFP（提案依頼書）による提案比較、契約と移行条件の合意の順に進めると、発注後の認識違いや混乱を防げます。
全体の流れは、通販サイト/システムリプレイスの完全ガイドにもまとめています。
▼全体ガイドの記事
・通販サイト/システムリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
発注前に固めるべきこと（目的・KPI・要件の明確化）
発注後のトラブルは、外注先の技術力より、発注前の準備不足から起きることがあります。目的が曖昧なまま見積もりを取ると、各社の前提がそろわず、提案を比べられません。そこで、発注前に刷新の理由、成功の基準、外せない要件を自社で言葉にしておきます。
リプレイスの目的とKGI/KPIの数値目標
ゴールは、KGI（最終目標）とKPI（中間指標）の数値で定めます。数値目標があれば、各社の提案を、目標を達成する方法で比べられます。
- カゴ落ち率：現状の70%から60%への改善
- 表示速度とCVR：3秒以内の表示と、モバイル経由のCVRを1.5倍に
- 受注処理：手作業の月40時間の削減
また、稟議でも投資対効果を説明しやすくなり、デザインの好みだけで選ぶ失敗も防げます。目的と優先順位は、経営層・現場・情報システム部門で共有しておきます。
Must/Wantによる要件の仕分けと要件肥大化の防止
機能の優先度を分けておくと、要件の膨張や見積もりの増加を抑えられます。
- Must：クレジットカード・コンビニ後払い、定期購入機能
- Want：ID決済（第二フェーズ）、サブスク向けのポイント二重付与
すべての要望を盛り込むと、見積もりが当初の1.5倍から2倍になることがあります。さらに、納期が延びる要件肥大化（スコープクリープ）も、発注前の仕分けで多くを防げます。
このため、初期リリースはMustに絞り、Wantは公開後の追加開発に回すと、費用と期間を抑えられます。仕分け表は、RFPやベンダーとの認識合わせにも使えます。
発注先の種類と特徴、候補の絞り込み
発注先の候補は、月商と業務の独自性、将来の拡張性に合わせて絞り込みます。
- ASP/SaaS型：ECプラットフォーム提供事業者
- クラウドEC：クラウド型のEC提供ベンダー
- OSS：オープンソースをカスタマイズする開発会社
- ECパッケージ：既製のEC製品を提供するベンダー
- フルスクラッチ：個別開発を得意とするシステム開発会社
月商100万円未満の立ち上げ期は、ASPやモール出店が候補になります。月商数百万から数千万円の成長期なら、高機能ASPやクラウドEC、OSSが候補に挙がります。
一方で、月商数億円以上で独自業務フローや基幹連携が必須なら、パッケージやフルスクラッチを検討します。自社の段階と3〜5年後の拡張性を見据えると、候補を比較しやすくなります。
RFP（提案依頼書）の作り方と経営層への稟議の通し方
候補が固まったら、各社に同じ条件で提案を求めるRFP（提案依頼書）を作ります。RFPは相見積もりの共通の基準になり、稟議資料の準備もこの段階で並行して進めます。
RFPがないと、提案の前提がばらつき、金額の妥当性を比べにくくなります。数千万円から数億円規模の投資を承認してもらうには、比較材料をそろえておく必要があります。
RFPに盛り込むべき項目と書き方
前提と提案条件をそろえるため、RFPには次の情報を含めます。
- 目的と要件：背景、KGI/KPI、Must/Want別の機能要件
- 現行環境：システム構成とデータ移行の対象範囲
- 連携要件：基幹・WMS・CRM・会計との接続
- 提案条件：スケジュールと予算レンジを示したうえで、体制・実績、見積内訳、保守内容を提案してもらう
連携要件は、対象システム名に加えて、APIやCSVなどの連携方式とデータ項目まで具体的に求めます。そのため、「連携できます」といった曖昧な回答が減り、各社の対応力を比べられます。
見積もりは、合計額に加えて、項目ごとの内訳をそろえて出してもらいます。内訳には、要件定義や設計開発、データ移行を含めます。また、連携開発やテストの費用も、同じ区分で示してもらいます。
特に、公開前の保守費と公開後の運用保守費は分けて示してもらうと、追加請求を防ぐ手がかりになります。
評価基準は、提案を受ける前に社内で決めておきます。価格と実績に加えて、体制と保守の比重も決めます。
ROI・リスク対策・比較表による稟議の承認
投資回収とリスク、候補各社の違いを示せば、経営層の判断材料がそろいます。
- 回収見込み：初期投資と3〜5年のTCO、効果、回収年数
- リスク対策：売上喪失や情報漏えいへの対応策
- 比較表：候補ごとに価格と実績を並べ、体制や保守、連携対応も比べる
TCO（総保有コスト）は、初期投資額と3〜5年分のランニングコストを合算して求めます。さらに、KPI改善による売上増や業務削減による人件費の圧縮を、金額に換算して含めます。
例として、初期4,000万円、年間運用600万円の場合に、年1,500万円の効果を見込みます。この例はCVR改善と業務効率化を想定しており、回収は約3年です。
切り戻し計画、段階移行、セキュリティ対策は、それぞれ対応するリスクと対にして書きます。
推奨する会社は、定量と定性の両面から理由を説明します。そのため、発注の妥当性が経営層に伝わります。
ベンダー丸投げを防ぐ発注側マネジメント
発注後に炎上する原因の一つは、ベンダーに任せきりにする丸投げです。外注しても発注側の仕事は続き、プロジェクトマネジメント（PM）の質が使いやすさを左右します。
週次定例・課題管理表・成果物承認の仕組み
発注側のPMが、進捗と課題が見える運営の型を用意します。
- 週次定例：毎回のアジェンダと議事の記録
- 課題管理表：未解決の論点ごとの担当者、期限、対応方法
- 成果物承認：各フェーズの内容を確認したうえでの正式な承認
口頭だけで進めると、認識のずれが後工程の手戻りにつながります。そこで、要件定義書や基本設計書、画面設計などは、発注側が内容を確認して承認します。
承認の記録が残っていれば、仕様変更が追加要件なのか、当初の合意の範囲なのかを判断しやすくなります。運営ルールは発注前に合意したうえで、契約書や議事に残しておくと実効性が高まります。
責任分界点の合意とFit to Standardの徹底
連携や運用の担当範囲と、カスタマイズの線引きは、発注側が主導して決めます。
- 責任分界点：ベンダー、自社、他社の担当範囲を文書に残すこと
- 標準機能：業務を機能に合わせるFit to Standardの検討
- 個別開発：競争力の源泉となる部分に絞ったカスタマイズ
API仕様とデータ項目は、基幹システムとWMS、決済代行と会計の連携ごとに確認します。障害時の一次窓口まで含めて責任範囲を決めておくと、「連携できます」という回答の中身を具体化できます。
過剰なカスタマイズは費用と保守負担を増やします。そのため、標準機能で代替できる業務は、業務のやり方を機能に合わせます。現場の抵抗も踏まえつつ、外注先任せにせず、使い続けられるシステムを目指します。
切り戻し基準と段階移行によるリスクの抑制
公開時の障害に備えて、旧システムへ戻す条件と移行の方法を、事前に決めておきます。
- 切り戻し条件：公開後2時間以内に決済できない
- 連携障害：受注データが基幹に連携されない
- 段階移行：主要顧客や一部商品カテゴリからの切り替え
切り戻しの発動条件と判断者を文書で合意しておけば、障害時に慌てず判断できます。段階移行は、スケジュールが長くなる一方で、致命的な障害が全顧客に及ぶリスクを下げます。
BtoB ECでは、影響の大きい顧客に先に試してもらい、問題を洗い出す進め方もあります。ビッグバン移行と段階移行のどちらを採るかは、発注時に外注先と相談しておきましょう。
データ移行とSEOを引き継ぐ発注時の取り決め
データ移行やSEOの対応を誤ると、検索流入や顧客資産を失い、公開後の問題につながります。そのため、データ移行とSEOの引き継ぎは、対象範囲と責任を発注時に明確にしておきます。
301リダイレクトとSEOリスクの定量評価の依頼範囲
URLが変わる場合は、旧URLから新URLへの301リダイレクトと流入分析を、依頼内容に含めます。
- 設定範囲：リダイレクトの対象、実施責任、公開前の検証方法
- 一覧表：作成者とチェック担当の取り決め
- 流入分析：ページ群ごとのトラフィック構造を、移行前に調べておくこと
設定が漏れたページは検索結果から消え、積み上げた検索評価がリセットされるおそれがあります。流入がトップページやブランド名検索に集中するのか、数千の商品ページに分散するのかで、難易度が変わります。
流入の多くを特定のページ群が担っている場合は、その引き継ぎを先に進めるなど、リスクに応じた計画を立てられます。定量評価は、移行の必要性や投資に見合うかを経営判断する材料にもなります。
パスワード移行不可・会計データ突合・データ廃棄の業務計画
顧客対応と会計データの検証、旧システムの個人情報の廃棄まで、業務計画に含めます。
- パスワード：再設定の案内と、離脱を防ぐ施策の用意
- 会計データ：移行後に、旧システムと新システムの残高を突合
- データ廃棄：不要な個人情報の廃棄時期と方法
暗号化方式が新旧で異なる場合は、顧客のパスワードを引き継げないことが大半です。このため、再設定の手順を事前に決めておく必要があります。再設定した顧客へのポイント付与も、施策として検討できます。
注文履歴や売掛・買掛は、1円の差異も許さない突合が求められます。会計データの不整合は決算や監査に直結するため、検証の手順を発注内容に含めておきます。
顧客がログインできずに離脱する事態は、業務計画の段階で防いでおく必要があります。また、データ廃棄の取り決めも、コンプライアンスの観点から欠かせません。
契約・見積・支払い条件で注意すべきポイント
契約形態と支払い条件を押さえておくと、見積もり後の追加費用や認識違いを防げます。加えて、見積もりの総額に含まれる範囲や、要件定義費・公開前保守費の扱いも確かめておきましょう。
要件定義費・公開前保守費など隠れコストの扱い
初期開発費以外の費用も洗い出して、3〜5年の総コストで比べます。
- 開発関連：要件定義、データ移行、外部連携の開発
- 保守関連：公開直前の集中サポート、公開後の運用保守
- 運用費：決済手数料、従量課金、追加アプリ利用料
月商の増加に比例して、決済手数料や従量課金が膨らむことがあります。そのため、3〜5年のTCOには、アプリ追加費やOS・ミドルウェアの更新費も含めて見ておきます。また、倉庫やコールセンター、社内スタッフの教育とマニュアル整備も、予算に織り込みます。
契約形態（請負/準委任）と検収・支払い条件
契約形態と検収基準、支払いの前提は、フェーズごとに決めておきます。
- 請負契約：成果物の完成に対する責任
- 準委任契約：業務の遂行への対価
- 支払い：着手金、中間金、検収後の最終支払い
要件が固まった開発は請負、要件を詰める要件定義は準委任とする使い分けがあります。契約形態によって、瑕疵対応の責任範囲や追加対応の費用負担が変わります。
各支払いの前提となる成果物と完了の基準は、文書に残しておきます。特に、検収基準が曖昧だと、稼働前に支払いを求められたり、検収が長引いたりします。
納品物の範囲と検収期間、不具合対応の保証期間、無償保守の範囲と期間を、発注時に合意しておきましょう。
まとめ
成功の鍵は、発注先を選ぶことに加えて、発注側が準備と管理に踏み込むことです。目的とKGI/KPI、Must/Wantを明確にしたうえで、共通のRFPで相見積もりを取ります。
稟議では、3〜5年のTCOとROI、リスク対策、比較表をそろえて説明しましょう。発注後は運営の型を設け、責任分界点や標準機能の活用、切り戻し基準を合意しておきます。
データ・SEOの移行、顧客や会計への対応、隠れコストと契約条件も、発注時に確認しておきます。論点を一つずつ押さえることが、公開後も使い続けられ、事業成長に貢献する移行につながります。
この記事の各項目は、発注準備のチェックリストとしても使えます。
▼全体ガイドの記事
・通販サイト/システムリプレイスの完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。