システム開発の見積もりを比較する｜7つの見積もり手法と、どこまで分かっているかで選ぶ基準

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

近年、システム開発を発注する部署から、この形の相談が増えています。候補の数が多すぎる、という話ではありません。同じ要件定義書（システムで実現する内容や条件をまとめた文書）を渡したのに、返ってきた数字が揃わない、という話です。

数字が揃わない原因は、たいてい1つに絞れます。3社が、それぞれ別の見積もり手法を使っているからです。どの手法で作られた数字なのかが分かれば、3つの数字は比べられる形になります。

作業を細かく割って人日（1人が1日働く量）を積み上げた会社。自社の過去の類似案件の実績値から当てた会社。機能の規模を国際規格の手順どおりに測ってから換算した会社。3社の数字は、そもそも同じ土俵に乗っていません。

ただ、発注側が本当に判断に困っているのは、金額の比較ではありません。その見積もりが、どこまで分かっている状態で作られたのかが、書面から読み取れないことです。

見積書に並ぶのは、合計金額と工程名だけです。「この数字は、要件が確定していない前提で置いた概算です」とは、たいてい書いてありません。だから、確度（見積もりが実態に近い度合い）のちがう3つの数字を、確度が同じものとして並べてしまいます。

本記事では、実務で使われている見積もり手法を7つの類型に分けます。同じ表に並べて、選び方の話をしていこうと思います。

なお、本記事はアルチェコ（ARCHECO）が運営する媒体です。7類型の最後の1つは運営会社も採用している進め方なので、その旨だけ先に添えておきます。

金額が割れているのではなく、数えているものが割れている

見積もりの精度は、手法の優劣で決まりません。見積もり手法が必要とする情報量と、手元にある情報量が揃っているかで決まります。

南カリフォルニア大学のBarry Boehm氏らがまとめた見積もりモデル「COCOMO II」（ソフトウェアの規模や開発条件から工数を算出するモデル）の COCOMO II Model Definition Manual に、はっきり書かれています。

見積もりモデルの粒度（情報の細かさ）は、見積もりを支える情報の粒度と揃っていなければならない。定義書の原文では「the granularity of the software cost estimation model used needs to be consistent with the granularity of the information available」と書かれています。

平たく言えば、ざっくりした情報しか無い段階で、細かく積み上げた数字を出しても、細かさは見せかけにしかならない、ということです。

同じ定義書には、初期段階の不確かさにも数字が置かれています。ごく初期には、開発するシステムの規模が4倍の幅でしかつかめない。原文は「one may not know the specific nature of the product to be developed to better than a factor of 4」です。構想の段階で1,000万円と置いた案件が、実際には4,000万円になることがある、という意味の幅です。

ただし、この幅は工程が進むにつれて縮みます。実際の工数が見積もりをどこまで上回りうるかについて、定義書の図を表にしておきます。

段階	大きい側へ振れる幅
構想（Concept of Operation）	4倍
要件定義（Requirements Spec.）	2倍
基本設計（Product Design Spec.）	1.5倍
詳細設計（Detail Design Spec.）	1.25倍

実際より大きく見積もる場合だけでなく、小さく見積もる場合にも、同じだけの幅が引かれています。構想段階なら実際の4分の1、要件定義でも半分という数字です。

この幅は、机上の話ではありません。表の元になっているのは、Boehm氏が1981年の著書で示した図です。定義書には、その図に米空軍の部門へ出された提案5件と、仕様が粗いまま作られたソフトウェア7件を重ねたものが載っています。合計12件と数は多くありませんが、実際のプロジェクトが図の幅の中に散らばっていることが示されています。

言い換えると、幅は見積もる人の腕前の話ではありません。腕がよくても、その時点で手元にある情報の量より狭くはできないということです。

つまり、要件が固まっていない段階で「正確な見積もりを出してください」と要求しても、正確な数字は返ってきません。返ってくるのは、幅を隠した1つの数字です。あるいは、幅を織り込んだ大きめの数字になります。

①積み上げ型｜作業を割って、人日を足す

いちばん広く使われている型です。WBS（作業分解構成図）——作るものを、担当者が着手できる作業の単位まで分解した一覧——で作業を細かく割ります。1つずつに人日を当てて、合計します。

