論文
ファンクションポイント法を応用した早期見積技法の提案とそのシステム化
原田 晃† 幕田 行雄‡ 石川 貞裕§ 大野 治§ 楠本 真二** 井上 克郎**
Early Software Size Estimation Method Based on Function Point
Akira Harada†, Ikuo Makuta‡, Sadahiro Ishikawa§, Osamu Ohno§, Shinji Kusumoto** ,and Katsuro Inoue**
あらまし

業務ソフトウェアの開発では，機能仕様の明確になっていない開発の前段階で開発費，開発期間を見積ることが重要であると考えられている．開発費，開発期間は，開発対象の業務ソフトウェアの規模を見積り，それに信頼性等のシステム特性を加味して算出する．最近，業務ソフトウェアの規模を，ファン
クションポイントという機能量で見積るファンクションポイント法が普及してきた．しかし，開発の前段階
でファンクションポイント法により見積を行うには，いくつかの困難を伴う．本論文では，開発の前段階でも，業務ソフトウェアの規模を見積ることのできる，ファンクションポイント法を応用した早期見積技法の提案と，そのシステム化について報告する．多数のプロジェクトに適用し評価したところ，非常に高い精度で，しかも簡単に，業務ソフトウェアの規模を見積ることができるという結果を得た．
キーワード

見積，ファンクションポイント，FP，プロジェクト管理，業務ソフトウェア

１．まえがきインターネットや Web の普及拡大に代表されるように情報化社会の進展は著しく，それに伴い，業務ソフト
ウェアの開発においても大規模化，高機能化，短納期化，低コスト化の要求が急速に高まってきている．これを実現するためには，プロジェクトの開発計画を立て，開発計画どおりに開発が進むようにプロジェクト管理を行うことが必要である[1],[2],[3]．開発計画の中でも，開発費，開発工数，開発期間は，特に重要であると考えられており，これらを予測することを見積という．通常，開発費，開発工数と開発期間は，まず対象となる業務ソフトウェアの開発規模を見積り，それに品質や性能等の要素を加味して予測されることが多い[4],[5],[6]．
従来，ソフトウェアの規模はプログラム行数（SLOC: Software Lines Of Codes）で測定されてきた．しかし，プログラム行数を尺度とする場合，開発言語に依存，開発者の技術レベルに依存，再利用可能プログラ
ムの行数の扱い方の不統一等の課題が多く，最近では，ソフトウェアの機能量をファンクションポイント（以後，FP という）という尺度によって定量的に計測する，ファンクションポイント法（以後，FP 法という）が普及してきており，特に業務ソフトウェアでは FP 法が標準になりつつある[7]．
FP 法は 1979 年に Albrecht によって提案された[8]．これはユーザの視点から機能量を定量化するため，開発言語や実装方法に影響されない値を得ることができ，優れた見積技法であると考えられている．
FP 法による業務ソフトウェアの規模見積の時点には，企画段階，開発の前段階，要求要件設計終了段階等があるが，プロジェクトの開発計画を立てるためには，開発の前段階での規模見積が必要である．ところが，
この段階では発注者から提案依頼書（RFP: Request For Proposal）が提示されるのみで，実装すべき機能
仕様が詳細には定まっておらず，FP 法による規模見積を実施するには，いくつかの困難を伴う．この課題を改善したものとして NESMA 法[11]，ユースケースポイント法[12]，電中研法[13]等いくつか考案されている．
†

日本電子計算株式会社，東京都
日立ソフトウェアエンジニアリング（株），東京都§（株）日立製作所，東京都**
大阪大学大学院情報科学研究科，大阪府‡

1本論文では，開発の前段階でも FP を計測できる，要素見積法と呼ぶ見積技法を提案する．また，この見積技法を実装した見積システム（AP‑Estimate）について説明する．
画面上の 1 個の GUI ボタンや 1 回のファンクションキー押下で実行される，ユーザ視点での入出力の最小単位を要素機能と呼ぶ．要素見積法では，16 種類の要素機能を予め定義しておき，対象となるソフトウェアに，これらの要素機能が，それぞれいくつ含まれているかを計測して FP を算出するものである．
これまで約 200 プロジェクトで，開発の前段階で AP‑Estimate を用いた規模見積を実施しており，精度の高い結果を得ている．
本論文では，第 2 章で IFPUG 法の概要と課題を，第 3 章で要素見積法を，第 4 章で AP‑Estimate の実現方式
を，第 5 章で適用事例を，第 6 章で評価を行い，第 7 章ではまとめを述べる．
２．業務ソフトウェアの見積技法
２．１ 業務ソフトウェアのライフサイクルと見積の時点（１）ソフトウェアライフサイクル
図 1 に示すように，業務ソフトウェアの開発では，開発を委託する側と，委託を受けて開発する側の 2 つの組織が考えられる．[14]に倣って，開発を委託する側を購入者，開発を担う側を供給者と呼ぶことにする．
購入者は新しく開発する業務ソフトウェアの企画を行った後，高品質のソフトウェアを低コストかつ短期間で開発できる供給者を選んで，開発を委託することが多い．そのために，購入者は開発するソフトウェアの要件を記載した RFP を作成し，複数の供給者に提案書の提出を依頼する．供給者は，その要件を満たすソフ
トウェアのアーキテクチャー，開発するためのコスト，期間等を記載する提案書を作成し，購入者に提出す
る．購入者は，複数の供給者から提出された提案書の内容，供給者の能力を評価して，供

企 画

R FP
作 成

供 給 者
決 定

購 入 者

給者を決定し，開発を委託する．

開 発 プロ セス

提 案 書
作 成

プ ロ ジェ
ク ト 計画作成

委託を受けた供給者はプロジェクトを組織し，プロジェクト計画を作成して，開発を進めて納入

開 発 委託

供 給 者

要求
分析

業務要
件設計

ソフト
ウェア
方 式 設計ソフト
ウェア
詳 細 設計・ ・・
企 画 段階で の 見積いくことになる．
開発は，要求分析，業務要件設計，ソフトウ
ェア方式設計，ソフトウェア詳細設計，プログラミ

開 発 の前 段
階 で の見 積

