システム開発の見積もりの内訳——工程・工数・単価に分解して読む方法と、金額差の正体【2026年版】

手元に3社の見積書が並んでいて、金額が1,180万円、1,650万円、2,400万円。同じ要件を渡したはずなのに倍の差がある。一番安い会社の見積書は5行しかなく「開発一式 800万円」と書かれている。一番高い会社は30行ある。どちらが誠実なのか、どう説明すれば役員会を通るのか——この記事にたどり着いた方の多くは、そういう状態にいます。

先に結論を書きます。見積書は金額の大小で読むものではありません。『どの工程に、何人月を、いくらの単価で積んだか』の3つに分解できたとき、はじめて比較できる資料になります。そして3社の金額差の正体は、単価の差ではなく範囲の差であることがほとんどです。安い見積書は安いのではなく、テストとデータ移行と保守が入っていないだけ、ということが実際に起こります。

この読み方を身につけると、値引き交渉という不毛な会話から降りられます。代わりにできるのは、各社へ同じ質問を投げて、抜けている範囲を埋めてもらうことです。金額は上がるかもしれません。しかし契約後に「それは見積もり範囲外です」と言われて追加費用を払う事態は避けられます。稟議で説明する言葉も、そこで手に入ります。

私はTALENTBASE VIETNAMでCOOを務めています。人材業界の出身で、商流と中間マージンの実務を見てきました。2018年以降、約100社のご相談を受けるなかで「A社1,200万円、B社2,300万円。この差は何ですか」という質問は何度も届きます。当社は実務3年のエンジニアで月額1,500USD、5年で2,000USD、ブリッジSEで3,000USD(1USD=150円換算が目安)と単価を公開しています。公開できるのは、2,000名以上の人財データベースから直接アサインしていて、多重下請けの中間マージンが乗らないからです。単価が見えていれば、議論は工数の根拠に移せます。

この記事では、見積書の項目一覧と各項目の中身、工程別の金額比率の目安、人月単価の3層構造、見積もりに入っていないことが多い費用のチェックリスト、相見積もりを同じ土俵に並べる手順を、順に整理します。読み終えたら、手元の見積書に赤ペンで印をつけながら、各社に投げる質問を3つ選んでみてください。それだけで、来週の会議で話せる内容が変わります。

見積書の内訳は「工程 × 工数 × 単価」で読む——項目一覧と各項目の中身

見積書の項目名は会社ごとに違います。ある会社は「基本設計」と書き、別の会社は「設計費用」とだけ書く。それでも骨格は共通していて、どの見積書も工程・工数・単価の3つに分解できます。この3つに置き換えて読むことが、比較の第一歩になります。

見積書に並ぶ項目と、それぞれが何の作業か

まず項目の意味を押さえます。次の表は、システム開発の見積書に登場する代表的な項目と、その中身です。発注者が何をする必要があるかも併記しました。ここが空欄の工程は、実際には発注側の作業時間が発生します。

この表を横に置いて手元の見積書を見ると、どの行が欠けているかが分かります。私のところに届く相談で最も多いのは、テスト・導入移行・運用保守の3行が抜けているケースです。

「一式」「諸経費」「管理費」に何が入っているか

「開発一式 800万円」という書き方は、それ自体が悪いわけではありません。概算段階では珍しくない書き方です。問題は、その一式の中に何が含まれ、何が含まれないかを誰も確認しないまま契約に進むことです。

管理費(進行管理費・PM費)は、開発費に対する一定の割合として見積もられるのが一般的です。ただし、その比率を定めた法律や公的な基準はありません。プロジェクトの難易度や関係者の多さで変わります。比率そのものより、その管理費で誰が何をするのか——定例会の頻度、報告の形式、課題管理の方法——を聞くほうが実務的です。

私は人材業界の出身で、商流と中間マージンの実務を見てきました。その経験から言えるのは、管理費が不透明な見積書は、多くの場合その会社自身が下請けに出しているということです。自社のエンジニアが作るなら、管理の中身は具体的に説明できます。

概算見積もりと詳細見積もりは別物

システム開発では、要件が固まる前に概算見積もりを出し、要件定義の後に詳細見積もりを出す「2段見積もり」が一般的です。概算はあくまで予算感であり、詳細は作業量に基づいた金額です。この2つを同じものとして扱うと、後で「話が違う」となります。

見分け方は簡単で、前提条件が書かれているかどうかです。「画面数20、外部連携なし、データ移行は対象外、テストは結合まで」といった条件が明記されていれば詳細寄り、何も書かれていなければ概算です。前提条件のない見積書は、金額を比べても意味がありません。項目が読めるようになったら、次は金額の中身を確かめます。

