情報管理技術士 学習ノート
← 一覧へ
SW工学・管理
#기능점수#FP#IFPUG#기능규모측정#대가산정
最終更新 · 2026-10-29

ファンクションポイント(Function Point、FP)分析

1. 概要

A. 定義

ファンクションポイント(FP) は、ソフトウェアが 利用者に提供する機能(functionality)の量 を、実装言語・技術・プラットフォームに関係なく定量的に測定する 機能規模測定(Functional Size Measurement、FSM) 手法である。利用者要求をデータ機能とトランザクション機能として識別し、各機能の複雑度に重みを付けて合算することで、コードが一行も書かれる前に「作るべき仕事の大きさ」を数値に換算する。

ファンクションポイントの出発点は、ソフトウェア規模を「何で測るか」という根本的な問いである。従来のLOC(Lines of Code)は完成したコードの量を数えるが、同じ機能をアセンブリで書けば数千行、高水準言語で書けば数十行となり、生産性が高いほど規模が小さく見える逆説 が生じる。さらにコードは開発が終わってからしか数えられず、見積りの本来の目的である「着手前の予測」と矛盾する。ファンクションポイントは測定の基準を「コード」から「利用者が体感する機能」へ移すことでこの逆説を解消する。利用者の立場では「顧客登録」「月次売上照会」が提供する価値は実装技術が何であれ同一であるため、機能で規模を測れば技術中立で比較可能な尺度が得られる。

この転換が持つ意味は大きい。ファンクションポイントは単なる見積り補助手段ではなく、ソフトウェアを「測定可能な工学的対象」として扱うためのメタファーである。異なる言語・フレームワークで開発された二つのシステムの生産性(FP/Man-Month)や欠陥密度(欠陥/FP)を同じ物差しで比較できるようになり、発注者と遂行社が「いくらの事業か」をめぐって繰り広げる消耗的な論争を、客観的規模という共通言語に置き換える。国内の公共情報化事業がファンクションポイントを対価算定の法定標準として採用した理由もここにある。

B. 登場背景と必要性

ファンクションポイントは1979年、IBMのアラン・アルブレヒト(Allan J. Albrecht)が提案した。当時IBM内部では異なる言語で開発されたアプリケーションの開発生産性を比較する共通尺度がなく、LOCベースの比較が言語差に汚染される問題が深刻であった。アルブレヒトは「利用者に伝達される機能の量」を測れば言語に独立な生産性指標が得られるという洞察からファンクションポイントを考案し、その後1986年に IFPUG(International Function Point Users Group) が結成されて測定規則を標準化・精緻化した。現在IFPUGの測定規則は CPM(Counting Practices Manual) として管理され、ISO/IEC 20926として国際標準化された。

国内では公共ソフトウェア事業の予算適正性と発注透明性が監査・監理の核心争点となるにつれ、ファンクションポイントの必要性が一層際立った。かつての投入工数(Man-Month)ベースの対価算定は「人をどれだけ長く投入したか」を根拠とし、生産性が低いほど対価が大きくなる逆誘因と紛争を生んだ。これを受けて政府は SW事業対価算定ガイド を通じて開発費をファンクションポイントベースで算定するよう定着させ、成果物(機能)の規模に費用を連動させることで生産性向上を報いる構造を作った。すなわちファンクションポイントは技術的測定技法であると同時に、公正な取引秩序を支える制度的インフラである。

C. ファンクションポイントが持つ本質的特性

ファンクションポイントが良い規模尺度として機能するにはいくつかの性質を備えなければならず、実際にそう設計されている。第一に 技術独立性 — 測定対象は利用者要求であって実装ではないため、言語・DBMS・アーキテクチャに左右されない。第二に 早期適用性 — 要求・機能仕様が整理される分析段階から測定でき、発注・契約時点に根拠を提供する。第三に 反復可能性 — 測定規則が文書化されているため、異なる測定者が測っても類似した結果に収束する(ただし完全な客観性ではなく、測定者の熟練度による偏差は存在する)。

