機能の数と複雑さからソフトウェアの規模を見積もる手法。
ファンクションポイント法とは、ユーザーから見た機能の数と、その複雑さからソフトウェアの規模を見積もる手法です。「ファンクション」は機能、「ポイント」は点数の意味で、機能を点数化して合計します。
身近な例で考えると、引っ越しの料金見積もりに似ています。荷物を「段ボール何箱・大型家具何点」と種類ごとに数え、それぞれの重さや運びにくさ(=重み)を考えて料金を出します。コードの行数ではなく「何ができるシステムか」で測るのがポイントです。
上のツールで▶ボタンを押すと、機能を5種類に分類し、機能数に重みを掛けて合計し、システム全体のファンクションポイントを算出する流れを確認できます。
FPは次の手順で求めます。コードを書かなくても、システムの設計(どんな画面・データがあるか)が決まっていれば計算できます。
・① 機能を5種類に分類:外部入力(EI)・外部出力(EO)・外部照会(EQ)・内部論理ファイル(ILF)・外部インタフェースファイル(EIF)に分けて、それぞれの個数を数える
・② 重みをつける:機能ごとの複雑さに応じて点数(重み)を割り当てる
・③ 機能数 × 重みを合計:各種類の「機能数 × 重み」を足し合わせて未調整FPを出す
・④ 補正をかける:性能やセキュリティなどの影響度から補正係数を掛け、最終FPを出す(参考)
上のツールの例では、外部入力が 3件 × 重み4 = 12点、内部論理ファイルが 2件 × 重み10 = 20点…というように計算し、5種類を足して合計57FPになりました。求めたFPに「1FPあたり何人日かかるか」を掛ければ、開発工数の見積もりに使えます。
ファンクションポイント法には、コード行数で測るLOC法(=プログラムの行数で規模を見積もる方法)にはない、いくつかの利点があります。
・早い段階で見積もれる:コードを書く前の設計段階でも、機能が分かれば計算できる
・言語に依存しない:行数と違い、どのプログラミング言語で作っても同じ機能なら同じFPになる
・システム同士を比較しやすい:言語や作り方が違うシステムでも、規模を同じ物差しで比べられる
・ユーザーが理解しやすい:「機能の数」という、技術者でなくても分かる単位で説明できる
一方で、機能の分類や重みづけに担当者の判断が入るため、人によって結果が多少ぶれることがあります。それでも「機能の数で規模を測る」という考え方は分かりやすく、見積もりの世界で広く使われています。
FP法ではシステムの機能を5種類に分類します。最初は名前が似ていて混乱しがちですが、「外部とのやり取り系(3種)」と「データ保管系(2種)」の2グループに分けると整理しやすいです。
外部とのやり取り系(青)の3種:
・EI(外部入力):ユーザーや外部システムからデータを受け取る機能。例:検索フォームへの入力、ファイルのアップロード
・EO(外部出力):システムが計算や加工をしてデータを外に出す機能。例:集計レポートの出力、グラフの生成
・EQ(外部照会):データをそのまま(加工なしで)参照・表示する機能。例:会員情報の検索表示
データ保管系(紫)の2種:
・ILF(内部論理ファイル):システムが自分で管理・更新するデータの塊(=データベースのテーブルに相当)。例:顧客マスタ、注文テーブル
・EIF(外部インタフェースファイル):外部システムが管理するデータで、自システムが参照だけするもの。例:別システムの商品カタログを参照する
LOC法(=Lines of Code法:プログラムの行数で規模を測る方法)は昔から使われている見積もり手法ですが、コードが完成しないと正確な行数が分からないという根本的な問題があります。開発の最初に見積もりをしたいときに使えません。
また、同じ機能を作ってもプログラミング言語によって行数が大きく変わります。JavaとPythonでは同じ処理でもコード量が数倍違うことがあるため、LOCで比べると言語が変わるたびに基準がずれてしまいます。
FP法はこれらの問題を解決します。
・設計段階から使える:「どんな機能を作るか」が決まれば計算できるので、開発を始める前に見積もりができる
・言語に依存しない:「入力フォームが3個ある」という機能の数は、どの言語で作っても変わらない
・顧客に説明しやすい:「行数」よりも「機能の数」の方が、技術者でない顧客にも伝わりやすい
ただしFP法にも弱点はあります。機能を5種類に分類し重みを判断するのに経験と知識が必要で、担当者が変わると結果が多少ぶれます。どちらの手法も一長一短あり、プロジェクトの性格に合わせて使い分けるのが現実的なやり方です。