ソフトウェアの大きさ（規模）を、使う機能の数で測る方法のこと
簡単な説明
ファンクションポイント法ってのは、
「このシステム、どんくらいのボリュームあるの？」を使える機能の数で見積もる方法です。
「画面からの入力が○個、検索が○個、出力が○個…じゃあこのくらいの大きさね！」って、
中身（機能）ベースでざっくりサイズ感を出すって感じです。
行数とかじゃなくて、ユーザーから見て「何ができるか」を数えるのがポイントです。
由来
ソフトウェアの開発規模を測るには、昔は「プログラムの行数（LOC: Lines of Code）」を使っていました。しかし、これは使う言語やプログラマーの書き方で大きく変わってしまうため、客観的ではありませんでした。
そこで1979年、IBMのアラン・アルブレヒト（Allan Albrecht）さんが、「プログラムの行数に依存しない方法」としてこのファンクションポイント法（Function Point Method）を提案しました。
具体的な説明
ファンクションポイント法は、ソフトウェアの「利用者が使う機能」や「外部とのやりとり」をもとに、以下の5つの観点でソフトウェアの規模を数値化します：
- 外部入力（EI）：ユーザーがシステムに入力する情報
- 外部出力（EO）：システムがユーザーに出す結果
- 内部論理ファイル（ILF）：システム内部で保持するデータ
- 外部インターフェースファイル（EIF）：他のシステムと共有するデータ
- 外部照会（EQ）：検索などで、表示だけする処理
それぞれの要素に「単純」「普通」「複雑」などの難易度をつけて、点数（ファンクションポイント）を割り振ります。
たとえば、レストランの注文アプリを作るとします。
- お客さんが注文する → 外部入力
- 注文結果を画面に出す → 外部出力
- メニューや注文データを記録する → 内部論理ファイル
- 在庫管理システムと連携 → 外部インターフェースファイル
- 過去の注文を検索する → 外部照会
これらを数えていくことで、「このアプリは50ファンクションポイントくらいの規模だ」と測ることができます。
ファンクションポイントの算定方法は、「機能の種類 × 複雑さに応じた重み付け」で行います。以下に具体的な手順を説明します。
【ステップ1】機能の分類（5つの機能タイプ）
まず、ソフトウェアの機能を以下の5つに分類します：
| 機能タイプ | 説明 |
|---|---|
| 外部入力（EI） | ユーザーからデータを入力する機能 |
| 外部出力（EO） | データを出力・計算・加工して表示する機能 |
| 外部照会（EQ） | 検索や表示のみ（計算なし）の機能 |
| 内部論理ファイル（ILF） | システム内部で保持するファイルやデータ群 |
| 外部インターフェース（EIF） | 他システムとやりとりする外部データ |
【ステップ2】それぞれの数を数える
たとえば：
- 外部入力（EI） = 4個
- 外部出力（EO） = 3個
- 外部照会（EQ） = 2個
- 内部ファイル（ILF） = 2個
- 外部IF（EIF） = 1個
【ステップ3】複雑度を判定する（単純／普通／複雑）
各機能について、データ量や論理的な処理の数から**「単純（Low）」「普通（Average）」「複雑（High）」**に分類します。
ファンクションポイント法は、機能規模を客観的に数値化するための指標であり、ココモ法（COCOMO）など他の見積もりモデルとも組み合わせて使用されます。ファンクションポイントの評価は、業務的視点から機能を分類し、影響度評価とともに加重合計をとることにより求められます。
ファンクションポイント = 各機能の個数 × 重み
その後、複雑度調整係数（14項目の質問による）をかけて、調整後ファンクションポイントが求められます。
【ステップ4】重みを掛ける（下記の表）
| 機能タイプ | 単純 | 普通 | 複雑 |
|---|---|---|---|
| 外部入力（EI） | 3 | 4 | 6 |
| 外部出力（EO） | 4 | 5 | 7 |
| 外部照会（EQ） | 3 | 4 | 6 |
| 内部論理ファイル（ILF） | 7 | 10 | 15 |
| 外部IF（EIF） | 5 | 7 | 10 |
【ステップ5】ファンクションポイントを合計する
例えば、以下のように評価したとします：
- EI（4個 × 普通）→ 4 × 4 = 16
- EO（3個 × 単純）→ 3 × 4 = 12
- EQ（2個 × 複雑）→ 2 × 6 = 12
- ILF（2個 × 普通）→ 2 × 10 = 20
- EIF（1個 × 単純）→ 1 × 5 = 5
合計：65ファンクションポイント
【ステップ6】必要に応じて「複雑度調整係数（VAF）」を掛ける
14項目（たとえば「パフォーマンスは重要か」「トランザクション処理の頻度」など）を0〜5点で評価し、調整係数を算出します：
最終FP = 合計FP × (0.65 + 0.01 × 合計評価点)
実験・観察と結論
プロジェクトAとBで、同じような機能を別のプログラミング言語で開発したとき、行数（LOC）は大きく違いましたが、ファンクションポイントはほぼ同じでした。
このことから、「ファンクションポイント法は言語に依存せず、客観的な規模測定が可能」と結論づけられました。
例文
「このアプリは50ファンクションポイントだから、開発にはだいたい3人月かかるね。」
疑問
Q: ファンクションポイントは何のために使うのですか？
A: ソフトウェアの大きさを客観的に測って、開発期間や費用の見積もりに使います。
Q: プログラムの行数で測るのと何が違うのですか？
A: 行数だとプログラム言語によって差が出ますが、ファンクションポイントならどんな言語でも同じ基準で測れます。
Q: 誰がファンクションポイントを数えるのですか？
A: システムエンジニアなど、業務内容とシステム構成を理解している人が行います。
Q: 難しい機能も簡単な機能も同じように数えますか？
A: 難易度によって点数が違います。たとえば「複雑な外部出力」は高い点数になります。
Q: 小さなシステムにもファンクションポイント法は使えますか？
A: はい、小規模なアプリにも使えます。ただし簡易版で十分な場合もあります。
理解度を確認する問題
ファンクションポイント法の特徴として適切なものはどれか？
A. ソフトウェアの行数を直接数えて規模を測る方法
B. ソフトウェアのファイルサイズを測る方法
C. ソフトウェアの機能数と複雑さで規模を評価する方法
D. 実行速度を測って機能規模を見積もる方法
正解：C
関連論文や参考URL
「Software Metrics: A Rigorous and Practical Approach」（Norman Fenton 他）
解説：この論文では、ファンクションポイント法を含む複数のソフトウェアメトリクスを比較し、特に初期見積もりの信頼性においてFP法の有効性が述べられています。
結果：ファンクションポイント法は特に「上流工程での見積もり精度」に強みを持ち、開発管理に有用であるとされています。
まとめ
ファンクションポイント法は、ソフトウェアの機能の数と複雑さから規模を数値化する手法です。
外部入力や出力など5種類の機能に分類し、それぞれに重み付けして合計します。
プログラム言語に依存せず、見積もりや工数管理に客観的に使えるのが特徴です。
コメント