「概算見積書を作ってほしい」と言われたものの、作った経験がなく手が止まる——多くのエンジニアが通る道です。とくに真面目な人ほど「正確な数字を出さなければ」と気負い、かえって完成できなくなります。
この記事を読むと、概算見積に求められるのは「数字の精度」ではないという考え方に切り替えられ、上司から頼まれがちな「①実装イメージ ②工数概算 ③前提条件」の3点で見積書を組み立てられるようになります。
なぜ「初めての概算見積」でつまずくのか
概算見積とは、要件がまだ固まりきっていない初期段階で「だいたいこのくらいの規模・金額です」を示す見積もりです。契約直前に出す精緻な「詳細見積」とは目的が違い、発注側が予算を確保したり、進めるかどうかを判断したりするための”あたり”をつけるものです。
つまずきの正体は、この性質を知らずに「詳細見積なみの正確さ」を自分に課してしまうこと。しかし見積もりには努力では超えられない構造的な限界があります。
【用語】詳細見積：要件定義が終わり作業内容が固まった段階で作る精緻な見積もり。契約金額の根拠になる。概算見積はその前段。
見積もりのブレは「努力」では消えない（不確実性コーン）
不確実性コーンは、1981年にバリー・ベームが示し、後にスティーブ・マコネルが命名した、開発が進むほど見積もりのブレが小さくなることを表した図です。要件や技術が固まっていない初期段階では、見積もりが最大で数倍規模までブレ得るとされ、フェーズが進むにつれて誤差が収束します。
この図が教えるのは、何も決まっていない段階でいくら時間をかけても到達できる正確さには限界がある、ということです。だから概算では精度を追うより「どんな前提のもとでの数字か」を明確にすることに力を使うのが正解です。
【用語】不確実性コーン：開発が進み決定事項が増えるほど、見積もりのブレ幅が小さくなる様子を円錐状に表した図。
考え方の核：正確さは「精度」でなく「前提の明確さ」で担保する
概算見積の”正確さ”とは、数字をピタリと当てることではなく、「この前提なら、だいたいこの規模・金額」という根拠を説明できることです。次の3つで「正確に出さなきゃ」の呪縛を外せます。
- 幅（レンジ）で出す：「800万円」より「700〜1,000万円程度（要件次第）」。不確実さを情報として渡せる。
- バッファを明示する：「未確定要素が多いため20%のバッファを含む」と一行足して積む。
- 時間を区切る：コーンの入口では時間をかけても精度は上がらない。根拠が説明できたら一度手を止めてレビューへ。
【用語】バッファ：不確定要素やリスクに備えて見積もりに上乗せする予備の工数・費用。
見積もりの3つの代表的な手法
状況に応じて手法を使い分けることが重要です。以下に代表的な3つの手法をまとめます。
| 手法 | 概要 | 向いている場面 | 注意点 |
|---|---|---|---|
| ①類推法（トップダウン見積） | 過去の類似案件をもとに「この規模なら約○人月」と素早く算出 | 初期の概算・予算確保向き | 経験のないシステムには使えず、補正が必要 |
| ②ボトムアップ法（積み上げ見積） | 作業を機能・工程単位に分解しWBSで洗い出して合算 | 要件確定後の詳細見積 | 洗い出し漏れが誤差に直結 |
| ③ファンクションポイント法（FP法） | 機能をユーザー視点で5要素に分類し規模を数値化 | 言語・スキルに左右されない客観指標が必要な場合 | 正確な算出に専門知識が必要。非機能要件は評価しにくい |
【用語】人月：1人が1か月作業する量の単位。12人月＝ざっくり1人で12か月ぶんの作業量。
【用語】WBS：大きな作業を管理できる小さなタスクへ階層的に分解・一覧化する手法。「作業の地図」。
【用語】ファンクションポイント：機能の数と複雑さからシステム規模を測る単位（建物の延床面積のような物差し）。
【用語】非機能要件：性能・セキュリティ・可用性など「どれだけの品質で動くか」に関する要件。
上司に頼まれがちな「3つの観点」で組み立てる
実務では「①何をどう作るか（実装イメージ）②工数概算（ざっくりでOK）③前提条件」を頼まれることが多いです。この3つは独立した項目ではなく、1本のストーリーとしてつながっています。
「③この前提のもとで、①こういうものをこう作るので、②だいたいこれくらいの工数です」——この筋が通れば説得力が出ます。
とくに③前提条件は「正確に出せない不安」の受け皿になります。数字を詰める代わりに、不確実な部分を前提として書き出しましょう。たとえば次のように一行ずつ記載します。
- 要件は標準的な業務範囲を想定
- 既存データはCSVで提供される前提
- データ移行は対象外
こうしておけば、前提が崩れたときに「だから見積もりも変わります」と堂々と言えます。
実例と例え話で理解する
【例え話】家のリフォーム見積もり
現地をざっと見た段階では「だいたい200〜300万円くらい」と幅で答えるのが概算です。図面や工事内容が固まって初めて正式金額を出します。概算で1円単位の正確さを求める人はいません。システムの概算見積も同じで、幅と前提つきの”あたり”で十分です。
【実例】社内の問い合わせ管理システム（概算）
実装イメージ：クラウド上に新規構築。認証は既存SSOを流用、社員マスタはCSV連携。
| 工程 | 工数（人月） | 金額（万円） |
|---|---|---|
| 要件定義 | 1.0 | 80 |
| 基本設計 | 2.0 | 150 |
| 詳細設計 | 2.0 | 140 |
| 製造（実装） | 3.0 | 195 |
| テスト | 3.0 | 210 |
| 移行・リリース | 1.0 | 75 |
| クラウド構築・初期設定 | — | 50 |
| リスクバッファ | — | 100 |
| 小計（税抜） | 12.0 | 1,000 |
金額・単価はサンプルです。大切なのは「前提（実装イメージ）→ 工数の積み上げ → バッファ」で筋が通ること。「±30%程度変動しうる概算です」と添えれば立派な概算見積になります。
【初めての人ほど効く一手】
完成品をいきなり見せて直されるより、骨子（前提条件・工程の区切り・想定規模）の段階で先輩や上司にレビューしてもらいましょう。「過去の似た案件はどれですか」と聞くだけでも類推の基準が手に入ります。
まとめ
- 概算見積に「数字のピタリ賞」は不要。求められるのは前提と根拠の明確さ。
- 不確実性コーンが示すとおり初期の精度には構造的な限界がある。精度でなくレンジ・バッファ・時間の区切りで扱う。
- 手法はまず類推法から。要件が固まったらボトムアップ法やFP法で精度を上げる。
- 構成は「①実装イメージ／②工数概算／③前提条件」の3ブロック。1本のストーリーでつなげば自信を持って出せる。
参考リソース
- システム開発の見積もり方法（株式会社インプル）：ボトムアップ法・FP法など各手法の特徴と見積書の内訳をサンプル付きで解説。
- システム開発の見積方法7選：類推法・FP法を含む複数手法をメリット・デメリットと見積例つきで比較。
- システム開発の見積もりの見方・手法（トッパジャパン）：トップダウン（類推）見積を中心に、見積書の項目や算出方法を整理。
- システム開発の見積書の内訳を解説（Sun*）：類似プロジェクト参照法など、見積書の内訳をサンプル付きで説明。
- 不確実性コーンとは（Promapedia）：不確実性コーンの由来と段階的詳細化の考え方を解説。
- 見積もりが当初より増える理由と不確実性コーンの活用（Zenn）：不確実性コーンや三点見積もり（PERT）を使った誤差マネジメントの実践的考察。
コメント