ファンクションポイント法(FP法)とは FP法の研修を受けてきました

  • 2019年8月28日
  • 仕事
  • 48view

先日、ファンクションポイント法(以下、FP法)を学ぶ研修に行ってきました。

どんな企業でも、システム開発における見積もりの精度向上は必須ですね。

特に私はシステムの発注側なので、見積もり依頼を出して正確な見積もりであるのか、それとも、盛った見積もりになっているのかをしっかりと判断しなくてはいけません。

今回の記事では、FP法とはどのような見積もり手法なのかをご紹介するとともに、研修で私が講師の方に常々疑問に思っていた見積もりの質問の回答をご紹介したいと思います。

FP法とは

FP法は簡単に紹介すると以下の通りです。

機能の大きさ(function)に注目した見積もり方法で、規模を算出する見積もり方法のこと。ある程度、要件の固まってきた要件定義フェーズなどで使用される。

要は、開発するシステムでのデータの入力処理や出力処理、参照処理などの機能に対してファンクションポイント値(以下、FP値)を規模として見積もる手法です。

ユーザからすると、どのような入力をしてどのような結果を出力したいのかという機能をFP値として算出します。そのため、ユーザ自身が要望した入出力項目が見積もりとして算出されるため、見積もりの納得感が出ます。

ただ、あくまでユーザから見える範囲の見積もりになります。そのため、内部ロジックが複雑な場合等、FP法ではうまく見積もれないケースも存在します。

例えば、データの抽出ボタンしかないのですが、出力するまでの集計に膨大な計算を要するなどの場合は、この計算ロジックはユーザからは見えないため、ステップ数は膨大になりますがFP値としてはそこまで大きくならない恐れがあります。

このような場合、FP値が少ないにも関わらず見積額が大きくなり、見積もりの納得感も出なくなってしまいます。

そのため、FP法を用いて見積もりをするかは、開発対象のシステム特性を鑑みて決定する必要があります。

FP法の手順

FP法は以下の手順で実施します。

  • 開発プロジェクトの内容把握(新規開発、既存機能改修)
  • 見積もり対象範囲の特定
  • データファンクションを計算(①)
  • トランザクションファンクションを計算(②)
  • 総FP値を算出(①+②)
  • 調整係数の計算(実施しない場合もあり)

開発プロジェクトの内容把握

開発対象のシステムが新規開発なのか、それとも現在稼働している既存システムの改修なのかを判断します。

これは、新規開発なのか既存システム改修なのかによってFP値の算出方法が異なるためです。

これは、特に難しく考えずにできるのではないかと思います。

見積もり対象範囲の特定

これは、業務フローや要件一覧などをもとに今回の開発プロジェクトがどこまでの開発をするかを特定します。

例えば、既存機能の改修の場合、影響のある機能は何か、何の業務に変更が入るかを特定します。

このため、ある程度、要件が固まっていないとこの作業はできません。そのため、初期のシステム化の企画フェーズなどではFP法を使用するのは困難です。

データファンクションを計算(①)

アプリケーションがアクセスするファイルを対象に計算します。また、そのファイル内のユーザが意識するデータ項目数も計算します。

その結果、アプリケーションの複雑度を算出しFP値を求めます。

ファイルの種類

内部論理ファイル(ILF):アプリケーションにより追加・変更・削除されるファイル

外部IFファイル (EIF):アプリケーションにより参照されるファイル

データタイプ

データエレメントタイプ(DET):レコード内の項目数(繰り返しを含まない)

レコードエレメントタイプ(RET):ILFやEIFのデータのサブグループの数

※両タイプともにユーザが認識できるものに限ります。

トランザクションファンクションを計算(②)

アプリケーションの境界ごとに要素処理の機能のFP値を計算します。

要素処理

外部入力(EI):外部からデータが入力され、追加・更新・削除する処理

外部出力(EO):データを追加・更新・削除又は計算し外部へ出力する処理

外部紹介(EQ):データを外部へ出力する処理※計算等はしない

データタイプ

データエレメントタイプ(DET):要素処理内で参照、更新するデータ項目数

ファイルタイプリファレンス(FTR):アプリケーションで使用するファイル数

総FP値を算出

データファンクション、トランザクションファンクションで計算したFP値を合算し、総FP値を算出します。

講師の方との質疑応答

私が疑問に思い質問した内容を紹介します。

FP法により開発規模を算出することはできますが、その後、生産性をもとに工数・金額にしていくことになると思います。その際の生産性の求め方はどのようなものがありますでしょうか。1FP当たりの生産性の求め方など。
過去の開発実績や類似のプロジェクト実績をもとに1FP当たりの生産性を算出してください。この点については、引き続き精緻な見積もりができるように開発を完了した後は振り返りを行ってください。それが未来のプロジェクトへの橋渡しになります。
FP法はユーザ目線での見積もり手法と理解しました。ただ、そうなった場合、内部ロジックが複雑ではあるもののユーザが見える(意識する)画面は単純なシステム、例えばDWHなどの場合はFP法で見積もるのはできないものでしょうか。
FP法の限界であると考えられます。内部ロジックが複雑なシステムにはFP法を適用するのは難しいと言わざるを得ません。
FP法の話ではありませんが、現在の契約の主流としては、まずは超概算見積もりで要件定義など上流工程の契約を実施し要件が詳細になってきた段階でFP法などを使用して詳細な見積もりを実施し契約変更などをするものなのか。
IPAでも推奨されているが、まずは準委任契約で上流工程の契約をし設計工程以降くらいから請負契約、ユーザの受入テストや検収テストなどでは再度、準委任契約にすることが良いとされています。ただし、現実的には最初から一括で請負契約ということも多いのが現実です。

最後に

いかがでしたでしょうか。

FP法も良いところや適用が難しいところがありました。

また、現在の契約形態も聞いてみましたがまだ、一括請負契約というものも多いみたいです。

私も開発側でユーザと要件をまとめて発注していましたが、一括請負契約というものはかなりリスキーだと考えています。

楽ではあるのですが。

今後は、せめて要件定義工程までは準委任契約で実施していくことが良いと考えています。皆様はどう思われますか?

最新情報をチェックしよう!