要件モデルから「実装可能な精度」で見積もりを出す

RDRAの要件モデルから、定量的にソフトウェア開発の工数・工期・コストを見積もる方法を解説します。SFP（Simple Function Point）法とRDRAモデルを組み合わせることで、要件定義の早い段階で概算見積もりを算出できます。

本記事では、SFP法の理論的背景だけでなく、RDRAのBUCシート・情報シートからEP/LFを数える際の補正ルール（CRUD統合画面やダッシュボードの扱い）、IPA/JUAS統計データを用いたレンジ見積もり、妥当性検証のチェックポイントまで、実務で判断に迷いやすい箇所を重点的に整理しています。

SFP法の仕組み

SFP法とは

SFP（Simple Function Point）法は、ソフトウェアの機能規模を2つの要素だけで測定する簡易手法です。IFPUG FPAから複雑度判定を省略し、迅速な規模算出を実現します。

項目	内容
提唱者	Roberto Meli（2010年設計、2011年SMEF2011で発表）
標準化	2019年にIFPUGが公式取得。公開確認済みの最新版は SFP v2.1（2021年10月）
ISO準拠	ISO/IEC 14143-1（機能規模測定法の定義）に準拠

計算式

SFPの計算式は以下のとおりです。

Size[SFP] = 4.6 × EP数 + 7.0 × LF数

要素	説明
EP（Elementary Process）	ユーザーまたは外部システムとのやりとりを伴う処理の最小単位。IFPUG FPAの EI/EO/EQ の区別を省略し一括で扱う。重み 4.6
LF（Logical File）	システムが保持する論理的なデータグループ。IFPUG FPAの ILF/EIF の区別を省略し一括で扱う。重み 7.0

重み付け値（4.6, 7.0）は、ISBSGの大規模データセットから経験的に導出されています。SFP値がIFPUG FPAの未調整FP（UFP）と平均的に一致するよう設計されています。

IFPUG FPAとの差異

SFPが省略する工程は以下の3つです。

工程	IFPUG FPA	SFP
データ機能の分類（ILF/EIF）	必要	省略（LFに統合）
トランザクションの分類（EI/EO/EQ）	必要	省略（EPに統合）
複雑度判定（DET/RET/FTR → Low/Average/High）	必要	省略（固定重みで代替）

IFPUG FPAでは機能種別×複雑度で15通りの重み（3〜15）を使います。SFPではEP=4.6、LF=7.0の2通りのみです。

精度の実証データ

研究	データセット	SFP-UFP換算係数	平均相対誤差
Meli, 2011	ISBSG 768PJ	UFP = 1.0005 × SFP	約12%
Lavazza & Meli, 2014	ISBSG 766件	SFP = 0.998 × UFP	約12%
多データセット検証, 2017	7データセット	k = 0.957〜1.221	データセット依存

工数見積もりモデルの精度は、SFPベースとUFPベースで統計的に有意な差がありません（符号検定）。ただし換算係数はデータセット依存で k = 0.957〜1.221 の振れ幅があります。平均的にはSFP ≒ UFP として扱えますが、適用する案件群の傾向次第で誤差が±20%程度まで広がる点に留意してください。IFPUG FPの生産性データをSFPに適用する場合は、自社の実績データで校正することを推奨します。

類似手法との精度比較

手法	UFPとの平均誤差	必要な識別	計測の速さ
SFP	約12%	EP/LFの2種類	非常に速い
NESMA Indicative	約16.3%	ILF/EIFの2種類	最も速い
NESMA Estimated	約1.5%	ILF/EIF/EI/EO/EQの5種類	中程度
IFPUG FPA Detailed	基準（0%）	5種類＋複雑度判定	遅い

SFPはNESMA Indicativeに近い手軽さで、より高い精度を達成します。

RDRAモデルからSFPへのマッピング

SFP法の計算式が分かったところで、RDRAの成果物からEP/LFをどう数えるかを見ていきます。

基本マッピングルール

