ECサイト制作の見積もりの作り方｜あとで足せない項目

2026年7月29日

朝比奈蒼

この記事のポイント

✓ECサイト制作の見積もりの出し方を
✓項目の立て方から順に解説
✓前提が変わったときの再見積もりの条件

ECサイト制作の見積もりで赤字になる原因は、単価が安すぎたからではありません。見積もりを出した時点で決まっていなかった前提が、制作の途中で勝手に確定していくからです。結論から言うと、見積書に書くべきなのは「やること」ではなく「やらないこと」と「前提が変わったらどうするか」です。この記事では、ECサイト制作の見積もりの出し方を、項目の立て方、あとから足せない項目の見抜き方、前提が崩れたときの再見積もりの条件という順で整理します。

ECサイト制作の見積もりが崩れる原因は作業量ではなく前提の欠落にある

コーポレートサイトの制作とECサイトの制作は、見積もりの性質がまったく違います。コーポレートサイトはページ数を数えれば作業量がほぼ見えます。トップページ、会社概要、サービス紹介、お問い合わせ。ページを増やせば増えた分だけ作業が増えるという、素直な比例関係が成立します。

ECサイトにはこの比例関係がありません。商品ページは1ページ作れば、あとは商品データを流し込むだけに見えます。ところが実際には、商品ごとにバリエーションの持ち方が違い、在庫の数え方が違い、送料の計算ルールが違い、税率が違います。ページ数は増えていないのに、条件分岐が増えていく。ここが見積もりの読み違いを生む構造です。

もうひとつ、ECサイトには「外部に依存する工程」が必ず含まれます。決済代行会社の審査、配送業者との契約、モールとの連携、在庫管理システムのAPI仕様。これらは制作側がいくら急いでも短縮できません。制作の進捗とは無関係に時間が流れる工程が、スケジュールの中に埋め込まれています。見積もりを工数だけで組むと、この待ち時間が誰の責任なのかが決まらないまま進行します。

そして、ECサイトの発注者は「売上を上げるため」に発注しています。制作物が完成しても売れなければ、発注者の目的は達成されません。この温度差が、検収の場面で「イメージと違う」という形で噴き出します。見積もりの段階で、この案件の成果物は何であって何でないのかを言語化しておくことが、実務上いちばん効く防御になります。

制作の実務を扱う分野の全体像は、ECサイト制作・運用・画像制作のお仕事にまとまっています。構築だけでなく商品登録や画像加工まで含めた業務の幅を確認しておくと、自分がどこまでを引き受けるのかの線引きがしやすくなります。

見積もりを出す前に確定させる前提

見積もりは、前提が固まっていない状態では出せません。正確には、出してはいけません。前提が不明なまま金額だけを提示すると、その金額が「上限」として一人歩きします。ヒアリングの段階で、次の項目は必ず確定させてください。

商品点数とバリエーションの数え方

「商品は50点です」という回答をそのまま受け取ってはいけません。確認すべきは、その50点がどう数えられているかです。色5種類、サイズ4種類のTシャツは、発注者にとっては1商品ですが、システム上は20のSKUです。在庫を色サイズ別に持つのか、まとめて持つのかでも登録の手間が変わります。

さらに、バリエーションによって価格が変わるのか、画像が変わるのか、送料区分が変わるのかを聞きます。これが変わる場合、商品登録の作業量は数え方の何倍にも膨らみます。見積書には「商品点数」ではなく「SKU数」と書き、その定義を注記してください。

商品データと画像が誰の手元にあるか

商品名、価格、説明文、スペック、画像。これらが揃った状態で渡されるのか、こちらが作るのかで作業量は根本的に変わります。発注者は「データはあります」と言いますが、その実体が紙のカタログだったり、担当者の頭の中だったり、旧サイトのHTMLの中だったりします。

確認の方法は単純で、サンプルを3件だけ、実際のファイルで送ってもらうことです。表計算ファイルで整形済みのデータが来るのか、画像フォルダに撮影日のままのファイル名が並んでいるのかで、見積もりの前提が変わります。口頭の「あります」を信用せず、現物を見てから項目を立ててください。

