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

通販サイト開発の外注は、発注形態を理解したうえで、要件を整理してRFPを作り、発注先を比べて選び、契約と品質管理へ進むのが基本です。

発注の進め方を誤ると、要件の認識ズレやコスト超過、リリース遅延につながります。本テーマの全体像は次の記事にまとめています。

▼全体ガイドの記事
・通販サイト/システム開発の完全ガイドをご覧ください。

外注・発注を成功させるための基礎知識

通販サイトの開発を外注する前に、発注の基本的な仕組みと考え方を理解しておきます。契約形態の選び方や内製と外注の使い分けは、プロジェクトを進めるうえで前提になる基礎知識です。

  • 発注形態:請負、準委任、SESの責任範囲と進め方の違い
  • 発注先選び:開発実績、提案、見積、保守体制をどう見るか
  • 契約と品質:要件、契約条項、品質管理、SLAの取り決め

発注形態の種類(請負・準委任・SES)

通販サイトの開発を外注する際は、主に「請負契約」「準委任契約」「SES(システムエンジニアリングサービス)契約」の3種類から形態を選びます。

特徴を理解したうえで、自社の開発ニーズに合う形態を選ぶことが大切です。

  • 請負契約:開発会社が完成した通販サイトを成果物として納品することを約束する契約です。
  • 準委任契約:設計・開発・テストなどの業務を誠実に遂行することを約束する契約で、成果物の完成は保証されません。
  • SES(システムエンジニアリングサービス)契約:開発会社のエンジニアを一定期間、発注者の指揮命令のもとで稼働させる契約形態です。

請負契約では、「〇〇の機能を持つ通販サイトを〇月末までに納品する」のように成果物と納期を定めます。発注者は成果物に対して支払うため費用が見えやすく、成果物の完成責任は受注者側にあります。請負契約は、仕様変更が起きると追加費用が生じやすく、途中での要件の追加や変更もしにくいため、要件が固まっている中〜大規模の通販サイト開発に向く契約形態です。

準委任契約とSESは、請負とは仕組みが違うため、向く場面と注意点を分けて見ておく必要があります。

  • 準委任契約の報酬:月単位の工数(人月)に対して支払うのが一般的です。
  • 準委任契約が向く場面:要件が固まっていない段階やアジャイル開発で、仕様変更にも柔軟に対応しやすいです。
  • 準委任契約の注意点:費用が青天井になるおそれがあるため、工数の上限設定と定期的な費用確認が欠かせません。
  • SESが向く場面:開発の進め方を細かく管理したい場合に有効で、自社にPMやエンジニアが在籍し、特定のスキルを持つエンジニアを補強したい場合にも使われます。
  • SESの注意点:エンジニアの確保・管理コストが発生するほか、労働者派遣法との関係に注意が必要です。

内製と外注の使い分けポイント

通販サイトの開発を内製にするか外注にするかは、事業戦略・技術力・コスト・スピードの観点から総合的に判断する必要があります。

内製では、開発ノウハウが社内に蓄積されるほか、要件変更へ即時に対応でき、長期的には外注コストを削減できる可能性があります。

  • 内製の課題:優秀なエンジニアの採用・確保が難しく、社内リソースがボトルネックになりやすいです。さらに、最新技術へのキャッチアップに時間とコストがかかります。
  • 外注のメリット:専門知識を持つエンジニアをすぐに活用でき、開発スピードが速いうえ、社内リソースをコア業務に集中させられます。
  • 外注のリスク:認識ズレによる品質問題のリスク、外注依存による内部ノウハウの喪失、継続的なメンテナンスコストの発生などが挙げられます。

内製が適しているのは、ECが事業の中核で継続的なシステム改善が欠かせない企業(例:大手EC事業者・D2Cブランド)や、社内にエンジニア組織がすでに整っている企業です。

一方、外注が適しているのは、初めて通販サイトを構築する企業、社内に開発リソースがない企業、特定機能の追加やリニューアルを限定的に行いたい企業です。多くの企業では、「コア機能の開発は外注し、運用・改善は内製エンジニアが担う」というハイブリッド型が現実的な選択肢となっています。

ポイント

契約形態は、要件が固まっていれば請負、固まっていなければ準委任が候補になり、社内にPMやエンジニアがいて人員だけを補うならSESが候補になります。