RDRAのシステム境界レイヤーと情報モデルからEP/LFを数えます。

RDRAの成果物	対象要素	SFP要素	重み	カウント方法
BUCシート	画面（UI/帳票）	EP	4.6	画面・帳票の数をカウント
BUCシート	イベント（外部システムI/F）	EP	4.6	外部システムとのインタフェースの数をカウント
BUCシート	タイマー（定時バッチ）	EP	4.6	定時実行される処理の数をカウント
情報シート	情報（データエンティティ）	LF	7.0	システムが管理する情報の数をカウント

EPのカウント手順

Step 1: BUCシートからシステム境界要素を抽出する

RDRAのBUCシートは「業務 → BUC → アクティビティ → UC」の階層構造を持ちます。UCに紐づく以下の要素がEPの候補です。

業務: 受注管理
  BUC: 受注を登録する
    アクティビティ: 受注情報を入力する
      UC: 受注登録
        → 画面: 受注登録画面     ← EP候補
        → 画面: 受注確認画面     ← EP候補
    アクティビティ: 在庫を確認する
      UC: 在庫照会
        → 画面: 在庫照会画面     ← EP候補
        → イベント: 在庫API連携  ← EP候補
  BUC: 月次集計を行う
    アクティビティ: 月末締め処理
      UC: 月次集計
        → タイマー: 月末集計バッチ ← EP候補

Step 2: EP数を確定する

基本ルールは「画面/イベント/タイマーの数 = EP数」です。ただし以下の補正が必要です。

ケース	基本カウント	補正	理由
CRUD統合画面（一覧+登録+更新+削除が1画面）	1 EP	3〜5 EP	内部的に複数のトランザクションが存在。IFPUG FPAでは一覧=EQ、登録=EI、更新=EI、削除=EIと分けてカウント
ダッシュボード画面（複数の集計・グラフ）	1 EP	2〜5 EP	複数のデータ取得・集計処理が1画面に集約
ウィザード画面（複数ステップ）	1 EP	ステップ数分	各ステップが独立したデータ入力トランザクション
静的表示画面（ヘルプ、利用規約）	1 EP	0.5 EP（または除外）	トランザクションではなく静的コンテンツ
類似画面の繰り返し（同パターンの入力画面が多数）	N EP	N × 0.7 EP（経験則）	共通コンポーネント化で実工数が減少

補正ルールの位置づけ: CRUD統合やダッシュボードの補正は、IFPUG FPAで「一覧=EQ、登録=EI、更新=EI、削除=EI」と分けてカウントする原理を踏まえた補正です。一方、「類似画面 N×0.7」は著者の経験則であり、適用時は自社実績との整合を確認してください。

補正の判断基準は「ユーザーが認識する独立した処理がいくつあるか」です。1画面でも「検索する」「登録する」「削除する」が独立した操作であれば、3つのEPとして数えます。

重複排除ルール（二重カウント防止）

RDRAのBUCシートでは、同一の画面・API・タイマー処理が複数のUCから参照されるケースが頻出します。UC起点でEPを数えると二重カウントが発生するため、以下のルールで一意化してください。

ケース	対応
同一画面が複数UCから参照	画面IDで一意化し、1 EP として1回だけカウント
共通API・共通サービス	APIエンドポイントIDで一意化し、1 EP として1回だけカウント
同一タイマー処理が複数UCをトリガー	タイマー処理IDで一意化し、1 EP として1回だけカウント

実務のコツ: UC起点でEPを数えるのではなく、境界要素台帳（画面一覧・API一覧・タイマー一覧）を作成し、そこからカウントすると重複を防ぎやすくなります。

Step 3: EP補正値を記録する

UC	画面/イベント/タイマー	基本EP	補正理由	補正後EP
受注登録	受注登録画面	1	CRUD統合（一覧+登録+更新+削除）	4
受注登録	受注確認画面	1	単純表示	1
在庫照会	在庫照会画面	1	—	1
在庫照会	在庫API連携	1	—	1
月次集計	月末集計バッチ	1	—	1
合計		5		8