決済手段と配送の条件

決済代行会社が決まっているか、これから選ぶのかを聞きます。決まっていない場合、選定の支援は制作の範囲外なのか範囲内なのかを明記してください。審査には時間がかかり、法人設立直後や特定の商材では通らないこともあります。審査が通らなかった場合にスケジュールをどう扱うかを、見積もりの前提条件として書いておきます。

配送は、全国一律なのか、地域別なのか、商品サイズ別なのか、金額による無料ラインがあるのか。この組み合わせが増えるほど設定の手間が増えます。「後で決めます」と言われた場合は、標準的なパターンを1つ仮定して見積もり、複雑化した場合は別途とすることを明示してください。

誰が決めるのか

制作の途中で判断が止まる案件には共通点があります。打ち合わせに出てくる担当者に決定権がないことです。窓口の担当者が持ち帰り、社内で意見が割れ、前回の合意が覆る。この繰り返しが工数を食い潰します。

反対に、最初の打ち合わせで方向性をそろえておくことで、制作会社も提案の軸を持ちやすくなり、担当者としても「この制作会社なら安心だ」という手ごたえを感じながらプロジェクトを進められます。出典: wwg.co.jp

見積もりの前提条件欄に「デザイン確定の判断者」「機能仕様の判断者」を名前で書いてもらう。これだけで、後から出てくる「上が違うと言っている」という差し戻しにブレーキがかかります。

見積書に立てるべき項目

見積書を「ECサイト制作一式」の1行で出すのは、自分の首を絞める行為です。項目が1行しかないと、追加作業が発生したときに「一式に含まれている」と言われて反論できません。項目を割ることは、値引き交渉のためではなく、範囲を可視化するためにやります。

要件定義と設計

サイトの目的、ターゲット、扱う商品、必要な機能を文書に落とす工程です。この工程を見積もりに入れず「打ち合わせのついで」で済ませると、仕様の食い違いがすべて制作側の負担になります。成果物として要件定義書を出すことを明記し、この文書に書かれていないものは範囲外だと定義してください。

デザイン

トップページ、商品一覧、商品詳細、カート、購入手続き、会員ページ、静的ページ。ECサイトでデザインが必要な画面は、コーポレートサイトより明らかに多いです。デザインの見積もりは「デザイン一式」ではなく、画面種別ごとに数を書きます。スマートフォン向けの表示を別に作るのか、同じデザインを流用するのかも項目に反映させてください。

構築と実装

ここでいちばん重要なのは、何の上に作るかです。ASPカートを使うのか、オープンソースのシステムを使うのか、モールに出すのか、フルスクラッチなのか。土台が変わると、同じ機能でも実装の手間が桁違いに変わります。見積書には採用するプラットフォーム名を明記し、「変更する場合は再見積もり」と書いてください。

商品データの登録

これを見積もりから落とす制作者が非常に多い項目です。データが整っていれば流し込みで済みますが、整っていなければ1件ずつ手作業になります。見積もりでは「登録代行はSKU単位」「初回10件までは動作確認用として制作範囲に含む、それ以降は別項目」といった形で、範囲を数で切ってください。

決済と配送の設定

決済代行の申し込み書類の記入支援、テスト決済の実施、配送設定、税率設定。これらは技術的には難しくありませんが、確認と待ちが多い工程です。工数としては小さくても、独立した項目として立てておくと、審査の遅れが誰の責任かを説明しやすくなります。

テストと公開

商品を買う導線が正しく動くかを、実際にお金を動かして確認する工程です。ブラウザ、スマートフォン、決済手段、クーポン、送料無料ライン。組み合わせが多いので、テストする条件の一覧を先に作り、それを見積書の添付資料にします。テスト項目が増えれば工数が増えることを、数字で示せる状態にしておきます。

進行管理

会議、議事録、スケジュール管理、関係者との調整。制作会社の見積書ではこれが独立した項目として立っています。

進行管理にかかる費用の目安は、制作費全体の10％程度です。例えば、Webサイトの制作費全体が100万円ほどであれば、進行管理の費用は10万円程度になります。なお、担当者の稼働割合によっては制作費用の30％程度になることもあります。出典: hnavi.co.jp