一方、限界も明確である。ファンクションポイントは 利用者に見える機能 を測るため、性能・セキュリティ・可用性のような 非機能要求 や、複雑なアルゴリズム(例:映像圧縮、数値解析)の内部難度はうまく捉えられない。見かけの機能は単純な「計算一回」であっても、その中に入るアルゴリズム的努力が莫大な場合、ファンクションポイントはその努力を過小評価する。この隔たりを埋めるため、後述するSNAP(非機能規模測定)やCOSMIC(リアルタイム・組込特化)のような補完・代替技法が登場した。

2. ファンクションポイント算定の全体構造と測定手順

ファンクションポイント測定は、ソフトウェアの機能を データ機能 と トランザクション機能 に分けて識別し、それぞれの複雑度を評価して重みを合算する体系的な手順に従う。全体構造は次のとおりである。

flowchart TB
  FP["ファンクションポイント(FP)"] --> DF["データ機能(Data Function)<br/>保存・維持されるデータの規模"]
  FP --> TF["トランザクション機能(Transaction Function)<br/>処理・移動するプロセスの規模"]
  DF --> ILF["内部論理ファイル(ILF)<br/>システムが維持・管理するデータ"]
  DF --> EIF["外部インタフェースファイル(EIF)<br/>外部が維持し参照のみのデータ"]
  TF --> EI["外部入力(EI)<br/>データを変更する入力"]
  TF --> EO["外部出力(EO)<br/>加工・計算された出力"]
  TF --> EQ["外部照会(EQ)<br/>単純な照会・検索"]
  style DF fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style TF fill:#fff3e0,stroke:#e8890c,stroke-width:2px

上記の五類型は、ソフトウェアを「データを盛る器(ファイル)」と「そのデータを扱う仕事(トランザクション)」という二つの軸で分解した結果である。データ機能はシステムが責任を持って維持・管理するデータの束を数える。そのデータを システム内部で生成・修正・削除まで責任を持てばILF、他のシステムが管理し我々は読むだけならEIF である。トランザクション機能は境界を越える処理単位を数え、データを 変更すればEI、加工・計算して送り出せばEO、計算なしにそのまま見せればEQ に区分する。この分類の妙は、「機能」という曖昧な概念を測定可能な五つの範疇に還元した点にある。

測定は次の手順で進む。全体の流れは、測定種別と境界を先に定め、機能を識別・分類したうえで、複雑度を付けて未調整ファンクションポイントを求め、必要に応じて調整係数を適用して確定する順である。

flowchart LR
  A["測定種別・目的の決定"] --> B["測定境界(Boundary)の設定"]
  B --> C["データ・トランザクション機能の識別"]
  C --> D["各機能の複雑度評価<br/>(Low/Average/High)"]
  D --> E["重み合算 = 未調整FP(UFP)"]
  E --> F["調整係数(VAF)の適用"]
  F --> G["調整ファンクションポイント(AFP)の確定"]
  style E fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style G fill:#e6f4ea,stroke:#1e8e3e,stroke-width:2px

A. 測定種別の決定と境界の設定

測定の第一段階は「何を測るか」を定める作業である。IFPUGは測定種別を新規開発(Development)、機能改善(Enhancement)、既存アプリケーション(Application)の三つに区分する。新規開発は初めて作る機能全体を、改善は追加・変更・削除される機能のみを、アプリケーションは現在稼働中のシステムが提供する機能全体を数える。保守対価や再開発の妥当性を問う際に「現在のシステムの規模」が必要となるため、アプリケーション測定は実務で非常に頻繁に使われる。

次に 測定境界(Application Boundary) を設定する。境界とは「測定対象システム」と「その外側(利用者・他システム)」を分ける論理的な線であり、データと処理がこの境界を越えるか否かによって機能種別が決まる。例えばあるデータを我々のシステムが直接管理すればILFとして境界内にあり、他機関のシステムが管理するものを参照のみすれば境界外のEIFとなる。境界をどこに引くかによって同じ機能が別の種別に捉えられうるため、境界設定は測定結果を左右する最も重要な設計判断 である。誤った境界は機能の重複計数や欠落を招くため、利用者視点と業務責任の所在を基準に一貫して引かなければならない。

