COLUMN
ECサイト構築・リニューアルを外注する前に整えておくべき要件定義の全手順
ECサイトの外注は、制作会社を探す前に要件定義を固めるのが順序です。要件が曖昧なまま選定に入ると見積もりを比べる軸が定まらず、「想定した機能がなかった」「追加開発で費用が倍になった」が起きます。
この記事は選定の観点をまとめたものです。自社の条件で比較したい場合は、3年総額の試算が早いです。
はじめに
ECサイトの構築やリニューアルを外注するとき、多くの担当者がまず「どの制作会社に頼もうか」「どのカートシステムがいいか」を調べ始めます。しかし、その順番は逆です。
要件が曖昧なまま制作会社の選定に入ると、見積もりの比較軸も定まらず、提案の良し悪しも判断できません。結果として、「想定していた機能がなかった」「追加開発で費用が倍になった」「公開後に制作会社と揉めた」という失敗につながります。これはスキルの問題ではなく、プロセスの問題です。
本記事では、ECサイト構築・リニューアルの外注を成功させるために「外注前」に整えておくべき要件定義の全手順を、制作会社の評価軸・見積もりの読み方・契約前チェックリストとあわせて、一連の流れで解説します。ECサイトの構築やリニューアルを控えた事業責任者・マーケティング責任者・DX推進担当の方に、実務で即使えるガイドとして活用いただければ幸いです。
なぜ外注前の要件定義が失敗を防ぐのか
要件が曖昧なまま進んだプロジェクトに何が起きるか
ECサイトの構築・リニューアルプロジェクトで失敗が起きる根本原因の多くは、「要件定義が不十分なままベンダー選定・発注に進んだこと」にあります。複数の視点から整理してみると、失敗のパターンは驚くほど一致しています。
まず頻繁に起きるのが、仕様変更による追加費用の発生です。「定期購入機能も当然入ると思っていた」「ポイント機能はオプションだと言われた」といったケースでは、発注側と制作会社の認識がそもそもズレています。この認識ズレは、要件を文書化していないことに起因します。
次に多いのがスケジュールの大幅遅延です。「社内で決まっていない部分が多すぎて、承認が取れず止まってしまった」というケースは、事業側の意思決定プロセスの整理が外注前に済んでいなかったことを意味します。制作会社がいくら優秀でも、発注側の準備が整っていなければプロジェクトは動きません。
さらに深刻なのは、公開後に「使えないサイト」が出来上がるケースです。デザインはきれいだが管理画面の操作が難しい、基幹システムとのデータ連携が想定より重い、スマホでの購入フローが複雑すぎてCVRが上がらない──こうした問題は、要件定義の段階で「何を優先するか」を明確にしていれば防げるものがほとんどです。
「RFP(提案依頼書)を作る」という一歩がすべてを変える
要件定義の成果物として最も重要なのがRFP(Request for Proposal=提案依頼書)です。RFPとは、発注側が制作会社・ベンダーに対して「自社のEC事業の目的・現状課題・必要な機能・スケジュール・予算感」などを明記した文書のことで、これを用意するだけで外注の質が根本から変わります。
具体的には3つの効果があります。一つ目は「比較の土俵を揃えられること」。RFPなしでは各社が自由に解釈して提案するため、見積もりの内容がバラバラで比較できません。RFPがあれば、同一条件での比較が可能になります。二つ目は「提案の質が上がること」。経験のある制作会社ほど、RFPの精度を見てクライアントの成熟度を判断します。質の高いRFPを出すと、それに応えようとして提案内容も自然とレベルが上がります。三つ目は「社内の意思統一が進むこと」。RFPを作るプロセス自体が、事業部・IT部門・経営層の認識ズレを炙り出す機会になります。
RFPを「難しそうなもの」と感じる必要はありません。最初は10〜15ページ程度の文書から始めれば十分です。次のセクションで、RFPに盛り込むべき要件定義の7項目を具体的に解説します。
要件定義の作り方──外注前に固めるべき7つの項目
以下の7項目を順番に整理することで、外注前に必要な要件定義が完成します。すべてを完璧に仕上げる必要はありませんが、最低限「①〜③」の3項目は外注前に固めておくことをお勧めします。7項目の全体像は次の表のとおりです。
| 項目 | 決めること | 外注前に | RFPに書く形の例 |
|---|---|---|---|
| ① 現状課題と目的 | なぜ今、構築・リニューアルするのか | 必須 | 課題を数字で3〜5行(CVR・処理時間・止まっている機能など) |
| ② 事業目標・KPI | 3年後の売上・受注件数・CVRなどの目標 | 必須 | 今と3年後の数字を並べた表 |
| ③ 機能要件の優先度 | 欲しい機能を「必ず必要」と「あればよい」に分ける | 必須 | フロント・バックオフィス・マーケティング別の機能一覧 |
| ④ 連携システム | 基幹・WMS・MA・決済のどれと、どうつなぐか | 推奨 | 連携先ごとの方式(API・CSV)と、仕様書の有無 |
| ⑤ データ移行 | 移すデータの範囲と、何年分をどう扱うか | 推奨 | 商品・会員・注文・ポイントごとの件数と移行の可否 |
| ⑥ 運用体制 | 公開後に誰が何をするか、どこを外部に任せるか | 推奨 | 担当者の人数と、社内・外部の役割分担 |
| ⑦ スケジュールと予算 | 動かせない公開日、初期費用と月額の上限、稟議のライン | 推奨 | 公開日(希望/期限)と、初期・月額・3年総額の上限 |
「推奨」の④〜⑦も、見積もりを依頼する前までには決めておくと、各社の提案を同じ条件で比べられます。
①現状課題と移行目的の言語化
「なぜ今、構築・リニューアルをするのか」を一文で言語化できるでしょうか。この問いに答えられない状態で外注に進むと、制作会社が「何を解決するためにサイトを作るのか」を理解できないまま設計が進んでしまいます。
現状課題は、できれば定量的な言葉で記しましょう。「CVRが業界平均の半分以下」「管理画面の操作に1件あたり平均5分かかり、月間受注3,000件の処理に支障が出ている」「現カートのバージョンアップが止まり、セキュリティ要件を満たせなくなっている」といった具合です。課題が具体的なほど、制作会社も的確な解決策を提案できます。
②事業目標・KPIの数値化(3年後の売上・件数・CVR目標)
リニューアル後に「何を達成したいか」を数値で設定します。具体的には、年間売上目標・月間受注件数・CVR・LTV・新規会員獲得数などが主なKPI候補になります。
重要なのは「3年後」を視点に置くことです。リニューアル直後ではなく、3年後の事業規模を想定することで、今必要なシステムの拡張性や将来のデータ量に耐えられるインフラ要件が見えてきます。「現在の月間受注は500件だが、3年後には5,000件を目指す」という前提があれば、選ぶプラットフォームも変わってきます。
③必須機能要件と優先度の仕分け(Must/Want)
欲しい機能をすべてリストアップした後、「Must(必ず必要)」と「Want(あればよい)」に仕分けしましょう。この作業を省くと、制作会社はすべての要望を盛り込んだ提案をしてきます。結果として見積もりが膨らみ、予算オーバーになるか、妥協の連続で中途半端なサイトになるか、どちらかになりがちです。
機能要件は大きく「フロント系(購入フロー・レコメンド・ポイント・クーポン・レビューなど)」「バックオフィス系(受注管理・在庫管理・CSVインポート・帳票出力など)」「マーケティング系(MA連携・メール配信・SEO設定・A/Bテストなど)」に分類して整理すると見通しが立てやすくなります。
④連携システムの洗い出し(基幹・WMS・MA・決済)
ECサイトは単独では動きません。受注データを流す基幹(ERP)、在庫を管理するWMS(倉庫管理システム)、顧客を育てるMA(マーケティングオートメーション)ツール、決済代行会社──これらとの連携仕様を事前に整理しておくことが、後工程でのトラブルを大幅に減らします。
特に注意が必要なのは「既存システムのAPI仕様書が存在するか」です。古い基幹システムの場合、API接続に対応していないことがあり、連携方法(バッチ処理・CSV連携など)の検討が必要になります。この確認を制作会社任せにすると、「思ったより連携コストがかかった」という話になりやすいため、事前の確認を怠らないようにしましょう。
⑤データ移行の範囲と品質基準の定義
既存サイトのリニューアルでは、商品データ・会員データ・注文履歴・ポイント残高などの移行が必要になります。このデータ移行の範囲と品質基準(何年分のデータを移すか、不完全なデータはどう扱うかなど)を事前に定義しておかないと、移行作業中に判断が止まり、スケジュールが延びてしまいます。
SKU数が多い事業者や、長年運営してきたサイトほど、データの整合性の確認に時間がかかります。データ移行は「技術的な作業」ではなく「事業の意思決定」を含む作業だという認識を持っておくことが大切です。
※関連記事:ECカートの移行を成功させよう!移行手順と失敗を防ぐポイント、成功事例を紹介!
⑥運用体制と内製化の範囲の明確化
「サイトが公開された後、誰が何をやるのか」を外注前に定義しましょう。更新作業・広告運用・メール配信・分析レポート作成・問い合わせ対応──これらのどこまでを社内でやり、どこから外部に委託するかを決めておくと、CMSの使いやすさや管理画面の操作性という「運用目線の要件」がRFPに書けるようになります。
社内のEC担当が1〜2名で回す体制なのか、専任チームがある体制なのかによって、「ノーコードで直感的に操作できること」が必須条件になるかどうかも変わってきます。
⑦スケジュール・予算の上限と稟議ライン
「希望公開日」と「絶対に守らなければならない公開日」は別の概念として整理しましょう。季節商材の繁忙期前にオープンしなければならない場合や、既存カートのサービス終了日がデッドラインになる場合は、スケジュールがすべての設計に影響します。
予算については、「初期費用の上限」だけでなく「月額・年額の運用コスト(ランニングコスト)の許容範囲」もあわせて明記しましょう。また、社内稟議に必要な決裁金額のラインを把握しておくと、制作会社との見積もり調整もスムーズになります。
制作会社・ベンダーの評価軸──比較検討で見るべき5つのポイント
要件定義が整ったら、いよいよ制作会社・ベンダーの選定に入ります。ここでは「何となく大きな会社」「以前付き合いのある会社」という選び方ではなく、自社の要件に照らした評価軸で比較することが重要です。
EC特化の実績と業界・規模の近さ
制作会社の実績は「件数」よりも「質」で評価しましょう。自社と近い業界(食品・アパレル・コスメ・BtoBなど)や規模(月間受注件数・SKU数・売上規模)での構築実績があるかどうかを確認します。複雑な定期購入フローが必要なのに、単品通販の実績しかない会社に依頼するのは、リスクが高いといえます。
ポートフォリオを見る際には「見た目のデザイン」だけでなく、「どんな機能課題をどう解決したか」というロジックを聞けるかどうかを確認しましょう。実績について深掘りできる担当者がいる会社かどうかは、発注後のコミュニケーションの質にも直結します。
構築後の伴走支援体制(カスタマーサクセスの有無)
ECサイトは公開してからが本番です。「構築は得意だが、公開後はほぼノータッチ」という制作会社も少なくありません。一方、プラットフォームベンダーの中には、構築中から公開後の運用改善まで一貫して伴走するカスタマーサクセス体制を持つところもあります。
たとえばメルカートでは、構築中の手順を30段階に分けて担当チームが伴走し、公開後も定例ミーティングで運用を支えます。EC初経験の担当者でも、何をいつ決めればよいかがわかる進め方です。こうした「構築後の伴走支援体制の有無」は、制作会社・ベンダー選定における重要な評価軸の一つです。特に社内のEC運営リソースが限られている企業ほど、この観点を優先したいところです。
プラットフォームの中立性(特定カートを推すだけでないか)
制作会社によっては、特定のカートシステムのパートナー契約を結んでいるため、自社に合うかどうかに関わらず「そのカートを勧めてくる」ケースがあります。自社の要件に対して「このカートでは対応できない部分がある」と正直に言える会社かどうかを見極めましょう。
複数のプラットフォームを扱った実績があり、それぞれのメリット・デメリットを説明できる会社を選ぶと、より中立な視点でのカート選定が可能になります。
セキュリティ・コンプライアンス対応力
ECサイトは、クレジットカード情報を含む個人情報を扱います。PCI DSS(クレジットカードのセキュリティ基準)への対応状況、個人情報保護方針、WAF(Webアプリケーションファイアウォール)の有無、24時間365日の監視体制があるかを確認しましょう。
また、特定商取引法・景品表示法などの法改正が頻繁に行われるEC領域では、「法改正に追いつくための機能更新が自動で行われるか」も重要な確認点です。自社でキャッチアップし続けるには限界があるため、プラットフォーム側が自動対応するかどうかは、長期的なコストと安心感に大きく影響します。
提案の質──RFPへの回答精度で見極める
最終的に最も信頼できる評価軸は、「RFPへの回答品質」です。自社の課題を正確に理解した上で提案しているか、KPIに対して具体的なアプローチを提示しているか、課題に対して正直に「難しい部分」を伝えているか。RFPへの回答を見れば、その会社が自社のビジネスをパートナーとして考えているか、ただの受注案件として処理しているかが透けて見えます。
見積もりの比較の見方──「安さ」で選ぶと高くつく理由
費用相場の目安(規模別)
ECサイトの構築・リニューアル費用は、構築方法と事業規模によって大きく異なります。あくまで目安として、以下の水準を参考にしてください。
| 構築方法 | 初期費用の目安 | 月額費用の目安 | 主な対象規模 |
|---|---|---|---|
| ASP型(テンプレート活用) | 数十万〜150万円程度 | 数万円〜 | 年商1億円未満 |
| クラウドEC(SaaS型) | 100万〜500万円程度 | 数万〜数十万円程度 | 年商1億〜50億円 |
| パッケージ型 | 500万〜3,000万円程度 | 保守費:数十万円〜 | 年商1億〜50億円(独自要件が多い)/50億円以上 |
| フルスクラッチ開発 | 数千万〜数億円 | 保守・運用費:高額 | 年商50億円以上・特殊要件 |
上記は一般的な相場です(2026年9月時点)。同じクラウドECでも、基幹システム連携の複雑さやSKU数、デザインのカスタマイズ範囲によって費用は大きく変動します。複数社から見積もりを取り比較することは前提として、「なぜその金額になるのか」の内訳を説明できる会社を選びましょう。
見積もり比較で見落としがちな3つの落とし穴
見積もりを比較するとき、金額の「合計」だけを見てはいけません。以下の3点が落とし穴になりやすいため、注意が必要です。
落とし穴①:スコープの違いを見逃す
A社は「デザイン制作費・開発費・データ移行費」すべて込みの見積もりで500万円、B社は「開発費のみ」で300万円──この場合、B社のほうが最終的に高くなる可能性があります。見積もりに含まれる作業スコープを必ず確認しましょう。
落とし穴②:追加開発・仕様変更の単価が書かれていない
ECプロジェクトで仕様変更は「ほぼ必ず」発生します。追加開発1人日あたりの単価が見積もり書に明記されているか確認しましょう。「都度相談」という会社は、変更のたびに高額が発生するリスクがあります。
落とし穴③:保守・サポート費用が含まれていない
初期費用が安くても、公開後の保守費・サポート費が別途かかる場合は総コストが跳ね上がります。特にパッケージ型やフルスクラッチの場合、バージョンアップの都度費用が発生することも珍しくありません。
TCO(総所有コスト)で比較する考え方
ECサイトの費用は、初期費用だけで判断しないことが鉄則です。「3年間で総額いくらかかるか(TCO=Total Cost of Ownership)」で比較する視点を持ちましょう。
たとえば、月額固定のクラウドEC(SaaS型)では、売上が伸びてもトランザクション課金が発生しないケースがあります。この場合、売上規模が大きくなるほどコスト優位性が生まれます。一方、受注件数・売上連動型の課金体系では、事業成長とともにプラットフォームコストが膨らみます。どちらが自社の事業計画に合うかは、将来の売上見込みを加味した試算で判断することをお勧めします。
契約前に確認すべき注意点チェックリスト
発注先が決まり、いよいよ契約という段階でも、確認すべき項目があります。ここを後回しにすると、公開後のトラブルや事業継続上のリスクにつながります。
ソースコードとデータの帰属・持ち出し権
フルスクラッチやパッケージ開発でカスタマイズを行う場合、「開発したソースコードの知的財産権が誰に帰属するか」を契約書で確認しましょう。制作会社に帰属する場合、後から別会社に乗り換えようとしても「コードを持ち出せない」という事態が起きます。
同様に、顧客データ・商品データ・注文履歴など、自社が生成したデータを「いつでも・どのような形式でも・追加費用なしで」エクスポートできるかを確認しましょう。データのポータビリティは、プラットフォームを乗り換える際の最大の障壁になり得ます。
追加開発・仕様変更時の単価と発注フロー
「今回の契約範囲外の変更が発生した場合の単価(人日単価)」と「変更を発注するための手続きフロー(稟議・承認の流れ)」を契約前に合意しておきましょう。急ぎで変更が必要な際に、都度見積もりを取り直すプロセスが重くて動けない──というケースは、EC現場でよく起きます。あらかじめ「少額変更(○万円以下)は口頭発注可」「それ以上は変更仕様書を発行」などのルールを決めておくと、スムーズに動けます。
保守・SLAの具体的水準と連絡体制
サイト障害が発生した場合の対応時間・連絡窓口・エスカレーションフローをSLA(Service Level Agreement)として契約書に明記してもらいましょう。「営業時間内のみ対応」では、深夜・早朝の障害(セール中などに起きやすい)に対応できません。また、障害対応の連絡先が「担当営業経由のみ」では、緊急時の初動が遅れます。
中堅・大手ECであれば、「24時間365日の監視体制」「障害発生から1時間以内の一次応答」を最低ラインとして求めることをお勧めします。これをSLAとして契約に盛り込めるか否かは、ベンダー選定の重要な判断基準になります。
メルカートなら要件定義から伴走し、外注の失敗リスクを下げられる
ECサイトの構築・リニューアルを外注する際、「要件定義の段階から一緒に考えてくれるパートナー」がいるかどうかは、プロジェクトの成否に大きく影響します。
中堅・大手企業向けのクラウドECプラットフォーム「メルカート」は、要件定義〜構築〜公開後の運用改善まで、同じ担当チームが一貫して伴走する体制を整えています。
構築フェーズでは、お申し込みからサイト公開まで平均3か月です。手順を30段階に分け、担当チームが一つずつ一緒に進めます。EC担当が初めての担当者でも、何をいつまでに決めるべきかが明確で、意思決定が止まらない設計になっています。
公開後は、機能の活用方法からデータ分析の進め方まで、20項目以上を無償サポートの範囲で対応します。専任のヘルプデスクとカスタマーサクセスが窓口で、サポート満足度は97%(ITreviewのレビューデータより)です。
また、年240回の自動バージョンアップで機能が更新され、バージョンアップのたびの追加開発費はかかりません。受注件数や売上に対する従量課金もないため、売上が伸びても月額は変わりません。ECパッケージ「ecbeing」のSaaS版として、ecbeingが1,600サイト以上の構築で培ったノウハウを受け継いでいます。
リニューアルの進め方・費用・期間の目安はECサイトリニューアルの進め方でまとめています。
「要件定義の段階から相談したい」「今のカートシステムで限界を感じている」という段階でも、まずは無料相談から始めることができます。ECサイト構築・リニューアルを検討している方は、ぜひメルカートにご相談ください。
まとめ
ECサイトの構築・リニューアルを外注で成功させるために、最も重要なのは「発注前の上流設計」です。本記事で解説した内容を改めて整理します。
まず、要件定義の7項目(①現状課題の言語化、②KPIの数値化、③機能要件のMust/Want仕分け、④連携システムの洗い出し、⑤データ移行の定義、⑥運用体制の明確化、⑦スケジュール・予算の上限)を整えてRFPを作りましょう。次に、EC特化の実績・伴走支援体制・プラットフォームの中立性・セキュリティ・提案の質の5軸で制作会社を比較してください。見積もりは初期費用だけでなくTCOで判断し、スコープの違いを揃えた上で比較することが大切です。そして契約前にはデータの帰属・追加開発の単価・SLAを書面で確認しましょう。
これらを一連のプロセスとして実行することで、「作ったはいいけど使えない」「費用が想定の2倍になった」という典型的な失敗を防ぐことができます。ECサイトは公開がゴールではなく、売上を伸ばし続けるための起点です。その起点を正しく設計するための投資として、要件定義に時間とリソースをかける価値は十分にあります。
構築・リニューアルのご検討が具体化してきた段階でも、「まだ要件が固まっていない」という段階でも、まずは無料相談からお気軽にご連絡ください。
よくある質問
要件定義にはどれくらいの時間がかかりますか?
規模や社内の意思決定スピードによりますが、中堅・大手ECの場合、本格的な要件定義(RFP作成まで含む)には1〜2ヶ月程度を見ておくことを推奨します。「現状課題の言語化」と「機能要件のMust/Want仕分け」だけであれば、2〜3週間で整理できるケースも多くあります。要件定義に十分な時間を確保することで、その後の制作会社選定・見積もり比較・開発の各フェーズが格段にスムーズになります。
制作会社とプラットフォームベンダーはどちらに先に相談すべきですか?
どちらが先でも構いませんが、「プラットフォームの仕様が先に決まると、制作会社の選択肢が絞られる」という関係があります。そのため、まず自社の要件を整理した上でプラットフォームの候補を絞り、次に「そのプラットフォームでの構築実績がある制作会社」を選ぶ流れが一般的です。プラットフォームと制作会社が同一グループまたはパートナー関係にある場合は、一括して相談できるため、調整の手間が省けます。
見積もりが複数社で大きく違うとき、どう判断すればいいですか?
まず「スコープが同じかどうか」を確認することが先決です。見積もりが大きく異なる場合、含まれる作業範囲が異なっていることがほとんどです。デザイン制作・データ移行・テスト工程・研修費が含まれているかどうかを各社に確認し、同一条件に揃えた上で比較してください。それでも差がある場合は、開発工数の見積もり根拠を確認することをお勧めします。「安い見積もり」には理由があり、後から追加費用が発生するリスクがあることを念頭に置いてください。
NEXT STEP
いまの構成のまま、3年でいくらかかるか出せます
現在のカート・売上規模・運用体制をうかがえば、その場で3年総額の試算をお出しします。乗り換えるべきかどうかの判断材料としてお使いください。