LFのカウント手順

Step 1: 情報シートからエンティティを抽出する

RDRAの情報シートに定義された「情報」がLFの候補です。情報とは「システムが管理する概念的なデータ群」を指します。

情報シートの例:
  - 顧客
  - 商品
  - 受注
  - 受注明細
  - 在庫
  - 請求
  - 入金
  - マスタ（区分値）
→ LF数 = 8

Step 2: 粒度を確認する

LF数はエンティティの分割粒度に依存します。以下の基準で統一してください。

判断基準	カウント方法	例
独立してCRUDされるデータ群	1 LF	「顧客」「商品」はそれぞれ独立に登録・更新される → 各1 LF
親子関係で常にセットで扱われる	親のみ1 LF	「受注」と「受注明細」が常にセットで登録・表示される → 1 LF
親子関係だが独立にも操作される	それぞれ1 LF	「受注」は単独で検索、「受注明細」は個別に追加・削除できる → 2 LF
区分値・コードマスタ	まとめて1 LF	都道府県コード、商品カテゴリ等の小規模マスタ群 → 合計1 LF
外部システムのデータ（参照のみ）	1 LF	外部の在庫システムから取得するデータ → 1 LF

粒度の目安は「ER図でエンティティとして独立させるかどうか」と同じ判断基準です。過度に細かく分割する必要はありません。

SFP算出の全体フロー

1. BUCシートから画面/イベント/タイマーを一覧化する
2. 各要素のEP数を確定する（補正含む）
3. 情報シートからエンティティを一覧化する
4. 各エンティティのLF数を確定する（粒度調整含む）
5. SFP = 4.6 × EP合計 + 7.0 × LF合計

計算例

■ EP一覧
  画面: 20個（うち CRUD統合画面 5個 → 5×4=20 EP、残り15個 → 15 EP）
  イベント: 8個 → 8 EP
  タイマー: 3個 → 3 EP
  EP合計 = 20 + 15 + 8 + 3 = 46 EP

■ LF一覧
  独立エンティティ: 10個
  親子統合: 2組 → 2 LF
  区分マスタ群: → 1 LF
  LF合計 = 10 + 2 + 1 = 13 LF

■ SFP算出
  SFP = 4.6 × 46 + 7.0 × 13 = 211.6 + 91.0 = 302.6 SFP

SFPから工数・工期・金額への変換

SFP値が算出できたら、次は工数・工期・金額に変換します。ここではIPA/JUASの統計データを活用します。

開発工数の算出

開発工数は以下の式で算出します。

開発工数（人月） = SFP ÷ 生産性（SFP/人月）

生産性パラメータの設定

シナリオ	推奨値（SFP/人月）	根拠
高難度（基幹系、金融、高信頼要求）	10〜15	IPA工数密度P75（9.94人月/100FP）から逆算
標準（業務系Webアプリ、Java/C#）	15〜25	IPA工数密度中央値（6.31人月/100FP）から逆算
低難度（シンプルCRUD、ローコード）	25〜40	IPA工数密度P25（3.88人月/100FP）から逆算

上記はIPAソフトウェア開発分析データ集2022の工数密度統計からの逆算参考値です。自社の過去実績データがあれば、そちらを優先してください。

レンジ見積もりの方法

ポイント見積もり（1つの値）ではなく、3値で算出します。

楽観: SFP ÷ 高生産性値（P25相当）
最頻: SFP ÷ 中央値
悲観: SFP ÷ 低生産性値（P75相当）

SFP = 302.6 の場合:

楽観: 302.6 ÷ 25 = 12.1 人月
最頻: 302.6 ÷ 16 = 18.9 人月
悲観: 302.6 ÷ 10 = 30.3 人月

→ 開発工数: 12〜30人月（最頻値 19人月）

工程別配分（ウォーターフォール）

IPA「ソフトウェアデータ白書2018-2019」中央値に基づく初期値です。

