システム開発の見積もりを出すとき、「なぜこの規模になるのか」を説得力のある根拠で説明できていますか？本記事ではそのために役立つ手法のひとつ、FP法（ファンクションポイント法）を取り上げます。エンジニアの方はもちろん、これから発注を検討される方にもわかるよう、できるだけ噛み砕いて解説していきます。
本記事のポイント
- FP法（ファンクションポイント法）は、機能の数と複雑さからシステム開発の規模を算出する国際標準の見積もり手法
- 言語や技術に依存せず客観性が高いが、習得には学習と経験が必要
- 業務システム・Webアプリの開発に向き、リアルタイム制御や組込みには不向き
- 計測は5ステップ：範囲決定 → データ機能 → 処理機能 → UFP算出 → 調整係数で最終値
- 発注側は「計測範囲」「数え方」「換算根拠」の3点を確認すると見積もりの精度が判断しやすい
FP法（ファンクションポイント法）とは
FP法とは、機能の数と複雑さからシステムの開発規模を測る、国際的な見積もり手法です。プログラムの行数を数えるのではなく、画面・帳票・データといった「ユーザーから見える機能」をひとつずつカウントし、それぞれの複雑度に応じて点数（ファンクションポイント）を付けていく──そんなアプローチを取ります。
特徴は、開発言語や技術環境を問わないことで、JavaでもPHPでも、クラウドでもオンプレでも、同じ尺度で評価できます。だからこそ、システム開発の見積もり根拠をクリアにしたい場面で重宝されています。
FP法（ファンクションポイント法）が生まれた背景
FP法は、1979年にアメリカのIBM社のAllan J. Albrecht（アラン・アルブレヒト）氏によって考案されました。
それまで開発規模を測る物差しといえば、プログラムの行数（LOC：Line of Code）でしたが、この方法には弱点がありました。言語によって行数が大きく変わることや、コードが完成するまで正確な数値がわからないという点です。そのため、発注する側にとっては、見積もりの根拠がどうしてもブラックボックスになりがちでした。
そこでアルブレヒトが打ち出したのが、「ユーザーから見える機能を数える」というシンプルな発想でした。言語にも技術にも依存しない、一貫した尺度──それがFP法のはじまりです。1986年には国際組織IFPUGが立ち上がり、いまではISO/IECの国際規格にもなっています。
実際の現場でも、要件定義の段階でFP法による概算が出せていると、その後のスコープ調整や追加見積もりの議論がスムーズに進みます。
なぜシステム開発の現場でFP法（ファンクションポイント法）が使われるのか
業務システムやWebアプリケーションのシステム開発では、見積もりの段階でプロジェクト全体の規模と工数が見えているかどうかが、その後の進行を大きく左右します。FP法が多くの現場で選ばれているのは、この「規模の見える化」を高い精度で実現できるからです。
強みは大きく2つあります。まずひとつめは、開発に着手する前から見積もりが立てられること。要件定義の段階で機能数が見えれば、コストや期間の概算は出せます。そしてもうひとつが、客観性です。計測ルールが標準化されているため、誰が見積もっても結果は大きくぶれません。発注側と開発側が「なぜこの規模になるのか」を同じ言葉で議論できるというのは、想像以上に大きな価値があります。
こうした特性から、FP法は契約時の見積もりだけでなく、生産性の評価やプロジェクト管理の指標としても使われています。ヨドックが採用している開発手法も、こうした客観的な指標を重視しています。
FP法（ファンクションポイント法）のメリット
FP法をシステム開発の見積もりに使うメリットを整理してみましょう。
- 言語・技術にとらわれない：JavaでもPHPでも、言語に依存することなく、同じ尺度で規模を比較できる
- 早期に見積もりが立てられる：要件定義の段階で概算が可能、プロジェクト初期の意思決定が楽になる
- 客観性・再現性が高い：誰が計測してもほぼ同じ結果になり、根拠が明白。属人化を防げるのも強み
- 仕様変更の影響を数値化できる：追加・変更分の機能数を数えるだけで、開発規模への影響が読み取れる
- 国際標準として認められている：ISO/IECにより標準化された、世界共通の物差し
発注する側にとっては、「見積もりの根拠を数値で説明してもらえる」点が、なにより大きな安心材料となります。プログラミングの専門知識がなくても、機能の数をもとに話すことで、開発内容や規模感をぐっとイメージしやすくなります。
FP法のデメリット
メリットの多いFP法ですが、弱点があります。
- 習得のハードルが高い：ILF/EIF/EI/EO/EQなどの計測対象や複雑度判定にはルールが多く、使いこなすには学習と実践の積み重ねが必要
- 計測そのものに工数がかかる：機能をひとつずつカウントするため、大規模システムでは「計測作業」自体がそれなりの工数になる
- 得意・不得意がはっきりしている：業務系・Web系には向くが、リアルタイム制御や組込みなど、データ処理中心ではない領域には不向き
- 非機能要件はカバーできない：性能・セキュリティ・運用性などはFP法だけでは見積もれないため、別の方法と組み合わせる必要がある
つまり、FP法は万能のツールではありません。「自分たちのプロジェクトはどのタイプか」を見極めて、適材適所で使うのがコツです。
他の見積もり手法との比較
見積もり手法はFP法だけではありません。代表的なものを並べると、こんな形になります。
| 手法 | 計測の基準 | 強み | 弱み |
|---|---|---|---|
| FP法 | ユーザーから見える機能 | 言語非依存・客観性が高い | 習得難度、計測の手間 |
| LOC法（ステップ法） | プログラムの行数 | 直感的でシンプル | 言語依存、コード完成後にしか正確に測れない |
| 類推見積もり | 過去の類似プロジェクト | 経験者がいれば素早く算出可能 | 主観に左右される、過去事例が必要 |
| COCOMO | 統計モデルと数式 | 学術的裏付けがある | パラメータが多く運用が複雑 |
どれにも長所と短所があるので、ひとつの手法に絞り込まず、プロジェクトの規模や検討段階に応じて使い分け・組み合わせるのがおすすめです。
FP法（ファンクションポイント法）が向く案件・向かない案件
FP法は効果的な手法ではありますが、万能ではありません。得意な領域と苦手な領域を区別できるかどうかで、FP法の活かし方が変わってきます。
〇 FP法が向いているケース
- 販売管理、在庫管理、人事管理、会計などの業務システム
- 基幹システムや業務系のWebアプリケーション
- 画面・帳票・データベース処理がメインの開発
- 中規模〜大規模のシステム開発プロジェクト
× FP法が向いていないケース
- リアルタイム制御や組込みシステム
- 科学技術計算など、数値計算が主体の開発
- 小規模・短納期で、計測コストが見合わない案件
ご自身のプロジェクトがどちらのケースに近いかを確認した上で、FP法の採用を検討してみてください。具体的にどんな開発をご検討中か知りたい方は、ヨドックの製品・サービス一覧もあわせてご覧ください。
FP法（ファンクションポイント法）の計測フロー（概要）
具体的にどう測るのか、流れだけざっくり紹介しておきます。
① 計測の対象と範囲を決める
② 扱うデータの数を数える（ILF・EIF）
③ 画面・帳票などの処理機能を数える（EI・EO・EQ）
④ 機能ごとの点数を合計する（未調整FP値）
⑤ システム全体の難しさで補正して、最終FP値を出す
各ステップの計算方法や複雑度の判定基準など、さらに細かい解説は別記事「ファンクションポイント法の流れ」にまとめてあります。気になる方はそちらをご覧ください。
FP法（ファンクションポイント法）の具体的な計算例
具体的にどんな数字が出るのか、シンプルなシステムで見てみましょう。
たとえば「社員情報を管理する小さな業務システム」を想定。次のような機能だけ持つとします。
- 社員情報（マスタデータ）を保持する
- 社員情報を新規登録する画面
- 社員情報を一覧表示する画面
- 社員情報を検索する画面
これをFP法の計測対象に分類すると、こうなります。
| 分類 | 該当する機能 | 数 | 複雑度（仮） | 点数 |
|---|---|---|---|---|
| ILF（内部論理ファイル） | 社員マスタ | 1 | 低 | 7 |
| EI（外部入力） | 社員情報の登録画面 | 1 | 低 | 3 |
| EO（外部出力） | 社員情報の一覧表示 | 1 | 低 | 4 |
| EQ（外部照会） | 社員情報の検索 | 1 | 低 | 3 |
| 合計（未調整FP値） | − | − | − | 17 |
合計した未調整FP値が「17」。ここに、性能要件や運用環境を反映した調整係数を掛けて、最終FP値が出ます。仮に調整係数を1.0なら、このシステムは17ファンクションポイントとなります。
この17が、開発工数や費用を出すベース値です。実務では、ここに「1FPあたり◯時間」「◯円」という生産性係数を掛け合わせ、最終的な見積もり金額を導いていきます。
機能の数で規模を測れる──だから、発注側にも数字で根拠を示せる。FP法の強みは、まさにここにあります。
発注側がFP法（ファンクションポイント法）で確認すべき3つのポイント
開発会社からFP法ベースの見積もりを受け取ったとき、押さえておきたい確認ポイントを3つに絞って紹介します。
計測範囲（アプリケーション境界）が明確か
まず聞いておきたいのは、「どこからどこまでをFP計測の対象にしているか」。境界が曖昧なまま進むと、あとから「ここも対象に入れるべきだった」という話になり、追加見積もりが発生しがちです。とくに、外部システムとの連携部分や、既存システムとの境目──このあたりは早い段階で認識を合わせておくと安心です。
機能の数え方に納得できるか
画面・帳票・データの数え方は、会社や担当者によって解釈が分かれることがあります。「なぜこの機能が3つカウントなのか」「この画面はEIなのかEQなのか」──こうした質問をぶつけると、見積もりの透明性がぐっと増します。丁寧な見積もりなら、開発会社側もきちんと答えてくれるはず。
ファンクションポイントから工数・費用への換算根拠
FP法で出るのは「規模」を表す数値です。これを「工数」「費用」に変換する段階で、「1FPあたり◯時間」「◯円」という生産性係数を使います。この係数は、開発会社の生産性や案件の難易度で変わるものです。どんな前提で算出された数字なのか──ここを確認しておくと、見積もりの妥当性も判断しやすくなります。
この3つを開発会社に投げかけるだけで、見積もりの解像度は驚くほど変わります。「なぜこの金額？」を、数字でクリアに答えてもらえる手法だからこそ──こうした問いにも、しっかり応えてくれるはずです。
FP法（ファンクションポイント法）を使いこなすために
FP法を一言でまとめるなら、「システム開発の規模を、誰が見ても納得できる形で測れる手法」です。言語や技術に縛られず、発注する側と作る側が同じ言葉で見積もりを話し合える──これは、プロジェクトを進めるうえで意外と大きな違いを生みます。
エンジニアの方も、発注を検討中の方も、見積もり手法の引き出しを増やしたいときに、FP法は良い選択肢のひとつです。システム開発を検討中の方は、見積もり根拠を確認する材料として頭の片隅に置いておいてください。
