ECリプレイスの発注は、情報収集から要件の提示、提案の評価、契約まで段階を追って進めます。
ECリプレイスは数百万円から数千万円規模の投資で、稼働中のECサイトを止めずに移行する必要があります。
▼全体ガイドの記事
・ECリプレイスの完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
ECリプレイスの発注プロセス全体像
ECリプレイスの発注は、「ベンダーに問い合わせて見積もりをもらう」という単純なものではありません。RFI（情報提供依頼）でベンダーの技術情報を集め、RFP（提案依頼書）で要件を正式に伝え、提案の評価と選定を経て契約を締結する、段階的なプロセスが必要です。
段階を省略したり、順序を逆にしたりすると、後で「要件の認識が違った」「追加費用が青天井だった」といったトラブルにつながります。そこで、RFIからRFP、評価、契約までの4段階を、この順で進めます。
- ステップ1：RFIによる技術情報の収集
- ステップ2：RFPによる要件の正式な提示
- ステップ3：提案の評価と発注先の選定
- ステップ4：契約内容の確認と締結
RFI → RFP → 評価・選定 → 契約の4ステップ
第一段階のRFI（Request for Information：情報提供依頼）では、特定のベンダーに絞らず、複数社に自社の課題と大まかな要件を伝えます。そのうえで、対応可能なプラットフォームや技術スタック、過去の実績、おおよその費用感などを集め、3〜5社程度に絞り込むと、RFPを送る相手が明確になります。
第二段階は、RFP（Request for Proposal：提案依頼書）の作成と送付です。RFPは発注側が要件を正式に文書化したもので、ベンダーはこれを読んで具体的な提案書と見積書を作ります。RFPの質は提案の質に直結するため、「何を・いつまでに・どのレベルで」を明確に書くことが大切で、曖昧なRFPに基づく見積もりは後から仕様追加の要因になります。
第三段階は提案の評価と選定で、提案書を採点し、プレゼンテーションや質疑応答を経て最終候補を絞ります。評価軸は「技術力と実績」「プロジェクト体制」「費用の妥当性」「アフターサポート」「契約の柔軟性」の5つが基本です。第四段階は契約締結で、契約形態（請負か準委任か）とSLA・ペナルティ条項の設計に注意が必要です。
発注先の種類と特徴：SIer・EC専門ベンダー・コンサルの違い
ECリプレイスの発注先は大きく3種類に分かれます。大手SIerや独立系SIerは、要件定義から設計・開発・テスト・運用保守まで一括して対応できる体制が強みです。ただし、エンジニアのスキルにばらつきがあったり、EC特有の業務知識が薄かったりするケースもあるため、「ECの実案件をどれだけ手掛けてきたか」を必ず確認する必要があります。
EC専門ベンダーは、ECサイト構築に特化した会社で、ShopifyやECBEING、ecbeingといった特定プラットフォームに深い知見を持っています。業種・業態に即したテンプレートや導入実績が豊富です。その反面、プラットフォームの制約の範囲内での開発となるため、大幅なカスタマイズが必要な案件には向かないことがあります。
コンサルティング会社（riplaのような企業を含む）は、要件定義・RFP作成・ベンダー選定の支援から開発まで一気通貫で対応できる点が強みです。発注側が初めてのリプレイスで何から始めればよいか分からない場合や、ベンダーコントロールに不安がある場合に、特に有効です。
EC向けRFPの書き方：ベンダーから良い提案を引き出すコツ
ECリプレイスのRFPは、一般的なシステム開発のRFPより記載すべき要素が多くなります。決済・物流・在庫管理などのECならではの要件に加え、会員管理やSEOも漏れなく盛り込む必要があります。
要件を漏らしたまま見積もりを取ると、後から「この機能は見積もりに含まれていない」と言われる原因になります。RFPの精度は、プロジェクトの成否を左右する大きな要因です。
RFPに記載すべき必須項目：機能要件・非機能要件・SEO要件・決済要件
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を送った後に「やっぱりこの機能も欲しい」という要件追加が頻発することがあります。これはベンダーにとって追加見積もりの機会となり、最終的な費用が青天井になる原因です。
対策として、RFP送付後の一定期間（例：提案提出締め切りの1週間前まで）は、質疑応答のみを受け付けます。要件の追加・変更は原則として禁止する「フリーズ・ポリシー」を、RFPに明文化しておくことを勧めます。どうしても変更が必要な場合は、全ベンダーに同時に変更通知を出して公平性を保ちます。
見積もりの精査と相見積もりの比較方法
複数のベンダーから見積もりを受け取ったら、金額の高低より「何が含まれているか」を見て比べることが大切です。見積もりごとに含まれる内容には大きな差があり、安い見積もりほど後から追加費用が発生しやすい傾向があります。
正しい比較方法を知っておくと、見かけの金額に惑わされずに本当のコストを見抜けるようになります。
見積もりの妥当性を判断する5つのチェックポイント
見積もりの中身は、次の5点で判断します。
- 工程ごとの明細：「EC構築一式〇〇円」のような一括見積もりは比較・交渉が難しいため、工数と単価が工程ごとに示されているかを見ます。
- 前提条件の確認：「超概算（±50%）」「概算（±30%）」「確定見積もり（±10%）」のどの段階の見積もりかを、ベンダーに明確にしてもらいます。
- 移行・クレンジング費用：商品マスタや会員データの移行費用は別途発生することが多いため、見積もりに含まれているかを必ず確かめます。
- ライセンス・月額費用：ShopifyやECパッケージの月額利用料、決済手数料、CDN費用などの継続コストが、見積もりに入っているか。
- 保守・サポート費用：カットオーバー後の問い合わせ対応やバグ修正をどこまで無償で行うか、月額保守費用はいくらか。
また、見積もりの金額は要件定義の精度によって大きく変動します。
工程ごとの内訳を見るときの目安は、開発・実装が50〜60%、要件定義が10〜15%、設計が10〜25%、テストが5〜10%、運用保守が15〜20%とされます。これと大きく違う項目があれば、理由を聞くべきです。
金額差が大きい場合の見極め方：安すぎる見積もりの罠
相見積もりで金額に2倍以上の差がある場合、安い方をそのまま選ぶのは危険です。安い見積もりが出る主な理由は3つあります。
一つ目は「要件の読み飛ばし」で、非機能要件や決済連携など複雑な部分を見積もりから外しているケースです。二つ目は「後から追加費用を取る前提」で、初期見積もりを低く抑えて受注し、追加仕様として費用を積み増す商慣行です。三つ目は「リソース不足や技術力の問題」で、実際には対応できないのに安価に見積もってしまうケースです。
判断の基準として、安価な見積もりを出したベンダーには、「この金額で何が含まれ、何が含まれていないか」を文書で回答してもらうことが有効です。また、類似規模のEC構築・移行実績を具体的に3件以上示してもらうと、技術力と実績の有無を確かめられます。プレゼン力が高く見積もりが安いからといって安易に選定すると、後の大きなリスクを招きます。
契約の落とし穴と法務的注意点
ECリプレイスの発注で、トラブルが最も起きやすいのは契約の段階です。「言った・言わない」の水掛け論や想定外の追加費用、ベンダーの責任逃れといった問題の多くは、契約時に適切な取り決めをしていなかったことから生じます。
だからこそ、契約書は形式で終わらせず、プロジェクトを守るための取り決めとして機能させる必要があります。
請負契約と準委任契約：ECリプレイスでの選び方
請負契約は「成果物の完成」を目的とし、仕様どおりの成果物を納品する責任をベンダーが負います。不具合は無償で修正する義務（契約不適合責任）があるため、成果物の品質を担保しやすいのが利点です。ただし、要件や仕様が変わるたびに変更契約が必要になり、要件が途中で変わりやすいECリプレイスでは管理コストが高くなります。
準委任契約は「業務の遂行（プロセス）」に対して対価を払う契約で、成果物の完成責任はベンダーにありません。柔軟に要件変更や追加に対応できる反面、「どこまで進んだか」を発注者自らが管理しなければ、コストが際限なく膨らむリスクがあります。
ECリプレイスでは、要件定義・基本設計フェーズは準委任、開発・テストフェーズは請負という「ハイブリッド型」が実務上有効です。なお、要件が固まっていない初期段階を請負にすると、後から仕様変更による追加費用が多発する原因になります。どちらの契約形態を選ぶにせよ、「フェーズ完了の定義」を契約書に明記することが不可欠です。
下請法の適用条件と支払いルール：発注側が知るべき義務
ECリプレイスの発注では、取引先（ベンダー）が一定規模以下の中小企業である場合、下請代金支払遅延等防止法（下請法）が適用されます。下請法が適用される主な条件は、資本金3億円超の親事業者が、資本金3億円以下の下請事業者に業務を委託する場合です。情報サービス業のシステム開発は、下請法の「情報成果物作成委託」に該当し、適用される可能性があります。
下請法で最も重要なルールは「60日ルール」です。役務の提供を受けた日から60日以内に代金の支払期日を設定し、その全額を支払う必要があります。60日を超えた場合は、年14.6%の遅延利息が発生します。
また、「買いたたき（一方的な値下げ要求）」「発注後の不当な追加作業の要求」「手形払いによる実質的な支払い遅延」なども禁止されています。発注側の担当者がこれらを知らずに行うと、下請法違反として公正取引委員会から勧告を受けるリスクがあるため、注意が必要です。
SLA・ペナルティ条項の設計：ECサイト特有の稼働率・決済成功率の定め方
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（アイルオ）評価」をフェーズ完了判定に取り入れる方法を勧めています。
ILUOとはトヨタ生産方式で活用されるスキル評価フレームワークで、I（見て理解できる）・L（補助があればできる）・U（一人でできる）・O（他者を指導できる）の4段階でスキルを評価します。ECリプレイスのフェーズ完了判定では、発注側の担当者（検収担当者）が、新システムの対象機能について「U（一人で操作できる）」に達していることを条件にします。
具体的には、受注管理・商品登録・顧客対応・レポート確認などの主要業務を、マニュアルなしで一人で操作できるかを実際に確かめます。これにより、「納品はされたが使えない」という事態を防ぎ、現場定着の前提条件を担保できます。
予算超過時の経営陣への説明と追加予算獲得の進め方
ECリプレイスでは、要件定義の進行や非機能要件の詳細化に伴い、当初見積もりより費用が増えることが構造的に起こりえます。これは、見積もりが「超概算→概算→確定」と段階的に精度を高めていく性質を持つためです。予算超過が起きたときは、「なぜ増えたのか」を原因別に分解して経営陣に説明することが大切です。
増加の原因は、「要件の明確化による増加（やむを得ないもの）」「スコープ追加による増加（発注者側の意思決定による追加）」「見積もりの精度不足（ベンダー側に責任があるもの）」の3つに分けられます。それぞれの金額を示すと、経営陣の納得を得やすくなります。
追加予算を申請する際は、「追加しなかった場合のリスクとコスト（EC停止や機会損失）」を定量的に示すことが有効です。EC停止1時間当たりの損失額（例：時間あたり売上×機会損失率）を算出し、追加投資によってそのリスクを回避できることを説明します。
損切りの判断基準：EC停止コストを踏まえたサンクコスト放棄の考え方
プロジェクトが深刻なトラブルに直面したとき、「ここまで費用と時間を投資したのだから続けるしかない」というサンクコスト（埋没費用）の罠にはまることがあります。しかし、ECリプレイスでは、問題のあるプロジェクトを続けることによる損害（現行ECサイトの機会損失の継続、追加費用の積み重ね、組織の疲弊）が、損切りコストを上回るケースも少なくありません。
損切りを判断すべき主なシグナルは3つです。「プロジェクトの遅延が当初工期の50%を超えている」「追加費用が当初予算の30%を超え、かつ収束の見通しがない」「ベンダーとの信頼関係が修復不可能な水準に達している」という状況が重なる場合は、損切りを真剣に検討します。
損切りを判断した場合は、投入済みコストを回収するための法的手段（契約不適合責任の追及等）と並行して、代替ベンダーへの移行計画を策定します。継続するかどうかは、感情ではなく「現時点から見た将来のトータルコスト」で決めることが、経営的に正しいアプローチです。
まとめ：ECリプレイスの発注を成功させる5つの鉄則
ECリプレイスの発注は、安いベンダーに任せることより、発注側が主体となってプロジェクトを管理する姿勢で成否が分かれます。ここまでの内容を整理すると、成功のための5つの鉄則が見えてきます。
第一に、RFPにEC特有の要件（非機能要件・SEO要件・決済要件）を、具体的な数値で書き込むことです。曖昧なRFPからは曖昧な提案しか返ってこず、後の追加費用トラブルにつながります。
第二に、見積もりは金額だけでなく、「何が含まれているか」の中身で比べることです。安すぎる見積もりには、必ず理由があります。
第三に、契約形態（請負・準委任）をフェーズの特性に合わせて選び、下請法の義務を正しく把握することです。
第四に、SLAをECサイト特有の指標（稼働率・決済成功率）で設計し、ペナルティ条項を明文化することです。
第五に、発注後も「ILUO評価」などの独自基準を使ってフェーズ完了を厳格に検収し、問題が深刻化する前に早期に介入することです。
ECリプレイスは複雑なプロジェクトですが、適切な発注の進め方と契約の設計、発注後の主体的な関与によって、成功の確率を大きく高められます。
riplaでは、RFP作成の支援からベンダー選定、プロジェクト管理、カットオーバー後の定着支援まで一気通貫でサポートしています。まずは気軽にご相談ください。
▼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を創業。