「3社に相見積もりを出したら、80万円と600万円が並んで、どう判断していいのか分からない」——在庫と受発注を一つにまとめたいという、従業員 40 名ほどの食品卸の専務さんから、そんな相談を受けたことがあります。一番安いところに頼みたいのが本音だけれど、ここまで差があると逆に怖い、と。見積書を三通とも見せていただいて、すぐに分かったのは、三社が「まったく違うものを見積もっていた」ということでした。80 万円の会社は出来合いのテンプレートに項目を足すだけの作業を、600 万円の会社は業務のヒアリングから要件定義・設計・テスト・一年間の保守までを、同じ「在庫管理システム開発」という一言の下に積もっていた。金額を横並びで比べられる状態ではなかったのです。
業務システムの外注は、初めての会社にとって相場の見えない買い物です。何にいくらかかるのか、どの会社が誠実なのか、どこまでが見積もりに含まれているのか——ここが見えないまま発注して、納品されたものが想定と違った、追加費用でもめた、作った会社としか連絡が取れず塩漬けになった、という事故が後を絶ちません。すでに 内製か外注かの切り分け を済ませて「これは外注する」と決めた前提で、本記事ではその先——どう発注すれば失敗しないかを、発注経験の浅い中小企業の目線で整理します。システム開発の出身で、いまは受託の側にいる立場から、なるべくポジショントークを抜いて書きます。
なぜ同じ依頼で見積もりが何倍も違うのか
冒頭の 80 万と 600 万のように、見積もりが数倍から十倍ひらくのは珍しくありません。これは一方が法外にぼったくっているからでも、もう一方が破格に良心的だからでもなく、たいていは前提と含まれる工程が違うからです。
システム開発の見積もりは、突き詰めると「誰が・何時間働くか」の積み上げです。業界では人月（一人が一ヶ月働く工数）や人日という単位を使い、エンジニアの単価に必要な工数を掛けて算出します。中小企業向けの開発では、エンジニア一人の単価がおおむね月 60 万〜120 万円、難度の高い領域や大手では 150 万円を超えることもあります。つまり、同じ「在庫管理」でも、想定する工数と単価が違えば金額は何倍にもなる。問題は、その想定の中身が見積書の表面からは読み取れないことにあります。
差が生まれる最大の要因は、要件の解像度です。発注側が「在庫を管理したい」としか伝えていなければ、各社は自分の都合のいい範囲を想像して見積もります。安い会社は「最低限の入出庫記録だけ」を、高い会社は「複数倉庫・ロット管理・他システム連携・スマホ対応まで」を思い浮かべているかもしれない。同じ言葉でも、見ている絵がまるで違うのです。次に効くのが含まれる工程です。要件定義・設計・開発・テスト・導入・保守という一連の工程のうち、どこまでを見積もりに入れているか。テストを省けば安くなりますが、バグが本番で出ます。要件定義を「発注者が用意する前提」にしている見積もりは、その分だけ安く見えて、いざ始めると別料金が乗ります。
さらに、保守を含むか含まないかで総額の見え方が大きく変わります。後で詳しく触れますが、システムは納品して終わりではなく、作った後に直し続ける費用がかかる。それを初期見積もりに入れている会社と、別建てにしている会社では、横並びの数字に意味がありません。
だからこそ、見積もりは金額の大小ではなく、何が含まれていて何が含まれていないかで読む必要があります。安い見積もりが悪いのではなく、安さの理由が「省いているから」なのか「無駄がないから」なのかを見分けられないまま選ぶのが危ない。最安値を選んで、抜けていた工程を後から追加して、結局一番高くついた——というのが、初めての発注で最も多い失敗です。
請負と準委任、どちらの契約で頼むか
見積もりの中身と並んで、初めての発注者が見落としがちなのが契約形態です。ここを取り違えると、仕様変更のたびに揉めたり、思っていた責任を相手が負っていなかったりします。中小企業のシステム開発で実務上選ぶことになるのは、おおむね請負・準委任（ラボ型を含む）の二つです。
請負契約は、「決めた仕様のものを、決めた金額で、完成させて納品する」という契約です。完成責任が受託側にあり、約束したものが動かなければ受託側が直す義務を負います。発注者から見れば金額が固定で予算が読みやすく、完成の保証もある。ただしこれが成り立つのは、作るものが事前にはっきり決まっている場合だけです。仕様が固まっていない段階で請負にすると、ヒアリングで「やっぱりこうしたい」が出るたびに「それは契約範囲外なので追加で」となり、変更のたびに見積もり交渉が発生します。固いぶん、動くものには弱い契約形態だと言えます。
準委任契約は、「成果物の完成」ではなく「働いてもらった工数」に対して支払う契約です。エンジニアの稼働時間を買う形で、月いくらで何人月、というラボ型契約もこの一種です。仕様が動く、作りながら固めていく、優先順位を走りながら変える——こうしたアジャイル的な進め方や、要件がまだ探索段階の案件に向きます。半面、完成責任は受託側になく、「動くものが必ず出てくる」保証はありません。発注者側が方向を握り、何を作るかを判断し続ける関与が前提になる契約です。SES（システムエンジニアリングサービス）と呼ばれる人員提供の形態も、構造としてはこの工数ベースの仲間です。
| 契約形態 | 支払いの基準 | 向く案件 | 発注者が負う主なリスク |
|---|---|---|---|
| 請負 | 完成した成果物に固定金額 | 仕様が固まっている／予算を固定したい | 仕様変更のたびに追加費用・交渉が発生 |
| 準委任・ラボ型 | 働いた工数（人月・時間） | 仕様が動く／作りながら固める | 完成保証がなく、自社の関与・判断が前提 |
どちらが正解かは案件によります。要件がきっちり固まっているなら請負で予算を固め、まだ探りながら作る段階なら準委任で柔軟に進める。よくあるのは、最初に小さく準委任で試作・要件固めを行い、固まったところで本番を請負に切り替える、という二段構えです。最初から全部を請負の固定見積もりに押し込もうとすると、固まっていない部分が後から全部追加費用に化けます。逆に、仕様が明確なのに準委任でだらだら工数を積むと、終わりが見えずコストが膨らむ。自社の案件が「固まっているのか、動くのか」を見極めることが、契約形態選びの起点です。
丸投げをやめる — 要件定義と発注準備
ここまで読んで気づかれたと思いますが、見積もりが読めない理由も、契約形態を間違える理由も、根っこは同じ一点に行き着きます。発注側が「何を作りたいか」を言語化できていないことです。そして、初めての外注で最大の失敗要因も、まさにこれ——いわゆる丸投げです。
丸投げが事故るのは、受託側が業務を知らないからではなく、発注側にしか分からないことがあるからです。どの業務のどこが今いちばん困っているのか、現場が一日に何回その作業をするのか、誰が使うのか、絶対に外せない条件は何か——これらは、その会社で働いている人にしか言えません。ここを伝えずに「いい感じに作って」と渡すと、受託側は想像で埋めるしかなく、出てきたものが現場とずれる。そしてずれを直すたびに追加費用がかかる、という悪循環に入ります。
とはいえ、初めての発注者が立派な要件定義書を一人で書く必要はありません。求められるのは技術仕様ではなく、「何を解決したいか」という業務課題の言語化です。最低限、次の三つを自分の言葉で書き出せれば、相見積もりの土台になります。一つ、いま何にどれだけ困っているか（例：受注をメールと電話で受けて手書き転記しているせいで月に数回欠品が起きる）。二つ、それがどうなれば成功か（例：受注がその場で在庫に反映され、欠品アラートが出る）。三つ、絶対条件と、あれば嬉しい条件の区別（必須：外出先のスマホで在庫が見られる／任意：会計ソフトとの連携）。この三つを書いた一枚の紙が、いわゆる RFP（提案依頼書）の核になります。
この「必須」と「あれば嬉しい」を区別することが、実は予算管理の急所です。区別をつけないまま「全部欲しい」と伝えると、使われない機能まで作り込まれて、保守だけが重くなる。私たちは受託の側でも、むしろ削る提案を意識していますが、これは 作りすぎを防ぐスコープ設計 で詳しく書いた通り、「作る力」より「作らない判断」のほうがシステムの寿命とコストを左右するからです。要件をどう構造化して伝えるか、AI コーディングが普及した時代の要件定義のあり方については 要件定義の三層設計の記事 も合わせて読むと、発注前の準備の解像度が上がるはずです。
一枚の紙ができたら、それを同じ内容で複数社に渡して相見積もりを取る。これで初めて、各社の見積もりが「同じものを見積もった、比べられる数字」になります。冒頭の食品卸の専務さんには、この一枚を一緒に作るところからお手伝いしました。それを揃えて出し直したら、80 万と 600 万だった見積もりは、200 万円台に三社が収まりました。差が大きかったのは、各社が違うものを見ていたからだったのです。
契約書で必ず確認する条項
要件と相見積もりが整い、頼む会社が決まったら、最後の関門が契約書です。ここで見落とすと、納品後に取り返しのつかない事態になる項目があります。専門用語を全部理解する必要はありませんが、次の点は発注者として必ず確認してください。
最も重要なのが、ソースコードの著作権の帰属です。これを取り決めずに発注すると、納品物のソースコードの権利が受託側に残り、後から別の会社に保守や改修を頼めなくなります。作った会社としか連絡が取れず、その会社が値上げしてきても、廃業しても、自社では何も触れない——これが塩漬けの典型的な入り口です。「ソースコード一式を成果物として納品し、著作権を発注者に譲渡する（または改変・他社への委託を認める）」旨を契約に入れておくこと。これだけで将来の選択肢がまるで変わります。
次に、契約不適合責任（旧来の瑕疵担保責任にあたるもの）です。納品後に不具合が見つかったとき、いつまで、どこまでを受託側が無償で直すのか。請負ならこの責任が伴いますが、期間や範囲は契約で定まります。あわせて、検収条件——どういう状態になったら「完成・受領」と認めるのか、その判定基準とテストの範囲を曖昧にしないこと。「動いたら検収」では、何をもって動いたとするかで揉めます。
そして、保守の範囲と追加要件の扱いです。納品後の保守に何が含まれ何が含まれないのか、月いくらなのか。バグ修正は保守内だが機能追加は別料金、という線引きがどこに引かれているか。追加要件が出たときにどういう手続き・単価で対応するのか。ここを決めておかないと、後から「それは保守外です」と想定外の請求が来ます。
保守費用の感覚も持っておきましょう。一般的な目安として、年間の保守費用は初期開発費の 10〜15% 程度を見込むのが通例です。500 万円で作ったなら、年に 50 万〜75 万円前後が保守の相場感。これを予算に入れずに初期費用だけで判断すると、運用フェーズで資金繰りが苦しくなります。システムは買って終わりの物ではなく、飼い続ける生き物に近い。「作る費用」と「飼う費用」は分けて予算化してください。
なお、AI コーディングが実用化した 2026 年は、この相場の前提が少しずつ動いています。実装そのものの工数が圧縮され、小規模なものは以前より安く・速く作れるようになりつつある一方、安く速く作れるからこそ設計の甘いものが量産され、保守で詰むリスクはむしろ上がっています。古くなったシステムの作り直しでも、AI 支援で移行を 数年から数週間に圧縮する進め方 が現実になりましたが、これも「丸投げで一瞬」ではなく、人が判断と品質を握る前提での話です。AI で安くなった分を価格の安さだけで受け取ると、保守費用で取り返される。価格の内訳と保守設計を見る目が、AI 時代はむしろ重要になっています。
初めての発注でハマる失敗パターン
最後に、これまで相談を受けてきた中で繰り返し見る失敗を、早見表にまとめておきます。自社の発注が当てはまっていないか、発注前のチェックリストとして使ってください。
| 失敗パターン | 何が起きるか | 防ぎ方 |
|---|---|---|
| 丸投げ・要件が曖昧 | 出てきたものが現場とずれ、修正で追加費用が膨らむ | 業務課題を一枚の紙に言語化してから相見積もり |
| 最安値で選ぶ | 工程が省かれており、後から足して結局割高に | 金額でなく「含まれる工程」で見積もりを比べる |
| 契約形態の取り違え | 仕様変更のたびに揉める／終わりが見えず工数が膨張 | 案件が「固まっている／動く」で請負か準委任を選ぶ |
| 保守を考えない | 運用費が予算に無く、改修のたびに資金繰りが苦しい | 年10〜15%の保守費を初期から予算化する |
| ソースが納品されない | 作った会社としか連絡が取れず塩漬けに | 著作権の帰属と他社委託の可否を契約に明記 |
この五つは、ほとんどが発注前の準備で防げるものです。逆に言えば、納品後に気づいても手遅れになりやすい。安い見積もりに飛びつく前の数時間を、要件の言語化と契約条項の確認に使うだけで、後の数百万円と数年の塩漬けを避けられます。中小企業の DX が「導入はしたが成果が出ていない」で止まりがちな構造は 中小企業DXの成功事例 でも触れた通りで、その分かれ目の多くは、作る前の発注の質にあります。
次の一歩
初めての業務システム外注で失敗しないために、いきなり開発を頼むのではなく、順番を逆にしてください。まずやるべきは、自社の業務課題を一枚の紙に言語化すること。いま何に困っていて、どうなれば成功で、何が必須で何が任意か。この一枚があれば、相見積もりは比べられる数字になり、契約形態の選択も見え、丸投げの事故も防げます。
そのうえで、できれば小さく始めること。最初から全社の基幹を一気に作ろうとせず、いちばん困っている一業務だけを小さく作って現場で当て、手応えを見てから広げる。要件が固まっていないうちは準委任で試し、固まってから請負で本番に作り直す——この順番が、予算の事故を最も減らします。
要件の言語化が自社だけでは進まない、相見積もりの読み方が分からない、契約条項のどこを見ればいいか不安——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。開発の受注ありきではなく、まずは業務課題の棚卸しと、そもそも外注すべきかどうかの見立てから、率直にお手伝いします。