プ ロ グラ ミング&
単 体 テス ト

組合
テスト

総合．
シ ス テム テスト・業 務 要件 設計
終 了 以降 での 見積

図1 ソフトウェアライフサイクルと見積時点の関係
Fig.1 Relation of software life cycle and the timing forsoftware sizing

ング＆単体テスト，組合テスト，総合・システムテストというように複数の工程に分割され，この順序で行われていく．
このような開発プロセスは[14]で標準化されており，上記の 7 つの工程も標準化された開発プロセスと対応をつけることができる．
（２）見積の時点
ソフトウェアライフサイクルの様々な時点で見積を行うことは，企画の作成や，開発を進めていくうえでの改善に役立つが，特に，図 1 に示す次の 3 つの時点での見積が重要であると考えられる．
(a)企画段階での見積予算化等を目的に開発費，開発期間を算出するために行う見積である．企画段階では，機能要件が明確になっていないことが多く，ここで見積る開発費は非常に粗い概算というべきものになる．
(b)開発の前段階での見積
図 1 に示すように，提案書の作成時点やプロジェクト計画作成時点等の開発の前段階で，開発費，開発工数，
開発期間を算出するために行う見積である．購入者が作成した RFP に記載されている要件を基に見積を行う．
RFP には，業務要件，ユーザ要件，機能要件が記載されている．業務要件とは，購入者である組織が，ソフ
トウェアを購入する理由や達成したいと望む目的を表す．ユーザ要件とは，ユーザがソフトウェアを使って実行できなければならない目標や仕事を表す．機能要件は，ユーザが仕事を遂行して業務要件を満たすために，ソフトウェアが備えていなければならない機能を表す．即ち，RFP には，実現して欲しいことは記載さ2れているが，それをどのように実現するかは記載されていない．どのように実現するかは，開発プロセスの中で明確にされていく．したがって，RFP には，ユーザの観点から直接，必要となる機能が記載されているが，その機能を実現するために必要となる２次的な機能について明確になっていないことが多く，精度の高い見積を行うことは難しい場合が多い．ここで見積る開発費，開発工数，開発期間は企画段階のものよりも精度は高いものの，概算というべきものになる．
(c)業務要件設計終了以降での見積
購入者，供給者間の契約内容の見直しや，プロジェクトの開発計画をより詳細化すること等を目的に，図 1に示すように，業務要件設計やソフトウェア方式設計完了時に，開発するソフトウェアで実現する機能，性能，信頼性等の機能仕様が明確になった時点で行う見積である．高い精度での見積が可能な場合が多い．な
お，今後，本論文では，業務ソフトウェアを単にソフトウェアと呼ぶことにする．また，見積とはソフトウ
ェアの規模を見積ることを指すことにする．
２．２ FP 法の概要と課題
FP 法には，IBM 法[9]，IFPUG 法[10]等、数十種類の計測方法があるが，現在では IFPUG 法が主流となっており，本論文では IFPUG 法を用いる．
（１）IFPUG 法の概要
IFPUG 法には，開発するソフトウェアの規模を表すアプリケーション FP，新規にソフトウェアを開発するプ
ロジェクトの規模を知るために使用する新規開発プロジェクト FP，既存ソフトウェアを機能改良するプロ
ジェクトの規模を知るために使用する機能改良プロジェクト FP の 3 種類がある．本論文は，ソフトウェアの規模を計測することを対象としており，アプリケーション FP について説明する．また，アプリケーショ
ン FP はシステム特性を反映したものであるが，本論文ではシステム特性を反映していない未調整 FP のみを扱う．IFPUG 法では，未調整 FP を次の手順で計測する[10]．なお，説明の中にでてくるアプリケーションとはソフトウェアと同じ意味である．
(Step1)アプリケーション境界と計測範囲の設定
FP を計測する範囲を明確にするために，計測対象のアプリケーション境界（ソフトウェアの境界）を設定する．アプリケーション境界を今後，計測境界と呼ぶ．
(Step2)データファンクションの計測
データファンクションとは，計測対象となるソフトウェアから参照，若しくは更新を行う論理的な意味でのデータのまとまりのことである．データファンクションは，計測対象のソフトウェアから更新される内部論
理ファイル(ILF: Internal Logical File)と，計測対象のソフトウェアから参照されるのみの外部インタフ
ェースファイル(EIF: External Interface File)の 2 種類のファンクションタイプに分類できる．
最初に，計測対象のソフトウェアからデータファンクションを抽出し，ファンクションタイプを決定する．
次に，それぞれのデータファンクションの複雑度を，データ項目数，レコード種類数の 2 つのパラメータによって，低，中，高の 3 段階に分類する．データ項目とはデータを定義する最小の単位であり，データ項目
数は 1 つのデータファンクションの中に存在するデータ項目の個数である．また， 1 つのデータファンク
ションの中に，異なる意味合いをもつデータの纏まりが混在している場合，その個数をレコード種類数という．混在していない場合は，レコード種類数は 1 となる．
(Step3)トランザクションファンクションの計測
ソフトウェアに対するデータの入出力を伴う処理をトランザクションファンクションという．トランザクションファンクションは，計測境界外からのデータ入力によってデータファンクションの更新を行う外部入力(EI: External Input)，計測境界外へ派生データ(計算や条件判断など何らかの加工を必要とするデータ項
目)の出力を行う外部出力(EO: External Output)，計測境界外へデータをそのまま出力する外部照会(EQ:
External Inquiry)の 3 種類のファンクションタイプに分類できる．
最初に，計測対象のソフトウェアからトランザクションファンクションを抽出し，ファンクションタイプを3

決定する．次に，それぞれのトランザクションファンクション の複雑度を，関連ファイル数，データ項目
数の 2 つのパラメータによって，低，中，高の 3 段階に分類する．関連ファイル数とは，対象となるトランザクションファンクションで参照，若しくは更新するデータファンクションの個数である．データ項目数は，
実際に参照，若しくは更新するデータ項目の個数である．
(Step4)未調整ファンクションポイントの算出
Step2, Step3 の結果を基に，表 1 を用いて未調整

表 1 未調整 FP 算出表
Table1 Calculation table of unadjustment FP