工程	比率	調整の目安
基本設計	15%	要件が複雑なら引き上げ
詳細設計	20%	—
製造（コーディング・単体テスト）	35%	技術的難易度で調整
結合テスト	15%	外部連携が多ければ引き上げ
総合テスト	15%	品質要件で調整

JUAS 2025調査では、要件定義:設計〜結合テスト:総合テスト = 15:60:25 という集約形で報告されています。

非比例工数の加算

開発規模に比例しない工数を工程ごとに加算します。この工数の見落としが見積もり失敗の主要因になります。

項目	内容	見積もり方法
基盤工数	インフラ構築、ミドルウェア設定、CI/CD	過去実績またはボトムアップ
移行工数	既存データ移行、クレンジング、検証	データ量とルール複雑度から積算
運用準備工数	マニュアル整備、監視設定、トレーニング	対象者数・ドキュメント量から積算
その他	外部機関調整、セキュリティ審査等	個別見積もり

基盤工数の見積もり

基盤工数は以下の変動要因から見積もります（数値はSI現場の経験則）。

変動要因	増減の目安
環境数（dev/stg/prod、DR環境等）	環境数 × 基本工数
インフラ種別	クラウド（IaC活用）は工数少、オンプレは工数大
CI/CDパイプライン数	パイプライン1本あたり0.5〜1人月
セキュリティ要件	監査ログ、WAF、IDS等の有無で±20〜50%

目安値: 小規模PJで開発工数の10〜15%、大規模PJで15〜25%を初期値として積み上げます。

IPA非機能要求グレードからの算出

より構造化された見積もりが必要な場合、IPAの「非機能要求グレード」を基軸にする方法があります。

カテゴリ	基盤工数に影響する代表例
可用性	HA構成、DR環境、フェイルオーバー機構
性能・拡張性	オートスケーリング、ロードバランサ、キャッシュ
運用・保守性	監視、ログ集約、アラート、CI/CD
移行性	並行稼働、段階移行の環境準備
セキュリティ	WAF、IDS、暗号化、監査ログ
システム環境・エコロジー	複数環境（dev/stg/prod/DR）

各カテゴリのグレード（Lv1〜Lv3）に応じて係数を掛けて積み上げます。

グレード	係数の目安
Lv1（簡易）	1.0
Lv2（標準）	1.5〜2.0
Lv3（高度）	2.5〜4.0

自社・クラウドベンダー別にカテゴリ別の基本工数テーブルを整備し、過去実績で校正すると精度が向上します。IaC資産が整備されている場合は係数を下方修正してください。

移行工数の見積もり

移行工数は「データ量 × 変換ルール複雑度 × 検証密度」で決まります。

変動要因	見積もりの観点
移行対象テーブル数	テーブル数 × 単価工数（0.1〜0.5人月/テーブル）
変換ロジック複雑度	1:1マッピング（軽）、変換・集約（中）、複数ソース統合（重）
データ品質	クレンジング要否、欠損データの扱い
データ量	リハーサル回数、移行実行時間
検証要件	全件検証 vs サンプル検証

目安: テーブル数を基本単位とし、変換ロジックの複雑度を1.0（軽）/1.5（中）/2.5（重）で係数補正します。クレンジングが必要な場合はさらに×1.3〜1.5します。

運用準備工数の見積もり

運用準備工数は以下の要素を積み上げます。

項目	見積もりの観点
マニュアル・運用手順書	ドキュメント本数 × 作成工数（0.2〜0.5人月/本）
監視設定	メトリクス数、アラート定義数、ダッシュボード数
障害対応訓練	訓練シナリオ数 × 実施工数
エンドユーザー教育	対象人数 × 研修時間 + 教材作成工数
運用引き継ぎ	並行稼働期間、運用チーム人数

目安: 開発工数の5〜15%を初期値とし、引き継ぎ対象の複雑度で調整します。

非比例工数の合計目安

以下の数値は、複数のSIプロジェクトの経験則です。自社実績がある場合は、必ずそちらを優先してください。