工程ごとの小計が出るので、見積書の見た目はいちばん整います。強いのは、契約と検収（納品物が条件どおりかを発注側が確認する作業）に直結することです。 作業が1行ずつ並んでいるので、どの作業がいくらかが分かります。

追加要望が出たときも、「その画面は行が無いので追加になります」と指差せます。発注側にとっても、見積もりから項目を削る交渉がしやすい。

ただし、弱点もあります。作業を割った担当者が把握している内容しか、見積もり項目にできないことです。割る時点で把握していなかった作業は、見積書の項目になりません。

見えないものの代表が、失敗したときの後始末です。

まだ作っていない積算システムでは数えようがないので、すでに動いている別のシステムで数えます。オンラインで支払いを受け取るサービスの、サーバー側で動く処理のまとまり（関数）を数えた例です。44本のうち12本が、キャンセル・返金・記録の突き合わせ・障害からの復旧・残ったデータの掃除・失敗の記録でした。4本に1本以上が、機能ではなく後始末です。

内訳は、注文の取り消しが3本、返金が1本、記録の突き合わせと障害からの復旧が3本、使われないまま押さえられていた割引を戻す処理が1本、通知の再送が1本、失敗の記録が1本、決済サービスから届く通知の取り込みが2本です。

後始末は、機能一覧にも画面一覧にも載りません。後始末に名前が付くのは、後始末が必要な事態が実際に起きたあとだからです。しかも12本の名前は、機能の名前になっていません。「注文を作る」ではなく「注文の記録を突き合わせる」。「決済する」ではなく「決済サービスから届く通知を取り込む」。機能一覧の言葉づかいでは、そもそも拾えない名前です。積み上げ型は、この部分に構造的に弱い。

②機能規模型｜国際規格の手順で、機能の大きさを測る

作業ではなく、できあがるものの大きさを数える型です。代表が「ファンクションポイント法」になります。画面・帳票・データの種類を数え上げ、それぞれの複雑さに応じた点数を足す。作るものの大きさを点数で表す、という考え方です。

1979年に、IBMのAllan J. Albrecht氏が考案しました。1986年には、この手法を使う人たちの団体であるIFPUG（International Function Point Users Group）が設立され、標準化が進みます。IFPUGの公表によれば、この手法は2003年11月に「ISO/IEC 20926:2003」として国際規格になりました。機能の大きさをどう測るかの手順を、国際的に定めた規格です。

入力・出力・読み出し・書き込みという、データの移動の回数で測る「COSMIC法」も、「ISO/IEC 19761」として規格になっています。どちらも「機能規模測定」という同じ考え方の上にあります。

強いのは、発注者と受注者が同じ物差しを持てることです。 人日は会社ごとに中身がちがいます。しかし機能の規模は、手順書どおりに測れば同じ数になります。だから、相見積もり（複数社から見積もりを取ること）の比較にそのまま使えます。

画面の作り込みの度合いではなく、扱う情報の種類と数で大きさが決まります。

ただし、測るのに手間と技能が要ります。規格どおりに数えるには、要件がある程度まで書けている必要があります。構想段階では、そもそも数える対象がありません。

もう1つの弱点は、機能の数に現れない条件の扱いです。「同時に何人が使うか」。「応答が何秒までか」。「24時間止められないか」。この種の条件は「非機能要件」と呼ばれ、機能の数には現れませんが、工数には確実に効きます。

③パラメトリック型｜統計モデルに、条件を入れて計算する

作るものの大きさと開発の条件を入力すると、必要な工数が出てくる数式のモデルです。冒頭で引いた「COCOMO II」が代表格にあたります。

COCOMO IIは、段階に応じて2つのモデルを持っています。要件が粗い段階の「Early Design」。システムの全体構成（アーキテクチャ）が決まったあとの「Post-Architecture」。前者は少ない項目で概算します。後者は細かい条件を入れて精度を上げます。

つまり、手法そのものが、情報量に合わせて粒度を切り替える設計になっています。定義書の「粒度を揃える」という一文が、モデルの構造にそのまま入っています。

条件として入るのは、開発チームの経験、動かす環境の難しさ、求められる信頼性、再利用の度合いなどです。定義書はこれらを「cost driver」と呼び、「開発工数を増やしたり減らしたりする効果を持つ、ソフトウェア開発の特定の性質」と説明しています。

