通販サイト/システム更改の発注/外注/依頼/委託方法について

通販サイトやECシステムの更改は、数千万円規模の投資と半年から1年に及ぶ期間を要する一大プロジェクトです。「老朽化したシステムをそろそろ刷新したいが、どこに、どう発注すればよいのか分からない」「過去にベンダーへ丸投げして、現場で使いにくいシステムが出来上がってしまった」といった悩みを抱える発注担当者の方は少なくありません。発注の進め方を誤ると、稟議が通らない、見積もりが各社バラバラで比較できない、公開後に売上が落ちるといった事態に直結します。

この記事では、通販サイト/システム更改を外注・委託する際に、発注担当者が押さえるべき実務を体系的に解説します。発注前の目的・KPIの固め方から、RFP（提案依頼書）の作り方、経営層への稟議の通し方、ベンダー丸投げを防ぐ発注側マネジメント、契約・支払い条件の注意点、そしてデータ移行とSEO引き継ぎの取り決めまでを網羅します。読み終えるころには、自社が「何を準備し、誰に、どう発注すればよいか」が具体的に描けるようになります。

▼全体ガイドの記事
・通販サイト/システム更改の完全ガイド

通販サイト/システム更改の発注を成功させる全体像

通販サイト/システム更改の発注は、ベンダーを決めて契約書に印鑑を押せば終わり、というものではありません。発注の成否は「発注前にどこまで自社で準備したか」と「発注後に発注側がどこまで主体的にプロジェクトを運営したか」でほぼ決まります。中規模ECの全面刷新では3,000万〜8,000万円、移行期間は6〜12カ月が一つの目安となり、ここでの判断ミスは大きな損失につながります。

まずは発注の全体像を俯瞰し、なぜ「丸投げ」が失敗を招くのか、そして発注に踏み切る前に何を把握しておくべきかを整理します。この土台があるかどうかで、後工程のRFP作成や稟議、ベンダー管理の精度が大きく変わってきます。

システム更改で最も多い失敗が「ベンダー丸投げ」です。要件定義をベンダー任せにすると、自社の業務フローを十分に理解しないまま標準機能だけで作り込まれ、公開後に「現場の運用に合わない」「結局Excelの二重管理が残った」という事態に陥ります。ベンダーは自社の倉庫オペレーションやコールセンターの応対手順までは把握していないため、発注側が要件を言語化しなければ正しく形にはなりません。

発注側に求められる役割は、業務知識の提供、意思決定、関係部署の調整という3点です。とくにECの更改では、マーケティング・物流・カスタマーサポート・経理など複数部署が関わるため、社内の合意形成を主導できるのは発注担当者だけです。ベンダーは「作る」専門家であって、「自社の業務をどう変えるか」を決められるのは発注側であるという前提を最初に共有しておくことが重要です。

発注に踏み切る前に、まず「なぜ今、更改が必要なのか」を自社で言語化しておく必要があります。代表的な更改のサインは、既存システムの老朽化やカスタマイズの限界、利用しているパッケージやミドルウェアのサポート終了（EOL）、そしてOMOやERP刷新など事業戦略の変化です。これらが複数重なっている場合は、更改を先送りするほど運用コストとリスクが膨らみます。

あわせて、現行システムの構成、連携している外部システム、月商規模、年間の注文件数、保有している顧客・商品・注文履歴のデータ量を棚卸ししておきます。これらは後のRFPや見積もり依頼で必ず聞かれる情報であり、ここが曖昧だと各社から精度の低い概算見積もりしか得られません。現状把握は発注準備の出発点であり、ここに時間をかけることが結果的に手戻りを減らします。

発注前に固めるべきこと（目的・KPI・要件）

発注の精度は、発注前の準備でほぼ決まります。目的・KPI・要件という3つを社内で固めてからベンダーに声をかけることで、的外れな提案や見積もりのブレを大幅に減らせます。逆に、ここが曖昧なまま発注すると、要件が次々と膨らみ、追加費用と納期遅延の温床になります。

「システムが古いから」という理由だけで更改を進めると、判断基準を持たないままプロジェクトが迷走します。まずは「カゴ落ち率を現状の70%から60%に改善する」「スマホ経由のコンバージョン率を1.2%から1.8%に引き上げる」「受注処理にかかる人時を月200時間削減する」といった、定量的なKPIに落とし込むことが重要です。