境界設定の実務的な難点は、マイクロサービス・API中心のアーキテクチャで際立つ。一つの業務機能が複数のサービスに散らばっている場合、各サービスを独立した境界と見るか一つのアプリケーションと見るかによってEIF・内部呼出の計数が変わる。この際は「利用者に一つのアプリケーションとして認識される単位」を境界とし、組織・契約・運用責任の分割線と合わせることが紛争を減らす。

B. データ機能(ILF・EIF)

データ機能はシステムが扱う 論理的データグループ を数える。ここで「論理的」という修飾が核心であり、物理的なテーブル数ではなく、利用者視点で一つの意味単位として認識されるデータの束を数えるという意味である。例えば正規化で「顧客」が顧客基本・顧客連絡先・顧客等級の三テーブルに分かれていても、利用者には一つの「顧客情報」であるため 一つのILF として計数する。この原則のおかげでファンクションポイントは物理設計(正規化水準、インデックス戦略)に左右されない。

内部論理ファイル(ILF、Internal Logical File) は、測定対象システムが 自ら生成・修正・削除し維持・管理する データグループである。受注システムの「受注」「商品」「会員」が代表的である。一方、外部インタフェースファイル(EIF、External Interface File) は、他のシステムがILFとして維持・管理するデータを、我々のシステムは参照(読取)のみする 場合である。例えば受注システムが決済システムの「カード会社コード」テーブルを照会のみするなら、それはEIFである。同一のデータでも責任の所在(誰が維持するか)によってILFとEIFに分かれる点が重要である。あるシステムのILFは、そのデータを参照する他のシステムにとってはEIFとなる。

データ機能の複雑度は二つの指標で決まる。DET(Data Element Type) は利用者が認識する固有のフィールド(属性)の数であり、RET(Record Element Type) はそのデータグループ内の下位グループ(部分集合)の数である。例えば「顧客」に個人顧客・法人顧客の二下位類型があればRET=2となる。DETが多いほど、RETが多いほど複雑度が上がり、この二つの組合せでLow/Average/Highが決まる。データ機能により高い重み(ILF 7〜15)が付与される理由は、データを維持・管理する仕事が単純処理より設計・整合性の面でより大きな努力を伴うという経験則による。

C. トランザクション機能(EI・EO・EQ)

トランザクション機能は境界を越える 基本処理単位(Elementary Process) を数える。基本処理とは利用者に意味のある最小の完結した活動であり、「一部だけ遂行されると業務的に不完全な」単位をいう。「会員登録」が途中で途切れると何の意味もないように、一つの完結した業務が一つのトランザクション機能である。

外部入力(EI、External Input) は、境界の外からデータ・制御情報が入り、ILFを変更(生成・修正・削除)するかシステム動作を変える 処理である。「商品登録」「受注取消」「パスワード変更」が典型的なEIである。外部出力(EO、External Output) は、データを境界の外へ送り出すが、計算・加工・派生ロジックを含む 出力である。「月次売上集計表」「損益計算書」のように合計・比率・派生値を作って送り出せばEOである。外部照会(EQ、External Inquiry) は、計算なしに保存されたデータをそのまま検索・照会 して見せる処理である。「会員情報詳細照会」「商品一覧検索」がEQである。EOとEQを分ける決定的基準は「派生データや計算ロジックの有無」であり、この区分が曖昧なとき測定者間の偏差が最も大きく生じる。

トランザクション機能の複雑度は FTR(File Type Referenced、参照するファイル数) と DET(処理に関与するデータ要素数) で決まる。一つの処理が多くのファイルを参照し多くのフィールドを扱うほど複雑度が高まる。例えば「受注生成」EIが受注・商品・在庫・会員の四ILFを参照すればFTR=4でHigh寄りになる。トランザクション機能の重みがデータ機能より低く設定されたこと(EI 3〜6など)は、処理ロジック一つ一つよりデータ構造の維持・管理がより根本的な努力であるという設計哲学を反映している。

3. 複雑度評価とファンクションポイント計算

A. 複雑度マトリクスと重み

識別された各機能は複雑度(Low/Average/High)に応じて次の重みを受ける。この表はIFPUGが数多くのプロジェクトデータを回帰分析して定めた値で、データ機能がトランザクション機能より、HighがLowより大きな努力を要するという経験的事実を数値化したものである。

