「ECサイトをリプレイスしたいが、どこにどう発注すればよいのかわからない」「ベンダーに任せきりにして失敗した」という声は、EC担当者やDX推進責任者から頻繁に聞かれます。ECリプレイスは数百万円から数千万円規模の投資になるだけでなく、稼働中のECサイトを止めずに移行するという難易度の高いプロジェクトです。発注の仕方を誤ると、完成物が要件を満たさない、追加費用が膨れ上がる、リリース後も障害が続くといった深刻なトラブルに直結します。

この記事では、ECリプレイスの発注プロセス全体像から、RFP（提案依頼書）の作り方、ベンダーからの見積もりを精査する方法、契約形態の選び方、SLA・ペナルティ条項の設計、そして発注後のプロジェクト管理まで、実務で使える知識を体系的に解説します。契約・法務の観点や、ILUO評価によるフェーズ完了判定など、他のメディアではほとんど触れられていない独自の知見も盛り込んでいますので、これから発注を検討されている方はぜひ最後まで読んでください。

▼全体ガイドの記事
・ECリプレイスの完全ガイド

ECリプレイスの発注プロセス全体像

ECリプレイスの発注は「ベンダーに問い合わせて見積もりをもらう」という単純なものではありません。RFI（情報提供依頼）でベンダーの技術情報を収集し、RFP（提案依頼書）で要件を正式に伝え、提案評価・選定を経て契約を締結するという段階的なプロセスが必要です。このプロセスを省略したり順序を逆にしたりすると、後になって「要件の認識が違った」「追加費用が青天井だった」というトラブルが起きます。

発注プロセスの第一段階はRFI（Request for Information：情報提供依頼）です。RFIでは特定のベンダーに絞らず、広く複数社に対して自社の課題と大まかな要件を伝え、対応可能なプラットフォームや技術スタック、過去の実績、おおよその費用感などを収集します。この段階で3〜5社程度に絞り込むことで、RFP送付の対象が明確になります。

第二段階がRFP（Request for Proposal：提案依頼書）の作成と送付です。RFPは発注側が要件を正式に文書化したもので、ベンダーはこれを読んで具体的な提案書と見積書を作成します。RFPの質がそのまま提案の質に直結するため、「何を・いつまでに・どのレベルで」を明確に記載することが重要です。曖昧なRFPに基づく見積もりは、後から仕様追加の要因になります。

第三段階は提案の評価と選定です。複数のベンダーから受け取った提案書を評価基準に沿って採点し、プレゼンテーションや質疑応答を経て最終候補を絞ります。評価軸は「技術力と実績」「プロジェクト体制」「費用の妥当性」「アフターサポート」「契約の柔軟性」の5つが基本です。第四段階はいよいよ契約締結で、契約形態（請負か準委任か）やSLA・ペナルティ条項の設計が肝心になります。

ECリプレイスの発注先は大きく3種類に分かれます。大手SIerや独立系SIerは、要件定義から設計・開発・テスト・運用保守まで一括して対応できる体制が強みです。ただし、担当するエンジニアのスキルにばらつきがあったり、EC特有の業務知識が薄かったりするケースもあるため、「ECの実案件をどれだけ手掛けてきたか」を必ず確認する必要があります。

EC専門ベンダーはECサイト構築に特化した会社で、ShopifyやECBEING、ecbeingなどの特定プラットフォームに深い知見を持っています。業種・業態に即したテンプレートや導入実績が豊富な反面、プラットフォームの制約の範囲内での開発となるため、大幅なカスタマイズが必要な案件には向かないことがあります。コンサルティング会社（riplaのような企業を含む）は、要件定義・RFP作成・ベンダー選定の支援から開発まで一気通貫で対応できる点が強みで、発注側が初めてのリプレイスで何から始めればよいかわからない場合や、ベンダーコントロールに不安がある場合に特に有効です。

EC向けRFPの書き方：ベンダーから良い提案を引き出すコツ

ECリプレイスのRFPは、一般的なシステム開発のRFPよりも記載すべき要素が多くなります。決済・物流・在庫管理・会員管理・SEOなど、ECならではの要件を漏れなく盛り込まなければ、後から「この機能は見積もりに含まれていない」と言われる原因になります。RFPの精度がプロジェクト成否の大きな鍵を握っています。

