ソフトウェア開発を行う際には、詳細な開発作業、予算、スケジュールを規定する開発管理計画の作成が必要になります。きっちりとした開発管理計画を作成するためには、開発すべきソフトウェアの規模や開発に必要な工数（コスト）の見積りが重要です。実際に、ソフトウェア開発が失敗する要因の一つとして、見積りが不十分であったために納期の超過や赤字といった問題が発生するということがよく知られています。

開発の規模を評価するための有効な手法として、ファンクションポイント（以降FP）法があります。FPの歴史は古く、1979年にIBMのA. J. Albrechtによってその概念が提案されました。簡単に言うと、FPはこれから開発するソフトウェアがユーザに提供する“機能”に対して、その処理内容の複雑さなどから点数を付けていき、すべての機能の点数を合計したものです。この値に基いて、開発に必要な期間や工数を見積ります。例えば、下表によると受託開発ソフトウェアであれば、約22ヶ月必要となります。

FPの値は規則にしたがって計測される値であり、誰が計測しても同じ値が得られるということと機能仕様にだけ依存するため開発環境や開発言語などの技術要件に左右されないという特徴があります。機能仕様だけに依存するので、品質や性能といった点は考慮されていません。例えば、家を購入する場合、土地と建物を購入することになりますが、価格的には土地の価格が大勢を占めることが多いと思います。FPもソフトウェアを購入する場合は、それが提供する機能がユーザにとって重要であるという観点で、ソフトウェアの規模を計測しています。

平成26年12月に日本政府におけるITガバナンス強化のため、情報システム調達やプロジェクト管理に関する共通ルールとして「政府情報システムの整備及び管理に関する標準ガイドライン」が決定しました。このガイドラインでは、要求内容に設計又は開発に関する工程が含まれる場合には、原則として、ファンクションポイントの見積りとその根拠を提示することが求められています。

FPは非常に有用であると言われてきていますが、日本では未だ十分に普及しているという状況ではありません。その原因として、以下の3点が挙げられています。

1. 見積りのための基礎データが必要

   これから開発するソフトウェアのFPがうまく算出できたとしても、FPを工数等に変換する必要があります。そのためには、過去プロジェクトのFP値と工数等の実績データが必要になります。一方、FPは主に設計段階で計測されますが、実装以降で仕様が変更される場合があります。結果として最終的な機能はソースコードを調べないといけません。ソースコードから機能を計測するのは非常に手間がかかります。

2. 計測者の判断による誤差

   FPは計測ルールに従って計測されるので、誰が計測しても同じ値が得られると上述しましたが、実際に計測者の判断が入る部分が存在します。同じソフトウェアのFPは計測をする場合、同一組織の計測者であっても30％程度、熟練者同士であっても10%程度の誤差がでると言われています。

3. 導入教育が必要

   当然ですが、FP計測や見積りのための教育が必要です。

当研究室では、上記の問題に対して、FPを用いた見積り支援ツールや初心者向けのFP計測支援ツールの開発を企業との共同研究を通じて実施してきています。