KPIを明確にすると、ベンダー選定や機能の優先順位づけの判断軸になります。たとえば「モバイルUXの改善」が最優先なら、表示速度やフロントエンドの実績が豊富なベンダーを重視できます。目的とKPIは、後の稟議でROIを説明する際の根拠にもなるため、発注前の段階で経営層と握っておくことが望ましいです。

更改プロジェクトで予算が膨らむ最大の原因は、要件の肥大化です。各部署から「あれもこれも」と要望を集めると、本来不要な機能まで盛り込まれ、見積もりが当初想定の1.5倍、2倍に膨れ上がることも珍しくありません。これを防ぐには、すべての要件を「Must（必須）」と「Want（できれば）」に仕分けし、優先順位を明確にすることが不可欠です。

仕分けの基準は、先に定めたKPIへの貢献度です。KPI達成に直結する機能はMust、なくても事業が回る機能はWantとし、Wantは予算と納期に余裕があれば実装する位置づけにします。この仕分け表をベンダーと共有しておくと、提案段階で「Mustだけの最小構成」と「Want込みのフル構成」の見積もりを並べてもらえ、投資判断がしやすくなります。

通販システムは単独では完結せず、基幹システム、WMS（倉庫管理システム）、CRM、会計システムなどと連携します。発注前に「どのシステムと、どのデータを、どの方式（API・CSV・リアルタイム/バッチ）で連携するのか」を整理しておかないと、後工程で「連携できると思っていたのにできない」という事態が発生します。これは見積もりの大きな変動要因にもなります。

とくに注意したいのが「連携できる」という言葉の罠です。ベンダーが言う「連携可能」は、API仕様が公開されている前提であったり、追加開発が必要だったりと、解釈に幅があります。発注前に、どこまでが既存システム側の責任で、どこからがECベンダー側の責任かという責任分界点を文書化しておくことで、後の追加費用や責任の押し付け合いを防げます。

RFP（提案依頼書）の作り方と相見積もりの取り方

固めた目的・KPI・要件を、ベンダーに正しく伝える手段がRFP（提案依頼書）です。RFPの完成度が高いほど、各社から精度の高い提案と見積もりが集まり、横並びで比較できるようになります。口頭やメールでの曖昧な依頼では、各社が前提をバラバラに解釈し、比較不能な見積もりが返ってくるだけです。

RFPには、最低限として次の項目を記載します。プロジェクトの目的とKPI、現行システムの構成と課題、Must/Wantに仕分けした機能要件、連携対象システムと責任分界点、移行対象データの量、希望スケジュールと予算レンジ、そして提案・見積もりの提出形式です。とくに予算レンジを示すかどうかは悩みどころですが、概算でも提示した方が現実的な提案を引き出せます。

書き方のコツは、機能を細かく指定しすぎず「実現したいこと」を中心に書くことです。実装方法まで縛ってしまうと、ベンダーが持つ標準機能やノウハウを活かした効率的な提案を引き出せません。「何を実現したいか（要求）」を発注側が示し、「どう実現するか（手段）」はベンダーの提案に委ねる、という役割分担を意識すると質の高い提案が集まります。

発注先は、最低でも3社程度から相見積もりを取ることをおすすめします。1社だけでは金額や提案内容の妥当性を判断できず、適正価格を見極められません。同じRFPを各社に渡すことで、提案範囲・金額・スケジュール・体制を同じ土俵で比較できるようになります。

比較の際は、金額だけで判断しないことが重要です。評価軸を「費用」「同業種・同規模の実績」「提案内容の的確さ」「プロジェクト体制と担当者の質」「公開後の運用・保守体制」などに分け、それぞれを点数化した比較表を作ると、合理的かつ社内説明のしやすい選定ができます。最安値のベンダーが要件を十分に理解していないケースもあるため、提案の質を必ず加味します。

経営層への稟議を通すための材料づくり

通販システムの更改は数千万円規模の投資となるため、発注の前に経営層の承認を得る稟議が大きな関門になります。担当者がどれだけ良いベンダーを見つけても、稟議が通らなければプロジェクトは前に進みません。経営層が知りたいのは「いくらかかり、どんなリターンがあり、どんなリスクがあるのか」の3点です。ここを論理的に示せるかが鍵になります。

稟議で最も説得力を持つのが、ROI（投資対効果）のシミュレーションです。先に定めたKPIをもとに、「コンバージョン率が0.5ポイント改善すれば年間売上が約3,000万円増える」「受注処理の自動化で年間2,000時間の工数削減につながる」といった形で、投資が生む金額的なリターンを試算します。前提条件を明記したうえで、保守的なケースと標準的なケースを併記すると信頼性が高まります。

