システム開発の見積もり｜費用の内訳・8つのチェックと7つの手法

「3社から見積もりを取ったら、高いほうと安いほうで金額が2倍以上ちがいました。どれを信じればいいのか、判断がつきません」

同じ要件を渡しても、見積金額は揃いません。単価だけでなく、作業範囲、品質水準、リスクの持ち方、見積もった時点の情報量が違うためです。本記事では、見積書の読み方と相場の捉え方を押さえたうえで、実務の手法を8類型に整理します。

① システム開発の見積もりとは

システム開発の見積もりとは、作るものを実現するための作業量、費用、期間、前提条件を着手前に示すことです。多くは工数（人日・人月）×単価に、クラウド利用料、ライセンス、機材、旅費、予備費などを加えて算出します。

見積もりの基本をすでにご存じの方は、③ 見積もり手法を8類型に分けるから読み進められます。

概算見積もりと正式見積もり

種類	出す時期	精度	目的
概算見積もり	要件が固まる前	幅が大きい	予算規模の把握、一次選定
正式見積もり	要件定義の後	幅が小さい	契約金額と条件の確定

企画、発注先選定、契約前で見積もりを更新する二段階以上の進め方が安全です。要件定義だけを先に契約し、その成果を基に開発を再見積もりする方法もあります。

開発費用の相場は「桁」と変数で見る

複数の競合資料に共通する幅を重ねると、小規模な開発は数百万円、中規模の業務システムは数百万円から数千万円、大規模な基幹システムは数千万円以上が一つの桁感です。これは価格表ではありません。画面数、利用者数、外部連携、データ移行、性能・可用性・安全性、開発期間と体制が同じでなければ比較できません。

システムの種類でも変数が違います。ECは決済・在庫・物流連携、アプリは対応端末と配信審査、業務システムは権限と既存データ、AIは学習・検索データの品質と評価方法が金額を動かします。種類別の単一相場を当てるより、同じ桁の中で何が増減要因かを確認するほうが実用的です。

人月単価は役割と体制で一桁の幅が出る

複数資料に共通する国内開発者の人月単価は数十万〜百数十万円、進行管理や上流設計は百万円台を含む幅です。海外拠点を使うオフショア開発では数十万円台の提示もあります。ただし、通訳、仕様伝達、品質管理、時差対応を別工数として積む場合があるため、単価だけで総額は決まりません。

大手のシステム構築会社、中堅・独立系、Web系、オフショアでは、管理層の厚さと再委託の段数が異なります。「提案した人が実装するか」「再委託先と直接会話できるか」を確認すると、単価差の構造が見えます。

開発会社のタイプと下請け構造

同じ内容でも、大手SIer・中堅SIer・独立系・Web系のどこに頼むかで金額の作られ方が変わります。大手は体制と品質保証の厚みが単価に乗り、実装の一部を協力会社へ再委託することがあります。再委託が挟まるほど、見積もりには中間の管理費が積まれます。

確認は1つで足ります。「実際に手を動かすのは誰か」を見積もりの場で聞き、体制図に社名まで書いてもらうことです。単価の高低を比べる前に、その単価が誰の作業に払われるのかを確かめます。

見積書の構成と有効期限

見積書には、宛名・件名・総額だけでなく、次を揃えます。

欄	確認する内容
作業内訳	工程、工数、単価、担当職種
前提条件	利用者数、データ量、連携先、発注側の提供物
対象外	調査、移行、教育、保守など含まない作業
成果物・検収	納品物、受入条件、確認期限
日程	納期、中間成果物、判断の締切
支払条件	着手金、中間金、検収後払い、締め支払日
変更条件	追加見積もりになる境界と承認手順
有効期限	単価・体制・為替などを維持できる期間

有効期限は複数資料で1〜3か月程度が目安とされています。期限内でも、要件、納期、体制、外部サービス価格が変われば再見積もりになるため、その条件を明記します。

支払条件の種類

支払いは、契約時の着手金、設計や試作など所定の工程を終えた時点の中間金、納品物を検収した後の残金という形に分けられます。工程ごとの請求にする場合は、請求のきっかけとなる成果物、確認期限、修正中の扱いまで見積書と契約書で揃えます。検収後払いでも、クラウド利用料や外部ライセンスをいつ負担するかは別に確認が必要です。改善策は、金額や比率だけでなく「何を確認したら支払いが発生するか」を一行ずつ対応させることです。

納期とマイルストーン

最終納期だけでは、認識違いが終盤まで見つかりません。要件一覧、業務フロー、画面案、基本設計、試作版、テスト結果など、中間成果物ごとに提出日と確認日を置きます。各確認点では、対象範囲、未決事項、次工程へ進む条件、発注側の回答期限を確認します。改善策は、日程表に「誰が・何を・いつまでに承認するか」を加え、判断待ちによる遅延と手戻りを見えるようにすることです。

