EC/通販業界のシステム開発の発注/外注/依頼/委託方法について

EC・通販システムの発注は、業務を整理し、要件と契約を決め、委託先を選ぶ順に進めると、運用に合う仕組みを選びやすくなります。業務の流れが見えていれば、発注形態や委託範囲も落ち着いて判断できます。

Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

EC・通販業界のシステムの概要

EC・通販システムは、販売画面だけでなく、受注から返品や再購入までの業務をつなぐ仕組みです。

経済産業省の調査では、2024年の国内BtoC-EC市場は26.1兆円で、前年比5.1％増でした（出典：経済産業省「令和6年度電子商取引に関する市場調査」、2025年）。

販売チャネルが増えるほど、個別のツールを入れるだけでは足りず、データの流れも設計しなければなりません。

OMS・WMS・カート・POSの組み合わせ

各システムの役割を分けると、どの業務をどこで連携させるかが見えてきます。

• カート・ECモール：商品の表示と注文の受付です。
• OMS：複数チャネルの注文を集約し、在庫引当や出荷指示、キャンセルを管理します。
• WMS：入荷から棚入れ、ピッキング、検品、梱包、出荷までの倉庫作業です。
• POS：実店舗の売上、在庫、会員情報を扱う仕組みです。
• CRM・MA：購入履歴に応じたメールやLINEの配信を支えます。

CRMやMAを加えると、カゴ落ち通知やレコメンドを含む顧客体験も設計できます。

在庫の分類と設計

在庫を「ある」「ない」だけで管理すると、取り置き品をECが販売したり、予約分を通常注文に引き当てたりする事故が起きます。

• 店舗在庫：店舗に置いている商品。
• 倉庫在庫：倉庫に保管している商品。
• EC販売可能在庫：ECで販売できる数量。
• 予約在庫：予約注文のために確保した数量。
• 引当済み・不良在庫：注文に割り当てた数量と、販売対象から外す商品。

店舗で取り置いた商品をECが販売すると、在庫数が合わなくなるおそれがあります。

リアルタイム同期では、販売時に全在庫を減らすか、安全在庫を残すかで仕様と費用が変わります。

EC・通販システムの発注形態の選び方

発注形態は、既存サービスの利用、サービス連携、独自開発の中から、業務に合うものを選びます。競争力に直結する業務は独自開発し、一方で標準化できる業務はSaaSやパッケージに寄せると、投資と納期の釣り合いを取りやすくなります。

SaaS型カート・OMS・WMSを使う場合

注文数が増えても業務フローが標準に近い企業では、SaaS型カートやOMS・WMSの組み合わせが候補になります。

• 初期開発：費用を抑えやすい傾向があります。
• 更新対応：機能追加やセキュリティ更新を、自社だけで抱えにくくなります。
• 継続費用：月額、従量課金、APIや端末の費用を含めます。

比較するときは、出荷件数課金、ハンディ端末レンタル、追加連携を含めた5年間の総額で見ます。

たとえば、LOGILESSはOMSとWMSを一体化し、10分に1回の出荷指示連携を行うサービスとして知られています。料金体系や対応範囲は、契約前に最新の資料で確かめておく必要があります。

既存基幹システムと連携する独自開発

古い基幹システムやPOSを使い、ShopifyなどのSaaS型カートやモール、倉庫をつなぐ場合は、連携基盤が必要になります。

• データの正を決める：商品、価格、在庫、注文、顧客、配送状況の情報を整理します。決めずにAPIをつなぐと、二重登録や更新漏れが起きます。
• 代替連携を設計する：APIがない場合は、CSV、RPA、データベース連携を検討します。

代替手段を選んだ場合も、データがどこまで即時に届くかと、障害時にどう復旧するかを設計しておく必要があります。

フルスクラッチを選ぶ判断基準

独自の価格優先順位、定期購入の同梱物、店舗ごとの取り置きなどが競争力に直結する場合は、フルスクラッチや大幅な拡張が有効です。

• 価格：独自の価格優先順位を扱います。
• 定期購入：同梱物を個別に設計します。
• 店舗：取り置きを店ごとに扱います。
• 在庫：複数倉庫の引当を制御します。
• 越境EC：関税計算を業務に合わせます。

独自仕様が増えるほど、法改正やモール仕様変更への追従費用も増えます。そこで、開発会社には、標準機能、個別開発、将来廃止できる範囲を分けて提案してもらいます。

発注前のRFP・要件整理の決定事項

RFPは開発会社への依頼資料であるとともに、自社の業務を整理する資料でもあります。まず、現状と困りごと、実現したい成果を記します。制約と優先順位も書いておくと、各社が同じ前提で提案できます。