あわせて重要なのが、初期費用だけでなくTCO（総保有コスト）で見る視点です。決済手数料、サーバーなどの従量課金、アプリ追加費用、保守費、将来のバージョンアップ費用までを3〜5年の期間で積み上げると、初期費用の安さだけで選ぶ危うさが見えてきます。経営層に対しても「単年の出費」ではなく「数年間の投資と回収」のストーリーで示すことで、納得感のある承認を得やすくなります。

経営層は、メリットだけを並べた提案に対してかえって警戒します。むしろリスクを正直に開示し、それぞれに対策をセットで示すことで、検討の深さが伝わり信頼を得られます。想定すべき主なリスクは、移行時のデータ不整合、公開直後の検索流入の落ち込み、納期遅延、そして公開後に現場が混乱する定着リスクです。

たとえば「移行に伴うSEO評価の低下リスクには301リダイレクトの徹底とリリース前の検証で対応する」「納期遅延リスクには段階的なリリースで影響範囲を限定する」といった形で、リスクと対策を一対一で対応づけます。さらに、更改を「やらなかった場合のリスク」、つまり老朽化したまま運用を続ける場合の機会損失や障害リスクも示すと、投資の妥当性がいっそう明確になります。

ベンダー丸投げを防ぐ発注側マネジメント

発注が完了しても、発注側の仕事は終わりません。むしろ契約後のプロジェクト運営こそが成否を分けます。ベンダーに任せきりにせず、発注側が主体的にプロジェクトを管理することで、認識のズレや手戻りを早期に発見し、炎上を未然に防げます。ここでは発注側が押さえるべき具体的なマネジメント手法を解説します。

発注側がプロジェクトを管理する基本の道具立ては、週次定例・課題管理表・成果物承認の3つです。週次定例では、進捗状況、今週の決定事項、来週の予定、課題の状況を定点で確認します。月1回などの頻度では問題の発見が遅れるため、原則として週次での開催をおすすめします。

課題管理表では、発生した課題・担当・期限・ステータスを一覧で管理し、「言った言わない」を防ぎます。さらに、要件定義書・設計書・テスト結果といった各フェーズの成果物について、発注側が内容を確認し正式に承認するプロセスを設けます。承認なくして次フェーズに進ませないことで、後工程での大きな手戻りを防止できます。

プロジェクトの炎上は、責任の所在が曖昧なときに起きやすくなります。発注時に整理した責任分界点を、契約後も改めてベンダーと文書で合意しておきます。データ移行はどちらの責任か、連携先システムの改修は誰が行うか、テストデータは誰が用意するかといった細部まで明確にしておくことで、トラブル時の責任の押し付け合いを防げます。

また、過剰なカスタマイズを避けるFit to Standardの考え方も重要です。これは、システムを自社業務に合わせて作り込むのではなく、標準機能に業務側を寄せていく発想です。カスタマイズは初期費用だけでなく、将来のバージョンアップ時の追加費用や保守の複雑化を招きます。標準機能で代替できる業務は業務側のやり方を見直すという社内調整を、発注側が主導することがコスト抑制につながります。

新システムへの切り替え（カットオーバー）当日は、最も障害リスクが高まる瞬間です。発注側は事前に「どの条件を満たさなければ旧システムに戻すか」という切り戻し（フォールバック）基準を、ベンダーと文書で合意しておく必要があります。基準が曖昧なままだと、障害が起きた際に「戻すか、進めるか」の判断が遅れ、売上の損失が拡大します。

あわせて、一度に全機能を切り替えるのではなく、段階的に移行する方法もリスク低減に有効です。たとえばBtoB ECなら一部の主要顧客から先行運用を始め、問題がないことを確認してから全体展開する進め方があります。段階移行は影響範囲を限定でき、初期段階で見つかった課題を本格展開前に修正できるという利点があります。

契約・支払い条件で注意すべきポイント

発注先が決まったら、契約内容を細部まで確認します。システム開発の契約は金額が大きいうえに期間も長いため、契約条件の見落としが後々のトラブルや追加費用につながります。とくに契約形態、費用の内訳、検収条件、著作権の扱いは、発注前に必ず押さえておきたいポイントです。

