- マネジメント
ファンクションポイント法の計算例|ILF・EI・EO・EQの数え方と判定表
ファンクションポイント法(FP法)とは、ソフトウェアの規模を「利用者から見た機能の量」で数える方法です。画面や帳票の裏にあるデータと処理を5種類に分け、それぞれに決まった点数を付けて合計します。プログラムの行数と違い、作る前の機能一覧から数えられるのが特長です。
この記事では、架空の備品貸出管理システムを題材に、機能一覧から調整済みFPまでを1行ずつ追える集計表にしました。数値はすべて掲載のPythonコードで検算しています。
確認環境:Ubuntu 24.04、Python 3.11.15(計算の検算)、@mermaid-js/mermaid-cli 12.0.0(図の描画確認)。確認日は2026-10-06です。判定表と重みは、IFPUG法として広く公開されている内容を使っています。
この記事の結論
- 先にデータ(ILF・EIF)を数え、次に処理(EI・EO・EQ)を数える。処理の複雑度は「いくつのデータを読み書きするか」で決まるため、データが先に決まっていないと数えられません。
- 画面や帳票は、そのまま1個とは数えない。登録・変更・削除・検索のように「それだけで利用者の用が足りる最小の処理」に分けてから数えます。
- EOとEQの境目は、計算や導出データがあるかどうか。保存済みのデータを取り出して見せるだけならEQ、合計・日数・割合などを作って出すならEOです。
- 複雑度は項目数(DET)と関連数(RET・FTR)から表で決める。感覚ではなく、表の区分に当てはめます。
- 題材のシステムは 未調整FP 103、調整係数 0.92、調整済みFP 94.76 になりました。
ファンクションポイント法の早見表
5種類の機能と重み
| 略号 | 名前 | 何を数えるか | 題材での例 | 低 | 中 | 高 |
|---|---|---|---|---|---|---|
| ILF | 内部論理ファイル | このシステムが登録・更新するデータのまとまり | 備品、貸出、予約 | 7 | 10 | 15 |
| EIF | 外部インタフェースファイル | 他システムが保守し、このシステムは参照だけするデータ | 社員、部署 | 5 | 7 | 10 |
| EI | 外部入力 | 外から入ったデータでILFを保守する処理 | 備品登録、貸出登録 | 3 | 4 | 6 |
| EO | 外部出力 | 計算や導出データを含めて外へ出す処理 | 延滞一覧、月次集計表 | 4 | 5 | 7 |
| EQ | 外部照会 | 保存済みのデータを取り出して見せる処理 | 備品検索一覧、詳細照会 | 3 | 4 | 6 |
計算の流れ
| 順番 | やること | 出てくる数値 |
|---|---|---|
| 1 | 数える範囲(境界)を決める | どこまでが自分のシステムか |
| 2 | データを数える(ILF・EIF) | DET・RET → 複雑度 → 点数 |
| 3 | 処理を数える(EI・EO・EQ) | DET・FTR → 複雑度 → 点数 |
| 4 | 点数を合計する | 未調整FP |
| 5 | 14項目の影響度(各0〜5)を合計する | 調整係数 = 0.65 + 0.01 × 合計 |
| 6 | 掛け合わせる | 調整済みFP = 未調整FP × 調整係数 |
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
(記載例)出典:株式会社RJC「ファンクションポイント法の計算例|ILF・EI・EO・EQの数え方と判定表」
用語を先にそろえる:DET・RET・FTR
複雑度を決めるための数え方は3つだけです。
| 略号 | 意味 | 数え方 | 使う場面 |
|---|---|---|---|
| DET | データ項目の数 | 利用者が認識できる、繰り返しのない項目を1つずつ数える | すべて |
| RET | レコード種類の数 | 1つのILF・EIFの中にある、利用者が認識できる項目のグループを数える。グループが無ければ1 | ILF・EIF |
| FTR | 関連ファイルの数 | その処理が読むか更新するILF・EIFの数 | EI・EO・EQ |
処理のDETを数えるときは、次の2点を押さえると数がぶれにくくなります。
- 同じ項目が入力と出力の両方にあっても1回だけ数える。
- 実行ボタンなどの「処理を起動する手段」で1、メッセージ表示で1を加える。ボタンが複数あっても、同じ処理を起動するなら1のままです。
数え分けの判定フロー
機能一覧の1行が5種類のどれに当たるかは、次の順に問いを当てていくと決まります。
flowchart TD
A[機能一覧の1行] --> B{利用者が認識する<br>データのまとまりか}
B -- はい --> C{このシステムが<br>登録や更新をするか}
C -- はい --> ILF[ILF 内部論理ファイル]
C -- いいえ 参照だけ --> EIF[EIF 外部インタフェースファイル]
B -- いいえ 処理である --> D{主な目的は<br>データの保守か}
D -- はい --> EI[EI 外部入力]
D -- いいえ 外へ出す --> E{計算や導出データ、<br>ILFの更新を含むか}
E -- はい --> EO[EO 外部出力]
E -- いいえ 取り出すだけ --> EQ[EQ 外部照会]
EI・EO・EQの数え分け表
| 画面・帳票・連携の例 | 種別 | そう判定する理由 |
|---|---|---|
| 登録画面、変更画面、削除ボタン | EI | ILFを追加・更新・削除するのが目的 |
| CSVの一括取込、他システムからの受信 | EI | 入口が画面でなくても、ILFを保守する処理 |
| 検索条件を入れて一覧を表示 | EQ | 保存済みの値をそのまま取り出す |
| 1件を選んで詳細を表示 | EQ | 同上。一覧と詳細は別の処理として数える |
| 保存済みの項目だけのCSV出力 | EQ | 出力先がファイルでも、計算が無ければ照会 |
| 合計・平均・件数を載せた集計表 | EO | 合計や件数は導出データ |
| 日数や割合を計算した一覧、グラフ | EO | 保存していない値を作って出している |
| 送信日時をILFに記録する通知メール | EO | 外へ出しつつILFを更新する |
| 選択肢のプルダウン表示 | EQ | 同じ内容を複数画面で使っていても数えるのは1回 |
| メニュー画面、ログイン画面への移動 | 数えない | 画面の移動だけで、データの出し入れが無い |
登録画面の中にある初期表示や入力補助は、登録処理の一部として扱い、別に数えません。一方、変更画面を開いたときに現在の値を表示する処理は、それだけで「内容を確認する」という用が足りるため、詳細照会と同じ処理として1回数えます。
複雑度の判定表
ILF・EIF(RETとDETで決める)
| RET \ DET | 1〜19 | 20〜50 | 51以上 |
|---|---|---|---|
| 1 | 低 | 低 | 中 |
| 2〜5 | 低 | 中 | 高 |
| 6以上 | 中 | 高 | 高 |
EI(FTRとDETで決める)
| FTR \ DET | 1〜4 | 5〜15 | 16以上 |
|---|---|---|---|
| 0〜1 | 低 | 低 | 中 |
| 2 | 低 | 中 | 高 |
| 3以上 | 中 | 高 | 高 |
EO・EQ(FTRとDETで決める)
| FTR \ DET | 1〜5 | 6〜19 | 20以上 |
|---|---|---|---|
| 0〜1 | 低 | 低 | 中 |
| 2〜3 | 低 | 中 | 高 |
| 4以上 | 中 | 高 | 高 |
EIの表とEO・EQの表は、区切りの数字が違います。EIはDETが「4/15」、FTRが「1/2」で区切られ、EO・EQはDETが「5/19」、FTRが「1/3」で区切られます。
計算例:備品貸出管理システム
題材の機能一覧
社員がノートPCやプロジェクターなどの備品を借りる、架空の社内システムです。社員と部署の情報は人事システムが持っており、このシステムは参照だけします。
| 区分 | 機能 |
|---|---|
| 備品管理 | 備品登録、備品変更、備品廃棄、備品一括取込(CSV)、備品検索一覧、備品詳細照会 |
| 貸出 | 貸出登録、返却登録、貸出状況照会、貸出履歴CSV出力 |
| 予約 | 予約登録、予約取消、予約一覧照会 |
| 帳票・通知 | 延滞一覧、月次貸出集計表、返却期限お知らせメール、部署別利用率グラフ |
手順1:データを数える(ILF 3個・EIF 2個)
| 種別 | データ | DET | RET | 数え方のメモ | 複雑度 | FP |
|---|---|---|---|---|---|---|
| ILF | 備品 | 12 | 1 | 備品番号、名称、分類、型番、購入日、保管場所、状態など | 低 | 7 |
| ILF | 貸出 | 22 | 2 | 貸出の見出しと貸出明細の2グループ。明細は単独では意味を持たないので、貸出と合わせて1つのILF | 中 | 10 |
| ILF | 予約 | 8 | 1 | 予約番号、備品番号、社員番号、期間など | 低 | 7 |
| EIF | 社員 | 6 | 1 | このシステムが使う項目だけを数える(社員番号、氏名、部署コードなど) | 低 | 5 |
| EIF | 部署 | 4 | 1 | 同上 | 低 | 5 |
テーブルの数とILFの数は一致しません。貸出と貸出明細のように、利用者から見て1つのまとまりなら1個のILFとし、内訳はRETで表します。逆に、作業用の一時テーブルや、技術的な都合で分けたテーブルは数えません。EIFは、相手のシステムが持つ全項目ではなく、こちらが参照する項目だけをDETに数えます。
手順2:処理を数える(EI 8個・EQ 5個・EO 4個)
代表的な3行の数え方を先に示します。
| 処理 | DETの内訳 | FTRの内訳 | 判定 |
|---|---|---|---|
| 貸出登録(EI) | 入力7項目(社員番号、備品番号、貸出日、返却予定日、用途、予約番号、備考)+登録ボタン1+メッセージ1=9 | 貸出(追加)、備品(状態を更新)、予約(引当を更新)、社員(参照)=4 | EIの表でFTR 3以上・DET 5〜15 → 高 |
| 備品詳細照会(EQ) | 表示12項目+備品番号の指定1+表示ボタン1=14 | 備品、貸出(現在の貸出先を表示)=2 | EO・EQの表でFTR 2〜3・DET 6〜19 → 中 |
| 延滞一覧(EO) | 出力7項目(備品番号、備品名、借用者名、貸出日、返却予定日、延滞日数、件数合計)+基準日の指定1+表示ボタン1=9 | 貸出、備品、社員=3 | 延滞日数と件数合計が導出データなのでEO。FTR 2〜3・DET 6〜19 → 中 |
集計表(タブ区切り)
表計算ソフトにそのまま貼れる形です。次の章のコードが出力したものを載せています。
種別 機能名 DET RET/FTR 複雑度 FP
ILF 備品 12 1 低 7
ILF 貸出(貸出・貸出明細) 22 2 中 10
ILF 予約 8 1 低 7
EIF 社員(人事システムが保守) 6 1 低 5
EIF 部署(人事システムが保守) 4 1 低 5
EI 備品登録 13 1 低 3
EI 備品変更 13 1 低 3
EI 備品廃棄 3 2 低 3
EI 備品一括取込(CSV) 12 1 低 3
EI 貸出登録 9 4 高 6
EI 返却登録 6 2 中 4
EI 予約登録 7 3 高 6
EI 予約取消 3 1 低 3
EQ 備品検索一覧 8 1 低 3
EQ 備品詳細照会 14 2 中 4
EQ 貸出状況照会 10 3 中 4
EQ 予約一覧照会 7 3 中 4
EQ 貸出履歴CSV出力 11 3 中 4
EO 延滞一覧(延滞日数を計算) 9 3 中 5
EO 月次貸出集計表 8 3 中 5
EO 返却期限お知らせメール 7 3 中 5
EO 部署別利用率グラフ 5 3 低 4
種別ごとの小計と未調整FP
種別 低 中 高 個数 FP
ILF 2 1 0 3 24
EIF 2 0 0 2 10
EI 5 1 2 8 31
EQ 1 4 0 5 19
EO 1 3 0 4 19
| 種別 | 低 | 中 | 高 | 個数 | FP |
|---|---|---|---|---|---|
| ILF | 2 | 1 | 0 | 3 | 24 |
| EIF | 2 | 0 | 0 | 2 | 10 |
| EI | 5 | 1 | 2 | 8 | 31 |
| EQ | 1 | 4 | 0 | 5 | 19 |
| EO | 1 | 3 | 0 | 4 | 19 |
| 合計 | 22 | 103 |
手順3:調整係数を求める(14項目)
システム全体の特性を14項目、それぞれ0(影響なし)〜5(強い影響)で評価します。
| No | 項目 | 見るところ | 題材の評価 |
|---|---|---|---|
| 1 | データ通信 | 通信を使ってやり取りする度合い | 3 |
| 2 | 分散データ処理 | 処理やデータが複数の場所に分かれる度合い | 1 |
| 3 | 性能 | 応答時間や処理量の要求の厳しさ | 2 |
| 4 | 高負荷構成 | 機器の利用率が高い環境で動かす度合い | 1 |
| 5 | トランザクション量 | 処理件数の多さが設計に与える影響 | 1 |
| 6 | オンラインデータ入力 | 画面から入力する割合 | 5 |
| 7 | エンドユーザー効率 | 使いやすさへの配慮の度合い | 3 |
| 8 | オンライン更新 | 画面操作でILFを即時に更新する度合い | 3 |
| 9 | 複雑な処理 | 計算や論理の込み入り具合 | 1 |
| 10 | 再利用性 | 他でも使える形にする度合い | 1 |
| 11 | 導入容易性 | 移行や導入のしやすさへの要求 | 2 |
| 12 | 運用容易性 | 起動・バックアップなど運用作業の自動化の度合い | 2 |
| 13 | 複数サイト | 複数の拠点や環境に導入する度合い | 0 |
| 14 | 変更容易性 | 利用者自身が設定を変えられる度合い | 2 |
| 合計 | 27 |
未調整FP = 103
影響度の合計 = 27(14項目)
調整係数 = 0.65 + 0.01 × 27 = 0.92
調整済みFP = 103 × 0.92 = 94.76
調整係数の取りうる範囲 = 0.65 〜 1.35
調整係数は0.65〜1.35の範囲に収まります。14項目の合計が35のときにちょうど1.00で、題材のように合計が27だと0.92となり、調整済みFPは未調整FPより小さくなります。
手順4:工数に換算する(説明用の値)
FPは規模の単位で、工数ではありません。工数にするには「1FPあたり何時間かかったか」という自分たちの過去の記録が必要です。ここでは説明用に、1FPあたり8人時、1人月を160時間という架空の値で換算します。
工数の例 = 94.76 × 8 = 758.08 人時 = 4.74 人月
Pythonで検算する(貼って使えるコード)
機能一覧をタブ区切りで貼り替えれば、自分のシステムにもそのまま使えます。
"""ファンクションポイント法の集計(IFPUG法の判定表)。python3 fp_calc.py で実行"""
import csv, io
# 複雑度の判定表:行は RET または FTR の区分、列は DET の区分
MATRIX = [["低", "低", "中"], ["低", "中", "高"], ["中", "高", "高"]]
WEIGHT = {"ILF": {"低": 7, "中": 10, "高": 15}, "EIF": {"低": 5, "中": 7, "高": 10},
"EI": {"低": 3, "中": 4, "高": 6}, "EO": {"低": 4, "中": 5, "高": 7},
"EQ": {"低": 3, "中": 4, "高": 6}}
def band(value, upper1, upper2):
"""value が upper1 以下なら 0、upper2 以下なら 1、それより大きければ 2"""
return 0 if value <= upper1 else 1 if value <= upper2 else 2
def complexity(kind, det, ref):
"""ref はデータファンクションなら RET、トランザクションなら FTR"""
if kind in ("ILF", "EIF"):
return MATRIX[band(ref, 1, 5)][band(det, 19, 50)]
if kind == "EI":
return MATRIX[band(ref, 1, 2)][band(det, 4, 15)]
return MATRIX[band(ref, 1, 3)][band(det, 5, 19)] # EO・EQ
# 種別 / 機能名 / DET / RETまたはFTR(タブ区切り。表計算ソフトからそのまま貼れる)
FUNCTIONS = """\
ILF 備品 12 1
ILF 貸出(貸出・貸出明細) 22 2
ILF 予約 8 1
EIF 社員(人事システムが保守) 6 1
EIF 部署(人事システムが保守) 4 1
EI 備品登録 13 1
EI 備品変更 13 1
EI 備品廃棄 3 2
EI 備品一括取込(CSV) 12 1
EI 貸出登録 9 4
EI 返却登録 6 2
EI 予約登録 7 3
EI 予約取消 3 1
EQ 備品検索一覧 8 1
EQ 備品詳細照会 14 2
EQ 貸出状況照会 10 3
EQ 予約一覧照会 7 3
EQ 貸出履歴CSV出力 11 3
EO 延滞一覧(延滞日数を計算) 9 3
EO 月次貸出集計表 8 3
EO 返却期限お知らせメール 7 3
EO 部署別利用率グラフ 5 3
"""
# 一般システム特性 14項目(各 0〜5)
GSC = {"データ通信": 3, "分散データ処理": 1, "性能": 2, "高負荷構成": 1, "トランザクション量": 1,
"オンラインデータ入力": 5, "エンドユーザー効率": 3, "オンライン更新": 3, "複雑な処理": 1,
"再利用性": 1, "導入容易性": 2, "運用容易性": 2, "複数サイト": 0, "変更容易性": 2}
rows, summary = [], {}
for kind, name, det, ref in csv.reader(io.StringIO(FUNCTIONS), delimiter="\t"):
c = complexity(kind, int(det), int(ref))
fp = WEIGHT[kind][c]
rows.append((kind, name, det, ref, c, fp))
s = summary.setdefault(kind, {"低": 0, "中": 0, "高": 0, "FP": 0})
s[c] += 1
s["FP"] += fp
print("種別\t機能名\tDET\tRET/FTR\t複雑度\tFP")
for r in rows:
print("\t".join(map(str, r)))
print()
print("種別\t低\t中\t高\t個数\tFP")
for kind, s in summary.items():
print(f"{kind}\t{s['低']}\t{s['中']}\t{s['高']}\t{s['低'] + s['中'] + s['高']}\t{s['FP']}")
ufp = sum(s["FP"] for s in summary.values())
tdi = sum(GSC.values())
assert len(GSC) == 14
vaf = 0.65 + 0.01 * tdi
print()
print(f"未調整FP = {ufp}")
print(f"影響度の合計 = {tdi}(14項目)")
print(f"調整係数 = 0.65 + 0.01 × {tdi} = {vaf:.2f}")
print(f"調整済みFP = {ufp} × {vaf:.2f} = {ufp * vaf:.2f}")
print(f"調整係数の取りうる範囲 = {0.65 + 0.01 * 0:.2f} 〜 {0.65 + 0.01 * 70:.2f}")
# 複雑度の判定を省いた簡易計算(データは「低」、処理は「中」に固定した場合)
simple = sum((WEIGHT[k]["低"] if k in ("ILF", "EIF") else WEIGHT[k]["中"]) * (s["低"] + s["中"] + s["高"])
for k, s in summary.items())
print(f"簡易計算(データ=低・処理=中に固定) = {simple}")
# 工数への換算(1FPあたり8人時、1人月=160時間は説明用の架空の値)
hours = ufp * vaf * 8
print(f"工数の例 = {ufp * vaf:.2f} × 8 = {hours:.2f} 人時 = {hours / 160:.2f} 人月")
python3 fp_calc.py
出力は、この記事の「集計表」「種別ごとの小計」「調整係数」「工数に換算する」に載せたものと同じです。最後の2行は次のとおりです。
簡易計算(データ=低・処理=中に固定) = 103
工数の例 = 94.76 × 8 = 758.08 人時 = 4.74 人月
似た手法との違いと選び方
| 手法 | 測るもの | 入力 | 出てくるもの | 向いている場面 |
|---|---|---|---|---|
| ファンクションポイント法 | 利用者から見た機能の量 | 機能一覧、データ項目、画面・帳票の項目 | FP(規模) | 作る前に規模を説明する、異なる言語や体制の間で規模を比べる |
| FPの概算(複雑度の判定を省く数え方) | 同上(粗い値) | データと処理の個数 | FPの概算値 | 項目がまだ決まっていない企画段階 |
| ストーリーポイント | チーム内での相対的な大きさ | ユーザーストーリー、基準にするストーリー | ポイント(チーム固有の単位) | 同じチームが短い周期で計画を立てる |
| COCOMO | 規模から工数を求める式 | ソースコードの行数(千行単位)と係数 | 工数(人月) | 行数の見込みや過去の行数データがある |
FPの概算は、NESMAが早い段階向けの数え方として公開しているものがよく知られています(NESMAの方式はISO/IEC 24570として規格化されています)。COCOMOはBarry W. Boehmが1981年の著書で発表したモデルで、基本形は「工数 = a × (千行)^b」という式です。
どれを使うかの判断基準
| 条件 | 選ぶもの |
|---|---|
| 画面・帳票の項目まで決まっていて、規模の根拠を他者に説明したい | ファンクションポイント法 |
| 機能の名前とデータの名前しか決まっていない | FPの概算。項目が決まったら数え直す |
| 同じチームが次のスプリントに入れる量を決めたい | ストーリーポイント |
| 行数の見込みと、行数あたりの工数の記録がある | COCOMO |
| 規模ではなく作業の漏れを確かめたい | 作業を分解して積み上げる見積もりと併用する |
数えるときに迷いやすい点
| 迷う場面 | 考え方 |
|---|---|
| 登録・変更・削除が1つの画面にまとまっている | 画面は1つでも、処理は3つ。それぞれEIとして数える |
| 同じ一覧を画面表示とCSV出力の両方でできる | 項目と処理の内容が同じなら1つ。出力先の違いだけでは増やさない |
| 一覧の下に合計行がある | 合計は導出データなのでEO |
| 検索結果の件数を表示している | 件数も導出データ。件数を出すならEO、出さなければEQ |
| コード表(区分と名称だけの表) | 利用者の業務データではなく、値の候補を持つだけの表は数えない |
| バッチ処理 | 利用者の要求にもとづきILFを更新するならEI、帳票を出すならEO。入口が画面かどうかは関係ない |
| 相手システムへデータを送る連携 | 送る内容に計算が含まれればEO、保存済みの値だけならEQ |
確かめて分かったこと
- EIの表をEO・EQに当てると結果が変わる。部署別利用率グラフ(DET 5・FTR 3)はEO・EQの表では「低」ですが、同じ数字をEIの表で引くと「高」になります。表を1枚にまとめず、3枚に分けて持つのが確実です。
- 貸出登録はFTRを3に減らしても「高」のまま。DET 9・FTR 4で「高」でしたが、FTR 3でも「高」、FTR 2まで減ると「中」でした。EIはFTRが3以上になった時点で複雑度が上がりやすいと分かります。
- 複雑度を固定した簡易計算が、今回は詳細な数え方と同じ103になった。データをすべて「低」、処理をすべて「中」に固定して数えたところ、ILFが24に対して21、EIが31に対して32、EQとEOが19に対して20と、種別ごとには差があり、合計で打ち消し合っていました。一致は題材による偶然で、種別ごとの差は残る点に注意が要ります。
- 調整係数で値が小さくなることがある。14項目の合計が35より小さいと係数は1.00を下回ります。題材では0.92で、103が94.76になりました。
- 判定フローのMermaidは、掲載のコードのまま描画できた。条件の文中に全角の読点を入れても、角かっこや波かっこの中であれば描画されました。
よくある質問
Q. ファンクションポイント法とは何ですか? A. ソフトウェアの規模を、利用者から見た機能の量で数える方法です。データ2種類(ILF・EIF)と処理3種類(EI・EO・EQ)に分け、複雑度ごとの点数を合計します。1979年にIBMのAllan J. Albrechtが考案しました。
Q. EOとEQの違いは何ですか? A. 計算や導出データを含むかどうかです。保存済みの値を取り出して見せるだけならEQ、合計・件数・日数などを作って出す場合や、出力と同時にILFを更新する場合はEOです。
Q. ILFとEIFの違いは何ですか? A. そのデータを保守するのが自分のシステムかどうかです。自分のシステムが登録・更新するならILF、他システムが保守していて参照だけするならEIFです。
Q. 画面数や帳票数からFPを出せないときはどうしますか? A. 画面を「登録」「変更」「削除」「一覧」「詳細」などの処理に分けてから数えます。1画面が1処理とは限らないため、画面数に点数を掛けるのではなく、処理の一覧を作るところから始めます。
Q. 調整係数は必ず掛けますか? A. 掛けずに未調整FPのまま使う組織もあります。規模そのものを比べたいときは未調整FP、システム全体の特性を反映させたいときは調整済みFPというように、どちらを使うかを最初に決めてそろえておくと、後から比べやすくなります。
まとめ
- 数える順番は、データ(ILF・EIF)→ 処理(EI・EO・EQ)。
- 画面や帳票は、利用者の用が足りる最小の処理に分けてから数える。
- EOとEQは、計算・導出データ・ILFの更新があるかで分ける。
- 複雑度はDETとRET・FTRを数えて表で決める。EIとEO・EQは区切りの数字が違う。
- 調整係数は 0.65 + 0.01 × 14項目の合計。範囲は0.65〜1.35。
- 題材の結果は、未調整FP 103 × 調整係数 0.92 = 調整済みFP 94.76。
- FPは規模の単位。工数にするには、自分たちの「1FPあたりの時間」の記録を掛ける。
参考・出典
- IFPUG「Function Point Analysis (FPA)」 https://ifpug.org/ifpug-standards/fpa (FPAの位置づけ、5種類の構成要素、ISO/IEC 20926。2026-10-06閲覧)
- NESMA「Function Point Analysis」 https://nesma.org/themes/sizing/function-point-analysis/ (2026-10-06閲覧)
- Wikipedia「Function point」 https://en.wikipedia.org/wiki/Function_point (考案者と年、各方式の規格番号。2026-10-06閲覧)
- Wikipedia「COCOMO」 https://en.wikipedia.org/wiki/COCOMO (発表者と年、基本式。2026-10-06閲覧)
本記事の内容は、ご自由にお使いください。
ご利用の際は、出典として本ページへのリンクを記載いただけますようお願いします。
(記載例)出典:株式会社RJC「ファンクションポイント法の計算例|ILF・EI・EO・EQの数え方と判定表」
株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。
WE ARE HIRING
RJCで一緒に開発しながら、
成長を楽しみませんか?
RJCは、Web・モバイル・AIを活用した開発プロジェクトで、テックリードやPM・PMOも活躍するシステム開発会社です。会社を知る、待遇を確かめる、話を聞いてみる。気になるところ見てみてください!
- 127日年間休日
- 12時間平均残業時間
- 毎日ガチャ遊びココロも大切にする福利厚生。アマギフなどの賞品ラインナップ!
ほかにも、チケットレストラン、書籍読み放題、2年ごとの慰労報奨(休暇 or 金一封)、11期連続の黒字決算。