FP法とCOCOMOはどう使い分ける？開発見積り6手法を完全比較

雲の大きさは定規で測れない？ 見積りが難しい理由

動画は「ソフトウェア開発って、雲の大きさを定規で測るような作業だと思わない？」という問いかけから始まります。形が変わり続け、手でつかむこともできない。たしかにソフトウェアの本質をついた表現です。普段の買い物なら、重さは何キロ、大きさは何センチと、誰が見ても同じ基準があります。ところがソフトウェアにはそれがありません。だから発注する側も作る側も、「費用はいくら？ 期間はどれくらい？」と頭を抱えることになります。

動画は、システム開発がうまくいかない最大の要因の1つが、この見えない雲に対する見積りの甘さだと説明します。最初に見誤れば予算はあっという間に尽き、プロジェクトは簡単に破綻してしまう、というわけです。そこで今回は、見えない規模やコストをどう算出するかを、6つの代表的な見積り手法で見ていきます。

6つの手法は、ばらばらに並んでいるわけではありません。「規模を何で測るか」「経験やデータを数式にするか」「プロジェクトのどの段階で使うか」という3つの視点で分けると、頭に入りやすくなります。動画も最後に、どれか1つが常に独立した正解なのではなく、プロジェクトの進行状況に合わせて使い分けるのが一般的だと整理しています。

（補足：動画にない話です。IPA（情報処理推進機構）の資料は、ソフトウェア開発の見積り手法として、類推法、専門家による判断、トップダウン見積り、ボトムアップ見積り（工数積上げ）、パラメトリック法、プライスツーウィンを挙げています。プライスツーウィンは顧客の予算に合わせる見積りで、不適切な方法とされています。動画の6手法は、このうち類推法・ボトムアップ・パラメトリック法の系統と、「規模」の測り方（FPとコード行数）にあたります。）

ファンクションポイント法：部屋ごとに値段をつける

最初に出てくるのはファンクションポイント法（FP法）です。ソフトウェアの機能ごとに開発規模を算出する手法です。動画は家づくりにたとえます。レゴを何個使うかではなく、キッチンやお風呂のように部屋ごとに値段を出すので、買う側にはとても分かりやすい。機能単位で見積りが示されるため、顧客の理解を得やすいのが大きな特徴だといいます。お客さんにとっては、裏側の仕組みよりも「結局何ができるのか」のほうが大事だからです。

（補足：動画にない話です。FP法は、1979年にIBMのアレン・J・アルブレヒト（Allan J. Albrecht）が考案した手法です。計測のルールはIFPUG（International Function Point Users Group）が管理し、国際規格ISO/IEC 20926にもなっています。数える対象は、外部入力・外部出力・外部照会・内部論理ファイル・外部インタフェースファイルの5種類で、それぞれ複雑さに応じて点数をつけて合計します。プログラミング言語に依存しない点も利点とされます。）

数え方のイメージをつかむために、小さな受注管理システムで試算してみましょう。点数は、一般に紹介されているIFPUG法の重み付けのうち、複雑さが「中」の場合の値（外部入力4・外部出力5・外部照会4・内部論理ファイル10・外部インタフェースファイル7）を使った説明用のものです。実際の計測では、機能ごとに複雑さを低・中・高と判定して点数を変えます（例：外部入力は3・4・6点）。IFPUGの計測マニュアルそのものは確認していません。

機能の種類	本数×点数	小計
外部入力（受注登録など）	6本×4点	24
外部出力（帳票など）	4本×5点	20
外部照会（検索画面など）	3本×4点	12
内部論理ファイル	3つ×10点	30
外部インタフェースファイル	1つ×7点	7
合計		93FP

こうして規模が93FPと出ます。ここに、過去の実績から「1FPあたり0.35人月かかる」という値を当てはめると、93×0.35＝32.55で、約32.6人月。FP法で出るのは、まず「規模」です。工数は、規模に生産性の実績値を掛けて求めます（この0.35も設例の仮の値です）。

LOC法：ブロックを何個積んだかで測る

FP法と対照的なのがLOC法、またはプログラムステップ法と呼ばれる手法です。ソフトウェアのソースコード数（行数）をもとに、開発規模を推測します。さきほどの家のたとえでいえば、レゴを何個積んだかで測るような、極めて物理的な基準です。動画は、顧客目線のFP法に対して、こちらは開発者目線の物理的な量に頼る手法、という対比を強調しています。

