ファンクションポイント法（function point method）
利用者から見える機能の数と複雑さから開発規模を見積もる手法。プログラム言語に左右されない。
もう少し詳しい説明
ファンクションポイント法は、利用者から見える機能の数と複雑さから、開発の規模を見積もる手法です。
何が問題だったのか
昔からある見積もり方は、ソースコード（人が書いたプログラムの文そのもの）の行数で規模を測るものでした（LOC法。Lines Of Code ＝ コードの行数）。これには2つの弱点があります。
| 弱点 | 中身 |
|---|---|
| 言語で変わる | 同じ機能でも、言語が違えば行数が変わる |
| 作らないと分からない | 行数が確定するのは、書き終わったあと |
見積もりは作る前にしたいのに、作り終わらないと分からない物差しを使っている——ここが根本的にちぐはぐでした。
発想：外から見える機能を数える
そこで、中身ではなく、外から見える機能を数えることにします。
画面が何枚あるか、帳票が何種類あるか、どんなファイルを持つか——これなら、要件定義（何を作るのかを決めて文書にする工程）の段階で分かります。そして、どのプログラム言語（人がプログラムを書くための言葉。Java、Python、C言語など）で作っても変わりません。
数える5つのもの
| 種類 | 何を指すか |
|---|---|
| 外部入力 | 外からデータを入れるもの（登録画面など） |
| 外部出力 | 外へデータを出すもの（帳票、集計結果など） |
| 外部照会 | 計算や更新を伴わず、ただ調べて表示するもの |
| 内部論理ファイル | そのシステムが自分で持ち、更新するデータ |
| 外部インタフェースファイル | 他のシステムが持つデータを、参照するだけのもの |
混ざりやすいのは、出力と照会です。加工や計算をしていれば出力、そのまま見せるだけなら照会、と分けます。
ファイルの2つも同じで、自分で更新するか、見るだけかで分かれます。
求め方
数えたら、それぞれを単純・普通・複雑に分けて重みを掛け、合計します。これが未調整FPです。
そのあと、性能や使いやすさといった全体にかかる条件を見て調整係数を掛け、最終的なFPを出します。
FPは「規模」であって、「工数」でも「期間」でもありません。 そこから工数を出すには、1FPあたり何人日かかるかという実績値を掛けます。この実績値は組織ごとに違うので、自社の過去データがないと精度が出ない——これがこの手法の弱点です。
ほかの見積もり方
試験では並べて出されます。
| 手法 | 何をもとにするか |
|---|---|
| ファンクションポイント法 | 外から見える機能の数と複雑さ |
| LOC法 | ソースコードの行数 |
| 類推見積法 | 過去の似たプロジェクトとの比較 |
| 標準タスク法（積算法） | 作業を分解し、1つずつ積み上げる |
| COCOMO | 規模を入力として、工数と期間を数式で求める |
| デルファイ法 | 複数の専門家の意見を、繰り返し集めてまとめる |
COCOMOは「規模から工数を出す」もので、規模そのものを測る手法ではありません。ここが取り違えられます。
覚え方：家の広さを測るように
家の値段を見積もるとき、使った釘の本数は数えません。
- LOC法 … 釘とネジの本数を数える。建ててみないと分からない
- ファンクションポイント法 … 部屋の数と広さを数える。図面の段階で分かる
そして、部屋の数が同じなら、木造でも鉄筋でも「規模」は同じです。そこから値段を出すときに、工法ごとの単価を掛ける——規模と工数を分けて考えるのが、この手法の骨格です。
試験ではこう出る
科目A（旧・午前）のプロジェクトマネジメントの分野で出ます。多いのは、ファンクションポイント法の特徴を選ばせる問題と、他の見積もり手法と取り違えさせる問題です。応用情報では、機能の数と重みを与えてFPを計算させる形も出ます。
判断の軸は2つです。数えるのは、外から見える機能。 そして、プログラム言語に左右されない。 選択肢に「ソースコードの行数」とあればLOC法、「過去の類似案件との比較」とあれば類推見積法です。もう1つ、FPは規模であって工数ではないという点も押さえておくと、引っかけを避けられます。
関連する用語
- EVM（アーンドバリューマネジメント）
- 進み具合と費用を金額で測る手法。見積もった規模が、計画値のもとになる
- WBS
- 作業を分解して並べた図。見積もりは、この単位ごとに積み上げることもある
- LOC法
- ソースコードの行数で規模を測る方法。言語によって行数が変わるのが弱点
- COCOMO
- 規模から工数と期間を見積もるモデル。規模の見積もりを入力として使う
- 要件定義
- 何を作るかを決める工程。ここで機能が見えていれば、この手法が使える
ミニクイズ
ファンクションポイント法の特徴として、最も適切なものはどれか。
正解は 4番：利用者から見える機能の数と複雑さをもとに規模を見積もるため、プログラム言語に左右されない
ファンクションポイント法は、入力画面や帳票、ファイルといった利用者から見える機能を数え、それぞれの複雑さで重み付けして規模を求めます。数える対象が外から見える機能なので、どの言語で作るかに結果が左右されません。「ソースコードの行数で見積もる」のはLOC法で、同じ処理でも言語によって行数が変わるうえ、書き上げるまで確定しないという弱点があります。「過去の類似プロジェクトとの比較だけ」で求めるのは類推見積法です。「人数と期間から逆算する」のは見積もりではなく、割り当てられた条件に合わせているだけです。
この分野をまとめて解く → プロジェクトマネジメントのミニテスト（全16問）
最終更新：2026-09-27