機能種別 Low Average High 備考
ILF(内部論理ファイル) 7 10 15 DET・RETで複雑度決定
EIF(外部インタフェースファイル) 5 7 10 参照専用、ILFより低い
EI(外部入力) 3 4 6 FTR・DETで決定
EO(外部出力) 4 5 7 計算・加工を含む
EQ(外部照会) 3 4 6 単純照会

重みの相対的な大きさ自体が多くを物語る。ILFのHigh(15)はEQのLow(3)の五倍であり、これは「データを責任を持って管理する複雑なマスタ」が「単純な照会画面」の五倍の努力を要するという経験則である。測定者はこの表を機械的に適用するが、各機能をどの複雑度に分類するかが結果を左右するため、DET・RET・FTRの算定に一貫した基準を維持しなければならない。

複雑度判定の実際を見ると、データ機能はDETとRETの組合せを三段階の複雑度マトリクスに当てはめる。例えばILFでDETが1〜19個かつRETが1個ならLow、DETが多いかRETが複数ならAverage・Highに上がる。トランザクション機能も同様にFTRとDETの組合せ表を使う。重要なのはこの境界値(threshold)自体を暗記することではなく、「複雑度は参照範囲(ファイル・レコード)とデータ要素の量という二つの軸で決まる」という原理を理解することである。同じ「会員登録」EIでも、扱うフィールドが数十個で複数のファイルを更新すればHigh、数個のフィールドだけを単一ファイルに入れればLowとなる。

この複雑度区分が実務で重要な理由は、全体のファンクションポイントの相当部分が少数のHigh機能から出るためである。数十個の単純照会(EQ Low)より、核心業務マスタ(ILF High)数個が規模と努力を左右する場合が多い。したがって測定品質を高めるには、すべての機能に均等な注意を注ぐより、複雑度の高い核心機能の識別・判定に検証能力を集中するのが効率的である。

B. 未調整ファンクションポイント(UFP)と調整係数(VAF)

識別されたすべての機能の重みを合算した値が 未調整ファンクションポイント(UFP、Unadjusted Function Point) である。UFPは純粋に機能規模のみを表し、ISO/IEC 20926はまさにこのUFPを公式の「機能規模」と定義する。

IFPUG方式はここに選択的に 調整係数(VAF、Value Adjustment Factor) を掛けて 調整ファンクションポイント(AFP、Adjusted Function Point) を求める。VAFはデータ通信、分散処理、性能、過負荷構成、トランザクション率、オンライン入力、エンドユーザ効率、オンライン更新、複雑な処理、再利用性、インストール容易性、運用容易性、多重サイト、変更容易性という 14個の一般システム特性(GSC) を各0〜5点で評価して算出する。計算式は VAF = 0.65 + 0.01 × ∑(14個のGSCスコア) で、すべての特性が平均(各々微々)ならVAF≈1に収束し、最大±35%の補正が可能である。AFP = UFP × VAF が最終ファンクションポイントである。

ただしVAFは論争的である。14個の特性が1980年代の技術環境(メインフレーム・バッチ)を前提に作られ、現代のクラウド・ウェブ環境と合わず、非機能要求を「14個に丸めた」補正が科学的根拠に乏しいという批判が多い。このためISO FSM標準と国内の SW事業対価算定ガイドはVAFを使わずUFP(未調整ファンクションポイント)のみを規模として採用 し、非機能要素は別途の補正係数やSNAPで扱う。技術士の答案では「VAFはIFPUGの選択的調整にすぎず、国内標準はUFP基準」という点を正確に区分して記述することが重要である。

C. 正規法(詳細法)と簡易法

実務でファンクションポイントを測る方式は、精度と測定時点によって二つの枝に分かれる。両者の違いは「各機能の複雑度を個別に評価するか、平均値で一括適用するか」にある。

区分 正規法(詳細法、IFPUG) 簡易法(国内対価算定)
複雑度評価 機能別にDET・RET・FTRでLow/Avg/Highを個別算定 平均複雑度の重みを一括適用
精度 高い 低い(近似値)
適用時点 設計がある程度具体化した後 要求水準の初期
努力・費用 大きい(測定専門性を要する) 小さい(迅速)
国内活用 詳細検証・精算 予算策定・発注段階の標準