ファンクションポイント（未調整 FP）を計算する．

タイプ

低

中

高

合計

ILF

a1×7

a2×10

a3×15

ILF の合計

ここで a1，a2，a3 は計測対象ソフトウェアに含ま

EIF

b1×5

b2×7

b3×10

EIF の合計れる複雑度が低，中，高の ILF の数，b1，b2，b3

EI

c1×3

c2×4

c3×6

EI の合計は計測対象ソフトウェアに含まれる複雑度が低，中，

EO

d1×4

d2×5

d3×7

EO の合計高の EIF の数，c1，c2，c3 は計測対象ソフトウェ

EQ

e1×3

e2×4

e3×6

アに含まれる複雑度が低，中，高の EI の数，d1，

EQ の合計総計(未調整 FP)

d2，d3 は計測対象ソフトウェアに含まれる複雑度が低，中，高の EO の数，e1，e2，e3 は計測対象ソフトウ
ェアに含まれる複雑度が低，中，高の EQ の数である．なお，今後，未調整 FP を単に FP と呼ぶ．
（２）IFPUG 法の課題
どの時点の見積も重要であるが，特に開発の前段階での見積が重要であると考えられる．この時点での見積が誤って過小になった場合，実際にかかった開発費，開発工数，開発期間は計画したものよりも大きくなる．
その結果，例えば，購入者は新しいソフトウェアの稼動開始時期が遅れて事業の好機を逃すことになり，供給者は購入者から支払われる金額を超える開発費がかかり，所謂，赤字になる．即ち，見積を誤った場合の影響が大きい．また，筆者らが，開発費が当初の計画よりも超過したプロジェクトの原因を分析したところ，見積不良によるものが非常に大きな割合を占めていることが判明した．したがって，開発の前段階で精度の高い見積を行うことが重要となる．この時点では，RFP に記載されている機能要件を基に見積を行う必要がある．しかし，記載されている機能に漏れがある場合や，業務要件設計やソフトウェア方式設計が完了していないために詳細部分が固まっていない場合が多い．従って，IFPUG 法に習熟していない人が計測しようとした場合，次のような課題があると考えられる．
・Step3 でのデータファンクションの複雑度を分類するときのパラメータである，レコード種類数，データ
項目数を正確に把握することが難しい．
・Step4 でのトランザクションファンクションの複雑度を分類するときのパラメータである，関連ファイル
数，データ項目数を正確に把握することが難しい．
・Step4 での EI, EO, EQ の 3 種類のファンクションタイプは，データの入出力を伴う処理を，最も小さな単位に細分化したものであり，抽象的で，具体的な処理や操作との対応づけが難しい．その結果，トラン
ザクションファンクションの抽出が難しい．
このような IFPUG 法の課題を改善するものとして，NESMA 法[11]，電中研法[13]等いくつか考案されている．
NESMA 法には，FP 概算法と FP 試算法の 2 種類の見積方法がある．
FP 概算法は，データファンクションやトランザクションファンクションの抽出及びファンクションタイプ
の決定の仕方は，IFPUG 法と同じであるが，複雑度をデータ項目数，レコード種類数，関連ファイル数で分類するのでなく，それぞれ予め設定されているデフォルト値を当てはめる．したがって，IFPUG 法での複雑度の分類が難しいという課題は解決されている．しかし，実際の業務ソフトウェアでは，3 種類のトランザ
クションファンクションは，低，中，高，いずれの複雑度もとりえるが，デフォルト値が一意に当てはめられるために，精度が粗くなると考えられる．また，IFPUG 法と同様に，トランザクションファンクションの抽出が難しいと考えられる．
FP 試算法は，データファンクションの計測は FP 概算法と同じであるが，トランザクションファンクションの抽出を行わず，データファンクションの ILF, EIF の個数から，計算式により FP を算出する．したがって，
FP 概算法よりも更に精度が粗いと考えられる．
4

電中研法は，機能の要素として画面，帳票，ファイル，電文などわかりやすいものを用いているため，早期の見積に適しているが，IFPUG 法とは互換性がない。
本論文では，開発の前段階でも高い精度で見積を行えるように IFPUG 法を改善した，「要素見積法」を提案する．要素見積法は FP 概算法と類似の手法である．
３．要素見積法
要素見積法では，第 2 章であげた IFPUG 法の課題の改善のために，データファンクションの複雑度の分類の簡易化と，トランザクションファンクションの抽出及び複雑度の分類の簡易化を図っている．
（１）データファンクションの計測
IFPUG 法と同様に，データファンクションを抽出し，ILF, EIF のいずれかにファンクションタイプを決定する．ただし，複雑度をレコード種類数，データ項目数の 2 つのパラメータによって分類するのでなく，FPのデフォルト値（ILF:8, EIF:5）を FP 単価として用いる．
（２）トランザクションファンクションの計測
要素見積法では，トランザクションファンクションのファンクションタイプを EI, EO, EQ の 3 種類に分類するのでなく，表 2 に示す，要素機能と呼ぶ 16 種類のファンクションタイプに分類する．
表 2 要素機能一覧
Table2 List of element functions
要素機能名
機 能 概 要更
新規登録
登録データ入力後，マスタファイルへの新規データ登録．例えば SQL の insert
新文．
系
既存データ変更
変更データ入力後，マスタファイルのデータ変更．例えば SQL の update 文．
既存データ削除
削除データの指示により，マスタファイルのデータ削除．
マスタメンテナンス
マスタファイルの内容をメンテナンスする機能．
その他更新
更新データ入力後，追加，変更，削除が混在する更新．
問合せ応答
画面上からの条件入力により，データを表示．
画
一覧照会
画面上からの条件入力により，該当データの一覧を表示．
面
明細照会
画面上で一覧から選択により，該当データの詳細内容を表示．
出
計算結果表示画面上からデータ入力後，計算結果を表示．
力更新のための照会
変更や削除のために，前もって現在値を照会．
系
選択肢一覧
ListBox や PopUp らで商品コード，商品名の選択肢を表示．
その他照会
上記にあてはまらない照会機能．
そ更
帳票出力
印刷帳票の出力，PDF ファイルの作成，EUR 帳票出力のためのデータの引渡し．
の新CSV 出力電子ファイルの出力機能．
他系
その他データ出力
帳票や電子ファイル以外のデータ出力．
他システムへの出力
他システム送信用のファイル作成，他システム送信用の電文の作成，API 呼び出
しによる他システムへのデータ引渡し．