費用の内訳と工程バランス

要件定義、設計、画面設計、実装、テスト、データ移行、導入支援、クラウド・ライセンス、進行管理、保守運用が基本です。旅費交通費、検証端末や機材、設備費も「その他」に埋めず、必要なら別行にします。

複数社の例では、実装が総額の半分前後、要件定義・設計・進行管理がそれぞれ1割前後を含む配分、テストが数%〜1割台という共通した桁が見られます。比率は正解ではなく警報器です。テストが極端に薄ければ対象範囲を、管理費が厚ければ体制と会議頻度を聞きます。

保守・運用費と総所有コスト

保守・運用は、複数資料で開発費に対して年1〜2割程度を含む幅が示されています。金額を動かすのは監視時間、問い合わせ窓口、障害時の応答・復旧目標、定期改修、クラウド利用量です。初期費用だけでなく、少なくとも数年分の保守、利用料、更新、移行、終了時のデータ取り出しまで含む総所有コスト（TCO）で比べます。

「一式」は何が危ういのか

「システム開発一式」は、変更前の基準線を消します。要件定義一式、テスト一式、移行一式と書かれていても、工数、成果物、対象、対象外、完了条件が併記されていれば比較できます。改善策は単純で、一式の行を工程×成果物×工数に分解してもらうことです。

② 隣接概念と契約を切り分ける

RFI・RFP・RFQの違い

• RFI（情報提供依頼）は、候補会社の技術や体制を知るもの
• RFP（提案依頼書）は、課題と条件を示して解決案を募るもの
• RFQ（見積依頼書）は、揃った条件で価格を求めるもの

RFPには背景、目的、対象業務、利用者、必須・希望・対象外の優先度、現行環境、連携先、データ移行、非機能要件、成果物、納期、予算幅、選定基準、質問期限を記載します。

業務フロー図と画面リストの作り方

業務フローは、長い説明文ではなく「作業・判断・データ」の3種類だけを置き、処理の順番を矢印でつなぎます。担当者や部署を行ごとに分けると、引き継ぎと判断の所在も伝わります。画面リストは、画面名、利用者、目的、主な入力、主な出力、連携先、優先度を列にした一覧表にします。依頼メールには、目的、対象範囲、参照資料、予算幅、希望時期、回答形式、質問窓口の7点を記載します。改善策は、完成度を上げる前に同じ版の図・表・依頼文を全社へ配り、比較条件を揃えることです。

予算の伝え方の型

予算は一点ではなく「レンジ＋社内事情＋時間軸」で伝えます。レンジは検討可能な幅、社内事情は承認枠や段階発注の可否、時間軸は予算を使える時期と初回リリースの希望時期です。発注先は、この3点から一括開発か段階開発か、必須機能をどこまで含めるかを提案できます。改善策は、安値を探る数字を先に置かず、予算内で優先する成果と次段階へ送れる範囲を併記することです。

請負・準委任と契約不適合責任

契約	約束の中心	仕様変更時
請負	成果物の完成	範囲外なら追加見積もり
準委任	一定期間の業務遂行	確保した時間の配分を変更

請負では、納品物が契約内容に合わない場合の契約不適合責任も確認します。民法上は追完、代金減額、損害賠償、解除が論点になり、買主が不適合を知ってから原則1年以内の通知が問題になります。個別契約で対応期間を定めることも多いため、見積書と契約書を法務担当者と突き合わせます。

2003年の裁判例には、当初想定外の追加作業を発注側が承諾した場合、追加額の明確な合意がなくても相当報酬の支払いが論点となったものがあります。教訓は、追加作業の有償・無償を事後に争うのではなく、変更依頼、見積もり、承認を着手前に記録することです。

SLA、受入テスト、負荷テスト

SLA（サービス水準合意）は、保守の受付時間、初動、復旧目標、稼働率などの合意です。RTOは復旧までの目標時間、RPOはどの時点までデータを戻せればよいかを表します。

開発会社の単体・結合・総合テストとは別に、発注側が業務上使えるか確かめる受入テスト（UAT）を置きます。多数利用や集中処理があるなら負荷テストも明記し、環境、データ、合格基準、発注側の参加工数まで見積もります。

パッケージ、個別開発、SaaS

方式	初期費用	向く条件	注意点
SaaS	抑えやすい	標準機能へ業務を合わせられる	月額、データ移行、解約条件
パッケージ＋改修	中間	業界標準を使い一部だけ変える	改修しすぎると更新が難しい
個別開発	大きくなりやすい	独自業務が競争力になる	保守、属人化、作り直し