EC向けRFPの骨格は以下の構成で作成することを推奨します。まず「プロジェクトの背景と目的」では、現行ECシステムの課題（保守切れ、表示速度の問題、受注数の上限など）と、リプレイス後に達成したいゴール（売上目標、UX改善、管理工数の削減など）を数値を交えて記載します。次に「機能要件」として、商品管理・カート・受注管理・顧客管理・ポイント・クーポン・レコメンドなどの要件を一覧化します。

競合が見落としがちな「非機能要件」は必ず明記してください。具体的には、ピーク時の同時接続数（例：セール時に5000件/秒）、ページ表示速度（LCP 2.5秒以内）、稼働率（99.9%以上）、セキュリティ基準（PCI DSS準拠の有無）などです。「SEO要件」もEC特有の重要項目で、URLの構造設計、構造化データの対応（商品レビューのリッチスニペット等）、Core Web Vitalsスコアの目標値を記載します。「決済要件」では対応すべき決済手段（クレジットカード・コンビニ・後払い・BNPL等）とPCI DSSへの対応方針を明確にします。

RFPの最大の落とし穴は「なるべく早く」「使いやすく」「高速で」のような抽象的な表現です。ベンダーはこれを自由に解釈して見積もりを作るため、完成後に「こんなものだと思っていなかった」という認識のズレが生まれます。「なるべく早く」ではなく「ページ読み込み時間は3秒以内（LCP基準）」、「使いやすく」ではなく「購入完了までのステップを現行の5ステップから3ステップに削減」というように、定量的かつ検証可能な表現に変換することが重要です。

また、現行システムの機能一覧を「As-Is（現状）」として整理し、新システムで「To-Be（あるべき姿）」に変更する箇所を明確にすることで、ベンダーが「何が変わるのか」を正確に把握できます。移行すべきデータの種類と件数（商品マスタ何件、会員データ何件、受注履歴何年分など）もこの段階で確定させておかないと、データ移行コストの見積もりが大幅にブレる原因になります。

RFPを送付した後に「やっぱりこの機能も欲しい」という要件追加が頻発するケースがあります。これはベンダーにとって追加見積もりの機会となり、最終的な費用が青天井になる原因です。対策として、RFP送付後の一定期間（例：提案提出締め切りの1週間前まで）は質疑応答のみ受け付け、要件の追加・変更は原則禁止とする「フリーズ・ポリシー」を明文化してRFPに記載しておくことを推奨します。どうしても変更が必要な場合は、全ベンダーに同時に変更通知を発行して公平性を保ちます。

見積もりの精査と相見積もりの比較方法

複数のベンダーから見積もりを受け取ったとき、単純に金額の高低だけで判断してはいけません。見積もりには「何が含まれているか」に大きな差があり、安い見積もりほど後から追加費用が発生しやすい傾向があります。正しい比較方法を知ることで、見かけ上の金額に惑わされずに本当のコストを見抜けるようになります。

第一に「工程の明細化」を確認します。良い見積もりは要件定義・設計・開発・テスト・データ移行・運用保守それぞれの工数と単価が明示されています。一方、「EC構築一式〇〇円」のような一括見積もりは、内訳が不明なため比較・交渉が困難です。一般的な費用比率の目安は、開発・実装が全体の50〜60%、要件定義が10〜15%、設計が10〜25%、テストが5〜10%、運用保守が15〜20%とされており、これと大きく乖離する項目があれば理由を聞くべきです。

第二に「見積もりの前提条件」を確認します。要件定義の精度によって見積もりは大きく変動します。「超概算（±50%）」「概算（±30%）」「確定見積もり（±10%）」という3段階の精度があり、どの段階の見積もりなのかを明確にしてもらうことが必要です。第三は「データ移行コスト」の有無です。商品マスタや会員データの移行・クレンジング費用が別途発生することが多く、見積もりに含まれているかを必ず確認してください。第四は「ライセンス・月額費用」の扱いです。ShopifyやECパッケージの月額利用料、決済手数料、CDN費用などの継続コストが含まれているかをランニングコストの観点で精査します。第五は「保守・サポート費用」の設定内容です。カットオーバー後の問い合わせ対応やバグ修正をどこまで無償で行うか、月額保守費用はいくらかを確認します。

相見積もりで金額に2倍以上の差がある場合、単純に「安い方を選ぶ」のは危険です。安い見積もりが出る主な理由は3つあります。一つ目は「要件の読み飛ばし」で、非機能要件や決済連携など複雑な部分を見積もりから除外しているケースです。二つ目は「後から追加費用を取る前提」で、初期見積もりを低く抑えて受注し、追加仕様として費用を積み増す商慣行です。三つ目は「リソース不足や技術力の問題」で、実際には対応できないにもかかわらず安価に見積もってしまうケースです。