設例で計算してみます。ソースコードが約12,000行になりそうで、過去の実績が1人月あたり400行なら、12,000÷400＝30人月です。計算は単純ですが、行数の見込みがずれれば、そのまま工数もずれます。

（補足：動画にない話です。IPAの資料は、見積りに必要な入力データのうち「規模」の例として、ファンクションポイント、コード行数、機能数・画面数・テーブル数を挙げています。FP法とLOC法は、どちらも「規模」を測る方法で、そこから工数を導くには、生産性などの実績が別に要ります。）

コブラ法：ベテランの勘を数式にする

動画によると、コブラ法（CoBRA法）はパラメトリック法の一種で、コストを目的変数、規模や環境要因を説明変数として、その関係を数式で表します。見積りの経験者の知見のようなものをコスト変動要因として取り出し、量的に扱うのが特徴だと説明されます。

ここで聞き手が、もっともな疑問を挟みます。

（補足：動画にない話です。IPAの資料では、CoBRAは「Cost Estimation, Benchmarking, and Risk Assessment」のハイブリッドな手法で、ドイツのフラウンホーファー協会IESEで開発されたと紹介されています。熟練者の経験と、定量データを組み合わせて見積りを出します。前提は「熟練者はリスクを経験から定量的に把握できる」「工数と規模は線形関係にある」「リスクがその線形関係をずらす原因（工数変動要因）になる」の3つです。原典は、ブリアンド、エルエマム、ボマリウスによる1998年のICSE（国際ソフトウェア工学会議）の論文です。）

（補足：パラメトリック法そのものは、IPAの資料では「工数などを目的変数として、説明変数に規模や要因などを設定し、数学的な関数として表す方法」と説明されています。この定義は、次に出てくるCOCOMOにも当てはまります。）

ココモ（COCOMO）：規模とスキルから工数・期間を出す

もう1つ、統計的なアプローチを使う重要な手法がCOCOMO（ココモ）です。動画は、予想されるコード数や技術者のスキルなどを考慮して、開発に必要な工数や期間などを導き出す手法だと紹介します。そして、使用するプログラミング言語に依存せず、客観的な数値を算出できるとされている、と説明しています。聞き手も「行数だけに引っ張られず、客観的な数値が出せるわけか」と受け止めます。

（補足：動画の説明を、資料で照らしておきます。COCOMOは、アメリカのバリー・ボームが1981年に発表したモデルで、IPAの資料はパラメトリック法に分類しています。式の形は、基本COCOMOでは「工数＝α×規模のb乗」、中間COCOMOでは、そこに工数変動要因による補正を掛けたものです。詳細COCOMOでは、モジュールごと、工程ごとの見積りまでできます。また、開発の性格に応じて、組織モード、半組込みモード、組込みモードの3つに分けて係数を使い分けます。）

（補足：「言語に依存しない」という点について。COCOMO 81の式は、規模を千行単位のソースコード行数（KLOC、KSLOC）で与える形です。IPAの資料も、規模の入力例にファンクションポイントとコード行数を並べています。中間COCOMOの補正項目にも、プログラミング言語の経験が含まれます。動画の「言語に依存しない」という言い方は、資料からはそのままの形では確認できませんでした。この点は、動画の説明と受け取っておくのが安全です。）

実際に計算してみましょう。基本COCOMOの組織モードで、規模が12KLOCの場合です。工数は 2.4×12^1.05＝約32.6人月、期間は 2.5×(32.6)^0.38＝約9.4か月、要員は 32.6÷9.4＝約3.5人になります。

指数が1.05と1より少し大きいので、規模が2倍になっても、工数は2倍よりわずかに増えます。たとえば24KLOCなら約67.5人月で、12KLOCの約32.6人月の2.07倍です。係数は二次資料から引いた値で、版や資料によって違いがあります。後継のCOCOMO IIは、IPAの資料では1997年に第2バージョン、別の資料では1995年に開発され2000年に書籍として公刊されたとされ、資料によって年が異なります。

類推法：過去の似た事例から当たりをつける