PJ特性	非比例工数 / 開発工数
新規SaaS開発（移行なし、クラウドネイティブ）	15〜25%
既存システム刷新（データ移行あり）	30〜50%
基幹系刷新（複雑な移行、運用要件）	50〜80%

非比例工数が開発工数の50%を超える場合は、ボトムアップ見積もりに切り替えて精度を確保してください。

管理工数の加算

管理工数 = （開発工数 + 非比例工数） × 管理工数率

規模	管理工数率
初期値	10%
大規模PJ（50人月超）	15〜20%
少人数PJ（10人月未満）	5〜10%

全体工数と工期

全体工数 = 開発工数 + 非比例工数 + 管理工数

標準工期はJUAS式で算出します。

標準工期（月） = ∛全体工数（人月） × 3.23

（JUAS ソフトウェア・メトリクス調査2025。旧調査では係数2.70）

SFP = 302.6、最頻値ベースの場合:

全体工数 = 18.9 + 4.5 + 2.3 = 25.7 人月
標準工期 = ∛25.7 × 3.23 ≒ 9.5 ヶ月

金額算出

見積金額 = 全体工数 × 人月単価

妥当性の検証方法

業界標準データとの比較

算出した工数・工期を、以下の業界統計データと比較してレンジ内に収まるか確認します。

データソース	提供情報	入手方法
IPA ソフトウェア開発分析データ集	FP生産性統計（5,546PJ）、工数密度の四分位範囲	IPA公式サイト
JUAS ソフトウェア・メトリクス調査	工数-工期の散布図、標準工期式	JUAS公式サイト

チェックポイント

SFP生産性が業界レンジ内か: IPA P25〜P75（約10〜26 FP/人月）の範囲内に収まるか確認
工期が標準工期と大きく乖離していないか: JUAS式 ∛工数 × 3.23 からの乖離率を確認
工程比率が業界標準と大きく乖離していないか: 設計30〜40%、製造30〜40%、テスト20〜30%が一般的な傾向

過去プロジェクトでの逆算検証

最も有効な検証方法は、過去プロジェクトの実績から自社の生産性パラメータを算出することです。

手順:
1. 過去PJの実績工数（人月）を記録する
2. そのPJのRDRAモデル（または相当する要件定義）からEP/LFを数える
3. SFP = 4.6 × EP + 7.0 × LF を算出する
4. 実績生産性 = SFP ÷ 実績工数 を算出する
5. 複数PJで実施し、自社の生産性レンジを特定する

他手法との突合せ

原理の異なる見積もり手法を最低1つ併用し、結果を比較します。

併用手法	やり方	確認ポイント
ボトムアップ見積もり	WBSを展開し、タスクごとに工数を積み上げ	SFP見積もりとの乖離が30%以内か
類推法	過去の類似PJの実績工数と比較	規模感の一致
3点見積もり	楽観/最頻/悲観をチームで合意	SFPのレンジに包含されるか

乖離が大きい場合は、EP/LFのカウント漏れ、生産性パラメータの設定ミス、非比例工数の見落としを疑ってください。

注意事項と限界

SFP法自体の限界

限界	影響	対策
複雑度を無視	すべてのEP/LFを平均的な複雑度として扱い、複雑なPJほど過少見積もりリスクが増大	EP補正で部分的に対応。複雑なPJではSFP値に係数1.2〜1.5を適用
非機能要件が対象外	性能・セキュリティ・可用性の工数がSFPに反映されない	非比例工数として別途積算
内部ロジックが反映されない	ユーザーが認識しないバッチ処理・集計ロジック等がカウントされない	タイマーEPとして可能な限り切り出し。残りは非比例工数に含める
FP→工数変換のばらつき	生産性パラメータ（SFP/人月）の変動が見積もり全体の誤差を支配	レンジ見積もり（3値）で対応。過去実績による校正が最重要

RDRAモデルの粒度に関する注意