現状業務と例外オペレーションの洗い出し

現状業務を洗い出すと、通常の処理だけでは見えない要件もRFPに反映できます。

• 販売量：注文数と繁忙期のピークを整理します。
• 運用範囲：チャネル数、倉庫数、出荷締め時間。
• 対応条件：キャンセル可能時間、返品率、問い合わせ件数を確認します。

本部が商品マスタを厳しく統一したくても、店舗では値引きや取り置きが起きます。また、店間移動や予約の取り消しも例外にあたります。これらをRFPに書いておかないと、本番で在庫が合わなくなるおそれがあります。

連携・セキュリティ・データ要件の具体化

連携要件には、接続先だけでなく、データと運用の条件も書きます。

• データ連携：項目と方向を決め、頻度と失敗時の再送も定めます。
• 重複と記録：二重処理を防ぐ方法と、ログの保存期間。
• 決済：カード情報を自社で持つか、外部の代行サービスに委ねるかを見極めます。
• 決済機能：3-D Secureと不正検知を中心に、返金や継続課金も確認します。

EMVCoは、EMV 3-D Secureを、カード非対面取引の不正防止とEC決済の安全性向上に使う仕組みと定義しています。また、2025年8月に2.2.0〜2.3.1.1の仕様書を公開しました（出典：EMVCo「EMV 3-D Secure」、2025年）。決済は後から付け足すと再設計になりやすいため、RFPの段階で要件に含めておきます。

必須・希望・将来の要件の優先順位

すべての要望を初回リリースに詰め込むと、費用も納期も膨らみます。

• 必須要件：在庫、受注、出荷、決済など、事業継続に必要な機能です。
• 希望要件：CRM、レコメンド、LINE通知など、効果を測りながら追加します。
• 将来要件：多通貨や多言語、複数国配送、関税計算への備えです。

将来要件は、今すぐ機能を作らなくても、APIとデータ構造だけ先に確保しておきます。

契約形態と開発の進め方の選び方

ECでは販売施策や物流運用が変わり、発注時に仕様を固定できない場合があります。そのため、契約は成果物の明確さと変更の見込みで選びます。発注側の意思決定が進められるか、受入れ体制を組めるかも判断材料になります。

請負契約が向いているケース

請負契約は、合意した仕様のシステムを完成させて検収する形です。要件や納品物、納期、検収基準が固まっている開発で使いやすい契約です。

• 予算管理：完成と検収を前提にするため、要件が明確なら金額の見通しが立ちます。
• 変更時の扱い：追加要望は変更契約になりやすく、仕様の曖昧さは見積に上乗せされます。
• 価格差の目安：EC・小売では準委任契約より1.3〜1.5倍程度の場合があります。

請負と準委任の価格差は一般的な目安で、実際には要件の確度と責任の分け方によって変わります。

準委任契約が向いているケース

準委任契約は、一定期間の業務支援や専門知識の提供を受ける契約です。

• 企画・設計：要件定義、アーキテクチャ設計、既存システム調査の場面に合います。
• 開発：アジャイル開発など、変更を伴う作業で使えます。
• 改善：リリース後の継続的な改善を依頼できます。

発注側が優先順位を決める一方で、受託側は進捗や課題、工数を透明に報告します。

完成責任や品質基準、障害対応は、契約書で明確にします。

知的財産権と再委託の条件も、明確にしておきます。

要件定義から運用までの段階的な進め方

現状調査から運用改善までを段階に分けて進め、受入れテストでは実際の業務を確かめます。

1. 現状調査と要件定義を行います。
2. 基本設計、詳細設計、開発を進めます。
3. 連携テスト、業務テスト、データ移行を行います。
4. リリース後に運用を確認し、改善します。

全社導入の前に、1倉庫・1チャネル・限定商品でパイロットを行うと、不具合を早く見つけやすくなります。

テストでは正常系に加え、キャンセルや欠品などの例外も確認します。二重注文と決済失敗も、試す対象になります。

さらに、返品と返金は業務シナリオで試します。配送遅延やモール停止時の復旧も、同じように確かめます。

EC・通販システム外注の費用相場

EC連携を含む中規模開発は700万〜1,800万円が目安です。

さらに、EC・モールの完全統合、複数倉庫、複雑な販促ロジックを含む大規模開発では、1,800万〜4,000万円以上が目安になります。ただし、これは公的統計ではなく、開発範囲と体制を前提にした実務上の相場感です。