FP 単価
5
5
4
12
6
5
5
5
6
4
3
5
6
5
5
5

要素機能は，IFPUG 法ではトランザクションファンクション EI, EO, EQ の抽出が難しいので，これらを想起しやすくするための処理を用意しようという着想から生まれた．例えば，EI として抽出される処理には，｢新規登録」，「既存データ変更」，「既存データ削除」があり，これらを要素機能として設定した． IFPUG 法の EI, EO, EQ はデータの入出力を伴う処理を最小の単位に細分化したものであるが，要素見積法での 16 種
類の要素機能は，画面上の 1 個の GUI ボタンや 1 回のファンクションキーを押すことで実行される具体的な処理であり，ユーザ視点での入出力の最小単位と考えることができる．
要素見積法でのトランザクションファンクションの計測では，最初に要素機能を抽出する．これは，IFPUG
法におけるトランザクションファンクションの抽出と，ファンクションタイプの決定に該当する．要素機能の複雑度は，IFPUG 法のように，関連ファイル数やデータ項目数で分類するのでなく，表 2 の「FP 単価」の列に示す，各要素機能の 1 個あたりの FP のデフォルト値を当てはめる．したがって，IFPUG 法と同様に，
FP を算出することができる．
（３）要素見積法での FP 単価の設定と評価
データファンクション ILF, EIF の FP 単価，要素機能の FP 単価は，次のような考え方で設定した．
著者らが所属する組織では，1996 年〜1998 年にかけて実施されたプロジェクトの IFPUG 法による実績から，
5

データファンクション，トランザクションファンクションの FP を，複雑度を評価せずに，ILF:8, EIF:5,
EI:5, EO:6, EQ:4 と FP 単価を設定すると，実用上，有用であることが経験的に得られていた． そこで，要素見積法における FP 単価は，これらの値を基に設定した．
(a)データファンクションの FP 単価
ILF, EIF の FP 単価は上記の値をそのままを採用し，ILF:8, EIF:5 とした．また，これらの FP 単価が妥当であるかを，金融分野の業務ソフトウェアから 1 つ、製造分野の業務ソフトウェアから 2 つ、公共分野の業務ソフトウェアから 3 つの計 6 業務ソフトウェアの IFPUG 法と要素見積法による実測データを用いて評価した．IFPUG 法による実測結果では，ILF, EIF の FP の平均値は，それぞれ 7.3, 5.0 であり，要素見積法のFP 単価との誤差は 10%未満であり，実用的に問題がないため，要素見積法で設定したデータファンクションの FP 単価は妥当であると判断した．
(b)要素機能の FP 単価
各要素機能の FP 単価は，次のような考え方で設定した．
要素機能はデータの入出力を伴う処理であるので，その中には IFPUG 法でのトランザクションファンクショ
ン EI, EO, EQ が含まれる．そこで，各要素機能でのトランザクションファンクションの出現頻度と FP を表
3 のように想定して，要素機能の FP 単価を設定した．また，ここでの EI, EO, EQ の FP は，先に説明した
経験的に得られた EI, EO, EQ の FP 単価，即ち EI:5, EO:6, EQ:4 を基に設定した．
例えば「新規登録」はデータファンクションの更新があり，EI のみが必ず 1 回出現するので，FP は EI のFP 単価の 5 を，そのまま採用した．同様に「既存データ削除」は，EI のみが必ず 1 回出現するが，削除処理ではデータ項目数が少なく複雑度が低くなる傾向にあるので FP には 4 を採用した．
「問合せ応答」は EO
または EQ の可能性があるが，それぞれの発生確率は，ほぼ同等であると考え，EO, EQ の出現頻度を 0.5 ず
つに設定した．また，そのときの FP は FP 単価をそのまま採用した．
表 3 要素機能毎の FP 単価算出表
Table3 Calculation list of unit FP of element functions
一
問
そ
マ
既
既
新
覧
合
の
ス
存
存
規
照
せ
他
タ
デ
デ
登
会
応
更
メ
￨
￨
録
答
新
ン
タ
タ
テ
削
変
ナ
除
更
ン
ス
EI 出現頻度 1.0 1.0 1.0 3.0 1.0
FP
5
5
4
3
6
EO 出現頻度
0.5 0.5FP
6
6
EQ 出現頻度
1.0
0.5 0.5
FP
3
4
4
要素機能の
5
5
4
12
6
5
5
FP 単価

明
細
照
会

計
算
結
果
表
示

0.5
6
0.5
4
5

1.0
6

6

更
新
の
た
め
の
照
会

1.0
4
4

選
択
肢
一
覧

そ
の
他
照
会

帳
票
出
力

Ｃ
Ｓ
Ｖ
出
力

そ
の
他
デ
￨
タ
出
力

他
シ
ス
テ
ム
へ
の
出
力

1.0
6

1.0
3
3

0.5
6
0.5
4
5

0.5
6
0.5
4
5

0.5
6
0.5
4
5

0.5
6
0.5
4
5

6

このように，IFPUG 法による実測の経験から表 3 を作成し要素機能の FP 単価を設定したが，これらの FP 単価の妥当性について，データファンクションの FP 単価と同様に 6 つの業務ソフトウェアについて，IFPUG
法と要素見積法による実測データを比較することで評価した．その結果を表 4 に示す．
FP 単価の評価では，表 4 における FP 単価−FP 平均値が FP 平均値の‑10%〜+25%の範囲に納まっているかを妥当であるかの基準とした[4]．したがって，「その他更新」，「その他照会」，「CSV 出力」を除いて，FP 単価は妥当なものであると判断した．この範囲に納まっていない要素機能については，出現頻度を加味して評価した．例えば「その他更新」は+57.9%と大きく外れているが，一方，要素機能の出現頻度の平均値が 6.7%に対して「その他更新」の出現頻度は 1.8%と少なく，実質的な影響は少ない．同様に「その他照会」，「CSV
出力」も実質的な影響は少ないと評価できる． これらの結果より，我々が対象としているドメインにおいては，設定した FP 単価の値は妥当なものであると判断した．
6