簡易法 は各機能の複雑度を逐一問わず、類型別の 平均重み(例:ILF平均、EI平均)を適用する。要求さえ整理されれば素早く規模を推定できるため、詳細設計前の 予算策定・事業発注段階 に適する。国内のSW事業対価算定ガイドが公共事業予算算定の基本として簡易法を採用した理由が、まさにこの早期適用性にある。一方、正規法(詳細法) は機能ごとにDET・RET・FTRを分析して複雑度を個別に判定するため精密だが、設計が具体化した後でなければ測定できず、専門人材と時間がかかる。実務では発注時に簡易法で予算を立て、設計完了後に正規法で精算・検証する二段階運用が多い。

簡単な数値例で感覚をつかもう。あるシステムを簡易法で測り、平均重み基準でILF 5個(平均10)=50、EIF 2個(平均7)=14、EI 20個(平均4)=80、EO 10個(平均5)=50、EQ 15個(平均4)=60と識別したなら、UFP = 50+14+80+50+60 = 254 FP となる。国内対価算定ではこの254 FPに、韓国ソフトウェア産業協会が毎年公表する ファンクションポイント当たり単価(FP単価) と各種補正係数(規模・連携・性能・運用環境など)を掛けて開発原価を算出する。単価は物価・賃金変動を反映して毎年更新されるため、答案では特定の金額を断定するより「協会が公表する当該年度の単価を適用する」と記述するのが安全である。

4. 比較および適用事例

ファンクションポイントの位置づけを理解するには、競合・代替尺度との比較が必要である。LOCとの比較 では、ファンクションポイントの核心的優位は技術独立性と早期適用性である。LOCは開発完了後にしか正確に数えられず言語・生産性に汚染されるが、FPは要求段階で言語と無関係に測定される。逆にLOCは自動集計が容易で測定者の主観が介入しない一方、FPは測定者の熟練度により結果が10%前後揺れうるという弱点がある。そこで二つの指標は「生産性(LOC/FP、言語別変換係数)」という形で互いを補完し、Capers Jonesの言語別LOC/FPテーブルがその代表的な変換ツールである。

COCOMO(LOCベースモデル)との比較 では、ファンクションポイントは「規模測定」と「工数換算」の役割が異なる。COCOMOは規模(KLOC)を入力として工数を計算するモデルであり、FPは規模そのものを測る手法である。実際にCOCOMO IIは初期段階の入力としてFPを受け取りLOCに換算(backfiring)して使うこともある。すなわち両者は競合ではなく、「FPで規模を測り → モデルで工数を換算する」パイプラインとして結合される。

COSMIC(ISO/IEC 19761)との比較 では、ファンクションポイントは適用ドメインで分かれる。IFPUG FPはデータ中心の経営情報システム(MIS)に強いが、データ移動(Entry・Exit・Read・Write)のみで規模を測るCOSMICはリアルタイム・組込・制御ソフトウェアにより適する。見かけのデータは少ないが内部データ移動が頻繁な通信・制御システムでは、IFPUG FPが規模を過小評価する傾向があるためCOSMICが好まれる。

具体的な産業適用事例として、国内の公共次世代システム構築では要求定義書(RFP)を基準に簡易法FPを算定して事業予算を確定し、設計完了時点でファンクションポイントを再算定して課業変更(増減)を定量的に精算する。金融圏ではベンダ成果を比較するため「開発生産性 = 引渡FP / 投入Man-Month」「品質 = 欠陥数 / FP」のようなFP正規化指標をKPIとし、異なる言語・チームの成果を同じ物差しで評価する。グローバルアウトソーシング契約でも「FP当たり単価」方式の成果ベース契約(Price-per-FP)が投入工数ベース契約を代替し、生産性向上の利益が発注者に戻るようにする誘因構造として使われる。

5. 深掘り — 非機能規模測定と自動化動向

