ファンクションポイント（FP）概要
ファンクションポイント（FP）とは
-
ファンクションポイント（Function Point：以下、FP）とはソフトウェアの「開発規模」（大きさ、サイズ）を測る尺度の一つです。（単位：FP）
-
そのFPを計測するためのルールがFP法（Function Point Analysis）です。
FP法はユーザーが実現したい機能をベースとした計測の考え方であり、開発基盤に影響されないソフトウェア規模計測尺度です。機能の代用特性として定義された入出力やファイルなどの数とその難易度からソフトウェア規模をFP値として算出します。 FPの具体的な計測手法については、FP法の標準化団体であるIFPUG(International Function Point User Group)により、計測手法(IFPUG法)が提供されています。
-
ソフトウェア規模を表すメトリクスとしては、FP以外ではソースコード行数(Source Lines Of Code: 以下、SLOC)が代表的ですが、昨今普及しているローコード/ノーコード製品による開発ではソースコードがリポジトリに隠蔽され取得できない場合があります。ソフトウェア規模は、見積りや障害密度などのベースとして活用されるため、アーキテクチャに依存せず、測定できることが重要です。
-
米国IFPUGがファンクションポイント法の統括団体であり、ITシステム可視化協議会（MCIS）は、その日本支部になります。
FPの歴史
1979年 | Allan J. Albrecht（アラン・J・アルブレクト）が、ファンクションポイント法を提唱 |
1986年 | 米国IFPUG（International Function Point Users Group）が発足 |
1989年 | オランダにてNESMAが発足 |
1994年 | 米国IFPUGの日本支部として、MCISの前身であるJFPUG（日本ファンクションポイントユーザ会）が発足 |
1996年 | JFPUGが講習会（現在のFP計測コース）を開始 |
1998年 | ソフトウェア測定―機能規模測定が、国際標準規格ISO/IEC14143に認定 |
1999年 | ソフトウェア測定―機能規模測定が、日本産業規格JIS X 0135に認定 |
2000年 | IFPUGが、CPCガイドラインを発行 |
2003年 | IFPUG法が、国際標準規格ISO/IEC20926に認定 |
2003年 | COSMIC法が、国際標準規格ISO/IEC19761に認定 |
2005年 | NESMA法が、国際標準規格ISO/IEC 24570に認定 |
2006年 | NESMAがJFPUGと連携し、「開発初期段階でのFPカウント方法」を更改 |
2006年 | COSMIC法が、日本産業規格JIS X 0143に認定 |
2010年 | IFPUG法が、日本産業規格JIS X 0142に認定 |
2010年 | IFPUGが、「Function Point Counting Practice Manual（Release 4.3.1）」を発刊 |
2010年 | R.Meliが、simple FPを提唱 |
2013年 | JFPUGが、「Function Point Counting Practice Manual（Release 4.3.1）」の日本語翻訳版を発刊 |
2016年 | JFPUGが、「Function Point Counting Practice Manual（Release 4.3.1）」の日本語翻訳版の修正版を発刊 |
2019年 | simple FPの所有権が、IFPUGに移管 |
2021年 | simple FPがIFPUGから発行 |
FP計測の概要
-
IFPUG法に基づいたFP計測手法の概要を説明します。最初に、機能(Function)を識別します。識別するものは、以下の5種類です。
・ 内部論理ファイル(ILF：Internal Logical File)
・ 外部インタフェースファイル(EIF：External Interface File)
・ 外部入力(EI：External Input)
・ 外部出力(EO：External Output)
・ 外部照会(EQ：External Inquiry)
それぞれの機能の関連を下図に示します。
-
また、これら5つの機能は、以下のようにデータファンクションとトランザクションファンクションに分類されます。
■データファンクション
アプリケーションが使用するデータのまとまり
・内部論理ファイル（ILF）：
データがアプリケーション内部で維持管理（追加、変更、削除）されるもの
・外部インタフェースファイル（EIF）：
データがアプリケーション内部で維持管理されず、参照のみのもの
■トランザクションファンクション
アプリケーション境界をまたがる一連のデータ処理（入出力）
・外部入力（EI）：
主に外部からのデータ入力によるデータ更新
・外部出力（EO）：
ユーザーへの情報提供、処理ロジックあり
・外部照会（EQ）：
ユーザーへの情報提供、処理ロジックなし
上記にありますように、データファンクションとは、アプリケーションが使用するデータ群を機能と考えたものであり、トランザクションファンクションとは、アプリケーション境界をまたがる一連のデータ処理(入出力)を機能と考えたものです。
また、ILFとEIFの違いは、データがアプリケーション内部で維持管理（追加、変更、削除など）されるものをILF、管理されず参照のみのものをEIFとして識別します。
トランザクションファンクションは、処理の目的によって、EI、EO、EQとして識別します。EIは主に外部からのデータ入力によるデータ(ILF)更新を目的としたものであり、EO、EQはユーザーへの情報提供を目的とします。EO、EQの違いは、レポートなど処理ロジックを通して情報提供するものがEO、単純なデータ検索により情報提供をするものがEQです。
-
次に、洗い出された機能の一覧をFP値として定量化します。そのためには、洗い出された個々の機能に対し重み付けを行う必要があります。IFPUG法では、重み付けは機能ごと複雑度ごとに予めポイントが定められています。FPを算出するには、洗い出された機能種別(ILF, EIF, EI, EO, EQ)ごと、複雑度(高、中、低)ごとに設定されているポイントを参照して算出します。複雑度は、下記の図のようにその機能が持つレコード種類数、データ項目数、関連ファイル数で決定されます。
こうして、次の図のように定められた個々の機能のポイントを合計し、アプリケーション全体のFP値を算出します。
ここまでがFP計測手法の簡単な概要説明です。
利用時の考慮点（FPでできること、FPではできないこと）
-
FPでできること
-
機能要件の定量化
-
データに関する機能（データファンクション）定量化
-
トランザクションに関する機能（トランザクションファンクション）定量化
-
-
-
FPではできないこと
-
非機能要件の考慮
-
UI/UX、性能要件、セキュリティ要件 など
-
-
ビジネスアプリケーション以外の分野での活用
-
科学技術計算
-
リアルタイムソフトウェア （内部ロジックの規模に反映されにくい）
-
CAD・CAM （各ソフトウェアへのFP利用方法が未成熟）
-
-
ソフトウェア実装単位での活用
-
プログラム単位の工数見積り （上流工程での概括的な見積もりには有効）
-
単体テストの試験目標設定 （結合テストでの品質管理等には有効）
-
-
プロジェクト管理が未成熟な状態でのFP適用による生産性・品質の向上
-
FPを適用することが、直接生産性・品質の向上に寄与するわけではない（FPは、あくまで「機能規模の尺度」にすぎない）
-
FPを適用して生産性・品質の指標を設定し、プロジェクト管理に組込むことで、初めて生産性・品質向上が図れる（FPは、生産性・品質向上の一要素）
-
-
FPの活用領域と活用例
FPの活用領域は多岐に及びます。
１ 上流工程におけるスコープマネジメント
FP法はプロジェクトの上流工程におけるスコープマネジメントに活用できます。多くのプロジェクトの失敗は上流工程に起因しています。要件が膨らみ、製造工程に入ってからリソースが足りなくなり、品質問題が露呈し、原価超過や納期遅延につながることがあります。機能要件の変動を上流工程でリアルタイムで把握することが重要であり、要件が想定しているリソース（工数・工期）を超えた場合は優先順位をつけて取捨選択する必要があります。FP法の利点は機能の粒度が決まっており、共通認識を持つことができることと、機能が増大しやすい領域を見つけやすくなることです。
２ 下流工程での活用
ⅰ. 派生開発におけるテストケース数の妥当性について
近年のエンタープライズ領域では、システム構築が「作る」時代から「組合せて使う」時代に変化しています。業務要件に基づき、既存のパッケージ・ソフトウェアやクラウドサービスを組み合わせてカスタマイズする手法が増えており、特に非戦略領域ではその傾向が顕著です。この変化に伴い、派生開発プロジェクトが増加していますが、品質保証が課題となっています。派生開発では開発コスト・期間は軽減されますが、テスト範囲の見極めが難しくなります。特に流用機能のテスト範囲とテスト量の妥当性が重要であり、FPとテスト密度の関係を利用してテストケース数を算出し、妥当性を確認する手法が考えられます。
ⅱ. 運用・保守における生産性の妥当性について
システムの投資対効果を考える際に、初期投資だけでなく運用・保守コストも評価することが重要です。全稼働システムの規模をFPで定量化し、保守作業工数との関係から保守生産性を算出することで、保守コストの妥当性を検証でき、またFPを使って各システムの規模を測定することで、同一企業内での保守生産性比較が可能になります。そして保守生産性が他のシステムに比べて低い場合は、改善策を実行することで保守・運用コストを適正化できます。また、各システムの規模と工数は環境の変化によって変動しますが、経年変化を定量的に測定することで、システムの複雑化や肥大化の兆候を予測し、次回のシステム更改方針を早期に判断できます。一般的に、アプリケーションのライフサイクルに比べてHWSWの保守期間は短いため、定期的な基盤更改の方針を早期に判断することが重要です。
３ システム価格の指標
FPは、FPのポイント判断が合意されたルールに基づいており、国際的な基準として公開されていること、及びFPは利用者にもわかりやすい外観をもとに計測されることから、ソフトウェアの 価格指標として適していると考えられます。
４ 投資対効果の尺度
投資対効果は通常、効果額を投資コストで割ったものですが、これだけではシステム企画やシステム構築の投資が妥当だっ たかを評価できません。ここで一度FPを挟むことで分割して評価することが可能で、「FP/投資コスト」で構築の生産性を測れます。FPは作り方によって変わらないため、パッケージ使用、アジャイル開発、ローコード開発などでも生産性を評価できます。世の中のベンチマークデータと比較して、今回の開発の生産性を評価することもできます。次に、「効果額/FP」はシステムで如何に価値を創出したかを表します。機能は多ければよいというわけではなく、運用にも費用がかかるため、ニーズに合った機能を提供できたかをこの指標で評価できます。
現在の活用状況
-
IPA「2023年度ソフトウェア開発アンケート結果」によると、FP法は、ユーザ企業の35％、ベンダ企業の45％、全体では39％の企業で利用されています。
-
IFPUG法が国際標準規格ISO/IEC20926に認定されて20年が経過した現在、ファンクションポイントは多くの企業で利用されています。
全体の39%が利用
出典：2023年度ソフトウェア開発に関するアンケート調査