個人で受ける場合、この項目を省く人がほとんどです。しかし進行管理の作業は、制作会社に発注しようが個人に発注しようが同じだけ発生します。省くのではなく、項目として立てたうえで判断してください。項目に無いものは、発注者からは「無料でやってくれるもの」に見えます。

あとから足せない項目

ここからが本題です。見積もりの実務で本当に怖いのは、金額が安いことではなく、あとから請求できない項目を無償で抱え込むことです。あとから足せない項目には共通の特徴があります。発注者から見て「それは当然含まれているはずのもの」に見える、という特徴です。

商品データの整形

発注者は「データを渡した」と認識しています。渡されたのが表計算ファイルなら、こちらから見れば「整形されていないデータ」でも、向こうから見れば「渡した」です。ここで整形作業を追加請求しようとすると、必ず揉めます。

対策は、見積もりの前提条件に受け入れ可能なデータ形式を明記することです。列の並び、必須項目、画像ファイルの命名規則、文字コード。この形式で渡されなかった場合は整形費用が発生する、と先に書いておきます。テンプレートファイルを渡してしまうのがいちばん確実です。仕様書やデータ定義書のような業務文書を正確に書く力は、ここで直接お金に効きます。

商品撮影と画像加工

「写真はこれを使ってください」と渡された画像が、背景も明るさもバラバラだったというのは日常的に起こります。並べたときに揃って見えないので、結局こちらで背景を白抜きし、明るさを揃えることになります。これを善意でやると、次の商品追加のときも当然やるものとして扱われます。

画像加工は必ず独立した項目にして、加工の内容と対象点数を書いてください。「リサイズと形式変換は含む」「背景除去、色調補正、合成は含まない」と書き分けます。撮影が必要なら、撮影は制作とは別のスケジュールと別の項目です。

既存サイトからのデータ移行

リニューアル案件で必ず出てくる項目です。旧サイトの会員データ、注文履歴、レビュー、ポイント残高。これらを新サイトに引き継ぐかどうかは、発注者にとっては「引き継がれて当たり前」です。しかし技術的には、旧システムからデータを取り出せるかどうかがそもそも不明で、取り出せても構造が違えば変換が必要になります。

移行は見積もり時点で範囲を確定できないことが多い項目です。であれば、「移行対象の調査」を先に単独の項目として立て、調査の結果で移行作業を別途見積もる、という二段構えにします。調査せずに移行費を含めるのは、金額を当てずっぽうで決めることと同じです。

税と送料の計算ルール

軽減税率の対象商品が混在する、複数商品をまとめたときの送料が個別と違う、特定の地域だけ追加料金がある、まとめ買い割引がある。こうした計算ルールは、発注者の頭の中には最初から存在していますが、打ち合わせでは出てきません。「今まで通りでお願いします」の一言に、複雑な条件分岐が畳み込まれています。

対策は、見積もり前に計算パターンを書き出して確認してもらうことです。「この4パターンの計算が必要という理解でよいか」と紙に書いて聞く。増えた分は追加になると書いておく。ここを詰めずに実装に入ると、テストの段階で仕様が生えてきます。

公開後の不具合対応

「公開したら終わり」ではないのがECサイトです。決済が特定の条件で通らない、スマートフォンの一部機種で購入ボタンが押せない、在庫が正しく減らない。公開後に見つかる問題は必ずあります。

ここで線を引くべきなのは、瑕疵の修正と仕様変更の区別です。契約した仕様どおりに動いていないなら制作側の責任で直します。仕様どおりに動いているが結果が気に入らないなら、それは新しい依頼です。この区別を見積書と契約書の両方に書いてください。区別を書いていないと、公開後の数か月が無償の作業で埋まります。

運用マニュアルと操作説明

納品後、発注者が自分で商品を追加できなければ、追加依頼はすべてこちらに来ます。マニュアルを作るか、操作説明の時間を取るか、どちらもしないか。どれを選んでも構いませんが、選ばずに曖昧なままにすると、電話とメールでの質問対応が延々と続きます。

