ファンクションポイントって何？ざっくりだけど役立つ規模見積もり
はじめに
先日、業務で「画面ごとにファンクションポイント（FP）をつける」作業をしました。
やってみて感じたのは、「かなりざっくりした指標だな」 ということ。
でも調べてみると、ざっくりだからこそ意味がある、という背景が見えてきました。
この記事では、ファンクションポイントをつける理由や使い道、具体例や他の方法との比較をまとめてみます。
ファンクションポイントとは？
ファンクションポイント（FP）は、ソフトウェア規模を測る国際的な指標です。
プログラムの行数ではなく、ユーザーに提供する機能に注目して「規模感」を数値化します。
分類は以下の5つ：
- 外部入力（EI）：データを入力する機能
- 外部出力（EO）：帳票や画面表示などの出力機能
- 外部照会（EQ）：検索や問い合わせ（入力＋結果返却）
- 内部論理ファイル（ILF）：システム内の保持データ
- 外部インターフェースファイル（EIF）：外部システムから参照するデータ
さらに、それぞれ「低・中・高」の複雑度を判定して点数化します。
なぜファンクションポイントをつけるのか？
-
見積もり精度を上げるため
「この画面はどれくらい工数がかかるのか？」を客観的に見積もる基準になります。
経験や勘に頼らず、標準化された物差しで算定できるのが利点です。 -
プロジェクト全体の規模管理
画面やバッチ単位でFPを合計すれば、システム全体の規模感を数字で把握できます。
進捗も「今スプリントで30FP分の開発を完了」といった形で表せます。 -
過去実績との比較
過去プロジェクトの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法 | 数理モデル | 理論的に算出 | 入力精度に依存 |
| ストーリーポイント | 相対見積もり | アジャイルに最適 | 他案件と比較できない |
まとめ
ファンクションポイントをつける作業は、
- 見積もりの妥当性を高める
- プロジェクト規模を客観的に管理する
- 過去実績との比較に役立つ
といった目的があります。
一方で、工数の細かい差や技術的難易度は吸収されてしまうため、「さっくり感」は避けられません。
それでも、標準化された“共通言語”として、見積もりや進捗管理の基盤を支える大事な手法だと感じました。
Discussion