ここまで4つの手法を見てきましたが、動画は、実際のプロジェクトでは時間軸によってもアプローチが変わると続けます。プロジェクトの初期段階から使えるのが類推法です。過去の類似事例や経験をもとに推測する手法で、動画では「まず全体のリソースを算出して、そこから個別の作業に割り当てる」やり方だと説明されます。字面のとおり、過去の似たプロジェクトから「だいたいこのくらい」と当たりをつける感覚です。

初期から使えるのは便利ですが、過去の経験が土台なので、見積り担当者のスキルに精度が大きく左右されます。動画は、これを類推法の難点としています。

（補足：IPAの資料は、類推法を「過去の類似プロジェクトの実績を基礎に見積る方法」と定義しています。また、全体システムを見積り可能なサイズのコンポーネントに細分化する方法は、類推法とは別に「トップダウン見積り」として挙げています。動画の「全体から個別へ割り当てる」という進め方の説明は、トップダウン的な考え方に近いものです。）

ボトムアップ法：作業を分解して足し上げる

類推法の対極にあるのがボトムアップ法です。成果物やタスクを細かく分け、構成要素ごとの見積りを合算します。動画は2つのやり方を挙げます。1つは、ソフトウェアを構造化して、機能単位で見積もるやり方。もう1つは、作業を分解したWBSごとに工数を算出するやり方です。

動画によると、見積り精度は非常に高い一方で、決定的な制約があります。設計や計画がある程度進んでいないと適用できない、という点です。タスクを細分化できるくらい計画が進んでいないと、積み上げようがないからです。

設例で見てみます。作業を6つに分けて、要件定義3人月、基本設計5人月、詳細設計6人月、製造9人月、テスト8人月、導入・移行2.5人月と見積ると、合計は33.5人月です。

（補足：IPAの資料は、ボトムアップ見積り（工数積上げ）を「プロジェクトの成果物の構成要素を洗い出し、それぞれに必要な工数などを見積って積み上げる方法」と定義しています。）

6手法の使い分け：試算は類推、詳細はボトムアップ

聞き手は、ここまでの話で「全部つながってきた」と言います。動画は、一見バラバラに見える手法が、プロジェクトの進行状況に合わせて使い分けられるのが一般的だと説明します。まだ情報が少ない初期の試算見積りでは、初期から使える類推法で当たりをつける。計画が進んだ詳細見積りでは、精度の高いボトムアップ法で緻密に計算する、という流れです。

動画の説明を、一覧にまとめておきます（動画での整理で、公的資料の定義ではありません）。

手法	動画での説明	動画の特徴・難点
FP法	機能ごとに規模を算出	顧客に伝わりやすい
LOC法	ソースコードの量から推測	開発者目線の物理的な量
コブラ法	経験者の知見を数式にする	曖昧な直感を見積りに
COCOMO	コード数やスキルから工数・期間	言語に依存しない、と動画は説明
類推法	過去の類似事例から推測	初期から可／担当者のスキルに依存
ボトムアップ法	細分化して合算	精度は高い／計画が必要

ここで、本ページの設例の数字を並べてみます。FP法は約32.6人月、LOC法は30人月、COCOMOは約32.6人月、ボトムアップ法は33.5人月です。設例はあえて近い値になるようにそろえてあります。実際の案件でも、別々の手法で出した値が近ければ心強く、大きく離れていれば前提を見直すきっかけになる、という使い方が考えられます（これは本ページの設例からの発想で、動画の内容ではありません）。

まとめ

動画の6手法を、あらためて振り返ります。

• ファンクションポイント法：機能ごとに規模を測る。顧客に伝わりやすいと動画は説明する。
• LOC法：ソースコードの行数で規模を推測する。開発者目線の物理的な量。
• コブラ法：経験者の知見をコスト変動要因として抽出し、数式にする。
• COCOMO：コード数や技術者のスキルなどから、工数・期間などを導く。（補足の確認：COCOMO 81の式の入力はソースコード行数）。
• 類推法：過去の類似事例から推測する。初期から使えるが、担当者のスキルに左右される。
• ボトムアップ法：作業を分解して足し上げる。精度は高いが、計画が進まないと使えない。

動画の最後は、リスナーへの問いかけです。あなたが新しいプロジェクトを始めるとき、まず過去の経験から全体の当たりをつける類推型で入るでしょうか。それとも、タスクを細かく分けて積み上げるボトムアップ型でしょうか。この見積りの視点は、試験勉強だけでなく、日々の仕事でも使える武器になるはずだ、と動画は結んでいます。