（2022.3.14 記）
システム開発において、その開発にかかる工数を割出す手法がいくつか存在します。
その中で私がよく利用している手法が「簡易FP法」です。
FPはFunctionPointの略で、端的に説明すると、画面に設置する項目数とデータテーブルの項目数と依存度によって開発の難易度を求め、この難易度を用いて簡易的に工数を割出すという手法です。
要件定義後の概算見積もりや、下請けプログラマーから貰う見積もりの妥当性を求める際に効果が発揮するのかなと思っています。
（※特性を理解したうえで使用しないと効果が薄れます）
手法のロジック自体は色々な記事でまとめてあるのですが、それをシート化（Excel化）したものが存在しない（見つからない）ので、自作した際に忘備録として記事に残そうと思った次第です。
下記よりダウンロードできますので、シートを自分で作るのは面倒だなっていう人はご自由にお使いください。
０．簡易FP法とは
■FP（FunctionPoint）
・簡単に言うと、画面を構成するラベルを含む項目数のこと
（例：下図なら、項目数＝１０ となる
※ラベルは項目数に入れずに算出する方法もあります
■算出手順
①：画面項目数をもとに難易度を求める
②：対象画面に関係するデータテーブル数をもとに難易度を求める
③：画面ごとに①、②を求め、①、②をもとに未調整工数を求める
④：外部要件（外部設計要件）より調整係数を求める
⑤：③、④より調整後工数を求めて完了
※必要に応じて更に個別係数をかけたり、調整工数で増減させる
下記項目より順次説明しますが、同様の内容がDLできるExcel表にも記載しています。
■特性
・画面の項目数、テーブルの項目数、外部要件が必要なため、要件定義が終わっている必要がある
・システム修正には適応が難しい（係数で調整）
・概算見積もり、下請け見積もりの妥当性、上流から請けた工期や費用の妥当性を計ることが可能
・あくまでも簡易見積もり手法なので、これで求めて良いかは会社による
１．データファンクションの計測
★対象画面ごとに、下記を求める
①まずは用語説明
・DET(Date Element Type)：繰り返しを含まないデータ項目
・RET(Recode Element Type)：繰り返しのあるデータ項目（リスト型式）
・ILF(Internal Logical File):追加・更新・削除など操作対象となるファイル
・EIF(External Interface File):参照されるファイル（Selectのみ）
②画面項目を数え、DET、RETに対応する項目がいくつあるか求める
（例：ログイン画面 ⇒ DET＝10、RET＝0
（例：一覧表 ⇒ DET＝10、RET＝5
③マトリックス表からDET、RET数に対応する難易度を求める
| 1～19 DET | 20～50 DET | 51以上DET | |
| 1 RET | Low | Low | Average |
| 2～5 RET | Low | Average | Hight |
| 6以上 RET | Average | Hight | Hight |
（例：ログイン画面 ⇒ Low、 一覧表 ⇒ Low
④対象画面のデータテーブルに対する操作種別（ILF、EIF）を選択
（「SELECT」のみ ⇒ EIF、 それ以外 ⇒ ILF
と考えると分かり易い）
（例：ログイン画面 ⇒ EIF、 一覧表 ⇒ EIF
⑤マトリックス表から項番１の工数を求める
| Low | Average | Hight | |
| ILF | 7 | 10 | 15 |
| EIF | 5 | 7 | 10 |
（例：ログイン画面 ⇒ 5、 一覧表 ⇒ 5
２．トランザクショナルファイルの計測
★対象画面ごとに、下記を求める
①まずは用語説明
・DET(Date Element Type)：アプリケーション境界を出入りする繰り返しを含まないデータ項目（画面遷移数）
・FTR(File Type Refarence)：参照更新などアクセスするファイル数（データテーブル数）
・EI(External Input):データを受け取る処理(ILFに対してデータの追加・変更・削除を行う)
・EO(External Output):データを外部へ出力する処理(ILF、EIFから参照したデータを加工してから出力)
・EQ(External inQuiry):データを外部へ出力する処理(ILF、EIFから参照したデータを加工しないで出力)
②対象画面について、画面遷移数（DET）、アクセスするデータテーブル数（FTR）を求める
（例：ログイン画面 ⇒ DET=1（メニュー画面）、FTR＝1（ユーザマスタ）
（例：一覧表 ⇒ DET＝0、FTR＝3（備品マスタ、倉庫マスタ、在庫トラン）
③マトリックス表からDET、FTR数に対応する難易度を求める
| 1～4 DET | 5～15 DET | 16以上DET | |
| 0～1 FTR | Low | Low | Average |
| 2 FTR | Low | Average | Hight |
| 3以上FTRT | Average | Hight | Hight |
（例：ログイン画面 ⇒ Low、 一覧表 ⇒ Average
④対象画面のデータテーブルに対する操作種別（EI、EO、EQ）を選択する
（「SELECT」のみでデータ加工あり ⇒ EO、 加工なし ⇒ EQ
それ以外 ⇒ EI
とすると分かり易い）
（例：ログイン画面 ⇒ EQ、 一覧表 ⇒ EO
⑤マトリックス表から項番２の工数を求める
| Low | Average | Hight | |
| EI | 3 | 4 | 6 |
| EO | 4 | 5 | 7 |
| EQ | 3 | 4 | 6 |
（例：ログイン画面 ⇒ 3、 一覧表 ⇒ 5
３．未調整ファンクションポイント（UFP：Unajusted Function Point）の計算
UFP ＝ SUM（項番１）＋SUM（項番２）
（例：UFP ＝ （5＋5）＋（3＋5） ＝ 18（人日）
４．調整係数（VAF：Value Adjustment Factor）の計算
①TDI = 以下14項目の評価点を合算し、係数0.01を掛けた値
（各外部設計要件に対する難易度を０～５Pointで評価したもの、Pointが高いほど難易度が高くなる）
（例：TDI ＝ 13＊0.01 ＝ 0.13
01)Data Communication(データ通信)
（例：スタンドアローンPCで稼働を想定 ⇒ 0Point
02)Distributed Data Processing(分散処理)
（例：特に考えない想定 ⇒ 0Point
03)Performance(性能)
（例：ピーク時のレスポンスを考慮したい ⇒ 2Point
04)Heavily Used Configuration(高負荷構成)
（例：特に考慮しない ⇒ 0Point
05)Transaction Rate(トランザクション量)
（例：毎日トランザクションのピーク期間がある ⇒ 3Point
06)Online Data Entry(オンライン入力)
（例：全てのトランザクションが逐次処理 ⇒ 0Point
07)End-User Effeciency(エンドユーザ効率)
（例：一覧表の操作効率を考慮したい ⇒ 1Point
08)Online Update(オンライン更新)
（例：オンライン更新はない ⇒ 0Point
09)Complex Processing(複雑な処理)
（例：考慮しない ⇒ 0Point
10)Reusability(再利用可能性インストール)
（例：可能な限りクラス化したい ⇒ 3Point
11)Installation Ease(インストール容易性)
（例：簡単なセットアップが必要 ⇒ 1Point
12)Operational Ease(運用性)
（例：項目１，４の２つに要件が該当 ⇒ 2Point
13)Multiple Sites(複数サイト)
（例：考慮しない ⇒ 0Point
14)Facilitate Change(変更容易性)
（例：全ての機能で変更を容易にしたい ⇒ 1Point
②VAF＝TDI＋0.65 を求める
※リスクヘッジとして、この数値に更に個別調整係数を足しても良い
（例：VAF ＝ 0.13＋0.65＋0.5（リスクヘッジ） ＝ 1.28
５．調整済ファンクションポイント（AFP：Adjustet Function Point）の計算
AFP ＝ UFP＊VAP（人日）
（例：AFP ＝ 18＊1.28 ＝ 23.04（人日）
これで全体工数が算出されたので、あとは各工程での作業割合で分割すると、各工程における必要工数が求まります。
（例：
これが見積もり根拠となり、交渉材料として使われるわけです。
例えば単価が50,000（円/日）とすれば、この２機能を新規で作るのに原価として約1,150,000円かかる計算となります。（売価は150万くらいかな？思ったより高いな・・・）
ただ実際、ST～OT工程は規模の大きさにLog比例していくので、UI～ITまで計算し、ST、OTは別途見積もるほうが多いです。
※これはあくまでも新規開発の例です。修正等やシステムの利用規模に応じて調整係数を色々弄る必要があります。
６．最後に（リアルな使い方など）
リアルな使い方として・・・
例えば下請けにPS～PT行程を割り振った際、貰った見積もり工数が妥当かどうか確かめる際に利用します。
上振れ、下振れしていれば認識祖語があるとしてお互いに打合せし、再見積もりとなる感じです。
費用感としては、これに単価を掛ければ算出できるため、ユーザの費用感に合うかどうかの確認や、費用感に合わないなら作業範囲を削ってどこまでコストダウンが計れるか見ることにも使えます。
例からすると・・・
自社開発ではトータル約120万となっていますが、これがPG～PT行程を3（万/日）の下請けのプログラマーに依頼すれば、ザル計算で原価約80～90万までコストカットが可能になるわけです。
逆に、費用感が合えば、その浮いた20～30万は売価で26～40万となり、その分は追加利益となるわけですね。
逆にその分値引きしてあげることもできます。
この例ではリスクヘッジを高く設けているため、開発体制が万全だったり、リスク要素が少ないと判断した際はその個別係数を小さく調整して金額感とリスクを天秤にかけていく流れとなります。
それでも合わなければテスト工程をお客様に委任するとか・・・
プロマネはこれで頭を悩ませている感じ・・・はぁ・・・
以上。
コメント