最初から個別開発を前提にせず、既製サービスで代替できない差分だけを作ると、費用と納期を同時に抑えられます。

③ 見積もり手法を8類型に分ける

① 積み上げ型

作業分解構成（WBS）で作業を分け、人日を足します。標準タスク法は定型作業を標準時間で積む方法で、この型に含まれます。契約と検収に直結する一方、分解した人が見落とした作業は数字に出ません。

例として、設計10人日、実装30人日、テスト15人日、移行5人日なら計60人日です。ここへ職種別単価と諸経費を掛けます。

② 機能規模型

入出力やデータなど利用者から見える機能規模を測るファンクションポイント法などです。プログラム行数で測るLOC法（プログラムステップ法）も規模を換算する考え方ですが、言語や実装方法の影響を受けます。

③ パラメトリック型

画面数、機能数、データ量などの量に、生産性や難易度の係数を掛けます。たとえば30画面×0.4人月×難易度係数1.2という形です。数字は説明用の例であり、実際には自社の実績から係数を校正します。

④ 合議型

複数の専門家が独立して見積もり、差の理由を話して再見積もりします。ワイドバンド・デルファイ法や計画ポーカーが代表例で、専門家判断を一人の勘で終わらせない型です。

⑤ ベンチマーク型

過去の類似案件や公開統計と照合する類推見積もりです。類似案件800に対し、画面数や連携数が約1.25倍なら1,000相当と置くように、差分の根拠を示します。単位は社内管理用でよく、実額である必要はありません。

⑥ 確率型

楽観値O、最頻値M、悲観値Pを置き、三点見積りでは (O + 4M + P) ÷ 6 で期待値を出します。たとえば10日、15日、30日なら (10 + 4×15 + 30) ÷ 6 = 約16.7日 です。一点断定を避け、納期を確率付きの幅で扱えます。

⑦ 作って測る型

不確実な機能だけを小さく試作し、実際にかかった工数を残りの見積もりへ戻します。生成AIで試作が速くなったことで使いやすくなった型です。全体を先に作るのではなく、最も読めない箇所を実測へ変えます。

⑧ プライスツーウィン型

発注側の予算や市場価格から逆算し、その枠内で実現範囲を設計します。予算に合わせて根拠なく工数を削る方法ではありません。「この予算なら必須機能まで」「次段階で追加」と範囲を動かす方法です。価格上限が先に決まる新規事業や入札で有効ですが、品質・安全性を黙って削らないことが条件です。

類型	数えるもの	強い場面	主な弱点
積み上げ	作業	要件確定後の契約	見落とし
機能規模	機能の大きさ	相見積もり	非機能要件
パラメトリック	規模と係数	条件比較	校正データ
合議	複数人の判断	認識合わせ	集団の偏り
ベンチマーク	類似実績	桁の検算	新規領域
確率	幅と確率	再予測	組織への説明
作って測る	実測値	要件未確定	一括請負との相性
プライスツーウィン	予算と優先度	上限が先にある	隠れた品質削減

④ この記事では「作って測る型」を掘り下げる

8類型は競合するものではなく、段階で組み合わせます。その中でも、要件定義書をまだ書けないAI・新規事業の発注に焦点を当てます。この段階では精巧な計算式より、見積もりの入力となる情報を増やす「作って測る型」が効くためです。

⑤ 見積書を細かくするほど比較しやすい。それでも精度は上がり切らない

工程、単価、成果物、前提条件を細かく書くのは正しい改善です。複数社の比較もしやすくなります。

ただし、未知の仕様を細かい行へ割っても、未知が既知に変わるわけではありません。構想段階では見積もりの幅が大きく、要件定義、基本設計、詳細設計と情報が増えるほど縮みます。重要なのは、幅を隠して一点に見せることではなく、どの未知が幅を生んでいるかを示すことです。

⑥ ARCの見積もり実務｜金額の前に「読めない一か所」を特定する

ARCの見積もり実務では、最初に画面一覧を完成させるのではなく、工数を最も揺らす仮説を特定します。生成AIなら回答品質と評価方法、既存システム連携なら仕様と検証環境、データ移行なら欠損と表記ゆれが候補です。

次に、その一か所だけを短い検証単位へ切ります。入力、期待する出力、合格条件、記録する時間を先に決めます。改善点は、試作の成否だけでなく、調査・待ち・手戻りも実測に含めることです。

⑦ ARCの見積もり実務｜実測を残りの計画へ戻す

試作後は、実装時間だけを横展開しません。仕様確認、データ整備、評価、修正、関係者の判断待ちを分け、残りの機能に同じ構造が何回現れるかを数えます。さらに、ベンチマーク型で桁を検算し、積み上げ型で契約可能な行へ直します。

