EC更改の発注・外注は、発注前の準備からベンダー選定、契約、発注後の管理と障害対応まで、順を追って進めます。
EC更改には、数万件から数百万件の商品・顧客・受注データの移行やSEO評価の引き継ぎなど、ECサイト特有の要件が多くあります。ベンダー選定を誤ると、リリース後に受注システムが止まり、売上がゼロになるおそれもあります。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
EC更改の発注前の準備
EC更改を外注する前に発注側が行う準備は、大きく「データ移行要件の洗い出し」と「現行ECの課題分析・要件定義」の2つにまとまります。
この準備をおろそかにすると、後工程でベンダーへの指示が曖昧になり、追加費用や工期遅延を招きます。発注前の準備に費やした時間は、プロジェクト全体のリスクを大幅に下げる投資だと考えてください。
データ移行要件（商品・顧客・受注・SEO）の棚卸しと整理
EC更改で最もリスクが高い工程のひとつが、データ移行です。一般的なシステム移行と異なり、ECサイトは商品マスタ・顧客マスタ・受注履歴・在庫データという4種類の基幹データを同時に引き継ぐ必要があります。さらに、長年の運用で積み上げてきたSEO評価の引き継ぎも必須です。
データ移行要件の洗い出しでは、まず現行システムのデータ件数と品質を把握します。商品データは「件数・画像枚数・属性項目数・バリエーション構造」、顧客データは「会員数・購入履歴・ポイント残高・メルマガ配信設定」などを整理します。受注データは「過去何年分を移行するか」「注文ステータスの変換ルールはどうするか」を事前に決めておく必要があります。
URLが変わると評価がリセットされ、リリース直後にオーガニック流入が激減するケースが後を絶ちません。そこで、旧URLと新URLの対応表（URLマッピング）を事前に作り、301リダイレクト設計をRFPに含めることが不可欠です。これらを発注前に終えておくと、ベンダーが見積もりを出しやすくなり、「移行対象データが多かった」と後から追加費用を請求されるリスクを抑えられます。
現行ECの課題分析と更改後の要件定義
要件定義の出発点は、「なぜ今のECを更改するのか」という問いに明確に答えられることです。よくある更改理由には、「現行プラットフォームのサポート終了」「拡張性の限界（プラグイン競合・パフォーマンス劣化）」「競合に比べてUI/UXが古い」「売上拡大に伴う機能追加の限界」などがあります。
これらの課題を具体的に言語化しないまま発注すると、ベンダーは「旧機能を新環境に移植するだけ」という最小限の対応に留め、同じ課題を抱えた新サイトが生まれてしまいます。そのため要件定義では、「As-Is（現状）」と「To-Be（あるべき姿）」を対比して整理するのが効果的です。要件定義書の完成度が高いほど、比較可能な見積もりを取りやすくなり、ベンダー選定の精度も上がります。
たとえば「現状はカゴ落ちメールが手動対応で月20時間かかっている」→「更改後は自動配信で0時間にする」といった具体的な記述が理想的です。また、更改後に追加したい機能（定期購入・ポイントシステム・レコメンデーション・法人向け受注管理など）の優先度は、MoSCoW法（Must・Should・Could・Won’t）で整理しておきます。そうしておけば、ベンダーとの認識齟齬を防げます。
RFI・RFPの作成方法と実践テンプレート
ベンダー選定を正確に行うには、RFI（情報提供依頼書）とRFP（提案依頼書）を段階的に使うことが大切です。RFIで複数のベンダーから基本情報を集め、その結果をもとに本命候補を絞り込んでからRFPを発行するのが効率的な流れです。
EC更改特有の要件を盛り込んだRFI・RFPを作成すると、「データ移行経験のないベンダー」や「SEO引き継ぎの重要性を理解していないベンダー」を早期に除外できます。
EC更改特有のRFI項目（データ移行実績・SEO引き継ぎ実績確認）
RFIでは、まずベンダーの基本スペックを確認します。EC更改では、システム会社向けの一般的な項目に加えて、データ移行とSEO引き継ぎの実績を確かめることが欠かせません。データ移行実績については「過去3年間のEC移行案件数」「最大移行データ件数（商品・受注）」「移行後のデータ整合性確認方法」を必ず質問してください。
移行案件の経験がなければ、どれだけ技術力があっても本番移行時に手戻りが発生するリスクが高まります。SEO引き継ぎ実績については「リプレイス後のオーガニック流入維持率」を具体的な数値で提示してもらうことが有効です。優良なベンダーであれば「リプレイス前後6ヶ月での流入比較データ」を保有しているはずです。
また、「利用可能なECプラットフォーム一覧（Shopify・EC-CUBE・Magento・SalesforceCommerce Cloudなど）」や「フルスクラッチ開発の可否」もRFIで確認しておきます。「保守運用体制（月次報告有無・SLA設定の可否）」も加えておくと、提案書審査の段階で比較の材料になります。
RFPに盛り込むべき必須項目と書き方のコツ
RFPはベンダーへの発注仕様書で、後から「そんな要件は聞いていない」という紛争を防ぐ役割を持ちます。EC更改のRFPには、最低限次の内容を盛り込みます。
- プロジェクト概要と現行システム：背景、プラットフォーム、月間流量、商品点数、顧客数
- 機能・非機能要件：継続・追加機能、表示速度、同時接続数、セキュリティ基準
- データ移行とSEO引き継ぎ：対象、件数、方式、URLマッピング、リダイレクト、構造化データ
- スケジュール要件：希望リリース日とマイルストーン
- 提案書の条件：記載形式と提出期限
書き方のコツとして、「要件は動詞＋名詞＋品質基準」の形式で記述することを推奨します。たとえば「商品ページを表示できること」では曖昧なため、「商品詳細ページを3秒以内に表示できること（Google PageSpeed Insightのモバイルスコア60点以上）」と具体化します。そうすると、ベンダーは明確な回答を示さざるを得なくなります。
「現行機能と同等のもの」という表現は避けてください。「同等」の解釈はベンダーによってまったく異なるため、機能を一つずつ列挙して確認を取ることが大切です。
予算の記載の是非と発注側の駆け引き
RFPに予算を明示すべきかは、発注担当者の間でも意見が分かれるテーマです。「透明性のためにオープンにすべき」という考え方と、「予算を見せるとベンダーがその上限に合わせて価格を設定する」という懸念が対立しています。
実務的には、予算を示すとベンダーは、その範囲で何ができるかを考えて要件の優先度を有利に解釈しがちです。その結果、本来実現したかった機能が「予算超過」を理由にスコープアウトされるケースが起きます。そのため、予算は明示せずに提案を求め、集まった見積もりの分布を確かめてから交渉に臨むのが有効です。
もし予算感を伝えたい場合は、「概算予算：500万〜1000万円」のように幅を持たせ、上限は明示しないことが大切です。ただし、予算が著しく少ない場合（たとえば実際の相場が3000万円の案件で予算が500万円など）は、現実的な提案が集まりにくくなります。その場合は、ある程度の予算感を共有して時間を無駄にしないことも、誠実な発注姿勢です。
ベンダー提案の評価・比較手法
複数のベンダーから提案書が揃ったら、いよいよ評価・比較の段階に入ります。EC更改のベンダー評価では、「安い・早い・かっこいい提案書」という表面的な印象より、「EC特有の課題を本当に理解しているか」という実力を多角的に評価する仕組みが求められます。
評価は「定量評価（スコアリング）」と「定性評価」を組み合わせることで、客観性と深さを両立させられます。
定量評価（スコアリングシート）の設計方法
スコアリングシートは、評価項目・配点・評価基準をあらかじめ設計し、全ベンダーに同一の基準で適用する評価ツールです。EC更改案件では、「技術提案の妥当性（30点）」「EC更改実績・データ移行実績（25点）」「費用の妥当性と透明性（20点）」を配点の中心にします。残りは「プロジェクト管理体制（15点）」と「保守運用サポート体制（10点）」です。
各項目は「1〜5点」の5段階で付け、複数の評価担当者（経営・IT部門・現場担当）が独立して採点したのちに平均を取ります。これにより、個人的な印象による偏りを排除できます。スコアリングシートを選定前に関係者で合意しておくと、選定後も「なぜそのベンダーになったのか」を透明性を持って説明できます。
特に「費用の妥当性と透明性」では、単純な安さではなく、費用の内訳と、追加費用が発生するシナリオが明示されているかを重視してください。安さだけで選ぶと、後から要件漏れを理由に追加費用を請求されるケースが多く、最終的にコスト高になるおそれがあります。
データ移行・SEO引き継ぎ実績の定性評価方法
スコアリングだけでは評価しきれない「実績の深さ」や「担当者の理解度」は、定性評価で測る必要があります。特にEC更改では、データ移行とSEO引き継ぎの2つの実績を深掘りすることが大切です。提案書に「EC移行実績あり」と書かれていても、実際にどのような規模・難易度の案件だったかは千差万別です。
定性評価の場として、提案書審査後に候補を2〜3社に絞り、プレゼンテーション審査（いわゆる「コンペ」）を行うことを推奨します。その場では、「過去のEC移行案件で発生した最大のトラブルとその対応方法」を説明してもらうのが非常に有効です。優良なベンダーは失敗経験を包み隠さず対策まで語れますが、経験の浅いベンダーは事例がないか、あっても曖昧な説明に終わります。
SEO引き継ぎについては、「リプレイス前後のオーガニック流入データ（Googleサーチコンソールのスクリーンショットなど）」の提示を求めると、実績の真偽を確認できます。また、データ移行の進め方として「並行稼働期間はどれくらい設けるか」「移行前後のデータ整合性チェックはどのように行うか」を具体的に説明できるかも、実力を見る指標になります。
同点時の最終判断基準
スコアリングと定性評価を経ても同点・僅差が残ることがあります。その際に実務的に有効なのは、「担当者との相性・信頼性」と「リスク対応方針の明確さ」の2点です。EC更改プロジェクトは平均で6〜18ヶ月に及ぶ長期プロジェクトで、その間に想定外のトラブルや要件変更が必ず発生します。そのような局面で誠実に対応してくれるパートナーかを見極めることが、最終選定では特に大切です。
「リスク対応方針の明確さ」は、提案書やプレゼンテーションで「リスク一覧と対応方針」を示しているかで見極めます。リスクを一切示さない提案書は、一見前向きでも、リスクを把握できていないか隠している可能性があります。反対に、リスクを正直に列挙し「このリスクにはこの対策を取る」と示す提案書は、実務経験の豊かさと誠実さを表しています。
最終的には「このベンダーと長期的にパートナーシップを結べるか」という視点で判断することが、EC更改成功の鍵となります。
契約締結時のリスクヘッジ
ベンダーを選定したら、次は契約締結です。EC更改プロジェクトの契約は、後になってトラブルが発生したときに発注側を守る役割を果たします。口頭合意や曖昧な文言が残る契約書は、紛争が起きたときに百害あって一利なしです。
「契約書のチェックは法務部門の仕事」と考える担当者も多いですが、EC特有のリスクポイントは、担当者自身が理解して契約書に盛り込むことが大切です。
ソースコード所有権・SLA・契約形態の取り決め
ECサイトの更改では、ソースコード所有権が特に重要な契約条項です。受託開発のソースコードの著作権は、契約で明示的に移転しない限り開発会社（受託者）に帰属します。これは、開発後の乗り換えや自社改修時に、ライセンス料の請求や改修拒否を受けるリスクを意味します。
EC更改の契約書には、「開発成果物（ソースコード・設計書・テスト仕様書を含む一切の著作物）の著作権は代金完済をもって発注者に移転する」条項を盛り込みます。SLAでは、「稼働率」だけでなく「障害時の応答時間」と「復旧時間」を明記することが大切です。たとえば「稼働率99.9%以上」「障害発生から1時間以内に一次回答」「24時間以内に暫定対応完了」「72時間以内に根本対応完了」と、数値で取り付けます。
特に繁忙期（年末年始・セール期間）の対応体制を別途記載しておくことで、最も売上が集中する時期のリスクを軽減できます。契約形態は、「請負契約」と「準委任契約」のどちらを採用するかも決めておく必要があります。開発フェーズは成果物責任が明確な請負契約、保守運用フェーズは作業量に応じた準委任契約が一般的です。
契約不適合責任・遅延損害金の取り決め
2020年の民法改正で、従来の「瑕疵担保責任」は「契約不適合責任」へと名称・内容が変わりました。契約不適合責任とは、納品物が契約の内容に適合しない場合（バグ・機能欠陥・仕様漏れなど）に、発注側が修補請求・代金減額請求・損害賠償請求・契約解除を行える権利です。ただし、契約不適合責任の追及には「不適合を知った時から1年以内に通知する」という期間制限があります。
そのため、リリース後1年間は定期的に動作確認を行い、不具合を見逃さない体制を整えることが欠かせません。また、遅延損害金は、ベンダーが契約上のリリース日を守れなかった場合に発注側が請求できる損害賠償です。EC更改ではリリース遅延が深刻で、シーズンセールに向けたサイトが遅れると、数千万円規模の機会損失が発生する場合もあります。
遅延損害金の額は「1日あたり契約金額の0.1〜0.3%」が相場ですが、額の多寡より、「遅延への抑止効果」と「遅延が発生した場合の迅速なエスカレーション体制」を契約書に明記することが実務的に大切です。なお、遅延損害金を請求できるのは「受注者の責に帰すべき事由による遅延」に限られ、発注側の仕様変更や意思決定の遅れによる遅延は除外されます。除外される点も認識しておきましょう。
ベンダーロックイン防止条項
ベンダーロックインとは、特定のベンダーに依存した技術・仕様・ライセンス体系が採用されることで、乗り換えコストが膨大になり、実質的に同じベンダーを使い続けざるを得ない状態です。EC更改では、プロプライエタリ（独自仕様）のフレームワークや独自カスタマイズを多用するベンダーが、ロックインリスクを高める傾向があります。
また、クラウド型ECプラットフォームでも、ベンダーが独自拡張機能に強く依存した設計を行うと、プラットフォーム乗り換え時に莫大なデータ移行コストが発生します。ロックインを防ぐ条項としては、まず「ソースコードおよび設計書の完全引き渡し義務」（前述）に加えて、「第三者による保守・改修の制限禁止」「解約時のデータポータビリティ保証」を盛り込むことが欠かせません。
「第三者による保守・改修の制限禁止」とは、発注者が別の会社に保守を依頼することをベンダーが妨害できないという条項です。「ソースコードの難読化・秘密化の禁止」も合わせて規定すると、実効性が増します。解約時のデータポータビリティ保証では、「解約から30日以内に全データをCSV・JSONなど汎用フォーマットで引き渡す」義務を課すことで、将来の乗り換えコストを大幅に減らせます。
発注後のプロジェクト管理と障害対応
発注・契約が完了したあとは、いよいよプロジェクトの推進フェーズです。発注者もベンダーとともに、適切なプロジェクト管理で品質・スケジュール・コストの三角形を保つ役割を担います。
特に本番リリース後に発生する障害への対応方針を事前に合意しておくことは、ECサイトという「止まれない」システムを運用するうえで欠かせません。
暫定対応（業務継続優先）と根本対応（バグ修正）の2段階フロー
EC更改リリース後の本番障害では、まず「暫定対応（業務継続優先）」で応急処置を施してサービスを継続させ、その後「根本対応（プログラム修正）」で原因を根本から解決する「2段階フロー」が基本です。ECサイトは1分1秒の停止が売上に直結するため、「完璧な修正」を待って何時間もサイトを止め続けることは現実的ではありません。
暫定対応の具体例として、決済エラーなら該当の決済手段を一時的に非表示にして他の決済手段での購入を継続させ、特定商品ページが表示エラーなら、その商品を一時的に非公開にします。カート機能に不具合があれば、電話注文に誘導するバナーを設置するなど、影響範囲を最小化しながら業務を継続させます。
この暫定対応の手順は、本番リリース前に「障害対応マニュアル」として事前に作成し、ベンダーと発注者の双方で合意しておくことが大切です。根本対応は、障害の深刻度（Severity）に応じて「S1（全面停止）：24時間以内」「S2（機能停止）：72時間以内」「S3（軽微な不具合）：次回定期メンテナンス時」などの期限を、契約書またはSLAに明記します。
EC更改リリース後の初期流動管理（受注急増への対応）
大型セールや新商品ローンチと合わせてEC更改をリリースするケースでは、リリース直後に想定を超えるアクセス・受注が集中することがあります。負荷テストで想定した最大同時接続数を超えると、サーバーが応答しなくなり、カートが使えない状態が続いて機会損失が発生します。
そのため、「初期流動管理」として、リリース後2〜4週間を「集中監視期間」と定め、ベンダーのインフラ担当者が24時間体制で監視する形が理想的です。監視すべき指標は「サーバーCPU使用率・メモリ使用率・レスポンスタイム・エラーレート」で、閾値を設定して超えた時点で自動アラートが発報される体制を作ります。
また、アクセス集中への対応として「オートスケーリング（アクセス増加に応じてサーバーを自動増設）」の設定を事前に済ませておくことも有効です。受注処理では「受注確認メールの遅延」「在庫管理のタイムラグ」が初期流動期に多発するため、これらの非機能要件もリリース前の最終確認としてチェックリストに含めることを推奨します。
まとめ
EC更改の発注・外注・委託を成功させるには、「良いベンダーを探す」以上の準備と知識が必要です。本記事で解説したとおり、まず発注前にデータ移行要件（商品・顧客・受注・SEO）の洗い出しと要件定義を徹底することが、後工程のトラブルを防ぐ最大の投資になります。
RFI・RFPでは、EC特有のデータ移行実績やSEO引き継ぎ実績を問うことで、実力のある会社を早期に絞り込めます。予算は上限を明示せずに複数社の見積もりを比べてから交渉に臨むと、発注側の交渉力を高められます。
ベンダー評価では、定量スコアリングと定性評価（プレゼン・実績確認）を組み合わせることで、提案の上手さより実務的な実力を見抜けます。契約では、ソースコード所有権・SLA・契約不適合責任・遅延損害金・ベンダーロックイン防止条項を丁寧に盛り込み、将来のトラブルから発注者を守ります。
そして発注後は、暫定対応と根本対応の2段階フローを事前に合意したうえで、リリース後の初期流動管理に力を入れることが、安定したEC更改完了への最後のカギです。EC更改は簡単なプロジェクトではありませんが、この記事で紹介したステップを一つひとつ実践すれば、リスクを抑えながら成功へ導けます。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・EC更改の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・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を創業。