概算見積もり・詳細見積もりとは
概算見積もりとは、要件が固まりきる前の段階で、システム開発にかかる費用と期間のおおよその目安を示す見積もりです。詳細見積もりとは、要件や設計が固まった後に、作業を細かく分解して工数を積み上げ、より確度の高い金額を算出する見積もりです。
言い換えると、概算は「だいたいこのくらい」という予算を立てるための目安、詳細は「この内容ならこの金額で請け負う」という契約の根拠です。概算は「ラフ見積もり」、詳細は「本見積もり」「確定見積もり」と呼ばれることもあります。
違いと見積もりの仕組み
| 観点 | 概算見積もり | 詳細見積もり |
|---|---|---|
| タイミング | 企画・相談・要件定義の前後 | 要件定義・基本設計の後 |
| 前提となる情報 | 目的、主な機能の一覧、規模感 | 機能仕様、画面一覧、外部連携、非機能要件 |
| 金額の幅 | 幅が大きい（上下の振れを含む） | 幅が小さい |
| 主な用途 | 予算確保、実施判断、依頼先の比較 | 契約、発注の最終判断 |
| 作り方 | 類似案件との比較、機能単位の大まかな工数 | 作業単位での工数の積み上げ |
システム開発の費用は、多くの場合「必要な工数（人月や人日）× 単価」で考えます。工数は、作る機能の数と複雑さ、画面数、外部連携、テストや移行の範囲などから見積もります。概算段階ではこれらの情報が粗いため、どうしても幅が出ます。開発会社によっては「〇〇〜〇〇」と幅で示したり、前提条件を列挙したうえで一つの金額を示したりします。
見積もりの金額を左右する主な要素は次のとおりです。
- 機能の数と、それぞれの複雑さ（計算ルールや例外処理の多さ）
- 画面や帳票の数とデザインのこだわり
- 外部サービスや社内システムとの連携の有無
- データ移行の範囲
- 性能・セキュリティ・可用性の要求水準
- テストの範囲、ドキュメントの量
- プロジェクト管理や打ち合わせの頻度
実務での使い方・具体例
架空の例として、新規事業で会員制のWebサービスを作ろうとしている会社を考えます。社内の予算申請のために、3社に概算見積もりを依頼したところ、金額に大きな差が出ました。
このような場合、金額だけで比べるのは危険です。差が出る理由の多くは「前提の違い」にあります。
- 各社の見積もりに書かれた前提条件（機能範囲、デザインの扱い、移行の有無）を一覧にする。
- 含まれている作業・含まれていない作業を確認する（テスト、マニュアル、リリース後の保守など）。
- 前提を揃えたうえで、同じ条件で再見積もりを依頼する。
- 不明点が多い部分は、要件定義を先に別契約で行い、その結果をもとに詳細見積もりを取る。
特に4の進め方は、概算と詳細の幅を縮める有効な方法です。要件定義を独立した工程として発注し、機能や画面を確定させてから開発の見積もりを取ることで、発注側は根拠のある金額で判断でき、開発側も無理な前提で請け負わずに済みます。
見積もりの精度を上げるために発注側が用意するもの
- 目的と、達成したいことの優先順位
- 必須機能と、あれば良い機能を分けた機能一覧
- 画面のラフや業務の流れの図
- 連携が必要なシステムと、その連携方法の情報
- 希望の時期と、予算の目安（伝えられる範囲で）
これらの資料は完璧である必要はありません。たとえば機能一覧なら、「誰が」「何をするための」機能かが一行ずつ書かれているだけでも、開発会社が工数を想定する手がかりになります。分からない部分は「未定」と明記しておけば、開発会社はその部分を前提条件として見積もりに書き分けてくれます。逆に、分からない部分を空白のままにすると、各社が独自の想定で埋めるため、見積もりの前提がばらばらになり比較できなくなります。
よくある誤解と注意点
- 概算の金額で契約できるとは限らない：要件が具体化すれば金額は変わります。概算は判断のための目安と捉えます。
- 安い見積もりが得とは限らない：必要な作業が含まれていないだけ、ということがあります。内訳と前提を必ず確認します。
- 予算を伝えないのは損になることも：予算の上限が分かれば、開発会社はその範囲で優先すべき機能を提案できます。
- 仕様変更の扱いを決めておく：詳細見積もり後の追加・変更がどう費用に反映されるかを、契約時に確認します。
関連用語
- WBS（作業分解構成図）：作業を分解して工数を積み上げる土台。
- 仕様書：詳細見積もりの前提となる文書。
- 基本設計：見積もりの精度を高める設計工程。
- SES（システムエンジニアリングサービス）：エンジニアの稼働に対して費用を払う契約形態。
- MoSCoW分析：機能を必須・推奨などに分けて優先度を付ける手法。
- 実践記事：見積もり比較のコツ、見積もり依頼前に準備する資料
Otsumuに相談できること
作るものがはっきりしていて、機能一覧や画面のイメージも揃っているなら、複数の開発会社に同じ資料を渡して見積もりを取れば十分に比較できます。何を作ればよいかがまだ固まっていない、見積もりの差の理由が分からない、予算の範囲で何を優先すべきか迷っている、といった場合は、目的から逆算して機能を絞り込み、見積もりの前提を整えるところから支援できます。Otsumuではシステム開発の相談に加え、事業の検証段階であれば新規事業レビュー Sprint（48万円・税別、1〜2週間）で計画と範囲を整理することもできます。30分の無料相談でお気軽にご相談ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01