表 4 6 つの業務ソフトウェアの実測結果
Table4 The result of the actual measurement of 6 business application software
要素機能個数
出現頻度(%)FP 合計
FP 比率(%)
FP 平均値
新規登録
既存データ変更
既存データ削除
その他更新
問合せ応答
一覧照会
明細照会
計算結果表示更新のための照会
選択肢一覧
その他照会
帳票出力
CSV 出力その他データ出力
他システムへの出力
合計

580
712
439
87
537
565
131
12
94
650
17
586
133
294
61
4898

11.8
14.5
9.0
1.8
11.0
11.5
2.7
0.2
1.9
13.3
0.3
12.0
2.7
6.0
1.2
100.0

2526
2980
1671
334
2362
2564
692
61
455
2045
59
3170
433
1285
329
20996

12.0
14.2
8.0
1.6
11.2
12.4
3.3
0.3
2.2
9.7
0.3
15.1
2.1
6.1
1.6
100.0

FP 単価

4.4
4.2
3.8
3.8
4.4
4.6
5.3
5.1
4.8
3.1
3.5
5.4
3.3
4.4
5.4
65.5

(FP 単価‑FP 平均値)
／FP 平均値(%)
13.6
19.0
5.3
57.9
13.6
8.7
‑5.7
17.6
‑16.7
‑3.2
42.9
11.1
51.5
13.6
‑7.4
221.8

5
5
4
6
5
5
5
6
4
3
5
6
5
5
5
74

なお，これまでの説明から，要素見積法で測定した FP と IFPUG 法で測定した FP は，精度を別にすれば，基本的には同じものとなることが理解できる．
４．要素見積法のシステム化(AP‑Estimate)
見積の容易化，見積結果の蓄積らを目的に，見積支援システム AP‑Estimate を開発した．本章では AP‑
Estimate の構成，機能について説明する．
４．１ AP‑Estimate の構成

AP-Estimateサーバー

図 2 に AP‑Estimate の構成を示す．

見積結果管理部

バーと複数のクライアント PC から構成され，には見積 DB が接続されている．見積を行うプ
ロジェクト管理者や開発者は，クライアント
PC から必要な情報を入力して見積結果（FP）を得る．また，この結果は見積 DB に格納される．見積技法の開発を担当している生産管理部

見積者

クライアントPC

登録AP‑Estimate は図 2 で示すように，1 台のサーイントラネットを介して通信を行う．サーバー

Intranet

アクセス制御

取込

登
録
・
取
込
処
理
部

要素見積法による規模見積
トランザクションファンクションの計測
バージョン比較データ
ファンクションの計測
規模比較処理部

見積DB（RDB）

表示処理部
プロジェクトA
見積結果
Ver.1

見積結果
Ver.2

収集

プロジェクトB
見積結果
Ver.1

生産管理部門

・・・・

見積結果
Ver.2

分析

クライアントPC

改善・・・・

図 2 AP‑Estimate の構成
Fig.2 The structure of AP‑Estimate

門は，見積 DB に格納されている多くの見積結果を分析し，例えば要素機能の FP 単価へのフィードバックらの見積精度の改善を実施する．
４．２ AP‑Estimate の機能（１）要素見積法のサポート
利用者は，図 3 で示すように，クライ
アント PC から各要素機能の個数を入力することによりトランザクションファンクションの FP を算出できる．同様に図 4 で示すように，ILF, EIF の個数を入力することによりデータファ
ンクションの FP を算出できる．
（２）見積結果の蓄積
見積結果を見積 DB に格納する．見積はプロジェクト毎に実施するが，企画段階，開発の図3 トランザクションファンクションのFP算出のための入力例
Fig.3 An example of input operation for calculation FP
of transaction functions7前段階，業務要件設計終了以降等、複数回，実施することが多いと考えられるので，プロジェクト名，格納した年
月日及び時刻を見積結果に付加し，区別できるようにした．
見積実施時期で区別された各見積結果
をバージョンと呼ぶ．なお，業務要件
設計終了以降は IFPUG 法によって見積を行うことが多図4 データファンクションのFP算出のための入力例
Fig.4 An example of input operation for calculation FP
of data functions

いと考え，AP‑Estimate では IFPUG 法による見積結果も蓄積できるようにしている．
（３）バージョン比較

バージョン間を比較し，差異を分析することにより，より精度の高い見積を実施できる．
（４）アクセス制御
見積結果にパスワードを付加して登録することにより，特定の人以外の参照を禁止することができる．
５．適用事例
一般に RFP に記載されている機能要件ではソフトウェアの機能仕様は明確でなく，IFPUG 法による見積は難しいと考えられている．第 5 章では，RFP に記載されている機能要件から要素見積法で規模の見積を行えることを，在庫管理ソフトウェアでの実例を用いて説明する．
５．１ 在庫管理ソフトウェアの機能要件
データに関する機能要件，業務に関する機能要件を図 5 に示す．ただし，図 5 は，業務仕様に関しては，
商品管理，入庫管理，選択肢一覧についてのみ，機能要件を示しており，他は省略してある．
５．２ FP の計測（１）データファンクショ
ンの計測
図 5 に記載されているデー
タに関する機能要件から，
ILF，EIF の個数は，それぞれ 10, 2 であることがわかるので，データファンク
ションの FP は，10×8＋2
×5＝90 と算出できる．ここで 8, 5 は，それぞれILF, EIF の FP 単価である．
（２）トランザクションファンクションの計測業務に対する機能要件
在庫管理システムの業務は，リソース管理，入出庫，共通の3つの大機能に分類．更に大機能は，次のように中機能から構成される．
リソース
管理

ユーザ管理

入出庫
管理

商品カテゴリ
ユーザ管理

共通

出庫予約