判断の基準として、安価な見積もりを出したベンダーに対して「この金額で何が含まれていて何が含まれていないか」を文書で回答してもらうことが有効です。また、類似規模のEC構築・移行実績を具体的に3件以上示してもらうことで、技術力と実績の有無を確認できます。プレゼン力が高く見積もりが安いからといって、安易に選定することは後の大きなリスクを招きます。

契約の落とし穴と法務的注意点

ECリプレイスの発注で最もトラブルが起きやすいのが契約フェーズです。「言った・言わない」の水掛け論、想定外の追加費用、ベンダーの責任逃れ——これらのほとんどは、契約時に適切な取り決めをしていなかったことに起因します。契約書は単なる形式ではなく、プロジェクトを守る「武器」として機能させる必要があります。

請負契約は「成果物の完成」を目的とした契約で、ベンダーは定められた仕様通りの成果物を納品する責任を負います。もし成果物に不具合があれば、ベンダーは無償で修正する義務（契約不適合責任）があり、発注者としては成果物の品質を担保しやすいというメリットがあります。一方で、要件が変わったり仕様が追加されたりするたびに変更契約が必要になり、ECリプレイスのように要件が途中で変化しやすいプロジェクトでは管理コストが高くなる側面があります。

準委任契約は「業務の遂行（プロセス）」に対して対価を払う契約で、成果物の完成責任はベンダーにありません。柔軟に要件変更や追加に対応できる反面、「どこまで進んだか」を発注者が自ら管理しなければ、コストが際限なく膨らむリスクがあります。ECリプレイスでは、要件定義・基本設計フェーズは準委任、開発・テストフェーズは請負という「ハイブリッド型」が実務上有効です。要件が固まっていない初期段階を請負にすると、後から「仕様変更による追加費用」が多発する原因になります。どちらの契約形態を選ぶにせよ、「フェーズ完了の定義」を契約書に明記することが不可欠です。

ECリプレイスの発注において、取引先（ベンダー）が一定規模以下の中小企業である場合、下請代金支払遅延等防止法（下請法）が適用されます。下請法が適用される主な条件は、資本金3億円超の親事業者が資本金3億円以下の下請事業者に業務を委託する場合です。情報サービス業のシステム開発は下請法の「情報成果物作成委託」に該当し、適用される可能性があります。

下請法で最も重要なルールは「60日ルール」です。役務の提供を受けた日から60日以内に代金の支払期日を設定し、その全額を支払う必要があります。60日を超えた場合は年14.6%の遅延利息が発生します。また、「買いたたき（一方的な値下げ要求）」「発注後の不当な追加作業の要求」「手形払いによる実質的な支払い遅延」なども禁止されています。発注側の担当者がこれらを知らずに行うと、下請法違反として公正取引委員会から勧告を受けるリスクがありますので注意が必要です。

SLA（Service Level Agreement：サービスレベル合意）は、システムの品質・性能・稼働率の最低保証水準をベンダーと合意する文書です。ECサイトは24時間365日の稼働が前提で、1時間のダウンタイムが数百万円規模の機会損失につながるケースもあるため、SLAは「努力目標」ではなく「ペナルティ付きの契約条項」として設計することが重要です。

EC向けSLAで定めるべき主な指標は以下のとおりです。「稼働率」は最低99.9%（月間ダウンタイム44分以内）を目安として設定し、セール期間中はさらに高い水準を要求することが多いです。「決済成功率」はECサイト特有の指標で、99.5%以上を基準とし、これを下回った場合の月額利用料の減額条件を明記します。「ページ表示速度」はLCPを2.5秒以内とし、超過が続く場合の対応義務を設けます。ペナルティの設計は「利用料金の何%を減額するか」という形式が一般的で、SLA未達が月に1回なら10%、3回以上なら30%などと段階的に設定するケースが多く見られます。ただし、ベンダー側の免責条件（サイバー攻撃や自然災害等）も合わせて確認し、双方が公平と感じる水準で合意することが長期的な関係構築に重要です。

発注後のプロジェクト管理：ベンダーコントロールの実践

発注が完了したら、それでプロジェクトが回り始めるわけではありません。「ベンダーに任せておけばいい」という発注側の姿勢こそが、ECリプレイス失敗の最大の原因の一つです。発注後は発注者自身がプロジェクトの「主体者」として積極的に関与し、進捗の把握、問題の早期発見、リスク対応の意思決定を行う必要があります。