システム開発の契約形態は、主に請負契約と準委任契約に分かれます。請負契約は成果物の完成に責任を負う契約で、仕様が明確な開発フェーズに向いています。一方の準委任契約は、業務の遂行自体に対価を払う契約で、仕様が固まりきっていない要件定義フェーズに適しています。フェーズごとに契約形態を使い分けるのが一般的です。

注意したいのが要件定義費の扱いです。要件定義は更改の品質を左右する重要工程であり、多くのベンダーでは別途費用として準委任契約で行います。「要件定義は無料」とうたうベンダーには、その分が開発費に上乗せされていないか、要件定義が形だけで終わらないかを確認します。要件定義費は数百万円規模になることもあるため、見積もりの段階で明示してもらうことが大切です。

見積もりで見落としがちなのが、構築期間中やオープン前の保守費、そして公開後の運用保守費です。これらが見積もりに含まれているか、月額いくらかを必ず確認します。とくに公開後の保守は数年にわたって発生する費用であり、TCOの観点では初期費用以上に重要になることもあります。

検収条件も重要なポイントです。「どの状態をもって完成とみなすか」「検収期間は何日か」「不具合があった場合の対応はどうするか」を契約書で明確にしておきます。さらに、開発したシステムやソースコードの著作権が自社に帰属するのか、ベンダーに残るのかも確認が必要です。著作権がベンダーに残ると、将来別の会社に保守を依頼したいときに制約が生じる場合があります。

データ移行とSEO引き継ぎを発注時に取り決める

通販サイトの更改で売上に直結するのが、データ移行とSEOの引き継ぎです。これらを発注時の取り決めから外してしまうと、公開後に「検索流入が半減した」「過去の注文履歴が見られない」といった重大な問題が発生します。発注の段階で、誰が何をどこまで担うのかを明確にしておくことが欠かせません。

サイト更改でURL構造が変わる場合、旧URLから新URLへの301リダイレクトを漏れなく設定することが必須です。これを怠ると、検索エンジンが積み上げてきた評価が引き継がれず、検索流入が大きく落ち込みます。発注時に、リダイレクトの設定範囲と責任者、そして公開前の検証手順を取り決めておきます。

さらに一歩進んだ取り組みとして、移行前に自社のトラフィック構造を分析しておくことをおすすめします。流入がトップページ中心なのか、数千ページに分散しているのか、ブランド検索と非ブランド検索の比率はどうかを把握すると、移行に伴うSEOリスクを定量的に評価できます。リスクが大きいと判明すれば、移行範囲や時期の見直しという経営判断にもつなげられます。

顧客のパスワードは、暗号化方式の違いから新システムへそのまま引き継げないことが多くあります。これを技術的な問題として放置すると、公開直後に既存顧客がログインできず離脱してしまいます。発注時に、パスワード再設定の案内をどう行うか、再設定時のポイント付与やキャンペーンで離脱を防ぐ業務計画まで含めて検討しておくことが重要です。

会計に関わるデータの移行はさらに慎重さが求められます。売掛・買掛の残高や注文金額は「1円の差異も許容しない」厳格さで突合する必要があり、ズレが生じると経理処理に支障をきたします。あわせて、移行後に不要となる旧システムのデータについては、コンプライアンスの観点から保管期間と廃棄方法を定めたデータ廃棄計画を立てておきます。これらは発注時に責任分担を明確にすべき項目です。

まとめ

通販サイト/システム更改の発注・外注を成功させる鍵は、「発注前の準備」と「発注後の主体的なマネジメント」にあります。目的とKPIを言語化し、要件をMust/Wantに仕分けたうえで、外部連携の責任分界点まで整理してからRFPを作成します。複数社から相見積もりを取り、費用だけでなく実績や提案の質を比較表で評価することで、自社に合った発注先を見極められます。

稟議ではROIとTCOで投資対効果を示し、リスクと対策をセットで提示することで経営層の承認を得やすくなります。発注後は週次定例・課題管理表・成果物承認でベンダー丸投げを防ぎ、Fit to Standardや切り戻し基準でリスクを抑えます。契約形態や保守費、データ移行とSEO引き継ぎまで発注時に取り決めておけば、公開後の混乱を最小限にできます。本記事を発注準備のチェックリストとして活用し、後悔のない更改を実現してください。

▼全体ガイドの記事
・通販サイト/システム更改の完全ガイド

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

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

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

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

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

執筆者プロフィール

張田谷凌央

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