選択肢一覧の機能要件
1.各業務共通で利用される機能である．
2.商品はいくつかのカテゴリー，サブコテゴリーに分類され，入出庫情報の登録，更新時にカテゴリーやサブカテゴリーの一覧から選択する．
3.入出庫情報の登録，更新時に，商品を一覧から選択する．
4.入出庫情報の登録，更新時に，在庫のある商品一覧
から 商品を選択する．

出庫処理

商品管理
在庫照会

商品管理の機能要件
1.この管理は管理者権限のある従業員のみ実行可能である．
2.新たな商品を登録する．
3.登録された商品情報（名称，カテゴリ−， メーカー名ら）を変更，削除する．
4.新商品が一度に多重発生した場合，新商品リストから商品を一括登録する．

入出庫集計

データに関する機能要件
1.論理ファイルはRDB形式であり，個数は12である．
2.うち，更新を伴うものは10個，参照のみは2個．

選択肢一覧

入庫処理

入庫管理の機能要件
1.入庫登録時に本入庫若しくは仮入庫を選択する．
仮入庫とは入庫確定前に入庫処理を実施することである．
2.登録時の商品選択を商品コードで検索する．
3.入庫情報を一覧表示する．
4.入庫情報を商品コード別に検索する．
5.仮入庫の状況を個別に編集する．
6.登録済の仮入庫情報の確定処理が本入庫となる．

図 5 在庫管理ソフトウェアの機能要件
Fig.5 Function requirements of stock control software

共通機能である選択肢一覧と商品管理の FP を算出する．算出のやり方は，図 5 に記載されている機能要件に対して，見積者が更に想定する仕様を追加し，要素機能を抽出して，個数を数えるものである．
(a)選択肢一覧
・機能要件「2.商品はいくつかのカテゴリー，サブコテゴリーに分類され，入出庫情報の登録，更新時にカ」には，カテゴリーから選択，サブカテゴリーから選択
テゴリーやサブカテゴリーの一覧から選択する．
の 2 種類の処理があり，それぞれが要素機能「選択肢一覧」に該当するので，「選択肢一覧」が 2 個存在
する．
8

・機能要件「3.入出庫情報の登録，更新時に，商品を一覧から選択する．
」には，要素機能「選択肢一覧」
が 1 個存在する．
・機能要件「4.入出庫情報の登録，更新時に，在庫のある商品一覧から商品を選択する．
」には，要素機能「選択肢一覧」が 1 個存在する．
・したがって，選択肢一覧には，要素機能「選択肢一覧」が 4 個存在する．表 3 より，選択肢一覧の FP 単
価は 3 ゆえ，中機能選択肢一覧の FP は，4×3＝12 となる．
(b)商品管理・機能要件の「2.新たな商品を登録する．
」には，要素機能「新規登録」が 1 個存在する．
・機能要件の「3.登録された商品情報（名称，カテゴリー，メーカー名ら）を変更，削除する．
」には，商品を選択し，その商品の登録情報を照会し，変更若しくは削除を行う処理が想定される．商品の選択のうち，カテゴリー，サブカテゴリーからの選択は共通機能の選択肢一覧に該当する．したがって，要素機能「一覧照会」，「明細照会」，「既存データ変更」，「既存データ削除」が各 1 個ずつ存在する．
・機能要件「4.新商品が一度に多重発生した場合，新商品リストから商品を一括登録する．
」は，要素機能「新規登録」が 1 個存在する．
・したがって，要素機能「新規登録」が 2 個, 「既存データ変更」が 1 個, 「既存データ削除」が 1 個,
「一覧照会」が 1 個，
「明細照会」が 1 個であり，FP は 2×5＋1×5＋1×4＋1×5＋1×5＝29 となる．
他の中機能についても，同様の方法で FP を算出できる．
６．評価（１）要素見積法の精度
要素見積法の精度の評価では，要素機能の FP
単価の精度評価と，要素機能の抽出精度の 2 つの面から行う必要がある．
(a)FP 単価の精度
要素見積法では，各要素機能の FP 単価を表 2の FP 単価の列に示すように設定している．したがって，この FP 単価の設定値が要素見積法の精度に影響を与えると考えられる．この精度分析も，第 3 章で要素機能の FP 単価の評価と同時に行った．図 6 は，6 つの業務ソフトウェ
アについて，IFPUG 法で計測した FP を 100%と

図 6 要素見積法の精度分析
Fig.6 Accuracy analysis of element sizing method

して，要素見積法で算出した FP を評価したものである．図 6 に示すように，要素見積法は，IFPUG 法に対し，‑4%〜+18%の範囲に納まっていることを確認できた．
(b)要素機能の抽出精度
要素見積法では，開発の前段階において，RFP に記載されている機能要件から要素機能を精度高く抽出できることを，出張旅費精算を行うソフトウ
ェアを例にとり評価する．RFP では，出張旅費精算ソフトウェアの機能要件について，表 5 の程度しか示されていないことは，よくあることである．

表 5 旅費精算ソフトウェアの RFP
Table5 RFP of travel expense reimbursement software機能1)事前に登録しておいた出張案件から，精算したい案件を選択する．
2)旅費に関する事項を入力しシステムに登録する．
3)登録した旅費精算の内容を後で修正できる．
4)領収書の提出などのために，旅費精算書という帳票を出力する．

IFPUG 法や NESMA FP 概算法では，この情報からトランザクションファンクションを抽出することになる。
手法に習熟していない人は，表 6(1)のように見積る可能性が高く，これでは過小見積となってしまう。一
方，見積手法に習熟している人は，機能の説明とトランザクションファンクションの関係を把握して，表6(2)のような適切な見積を行うが，ここまで習熟するには一定の経験を必要とする．IFPUG 法や NESMA 法で，
9このような習熟した考え方にたどりつけない要因として以下の 2 点があると考えられる．

ない．

表 6 IFPUG 法または NESMA 法による見積結果
Table6 Estimation result by IFPUG method or NESMA method(1)未習熟者の見積
機
能1)事前に登録しておいた出張案件から，精算したい案件を選択する．
2)旅費に関する事項を入力しシステムに登録する．
3)登録した旅費精算の内容を後で修正できる．
4)領収書の提出などのために，旅費精算書という帳票を出力する．