発注先の選び方と比較ポイント

通販サイト開発の発注先を、大手SIer・ITコンサルティング会社、中規模Web・EC開発専門会社、小規模制作会社・フリーランス、オフショア開発会社の4種類に分けた図。
会社の規模や得意分野から候補を絞り込めます。

通販サイト開発の外注先は、種類ごとに得意な規模・技術・費用感が大きく異なるため、種類を理解したうえで比べることが大切です。

自社の要件に最も合う発注先を選ぶことが、プロジェクトの成否を左右します。

開発会社の種類と特徴

外注先は規模や得意分野によって4種類に分かれ、それぞれ向く案件が違います。

  • 大手SIer・ITコンサルティング会社:豊富な開発実績と高い技術力で、大規模・複雑なシステム開発に強みがあります。
  • 中規模Web・EC開発専門会社:通販サイトの開発実績が豊富で、カートや決済、在庫管理などEC特有の機能への理解が深い会社です。
  • 小規模制作会社・フリーランス:比較的低コストで柔軟に対応でき、小規模・シンプルな通販サイトや既存サイトの部分的な改修に適しています。
  • オフショア開発会社:国内開発に比べてコストを大幅に抑えられるのが最大のメリットで、ベトナム・インド・中国などに多くの会社があります。

大手SIerは、PMO支援から要件定義・設計・開発・運用まで一貫して対応できます。ただし、費用が高く、中小企業の予算では対応してもらいにくい場合があるため、年商数十億円以上の大企業が基幹ECシステムを刷新する際に適しています。

中規模Web・EC開発専門会社は、コスト・品質・コミュニケーションのバランスが良く、中小〜中堅企業の通販サイト開発に最も適した選択肢です。ShopifyやMagento、ECCUBEなどへの対応実績が豊富な会社も多いです。ただし、組織力や対応リソースの限界から、大規模開発や複雑な要件には対応が難しい場合があるため、過去の実績や口コミを十分に調べて信頼性を確かめる必要があります。

一方で、オフショア開発には、言語の壁・時差・文化的な違い・品質管理の難しさといったリスクもあるため、国内PMがオフショアチームを管理するラボ型開発やブリッジSEの活用が一般的です。予算を抑えたい企業が補助的に活用するケースが多いです。

提案・見積評価のチェックポイント

複数の開発会社から提案・見積もりを取得したら、価格の安さだけで判断すると、品質や対応力の不足によるトラブルにつながりやすいため、総合的に評価します。評価の観点は、次の5つです。

  • 要件の理解度:最も重要な評価軸で、提案書から自社の要件・課題を正しく理解しているかを見ます。
  • EC開発の実績:類似した規模・業種の通販サイト開発実績があるか、参考事例(ポートフォリオ)を提示してもらえるか。
  • 見積もりの内訳:費用の範囲が明確か、設計・開発・テスト・初期設定・データ移行・保守運用などフェーズごとの費用が記載されているか。
  • 開発スケジュール:希望するリリース時期に対応できるか、マイルストーンの設定が現実的か。
  • 体制と対応:PM・デザイナー・フロントエンド・バックエンド・インフラの役割が明確か、担当者のスキルが要件に合うか。

体制と対応のうち、コミュニケーション対応では、問い合わせへのレスポンス速度、担当者の説明のわかりやすさ、質問への対応姿勢を見ておきます。開発中は確認や相談のやり取りが続くため、ここが弱いと行き違いや確認待ちが増えるおそれがあります。

理解度が低い提案は、開発開始後に認識ズレが生じるリスクが高まります。

複数社と打ち合わせて、パートナーとしての適合性を見極めることが大切です。

ポイント

発注先は、要件の規模と予算に合う開発会社の種類から絞り込みます。そのうえで、提案では要件の理解度と見積もりの内訳を比べます。

発注プロセスの進め方

通販サイト開発の発注プロセスを、要件整理、RFP作成、発注先選定、契約締結、プロジェクト管理の順に示す図。
要件を整理してから契約と管理へ進みます。

発注プロセスを正しい手順で進めると、開発会社との認識ズレを防ぎ、プロジェクトをスムーズに進められます。

通販サイトの外注では、「要件整理→RFP作成→発注先選定→契約締結→プロジェクト管理」という一連の流れを着実に踏むことが大切です。

要件整理とRFP作成

