通販サイト/システム移行の発注は、目的と要件を固め、RFP（提案依頼書）で提案を募り、発注側が進行を管理すると、認識のずれや移行リスクを抑えられます。
まず発注形態と委託先を決め、RFPと稟議、ベンダー選定、契約条件へと進みます。全体像は、下の「通販サイト/システム移行の完全ガイド」でも確認できます。
▼全体ガイドの記事
・通販サイト/システム移行の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
通販サイト/システム移行を外注する前に押さえる全体像
通販サイト/システム移行では、誰に何をどの形態で任せるかを、見積もりを取る前に決めておきます。発注形態や委託先を理解しないまま見積もりを集めると、提案の中身がそろわず、比べる軸を失います。
発注・外注・委託・依頼の違いと使い分け
「発注」「外注」「委託」「依頼」は日常では同じ意味で使われがちですが、契約上の責任範囲では区別して考える必要があります。
- 請負契約：指定仕様のシステムを完成させる移行案件に向き、成果物の完成に責任を負います。
- 準委任契約：要件がまだ固まらない上流工程や運用・保守など、業務の遂行に対して対価を支払います。
移行では、要件定義は準委任、構築は請負、公開後の運用は準委任とするのが一般的です。成果物の責任範囲を先に決めておけば、トラブルが起きたときに責任分界点が明確になり、どこまでを誰が負うのかも分かります。なお、発注形態の選び方は、後の追加費用や紛争リスクを左右します。
発注先の種類と委託できる範囲
通販システムの選択肢は事業規模や業務要件で異なり、発注先として検討する方式も、月商の規模によって大きく変わります。
- 月商100万円未満：初期費用とランニングを抑えやすい、ASPやモール出店が中心。
- 月商数百万円〜数千万円：高機能ASP、クラウドEC、オープンソースが候補。
- 月商数億円以上：独自業務や基幹連携に対応するパッケージやフルスクラッチが選ばれる傾向。
選択肢には、ASP・SaaS型クラウドEC、EC-CUBEなどのオープンソース、ECパッケージ、フルスクラッチがあります。方式が違えば発注できる相手も変わるため、方式の見当を先につけておくと、相手先の候補を絞り込めます。
構築だけでなく、要件定義、運用・保守、集客、物流まで委託するかを、あらかじめ決めておきます。委託範囲が曖昧なままだと、公開後に「それは契約外だ」という認識のずれが生じます。自社で担う部分と外部に委ねる部分を切り分けることが、発注先を選ぶ際の前提になります。
発注前に固めるべき目的・KPI・移行要件
目的やKPIが曖昧なまま見積もりを頼むと、ベンダーは提案を絞り込めません。「老朽化したから」という理由のまま進めると、過剰な機能や曖昧な要件が積み上がってしまいます。
移行の目的とKPIの数値化
移行の目的を具体的な数値にしておくと、ベンダーと改善目標を共有できます。売上や業務効率に関わる目標も、数値で決めておきます。
- カゴ落ち率：現状の70%から60%への改善を目標にする。
- 表示速度：ページ表示を3秒から1.5秒へ縮める。
- 受注処理：作業時間を月100時間減らす。
数値で示した目的があれば、ベンダーは設計の優先順位を把握できます。一方で、「使いやすくしたい」という目的のままでは評価の軸が人によって異なり、検収時のトラブルにつながります。
目的に対応するKPIには、コンバージョン率や客単価、リピート率のほか、運用工数も設定します。現状値を測っておくと、公開後の効果検証や経営層への報告に使えます。そのため、発注時に移行前の数字を押さえておくことが、投資対効果を説明する土台になります。
Must/Wantによる要件の仕分けと肥大化の防止
移行では、要件が膨らみやすくなります。そこで、移行で必須の機能と、後から検討できる機能を分けておきます。
- Must：移行目的に直結する機能に絞る。
- Want：公開後の改善フェーズに回す。
現行機能をすべて移すと、使われていない機能まで開発対象になり、費用と期間が膨らみます。まず利用実績を確かめて不要な機能を削っておくと、費用と運用の負荷を抑えられます。
この段階的な設計は、初期投資を抑えながら早期に効果を出すための方法です。また、要件の肥大化は、ベンダーへの丸投げと並ぶ移行失敗の要因になります。要件の暴走を止めるには、発注側が主体的にスコープを管理することが欠かせません。
RFP（提案依頼書）の作り方と稟議の通し方
複数のベンダーから同じ条件で提案を得るには、RFP（提案依頼書）が欠かせません。RFPがないと、提案や見積もりの前提がばらばらになり、比較が難しくなります。
RFPに盛り込むべき項目
提案内容と見積もりを公平に比べるには、各社に同じプロジェクト条件を伝える必要があります。そのため、依頼書には移行範囲や制約も含めておきます。
- 背景・目的：プロジェクトの経緯と達成したいこと。
- 対象・機能：移行範囲とMust/Wantに分けた機能要件。
- 現行環境：システム構成と移行対象データ。
- 予算・日程：想定予算とスケジュール。
- 外部連携：基幹、WMS、CRMなどとの連携要件。
既存の決済・物流・会計システムとの連携は、後から判明すると大幅な追加費用につながります。そこで、発注の時点で漏れなく明記しておきます。
提案書の中身も指定しておきます。体制図や実績のほか、保守体制と概算見積もりの内訳も求めます。提出期限と評価基準を示しておくと、提案の形式がそろい、比較表を作りやすくなります。
RFPの作成には手間がかかります。しかし、ベンダーが強みを正確に示せるようになり、ミスマッチや後工程での混乱も防げます。
ROI・リスク対策・比較表を使った稟議
数千万円から数億円規模の投資を通すには、投資対効果（ROI）を数値で示す必要があります。試算には、次のような例があります。
- 工数削減：月100時間を減らし、人件費換算で年間約300万円の効果を見込む。
- 売上増：表示速度改善でCVRが1%上がると、年商3億円のサイトで年間約3,000万円の増収を期待できる。
投資の回収期間も示しておくと、経営層は判断の材料を得られます。試算があれば、感覚ではなく数字で説明できます。
稟議では、リスクと対策を並べて書いておきます。SEO評価の一時的な低下、データ移行の失敗、公開直後の混乱については、301リダイレクトや段階移行、教育計画などの対策を示します。
複数社の比較表を添えて、ベンダー選定の理由を客観的に示すと、稟議の説得力が高まります。
発注先の選び方と相見積もりの取り方
価格だけで発注先を決めると、公開後に使いにくさや連携不足が表面化しがちです。そこで、RFPへの提案を同じ評価基準で比べます。
複数社比較で見るべき観点
相見積もりは、最低でも3社程度から取ります。価格や実績、体制などを合わせて、総合的に評価します。
- 実績：自社と同業種・同規模の移行経験があるか。
- 体制・保守：公開後の伴走支援と保守サポートが受けられるか。
- 運用のしやすさ：軽微な修正を自社で行えるか、集客や物流も相談できるか。
- 意思疎通：担当者と話を進めやすいか。
同業種・同規模の実績は、要件をどれだけ早く理解できるか、想定外のトラブルにどう対応できるかを見極める材料になります。また、見積もりは金額に含まれる範囲と含まれない範囲をそろえて比べます。
移行後も軽微な修正を自社で行えるか、集客から物流まで相談できるかは、長期的な運用コストを左右します。担当者との意思疎通も、移行の成否に関わります。
外部連携の責任分界点と「連携できるの罠」
「連携できます」という回答は、方式と責任分界点を確かめて初めて判断材料になります。基幹システム、WMS（倉庫管理システム）、CRMとの連携では、方式と責任分界点について、次の点を確かめます。
- 連携方式：API経由のリアルタイム連携か、CSVによるバッチ連携か。
- 仕様と担当：どの仕様まで対応し、どちらが開発するのか。
線引きが曖昧なままだと、公開直前になって契約範囲外と分かり、追加費用や遅延を招きます。提案の段階で、システムごとのデータ項目と連携頻度を質問します。さらに、エラー処理とテスト方法についても尋ねておきます。
回答の内容は、提案書に明記してもらいます。特に会計データは、売掛・買掛の残高が1円でもずれると経理が成り立たないため、突合精度について発注側とベンダーのどちらが責任を負うかも決めておきます。
連携要件の詰めが甘いことは、移行プロジェクトで最も炎上しやすい原因の一つです。
ベンダー丸投げを防ぐ発注側マネジメント
外注後に発注側が手を離してしまうと、現場の業務に合わないシステムができあがることがあります。発注側が主体的に関わりながらベンダーと進める体制が、移行を成功させる鍵になります。
責任分界点の合意とFit to Standard
外注後も業務に合うシステムにするには、発注側がベンダーと役割を分けて関わる必要があります。発注側は、PMとして定例・課題・承認の各場面でベンダーと向き合います。
- 週次定例：ベンダーと週に一度会議を開く。
- 課題管理：進捗とリスクを一覧にし、担当者・期限・作業を決める。
- 成果物承認：要件定義書や設計書を各フェーズで確認する。
課題管理表を使えば、認識のずれを早い段階で見つけやすくなります。各フェーズの成果物を承認しておくことが、後戻りを防ぐ仕組みになります。
Fit to Standardは、過剰なカスタマイズを避けて、業務を標準機能に寄せる考え方です。現行の業務をすべて再現しようとすると、費用と期間が膨らみ、保守も難しくなります。
標準機能で代えられる業務は、業務側を変える方針とし、発注側が社内調整を主導します。そうすることで、コストとリスクを抑えられます。
切り戻し基準と段階移行によるリスクの抑制
公開後に重大な不具合が出て、旧システムにも戻せない状態になると、売上が止まるおそれがあります。そのため、移行時の進め方を事前に決めておきます。
- 切り戻し基準：旧システムに戻す条件を、発注側とベンダーで合意しておく。
- 段階移行：一部の商品カテゴリや主要顧客から切り替える。
基準を文書にしておくと、障害が起きた際に感情論ではなく、決めた判断軸に沿って対応できます。段階移行では、たとえばBtoB ECなどで特定の取引先に先行して運用し、フィードバックを受けてから全体に展開できます。
段階移行は一見、時間がかかるように見えます。しかし、影響範囲を限って品質を高められるため、大規模な障害や現場の混乱を抑えられます。
契約・支払い条件で注意すべきポイント
契約時には、見積もりの総額に加えて、内訳と支払い条件も確認します。契約書の文言は、追加費用やトラブルが起きたときの責任の所在を左右します。
要件定義費・構築期間中の保守費という隠れコスト
移行費用には初期構築費のほかに要件定義費などがあり、見積もりの中に分かれて計上されます。内訳をあわせて確認すると、費用の全体がつかみやすくなります。
- 移行関連：要件定義費、構築中の旧システム保守費、データ移行費。
- 開発・利用：外部連携の開発費、決済手数料、従量課金、追加アプリ利用料。
要件定義は準委任契約として別途費用になることが多く、初期費用に含まれると思い込むと予算が崩れます。ランニングコストも積み上がります。
費用を比べる際は、3年から5年のTCO（総保有コスト）で見る視点が欠かせません。
支払い条件では、着手金や中間金、検収後の支払いといったマイルストーンを定めておきます。そのうえで、検収の基準を契約書に具体的に記載します。
完成の定義が曖昧だと、検収の時点で仕様外かどうかをめぐって争いになります。そこで、受け入れ条件を事前にベンダーと合意しておきます。
データ移行・SEO引き継ぎに関する取り決め
顧客情報や商品情報の移行、検索流入の維持には、作業範囲について合意しておくことが必要です。契約の前に、責任の範囲をそろえておきます。
- 移行対象と精度：顧客情報、商品データ、注文履歴をどこまで、どの精度で移すか。
- SEO対応：URL変更時の301リダイレクトをどちらが担当するか。
- 旧データ：不要となる旧システムデータをどう廃棄するか。
パスワードは暗号化方式が違うため、引き継げないことが多く、顧客に再設定を案内する必要があります。そこで、再設定キャンペーンやポイント付与など、離脱を防ぐ業務計画も用意しておきます。
301リダイレクトを怠ると検索評価が引き継がれず、移行直後に検索流入が激減するおそれがあります。また、旧データの廃棄計画まで決めておくと、情報漏えいのリスクを抑えられます。
まとめ
通販サイト/システム移行の発注・外注を成功させる鍵は、発注前の社内整理にあります。
まず目的とKPIを数値にし、要件をMust/Wantに分けます。そのうえでRFPを作り、複数社から公平に提案を集めます。
稟議ではROIとリスク対策、比較表を示すと、大型投資の承認を得やすくなります。発注後も、週次定例や課題管理、成果物承認を通じて、発注側が主体的に進行を管理します。
さらに、責任分界点やFit to Standard、切り戻し基準、段階移行を整え、リスクを抑えます。契約時には、隠れコストを3年から5年のTCOで把握します。
データ移行と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を創業。