EC刷新の発注は、社内の現状を把握することから始めます。そのうえで、RFP（提案依頼書）を作成し、ベンダーを選定して、契約を結び、移行を管理する順に進みます。
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
EC刷新を発注する前にやるべき社内準備
現行ECの棚卸し（機能・データ・外部連携の把握）
EC刷新で最初に失敗しやすいのは、発注前の社内準備が足りないことです。ベンダーに依頼する前に、次の3点を整理しておく必要があります。
- システム：機能一覧と商品マスタ
- 受注・顧客：注文履歴、会員データの件数と品質
- 外部サービス：決済代行会社や物流WMSなどとの連携状況
上の3点を洗い出し、全体像を正確につかんでおきます。特にデータの品質は、プロジェクト後半で重大な問題として浮上するケースが多いです。
ある中規模アパレルECの刷新では、注文履歴データの一部が旧システム固有のフォーマットで保存され、移行作業の終盤で互換性の問題が発覚しました。その結果、顧客から「注文履歴が確認できない」という問い合わせが届き、カスタマーサービスに多大な負荷がかかりました。こうした事態を防ぐには、データのクレンジングを誰が担うかを、RFP段階で明確に定めておくことが欠かせません。
キングジムのEC基盤刷新では、最終的に選ばれたのは最高額の見積もりを提示した会社でした。選定理由は金額ではなく、提案の場でシステムキーパーソンが「旧システムの構成を全部洗い出します」と明言した一言でした。この姿勢が評価されたのは、発注側が現行システムの複雑さを把握していたからで、自社の棚卸しが曖昧なままだと、適切な提案は引き出しにくくなります。
SaaS EC vs スクラッチの方針決定
発注先を探す前に社内で合意すべき最重要の決定は、SaaS型ECプラットフォームを使うか、スクラッチ（または既存フレームワークでのカスタム）開発にするかです。この方針が固まらないまま複数社にRFPを送ると、比較対象のそろわない提案書が集まり、評価そのものが難しくなります。
Shopify PlusやBASE、ecforceなどのSaaS型プラットフォームは、初期費用を抑えながら標準機能を素早く導入できます。ただし、独自の業務フローへの対応には限界があります。一方、スクラッチ開発は自由度が高いものの、初期開発コストが数千万円規模に上ることも珍しくなく、運用・保守の社内体制も必要になります。
年商10億円以下の中小ECであれば、まずShopify Plusのような実績あるSaaSを中心に、複数社から提案を取り、カスタマイズの範囲を見極めるのが合理的です。これに対して、年商50億円超で独自の商品管理フローや会員制度を持つ場合は、SaaSに絞らず、スクラッチやセミオーダーも含めて比較する必要があります。
予算確保のための稟議書に盛り込むべき情報
EC刷新の稟議書で承認を得るには、「システムが古い」という理由だけでは不十分です。そのため、現状の課題を数字で示したうえで、刷新後の期待効果をROIとして提示する必要があります。
たとえば、現行ECの表示速度の遅延による離脱率の上昇（GoogleのLighthouseスコアや直帰率の実績値を活用）と、カートの離脱率の高さを挙げられます。さらに、モバイル対応の遅れが売上に与えている機会損失額を試算し、刷新後に期待されるCVR改善幅と売上インパクトとあわせて記載します。
刷新の費用は、初期開発費用に加えて、並行稼働期間中の運用コスト（旧EC・新EC双方の保守費用）、データ移行・クレンジング費用、社内教育や運用体制の構築費用も含めて示します。さらに、トラブル時のバッファとして全体予算の15〜20%程度のリスク費用も明示します。こうして最初から費用を示しておくと、後から追加費用が発生したときの社内摩擦を最小化できます。
RFP（提案依頼書）の作り方
EC刷新RFPに記載すべき項目と書き方のポイント
EC刷新のRFPは、プロジェクトの背景・目的・制約条件を体系的にまとめた文書で、機能要件の羅列はその一部にすぎません。
ベンダーから精度の高い提案を引き出すには、「何を作りたいか」に加えて、「なぜ今刷新が必要か」「どんな制約の中で進めるか」まで示すことが欠かせません。
RFPの章立ては、比較の基準をそろえるために、次の5項目に分けます。
- プロジェクト概要：刷新の背景・目的・スコープ
- 現行システム情報：使用中のプラットフォーム、商品数・SKU数・月間注文件数・会員数、連携する外部サービス（決済代行・物流WMS・MAツール等）
- 機能要件：必須機能とオプション機能、将来的な拡張予定
- 非機能要件：Core Web VitalsのLCPが2.5秒以内などの表示速度、PCI DSS準拠の有無、稼働率99.9%以上などの可用性
- プロジェクト条件：希望するリリース時期・予算の概算・選定スケジュール
デザイン会社と開発会社の分離発注の検討
EC刷新では、デザインと開発を同じベンダーに一括で頼むことが多いものの、それぞれ専門の会社に分けて発注する「分離発注」も有力な選択肢です。分離発注のメリットは、デザインの品質を独立して担保できることと、ブランドのトンマナを守りながら開発コストを見直せることです。
特に、ブランドイメージが差別化要因となるファッション・コスメ・ライフスタイル系のECでは、デザインの専門性がCVRや顧客体験に直接影響します。そのため、デザイン専門会社への依頼が有効です。一方で、分離発注には、デザインと開発の間で責任の所在が曖昧になるリスクもあります。
たとえば、デザインカンプどおりに開発が実装できない場合、「デザインが開発上の制約を無視している」「開発側の技術的な解釈が違う」といった争いが起きやすくなります。分離発注を選ぶ場合は、発注者側がデザインと開発の橋渡し役を担う体制を明確にし、両社の仕様合意の進め方をプロジェクト管理計画に明記する必要があります。
繁忙期・並行稼働・SEO継続性の要件を盛り込む方法
EC刷新のRFPには、一般的なシステム刷新では見落とされがちなEC特有の要件を、明記しておくことが大切です。その代表が「繁忙期を避けた移行タイムライン」「旧ECとの並行稼働期間」「SEO継続性の確保」の3点です。SEO継続性については、新ECへのURLリダイレクト設計（301リダイレクト）を誰が担当し、どの段階で完了させるかを、RFPに明記する必要があります。
繁忙期は、年末商戦（11月〜12月）、バレンタイン（1月〜2月）、母の日（4月〜5月）など、業種ごとのピークを明記します。その前後6週間はシステム切り替えを行わないことを、前提条件にします。切り替え時に障害が起きた場合、繁忙期は売上への打撃が何倍にも膨らむことを、ベンダーと共有しておくと、リリース計画の精度向上につながります。
ある食品ECの刷新事例では、旧URLから新URLへの301リダイレクト設定が不完全だったため、Googleのインデックスが大幅に減り、刷新後3ヶ月で自然検索経由の流入が約40%減るという深刻な事態が起きました。検索エンジンの評価は一度失うと回復に数ヶ月かかるため、SEO継続性の責任範囲は契約書レベルで明確にしておくことが不可欠です。
ベンダー比較・選定プロセスの進め方
最低3社からの提案取得と評価基準の設定
ベンダー選定では、最低でも3社から提案を取ることを強く推奨します。1〜2社では比較が成り立たず、価格の妥当性も判断できません。3社以上から集めると、見積もりの相場感をつかみながら、技術的なアプローチの違いや各社の強み・弱みを客観的に比べられます。
評価基準は、RFPを送る時点で示しておくのが理想的です。たとえば、技術力・実績（30点）、提案の的確さ・課題理解度（25点）、プロジェクト管理能力（20点）、費用の妥当性（15点）、保守・運用体制（10点）といったウェイトが参考になります。基準を事前に公開すると、各ベンダーが優先すべき点を理解して提案を作れるため、発注側も比較しやすくなります。
評価は、必ず複数の関係者（IT担当・業務担当・経営幹部）が採点し、平均値や合議で決めます。こうすることで、特定個人の好みに左右されない選定プロセスになります。
リファレンスチェックの実施手順【独自テクニック】
ベンダー選定で競合他社が見落としがちなのが、過去のクライアントに直接確認する「リファレンスチェック」です。ベンダーの提示する実績はすべて成功事例のため、表向きの情報からは、プロジェクト遂行能力の本当の姿が分かりにくいものです。リファレンス先は、ベンダーの推薦に頼らず、公開実績から発注側が連絡先を探すと、より客観的な情報収集につながります。
リファレンスチェックを実施すると、「納品が6ヶ月遅延した」「仕様変更のたびに多額の追加費用が発生した」「担当者が途中で何度も交代した」といった重大な問題を事前に把握できます。実際に筆者が関与した某アパレルECの刷新案件では、最終候補に残ったベンダーに照会したところ、過去に類似規模のEC刷新で約8ヶ月の大幅遅延が発覚しました。
ベンダーは、その事実を提案書に一切記載しておらず、このチェックがなければ選定されていた可能性が高い状況でした。リファレンス先の企業には、「プロジェクトの進捗管理の精度」「追加費用の発生頻度と対応の透明性」「担当者の安定性」「本番移行後のサポート対応の速さ」の4つの観点で評価を求めるとよいでしょう。
EC特有の技術力（Headless Commerce、Core Web Vitals）の評価基準
EC刷新のベンダーを評価するには、一般的なシステム開発とは異なる、EC特有の技術要件への対応力を確認する必要があります。特に近年重要性が増しているのは、次の2点です。
- Headless Commerce：Headless構成での開発と運用の対応力
- Core Web Vitals：LCPやINPなどの表示速度に関する改善実績
Headless Commerceとは、フロントエンド（表示層）とバックエンド（commerce機能）を分けたアーキテクチャです。Next.jsやNuxt.jsといったフレームワークでフロントエンドを開発し、ShopifyやCommercetoolsといったバックエンドと組み合わせる設計を指します。この構成は表示速度の大幅な向上やコンテンツ管理の柔軟性を高める一方で、実装の複雑度も上がります。
ベンダーにHeadless Commerceの実績を確認する際は、具体的な構成（フロントエンドのフレームワーク・バックエンドのプラットフォーム・CDNの構成）を示してもらいます。あわせて、本番環境でのCore Web VitalsのLCPやINPのスコアも示してもらうと、技術力を客観的に評価できます。
なお、Googleが2024年以降にCore Web Vitalsの指標として重視するINP（Interaction to Next Paint）への対応実績は、EC業界の最新動向に追随している証左といえます。
契約締結のチェックリスト
請負契約と準委任契約の選択基準
EC刷新の契約形態は、プロジェクトの性格と発注者側のリスク許容度で変わります。大きく分けると、「請負契約」と「準委任契約」の2種類があります。請負契約は、成果物の完成をベンダーが責任を持って保証する形態で、仕様が明確なフェーズ（設計書をもとにした開発工程など）に適しています。
発注者にとっては予算が固定される安心感がある一方、仕様変更が起きると、追加費用や工期延長の交渉になりやすい特徴があります。準委任契約は、ベンダーが善管注意義務をもって作業を遂行することを約束する契約で、成果物の完成を保証するものではありません。要件定義や設計の初期フェーズ、継続的な保守・運用フェーズで使われることが多いです。
実務では、要件定義を準委任契約で進め、基本設計以降を請負契約に切り替える「フェーズ分割型契約」が、リスクと責任の面で合理的です。ただし、スルガ銀行と日本IBMの法廷闘争に代表される、95億円規模の開発費用の白紙撤回は、業務要件に合わないパッケージ選定が原因でした。契約形態を選ぶ前に、要件の合意プロセスを丁寧に踏むことが、最大のリスクヘッジになります。
並行稼働期間・URLリダイレクト・データ移行の責任分界点
EC刷新の契約書で特に注意したいのは、旧ECと新ECの「並行稼働期間」の扱いです。新ECの本番リリース後も、旧ECのサポートが一定期間必要になるケースが多く、その費用負担と責任範囲を契約書に書いておかないと、後のトラブルの原因になります。一般には、本番リリース後1〜3ヶ月を並行稼働期間とし、その間の旧EC保守費用をどちらが負担するか、障害対応の窓口をどこに設けるかを明確にします。
URLリダイレクトとデータ移行も、どこまでを誰が受け持つかを契約書に盛り込むべき重要事項です。特にURLリダイレクトは、「誰が・いつまでに・どの範囲で・どのように確認するか」という4W1Hを、契約書か別紙の仕様書に明記する必要があります。
データ移行では、移行対象のデータ範囲と、クレンジングの作業範囲や担当者を、契約書で定めます。さらに、移行後の検証方法と合格基準、移行後に見つかったデータ不整合の対応費用の帰属も明確にします。これによって、移行後にトラブルが起きたときの責任の所在がはっきりします。
瑕疵担保責任・追加費用・損害賠償の交渉ポイント
契約交渉で発注者側が特に注意すべき条項は、瑕疵担保責任の範囲と期間、追加費用の発生条件、損害賠償の上限額です。標準的な瑕疵担保期間は納品後1年が多いものの、ECシステムでは、繁忙期を経験した後に初めて発覚するバグや性能劣化があるため、最低1年、できれば2年を確保するのが望ましいです。
追加費用では、「仕様変更の定義」と「追加費用が発生する条件」を契約書に明記することが大切です。曖昧な仕様書をもとに開発を始めると、ベンダーは「仕様変更だ」と主張し、発注者は「最初から合意した内容だ」と主張する、典型的な追加費用トラブルに発展しがちです。
このリスクを下げるには、要件定義フェーズで作る要件定義書を成果物として契約書に附属させ、変更管理の流れ（変更管理委員会の設置、承認フローの明記）も盛り込むことが有効です。ベンダー側の提示する損害賠償の上限は、多くが請負金額の範囲内です。さらに、EC売上停止による機会損失の一部を補償対象とする条項を、交渉で追加するケースもあります。
発注後のプロジェクト管理と移行当日の進め方
繁忙期を避けた移行タイムライン設計
契約締結後のプロジェクト管理で最初に確定させるのは、リリース日です。EC刷新では、繁忙期を避けることが鉄則です。業種によって繁忙期は異なるものの、一般的なECで最大のリスクシーズンは11月〜12月（年末商戦・クリスマス・年賀状需要）です。
この時期にシステム切り替えを行って障害が発生すると、売上損失が億単位に達するケースも想定されます。理想的なリリース時期は、繁忙期終了後の2〜3月（閑散期）、または5〜6月（梅雨前の中間期）です。リリース日から逆算して、各フェーズの完了期限を決めます。
リリース日の8週間前にユーザー受入テスト（UAT）を始め、4週間前に本番環境での最終検証、2週間前に移行リハーサルを行う「マイルストーン逆算設計」が、現場の混乱を防ぐ有効な手段です。また、各部署から「システムキーパーソン」を選んで会議に参加させると、部門間の利害調整が円滑に進みます。この体制を早く整えた案件では、現場の反発を抑えてスムーズに移行できた事例が複数報告されています。
移行当日のロールバック計画と顧客告知の準備
移行当日に欠かせないのが、「ロールバック計画」の策定です。ロールバックとは、新システムへの切り替え後に重大な障害が起きた場合に、旧システムへ戻す手順のことです。「新しいシステムに問題があれば旧に戻せばいい」と考える担当者は多いものの、手順・タイムライン・判断基準・承認者を事前に決めておかないと、当日の混乱のなかで素早く判断するのは困難です。
ロールバック計画では、どのエラーレートやエラー種別でロールバックを判断するかという、定量的な基準を設けることが大切です。たとえば、「注文確定エラーが5分間で10件を超えた場合」「決済処理のタイムアウトが連続して3件発生した場合」といった具体的なトリガーを、事前に合意しておきます。そうすれば、移行当日に感情的な議論に陥らず、迅速かつ冷静な判断ができます。
また、顧客告知は、移行作業中のメンテナンス告知に加えて、新ECオープン時の「リニューアルのお知らせ」メールやSNS投稿の文案と送信タイミングを、事前に準備しておきます。これにより、移行当日の運用負荷を大幅に軽減できます。
プロジェクト炎上時の「撤退の作法」【競合にない切り口】
EC刷新が炎上すると、多くの発注担当者は「ここまで投資したのだから続けるべきだ」という「サンクコスト効果」に陥りがちです。しかし、回収できない損失が膨らみ続けるなかでプロジェクトを続けるのは、経営上の合理的な判断とはいえません。重要なのは、「撤退の判断基準」と「撤退時の損害を抑える方法」を事前に用意しておくことです。
撤退を検討すべき代表的なシグナルは、当初見積もりの150%以上の追加費用、品質基準を満たすための3回以上のリリース延期、中核担当者（PMやテックリード）の交代です。撤退を決めた場合は、契約書の「中途解約条項」を確認し、既払い費用の返還や未払い費用の精算方法を、弁護士を交えて協議します。
部分的な成果物（設計書・データモデル・画面デザイン）の知的財産権を明確にし、次のベンダーに引き継げる形で確保しておくことが、撤退後の再起動コストを抑えるうえで欠かせません。スルガ銀行と日本IBMの訴訟の教訓が示すように、法廷闘争は双方にとって長期間のコストと労力を要します。撤退は、早く判断するほど損失を限定できるため、炎上時こそ冷静かつ迅速な意思決定が求められます。
▼全体ガイドの記事・EC刷新の完全ガイドもあわせてご覧ください。
▼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を創業。