要件整理は発注プロセスの最初のステップで、不十分なまま外注すると見積もりの精度が下がり、仕様変更が頻発するリスクが高まります。そのため、開発会社に依頼する前に自社で整理しておくことが不可欠です。

まず、販売する商品の種類・数量と、ターゲットユーザーの想定アクセス数・注文数を整理します。

機能面では、商品管理・カート・決済が中心です。そのほかに、会員登録、マイページ、在庫管理を整理します。受注管理と配送管理、返品対応も含めます。さらに、メール配信、クーポン、ポイントも対象になります。

外部連携については、連携する外部システム(ERP・WMS・CRM・POSなど)を整理します。

セキュリティ要件(PCI DSS・SSL・個人情報保護法への対応)も決めておく必要があります。

自社では、デザインの方向性(既存サイトの継承・フルリニューアル)、希望リリース時期と予算上限、保守・運用体制(リリース後のサポート要件)も整理します。

RFP(Request for Proposal:提案依頼書)は、自社の要件を開発会社に正式に伝えて提案・見積もりを依頼する文書です。要件をA4で3〜5枚程度にまとめておくと、作成がスムーズになります。

RFPには、自社の要件に加えて、開発会社が提案と見積もりを出すための条件も書き込みます。

  • 背景・目的と事業概要:プロジェクトの背景・目的、通販サイトの事業概要・対象商品・販売チャネル
  • 機能と品質の要件:必須機能と優先度の区別を示した機能要件一覧、パフォーマンス・セキュリティ・可用性・拡張性の非機能要件
  • 外部連携とスケジュール:外部連携要件、フェーズ別の目標日程(開発スケジュールの希望)
  • 予算と提出・選定の条件:予算の目安、提案書・見積書の提出形式と期限、選定基準(評価軸の明示)

RFPが詳細であるほど各社の提案の質が高まって比較しやすくなりますが、自社だけで作るのが難しい場合は、ITコンサルタントや発注支援サービスも選択肢の一つです。

契約締結と品質管理の方法

発注先を選んだら、契約書の内容を慎重に確認してから契約を締結します。契約書は口頭の合意内容を法的に担保する文書で、不備があるとトラブルの原因になります。特に確認したいのは、次の4点です。

  • 開発範囲(スコープ)の明確化
  • 成果物の定義と検収条件
  • 知的財産権(著作権)の帰属先
  • 瑕疵担保責任の期間・範囲

ほかにも、次の項目が挙げられます。

  • 追加費用発生時の対応フロー
  • 秘密保持義務(NDA)
  • 解除条件と違約金
  • 個人情報の取り扱い

これらが契約書に明記されていない場合は、必ず追記・修正を求めます。

品質管理は開発会社任せにせず、発注者も積極的に関わり、週次や隔週の進捗報告ミーティングで進捗・課題・リスクを共有します。

画面モックアップや中間成果物を定期的に確認して要件とのずれを早期に修正するとともに、リリース前の単体・結合・負荷・セキュリティテストが実施されているかを確かめます。発注者側でもUAT(ユーザー受入テスト)を行い、実際の業務フローに沿って動作を確かめることが推奨されます。テスト結果の記録やエビデンスを残しておくと、引き渡し後のトラブル対応がスムーズになります。

ポイント

要件が曖昧なまま契約や開発に進むと、認識ズレやコスト超過が起きやすいため、RFPと契約書で要件と範囲を先に確定させておきます。

発注時のリスクと対策

通販サイトを中央に置き、RFPと要件定義書、追加費用の承認フロー、マイルストーン、セキュリティ診断で外注時のトラブルを防ぐ構成を示す図。
要件・費用・進捗・安全性をそれぞれ事前に整えます。

通販サイトの開発を外注する際には、さまざまなリスクが伴います。リスクを事前に把握し、適切な対策を講じることで、トラブルを未然に防げます。過去に外注で失敗した企業の多くが、リスク管理の不足を原因として挙げています。

よくあるトラブルと回避策

通販サイトの外注で起きやすいトラブルは、次の4つです。

  • 要件の認識ズレ:発注者と開発会社の認識が食い違い、納品物が期待と大きく異なるケースです。最も多いトラブルです。
  • コスト超過:途中の仕様変更や追加要件、想定外の工数増により、当初の見積もりを大幅に超えるケースがあります。
  • リリース遅延:開発リソースの不足や技術的課題、コミュニケーション不足が原因で起こります。
  • セキュリティ脆弱性:決済情報や個人情報を扱うため攻撃の標的になりやすく、情報漏洩や不正注文の被害につながります。通販サイト特有のリスクです。

