FP法とは「ファンクションポイント法」の略で、1979年に米国IBMのAllan Albrecht氏により考案されました。**FP法の目的は誰が見積もりの計測を行っても同じ結果が得られ、見積もり作業のばらつきを抑えることです。**そのため、ソフトウェア開発の生産性を測定するためのユーザー要件を、ファンクションとして定義しカテゴリー化することで、*見積もりの平準化を行います。*

### FP法で定量化できるのは機能要件

**FP法では機能要件とその他の要件を分類して計算することで、正確な見積もりを出すことができます。**FP法はデータ構造によって規模を見積もっているため、システムのデータやファイルが明確である機能要件が見積もりの対象です。*機能規模では、非機能要件や技術者要件を含みません。*

FP法ではシステムの機能を「ファンクション」と呼び、そのファンクションごとに点数を定めています。そのため*誰が見積もりをしても、ファンクションの数を数えるだけでシステム規模の見積もりが同等に実施できます。*そのファンクションはシステムの実装形式による違いがなく、従来のオンプレミス（所有型）でもクラウド（利用型）でも同じスコアとなります。

同様にシステム開発の形式にも依存しないので、新規開発でもパッケージ利用でも同等の結果となります。さらに開発手法においても、従来型のウォータフォールモデルでもアジャイル型でもスコアに差がありません。もちろん、開発言語にも依存しません。

アジャイル開発の特徴、メリット・デメリット、DXとの関係など

### FP法のファンクションの詳細

FP法ではファンクションをデータ処理に関する「トランザクションファンクション」と、データ格納に関する「データファンクション」に大別して集計されます。各区分のファンクションごとに点数を定めているため、*点数表に集計すると合計のスコアが簡単に求められます。*

各機能はそれぞれ、外部入力（EI）・外部出力（EO）・外部照会（EQ）・内部論理ファイル（ILF）・外部インターフェイスファイル（EIF）に分類し算出されます。

FP法の計算手順は以下のようになります。

*（1）扱うデータを5つのファンクション型に分類*

　外部入力（EI）、外部出力（EO）、外部照会（EQ）、内部論理ファイル（ILF）、外部インタフェースファイル（EIF）の5分類

*（2） 扱うデータごとに、「データ項目数」とそのデータに関連する「レコード種類数」を集計*

　データのファンクションの複雑さを3段階（低・中・高）に分類

*（3）システム全体の未調整FPの計算*

　各データに3段階のファンクションの複雑さに応じた未調整FP（調整係数）を掛けて合計

*（4） システムの特性の合計値を計算*

　システム特性を14の観点から0から5の6段階で評価

*（5） システム特性係数の計算*

　　VAF：Value Adjustment Factor、システム特性係数

　　TDI：Total Degree of Influence、システム特性の合計値

## FP法のメリット・デメリット

ここでは、FP法を活用するうえでのメリット・デメリットをそれぞれわかりやすく説明します。

FP法のメリットは、誰が算定しても同等の結果が得られるため、見積もり作業のばらつきを抑えることができます。同様に、プロジェクト期間中に仕様変更が生じた場合もFP数が変わることを指標として算定できるため、**要件変動による影響をあらかじめ可視化することが可能です。**

また、求める品質評価の目標値をFP法で設定することにより、品質の評価がより簡単に実施できるメリットがあります。

FP法は便利な見積もりの手法ですが、決して万能という訳ではありません。*過去に事例のない機能は評価が難しい・複雑な入力機能と単純な入力機能の見極めができないため同じ数値になってしまう・非機能要件は数値化できない*、といったデメリットが挙げられます。FP法をしようする際は、これらのデメリット部分も理解しておきましょう。

FP法は工数の見積もりだけでなく、プロジェクトサイクル全般で活用できます。具体的には*見積もりやその評価、工数管理・品質管理や進捗管理、ベンダーの評価や運用評価、ソフトウェア資産管理や投資対効果の評価等*、多岐に渡ります。

大規模なプロジェクトでは、ソフトウェア開発に着手するまでにシステム戦略策定からシステム化計画、そして要件定義・設計・開発と多くのフェーズを経由します。特に、先行して検討されるシステム戦略策定時には、システム化の方向性を決定するために多くの要求事項が挙げられるため、*実際にシステム開発で必要とする部分とのズレやブレが発生します。*

そのため、見積もり誤差がリスク分として多く計上されてしまい、そのリスク分は不確実性によるもので経験値によるところが大きい領域です。特に未確定の要求仕様については累積してリスク計上されていくため、システムが肥大化する要因となります。これを防ぐために、同様の要求を満たすシステム事例を参照したり、プロジェクトサイクル全般を想定した見積もり手法が必要です。

**FP法では早期から実装機能をファンクションとして算定できるためブレを吸収し実装していくことができます。**

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