強いのは、前提を変えたときの感度（条件の変化が工数に与える影響）を出せることです。 たとえば「経験者が1人しかいない場合」と「経験者が3人いる場合」で、工数がどれだけ違うかを出せます。値切る交渉ではなく、条件を変える交渉ができます。

ただし、モデルの前提は古くなります。COCOMO IIの係数は、モデルを作った当時に集められたプロジェクト群から求められたものです。生成AI（指示に応じて文章やプログラムなどを作るAI）を使った開発の生産性は、この係数に入っていません。

もう1つ、入力に規模が要る点も弱点です。規模が分からないから見積もりたいのに、規模を入れないと動きません。

④合議型｜複数人の見積もりを、その場でぶつける

人を集めて、同じ対象を各自が独立に見積もる型です。そのうえで数字を出し合います。「ワイドバンド・デルファイ法」と「プランニングポーカー」が代表になります。

ワイドバンド・デルファイ法は、Boehm氏が1970年代に提唱した進め方です。もとは、ランド研究所が考案した「デルファイ法」——専門家に匿名で回答を出させ、それを何度か繰り返して意見を寄せていく方法——にさかのぼります。そこに全員で話し合う場を足したものです。

プランニングポーカーは、見積もりを書いたカードを全員が一斉に出す方法です。2002年に、アジャイル開発（短い周期で設計・実装・改善を繰り返す開発手法）の実務者であるJames Grenning氏が定義して名付け、2005年にMike Cohn氏の著書「Agile Estimating and Planning」で広く知られるようになります。

Grenning氏がこの方法で解こうとしたのは、合意している人たちが話しすぎて、場を支配してしまう、という問題でした。原文では「people in agreement talking too much and dominating the effort」と書かれています。数字を先に出させることで、その偏りを外す狙いです。

強いのは、認識のズレがその場で表に出ることです。 カードに書くのは、ほかの機能と比べて何倍の重さかを表す数字です。同じ機能に「3」と「13」が並んだら、2人は別のものを想像しています。数字を合わせる前に、何がちがうのかを話すことになります。

営業出身者と開発者では、同じ機能でも思い浮かべる中身が違います。片方は画面の見た目を、片方は例外時の保存を想像している。そのズレが見えるのは、数字を出したあとです。

ただし、見積もりに参加した人が知らない条件は、やはり見積もりに出てきません。全員が同じ経験しか持っていない場合、全員が同じ誤った前提で見積もります。

もう1つ、金額に換算しづらいという弱点もあります。出てくるのは相対的な重さの数字で、円でも人日でもありません。そのままでは契約書の金額になりません。

⑤ベンチマーク型｜外部の実績分布と、突き合わせる

手元の数字を、外部の実績データと照合する型です。日本では、国の独立行政法人であるIPA（情報処理推進機構）が公開しているソフトウェア開発分析データ集が代表的な参照先になります。

2022年版について、IPAはこう書いています。「これまでに収集したデータ数は分析データ集2020で5,000件を超え、今回の分析データ集2022では5,546件になりました」。工数・工期・規模・生産性・信頼性といった項目が、業種ごとに整理されています。公開時点から直近6年間にあたる1,479件を使って、分析結果が算出されています。

自社の過去案件と照らす「類推見積もり」も、この型に含まれます。照合先が外部の公開データか社内の実績かがちがうだけで、「似た案件の実績と突き合わせる」という骨格は同じです。

強いのは、桁が外れていないかの検算に使えることです。 積み上げた数字が、同じ規模・同じ業種の分布のどこに位置するのかが分かります。分布の外に出ていたら、前提のどこかに無理があります。

自社の案件の工数が妥当かどうかを、感覚ではなく分布で確かめられます。役員会に出す資料として、公開データを根拠にできるのも強い。

ただし、平均は自分の案件ではありません。 分布のどこに来るかは、分布そのものからは分かりません。「うちの案件は平均より難しい」という主張の裏取りには、別の材料が要ります。

もう1つ、新しい作り方が反映されるまでに時間がかかる点も弱点です。集めて分析して公開するまでの間に、現場の作り方は変わります。

⑥確率型｜1つの数字ではなく、確率つきの幅で答える