要件の認識ズレには、RFPと要件定義書を詳細に作って開発着手前に双方でレビュー・合意し、ワイヤーフレームや画面設計書で視覚的に確認することが有効です。コスト超過には、契約書に追加費用の承認フローを明記し、仕様変更の影響範囲を都度見積もってもらうとともに、予算に10〜20%程度の予備費を設けておくことが挙げられます。

リリース遅延には、プロジェクト開始時にマイルストーンを設定して週次で進捗を確認し、兆候が見えたらリソース追加や優先順位の見直しを速やかに行います。セキュリティ脆弱性には、セキュリティ要件(PCI DSS準拠・脆弱性診断の実施)を契約書に明記し、リリース前に第三者によるセキュリティ診断を実施することが推奨されます。

開発会社の途中撤退・倒産は稀ですが、ソースコードが引き渡されないおそれがあるため、Gitリポジトリの権限を発注者も持ち、マイルストーンごとに部分成果物を受け取ることが有効です。

契約書・SLAで守るべき事項

契約書とSLA(Service Level Agreement:サービスレベル合意書)を適切に整備することは、通販サイトの開発・運用におけるリスク管理の基本で、トラブル時の「よりどころ」にもなります。契約書には、次の項目を定めておきます。

  • 成果物の定義と検収条件:何をもって開発完了・検収完了とするかを明確に定義します。
  • 瑕疵担保責任:不具合の修正対応期間は、一般的に3〜12ヶ月です。
  • 著作権の帰属:システム・ソースコード・デザインの著作権の発注者への帰属を明記します。
  • 秘密保持義務(NDA):事業情報・個人情報・技術情報の取り扱い。
  • 個人情報保護:開発会社が顧客の個人情報を適切に管理する義務。

EC事業ではユーザーの氏名・住所・決済情報を扱うため、この規定は特に欠かせません。SLAは主に運用・保守フェーズで重要になります。繁忙期(年末年始・セール期間)のアクセス集中や決済の安定稼働は事業に直結するため、次の項目を明記します。

  • 稼働率の保証:例:月次稼働率99.9%以上
  • 障害発生時の応答時間:例:重大障害は1時間以内に連絡
  • 復旧時間の目標:例:重大障害は4時間以内に復旧
  • 定期メンテナンス:実施方法と通知タイミング
  • セキュリティインシデント発生時の対応フロー

SLA違反時のペナルティ(例:サービスクレジットの付与)も明記しておくと、開発会社の責任を明確にできます。

ポイント

トラブルに備えて、対策は契約書とSLAに書いておき、開発の前に双方で合意しておくと、発生時の判断に迷いにくくなります。

まとめ

ここまで、通販サイト開発の発注について、基礎知識から発注先の選び方、発注プロセス、リスク対策までを順に整理しました。

発注形態(請負・準委任・SES)の特徴を理解し、自社の開発ニーズに合う形態を選びます。内製と外注の使い分けでは、自社の技術力・コスト・スピードを総合的に判断します。発注先は、大手SIer・中規模EC開発専門会社・小規模制作会社・オフショアの特徴を踏まえ、予算・規模・要件に合う会社を選びます。

提案・見積もりは、要件理解度・EC開発実績・見積内訳・スケジュール・体制と対応の5点から総合的に評価します。発注プロセスは、要件整理→RFP作成→発注先選定→契約締結→プロジェクト管理の順に進めます。よくあるトラブル(要件認識ズレ・コスト超過・リリース遅延・セキュリティ脆弱性)には、事前に対策を講じておくことが成功の前提になります。

契約書とSLAを適切に整備すると、品質・運用水準を法的に担保でき、リスクを最小限に抑えられます。

通販サイトの開発外注は、適切な準備と正しいプロセスを踏むことで、事業成長を加速させる強力な手段になります。本記事で紹介したノウハウを参考に、外注プロジェクトを成功させてください。

発注先の選定や外注支援についてお困りの場合は、専門家への相談も積極的にご活用ください。

▶ 無料相談・お問い合わせはこちら

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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