FP法では機能要件を低・中・高の複雑度の分類で算定するため、*対象とするアプリケーション開発の工数とソフトウェア製造量と直接的に合致しない場合もあります。*そのため、あらかじめ同等の業務での開発実績のデータを蓄積し、見積もり制度を向上させることが重要です。

特に要求仕様書が確定する前の見積もりでは精度のブレが生じるため、ユーザが認識していない要件が潜んでいる場合は別途追加見積の必要性が出てきます。

*FP法には様々な団体が存在します。*FP法は、国際標準化機構ISO（International Organization for Standardization）、および国際電気標準会議IEC（International Electrotechnical Commission）によって認定されています。その標準化の中でFP法は、以下のそれぞれの方法が各実装グループによって定義されています。

・FiSMA（FiSMA 1.1 functional size measurement method）

・IFPUG（IFPUG functional size measurement method）

・Mark-II（Ml II Function Point Analysis）

・Nesma（Nesma functional size measurement method）

・COSMIC（The Common Software Measurement International Consortium）

・OMG（Object Management Group Automated Function Points）

### 日本のFP法のユーザ団体はJFPUG

IFPUG（International Function Point User Group）は米国にあり、Allan Albrecht氏の考え方を引き継いでFP法を発展させています。*そのガイドラインはISOで標準化されています。*海外支部も多くあり、日本ではJFPUG（Japan Function Point User Group）として活動を行っています。

参考：[JFPUG](http://www.jfpug.gr.jp/introduction/top.htm)

### その他のソフトウェア開発見積もりモデルは？

COCOMO（Constructive Cost Model）は1981年に提唱されたものです。COCOMOでは、開発するソフトウェアの規模が大きいほどより多くの工数が発生するという考え方に基づいています。具体的には、開発するソフトウェアの想定ソースコード行数に、ソフトウェアの規模を表す係数を掛けて開発工数を算定します。

次にLOC（Lines Of Code）について紹介していきます。LOCは長年にわたり見積もりに用いられていた手法で、「ステップ数による見積もり」と言えばピンとくる人も多いでしょう。つまりプログラムソースの行数に比例して工数を求めるものです。

こちらは長きにわたり利用されていますが、空行やコメント行を除外したりする作業の誤差や、難易度がステップ数に反映されないので誤差のブレ幅が大きいものです。そのため、**大規模システムでは客観的な指標としては適さないとされています。**

## FP法のスキルを高めるには？

FP法はプロジェクト開発では標準的に活用されています。そのため、実際のプロジェクトで実務能力を高めることが可能です。それ以外にも市販の書籍が数多く出版されており、ITエンジニアのプロジェクト教育としてeラーニングが各社より提供されています。したがって、最初のステップとしては机上で知識を高めて実践する方法がおすすめです。

先に述べたIFPUG並びにJFPUGより、FP法に関連するドキュメントを入手することができます。その他、**情報処理推進機構（IPA）により2006年「ソフトウェア開発見積りガイドブック」が発行されています。**各種見積もり手法の紹介と実例が記載されており、PDF形式でダウンロードが可能です。

これらのツールを活用してFP法を学ぶことができます。

参考：[情報処理推進機構(IPA) ソフトウェア開発見積りガイドブック](http://www.ipa.go.jp/sec/publish/tn05-001.html)

**平成26年において総務省より「政府情報システムの整備及び管理に関する標準ガイドライン」が発行されています。**事業者からの経費の見積もりは、原則としてファンクションポイントの見積もり並びにその見積もり根拠を提示することが求められています。政府系システムに関連する方は一読されることをおすすめします。

参考：[政府情報システムの整備及び管理に関する標準ガイドライン](https://cio.go.jp/node/1426)

## FP法を活用してプロジェクトの見積もり手法をマスターしよう

FP法はプロジェクトの見積もり手法として広く浸透しています。FP法が効果的なのは要求仕様書が確定してからの各工程なため、まずは市販の書籍やeラーニング等で学習し、実際のプロジェクトで実践してみましょう。**プロジェクトでのソフトウェア開発の品質評価に活用できるため、全体のレビューや費用対効果の評価にも活用できます。**

ぜひとも様々なプロジェクト工程で活用してマスターしてくださいね。

FP法は米国で考案され、40年以上の活用実績がある手法です。その目的は誰が見積もりの計測を行っても同じ結果が得られることです。FP法を効果的に活用することでプロジェクトの見積もり品質が高められます。ぜひ実際のプロジェクトで実践してみましょう。

FP法は米国で考案されたソフトウェア開発の生産性を測定するための手法です

FP法ではシステム規模の見積もりが誰でも同等に実施できるため広く用いられています

FP法は工数の見積もりだけでなく、プロジェクトサイクル全般の評価として活用可能です

FP法とは？ソフトウェア開発の見積もり手法を解説します！

FP法の記事（1ページ目）