通販サイトの改修は、目的と要件を固め、RFP（提案依頼書）を作って発注先を選び、契約後も進行を管理する順に進めます。どの段階でも発注側が中心に立つと、発注の失敗を防ぎやすくなります。
全体像は、通販サイト/システム改修の完全ガイドもあわせてご覧ください。
▼全体ガイドの記事
・通販サイト/システム改修の完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
発注前の準備（目的・KPI・要件の言語化）
発注の成否は、ベンダーに声をかける前の準備でほぼ決まります。特に、目的やKPIが曖昧だと各社の提案を比べにくく、安さだけで選んで失敗する恐れもあります。
改修の目的とKPIの定義
改修の背景には、システムの老朽化やカスタマイズの限界、サポート終了（EOL）などがあります。OMOやERP連携といった戦略の変化も、きっかけになります。そこで発注側は、なぜ今取り組むのかを言葉にし、数値目標と合わせて整理します。
たとえば、購入完了率を現状の1.8%から3.0%へ上げる目標や、受注処理の手作業を月40時間削減する目標を置けます。こうしたKPIがあれば、提案を定量的に判断でき、経営層への説明にも役立ちます。
目的を「なんとなく古いから」としたままだと、ベンダーが安全側に寄せた過剰な提案をする場合があります。このため発注側は、KPIへの貢献を問い、投資対効果の高い改修範囲に絞り込みます。
Must/Wantによる要件の仕分けと肥大化の防止
要件の肥大化は、改修プロジェクトが炎上する主な原因です。たとえば、各部門の要望で当初の3倍の予算を求められる事態も珍しくありません。
発注側は、洗い出した機能を、事業継続に必須のMustと、あれば望ましいWantに分けます。ベンダーに渡す前に社内で合意しておくと、見積もりのぶれを抑えられます。
要望を分類するときは、事業継続への影響と初期リリースでの必要性を基準にできます。
- Must：決済、在庫連携、基幹システムとのデータ連携など。
- Want：レコメンド表示の高度化やデザインの細部など。
Wantの機能は、初期リリースで見送る判断もできます。また、フェーズを分けた段階リリースも計画に組み込めます。
発注先の種類と特徴
通販システムの改修では、プラットフォームと発注先のタイプによって費用も自由度も変わります。そのため、事業規模や将来構想に合わない選択をすると、数年後に再構築が必要になることがあります。
ASP/クラウドEC・パッケージ・フルスクラッチの違い
発注先は、ASP/SaaS・クラウドEC事業者、ECパッケージ会社、フルスクラッチ開発会社に大別できます。そのうえで、方式ごとの費用や制約を比べます。
- ASP・クラウドEC：月額数万円から利用でき、立ち上げが速い一方、独自の業務フローや基幹連携には制約があります。
- パッケージ：中規模以上では柔軟性と開発効率のバランスが取れますが、将来のバージョンアップや保守費も見込む必要があります。
- フルスクラッチ：独自フローや大規模な基幹連携を実現できますが、初期費用が数千万円から億単位になることもあり、保守体制の確保が前提です。
方式の当たりを付けてから会社を探すと、発注先の候補を効率よく選べます。
事業規模・月商別の最適な発注先
月商規模ごとに選択肢は異なるため、現在だけでなく3〜5年後の事業計画も踏まえて方式を比べます。
- 月商100万円未満：ASPやモール出店。
- 月商数百万円から数千万円：高機能ASP、クラウドEC、オープンソース。
- 月商数億円以上：パッケージのカスタマイズやフルスクラッチ。
立ち上げ期は、初期費用と運用費を抑えやすい方式が現実的です。成長期には販促や分析機能の拡張、大規模事業では独自業務や基幹連携への対応が、選択の目安になります。
現状の規模だけで選ぶと、将来の拡張に対応できず再構築が必要になる恐れがあります。そこで、商品数や受注件数が増える想定を候補先に伝え、対応できるかを確かめてください。
RFP作成と経営層への稟議の通し方
正確な見積もりと社内の予算承認には、RFP（提案依頼書）が欠かせません。各社に同じ条件で提案を求める共通仕様書になり、数千万円規模の投資を説明する稟議資料にもなります。
RFPに盛り込む項目
発注側は、各社の見積もりを同じ条件で比べるため、改修の範囲と進め方をRFPに具体化します。
- 目的・要件：KPI、現行システム構成、Must/Wantで分けた機能要件。
- 移行・連携：データ移行範囲、外部連携の要件。
- 計画・体制：希望スケジュール、予算レンジ、保守運用の体制要望。
データ移行や連携は仕様が膨らみやすいため、基幹・WMS・CRMなどの連携先と、APIやCSVなどの方式を、できる範囲で具体的に書いておきます。そうすると、見積もりの精度が上がります。
RFPが精緻になるほど提案を比較しやすくなり、相見積もりの効果も高まります。ただし、作成が難しい場合は、要件定義を支援するコンサル型パートナーに伴走を依頼することもできます。
ROI・リスク対策・ベンダー比較表による承認取得
稟議では、投資額と回収時期、回収見込みを示す必要があります。そのため、KPIの改善が売上や工数削減にどう結びつくかを、ROIシミュレーションにまとめておきます。
費用は、初期費用に加えて3〜5年のTCO（総保有コスト）で比べます。決済手数料や従量課金を、データ移行費や保守費と合わせて総額で示すと、追加予算が後から膨らむことを防げます。
移行に伴う売上毀損やスケジュール遅延のリスクも示し、段階移行や切り戻し基準の合意などの対策を併せて示します。さらに、複数社のベンダー比較表を用意して、費用・実績・体制から選定理由を説明すると、稟議の説得力が増します。
ベンダー選定と相見積もりの進め方
RFPが整ったら複数社に提案を依頼し、相見積もりを取ります。一般には3社程度に絞ると、比較のバランスが取れます。
価格だけで判断せず、提案内容を読み解きます。同じ要件でも各社の前提が違えば金額は変わるため、自社の課題を解決できる発注先かどうかを見極めます。
実績・技術力・連携対応力の評価
確認したいのは、自社と近い業種・規模での改修実績、希望するプラットフォームへの精通度、基幹やWMSとの連携経験の豊富さです。実績は件数よりも、どんな課題をどう解決したかを具体的に語れるかで見ます。
過去に担当した案件の体制や、想定外のトラブルへの対応も質問します。その回答から、技術力と現場対応力を把握できます。
公開後の運用や内製化の支援、集客から物流まで相談できるかも、評価軸に加えます。構築後も伴走してくれる発注先であれば、改修後の事業成長を見据えた提案が期待できます。
責任分界点の合意と「連携できるの罠」
提案段階で「外部システムと連携できます」と言われても、そのまま受け取るのは危険です。むしろ、どのデータをどの方式で連携するか、どこまでリアルタイムにするかを具体化しておきます。
仕様が曖昧なままだと、後工程で想定外の追加開発が発生することがあります。これが「連携できるの罠」です。そうならないよう、発注時に自社とベンダーの責任分界点を文書で合意し、契約書や仕様書に明記します。
基幹側の改修、データ仕様の確定、テストデータの用意は、それぞれ誰が担うかを決めておきます。分担を明確にしておくと、トラブルが起きたときに責任を押し付け合う事態を防げます。
ベンダー丸投げを防ぐ発注側マネジメント
外注後に任せきりにすると、現場に合わないシステムになったり、ベンダーへの依存が深まったりします。改修を成功させる決め手は、発注側がプロジェクトを主体的に動かすことです。
週次定例・課題管理表・成果物承認の運用
発注側のPMは、週次定例、課題管理表、成果物の承認を運用します。定例では進捗や課題、意思決定事項を確かめ、課題管理表で担当者と期限をまとめて管理します。
要件定義書や設計書、テスト結果は、内容を理解してから承認します。形式的に承認すると認識のずれを招くため、中身を精査し、合意してから次の工程へ進みます。
専任のPMを置かなくても、こうした運用は進められます。ただし、社内の推進役は1名を明確に決めておくことが望ましいです。
切り戻し基準・段階移行・Fit to Standard
公開時の復旧手段や移行方法、標準機能への業務の合わせ方は、公開前に確かめておきます。
- 切り戻し基準：重大障害時に旧システムへ戻す条件を「フォールバック基準」として事前に合意します。
- 段階移行：BtoB ECなどでは、主要顧客や一部商品からテスト運用する方法が有効です。
- Fit to Standard：過剰なカスタマイズを避け、パッケージやSaaSの標準機能に業務を合わせると、開発費と将来の保守費を抑えられます。
切り戻し基準が曖昧だと、障害時の判断が迷走して被害が広がります。
標準機能に業務を合わせるには、社内のやり方も変える必要があります。だからこそ、現場への説明と合意形成を丁寧に進め、発注側が社内への浸透を主導することが定着の分かれ目になります。
契約・支払い条件の注意点
発注先が決まったら、契約条件とスコープを細かく確かめます。見積もりの総額だけで契約すると、想定外の費用や責任範囲のずれにつながります。
要件定義費・構築期間中の保守費の扱い
要件定義フェーズは、別費用になる場合があります。品質を左右する工程で、数十万円から数百万円かかることもあるため、見積もりに含まれるか、別契約になるかを見極めます。
構築期間中も既存システムの運用は続くため、保守費が二重に発生していないかを確かめます。あわせて、支払いは着手金・中間金・検収後の残金の比率を決めておきます。
検収の条件と、何をもって完了とするかは、契約書に明記します。基準が曖昧だと、品質に不満があっても支払いを止めにくくなります。そのため、発注側と開発会社の双方を守れる条件にしておく必要があります。
データ移行・SEO引き継ぎの契約スコープ
データ移行とSEO引き継ぎは、契約スコープに明記しておきます。URLが変わる場合、301リダイレクトの設定が不十分だと、検索評価や流入を失い、売上が急落する恐れがあります。
顧客・商品・注文履歴の移行範囲と、リダイレクト設定の担当は、契約で確定させます。また、会員パスワードは暗号化方式の違いから引き継げないことが多いため、移行後に顧客へ再設定を案内する必要があります。
パスワードの再設定を促すキャンペーンやポイント付与など、離脱を防ぐ業務計画の役割分担も決めておきます。さらに、会計データの突合が不足して残高が合わなくなる事態に備え、移行後の検証手順も範囲に含めます。
まとめ
発注の成否は、ベンダーに声をかける前の準備でおおむね決まります。目的とKPIを言葉にし、Must/Wantで要件を分けて、自社の規模に合う発注先を選びます。
RFPを作って相見積もりを取ったうえで、発注側がプロジェクトを主導します。丸投げを避け、責任分界点や切り戻し基準、データ移行とSEO引き継ぎを契約に明記すれば、費用の膨張やトラブルを抑えられます。
発注は、3〜5年先の事業成長を見据えてパートナーを選ぶことでもあります。この記事のポイントを起点に、自社主導で納得できる発注を進めてください。
▼全体ガイドの記事
・通販サイト/システム改修の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。