マニュアル作成と操作説明会は、独立した項目として見積書に載せてください。仮に金額を入れずに「本見積もりには含みません」と書くだけでも効果があります。書かれていない項目は存在しないものとして扱われますが、書かれていて含まないと明記された項目は、後から相談の対象になります。

外部に待つ工程をスケジュールに書く

制作の工程表には、自分が手を動かす作業だけが並びがちです。ECサイトでは、これに加えて相手待ちの工程を独立した行として引いてください。決済代行会社の審査、ドメインとサーバーの手配、モールへの出店審査、SSL証明書の発行、配送業者との契約。どれも制作側の努力では短縮できません。

各行には、担当者の名前と、開始の条件と、終わりの合図を書きます。開始の条件とは、何が揃えばその工程が動き出すかです。審査であれば、申込書、登記事項の証明、扱う商材の一覧、サイトの下書き。これらが揃わないと申請そのものが出せません。終わりの合図とは、何を受け取ったら次に進めるかです。審査の通過通知、発行された接続情報、契約書の写し。合図を決めておかないと、進んだかどうかを毎回問い合わせることになります。

待ちの間に進められる作業も、先に並べておきます。審査を待つ間にデザインを固める、商品データの整形を進める、テストする条件の一覧を作る。並べておけば、待ちが発生しても手が止まりません。

そのうえで、待ちが伸びた場合の扱いを一文で書きます。発注者側の準備や外部の審査で工程が止まった場合、その日数分だけ納期を後ろにずらす、という書き方です。この一文がないと、待っていた期間まで制作側の遅れとして数えられます。審査に通らなかった場合の分岐も書いておいてください。別の決済代行に切り替えるのか、その切り替えにかかる作業は追加として扱うのか。落ちてから考えると、判断そのものに時間を取られます。

修正回数と検収条件の書き方

ECサイト制作でもっとも工数が溶けるのは、デザインの修正です。回数を決めていない案件では、発注者は納得するまで修正を要求できると考えます。それが悪意ではなく、決めていないから当然そう考えるという話です。

修正は「回数」ではなく「ラウンド」で数えてください。1ラウンドとは、こちらが提出し、発注者側が社内の意見をまとめて1回にまとめて返す、という往復です。個別の担当者から別々に修正依頼が飛んでくる状態を許すと、ラウンドの概念が崩壊します。「修正依頼は窓口担当者がまとめて1通で送る」ことを前提条件に書いてください。

検収の条件も同じです。検収基準を「発注者が満足すること」にしてはいけません。基準は「要件定義書に記載された機能が、記載された条件で動作すること」です。テスト項目の一覧を先に作り、その一覧にチェックが入ったら検収完了とする。この形にしておくと、検収の場が主観の議論になりません。

検収期間も決めます。納品後、一定の日数を過ぎても連絡がなければ検収完了とみなす、という条項を入れておく。発注者側の都合で検収が止まり、入金だけが遅れるという事態を防げます。契約と支払いの実務については、法務の基礎を扱う情報も参照しながら、自分の契約書の型を持っておくことをおすすめします。

テストする条件の一覧を先に作る

テスト項目の一覧は、見積書の添付資料であると同時に、検収の基準になります。作り方を決めておくと、案件ごとに悩まずに済みます。

軸は四つです。買う人の状態、決済の手段、配送の条件、見る端末。会員として買う場合と、会員登録せずに買う場合では挙動が変わります。決済はクレジットカード、コンビニ払い、代金引換、後払いのうち、その案件で採用するものだけを並べます。配送は通常の配送、日時の指定、送料無料のラインをまたぐ場合、地域による追加料金がある場合。端末はパソコンとスマートフォンの主要な組み合わせに絞ります。

四つを掛け合わせると条件の数が跳ね上がるので、全部は試しません。実際に注文が集中すると想定される組み合わせを選び、それを一覧に落とします。選んだ理由を一行添えておくと、後から条件を足したいと言われたときに、追加分が範囲外であることを説明できます。

一覧には、確認する内容と、期待する結果を並べて書きます。「送料無料のラインの直前の金額でカートに入れたとき、送料が加算されて表示される」という形です。動くかどうかではなく、どう動くのが正しいかを書くのが要点です。この書き方をしておくと、テストの一部を発注者側にお願いできます。実際に商品を扱う人が試すほうが、想定していない使い方が見つかります。

