対象試験と出題頻度
ファンクションポイント法（FP法）は、ITパスポート・基本情報技術者・応用情報技術者で出題されるテーマです。
ソフトウェア開発の見積もり手法として定番で、「LOC法（プログラムステップ法）」「COCOMO」「類推見積もり」との違いを正確に区別できるかが問われます。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
情報処理試験を勉強していると、「ファンクションポイント法って結局何を測ってるの？コード行数で見積もるのと何が違うの？」と混乱しがちです。
ファンクションポイント法（Function Point Method／FP法）とは、一言で言うと
「ソフトウェアが持つ機能の数と複雑さからシステムの規模を点数化し、開発工数を見積もる手法」
のことです。
イメージとしては、「引っ越し業者の見積もり」です。
引っ越し業者は「冷蔵庫1点」「ベッド1点」「段ボール20箱」のように荷物の種類と量を数えて料金を出します。家の間取りや荷造りの中身までは見ません。
FP法も同じで、「画面が何個」「帳票が何個」「ファイル更新が何個」のように外部から見える機能を数え、その合計点で開発の大きさを測ります。中身のプログラム行数は問いません。
📊 ファンクションポイント法の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Function Point Method（FP法） |
| 提唱者 | A.J.アルブレヒト（IBM、1979年） |
| 主な利用工程 | 要件定義・基本設計後の規模見積もり |
| 測定対象 | ユーザー視点で見える機能（入力・出力・問合せ・ファイル） |
解説
ソフトウェア開発の見積もりは、長らく「プログラムが何行になるか（LOC：Lines Of Code）」を基準にしてきました。しかし、この方法には大きな弱点があります。
使うプログラミング言語によって行数が大きく変わり、同じ機能でもCで書けば100行、Pythonで書けば10行ということが普通に起こります。さらに、要件定義の段階ではコード行数の予測自体が困難です。
この弱点を埋めるためにアルブレヒトが1979年に提案したのが、言語に依存せずユーザー視点の機能で規模を測る考え方です。
5つの機能タイプ
FP法では、システムが持つ機能を以下の5タイプに分類して数えます。
| 機能タイプ | 略称 | 具体例 |
|---|---|---|
| 外部入力 | EI | 登録画面、データ更新処理 |
| 外部出力 | EO | 帳票、集計レポート（加工あり） |
| 外部照会 | EQ | 検索画面、参照表示（加工なし） |
| 内部論理ファイル | ILF | 自システムが保持するマスタ・データ |
| 外部インタフェースファイル | EIF | 他システムから参照するファイル |
図解：FP法の計算フロー
FP値を算出する流れは「機能を数える → 複雑さで重み付け → 補正係数で調整」の3ステップです。
▼ ファンクションポイント算出の3ステップ
STEP 1：機能の数え上げ
EI・EO・EQ・ILF・EIFの5タイプを個数カウント
STEP 2：複雑さで重み付け
各機能を「単純／普通／複雑」に分類し点数を掛ける
STEP 3：補正係数で調整
性能要件・信頼性などの14項目で全体を補正 → 最終FP値
計算例：簡易な顧客管理システム
STEP1とSTEP2を具体的な数値で確認します。重み付け係数は「普通」レベルを採用しています。
| 機能タイプ | 個数 | 重み（普通） | 小計 |
|---|---|---|---|
| 外部入力（EI） | 5 | ×4 | 20 |
| 外部出力（EO） | 3 | ×5 | 15 |
| 外部照会（EQ） | 4 | ×4 | 16 |
| 内部論理ファイル（ILF） | 2 | ×10 | 20 |
| 外部インタフェースファイル（EIF） | 1 | ×7 | 7 |
| 未調整FP合計 | 78 | ||
この78に補正係数（例：1.05）を掛けて、最終的なFP値「約82FP」を得ます。
さらに「1FPあたり何人時」という生産性データを掛ければ工数見積もりに変換できます。
他の見積もり手法との比較
| 手法 | 測る対象 | 見分けキーワード |
|---|---|---|
| ファンクションポイント法 | ユーザー視点で見える機能の数と複雑さ | 機能、外部入出力、ファイル |
| LOC法（プログラムステップ法） | ソースコードの行数 | 行数、ステップ数、言語依存 |
| COCOMO | LOCに開発要因の係数を掛けた工数算出モデル | 数式モデル、ベーム、KLOC |
| 類推見積もり | 過去の類似プロジェクトとの比較 | 過去実績、経験、トップダウン |
| 標準タスク法 | 作業をWBSに分解して積み上げ | WBS、ボトムアップ、積算 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 FP法の核心を3行で
・ユーザーから見える機能の数と複雑さでソフトウェア規模を点数化する見積もり手法
・測定要素は「外部入力（EI）」「外部出力（EO）」「外部照会（EQ）」「内部論理ファイル（ILF）」「外部インタフェースファイル（EIF）」の5タイプ
・LOC法と違いプログラミング言語に依存しないため、要件定義段階から見積もり可能
試験ではこう出る！
FP法は、IP・FE・APの午前問題で見積もり手法の選択問題として繰り返し登場します。出題パターンは2つに集約できます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| AP R3秋 午前 問52 |
FP法の説明として正しいものを選ぶ問題。 | ・「外部入出力やファイル数などの機能から見積もる」が正解 ・LOC法・COCOMO・類推見積もりの説明がひっかけ |
| FE H30秋 午前 問52 |
ソフトウェアの規模を機能ごとに重み付けして合計する手法を選ぶ問題。 | ・正解は「ファンクションポイント法」 ・キーワードは「機能」「重み付け」 |
| IP R元秋 問38 |
FP法が何を基準にするかを問う問題。 | ・「外部仕様の機能数と複雑さ」が正解 ・行数や開発期間で測る選択肢はひっかけ |
| AP H29春 午前 問53 |
FP法の特徴として適切なものを選ぶ問題。 | ・「言語に依存せず要件定義段階で見積もり可能」が正解 |
📝 IPA試験での出題パターン
パターン1：「FP法の説明を選べ」
4つの見積もり手法の説明文が並び、FP法に該当するものを選ぶ形式。ひっかけとして「ソースコードの行数で測る」（LOC法）、「過去の類似プロジェクトと比較する」（類推見積もり）、「LOCと係数で工数を計算する」（COCOMO）が紛れ込みます。キーワードは「機能」「外部入出力」「ファイル」「重み付け」です。
パターン2：「測定対象を選べ」
FP法が何を基準に規模を測るかを問う形式。正解は「外部から見える機能の種類と数、複雑さ」。「ソースコード行数」「開発期間」「メンバー人数」は除外します。
ここまででOKです。EI・EO・EQの個別係数（3/4/6など）の暗記までは午前で問われません。深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. ソフトウェア開発における「ファンクションポイント法」の説明として、最も適切なものはどれでしょうか？
- A. 過去に開発した類似のシステムの実績工数を基準にして、規模や難易度の差分から新規プロジェクトの工数を見積もる手法。
- B. ソースコードの行数（LOC）を基準に、プログラミング言語ごとの生産性係数を掛けて開発工数を算出する手法。
- C. 外部入力・外部出力・外部照会・内部論理ファイル・外部インタフェースファイルの数と複雑さに重みを付けて合計し、ソフトウェアの規模を点数化する手法。
正解と解説を見る
正解：C
解説：
FP法は、ユーザー視点で見える5つの機能タイプ（EI・EO・EQ・ILF・EIF）を数え、それぞれの複雑さに応じた重みを掛けて合計することでソフトウェア規模を測定する手法です。プログラミング言語に依存しないため、要件定義の段階でも見積もりが可能な点が大きな特徴です。
選択肢Aは類推見積もりの説明です。過去の類似プロジェクトの実績を基準にする方法で、FP法のように機能を細かく数値化する手法ではありません。選択肢BはLOC法（プログラムステップ法）の説明です。ソースコード行数を基準にする手法で、言語によって行数が変動するという欠点があり、FP法はまさにその欠点を補うために考案されました。
よくある質問（FAQ）
Q. FP法には種類がありますか？
あります。代表的なのはIFPUG（International Function Point Users Group）が標準化した「IFPUG法」で、世界的に最も普及しています。他にイギリス発の「Mark II法」、機能数の数え上げを簡略化した「概算COSMIC法」「SLIM法」などがあります。IPA試験では「IFPUG法」の名前と、5つの機能タイプを覚えておけば十分です。
Q. 「外部出力（EO）」と「外部照会（EQ）」の違いがわかりません。
区別のポイントは「データを加工しているかどうか」です。EOは集計・計算・編集など加工処理を伴う出力（売上集計レポートなど）、EQは加工せずデータベースの内容をそのまま表示する出力（顧客マスタ参照画面など）を指します。試験では細部までは問われませんが、実務で見積もる際はこの違いで重み付けが変わります。
Q. アジャイル開発でもFP法は使えますか？
使えます。ただし、アジャイルではユーザーストーリー単位の「ストーリーポイント」を使うチームが主流です。FP法は要件が比較的固まっているプロジェクト（受託開発・保守案件など）の見積もりに向いており、要件が頻繁に変わるアジャイル現場では補助的な位置づけになることが多いです。発注側がFP単価で契約を結ぶケースでは、アジャイルでもFP値を算出します。
Q. FP値から工数（人月）への変換はどうやりますか？
「FP値 ÷ 1人月あたりの生産性（FP/人月）」で工数を算出します。生産性データは企業や言語、案件種別で大きく異なり、IPAの『ソフトウェア開発分析データ集』では業界の参考値が公開されています。例えば生産性が10FP/人月の組織で82FPのシステムを開発する場合、概算工数は約8.2人月です。試験ではここまで踏み込んだ計算は問われないため、考え方として押さえておけば十分です。
