開発の外注先から見積書が届いたものの、「この金額は妥当なのか」が判断できない——発注直前のこの不安は、予算を握る事業会社の責任者なら誰もが通る場面です。総額だけを見て「思ったより高い」「相見積もりより安い」と比べても、その数字が何に対する対価なのかが分からなければ、妥当性は判断できません。
この記事は相場表を並べるためのものではありません。狙いは、届いた見積もりが妥当かどうかを発注側が自分で判断できるフレームを渡すことです。まず外注費用のレンジ感を押さえ、人月単価の中身を設計・実装・テスト・PM・コミュニケーションに解体し、「高すぎる見積もりを見抜く観点」と請負一括発注と月額伴走の費用対効果まで示します。外部活用そのものの選び方は外部技術リソースの選び方もあわせてご覧ください。
なお筆者・馬込は、受託側で見積もりを作る立場と、発注側で見積もりを受け取る立場の双方を経験してきました。本記事は、その費用構造を内側から見てきた実務目線で書いています。
外注費用の相場感とレンジ
まず大枠のレンジ感です。システム開発の外注費用は、人月単価×工数（人月）で組み立てられるのが一般的で、人月単価は担当者のスキルや所属する会社の規模によって幅があります。一般に言われる目安として、おおよそ次のようなレンジで語られることが多いです。
| 区分 | 人月単価の目安（一般的なレンジ） | 主な担い手 |
|---|---|---|
| 若手・初級エンジニア | 50〜80万円/月 | 経験の浅い実装担当 |
| 中堅エンジニア | 80〜120万円/月 | 設計から実装まで一人称で回せる層 |
| シニア・リード級 | 120〜160万円/月 | 技術選定・設計・難所の実装を担う層 |
| PM・テックリード | 120〜200万円/月 | 進行管理・品質・技術判断を担う層 |
これはあくまで一般に語られる目安で、技術領域や地域、契約形態によって上下します。重要なのは、総額＝単価×工数であり、総額の妥当性は「単価が適正か」と「工数の前提が妥当か」の二軸でしか判断できないということです。総額だけを相見積もりで比べても、片方が工数を低く見積もって後で膨らむなら意味がありません。次章で、その単価の中身を分解します。
人月単価の内訳を解体する
「エンジニア1人月100万円」と言われると、つい「実装する人の人件費」だと思いがちですが、実際の見積もりにはそれ以外の工程が織り込まれています。人月単価が何の対価なのかを分解すると、妥当性の判断軸が見えてきます。一般的な開発工程の比重を、ざっくり示します。
| 工程 | 含まれる作業 | 工数比の目安 |
|---|---|---|
| 要件定義・設計 | 要件整理、画面・データ設計、技術選定 | 20〜30% |
| 実装 | コーディング、機能開発 | 30〜40% |
| テスト | 単体・結合・総合テスト、不具合修正 | 20〜30% |
| PM・進行管理 | 進捗管理、課題管理、品質管理 | 10〜20% |
| コミュニケーション | 定例、仕様調整、レビュー、ドキュメント | 5〜15% |
ここで発注側が誤解しやすいのは、実装だけが価値で、それ以外は無駄という見方です。実際には、設計の精度が低ければ実装で手戻りが増え、テストを削れば運用後の障害対応で高くつきます。PMやコミュニケーションの工数は一見「作っていない時間」に見えますが、ここを削った見積もりはむしろ赤信号です。指示の解釈ズレや仕様の握り違いが、後から最も高くつく追加費用を生むからです。
つまり妥当性を判断するときは、「実装比率が高い＝効率的」と短絡せず、設計・テスト・PMに相応の工数が割かれているかを見ます。これらがほぼゼロで実装だけが積まれた見積もりは、安く見えても運用フェーズで跳ね返るリスクを抱えています。この「安さだけで選ぶ」落とし穴は開発外注の失敗でも扱っています。
高すぎる見積もりを見抜く観点
内訳の解像度が上がると、「高すぎる見積もり」を見抜く観点も具体的になります。発注側が確認すべきは、次の5点です。
- 工数の前提が示されているか：総額だけで、何人月をどう積んだのかが書かれていない見積もりは、妥当性を検証できません。「設計◯人月・実装◯人月」と内訳が出せるかを確認します。出せない相手は、自分でも根拠を持っていない可能性があります。
- バッファの厚みが説明できるか：見積もりにはリスク分のバッファが乗ります。これ自体は健全ですが、「なぜこの厚みか」を説明できないバッファは、不確実性を発注側に転嫁しているだけのこともあります。
- 設計・テストが不自然に薄くないか／厚すぎないか：前章の比率から大きく外れる場合、薄ければ品質リスク、厚すぎれば過剰スペックの疑いがあります。どちらも理由を聞く価値があります。
- コミュニケーションコストが二重計上されていないか：定例や調整の工数を各工程に乗せたうえで、さらにPM費として別途厚く積んでいないか。重複は総額を不必要に押し上げます。
- 「一式」表記でブラックボックス化していないか：「開発一式◯◯万円」とだけ書かれた見積もりは、後の仕様変更時に何が含まれていたのかで揉めます。発注側が損をしやすい典型です。
逆に言えば、内訳の質問にきちんと答えられる相手の見積もりは、たとえ高くても信頼できることが多いです。妥当性は金額の大小ではなく、根拠の透明性で測るのが実務的です。なお、要件が固まりきっていない段階で総額を一括見積もりさせること自体に無理がある、という構造的な問題もあります。これは契約形態の選び方に関わるため、準委任契約と請負契約の違いとあわせて理解すると判断がぶれません。
請負一括 vs 月額準委任の費用対効果
見積もりの妥当性とあわせて考えたいのが、契約形態による費用構造の違いです。同じ開発でも、請負で一括発注するか、月額の準委任で伴走してもらうかで、総コストの出方がまったく変わります。
| 観点 | 請負一括発注 | 月額準委任（伴走） |
|---|---|---|
| 費用構造 | 確定スコープに対する固定総額 | 月額×期間（稼働ベース） |
| 初期の見積もり精度 | 要件が固いほど精度が高い | 動く要件でも始められる |
| 変更耐性 | 仕様変更ごとに追加見積もり | 優先度の調整で吸収しやすい |
| 総コスト感（要件が固い場合） | 抑えやすい | 割高に感じることがある |
| 総コスト感（要件が動く場合） | 変更費・手戻りで膨らみやすい | 変動を織り込めるため読みやすい |
| 発注側に必要な前提 | 完成形を描き切れていること | 優先度を決める判断ができること |
ポイントは、「要件がどれだけ動くか」で得な形が逆転することです。仕様が完全に固まり、変更がほぼ見込めない開発なら、請負一括のほうが総額を抑えやすい。一方、これから要件を詰める、市場の反応を見て方向を変える可能性がある開発を請負一括にすると、変更のたびの追加見積もりと手戻りで、結果的に高くつくことが珍しくありません。
筆者が発注側で経験した中でも、「安く固定できた」はずの請負契約が、要件の揺れによる追加費用で当初予算を大きく超える場面は何度もありました。逆に動く前提の開発を月額伴走に切り替えてからは、毎月の優先度すり合わせで変動を吸収でき、総額の見通しが立てやすくなりました。
TechMateという選択肢
「要件が固まりきっておらず、請負一括では追加費用が読めない。かといってエンジニアを採用するには時期尚早」——この中間に位置するのが、月額の準委任で伴走するTechMateです。
TechMateは月単位の準委任契約を基本とし、最低2か月からの利用を推奨しています。代表・PMの馬込浩を中心に、2名以上の体制で入ります。基本フルリモートで、自社プロダクト／自社サービスを持つ事業会社の開発・プロダクト責任者を対象に、要件の整理から実装、優先度の調整までを月額で伴走します。費用構造が月額で明確なため、本記事で触れた「内訳のブラックボックス化」や「変更のたびの追加見積もり」といった、発注側が損をしやすいポイントを避けやすいのが特徴です。
料金は税抜・月額で、ライト60万円・スタンダード80万円・プロ160万円の3プランです。どのプランが自社の開発量に合うか、請負一括と比べて費用対効果がどうなるかは、具体的なケースで試算するのが確実です。プランの詳細は月単位の準委任プラン、これまでの事例をご確認ください。見積もりの妥当性を一緒に確かめたい段階でも、無料相談でお話しできます。
よくある質問
Q. 相見積もりで一番安い会社を選べば失敗しませんか？ A. 総額だけの比較は危険です。安い見積もりは設計・テスト・PMの工数を削っていることがあり、その分が運用後の障害対応や手戻りとして跳ね返ることがあります。比べるなら総額ではなく、工数の内訳と前提の妥当性を比べてください。
Q. 見積もりの内訳を出してもらえません。問題ありますか？ A. 工数の積み上げを示せない相手は、自分でも根拠を持っていない可能性があります。妥当性を発注側で検証できない見積もりは、後の仕様変更時にも揉めやすい傾向があります。内訳を出せるかどうか自体が、相手を見極める材料になります。
Q. 要件がまだ固まっていません。それでも相場感は掴めますか？ A. 要件が動く段階で総額を一括見積もりさせること自体に無理があります。この場合は固定総額より、月額の準委任で稼働ベースに切り替えたほうが、費用の見通しが立てやすくなります。判断軸は準委任契約と請負契約の違いを参考にしてください。
外注費用の妥当性は、総額の大小ではなく、単価の中身と工数の前提が透明かどうかで判断するものです。人月単価を設計・実装・テスト・PM・コミュニケーションに分解し、内訳の質問に答えられる相手を選ぶ。そして、要件がどれだけ動くかに応じて請負一括と月額伴走を使い分ける——この視点があれば、高すぎる見積もりに発注してしまう失敗の多くは避けられます。
届いた見積もりが自社にとって妥当か、契約形態をどう設計すべきか迷ったら、具体的な金額と要件をお聞かせください。無料相談（30分）はこちらからお申し込みいただけます。