通販サイトやECシステムの移行は、数千万円から数億円規模の投資になることも珍しくありません。だからこそ「どこに発注すればよいのか」「外注先に丸投げして使いにくいシステムにならないか」「移行で今の売上や顧客を失わないか」といった不安を抱えたまま、最初の一歩を踏み出せずにいる発注担当者の方は少なくないはずです。発注方法を誤ると、要件のズレや費用の膨張、公開後の現場混乱といった失敗に直結します。
この記事では、通販サイト/システム移行を発注・外注・委託する際の具体的な進め方を、発注実務の観点から体系的に解説します。発注前に固めるべき目的とKPIの整理から、RFP（提案依頼書）の作り方、経営層への稟議の通し方、ベンダー丸投げを防ぐ発注側マネジメント、契約・支払い条件の注意点までを一気通貫でカバーします。読み終えるころには、自社が次に何をすべきかが明確になり、失敗しない発注の段取りが描けるようになります。
▼全体ガイドの記事
・通販サイト/システム移行の完全ガイド
通販サイト/システム移行を外注する前に押さえる全体像
通販サイト/システム移行の発注を成功させるには、まず「誰に・どこまでを・どのような形態で任せるのか」という全体像を整理することが出発点になります。発注の形態や委託先の種類を理解しないまま見積もりを取り始めると、各社の提案が比較できず、判断軸を失ってしまいます。ここでは発注前に押さえておきたい基本構造を整理します。
発注・外注・委託・依頼の違いと使い分け
「発注」「外注」「委託」「依頼」という言葉は日常的に同じ意味で使われがちですが、契約上の責任範囲を考えるうえでは区別して捉えておくと安全です。請負契約は成果物の完成に対して責任を負う形態で、移行プロジェクトのように「指定した仕様のシステムを完成させてほしい」というケースに向いています。一方で準委任契約は、特定の業務を遂行すること自体に対価を支払う形態で、要件が固まりきらない上流フェーズや、運用・保守の継続支援に適しています。
移行プロジェクトでは、要件定義フェーズは準委任、構築フェーズは請負、公開後の運用は準委任というように、フェーズごとに契約形態を切り替える発注設計が一般的です。どの範囲を成果物責任として明確に切り出すかを最初に決めておくと、トラブル時の責任分界点が曖昧になりにくくなります。発注形態の選び方が、後々の追加費用や紛争リスクを左右します。
発注先の種類と委託できる範囲
通販システムの移行先には、ASP・SaaS型のクラウドEC、オープンソース（EC-CUBEなど）、ECパッケージ、フルスクラッチという選択肢があり、どれを選ぶかによって発注できる相手も変わります。月商100万円未満の立ち上げ期であれば初期費用とランニングを抑えやすいASPやモール出店が中心となり、月商数百万円から数千万円の成長期では高機能ASPやクラウドEC、オープンソースが候補になります。月商数億円以上の大規模事業では、独自の業務フローや基幹連携に対応できるパッケージやフルスクラッチが選ばれる傾向があります。
発注時に重要なのは、構築だけを委託するのか、要件定義から運用・保守、さらには集客や物流まで含めて伴走してもらうのかという委託範囲の線引きです。範囲を曖昧にしたまま発注すると、公開後に「ここは契約に含まれていない」という認識のズレが生じやすくなります。自社のリソースで担える部分と外部に委ねる部分を切り分けておくことが、適切な発注先選びの前提になります。
発注前に固めるべき目的・KPI・移行要件
発注で失敗するプロジェクトの多くは、目的やKPIが曖昧なまま見積もり依頼に進んでしまっています。「老朽化したから」「他社が新しくしたから」といった動機だけでは、ベンダーも提案の的を絞れず、結果として過剰な機能や曖昧な要件が積み上がります。発注の精度は、依頼する前の社内整理でほぼ決まると言っても過言ではありません。
移行の目的とKPIを数値で言語化する
移行の目的は、「カゴ落ち率を現状の70%から60%に改善する」「ページ表示速度を3秒から1.5秒に短縮する」「受注処理にかかる作業時間を月100時間削減する」といった形で、できるだけ数値に落とし込むことが重要です。数値化された目的があれば、ベンダーは何を優先して設計すべきかを理解でき、提案の質が大きく変わります。逆に「使いやすくしたい」といった定性的な要望だけでは、評価軸が人によって異なり、検収時のトラブルにつながります。
目的を定めたら、それを測定するKPIとして、コンバージョン率・客単価・リピート率・運用工数などの指標を設定します。現状値を計測しておくことで、公開後の効果検証が可能になり、経営層への報告も説得力を持ちます。発注段階でこの「ビフォー」の数字を押さえておくことが、投資対効果を語るうえでの土台になります。
移行要件をMust/Wantで仕分けして肥大化を防ぐ
発注前の要件整理で最も効果的なのが、機能要件を「Must（必須）」と「Want（あればよい）」に仕分けする作業です。現行システムの機能をそのまま全部移植しようとすると、実際にはほとんど使われていない機能まで開発対象に含まれ、費用と期間が膨れ上がります。利用実績のデータを確認し、使われていない機能を思い切って削ぎ落とすことが、コスト抑制と公開後の運用負荷軽減につながります。
Must要件は移行の目的に直結する機能に限定し、Want要件は公開後の改善フェーズに回すという段階的な発注設計にすると、初期投資を抑えながら早期に効果を出せます。要件の肥大化は、ベンダーへの丸投げと並んで移行失敗の二大要因です。発注側が主体的にスコープを管理する姿勢が、要件の暴走を止める唯一の方法だと言えます。
RFP（提案依頼書）の作り方と稟議の通し方
複数のベンダーから同じ土俵で提案を引き出すには、RFP（提案依頼書）の作成が欠かせません。RFPがないまま「いい感じに提案してください」と依頼すると、各社の提案内容や見積もりの前提がバラバラになり、比較不能な見積書が並ぶことになります。発注の質を高めるうえで、RFPは最も投資対効果の高いドキュメントです。
RFPに盛り込むべき項目
RFPには、プロジェクトの背景と目的、移行の対象範囲、Must/Wantで仕分けした機能要件、現行システムの構成と移行対象データ、想定予算とスケジュール、外部システム（基幹・WMS・CRMなど）との連携要件を盛り込みます。とくに既存の決済・物流・会計システムとの連携要件は、後から発覚すると大幅な追加費用につながるため、発注段階で漏れなく明記しておく必要があります。提案の前提条件を揃えることが、公平な比較の出発点です。
あわせて、提案書に記載してほしい項目（体制図・実績・保守体制・概算見積もりの内訳）と提出期限、評価基準を明示しておくと、各社の提案フォーマットが揃い、比較表を作りやすくなります。RFPの完成度が高いほど、ベンダー側も自社の強みを正確にアピールでき、ミスマッチを防げます。手間はかかりますが、ここでの作り込みが後工程の混乱を確実に減らします。
ROI・リスク対策・比較表で稟議を通す
数千万円から数億円規模の投資を経営層に承認してもらうには、感覚的なメリットではなく、投資対効果（ROI）を数字で示すことが不可欠です。たとえば「移行により受注処理工数を月100時間削減し、人件費換算で年間約300万円のコスト削減を見込む」「表示速度改善でコンバージョン率が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引き継ぎの責任範囲も明記しておく必要があります。顧客情報・商品データ・注文履歴の移行は、どこまでをベンダーが担い、どのデータをどの精度で移すのかを取り決めます。パスワードは暗号化方式の違いから引き継げないことが多く、その場合は顧客への再設定案内が必要になるため、再設定キャンペーンやポイント付与といった離脱防止の業務計画もあわせて準備しておくと安心です。
SEOについては、URLが変わる場合の301リダイレクト設定をどちらが担当するかを契約で明確にしておきます。リダイレクトを怠ると検索評価が引き継がれず、移行直後に検索流入が激減するリスクがあります。さらに、移行後に不要となる旧システムのデータについては、コンプライアンスの観点からデータ廃棄計画まで含めて取り決めておくと、情報漏えいリスクを抑えられます。
まとめ
通販サイト/システム移行の発注・外注を成功させる鍵は、発注前の社内整理にあります。移行の目的とKPIを数値で言語化し、機能要件をMust/Wantで仕分けたうえで、RFPを作成して複数社から公平に提案を引き出すことが、ミスマッチを防ぐ第一歩です。経営層への稟議では、ROIとリスク対策、比較表をセットで示すことで、大型投資の承認を得やすくなります。
発注後も丸投げにせず、週次定例・課題管理・成果物承認で主体的にプロジェクトを管理し、責任分界点の合意やFit to Standard、切り戻し基準と段階移行でリスクを抑えていくことが大切です。契約段階では、要件定義費や構築期間中の保守費といった隠れコストを3〜5年のTCOで把握し、データ移行やSEO引き継ぎの責任範囲を明確にしておきましょう。発注側が主導権を握ることが、移行プロジェクトを成功に導く最大の要因です。
▼全体ガイドの記事
・通販サイト/システム移行の完全ガイド
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。