規模見積もりの女王様「FP見積もり」【後編】：山浦恒央の“くみこみ”な話（37）
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、計算手順が30分で理解できて、システムの分析やFP計算も1〜2時間程度で可能な「FP試算法」について説明する。
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。
今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。
見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回は、積み上げ法の代表である「FP（Function Point）」の概要を解説しました。
FPは、「LOC（Lines of Code）」見積もりに比べ、精度は高いのですが計算が複雑怪奇なので、一般のソフトウェア技術者から敬遠される傾向にあります。今回は、計算手順を“30分”ほどで理解できて、システムの分析やFP計算も1〜2時間程度で可能な「FP試算法」について述べます。FP試算法は、ソフトウェア開発の見積もりで非常に強力な武器になるはずです！
FP試算法の概要
FPは“ファンクションポイント”という字面から、「機能を直接カウントしている」と思いがちですが、実は「データの種類や数から開発規模を推定している」にすぎません。FPによる規模見積もりでは、まずこの点を理解しておく必要があります。
また、LOCが制御構造から規模を見積もっているのに対し、FPはデータ構造から規模を見積もっています。つまり、FPでは開発対象システムのデータやファイルが明らかになれば（あるいは、クラス設計がある程度明確になれば）、開発規模を見積もれることになります。システム設計の初期段階では、処理方式やアルゴリズムは決まっていませんが、処理対象となるデータやファイルは明らかになっている場合が少なくありません。そのため、FP試算法を適用すれば“初期段階での見積もり”が可能になります。
FP試算法による規模見積もりの具体的な手順は以下の通りです。
- 内部論理ファイルの数をカウント
- 外部インタフェースファイルの数をカウント
- 「内部論理ファイル数×35」と「外部インタフェースファイル数×15」を計算（これが総FP数になる）
- 総FP数を基に、使用するプログラミング言語でのステップ数に変換
以下に、詳細のステップを解説します。
1．内部論理ファイルの数をカウント
開発対象システムのうち、生成・更新・削除・読み出しをするファイルを「内部論理ファイル」と呼びます。例えば、「これまで、手作業で実施していた『学生成績管理』をコンピュータ化したい」との学校側の要望を受けて、ソフトウェア開発会社が学生成績管理システムを作るとします。このシステムが使用するファイルの中で、システム自身が新規生成、更新、削除するデータが内部論理ファイルです。まずは、この内部論理ファイルをカウントします。学生成績管理システムにおける具体的な内部論理ファイルには、以下のものがあります（図1：左）。
（1）総合成績情報（学生別の成績を「優」「良」「可」「不可」で表示したもの）
（2）出席情報（学生別の欠席、遅刻のデータ）
（3）レポート情報（100点満点で表したレポート成績の生データ）
（4）定期試験情報（100点満点で表したレポートの成績の学生別生データ）
（5）履修科目情報（学生が履修している科目のデータ）
（6）ヘルプファイル
（7）メッセージファイル
（8）システム更新履歴（学生成績管理システムのバージョン情報を記したファイル）
この「システムが使うファイルの一覧」は、仕様書の最初に「データ構成図」として必ず記述してあるものですので、過去の類似システムの仕様書を参考にするとよいでしょう。あるいは、クラス設計からもカウント可能です。
2．外部インタフェースファイルの数をカウント
開発対象システムの外にある別システムが管理しているファイルの中で、開発対象システムが参照するファイルを「外部インタフェースファイル」と呼びます。これは外部のシステムが管理しているファイルなので、開発対象システムでは、生成・更新・削除はせず、単に“参照（あるいは、借用）する”だけです。例えば、前述の学生成績管理システムの場合、外部インタフェースファイルとして、以下のものがあります（図1：右）。
（1）学生情報（各学生の所属学科、氏名、連絡先、生年月日などの一般情報を格納したデータで、一般的には学務課が管理している）
（2）学生別履修科目（各学生がどんな科目を履修しているかのデータ。これも一般的に学務課が管理している）
（3）履修科目情報（同上）
（4）担当教員情報（教員がどの科目を担当しているかのデータ。一般的に教務課が管理している）
3．「内部論理ファイル数×35」と「外部インタフェースファイル数×15」を計算
「1．内部論理ファイルの数をカウント」でカウントした内部論理ファイルの数（＝8）に“35”を乗じ、「2．外部インタフェースファイルの数をカウント」でカウントした外部インタフェースファイルの数（＝4）に“15”を乗じ、その和を求めます。これが、FP試算法による「総FP数」です。
この「35」や「15」は、固定の定数だと理解し、無条件にそのまま乗算してください。図1の例では、以下のようになります。
35FP × 8ファイル ＋ 15FP × 4ファイル ＝ 340FP
すなわち、FP試算法によると、この学生成績管理システムの総FP数は「340」になります。
4．総FP数を基に、使用するプログラミング言語でのステップ数に変換
前回、“FPはソースコード行数（LOC）に変換可能”と述べました。ソフトウェア工学の研究によりますと、1FPは、COBOLで記述すると100行、C++では50行、Visual Basicでは70行、Javaでは35行とのデータがあります。今回、例として挙げた学生成績管理システムをC++で記述した場合のステップ数は、以下のようになります。
340FP × 50 ＝ 1万7000ステップ
17KLOCということは、平均的な生産性が「1000LOC／人月」とすると、約17人月であり、3人のエンジニアを6カ月投入すれば開発可能といえます。また、1人月が100万円前後としますと、1700万円ほどのコストが掛かることになります。
各組織やプロジェクトにより、FPとLOCの変換係数は異なります。これまで蓄積してきたデータを参考にすると、より正確なソースコード行数に変換できるでしょう。
IFPUG法でのFP計算
通常、FPというと「IFPUG法」という“フルバージョン”を指します。前回紹介したように、IFPUGは理解するのが大変な上に、計算も1週間程度の時間がかかります。
FP試算法では、内部論理ファイル数と外部インタフェースファイル数というデータベースの数だけをカウントしましたが、IFPUG法では、データベースの数に加え、システムに対するトランザクションの数もカウントします。すなわち、例として取り上げた学生成績管理システムでは、以下のような入力データ・出力データ・参照データも全て考慮する必要があります（図2）。
（1）外部入力
・システムの外から入るデータや制御情報
・内部論理ファイルに登録・更新されたり、システムの動作が変わる
・例えば、画面入力（キーボード入力）、通信回線、外部記憶媒体などの入力
（2）外部出力
・システム内のデータや制御情報を処理し、システムの外へ出すもの
・例えば、画面への出力（ディスプレイ出力）、プリンタへ出力、通信回線、システム外のメモリやディスク、外部記憶媒体などへの出力
（3）外部参照
・システム外からの問い合わせに従い、システム内のデータや制御情報をそのままシステム外へ出す
・この場合、内部論理ファイルへの登録・更新・削除はなく、システムの動作も不変
・例えば、「キーボードから検索条件を入力し、それに合うデータを内部ファイルから検索し、ディスプレイやプリンタへ出力する」
IFPUG法では、解析した入力データ・出力データ・参照データの複雑度を分析し、乗じる係数を微妙に変えていきます（図3）。この計算や分析が面倒なため、「FPの見積もりは難解！」といわれてきました。
しかし、トランザクションを無視し、ファイル（データベース）のみを考慮するFP試算法であれば、計算や分析が数時間で可能な上に、予測精度もLOCより圧倒的に高い（もちろん、IFPUG法よりは劣りますが）ため、極めて有用度の高い見積もり方式として活用可能です。
単一の見積もり技法に頼ると異常値が出る可能性があるため、現実的な見積もり法としては2つ以上の方式で見積もるべきです。その場合、過去のデータを基にした類推法と、FP試算法を組み合わせて見積もるとよいでしょう。
さて次回は、ソフトウェア開発において「開発工数（人月）」「期間（月数）」「開発規模（LOC）」「生産性」「品質」の5つの関係を明らかにした「SLIM」という見積もり法について解説します。
SLIMを適用すれば、例えば、開発期間を18カ月から14カ月に短縮した際の開発工数や開発規模への影響を具体的に計算できます。「18カ月かかるところを14カ月でやれ！」とムチャをいわれ、「それは無理です!!」と反論したら、上層部から「工夫もしないで、できない何ていうな！」「できない何て答えは聞きたくない!!」とドヤされた……。そんなときの“究極の反撃法”がSLIMによる見積もりです！ ご期待ください。（次回に続く）
東海大学 大学院 組込み技術研究科 助教授（工学博士）
関連キーワード
デスマーチ | 組み込み開発 | 組み込み開発プロセス改善 | 組み込み開発の混沌から抜け出そう | 現場の声からプロセス改善を深掘りする | 山浦恒央の“くみこみ”な話 | バグ | 開発プロセス | ソフトウェアテスト | システム開発
Copyright © ITmedia, Inc. All Rights Reserved.
デスマーチ・プロジェクトでの正しい手の抜き方