ファンクションポイントって何？ざっくりだけど役立つ規模見積もり

はじめに

先日、業務で「画面ごとにファンクションポイント（FP）をつける」作業をしました。
やってみて感じたのは、「かなりざっくりした指標だな」 ということ。
でも調べてみると、ざっくりだからこそ意味がある、という背景が見えてきました。
この記事では、ファンクションポイントをつける理由や使い道、具体例や他の方法との比較をまとめてみます。

ファンクションポイントとは？

ファンクションポイント（FP）は、ソフトウェア規模を測る国際的な指標です。
プログラムの行数ではなく、ユーザーに提供する機能に注目して「規模感」を数値化します。

分類は以下の5つ：

• 外部入力（EI）：データを入力する機能
• 外部出力（EO）：帳票や画面表示などの出力機能
• 外部照会（EQ）：検索や問い合わせ（入力＋結果返却）
• 内部論理ファイル（ILF）：システム内の保持データ
• 外部インターフェースファイル（EIF）：外部システムから参照するデータ

さらに、それぞれ「低・中・高」の複雑度を判定して点数化します。

なぜファンクションポイントをつけるのか？

1. 見積もり精度を上げるため
   「この画面はどれくらい工数がかかるのか？」を客観的に見積もる基準になります。
   経験や勘に頼らず、標準化された物差しで算定できるのが利点です。

2. プロジェクト全体の規模管理
   画面やバッチ単位でFPを合計すれば、システム全体の規模感を数字で把握できます。
   進捗も「今スプリントで30FP分の開発を完了」といった形で表せます。

3. 過去実績との比較
   過去プロジェクトのFPと工数を紐づけておけば、次回見積もりの根拠になります。
   「前回100FPで2か月かかった。今回は150FPだから3か月程度必要」といった判断が可能です。

実務で感じた「さっくり感」

FPは便利な一方で、かなり大まかな指標です。

• 工数の違いが反映されにくい
  例：ログイン画面はFP上は数点ですが、セキュリティ要件次第で工数は大きく変わる。

• 技術差やチーム差は考慮されない
  経験豊富なチームと新人中心のチームでは、同じFPでも工数が倍違うこともある。

FPは「細かい見積もり」には向かないが、「全体規模感の把握」や「案件比較」には有効。

具体例で見るFPのつけ方

ログイン画面

• 入力：ユーザーID＋パスワード → 外部入力（EI）低＝3点
• 出力：エラーメッセージ → 外部出力（EO）低＝4点
• 合計：7 FP

商品検索画面

• 入力：検索条件（商品名・カテゴリ・価格帯など4項目） → 外部照会（EQ）中＝4点
• 出力：検索結果一覧（10列表示） → 外部出力（EO）中＝5点
• 合計：9 FP

単純に「画面数」でなく、項目数や参照ファイル数でFPが変わるのがポイント。

他の見積もり手法との比較

FP以外にもソフトウェア見積もりの方法はあります。

手法	特徴	メリット	デメリット
LOC法	行数ベース	分かりやすい	言語依存が大きい
FP法	機能ベース	標準化され比較可能	ざっくりしすぎる
UCP法	ユースケースベース	UMLと相性良い	モデリング依存
COCOMO法	数理モデル	理論的に算出	入力精度に依存
ストーリーポイント	相対見積もり	アジャイルに最適	他案件と比較できない

まとめ

ファンクションポイントをつける作業は、

• 見積もりの妥当性を高める
• プロジェクト規模を客観的に管理する
• 過去実績との比較に役立つ

といった目的があります。

一方で、工数の細かい差や技術的難易度は吸収されてしまうため、「さっくり感」は避けられません。
それでも、標準化された“共通言語”として、見積もりや進捗管理の基盤を支える大事な手法だと感じました。