ファンクションポイントの最も根本的な限界は「利用者に見える機能のみを測る」点にある。性能・セキュリティ・拡張性・可用性のような非機能要求や、アーキテクチャ転換・大規模リファクタリングのように機能変化なしでも莫大な努力がかかる作業をFPはほとんど捉えられない。この空白を埋めるため、IFPUGは2013年に SNAP(Software Non-functional Assessment Process) を発表した。SNAPはデータ運用、インタフェース設計、技術環境、アーキテクチャなど四範疇の非機能要求をSP(SNAP Point)で測定し、ファンクションポイント(FP)と 相互補完的な別尺度 として使う。FPが「何をするか」、SNAPが「どう・どれだけ堅牢にするか」を測る形である。最近の国内対価算定の議論でも、非機能要求の報酬体系としてSNAP導入が検討されている。

測定の 自動化 も重要な流れである。従来のFP測定は専門家が仕様を読んで手で数えるため、費用と測定者偏差が大きいという宿痾があった。これを解決するため、OMGはソースコードとトランザクション構造からファンクションポイントを自動算定する Automated Function Points(AFP) 標準を制定し、静的解析ツールがデータ関数・トランザクションをコードから逆抽出してFPを計算する。ただし自動測定は「実装されたもの」を測るため要求段階の早期算定には使えず、測定者の業務的判断(基本処理の識別、境界設定)を完全に代替することはできない。

最も最近の変化は AI・LLMベースの規模推定 である。要求文書やユーザストーリーを自然言語処理で分析してデータ・トランザクション機能を自動識別しFPを推定しようとする研究・ツールが登場しており、過去プロジェクトのFP-工数データで学習したモデルが算定誤差の削減に活用される。しかしAI推定は学習データの偏りと説明可能性の問題を抱えており、当面は専門家測定を補助・検証する用途にとどまる見通しである。アジャイル環境ではFPの代わりに相対的規模であるストーリーポイントが使われるが、組織レベルの予算・ベンチマーキングには依然として絶対尺度であるFPが必要で、「ストーリーポイント ↔ FP」の相互換算を試みるハイブリッドアプローチも現れている。

6. 考慮事項および示唆点

技術士の観点からファンクションポイントを適用・運用する際に考慮すべき戦略と含意は次のとおりである。

  • 測定時点と手法の二段階運用:発注段階では要求のみから迅速に測る簡易法で予算を確定し、設計完了後に正規法で再算定して課業変更を精算する二元戦略が望ましい。早期算定は「見積りの円錐」に沿って±誤差が大きいため、一度の測定で確定せず段階的な再測定で精錬すべきである。
  • 測定の一貫性・ガバナンスの確保:FPは測定者の熟練度により結果が揺れるため、境界設定・複雑度判定の基準を組織標準として文書化し、認証測定士(CFPS)または熟練者の相互検証を置いてこそ信頼を得る。測定根拠(識別内訳・複雑度判定)を追跡可能に残すことが監理・紛争対応の核心である。
  • 非機能・高難度要求の別途報酬:FPが過小評価する性能・セキュリティ・アルゴリズム難度はSNAPや別途の補正係数で補完すべきである。特にリアルタイム・組込・AIシステムはIFPUG FPのみで規模を定めると努力が深刻に歪むため、COSMICなどドメイン適合尺度の併用を検討する。
  • 成果ベース契約の誘因設計:FP当たり単価方式は生産性向上の利益が発注者に戻るようにするが、遂行社が「不要な機能を増やしてFPを膨らませる」逆誘因も生む。したがって機能の必要性検証(課業適正性審査)と結合して運用してこそ公正性が保たれる。
  • 展望と連携技術:長期的には測定自動化(OMG AFP)とAI推定が測定費用・偏差を減らし、アジャイル・DevOps環境ではストーリーポイントとの換算を通じてFPが組織レベルのベンチマーキング・ポートフォリオ管理指標として位置づけ直されるであろう。ただし自動化が測定者の業務的判断を完全に代替することはできないため、「自動測定 + 専門家検証」の結合が現実的な方向である。

参考資料

一言まとめ: ファンクションポイント(FP)は、ソフトウェアが提供する機能をデータ機能(ILF・EIF)とトランザクション機能(EI・EO・EQ)として識別・重み合算し実装技術と無関係に規模を測る機能規模測定手法であり、国内SW事業対価算定の標準であると同時に非機能(SNAP)・自動化(AFP)・AI推定へ拡張される工学的尺度である。