ボトムアップ見積もりは、作業をWBSで細かく分け、要素ごとの工数やコストを見積もって足し上げる方法です。「積み上げ法」「工数積上げ」とも呼ばれます。要件が固まった段階では根拠を説明しやすい一方、分解から漏れた作業はそのまま見積りからも抜けます。本記事では、類推見積り・パラメトリック見積り・三点見積り・専門家判断との違いを、IPA・NASA・Boehmの一次資料と計算例で整理します。なお、ここで扱うのはシステム開発の工数やコストを見積もる手法です。現場の提案を経営判断に上げる「ボトムアップ型」の組織運営とは別の話です。
まとめ：ボトムアップ見積もりと主要な見積り手法の違い
IPA/SECが挙げる見積り手法6分類のうち、不適切とされるプライスツーウィンを除く5つと、幅を出すために組み合わせる三点見積りを1表にまとめました。
| 手法 | 何から算出するか | 主に使う段階 | 主な弱点 |
|---|---|---|---|
| ボトムアップ見積もり | WBSの作業ごとの見積りを合計 | 要求仕様の確定後 | 計上漏れ・二重計上、作業量が多い |
| トップダウン見積り | 全体の特性から総額を出し配分 | 全体の規模しか分からない段階 | 根拠が粗い |
| 類推見積り | 似た過去案件の実績を差分補正 | 構想・企画 | 補正が判断頼み |
| パラメトリック見積り | 規模と工数の関係式（COCOMO等） | 規模を数えられる段階 | 自社実績での較正が必要 |
| 専門家判断 | 1人または複数の専門家の協議 | 実績データが無いとき | 参加者の経験に依存 |
| 三点見積り | 楽観値・最頻値・悲観値 | 他の手法と併用 | 合計時に分散でなく標準偏差を足しがち |
どれか1つが常に優れているわけではありません。Boehmの1984年の論文は、手法を組み合わせ、結果を比べ、食い違う箇所を詰め直すよう勧めています。三点見積りで複数の作業を合計するときは、作業同士が独立なら標準偏差ではなく分散を足します。段階ごとの使い分けは後半の章で扱います。
ボトムアップ見積もりの定義と積み上げの手順
IPA・Boehm・NASAが示す積み上げ法の定義
IPA/SECのエンタプライズ系事業/見積もり手法は、ボトムアップ見積り（工数積上げ）を「プロジェクトの成果物の構成要素を洗い出し、それぞれに必要な工数などを見積って積み上げる方法」と定義しています。Boehmの論文「Software Engineering Economics」（IEEE TSE、1984年。1981年の同名書籍とは別）も、ソフトウェア作業の構成要素を個別に見積もり、その結果を集計して全体の見積りにする方法として説明しています。
NASAのCost Estimating Handbook v4.0 付録Cは、同じ方法をEngineering Build-Up（grassroots）と呼びます。WBSの全作業を見積もって合計したうえで、適切な間接費を加えると書いている点が、他の2資料にない特徴です。
情報処理技術者試験では、基本情報技術者 令和元年度秋期 午前 問53の誤答選択肢エ「単位作業項目に適用する作業量の基準値を決めておき、作業項目を単位作業項目まで分解し、基準値を適用して算出した作業量の積算で全体の作業量を見積もる方法」が、積み上げ型の説明にあたります。
WBSから人日を積み上げる設例と漏れやすい作業
社内向けの申請ワークフロー（6画面・8テーブル）を想定した設例です。数値は手順を示すための仮置きで、実績値ではありません。
| 作業パッケージ | 見積り根拠 | 人日 |
|---|---|---|
| 要件定義 | 打合せ4回＋要件定義書 | 5 |
| 画面設計 | 6画面×0.5人日 | 3 |
| DB設計 | 8テーブル×0.5人日 | 4 |
| 画面実装 | 6画面×2人日 | 12 |
| API実装 | 10本×0.8人日 | 8 |
| 単体テスト | 実装20人日×0.3 | 6 |
| 結合・総合テスト | シナリオ25本 | 5 |
| 移行・リリース | 本番切替1回 | 2 |
| プロジェクト管理 | 週次会議・進捗報告 | 4 |
| 合計 | － | 49 |
手順は、(1)WBSで成果物と作業を洗い出す、(2)必要な資源と完了条件を具体的に見積もれる大きさまで分ける、(3)作業ごとに根拠つきで見積もる、(4)全体にかかる作業を足して合計する、の4段です。人日から人月への換算は、1人月＝20人日（160時間）とする場合で49÷20＝約2.5人月になります。
合計行の上の3行（結合・総合テスト、移行・リリース、プロジェクト管理）は、個々の画面や機能に属さない作業です。これを落とすと合計は38人日となり、11人日（約22%）少なく出ます。Boehmの論文はボトムアップの短所にMay overlook system-level costs（システム全体にかかるコストを見落としうる）を挙げています。管理工数を何%見込むかは管理工数の比率を検証した記事を参照してください。
NASAとBoehmの評価に見るメリット・デメリット
NASAの付録C（Table C-1）とBoehmの論文（Table I）を突き合わせると、ボトムアップの長所と短所は次のとおりです。
| 観点 | NASA付録C Table C-1 | Boehm 1984 Table I |
|---|---|---|
| 長所 | 要素ごとの根拠が見える | 根拠が詳細で安定 |
| 長所 | 1要素の誤りが全体を壊さない | 担当者のコミットを促す |
| 短所 | 計上漏れ・二重計上が起きやすい | システム全体のコストを見落とす |
| 短所 | 作成に時間と費用がかかる | 手間がかかる |
| 短所 | 統計的な信頼水準を示せない | － |
| 短所 | What-if（条件変更の試算）に弱い | － |
実務で効くのは「統計的な信頼水準を示せない」という短所です。積み上げた49人日は1つの点であって、何%の確率で収まるかは語りません。幅が必要なら、後述の三点見積りを作業パッケージごとに重ねます。一方でBoehmが長所に挙げるFosters individual commitment（担当者のコミットを促す）は、進捗管理で効きます。作業ごとの担当者が自分で出した人日は、そのまま進捗を測る基準線になります。
トップダウン見積りとボトムアップ見積もりの違い
Boehmの定義では、トップダウン見積りはソフトウェア製品全体の特性から総コストを導き、それを構成要素へ割り振る方法です。ボトムアップとは計算の向きが逆で、総額が先に決まります。IPA/SECのページもトップダウン見積りを6分類の1つに挙げ、「全体システムを見積り可能なサイズのソフトウェアコンポーネントに細分化」と説明しています。この説明は分割の側面だけを書いたもので、総額を先に出す点はBoehmの定義で補って読みます。
| 比較軸 | トップダウン | ボトムアップ |
|---|---|---|
| 計算の向き | 総額→構成要素へ配分 | 構成要素→総額へ合計 |
| 必要な情報 | 全体の規模・特性 | 作業レベルの分解 |
| 長所（Boehm） | 全体視点・効率的 | 詳細な根拠・安定 |
| 短所（Boehm） | 根拠が粗い・不安定 | 全体コストの見落とし・手間 |
Boehmはトップダウンとボトムアップを、長所と短所が互いに補い合う組み合わせとして挙げています。トップダウンで出した総額とボトムアップの合計を並べ、差が大きい箇所を点検すれば、ボトムアップ側の計上漏れを見つけやすくなります。
類推見積り（類推法）の仕組みと補正の注意点
類推見積りの手順と補正の難しさ
類推見積りは、IPA/SECの定義で「過去の類似プロジェクトの実績を基礎に見積る方法」です。基本情報技術者 令和元年度秋期 午前 問53の選択肢イは、手順まで具体的に書いています。類似ソフトウェアとの相違点を調べ、同じ部分には過去のデータを使い、異なる部分は経験で見積もるという流れです。
NASAの付録Cは、類推の長所を「実績データに基づく」「速い」「理解されやすい」とし、用途に設計の初期段階や桁感をつかむ概算（rough order-of-magnitude）、他手法との照合を挙げます。短所として挙がる4点を、補正に関わる2点をまとめて整理すると次の3点です。
- 実績が1件しかないことがある
- 適切な比較対象を見つけにくい
- 規模や条件の差をそろえる正規化（normalization）が要り、その補正係数は外挿や専門家の判断に頼る
最も効くのは3点目です。前回の案件が120人日だったとしても、画面数が1.5倍なら単純に180人日とはなりません。担当チームの経験、非機能要件、既存システムとの連携が違えば、補正は結局「判断」になります。NASAの付録Cも、見積りの妥当性を損なう主観的な補正は避け、補正の根拠を十分に文書化するよう求めています。その判断を誰がどんな根拠で下したかを見積り書に残してください。専門家の判断だけに頼る見積りは「KKD（勘・経験・度胸）」と呼ばれることがあり、その限界と使いどころはKKDとは？勘・経験・度胸の意味、KKD法・KKD経営のデメリットと反対語で扱っています。
類推見積りとパラメトリック見積りの使い分け
どちらも過去の実績を使いますが、使い方が違います。類推は似た案件の実績を1件か数件まるごと参照し、差分を補正します。パラメトリックは複数案件の実績から「規模が増えると工数がどれだけ増えるか」という関係式を作り、新しい案件の規模を当てはめます。
- 同じ種類・同じ規模の案件の実績が手元にある → 類推。関係式を作るより、その実績のほうが条件を多く含んでいます。
- 自社の実績から作って誤差を確かめた関係式があり、新しい案件の規模がその実績の範囲に収まる → パラメトリック。規模の差を式で吸収できます。
- どちらの実績も無い → 専門家判断で出し、後の段階で他の手法と照合します。
パラメトリックにも限界があります。後述のCoBRA法の原論文（Briandら、ISERN-97-24）は、作った生産性モデルをonly be used for interpolation purposes（内挿の目的にだけ使う）とし、元データの範囲外には当てはめないよう求めています。過去の最大案件が30人月なら、300人月の案件に同じ式を延長するのは類推の補正と同じくらい不確かです。
パラメトリック見積りの計算式とCOCOMOの計算例
パラメトリック見積りの定義と試験での出題
IPA/SECはパラメトリック法を「工数などを目的変数として、説明変数に規模や要因などを設定し、数学的な関数として表す方法」と定義し、ベースとなる考え方を「規模と工数は比例する」と書いています。パラメトリック見積りは1つの決まった計算法ではなく、この考え方に立つ手法群の総称です。COCOMO、後述のCoBRA法、規模をコード行数で数えるLOC法などがここに入ります。
最も単純な形は「工数＝係数×規模」です。過去の案件で画面1枚あたり平均3.2人日かかっていたなら、20画面の案件は3.2×20＝64人日と出します（数値は説明用の仮置き）。COCOMOのようなモデルは、この係数に開発条件による補正を掛け、規模に指数を付けて「規模が2倍なら工数は2倍以上」という性質まで表せるようにしたものです。
応用情報技術者 平成30年度春期 午前 問52は、PMBOKガイド第5版に基づいてパラメトリック見積りの説明を選ばせる問題で、正答はイ「関連する過去のデータとその他の変数との統計的関係を用いて、プロジェクトにおける作業のコストを見積もる」です。
この問題の誤答選択肢は、そのまま他の手法の定義になっています。アの「WBSの下位レベルの構成要素単位の見積り結果を集計」はボトムアップ見積り、ウの「楽観値、悲観値、最可能値を使って」は三点見積り、エの「類似のプロジェクトにおける過去のコスト実績を使って」は類推見積りです。4手法の違いを1問で確認できます。前章の設例にある「6画面×2人日」も単価×数量の形で、ボトムアップの内側でもパラメトリックの考え方が使われています。
COCOMOの名目工数式と10KDSIの計算例
COCOMOはBoehmが1981年に発表したパラメトリックモデルで、1997年に第2版のCOCOMO IIが出ています。Boehmの1984年論文のTable Vは、中間COCOMO（Intermediate COCOMO）の名目工数式を開発形態（モード）ごとに載せています。コストドライバーを使わない基本COCOMOとは係数が異なるため、資料間で数字が合わないときはどちらの式かを確かめてください。KDSIは納品されるソース命令数（千行）、MMは人月、TDEVは開発期間（月）です。
| モード | 名目工数 | 開発期間 |
|---|---|---|
| 組織型（Organic） | MM＝3.2×KDSI^1.05 | TDEV＝2.5×MM^0.38 |
| 半組込み型（Semidetached） | MM＝3.0×KDSI^1.12 | TDEV＝2.5×MM^0.35 |
| 組込み型（Embedded） | MM＝2.8×KDSI^1.20 | TDEV＝2.5×MM^0.32 |
論文の計算例は、高い信頼性が求められる電子資金移動ネットワーク向けの通信処理ソフトウェア（組込み型、10KDSI）です。名目工数は2.8×10^1.20≒44.38人月で、以下は論文に合わせて44人月に丸めて計算します。15個のコストドライバー（信頼性要求、複雑さ、チームの経験など）の乗数を掛け合わせた1.35を掛けて59人月、開発期間は2.5×59^0.32＝約9か月となります。
指数が1より大きいため、規模が2倍になると工数は2倍より多く増えます。この性質を実績から推定したことが、類推やボトムアップにはない強みです。ただし係数はBoehmが分析した63プロジェクトのデータから出たもので、IPAが公開する石谷靖氏（三菱総合研究所）の講演資料（2012年）も、ある環境で作ったモデルはそのままでは精度が出ず、キャリブレーション（較正）が必要だと整理しています。Boehm自身も、データの定義がそろわない現状ではモデルの精度はwithin 20 percent of the actuals, 70 percent of the time（実績の±20%以内に70%の確率で収まる）程度にとどまると書いています。
ファンクションポイント法・プログラムステップ法とCOCOMOの関係
COCOMOとファンクションポイント法（FP法）は、比べる対象の段が違います。FP法は規模を測る方法で、基本情報技術者 令和元年度秋期 午前 問53の正答ウ「ソフトウェアの機能を入出力データ数やファイル数などによって定量的に計測し、複雑さによる調整を行って、ソフトウェア規模を見積もる方法」がその定義です。COCOMOは規模から工数と期間を出すモデルで、同じ問題の選択肢ア「開発規模が分かっていることを前提として、工数と工期を見積もる方法」がCOCOMOにあたる説明です（問題文に名称は出ません）。
プログラムステップ法（LOC法）は、ソースコードの行数（ステップ数）で規模を測る方法です。COCOMOが入力に使うKDSIもこの系統に属します。Boehmは、DSIには初期の規模見積りに使うには粒度が細かすぎるという弱点があると認めつつ、複雑度メトリクスもDSIを上回る予測力は示せていないと書いています。コードを書く前は行数を推測するしかないため、初期段階では画面・帳票・ファイルの数から数えられるFPのほうが根拠を示しやすくなります。FP法の計算手順と重み表はファンクションポイント法（FP法）とは｜計算方法と重み表・見積もりへの換算を実例で解説で詳しく扱っています。
CoBRA法：専門家の判断と少ない実績を組み合わせるモデル
CoBRA法は、ドイツのフラウンホーファー協会IESEのBriandらが開発した見積りモデルで、IPA/SECが国内で普及を担ってきました。原論文（ISERN-97-24）の出発点は、パラメトリックモデルが実務で使われていないという調査結果です。Heemstraの1992年の調査では、見積りを行うオランダ企業364社のうちモデルを使うのは14%未満でした。論文はほかの調査も引き、最も多く使われる方法は「個人の記憶にもとづく類似案件との比較」だったと書いています。実績データを集めていない組織が多いことが、その理由に挙げられています。
そこでCoBRA法は、経験豊富なプロジェクトマネージャーに「理想的な条件の案件と比べて何%余計にかかるか」（コスト超過、CO）を工数の変動要因ごとに評価してもらい、その値と生産性の関係を少数の実績から求めます。関係は直線で表すため、実績は10件程度で足りるとしています。COCOMOとの違いは規模の扱いです。COCOMOは規模が大きいほど工数が割高になる指数を持ちますが、CoBRAの原論文は工数と規模の関係を線形と仮定しています。
IPAは2010年3月からCoBRA法に基づく見積り支援ツールを公開してきましたが、同ページは2026年10月22日の更新で、システムの安全性確保の対応のため公開を一時停止したと告知しています。同ページの説明では、モデルは最低3件の実績で作れ（推奨は10件）、構築には経験豊かな複数のプロジェクトマネージャーの協力が要ります。実績もベテランの協力もそろわない組織では、CoBRAより類推と専門家判断の組み合わせが現実的です。
三点見積りの計算式と合計時の落とし穴
三点見積りにおける平均・分散・標準偏差の計算式
基本情報技術者 平成21年度春期 午後 問6は、3点見積法を「最頻値、悲観値（悲観的に最も長い期間を見積もる）、及び楽観値（楽観的に最も短い期間を見積もる）の3種の値を用いて推定する方法」と説明し、次の計算式を示しています。元になったのは、米海軍特別計画局とBooz, Allen and Hamiltonの研究者が1959年に発表したPERT（Malcolmら、Operations Research 7巻5号）です。
- 平均＝（悲観値＋4×最頻値＋楽観値）÷6
- 分散＝｛（悲観値－楽観値）÷6｝の2乗
- 標準偏差＝√分散
- 開発全体（各作業日数の合計）の標準偏差＝√（分散の合計）。作業同士が独立で、直列に行う場合の式です
最頻値に4倍の重みを置くのは、PERTが作業日数をベータ分布で近似し、その平均をこの簡便な式で求めることにしたためです。ベータ分布を仮定しただけで重み4が決まるわけではありません。悲観側に長く伸びた見積りでは、平均が最頻値より後ろにずれます。
標準偏差を足すと幅を過大に見積もる理由
同じ試験問題の数値で確かめます。
| 作業 | 悲観値 | 最頻値 | 楽観値 | 平均 | 分散 | 標準偏差 |
|---|---|---|---|---|---|---|
| M3の新規開発 | 20 | 12 | 8 | 12.7 | 4 | 2 |
| M2の改造 | 16 | 12 | 10 | 12.3 | 1 | 1 |
| 開発全体 | － | － | － | 25 | 5 | 2.2 |
開発全体の標準偏差は√5≈2.2日です。標準偏差をそのまま足すと2＋1＝3日になり、幅を過大に見積もります。悲観値同士を足した36日は、2つの作業がそろって悲観条件になった場合の合計です。作業が独立なら両方が同時に悲観値まで延びる確率は低く、36日を予算にすると幅を大きく取りすぎます。逆に同じ原因でそろって遅れる作業なら、36日は現実的な想定になります。試験は「作業日数がμ±2σの範囲に収まる確率は0.95」という前提を置き、平均25日±2σ（約20.5〜29.5日）の上端を、確率0.95で完了する最長作業日数としています（解答はσを2.2に丸めて2σ＝4.4日）。合計日数を正規分布で近似して片側で見ると、約29.5日までに終わる確率は約97.7%で、95%の確率で終わる日数は平均＋1.645σの約28.7日です。
注意点が1つあります。分散を足してよいのは、作業同士が独立している場合です。同じチームが担当する作業や、同じ仕様変更の影響を受ける作業は同時に遅れやすく、正の相関があると分散の単純合計は全体の幅を小さく見積もります。三点見積りの合計を納期の約束に使うなら、同じ原因で遅れやすい作業を1つのパッケージにまとめてから三点を付け、残る作業間の相関や依存関係も確かめてください。
見積り段階に応じた手法の使い分けと避けるべき見積り方
構想・要件定義・設計の各段階で選ぶ手法
Boehmの論文は、構想を比較している段階の見積りは実際のコストに対して上下4倍の幅があり、実現可能性の検討を終えると2倍、ソフトウェア要求仕様書ができると1.5倍まで縮むと述べています。ただし脚注で、この幅は主観的に定めた「80%の信頼限界」だと断っています。精度を保証する数字ではなく、段階ごとに情報の確定度が違うことを示す目安です。見積りの外れがどのように損益へ波及するかは工数見積りの精度低下がプロジェクト全体の損益に直結する構造的背景で扱っています。
| 段階 | Boehmの幅 | 主に使う手法 | 照合に使う手法 |
|---|---|---|---|
| 構想・企画 | 4倍〜1/4倍 | 類推 | パラメトリック |
| 実現可能性の検討後 | 2倍〜1/2倍 | FPで規模測定＋パラメトリック | 類推 |
| 要求仕様書の完成後 | 1.5倍〜1/1.5倍 | ボトムアップ | パラメトリック |
手法の割り当ては、NASAの付録Cが類推の用途を設計の初期段階、Engineering Build-Upの用途を成熟したプロジェクトや交渉としている整理に沿っています（同付録の本文は、Build-Upを最終設計・製作のPhase C以降に最も多く使うとしています）。中段のパラメトリックは、規模をFPで数えられる段階だという本記事の判断です。要件が固まる前にボトムアップを使うと、分解できない部分を担当者の勘で埋めることになり、細かい表の見た目だけが精度を装います。この段階ではボトムアップを主手法に採りません。見積りの根拠の書き方や妥当性の精査手順は工数見積もりの指針｜手法の選び方と根拠の作り方・妥当性の精査手順にまとめています。発注側で、要件の段階に合った見積りを依頼し、受け取った見積りの前提を点検する体制が無い場合は、要件定義・RFP作成・PMO支援のような外部の支援を使う方法もあります。
専門家判断（デルファイ法・プランニングポーカー）の位置づけ
IPA/SECの6分類には「専門家による判断」があり、「一人ないし複数専門家による協議」と説明されています。新しい技術を使う案件のように、類推に使える実績もパラメトリックの係数も無いときに残る手段です。ただしCoBRA法の原論文は、経験にもとづく見積りの精度とばらつきは見積もる人の経験に大きく左右されると先行研究を引いて指摘しています。1人の判断に頼ると、その人の経験の偏りがそのまま見積りに入ります。
そこで複数人の判断を手順で束ねる方法が使われます。匿名の回答と集計を繰り返して収束させるデルファイ法と、アジャイル開発でチーム全員がカードを同時に出してストーリーポイントを決めるプランニングポーカーによるストーリーポイント見積もりが代表例です。ストーリーポイントは基準の作業と比べた相対的な大きさで、人日ではありません。人日に換算して契約金額に使う場合は、チームの過去の実績（何ポイントを何日でこなしたか）を別に示す必要があります。
プライスツーウィンとパーキンソン型の見積り
IPA/SECの6分類には、顧客予算に合わせるプライスツーウィンも入っていますが、「不適切な見積り方法」と明記されています。Boehmの論文も、受注に必要と思われる価格を見積りとするプライスツーウィンと、使える資源に見積りを合わせるパーキンソン型の2つを、満足な見積りを生まない受け入れがたい方法と結論づけています。Table Iでもプライスツーウィンの短所は「一般に大きな超過を生む」です。
形の上ではボトムアップでも、先に総額が決まっていて、それに合うよう各作業の人日を削った見積りは実質的にプライスツーウィンです。見分けるには、作業ごとの根拠欄が「予算配分」になっていないかを確認します。予算の制約があるなら、見積りを削るのではなくスコープを削る交渉に回してください。
よくある質問
ボトムアップ見積もりとWBSの違いは何ですか？
WBSは成果物と作業を階層的に分解した構造そのもので、ボトムアップ見積もりはその末端の作業に工数やコストを付けて合計する見積り方法です。WBSは見積りの入力であり、スケジュールや担当割り当てにも使われます。NASAの付録Cも、Engineering Build-UpをWBSの全作業を見積もって合計する方法として定義しています。WBSの粒度が粗いと、ボトムアップの根拠もそのまま粗くなります。
積み上げ法・工数積上げ・ボトムアップ見積もりは同じ意味ですか？
同じ方法を指します。IPA/SECは「ボトムアップ見積り（工数積上げ）」と併記し、NASAはEngineering Build-Up、grassroots、bottom-upを同じ方法の呼び名として挙げています。社内文書では「ボトムアップ」だけだと意思決定の進め方と混同されやすいので、「ボトムアップ見積り」と見積りまで書くと誤解を防げます。
COCOMOとファンクションポイント法の違いは何ですか？
ファンクションポイント法は機能の数と複雑さからソフトウェアの規模を測る方法で、COCOMOは規模を入力に工数と開発期間を算出するモデルです。役割が違うため、両者は競合せず組み合わせて使えます。IPAが公開する石谷靖氏（三菱総合研究所）の講演資料（2012年）は、FPとCOCOMOをつなぐ商用ツールとして1986年のBYL（Before You Leap）を挙げています。なお、1981年のCOCOMOは入力にソース命令数（KDSI）を使います。
三点見積りの楽観値と悲観値はどう決めればよいですか？
IPAの試験問題は、悲観値を「悲観的に最も長い期間」、楽観値を「楽観的に最も短い期間」と定義しています。似た作業の過去実績の最短・最長を出発点に、今回の条件差と未経験のリスクを加味して楽観値・悲観値を設定します。実績が無い場合は、手戻りが起きない前提と、主要なリスクが同時に起きた前提を具体的に書き出してから日数を付けます。3値の幅が、実績のばらつきや想定リスクの影響に比べて狭い場合は、不確実性の過小評価を疑います。
「ファンクションポイント法の説明はどれか」という試験問題はどう解けばよいですか？
正答は「機能を入出力データ数やファイル数などで定量的に計測し、複雑さで調整して規模を見積もる」という趣旨の選択肢です（基本情報技術者 令和元年度秋期 午前 問53の正答はウ）。この回の誤答は、規模が分かっている前提で工数と工期を出す方法（COCOMOにあたる説明）、類似案件の差分から見積もる方法（類推法）、単位作業の基準値を積算する方法（積み上げ型）でした。手法ごとに「何を入力に、何を出すか」を押さえておけば選択肢を切り分けられます。