「フェーズ完了」の判断は通常、ベンダーが「〇〇が完成しました」と報告するタイミングで行われますが、これだけでは発注側の担当者が実際にシステムを使えるかどうかが確認できません。そこで推奨しているのが「ILUO（アイルオ）評価」をフェーズ完了判定に導入する方法です。ILUOとはトヨタ生産方式で活用されるスキル評価フレームワークで、I（見て理解できる）・L（補助があればできる）・U（一人でできる）・O（他者を指導できる）の4段階でスキルを評価します。

ECリプレイスのフェーズ完了判定では、発注側の担当者（検収担当者）が新システムの対象機能について「U（一人で操作できる）」に達していることを条件にします。具体的には、受注管理・商品登録・顧客対応・レポート確認などの主要業務を、マニュアルなしで一人で操作できるか実際に確認します。これにより「納品はされたが使えない」という事態を防ぎ、現場定着の前提条件を担保できます。

ECリプレイスでは、要件定義の進行や非機能要件の詳細化に伴い、当初見積もりより費用が増加することが構造的に起こりえます。これは見積もりが「超概算→概算→確定」と段階的に精度が高まる性質を持つからです。予算超過が発生した際に大切なのは、「なぜ増えたのか」を原因別に分解して経営陣に説明することです。

説明のフレームワークとして「要件の明確化による増加（やむを得ないもの）」「スコープ追加による増加（発注者側の意思決定による追加）」「見積もりの精度不足（ベンダー側に責任があるもの）」の3つに分類し、それぞれの金額を示すと経営陣に納得を得やすくなります。追加予算を申請する際は、「追加しなかった場合のリスクとコスト（EC停止や機会損失）」を定量的に示すことが有効です。EC停止1時間当たりの損失額（例：時間あたり売上×機会損失率）を算出し、追加投資によってそのリスクを回避できることを説明します。

プロジェクトが深刻なトラブルに陥ったとき、「ここまで費用と時間を投資したのだから続けるしかない」というサンクコスト（埋没費用）の罠に陥ることがあります。しかしECリプレイスにおいては、問題のあるプロジェクトを継続することによる損害（現行ECサイトの機会損失の継続、追加費用の積み重ね、組織の疲弊）が、損切りコストを上回るケースは少なくありません。

損切りを判断すべき主なシグナルは3つです。「プロジェクトの遅延が当初工期の50%を超えている」「追加費用が当初予算の30%を超え、かつ収束の見通しがない」「ベンダーとの信頼関係が修復不可能な水準に達している」という状況が重なる場合、損切りを真剣に検討する必要があります。損切りを判断した場合は、投入済みコストを回収するための法的手段（契約不適合責任の追及等）と並行して、代替ベンダーへの移行計画を策定します。感情的に継続を選ぶのではなく、「現時点から見た将来のトータルコスト」で意思決定することが経営的に正しいアプローチです。

まとめ：ECリプレイスの発注を成功させる5つの鉄則

ECリプレイスの発注は、「安いベンダーに任せる」ではなく「発注側が主体となってプロジェクトをコントロールする」という姿勢が成否を左右します。この記事で解説した内容を整理すると、成功のための5つの鉄則が見えてきます。

第一に、RFPにEC特有の要件（非機能要件・SEO要件・決済要件）を具体的な数値で記載することです。曖昧なRFPは曖昧な提案を生み、後の追加費用トラブルの温床となります。第二に、見積もりは金額だけでなく「何が含まれているか」の中身で比較することです。安すぎる見積もりには必ず理由があります。第三に、契約形態（請負・準委任）をフェーズの特性に合わせて選択し、下請法の義務を正しく把握することです。第四に、SLAをECサイト特有の指標（稼働率・決済成功率）で設計し、ペナルティ条項を明文化することです。第五に、発注後も「ILUO評価」などの独自基準を使ってフェーズ完了を厳格に検収し、問題が深刻化する前に早期に介入することです。

ECリプレイスは複雑なプロジェクトですが、適切な発注プロセスと契約設計、そして発注後の主体的な関与によって成功確率を大幅に高めることができます。riplaでは、RFP作成の支援からベンダー選定・プロジェクト管理・カットオーバー後の定着支援まで一気通貫でサポートしています。まずはお気軽にご相談ください。

▼全体ガイドの記事
・ECリプレイスの完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。