金額の妥当性を確認する——工程別の比率、人月単価の中身、入っていない費用

妥当性は、総額を見ても分かりません。確かめる順序は3つです。工程別の比率で偏りを探し、人月単価の中身を分解し、書かれていない費用を洗い出す。この順で見ると、金額差の理由がたいてい言葉にできます。

工程別の比率で偏りを見つける

工程ごとの金額が全体の何割かを計算してみてください。比率そのものに公的な基準はないため、本記事では数値の目安は示しません。代わりに、各工程が薄いとき・厚いときに何を疑えばよいかを整理します。

比率が偏っていること自体は問題ではありません。既存システムの改修ならテストの比重が上がりますし、2026年時点ではAIを使った実装の効率化で実装工程の比率が下がる見積もりも出てきています。当社もAIを活用した開発体制を組んでいます。大事なのは、偏っている理由を説明できるかどうかです。理由を聞いて即答できる会社は、工数を積み上げて計算しています。

人月単価の中身——給与・間接費・管理費と利益

見積書の単価は、エンジニアの給与ではありません。人月単価は、技術者の給与、社会保険や機材・オフィスなどの間接費、開発会社の管理費と利益の3つで構成されます。それぞれの比率を示す公的な一次統計はないため本記事では金額を示しませんが、多重下請けが入ると、このうち管理費と利益が階層ごとに積み上がります。

当社は単価を公開しています。実務3年のエンジニアで月額1,500USD、5年で2,000USD、ブリッジSEで3,000USD。1USD=150円換算が目安です。相場の約1/2という水準になります(当社調べ)。公開できる理由は構造にあります。2,000名以上の人財データベースから直接アサインするため、あいだに協力会社が入らず、中間マージンが乗りません。

読者に使ってほしいのはこの考え方のほうです。単価が安い会社に出会ったら、「なぜ安いのか」を構造で説明してもらってください。直接雇用なのか、下請けなのか、経験年数は何年なのか。安さの理由を構造で言える会社と、言えない会社があります。逆に単価が高い会社にも、その中身を聞く価値があります。単価の高低だけでは、どちらが得かは決まりません。

見積もりに入っていないことが多い費用

最後に、書かれていないものを探します。次のチェックリストを見積書と突き合わせてください。どれも後から「範囲外です」と言われやすい項目です。

当社が手がけた案件でも、決済アプリでは週次の保守を前提に体制を組みました。保守を含めた総額で比べないと、初年度だけ安い見積もりを選ぶことになります。安い見積もりは安いのではなく、書かれていないだけ——この一文を、手元の見積書を見るときの合言葉にしてください。

同じ土俵に並べる——相見積もりの取り方と、追加費用で揉めない準備

項目が読めて、妥当性の見方が分かったら、最後は比較の作法です。相見積もりは「3社に声をかける」ことではありません。同じ資料を渡し、同じ前提で出してもらい、同じ表に並べることです。

同じ資料を渡し、前提条件をそろえてから比べる

各社に口頭で説明を変えていると、見積もりの前提はばらばらになります。最低限そろえたいのは、目的と成功条件、対象業務の範囲、必須機能と将来機能の区別、想定ユーザー数、既存システムと連携先、希望する開始時期と公開時期の6点です。これを1枚の資料にして全社へ同じものを渡します。

そのうえで、比較表を作ります。列は会社名、行は工程・工数・単価・前提条件・含まれない範囲・保守。金額の行より、含まれない範囲の行のほうが判断材料になります。差が大きいときは、安いほうを疑うのではなく、両社に同じ質問を投げて範囲をそろえた再見積もりを依頼してください。

以前ご相談いただいた案件では、A社1,200万円、B社2,300万円という差がありました。並べ直すと、安いほうはテストの工数が極端に小さく、データ移行と外部API連携が範囲外、保守は別見積もり。範囲をそろえた結果、差は300万円程度まで縮みました。倍の差に見えたものの大半は、範囲の差だったわけです。

請負と準委任で、見積もりの意味は変わる

契約形態によって、見積書が約束しているものが違います。請負は完成責任を負う代わりに、契約時に決めた仕様が基準になります。仕様変更は追加費用や変更契約の対象です。準委任(ラボ型開発)は、一定の体制を一定期間提供する契約で、月額が先に決まります。

なお、契約形態についての本記事の記述は一般的な整理であり、法的助言ではありません。個別の契約の判断は弁護士にご確認ください。

