ファンクションポイント法は、画面やファイルといった利用者から見える機能の個数と複雑さでソフトウェアの規模を測る手法です。日本語の解説の多くは「機能を数えて重みを掛け、最後に調整係数を掛ける」という手順で止まっていますが、その調整係数は2010年のIFPUG CPM 4.3で標準の計測手順から外れています。この記事では、複雑度判定に使うマトリクスと重みの実数値、ログイン機能を28FPと数えるまでの途中経過、そしてIPAが公開した実績値で工数へ換算するところまでを示します。
まとめ
- 測定対象は内部論理ファイル（ILF）、外部インタフェースファイル（EIF）、外部入力（EI）、外部出力（EO）、外部照会（EQ）の5種類だけです。サーバ構成やセキュリティ要件はファンクションポイントに含めません。
- 重みは低／中／高の順に、ILFが7・10・15、EIFが5・7・10、EIが3・4・6、EOが4・5・7、EQが3・4・6です。
- 調整係数はIFPUG CPM 4.3で規定本文から削除され、ISO/IEC 20926:2009も未調整ファンクションポイントを機能規模として報告します。掛ける必要はありません。
- 会員サイトのログイン周辺機能を数えると28FPになります。IPAの新規開発実績（400FP未満の中央値0.098 FP/人時）で割ると約286人時です。
- ただし同じ実績データのP25とP75は0.040と0.285で7倍開きます。単一の換算係数で工数を提示すると、根拠のない精度を装うことになります。
この記事の立場は2つです。調整係数は掛けない。そして、公開ベンチマークの中央値ひとつで工数を確定させない。理由を順に示します。
ファンクションポイント法が数える5つの機能タイプ
ファンクションポイント法は1979年にIBMのアラン・アルブレヒトが発表した測定手法です。プログラムの行数ではなく、利用者が認識できる機能の単位で規模を測るため、開発言語や実装技術が変わっても値が比較できます。日本では JIS X 0142:2010「ソフトウェア技術－機能規模測定－IFPUG機能規模測定手法（IFPUG 4.1版未調整ファンクションポイント）計測マニュアル」として規格化されており、対応国際規格は ISO/IEC 20926:2003 です。
機能タイプ別の定義と該当例
| 略号 | 名称 | 区分 | 該当例 |
|---|---|---|---|
| ILF | 内部論理ファイル | データ | 会員マスタ、注文明細 |
| EIF | 外部インタフェースファイル | データ | 他システムの商品マスタ参照 |
| EI | 外部入力 | トランザクション | 会員登録、パスワード変更 |
| EO | 外部出力 | トランザクション | 集計値を含む月次レポート |
| EQ | 外部照会 | トランザクション | 会員情報の一覧表示 |
ILFは測定対象アプリケーションが自分で保守するデータの論理的なまとまり、EIFは他アプリケーションが保守していて参照だけするデータです。トランザクション側の3種は、いずれも「利用者にとって意味のある最小の処理」を1件として数えます。EOとEQを分けるのは計算や導出データの有無で、集計値や算出値を作るならEO、既存データを取り出して見せるだけならEQです。
インフラ構成と非機能要件が測定対象外である理由
サーバの冗長化、VLANの分割、暗号化方式の選定、負荷試験といった作業は、どれだけ工数を要してもファンクションポイントには一切加算されません。ファンクションポイントが測るのは機能規模であって作業量ではないからです。ここにポイントを足してしまうと、規模の値が実装方式に依存し、他プロジェクトとの比較という手法本来の目的が失われます。
非機能面を定量化したい場合は、IFPUGが別に用意しているSNAP（Software Non-functional Assessment Process）を併用します。SNAPは2019年にIEEE 2430-2019として標準化されており、ファンクションポイントとは独立した単位で非機能規模を測ります。両者は足し算するのではなく、別々の指標として並べて扱うのが前提です。
未調整ファンクションポイントの計算手順
計測は、対象範囲とアプリケーション境界を決めたうえで、データファンクション、トランザクションファンクションの順に数えます。各機能は個数を数えるだけでなく、DET（利用者が識別できる重複しない項目）とRET（データの下位グループ）またはFTR（参照するファイル数）から低・中・高の複雑度を判定し、対応する重みを合計します。
データファンクションの複雑度判定と重み
| RET数 | DET 1-19 | DET 20-50 | DET 51以上 |
|---|---|---|---|
| 1 | 低 | 低 | 中 |
| 2-5 | 低 | 中 | 高 |
| 6以上 | 中 | 高 | 高 |
判定した複雑度に対する重みは、ILFが低7・中10・高15、EIFが低5・中7・高10です。多くの業務システムのマスタは1RETかつ20項目未満に収まるため、実際にはILFが7FP、EIFが5FPと判定されるケースが大半を占めます。
トランザクションファンクションの複雑度判定と重み
DETの区切りがEIとEO・EQで異なるため、マトリクスは別々に用意されています。まずEI（外部入力）です。
| EIのFTR数 | DET 1-4 | DET 5-15 | DET 16以上 |
|---|---|---|---|
| 0-1 | 低 | 低 | 中 |
| 2 | 低 | 中 | 高 |
| 3以上 | 中 | 高 | 高 |
EO（外部出力）とEQ（外部照会）は共通のマトリクスを使い、DETの区切りがEIより1つずつ広くなります。
| EO・EQのFTR数 | DET 1-5 | DET 6-19 | DET 20以上 |
|---|---|---|---|
| 0-1（EQは1以上） | 低 | 低 | 中 |
| 2-3 | 低 | 中 | 高 |
| 4以上 | 中 | 高 | 高 |
重みは低・中・高の順にEIが3・4・6、EOが4・5・7、EQが3・4・6となります。EQは必ず1つ以上のFTRを持つため、上表の1行目でFTR 0となるのはEIとEOだけです。参照するファイルが1つも無い処理は、定義上EQになりません。
調整係数を計算手順から外した版の境界
14項目の一般システム特性を0から5で評価し、0.65から1.35の調整係数を掛ける手順は、現行の標準にはありません。IFPUGは2010年のCPM 4.3で調整係数を規定本文から削除し、歴史的経緯として附属書に残す扱いへ変更しました。ISO/IEC 20926:2009も未調整ファンクションポイントを機能規模として報告する仕様です。
規格側では、この線引きはIFPUGの改訂より先に決まっていました。JIS X 0142:2010が対応する ISO/IEC 20926:2003 は、表題の時点で規格化の対象を未調整ファンクションポイントに限定しています。機能規模は利用者機能要件だけから導くという枠組みがあり、開発環境や技術要件を反映する調整係数はそこに入らないためです。CPM 4.3の改訂は、IFPUG自身の計測マニュアルをこの枠組みに合わせた変更にあたります。
なおJIS X 0142:2010が翻訳しているのはIFPUG 4.1版で、本記事が現行として扱うCPM 4.3とは版が異なります。ただし5つの機能タイプの区分と重み（ILF 7・10・15、EIF 5・7・10など）は両版で変わっていないため、規格名で確認しても数値は一致します。社内標準や過去の見積書に調整係数の手順が残っている場合、それはCPM 4.2以前の手順であり、外部のベンチマークデータと突き合わせる用途には使えないと考えてください。
ログイン機能を28FPと数える算出例
会員サイトのログイン周辺機能を対象に、実際に数えてみます。データは会員マスタとログイン履歴の2つ、処理はログイン、パスワード変更、会員情報照会、月次ログイン集計レポートの4つとします。
| 機能 | 種別 | DET | RET/FTR | 複雑度 | FP |
|---|---|---|---|---|---|
| 会員マスタ | ILF | 8 | RET 1 | 低 | 7 |
| ログイン履歴 | ILF | 5 | RET 1 | 低 | 7 |
| ログイン | EI | 4 | FTR 1 | 低 | 3 |
| パスワード変更 | EI | 5 | FTR 1 | 低 | 3 |
| 会員情報照会 | EQ | 7 | FTR 1 | 低 | 3 |
| 月次ログイン集計 | EO | 6 | FTR 2 | 中 | 5 |
| 合計 | – | – | – | – | 28 |
会員マスタのDET 8は、会員ID・パスワードハッシュ・氏名・メールアドレス・権限区分・状態・最終ログイン日時・登録日時です。ログインのDET 4は、会員ID・パスワードの入力2項目に、実行を指示する能力とエラーメッセージを返す能力を各1として数えています。ボタンが複数あっても実行指示は1DET、メッセージが何種類あっても応答は1DETです。月次ログイン集計だけが中の複雑度になるのは、会員マスタとログイン履歴の2ファイルを参照し、ログイン率という導出データを作るためです。
ログインをEIとEQのどちらに分類するかの判断
ログイン処理の分類は設計に依存します。上の例では最終ログイン日時を会員マスタへ書き込むため、ILFを保守する処理としてEIになります。認証結果を記録せず、入力値を照合して画面遷移するだけの設計であれば、ILFを保守せず計算も導出データの生成も行わないため、EQと判定するのが自然です。
ここを機械的に「ログイン画面だからEI」と決めてしまうと、数え方が測定者ごとに揺れます。判定に迷ったら、その処理がILFを更新するか、計算を含むか、システムの振る舞いを変えるかという3点を確認してください。いずれかに該当すればEI側、どれにも該当せず取り出して見せるだけならEQ側です。
NESMA概算法で同じ機能を数えた場合の差
要件が固まる前に規模のあたりをつけたい場合は、ISO/IEC 24570:2018として標準化されているNESMAの概算法が使えます。データのまとまりをILFとEIFに分類するだけで、FP = 35 × ILF数 + 15 × EIF数 で概算値が出ます。上の例に当てはめるとILFが2、EIFが0なので70FPです。
詳細に数えた28FPに対して2.5倍になりました。概算法は1つのILFにつきEIが3件・EOが2件・EQが1件、1つのEIFにつきEOとEQが各1件あるという平均像を前提に置き、そこから丸めた係数として35と15を採用しています。個々の複雑度を判定しないぶん、詳細計測を再現する係数にはなっていません。今回のようにデータ1つあたりの画面数が少ない設計では、概算値は明確に上振れします。逆に、1つのマスタに対して登録・更新・削除・一覧・詳細・帳票が一通り揃う基幹系では、実測値に近づきます。概算法を使うときは、この前提が自社の設計に合うかを先に確かめてください。
ファンクションポイントから工数への換算精度
ファンクションポイント法は規模を測る手法であり、工数を算出する式を持ちません。人月へ変換するには、1FPあたり何時間かかったかという生産性の実績が別途必要です。自社の過去プロジェクトに実績が無い場合、公開ベンチマークを借りることになります。
IPA公開データによる換算の実測レンジ
IPAの「ソフトウェア開発分析データ集2022」は、FP生産性（FP規模を開発5工程の工数で割った値）を規模帯別に公開しています。新規開発の集計は次のとおりです。
| FP規模 | 件数 | 中央値[FP/人時] | 中央値[FP/人月] |
|---|---|---|---|
| 全体 | 46 | 0.151 | 24.20 |
| 400FP未満 | 9 | 0.098 | 15.66 |
| 400-1,000FP | 13 | 0.122 | 19.47 |
| 1,000-3,000FP | 20 | 0.191 | 30.61 |
| 3,000FP以上 | 4 | 非公表 | 非公表 |
人月換算は1人月160時間としたIPAの定義に従っています。両列とも原典の掲載値をそのまま引いており、FP/人時列は小数第3位に丸めてあるため、160倍しても人月列と厳密には一致しません。3,000FP以上の4件は統計値が非公表です。先ほどの28FPは400FP未満の帯なので、中央値0.098 FP/人時で割ると約286人時、1人月160時間なら約1.8人月になります。
単一の換算係数で工数を提示してはいけない理由
同じ新規開発46件の分布を見ると、第1四分位が0.040 FP/人時、第3四分位が0.285 FP/人時です。28FPをこの両端で割ると700人時と98人時になります。真ん中の半数だけを取っても7倍の開きがあるということです。
したがって、公開ベンチマークの中央値を1つ選んで「28FPだから286人時です」と提示するのは避けてください。提示するなら、採用した係数の出典と分布の幅を必ず添え、幅のどこを見込んだのかを説明できる状態にします。実務で精度を上げる方法は1つだけで、自社の完了プロジェクトのFP実績と工数実績を蓄積し、自社の生産性分布を持つことです。他社の中央値は、自社データが揃うまでの暫定値にすぎません。
公開ベンチマークが2022年で止まっている影響
このデータ集は2022年9月26日公開の2022年版が最終版で、IPAは事業終了に伴い今後の発行予定はないと告知しています。収録は累計5,546プロジェクトですが、上の表の46件は「新規開発」「開発5工程がそろっている」「FP計測手法が明確」「FP実績値がゼロより大きい」をすべて満たしたものに限った件数です。改良開発で同じ条件を満たすものは35件になります。任意提供データの集計であり国内の悉皆調査ではないため、母集団の代表性にも限界があります。ベンチマークとして参照する際は、2016年度から2021年度のデータであることと、この層別条件を前提に置いてください。
COCOMO・プログラムステップ法との役割の違い
COCOMOとの違いを問われることがありますが、両者は比較する対象ではありません。ファンクションポイント法は規模を測る物差しで、COCOMOはその規模を入力として工数と期間を推定する数理モデルです。COCOMO IIが入力に取るのはKSLOC（千行単位のソースコード行数）であり、ファンクションポイントを使う場合は言語ごとの換算値でSLOCへ直してから投入します。物差しと計算モデルという別の層に属します。
| 手法 | 測る・出すもの | 必要な情報 | 適用時期 |
|---|---|---|---|
| ファンクションポイント法 | 機能規模 | 画面・帳票・ファイルの一覧 | 要件定義後 |
| プログラムステップ法 | コード規模 | 類似実装の行数実績 | 設計後 |
| COCOMO II | 工数・期間 | KSLOCと各種係数 | 規模確定後 |
| 類推見積り | 工数 | 類似案件の実績 | 企画段階から |
プログラムステップ法は実装後の行数に依存するため、言語や実装者の書き方で値が変わります。一方で設計が固まっていれば精度は出しやすく、既存システムの改修では有効な選択肢です。使い分けの基準は単純で、要件定義の成果物しか無い段階ならファンクションポイント法、実装方式まで決まっているならステップ法を使います。企画段階でどちらも使えない場合は、ボトムアップ見積もりとは？パラメトリック・類推・三点見積りとの違いをわかりやすく解説で扱っている類推見積りや三点見積りが選択肢になります。算出した工数を人日・人月へ落とす際の換算は工数計算のやり方｜人日・人月の計算式と単位換算・見積もりの手順にまとめました。案件の規模と体制から手法を選び直したい場合は、プロジェクト規模と開発体制に応じた工数見積もり手法の全体像が全体地図になります。
ファンクションポイント法を採用すべきでない場面
この手法が向かない案件は明確です。次のいずれかに当てはまるなら、無理に導入しても計測コストに見合いません。
- 要件が画面・帳票・ファイルの一覧に落ちていない企画段階。数える対象そのものが存在しません。
- データ処理が主役ではない領域。組込み制御、バッチの性能改善、インフラ更改は、工数の大半が測定対象外の作業に費やされます。
- 数十人時規模の小改修。計測と検証の工数が、対象作業の工数を上回ります。
- 自社にFP生産性の実績が1件も無い状態。規模は測れても工数へ変換できず、結局は勘に戻ります。
最も効くのは、複数ベンダーの見積りを同じ物差しで並べたい場面です。利用者から見える機能だけを根拠にするため、実装技術の内訳を理解していない発注担当者とも規模の議論が成立します。次に有効なのが、複数年にわたる開発の生産性推移を同じ単位で追う用途です。単発の案件で精度を上げる目的だけなら、導入コストに見合わないことのほうが多いと考えてください。見積り精度が崩れる要因を工程側から整理したい場合は、開発現場で見積もり精度が低下する構造的な原因とプロジェクト規模別の傾向も参考になります。
よくある質問
基本情報技術者試験でファンクションポイント法の説明として正しいのはどれですか？
繰り返し出題されている設問で、正答は「外部入出力や内部論理ファイル、外部照会、外部インタフェースなどの個数や特性から開発規模を見積もる」という趣旨の選択肢です。誤答として並ぶのは、プログラムの行数から見積もる型と、開発者の経験年数や過去の類似案件から見積もる型の2つ。5つの機能タイプの名称を覚えておけば判別できます。
ファンクションポイント法の無料の計算ツールはありますか？
IFPUGが公式に配布している無料ツールはありません。ただし第三者が公開しているフリーソフトはあり、IFPUG法・試算法・概算法に対応した算出支援ツールがダウンロードサイトで配布されています。いずれの場合も複雑度判定は人が行うため、ツールが担うのは集計と記録の部分です。この記事の複雑度マトリクスと重みを表計算ソフトへ入れて機能一覧と突き合わせても、得られる結果は変わりません。要件が固まっていない段階なら、ILFとEIFの数だけで計算できるNESMA概算法のほうが早く済みます。
調整係数（VAF）は計算しなくてよいのですか？
現行の標準では計算しません。IFPUGはCPM 4.3で調整係数を規定本文から外し、ISO/IEC 20926:2009も未調整ファンクションポイントを機能規模として報告します。過去の見積書と比較する目的で参考値として併記するのは構いませんが、外部データと突き合わせる規模の値は未調整のものを使ってください。
プログラムステップ法とファンクションポイント法はどちらが正確ですか？
適用する時期が違うため、正確さの単純比較はできません。設計が完了し類似実装の行数実績がある改修案件ではステップ法のほうが誤差は小さく、要件定義書しか無い新規開発ではファンクションポイント法しか適用できません。どちらも規模を測る手法であり、工数へ変換する係数の精度が最終的な見積り精度を決めます。
非機能要件やインフラ構築の工数はファンクションポイントに含めますか？
含めません。冗長構成、暗号化、負荷試験、ネットワーク設定はいずれも測定対象外です。これらを定量化する場合はSNAP（IEEE 2430-2019）を併用し、ファンクションポイントとは別の指標として管理します。実務では、機能規模から出した工数に、非機能対応分を別立ての作業項目として積み上げる形が現実的です。