既製サービスの費用は、初期費用と月額費用に分かれます。一方で、独自開発では要件定義から保守までの人件費が大きな割合を占めます。

費用の中心となる人件費と連携工数

費用の中心は各工程の人件費で、接続先や業務の分岐が増えるほど、連携工数も増えます。

• 工程：要件定義、PM、UI・業務設計を含みます。
• 開発・運用：バックエンド、フロント、移行、テスト、インフラ、保守を含みます。
• 単価：中堅エンジニアは月額60万〜80万円です。
• 上流層：上流・マネジメント層は月額80万円以上です。

また、上流工程が開発費の40〜60％を占める場合もあります。さらに、モールや倉庫の数、POS・基幹との接続本数も工数に影響します。在庫同期の頻度や価格ルール、返品・返金の分岐が増えると、連携テストと障害対応も増えます。

初期費用以外のランニングコスト

月額料金だけでなく、利用量や運用に応じて発生する費用も合算して見ます。

• サービス費：月額利用料、従量課金、決済手数料を含めます。
• システム費：クラウド、監視、保守、脆弱性対応を見ます。
• 外部費用：API料金や端末レンタル費を加えます。

出荷量が増えると単価の上昇が利益を圧迫するため、複数の数量帯で試算しておきます。たとえば、月300件、1,000件、5,000件などを比べて、将来の費用を見積もります。

国土交通省は、担い手不足や時間外労働上限規制を背景に、2025年4月から物流改正法の一部を施行しました（出典：国土交通省「物流改正法の一部を施行」、2025年）。

配送計画や再配達の削減に役立つ機能も、投資効果に含めて考えます。

補助金の公募条件と対象経費

SaaS導入や業務効率化では、デジタル化・AI導入補助金の対象になる場合があります。

• 対象経費：受託開発費がすべて対象になるとは限りません。
• 申請要件：申請時期、SECURITY ACTION、公募要領、登録ITツールを確認します。
• 発注時期：申請者要件と交付決定前の契約可否を確認し、補助金を前提に日程を組みません。

2026年、IPAはデジタル化・AI導入補助金を案内しています（出典：IPA「デジタル化・AI導入補助金」、2026年）。中小企業や小規模事業者のITツール導入費の一部を補助する制度です。

委託先選定と見積比較のポイント

委託先は、EC・店舗・倉庫をまたぐ業務への理解と提案条件を比べて選びます。まず、同じRFPを各社に渡し、前提や対象外、追加費用に加えて、納期や体制、リスクも同じ形式で回答してもらいます。

安い見積では、データ移行やテストが含まれない場合があります。教育や障害連絡、モール変更対応も、抜けがないかを見ておく必要があります。

EC・物流・店舗の実績

ECサイトの制作件数だけでなく、受注から出荷までを改善した経験も確かめます。

• 販売連携：モールや店舗POS、会員・ポイントの経験を聞きます。
• 物流運用：複数倉庫や返品、定期購入にどこまで対応しているかを確かめます。
• 海外対応：越境ECをどこまで担当できるかを確かめます。

さらに、提案の段階では、現場ヒアリング担当や設計責任者、開発責任者が参加するかも見ておきます。契約後に別のチームへ引き継ぐ場合は、体制と引継ぎ方法を書面で確認します。

見積書の工数・前提・対象外の読み方

「システム開発一式」では比べられないため、工程ごとの工数と単価を確認します。

• 工程：要件定義、設計、開発、連携、移行、テストを分けます。
• 運用準備：PM、インフラ、教育、保守を確認します。
• 工数根拠：API、画面、権限、移行件数、テスト数を聞きます。

また、契約前には、追加要望の単価と仕様変更の承認方法を確かめておきます。あわせて、保守時間や障害の優先度、モール仕様変更の費用も見積条件に含めます。

発注後の失敗リスクと契約前の備え

責任者の不在や現場参加の遅れ、データ未確認、受入れ基準の不足などの準備不足が、失敗につながります。

• 発注側の体制：業務・システム責任者、店舗・倉庫の代表、経営判断者を置きます。
• 週次の管理：課題と意思決定を記録し、受託側に課題管理表、変更管理表、テスト計画を求めます。
• 変更とリリース：受託側にリリース判定基準を提出してもらいます。

双方がどこまでを受け持つかが見えていれば、問題が起きたときに原因探しで時間を取られにくくなります。

年商規模別のシステム投資ロードマップ

投資額は、売上だけでなく、注文数や粗利、人件費で判断します。欠品損失やチャネル数、成長計画も、あわせて見ます。リサーチの目安では、年商1億円、10億円、30〜100億円の壁ごとに必要な仕組みが変わります。