「いつ終わるか」に1点で答えるのをやめる型です。「いつまでに終わる確率が何%か」で答えます。 代表が2つあります。3つの日数から期待値を出す「三点見積り」と、過去の見積もりのズレ方から完成日の確率を出す「Evidence-Based Scheduling（証拠にもとづく日程計画）」です。

三点見積りは、いちばんありそうな日数（最頻値）、うまくいったときの日数（楽観値）、こじれたときの日数（悲観値）の3つを置きます。そこから、最頻値に重みを置いて3つをならす式で期待値を出します。この式は、1950年代に、大規模な開発の日程を管理するために作られた手法から来ています。PERT（Program Evaluation and Review Technique）と呼ばれるものです。1つの数字を出す前に、幅を先に言葉にする進め方だと言えます。

Evidence-Based Schedulingは、2007年10月26日にソフトウェア開発者のJoel Spolsky氏が発表しました。各開発者が過去に出した見積もりと、実際にかかった時間の比を蓄えます。この比を「velocity」と呼びます。1.0なら見積もりどおり、0.5なら見積もりの倍かかった、という読み方です。蓄えた比からランダムに引いて何度も試行する、モンテカルロ法と呼ばれるやり方で完成日を散らします。

出力は日付ではなく、確率の曲線です。試行を100回まわして、100通りの完成日を作る。そのひとつひとつが1%ぶんの重みを持つので、任意の日付までに出荷できる確率のグラフになります。

Evidence-Based Schedulingの前提として、タスクは細かく割ることが求められます。1つのタスクが16時間を超えないこと、という基準が置かれています。原文は「Nothing longer than 16 hours」。働く時間にすると2日ぶんで、それより大きい塊は割ってから見積もる、ということです。

強いのは、幅を隠さずに渡せることです。 冒頭で見たCOCOMO IIの4倍の幅は、消せません。消せないものを、消したふりをせずに扱えるのがこの型です。

報告の形が変わります。「4月末までに動く確率は60%」。「6月末までなら90%」。役員会で問われるのは、たいてい「間に合いますか」です。確率で答えておけば、遅れたときに「そんな話は聞いていない」とはなりません。

ただし、過去の実績が無いと成立しません。初めて組むチームや、初めての領域では、引いてくる見積もりと実績の比がありません。

もう1つ、社内文化との相性もあります。「90%の確率で6月末」という報告が、そのまま受け取られる組織ばかりではありません。

⑦作って測る型｜先に一部を作り、実測を見積もりに戻す

7つ目は、本メディアの運営会社（ARCHECO）も採用している進め方です。特定の会社の専売ではなく、生成AIで試作が速くなったことで実務に入ってきた型です。

見積もりの精度を上げるのではありません。見積もる前に、情報量のほうを増やす型です。生成AIを使って動くものを短期間で作ります。そこで実際にかかった工数を、見積もりの入力に戻します。

順番が入れ替わります。従来は、要件を固め、見積もり、契約し、作る。この型では、いちばん工数を見積もりにくい部分を先に小さく作ります。実測してから、残りを見積もります。

冒頭で引いたCOCOMO IIの定義書の言い方を借りると、次のようになります。モデルの粒度に情報を合わせるのではなく、情報の粒度をこちらから引き上げる進め方です。

使い方はこうです。最初の数週間で、いちばん工数の読めない1か所だけを作る。その実測が取れれば、残りは積み上げ型で十分に数えられます。工数を見積もれない部分だけを実測に置き換える、という使い分けです。

強いのは、要件が固まっていない段階から入れることです。 上の6つは、いずれも数える対象が言葉になっていることを前提にしています。言葉になっていない段階では、数える手法は動きません。

ただし、契約の形が普通ではありません。「作ってから見積もる」という順番は、金額を先に決めて一括で請け負う契約の稟議（社内で承認を得る手続き）と噛み合いません。この型を選ぶなら、契約の作り方から相談する必要があります。

もう1つ、規模の大きい案件には向きません。会社全体の基幹システム（会社の主要業務を支えるシステム）を入れ替えるような、対象が巨大で、似た前例も数多くある領域では、一部を先に作って測る意味が薄くなります。そこはパラメトリック型とベンチマーク型のほうが確実です。

考え方の詳細はAIプロダクト開発のページに整理しています。

7類型を、同じ表に並べる

優劣ではなく、目的で選ぶための表です。 各類型に◎を1つずつ置いてあります。

