見積もりを出したあとに「もう少し安くならないか」と言われる場面は、EC開発の受託では避けて通れません。このとき単価を削って帳尻を合わせると、後で自分の首を絞めます。当社が値引きを作るときにまず考えるのは「金額を下げること」ではなく「どの作業を誰に渡すか」です。この記事は、Shopifyまわりの開発を受託する立場の担当者に向けて、値引き版の見積もりをどう組み立てるか、そしてその際に必ず入れておく線引きは何か、という実務をまとめます。既存の自社アプリ基盤を流用して工数そのものを削る話は当社の別記事で扱っているので、ここでは「作業の受け渡しで値引きを作る」やり方に絞ります。
AIで作っても、費用は人日から逃げられない
前提として、AI駆動で開発効率が上がっても、見積もりの構造そのものは変わりません。マージンを載せない条件で予算が丸ごと届いたとしても、それが実質何人月ぶんなのかを先に見極めないと、スコープが予算に収まらないまま走ることになります。当社では、提示された金額をまず人日に逆算し、各機能ブロックが何人日でいくらか、幅の上限と下限が何で決まるかまで言語化してから交渉に臨みます。お客様の関心が「金額そのもの」より「その金額の理由」にあることは多く、根拠を説明できる状態こそが交渉の勝負どころになるからです。
値引きは「作業を客先に渡す」ことで作る
正攻法の値引きは、こちらがやる予定だった作業の一部をお客様側に引き取ってもらい、そのぶんを減額する形です。典型的なのが受入テストと業務シナリオテストです。テストデータの準備も含めてお客様側で実施いただく前提にすれば、そのぶんの人日を落とせます。詳細設計書や運用マニュアルを正式な文書ではなく実務で足りる水準の記述に留めることでも工数は下がります。
ただし作業を渡すときには、渡した範囲を見積書に明記することがセットになります。特に受入テストを客先に渡す場合は、「受入テストで検出された不具合の修正は本見積に含む/仕様変更は別途」という線引きを必ず書きます。ここを書かないと、受入テストで出た指摘がすべて無償対応に流れ込みます。不具合と仕様変更の境目を先に文章にしておくことが、値引きと引き換えに自分たちを守る手当てになります。マニュアル整備までお客様に引き取ってもらえればさらに下げられる、といった追加の一手は、備考に残して交渉のカードにしておきます。
スコープは段階に分け、全体像も併記する
値引きのもう一つの作り方が、スコープを段階に分けて第一段に絞ることです。発生頻度の高い機能や効果の見えやすい機能を先にリリースし、残りを後追いにする。この分け方なら、初回の金額を予算に収めつつ、価値をすぐ出せます。技術検証が必要な場合も、別発注にすると稟議が二回必要になるので、第一段に含めて一本の見積もりにするほうが通りやすいことが多い。ただし検証結果によって設計方針が変わり得ることは、前提条件として明記しておきます。
段階に分けたときは、第二段・第三段を参考見積として併記しておくのが安全です。全体像を見せないと「これで全部そろうはず」という誤解が残り、後で「聞いていない」というトラブルになります。合計で最大いくらになるかを先に示しておくほうが、結果的にお客様の意思決定も速くなります。
除外項目と保守は、前提の置き方で金額が変わる
見積もりを出すときは、含まれない費用を列挙しておきます。要件定義、プロジェクト管理、インフラ環境の構築、保守などを開発本体と分けて明示しておかないと、「この金額で全部入りだと思っていた」という受け取り方をされます。社内用の根拠資料としては除外項目を詳細に持ち、お客様提示用は除外項目を簡潔にまとめた版を別に作る、という二段構えも有効です。
保守については、インフラのアカウントを誰が持つかで委託の可否そのものが変わる点に注意します。当社のクラウドアカウント上で構築した場合、保守だけを別会社に委託するのは難しく、逆にお客様側や別会社のアカウントを使うなら保守の切り分けができる、といった具合に、アカウントの持ち主が保守体制の選択肢を規定します。ここは見積もりの初期に前提として握っておくべきところです。ランニング費用をお客様アカウントに寄せれば見積総額から運用費が消え、「月額固定費なし」と言える、という副次効果もあります。
多重下請けでは、宛先と責任範囲を先に確かめる
案件によっては、間に一次受け・二次受けが入る商流になります。この場合、見積書の宛先が誰なのか（一次受けか二次受けか）を確認しないと、そもそも正しい書類が作れません。責任範囲を後から問われたときの防御材料として、作業分担表にあたる記述だけは値引き版でも残しておきます。予算の性質を確認する価値もあります。初期投資は追加予算が出にくくても、初期費用を下げて月額の保守に回せば、運用費として別の予算枠から出せることがある。予算の枠がどこにあるかを一次受けに確認するだけで、通し方が変わることがあります。
まとめ
値引きは単価を削って作るものではなく、受入テストやマニュアルといった作業をお客様側に渡し、そのぶんを減額する形で作ります。その際は渡した範囲を明記し、「不具合修正は含む/仕様変更は別途」の線引きを必ず入れて、無償対応への流れ込みを止めます。スコープを段階に分けて全体像を併記し、除外項目と保守の前提、多重下請けでの宛先と責任範囲を先に固める。当社では、AIで開発が速くなっても変わらないこの見積もりの作法を、値引き交渉を安全に進めるための土台にしています。