この違いは発注者にとって、総額を固めたいのか、予算の上限を決めて優先順位を動かしたいのか、という選択になります。要件が固まっているなら請負が向きます。作りながら決めたい、優先順位が変わる前提なら準委任が向きます。当社が提供しているのはラボ型で、最小構成は日本人PM+2〜3人月の月額約80万円から。1名から始められ、最短2週間で開始、増員は約1週間、1か月単位でリプレイスメントに対応しています。

発注側が用意すると精度が上がるもの

見積もりの精度は、渡す情報の量で決まります。目的と成功条件を1枚に書く。現状の業務フローを図か箇条書きで共有する。必須機能と将来機能を分ける。現行データの件数と、連携先のシステム名・APIの有無を早めに確認する。この4つを用意するだけで、各社の見積もりは驚くほどそろいます。

当社にご相談いただく場合も、この4点があれば初回の打ち合わせで体制の提案までお出しできます。逆に、要件を伺った結果、当社の体制では合わないと判断することもあります。その場合は率直にお伝えします。受注のために工数を盛った見積もりを出しても、途中で破綻するのはお互いにとって損だからです。あなたの手元の見積書に、前提条件は書かれていますか。

よくある質問

システム開発の見積もりについて、実務でよく届く質問に答えます。いずれも当社への相談で繰り返し聞かれる内容で、判断を先送りにしがちな論点でもあります。

Q1. 見積もりは無料で出してもらえますか

概算見積もりは無料で対応する会社が大半です。ただし、要件定義を伴う詳細見積もりは有償になることがあります。要件定義そのものが作業だからです。当社は初回の打ち合わせと概算のご提示まで無料で対応しています。

Q2. 値引き交渉はしてよいですか

してかまいませんが、値引きは工数削減とセットになります。削られるのは多くの場合テストと設計で、品質リスクは発注者側に残ります。金額を下げたいときは、値引きではなく機能の優先順位を調整するほうが安全です。

Q3. 見積もりが出るまでどのくらいかかりますか

概算は資料をいただいてから数日から1週間程度が一般的です。当社の場合、体制のご提案まで含めてもお打ち合わせから約1週間、面談を経て開始まで最短2週間です。

Q4. オフショア開発なら総額も半分になりますか

単価は下がりますが、総額が半分になるとは限りません。ブリッジSEや日本人PMの費用、コミュニケーションの工数が加わるためです。当社は単価を公開しており、相場の約1/2の水準です(当社調べ)。総額で比べてください。

Q5. 為替や海外送金の費用は見積もりに含まれますか

当社は日本国内法人で、日本法に準拠した契約です。海外送金は不要で、見積もりに為替手数料や送金手数料は含まれません。円建てでご請求します。

まとめ: 見積書は工程・工数・単価に分解して読む——金額差の正体は、たいてい範囲の差

システム開発の見積書は、総額の大小で判断するものではありません。どの工程に、何人月を、いくらの単価で積んだか。この3つに分解できたとき、はじめて他社の見積書と比較できる資料になります。項目一覧で各工程の意味を押さえ、要件定義・設計・実装・テスト・進行管理への金額配分に偏りがないかを探してください。偏っていること自体は問題ではなく、偏った理由を会社が説明できるかどうかが判断材料になります。

次に、単価の中身を分解します。人月単価は技術者の給与・間接費・開発会社の管理費と利益で構成され、多重下請けが入るほど管理費と利益が階層ごとに積み上がります。そして、書かれていない費用を洗い出してください。データ移行、外部API連携、非機能要件、受入テストの支援、ライセンスとクラウド利用料、運用保守、検収後の不具合対応。この7項目は後から「範囲外です」と言われやすいものです。安い見積もりは安いのではなく、書かれていないだけ、ということが実際に起こります。

最後に、同じ資料を全社へ渡し、範囲をそろえた再見積もりを依頼します。倍に見えた金額差が、範囲をそろえると数百万円まで縮むことは珍しくありません。要件が固まっているなら請負、作りながら決めるなら準委任(ラボ型)という選び方もできます。単価そのものの水準はベトナムオフショア開発の単価相場、人月という単位の扱いは人月単価の相場もあわせてご覧ください。当社は実務3年1,500USD・5年2,000USD・ブリッジSE3,000USD(1USD=150円換算が目安)と単価を公開し、最小構成は日本人PM+2〜3人月で月額約80万円からご提供しています。現在の体制と要件をお聞かせいただければ、内訳を分解した概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。