この進め方は、AIプロダクト開発で扱う、要件が固まる前の検証と相性があります。改善点は、実測値を平均一つにせず、最短・通常・最長の幅で残すことです。

⑧ 現場の壁｜見積もりを揺らすのは仕様だけではない

非機能要件が後から現れる

可用性、性能、拡張性、安全性、監視、バックアップは、画面数に出にくい一方で設計・試験を増やします。何時間止められるか、何件を何秒で処理するか、どのデータを誰が見られるかを先に決めます。比率を一律に足すのではなく、水準ごとの差額を出してもらうのが改善策です。

バッファと一般管理費が混ざる

予備費は特定できないリスク、作業バッファは工数の揺れ、一般管理費は組織運営の費用です。「その他」にまとめず、名称、対象リスク、使用条件を分けます。値下げ交渉ではバッファ率だけを削らず、未知を検証して対象リスクそのものを減らします。

発注側の判断待ちが工数になる

素材、アカウント、データ、規程の提供が遅れたり、決裁者の返答に時間がかかったりすると、待機と組み替えが発生します。発注側の担当者、回答期限、用意するものを見積もり前に表へ置くのが改善策です。

値引き交渉で守るべきものまで削る

良い削減は、必須でない機能を次段階へ移す、既製サービスを使う、試作で未知を減らす、納期を調整することです。悪い削減は、テスト、移行、監視、安全性、進行管理を説明なく薄くすることです。予算は「数百万円台、年度内、初回リリースまで」のように幅・社内事情・時間軸で伝え、極端に低い探りの数字は置きません。

失敗は「事例→対策」で先回りする

• 追加要望で予算超過：変更票に影響範囲、費用、納期を記録し、承認後に着手する
• 口頭合意で言った・言わない：議事録と課題表を一つの正本にする
• 納品後に業務で使えない：受入テストのシナリオと合格条件を要件定義中に作る

総額を割り戻して検算する

総額から外部利用料と諸経費を除き、人月で割ると、暗黙の平均単価が見えます。画面数でも割り戻せますが、「1画面なら同じ工数」とは限りません。入力項目、権限、連携、例外処理の差を確認します。改善点は、単価が高い・低いと決めつけず、割り戻しで見えた異常値を質問に変えることです。

⑨ まとめ｜違うのは金額ではなく、数えたものと情報量

3社の見積金額が揃わないとき、最初に比べるのは総額ではありません。作業範囲、前提条件、品質水準、契約、見積もった段階を揃えます。「一式」を分解し、保守を含む総所有コストで見れば、価格差の理由を質問できます。

見積もり手法は8類型です。要件が固まった部分は積み上げ、桁はベンチマーク、不確実性は三点見積り、読めない部分は作って測る型で扱います。予算が先ならプライスツーウィン型で範囲を動かします。改善の起点は、金額を一点に寄せることではなく、幅を生む未知を一つ減らすことです。

⑩ この先｜見積書を受け取った日の順番

1. 各社の対象範囲と対象外を一列に並べる

2. 「一式」を工程・成果物・工数へ分ける

3. 前提条件、非機能要件、発注側の役割を揃える

4. 初期費用ではなく数年分の総所有コストを比べる

5. 最も読めない一か所だけ検証し、正式見積もりを更新する

これで、値段を選ぶ作業から、前提とリスクを選ぶ作業へ変わります。

⑪ よくある質問

Q. 相見積もりは何社に依頼すればよいですか

比較できる複数社へ同じ資料・期限・回答形式で依頼します。社数を増やすより、質問へ回答でき、前提を明示する会社を残すことが重要です。

Q. 安い見積もりは避けるべきですか

安い理由を説明できるなら問題ありません。既製部品、再利用、得意領域、体制の違いで下がる場合があります。テスト、移行、保守、管理が抜けていないかを確認します。

Q. 見積もり前に発注側が準備するものは何ですか

目的、対象業務、必須・希望・対象外、業務フロー、画面リスト、データ、連携先、非機能要件、予算幅、希望時期、社内の判断者を揃えます。未確定な点は隠さず未確定と記載します。

Q. 仕様変更はいくらから追加費用になりますか

金額の大小ではなく、契約範囲、成果物、前提条件を変えるかで判断します。変更依頼、影響調査、見積もり、承認、着手の順を契約時に決めます。

Q. 生成AIを使えば見積もりは安くなりますか

自動的には下がりません。試作や定型実装は速くなる一方、データ整備、評価、安全性、運用監視が増えることがあります。読めない箇所を先に実測し、削減できた工数と新たに必要な工数を分けて見ます。