見積書の見せ方で結果が変わる

同じ内容でも、見せ方で受け取られ方が変わります。実務で効果があったやり方を挙げます。

1つ目は、金額を3段階で出すことです。必要最小限の構成、標準的な構成、拡張した構成。1つの金額だけを出すと、発注者はそれを高いか安いかで判断します。3つ出すと、どれにするかで判断します。判断の軸が変わることで、「値引きできませんか」ではなく「この機能は要りません」という建設的な削り方に話が向かいます。

2つ目は、含まないものを一覧にすることです。見積書の末尾に「本見積もりに含まないもの」の欄を作り、撮影、原稿執筆、ロゴ制作、サーバー費用、決済代行の手数料、公開後の運用、といった項目を並べます。この欄は、揉めたときにいちばん効きます。

3つ目は、前提条件を数字で書くことです。「SKU数100まで」「デザイン修正2ラウンドまで」「画面種別8種類」。数字で書いた前提は、超えたかどうかが誰の目にも明らかです。「大幅に増えた場合」のような曖昧な表現は、増えたかどうかの議論を生みます。

4つ目は、有効期限を書くことです。ECサイトは使うプラットフォームの料金体系や仕様が変わります。半年前の見積もりをそのまま出されて困る事態を避けるため、有効期限を明記してください。

前提が崩れたときの再見積もりの手順

前提条件を書いていても、それを使えなければ意味がありません。再見積もりは言い出しにくく、言い出さないまま作業が進み、終わってから請求できなくなる。この流れが、実務でいちばん多い失敗です。

出すかどうかの判断は、感覚ではなく基準で決めてください。分かれ目は三つあります。作業の時間が明らかに増えるか。他の工程の日程に影響するか。承認済みの成果物を後戻りさせるか。このどれかに当たるなら書面を出します。どれにも当たらない小さな変更は、記録だけ残して進めます。

出すときの手順も決めておきます。まず作業を止めます。次に、事実を短く書きます。届いた指示の内容、それが見積書のどの前提と食い違っているか、影響する工程はどれか。そのうえで、差分だけを示した追加の見積もりを送ります。全体を作り直した見積書を送ると、金額全体の再交渉が始まります。

文言はあらかじめ用意しておくと迷いません。「今回いただいたご指示は、お見積もりの前提条件に記載したSKU数の上限を超える内容です。超過分の登録作業について、追加のお見積もりをお送りします。着手はご承認をいただいてからとさせてください」。断るのではなく、進めるための条件として書くのが要点です。

記録だけ残して進めた小さな変更も、月に一度まとめて相手に伝えてください。無償で吸収した分が見えていれば、次の案件の条件を決めるときに話が早くなります。見えないまま積み上げると、それが標準の範囲だと理解されます。

保守と運用は最初から分けて出す

ECサイトは、公開した日から運用が始まります。商品の追加、セールの設定、バナーの差し替え、決済トラブルの一次対応、システムの更新。これらは制作とは性質の違う仕事です。

制作の見積もりに保守を混ぜると、発注者は「作ってもらったら面倒を見てもらえる」と理解します。制作の見積もりを提出する時点で、保守の見積もりも別紙で同時に出してください。同時に出すことで、運用には別の費用がかかるという前提を最初から共有できます。

保守の内容も切り分けます。システムの更新やバックアップのような「止めないための作業」と、商品追加やバナー差し替えのような「更新作業」は別物です。前者は定額、後者は作業単位、という形で分けると、発注者にとっても納得しやすくなります。運用まで含めた仕事の広がりは、AI・マーケティング・セキュリティのお仕事にあるように、集客支援やセキュリティ対応まで含めて考えると受注の幅が広がります。

技術者としての土台を客観的に示したい場合、ネットワークの基礎を証明するCCNA（シスコ技術者認定）のような資格が、サーバーやセキュリティまわりの相談を受ける際の説得材料になることがあります。制作だけでなく運用まで任せてもらうには、技術的な守備範囲を示せることが効きます。