・開発の前段階での見積では，EO(2)習熟者の見積･「2 段階の照会」，「修正の陰に削除あり」等，いわゆる機能説明の行間にあたるものを，EI，EO，EQ のファンクションタイプの定義だけから想起することは容易でかEQかの判別は難しい．何故ならEQではなくEOとなる要件は「処理中に計算が含まれる」か「データファンクション更新を伴う照会である」のいずれかであるが，いずれも，その時点では明確でないこ
とが多い．

見積結果
EQ×1
EI×1
EI×1
EO×1
FP 合計:17

習熟者の考え方
1)精算したい案件を選択するには，まず，条件入力→候補一覧というステッ
プがあり，続いて 1 件選択→精算案件内容表示となる．即ちここには２つの照会が存在し，さらに前者は計算を伴う可能性が高いので EO と判断できる．
2)文面どおり，登録のトランザクションファンクションがあると判断する．
3)修正するには登録した内容を表示する必要がある．その表示は 1)のケースと同様に 2 段階の照会となる．また，修正には削除機能も含まれると解釈できる．
4)帳票の出力は通常計算を伴うので EO と判断できる．

見積結果
EO×1

EI×1
EO×1
EO×1
EI×2
EO×1
FP 合計:32

要素見積法での見積結果は表 7 のようになる．表 7 で示すように，要素機能は具体的な機能を表すので，その機能に関連する要素機能が想起しやすく，要素機能の抽出漏れを防止する
ナビゲーションとしての役割を果たしていることがわかる．
こ の よ う に ， IFPUG 法 や
NESMA 法等に比べて，要素見
積法は見積の初心者であってもトランザクションファンク
ションの抽出を容易に行うこ

表 6(1),(2)の FP 合計の算出では EI, EO, EQ の複雑度を 中 と仮定している．
表 7 要素見積法による見積結果
Table7 Estimation result by element function estimation method
要素見積法での考え方
1)「案件の選択」とあるので案件を表示する 明細照会 が洗い出せるが 明
細照会 があるなら 一覧照会 も存在するのではないか，ということが想起される．
2)旅費精算の登録は 新規登録 であるが 新規登録 があると 既存データ
変更 や 既存データ削除 を伴うことが多い．変更や削除は 3)で示されているのでそちらで計上する．
3)修正が 既存データ変更 で，変更があれば 既存データ削除 も存在すると想起される．また 更新のための照会 という要素機能種別により，変更・削除には登録内容の照会を伴うことが想起され，それが 1)のケースと同様に 2段階の照会となるかどうかという連鎖思考に結びつく．
4)帳票の出力は EQ である可能性もある．早期見積時点では EO か EQ かは判断がつかないことが多いが，要素見積法では EO か EQ かは判断せず 帳票出力 として見積る．

とができる．

見積結果
一覧照会
明細照会
新規登録

既存データ変更
既存データ削除
一覧照会
明細照会
帳票出力

FP 合計:40（２）その他の評価
AP‑Estimate により規模の見積を実施した開発者に，AP‑Estimate の効果についてアンケートをとり，次のような評価を得た．
(a)各要素機能の個数の分布を評価することで，特定の要素機能の個数が多すぎる，少なすぎるということが判断でき，見積誤りを防止できる．
(b)IFPUG 法では，トランザクションファンクション，データファンクションの複雑度の評価に時間を費やすが，要素見積法では複雑度の評価が不要である．実際にソフトウェアの FP を，IFPUG 法と要素見積法の 2つの技法で計測したところ，要素見積法の計測速度は IFPUG 法に対して 3 倍〜5 倍速かった．
７．むすび
本論文では，IFPUG 法による見積が難しいと考えられている開発の前段階でも見積が可能な要素見積法の提案と，それをシステム化した AP‑Estimate の開発を行った．第 6 章で示すように，要素見積法は，１）精度が IFPUG 法の‑4%〜+18%の範囲に納まっており，２）仕様の明確でない開発の前段階でも要素機能の抽出が容易であり，３）計測速度が IFPUG 法の 3 倍〜5 倍速く，開発の前段階での見積技法として，十分なものであることを確認できた．また，見積支援システム AP‑Estimate は，膨大な量の見積結果の蓄積ができる．し10

かも，多くのソフトウェアの見積結果，同一のソフトウェアのライフサイクルの各時点での見積結果，要素見積法や IFPUG 法ら異なる見積技法による見積結果が蓄積される．したがって，これらの膨大なデータを分析することで，より精度が高く，適用の容易な見積技法への改善が期待できる．今後は，見積結果及び実績に関するデータを十分に蓄積し，分析を行い，より精度の高い見積技法に改善していきたい．
謝辞 本研究において，多大な協力を賜りました（株）日立システムアンドサービスの加藤允基氏に，心より御礼申し上げます．
参考文献[1] H. Kerzner, Project Management, John Wiley&Sons, Inc. New York, 2001.
[2] R. Rada, J. Craparo, " Standardizing software projects," Communications of the ACM, vol.43,
no.12, pp.21‑25, Dec. 2000.
[3] Watts S. Humphrey, Managing the Software Process, Addison‑Wesley, Winthrop, 1989.
[4] B. W. Boehm, C. Abts, A. W. Brown, S. Chulani, B. K. Clark, E. Horowitz, R. Madachy, D.
Reifer and B. Steece, Software Cost Estimation With COCOMOⅡ, Prentice Hall, New Jersey, 2000.
[5] 高橋宗雄，クライアント/サーバ システム開発の工数見積り技法，ソフト・リサーチ・センター，
東京，1998.
[6] 野中誠，角瀬章広，ブカーリイサム，東基衞， 画面仕様書に基づく対話型ソフトウェアの複雑度重みつき機能規模の測定技法， 情報処理学会論文誌，vol.43, no12, pp3993‑4004, Dec. 2002.
[7] C. Jones, Applied Software Measurement, The MeGraw‑Hill Companies, New York, 1996.
[8] A. J. Albrecht,

Measuring Application Development Productivity,