問題	具体例	対策
画面の粒度ばらつき	「受注管理画面」を1画面とするか「一覧」「登録」「詳細」に分けるかでEP数が変動	EP補正ルールを適用し、チーム内で粒度基準を合意
情報の粒度ばらつき	「顧客」を1つとするか「個人顧客」「法人顧客」「連絡先」に分けるかでLF数が変動	「独立してCRUDされるか」を基準に統一
RDRAモデルの詳細度不足	システム境界レイヤーまで定義されていないとEP/LFをカウントできない	最低でもBUCシートの画面/イベント/タイマーと情報シートが必要

疑似精度の罠

「数値が出る ≠ 正確である」 という点に注意してください。

要件定義段階の見積もりは不確実性コーン理論で 0.25x〜4x の誤差範囲にあります
SFP見積もりで「25.7人月」と出ても、実際は6〜100人月の可能性があります（理論上）
必ずレンジ（楽観/最頻/悲観）で提示し、意思決定者に概算であることを伝えてください
単一の数値を確定予算として扱わないでください

不向きなプロジェクト

パターン	理由	乖離方向
バッチ処理主体のシステム	内部ロジックがFPに反映されない	過少見積もり
科学技術計算・シミュレーション	アルゴリズム複雑性が計測不能	過少見積もり
セキュリティ高要件システム	非機能要件が対象外	過少見積もり
マイクロサービス・SPA	「画面」「トランザクション」の境界が曖昧	方向不定
機能変更なしのUI改善	FP値が0になる	計測不能
単純CRUD大量生成（ローコード）	再利用・自動生成で実工数が減少	過大見積もり

実例に学ぶ失敗パターン

事例: 70人月の赤字（日経XTECH報告）

SIベンダーが携帯電話会社のリベート支払いシステムを再構築しました。FP法で約6,000FP、400人月と算出しましたが、実際は520人月を要し70人月の赤字が発生しました。原因は、ユーザーが認識しない内部ロジック（バッチ処理、中間ファイル生成、データ合算・分割等）がシステム全体の70%以上を占めていたことです。

教訓: FP/SFP法は外部仕様ベースの計測手法です。内部処理が複雑なシステムでは構造的に過少見積もりになります。非比例工数や係数補正で吸収しきれない場合は、ボトムアップ見積もりを主とし、SFPは補助として使ってください。

実施チェックリスト

準備フェーズ

RDRAモデルのシステム境界レイヤー（BUCシートの画面/イベント/タイマー）が定義されている
RDRAモデルの情報シート（エンティティ一覧）が定義されている
EP/LFのカウント基準をチーム内で合意している
生産性パラメータを決めている（自社実績 or IPA値）

算出フェーズ

検証フェーズ

SFP生産性がIPA P25〜P75の範囲内に収まっている
工期がJUAS標準工期と大きく乖離していない
他の見積もり手法（ボトムアップ等）と突合せ、乖離を分析した
不向きなプロジェクトパターンに該当しないことを確認した
見積もりをレンジで提示している

実績蓄積フェーズ（PJ完了後）

実績工数を記録した
実績SFP生産性（= SFP ÷ 実績工数）を算出した
自社の生産性データベースを更新した

まとめ

RDRAの要件モデルからSFP法を使うことで、EP/LFという2要素だけで迅速に機能規模を算出し、工数・工期・コストの概算見積もりを導出できます。ただし、SFP法は外部仕様ベースの手法であるため、内部ロジックや非機能要件は別途積算が必要であり、必ずレンジ見積もりと他手法の併用で妥当性を検証してください。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

公式ドキュメント・標準
- IFPUG SFP Standards
- NESMA Early Function Point Counting
統計・調査データ
- IPA ソフトウェア開発分析データ集2022
- JUAS ソフトウェア・メトリクス調査2025
学術論文
- An Evaluation of Simple Function Point as a Replacement of IFPUG FP - Lavazza & Meli, 2014
- Sogeti NESMA精度実証, 2019
百科事典
- Wikipedia - Simple Function Point method
- HandWiki - SFP method
解説記事