現場を見てきた立場からの観察

20年この市場を見てきた立場から言えば、見積もりが上手な人は、金額の付け方が上手なのではありません。範囲の切り方が上手なのです。何をやるかを丁寧に書く人は多いのですが、何をやらないかを明記する人は少ない。そして、揉める案件はほぼ例外なく、やらないことを書いていない案件です。

もうひとつの観察として、長く続いている人ほど、見積もりの段階で発注者に質問をたくさんしています。質問が多いと嫌がられるのではないかと心配する人がいますが、実態は逆です。質問が多い相手のほうが、発注者は安心します。何も聞かずに金額だけ出してくる相手より、前提を確認してくる相手のほうが、仕事を分かっていると受け取られます。見積もりは価格表ではなく、この案件をどう理解したかを示す提案書です。

もう1点、手取りの構造について触れておきます。仲介手数料が引かれる経路で受注すると、同じ発注額でも受け取る額が減ります。逆に発注者から見れば、手数料が乗らない経路なら同じ予算でより多くの作業を頼めます。手数料0%で直接つながる仕組みが意味を持つのは、金額の大小ではなく、双方が同じ予算で得られる中身が増えるからです。見積もりに進行管理や運用マニュアルといった項目をきちんと立てられるのも、その分の余地が残っている取引だからこそです。

見積もりの精度を上げるために記録すること

見積もりの精度は、経験を記録した人だけが上げられます。案件が終わったら、次の項目を残してください。

見積もり時に想定した工数と、実際にかかった工数。差が出た工程はどこか。差の原因は、こちらの見積もり漏れなのか、発注者側の条件変更なのか。想定外に時間を食った作業は具体的に何だったのか。次に同じ条件の案件が来たとき、どの項目を追加すべきか。

記録は案件が終わった直後に書いてください。数日置くと、どの工程で何に手間取ったかの細部が抜け落ちます。書く場所は表計算ファイルでもテキストファイルでも構いませんが、案件ごとに一枚にまとめ、見積書の写しと同じ場所に置いておくと、次に似た案件が来たときに前提条件の欄をそのまま流用できます。前提条件の文面は、案件を重ねるほど精度が上がる資産です。

この記録を数件ぶん貯めると、自分の見積もりの癖が見えてきます。多くの制作者に共通する癖は、実装の工数は正確に読めるのに、コミュニケーションと待ち時間の工数を過小に見積もることです。実装は自分の手を動かせば終わりますが、確認と待ちは相手次第で伸びます。この部分を進行管理という項目で見積もりに載せられるかどうかが、案件ごとの採算を分けます。

技術職の仕事の広がりを俯瞰したいときは、ソフトウェア作成者の年収・単価相場で職種全体の位置づけを確認しておくと、自分の見積もりが市場からどれくらい離れているかの見当がつきます。文章を書く工程も引き受けるなら著述家，記者，編集者の年収・単価相場も参考になります。制作と執筆を両方引き受けられる人は、商品説明文まで含めた提案ができるため、見積もりの幅そのものを広げられます。

海外の発注者から仕事を受ける選択肢を検討している場合は、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法に、見積もりの提示方法や契約の進め方がまとまっています。契約書の様式や検収の考え方は国によって違いますが、範囲を明記するという原則は共通です。

よくある質問

Q. ECサイト制作の見積もりは、どこまで細かく項目を分けるべきですか？

発注者が削る判断をできる粒度まで分けてください。要件定義、デザイン、構築、商品データ登録、決済と配送の設定、テスト、進行管理が最低限の単位です。一式でまとめると、追加作業が発生したときに含まれていると解釈され、請求できなくなります。項目を分ける目的は値引き交渉ではなく、範囲を可視化することにあります。

Q. 商品データの整形費用を後から請求できないのはなぜですか？

発注者は「データを渡した」と認識しているためです。整形されていない状態でも、渡した側から見れば納品済みという理解になります。防ぐには、受け入れ可能なデータ形式を見積もりの前提条件に書き、列の並びと必須項目を定めたテンプレートを先に渡すことです。形式外のデータには整形費用が発生すると明記しておきます。