Proc. of the JointSHARE, GUIDE, and IBM Application Development Symposium, pp.83‑92, 1979.
[9] 西山茂， ソフトウェア規模の見積り技術の最近の流れ‐行数による評価から機能量による評価へ‑，
情報処理学会論文誌，vol.35, no.4, pp.289‑298, April 1994.
[10] Function Point Counting Practices Manual, Release 4.0, International Function Point Users
Group, 1994.
[11] http://www.nesma.nl/[12] C. E. Walston and J. P. Winters, Applying Use Cases, 2nd Edition, Addison Wesley, Winthrop,
2001.
[13] 高橋光裕他，情報システムの規模見積り手法，電力中央研究所研究報告(R93016), 1994.
[14] 共通フレーム 98 ‐SLCP‑JCF98‑(1998 年版),SLCP‑JCF98 委員会,（株）通産資料調査会，東京，1998.

11

著者紹介
原田 晃（学生員）
1970 埼玉大・理工・数学卒．1975 名古屋大学大学院博士課程了（数学専攻）．同年（株）日立製作所入社．
基本ソフトウェアの開発に従事した後，情報システム構築の生産技術に従事．2005.6 に日本電子計算株式会社に転属し，現在に至る．情報処理学会，プロジェクトマネジメント学会各会員．
幕田 行雄
1986 千葉大・工学・機械卒．1988 同大大学院修士過程了．同年（株）日立製作所入社習志野工場に勤務．
情報・通信グループで情報システム構築の生産技術に従事した後，2005.4に日立ソフトウェアエンジニアリ
ング（株）に出向し，現在に至る．PMI会員．
石川 貞裕1984 青山学院大・理工・経営工学卒．同年（株）日立製作所入社．現在，情報・通信グループ生産技術本部に所属．エンタープライズ系システムのアプリケーションアーキテクチャ、開発技術の整備に従事．
大野 治（正会員）
1969 宇部工業高等専門学校電器工学卒，同年より（株）日立製作所コンピューター事業部に勤務.現在，情報・通信グループ事業主管兼CIO.プロジェクトマネジメント学会，情報処理学会各会員．
井上 克郎（正会員）
昭54阪大・基礎工・情報卒．昭59同大大学院博士課程了．同年同大・基礎工・情報・助手．昭59〜昭61ハワ
イ大マノア校・情報工学科・助教授．平1阪大・基礎工・情報・講師．平3同学科・助教授．平7同学科・教授．平14阪大・情報・コンピュータサイエンス・教授．工学博士．ソフトウェア工学の研究に従事．情報処
理学会，日本ソフトウェア科学会，IEEE，ACM各会員．
楠本 真二（正会員）
昭63阪大・基礎工・情報卒．平3同大学院博士課程中退．同年同大・基礎工・情報・助手．平8同学科講師．
平11同学科助教授．平14阪大・情報・コンピュータサイエンス・助教授．博士(工学)．ソフトウェアの生産
性や品質の定量的評価，プロジェクト管理に関する研究に従事．情報処理学会，IEEE，IFPUG，PM各会員．

12

【英文アブストラクト】
ABSTRACT. In the development of the business application software, it is considered to be very
important to estimate the development cost and schedule at the early stage, which the function
specification is yet unconfirmed. To figure out the development cost and schedule, we firstly
estimate the size of business application software, and then make an additional consideration of
the system characteristics such as reliability.
Recently, the function point method, which estimates the size of business application software
by quantifying its functionality, has been in widespread use. However, there are somedifficulties in estimating the size at the early stage of software development by using thefunction point method. In this thesis, we report on the proposal of the early estimation
technique based on the function point method and its systematization. After applying it to a lotof projects, we gained a satisfactory result in terms of accuracy and simplicity.
【英文キーワード】[KEYWORD]
software size estimation, function point, FP, project management, business application software【図及び表ネーム】
図 1 ソフトウェアライフサイクルと見積時点の関係
Fig.1 Relation of software life cycle and the timing for software sizing
図 2 AP‑Estimate の構成
Fig.2 The structure of AP‑Estimate
図 3 トランザクションファンクションの FP 算出のための入力例
Fig.3 An example of input operation for calculation FP of transaction functions
図 4 データファンクションの FP 算出のための入力例
Fig.4 An example of input operation for calculation FP of data functions
図 5 在庫管理ソフトウェアの機能要件
Fig.5 Function requirements of stock control software
図 6 要素見積法の精度分析
Fig.6 Accuracy analysis of element sizing method
表 1 未調整 FP 算出表
Table1 Calculation table of unadjustment FP
表 2 要素機能一覧
Table2 List of element functions
表 3 要素機能毎の FP 単価表
Table3 List of unit FP of element functions
表 4 6 つの業務ソフトウェアの実測結果
Table4 The result of the actual estimation of 6 business application software
表 5 出張旅費精算ソフトウェアの RFP
Table5 RFP of the travel expense reimbursement software
表 6 IFPUG 法または NESMA 法のよる見積結果
Table6 Estimation result by IFPUG method or NESMA method
表 7 要素見積法による見積結果
Table7 Estimation result by element function estimation method13英文著者紹介
Akira Harada
Japan Information Processing Service Co., Ltd., IT Planning and Support Division
2-4-24 Toyo, Koto-ku, Tokyo, 135-8388, Japan
Ikuo Makuta
Hitachi Software Engineering Co., Ltd., Process Improvement Technology Center
4-12-7, Higashishinagawa, Shinagawa-ku, Tokyo, 140-0002, Japan
Sadahiro Ishikawa
Hitachi, Ltd., Information and Telecommunication Systems, Engineering Support Division
Hitachi Systemplaza Shinkawasaki 890 Kashimada, Saiwai-ku,
Kawasaki, Kanagawa, 212-8567, Japan
Osamu Ohno
Hitachi, Ltd., Information Technology Division.
6, Kanda-Surugadai 4-Chome, Chiyoda-ku, Tokyo, 101-8010, Japan
Shinji Kusumoto
Department of Computer Science Graduate School of Information Science and Technology
Osaka University
1-3 Machikaneyama-cho, Toyonaka-City, Osaka 560-8531, Japan
Katsuro Inoue
Department of Computer Science Graduate School of Information Science and Technology
Osaka University
1-3 Machikaneyama-cho, Toyonaka-City, Osaka 560-8531, Japan

14