一番簡単なFP法を利用した規模見積りのやり方

1. 目的・目標

1-1. できるだけ簡単に

FP法というと「難しい」というイメージを持つのではないでしょうか？

この記事ではFP法の手法のうちIFPUG法・NESMA概算法をベースにかなり簡略化しています。

IPAから出されているFP法の結果と比較すると数値が異なるのはご容赦してください。

誰でも簡単に規模を算出できて、その会社・その組織でのモノサシ（基準）を作るのを目的としています

1-2. 本質的にシステム開発の見積りはできない

システム開発において「見積りはできない」むしろ「見積りをして仕様・金額・納期を固定すべきではない」と考えています。

笑い話のようですが、KKD（経験・勘・度胸）が備わった昭和なおじさんの「たぶんこの金額」は割と当たります。

また、見積りをすると「仕様」「金額」「納期」が固定化されると、開発に柔軟性がなくなり顧客価値が失われる可能性が高くなり、開発する側も「仕様」「金額」「納期」に縛りができつらくなります。

1-3. モノサシ（基準）としてFPを利用する

FPを何に利用するのでしょうか？

FPによって開発規模がわかるので、モノサシ（基準）として使います。例えばテストケースの数を算出し、FPで割り、1FPあたりのテストケース数を求めます。システム間・プロダクト間・プロジェクト間・画面間・機能間で相対比較することが可能です。

また、開発規模がわかると計画が立てやすくなります。

アジャイルでイテレーションを組むときにタスクを分解しますが、そのタスクの単位の洗い出しに利用できます。

2. 一番簡単なFP算出の仕方

ここで紹介するやり方はIFPUG法・NESMA概算法をベースにし、かなり簡略化しています。

2-1. 画面・機能一覧を作成

まずは画面・機能一覧を作成します。粒度は単純なMVCの場合プログラム視点で考えるとコントローラに記載しているアクション単位とし、バックエンドがAPI化されており、コンポーネント思考で設計されている場合は画面というよりコンポーネント（画面のパーツ）単位の方がより良いです。

2-2. 画面・機能を分類

画面・機能を次のように分類します。例・DBにアクセスする場合を想定してSQL、APIでアクセスする場合を想定してCRUD操作、概算値、例を記載しました。

概算FPの根拠は「3. ざっくりしたFP法　IFPUG法とNESMA概算法」で説明します。

上記分類を画面・機能一覧に当てはめます。

画面・機能を分類するだけで規模の見積りができます。

2-3. そのFPって合っているの？

「ログインフォームと会員フォームが同じ数値だけど同じ工数でできるの？」

という疑問がわくと思います。

ログインフォームは「ID」と「パスワード」の２項目ですが、会員は「名前」「住所」「電話番号」と項目が多くなるはずです。

確かに画面・機能単位だとFPが合っていません。

目的がシステム全体・プロダクト全体の規模見積りだとすると、平均化されるので、誤差は±10%ほどになります。

上記は数千万規模のプロジェクトを20プロジェクト以上分析した結果です。

画面・機能単位で精度を上げたい場合は次の「3. ざっくりしたIFPUG法」を参照してください。

3. ざっくりしたFP法　IFPUG法とNESMA概算法

ここではざっくりとIFPUG法を解説します。要点のみをまとめていると捉えてください。

3-1. トランザクションファンクション

トランザクションファンクションは一言でまとめると「画面視点」で数値を定義します。

例えば、機能・画面が対象となります。

IFPUG法では「EI」「EO」「EQ」と3つのカテゴリに分けます。

3-2. データファンクション

データファンクションは一言でまとめると「データ視点」で数値を定義します。

例えばデータベースのテーブルやAPIが対象となります。

IFPUG法では「EIF」「ILF」と2つのカテゴリに分けます。

3-3. NESMA概算法

NESMA概算法ではEI, EO, EQ, EIF, ILFの値を固定します。

下記の表の通りです。

統計によるとNESMA概算法の誤差は±20%以内だそうです。

「2. 一番簡単なFP算出の仕方」の例で提示したFPはこのNESMA概算法から算出しています。

上記にトランザクションファンクションとデータファンクションを適用します。

4. 詳細なFP法

これまでのFP法は画面の分類でFPが決まります。画面ごとの重みづけはできませんでした。

この章ではトランザクションファンクション（EI, EO, EQ）とデータファンクション（EIF, ILF）ごとに値を決める定義を紹介します。

トランザクションファンクション

トランザクションファンクションを詳細見積りをする際の定義は下記の通りです。

画面・機能の種別

EI：登録・更新・削除を行う

EO：ファイル出力をする

EQ：一覧・詳細を表示する

トランザクションファンクションを決める際の要素

項目数が増えれば、複雑さが増すという考え方をしています。

DET：画面に表示する項目数

FTR：テーブル数、API数

トランザクションファンクション評価マトリクス

トランザクションファンクション評価手順

1. 画面・機能が「EI」「EO」「EQ」のいずれかに分類

2. 画面項目数を数える

3. 関連するデータベースのテーブル数かAPIの本数を数える

4. マトリクスに当てはめ「L」「A」「H」のいずれかに評価

5. 「EI」「EO」「EQ」と「L」「A」「H」の組み合わせでFPを評価

データファンクション

データファンクションの詳細見積りをする際の定義は下記の通りです。

データの種別

EIF：データを取得する。SQLでいうSELECT、CRUDでいうREAD

ILF：登録・更新・削除を行う。SQLでいうINSERT, UPDATE, DELETE、CRUDでいうCREATE, UPDATE, DELETE

データファンクションを決める際の要素

SQLの複雑さ（WHERE句など）はDETやRETの数に比例するという考え方をしています。

DET：データ項目（カラム）数、APIの要素数

RET：JOIN,（サブクエリを含む）、APIの本数

データファンクション評価マトリクス

データファンクション評価手順

1. データベーステーブルのカラム数かAPIの要素数を数える

2. 関連するデータベースのJOIN数（サブクエリ）かAPIの本数を数える

3. マトリクスに当てはめ「L」「A」「H」のいずれかに評価

4. 「EIF」「ILF」と「L」「A」「H」の組み合わせでFPを評価

5. 見積り

最後に、FP法を用いた見積り方法を紹介します。

式

次の式で工数を算出します。

FP生産性

FP生産性は0.65 〜 1.35の間の数値をとります。システム開発が難しければ生産性が下がり、相対的にFPが増えます。また、システム開発が難しくなければ生産性が上がり、相対的にFPが減ります。

生産性が上がり下がりする要素の例

具体的な数値は会社や組織によって異なるので記載できません。過去案件などから算出してください。

・API並行開発 ：生産性が下がる

・短納期 ：生産性が下がる

・リファクタリングをしている：生産性が上がる

・ユニットテストがある：生産性が上がる

係数

係数が一番重要ですが、会社・組織によって異なるので記載できません。過去案件などから算出してください。

複数のプロジェクトやプロダクトの係数を比較することで、コスト管理が適切かを相対比較できます。

コスト算出

工数に単価を掛ければコストを算出することができます。