類型	代表的な手法・出典	数えるもの	強い軸（◎）	効く段階	向いている発注
①積み上げ型	WBSによる人日積算	作業	◎ 契約と検収に直結する	要件確定後	仕様が固まり、検収条件を明確にしたい。
②機能規模型	ファンクションポイント法（ISO/IEC 20926）／COSMIC法（ISO/IEC 19761）	機能の規模	◎ 社をまたいで同じ物差しになる	基本設計前後	相見積もりを同じ土俵で比べたい。
③パラメトリック型	COCOMO II（南カリフォルニア大学）	規模と条件	◎ 前提を変えたときの感度が出る	概算〜基本設計	体制や品質水準の条件を交渉したい。
④合議型	ワイドバンド・デルファイ／プランニングポーカー	相対的な大きさ	◎ 認識のズレがその場で出る	反復開発（設計・実装・改善を短い単位で繰り返す開発）の各回	社内の認識を揃えながら進めたい。
⑤ベンチマーク型	IPA ソフトウェア開発分析データ集／類推見積もり	実績の分布	◎ 桁の間違いを検算できる	予算化の直前	公開データを根拠に上申（上位の決裁者へ判断を求めること）したい。
⑥確率型	三点見積り（PERT）／Evidence-Based Scheduling	確率つきの幅	◎ 納期を確率で答えられる	実装中の再予測	幅を隠さずに進捗を報告したい。
⑦作って測る型	生成AIで先に一部を作る	実測値	◎ 要件未確定でも着手できる	構想〜試作	何を作るかがまだ決まっていない。

作って測る型が要るのは、言葉になっていない部分が残っている場合だけです。 要件が言葉になっている案件は、上の6つだけで判断できます。作って測る型が要るのは、言葉になっていない部分が残っている場合だけです。

表は、上へ行くほど「よく分かっている段階」に効く手法が並んでいます。いちばん上の積み上げ型は、要件が固まりきってから効く。いちばん下の作って測る型は、まだ何も固まっていない段階に効きます。

見積書を受け取ったら、最初に確かめる4つの質問

比較表を持っていても、目の前の見積書がどの類型で作られたのかは書いてありません。判別するための質問を4つ置きます。どれも、電話1本で聞ける長さにしてあります。

質問	返ってくる答えで分かること	関係する類型
「この数字は、どの段階の情報で作りましたか」	4倍・2倍・1.5倍のどこにいるか。	7類型に共通する前提
「うまくいかなかった場合の処理は、どの行に入っていますか」	後始末が行として立っているか。	積み上げ型
「規模は、何で測りましたか」	機能規模で測ったのか、人日の勘なのか。	機能規模型
「この納期は、何%の確率で守れる想定ですか」	幅を持っているか、1点で答えているか。	確率型

2つ目の質問で、特に差が出ます。見積書の行を指差して答える会社があります。一方で、「そのあたりは工数に含んでいます」と答える会社もあります。

もっとも、行が無いことが即座に手抜きを意味するわけではありません。要件の粒度が粗ければ、行は立てられません。確かめたいのは金額の高低ではなく、その見積もりの土台となる情報量です。

「この納期は、何%の確率で守れる想定ですか」という4つ目の質問は、答えにくいものです。多くの現場では、納期は1点で答えるものとして扱われています。「確率で答えてよい」と発注側から言われた時点で、返ってくる情報の質が変わります。

立場によって、見るべき類型は変わります

同じ会社の中でも、見積書に求めるものは立場ごとにちがいます。役割別に、最初に見る類型を分けておきます。

立場	抱えている課題	最初に見る類型
発注担当者 — 相見積もりを比較する	3社の数字が揃わず、比較の根拠が作れない	機能規模型で物差しを揃え、積み上げ型で行を確認する。
予算の責任者 — 稟議と上申を通す	「その金額の根拠は何ですか」に公開データで答えたい	ベンチマーク型で分布と照合し、パラメトリック型で条件を交渉する。
事業の企画担当 — 作るものがまだ粗い	要件が書けないので、見積もりを頼めない	作って測る型で、読めない部分を先に実測する。
開発の進行管理 — 途中の遅れを報告する	「間に合いますか」に毎回1点で答えさせられる	確率型で確率に直し、合議型で各回の認識を揃える。