今の課題を解消しながら、次の成長段階で作り直さずに済むデータ構造を残しておきます。

年商1億円前後の受注・在庫・出荷の標準化

年商1億円前後の段階では、表計算や手作業で注文を処理していることがあります。

• 標準業務：SaaS型カート、OMS、WMSを使い、受注から配送通知までを安定させます。
• 投資効果：複雑なCRMや独自価格より先に、売り越しや出荷遅延、入力ミスを減らします。
• 将来への備え：店舗連携や定期購入を見越して、商品コードと顧客IDを慎重に設計します。

年商10億円前後のチャネル統合と業務分担

年商10億円前後では、モール、自社サイト、店舗、卸が増え、在庫や顧客データの分断が課題になります。

• 受注と在庫：OMSで受注を統合し、在庫を店舗、倉庫、EC、予約、引当、不良在庫に分けて、販売可能数を計算します。
• 価格と会員：会員ランク、ポイント、通常・セール・店舗限定価格の優先順位を統一します。
• 繁忙期の条件：セール初日の集中や欠品時の代替、キャンセル可能時間をRFPに含めます。

年商30〜100億円の基幹・物流・顧客データの統合

複数の倉庫や店舗、ブランド、サブスク、海外販売が重なると、部分的な導入だけでは全体を整えにくくなります。

• 基幹データ：ERPや基幹、OMS、WMSなどの各システムをAPIでつなぎ、管理元を決めます。
• 顧客対応：返品・交換・返金をCS、物流、決済に連動させ、効果を売上、粗利、LTVで測ります。
• 移行方法：ドメイン単位で移し、止められない業務を段階的に切り替えます。

よくある質問

発注では、機能だけでなく、責任の分け方と運用後の改善方法も見ておきます。

ECシステムの外注費用は最低いくらからですか？

依頼する範囲によって費用は変わるため、規模別の目安を見ておきましょう。

• 小規模：既存SaaSの初期設定や小規模連携は、数十万〜数百万円からの場合があります。
• 中規模：複数チャネル、在庫統合、POS・基幹連携を含む開発は、700万〜1,800万円が目安です。
• 大規模：完全統合や複数倉庫、複雑な販促ロジックを含む開発は、1,800万〜4,000万円以上です。

請負契約と準委任契約はどちらが良いですか？

仕様と納品物が固まった開発は請負で、要件定義や改善など変化する業務は準委任で進めます。ECでは、要件定義を準委任、仕様が確定した開発を請負に分ける方法もあります。

そのうえで、成果物と検収の条件、変更管理の方法を契約で確認します。障害対応と保守の範囲も、契約書に明記しておきます。

RFPは自社だけで作成できますか？

自社でも作成できますが、現場ヒアリングとデータ確認を行い、例外処理まで書いておくことが大切です。RFPには、優先順位や予算上限、希望時期、既存システムの制約を記載します。ただし、要件がまとまらない場合は、第三者に現状調査とRFP作成を頼んでから、開発会社を選ぶこともできます。

SaaSとフルスクラッチはどう使い分けますか？

業務が標準的で早く導入したい場合は、SaaSやパッケージが向いています。一方で、独自の価格や在庫引当、定期購入などが競争力の中心なら、独自開発を検討します。

どちらを選ぶ場合も、初期費用に加えて、5年間の月額や追加開発、移行、保守、モール対応まで含めた総所有コストで比べます。

まとめ

EC・通販システムの発注では、在庫や受注、出荷の流れを洗い出します。決済、返品、顧客データの流れも、あわせて整理しておきます。

業務の複雑さに応じて、SaaSやパッケージ、連携開発、フルスクラッチの中から方式を選びます。中規模は700万〜1,800万円、大規模は1,800万〜4,000万円以上が費用の目安です。見積では工数や対象外、従量課金、保守を確かめ、RFPでは必須要件と将来要件を分けておきましょう。

最初の着手点

まず現場の担当者と、注文から出荷、返品までの業務フローを作ります。

1. 店舗、倉庫、EC、予約、引当、不良在庫を分けます。
2. 正しいデータを持つシステムを決めます。
3. 複数社に資料を渡し、実績、契約形態、5年間の総額、運用支援体制を比べます。

この順に進めれば、価格だけで判断せず、運用に合った発注につながります。

参考にした公式情報：経済産業省「令和6年度電子商取引に関する市場調査」、国土交通省「物流改正法の一部を施行」、IPA「デジタル化・AI導入補助金」、EMVCo「EMV 3-D Secure」です。

▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。