http://monoist.atmarkit.co.jp/mn/articles/1111/16/news008.html
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工學における最重要課題の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 內部論理ファイルと外部インタフェースファイルの具體例（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）。
図2 トランザクションの具體例（1）外部入力
・システムの外から入るデータや制御情報
・內部論理ファイルに登録・更新されたり、システムの動作が変わる
・例えば、畫面入力（キーボード入力）、通信回線、外部記憶媒體などの入力
（2）外部出力
・システム內のデータや制御情報を処理し、システムの外へ出すもの
・例えば、畫面への出力（ディスプレイ出力）、プリンタへ出力、通信回線、システム外のメモリやディスク、外部記憶媒體などへの出力
（3）外部參照
・システム外からの問い合わせに従い、システム內のデータや制御情報をそのままシステム外へ出す
・この場合、內部論理ファイルへの登録・更新・削除はなく、システムの動作も不変
・例えば、「キーボードから検索條件を入力し、それに合うデータを內部ファイルから検索し、ディスプレイやプリンタへ出力する」
IFPUG法では、解析した入力データ・出力データ・參照データの複雑度を分析し、乗じる係數を微妙に変えていきます（図3）。この計算や分析が面倒なため、「FPの見積もりは難解！」といわれてきました。
図3 IFPUG法による総FP數の計算しかし、トランザクションを無視し、ファイル（データベース）のみを考慮するFP試算法であれば、計算や分析が數時間で可能な上に、予測精度もLOCより圧倒的に高い（もちろん、IFPUG法よりは劣りますが）ため、極めて有用度の高い見積もり方式として活用可能です。
単一の見積もり技法に頼ると異常値が出る可能性があるため、現実的な見積もり法としては2つ以上の方式で見積もるべきです。その場合、過去のデータを基にした類推法と、FP試算法を組み合わせて見積もるとよいでしょう。
さて次回は、ソフトウェア開発において「開発工數（人月）」「期間（月數）」「開発規模（LOC）」「生産性」「品質」の5つの関係を明らかにした「SLIM」という見積もり法について解説します。
SLIMを適用すれば、例えば、開発期間を18カ月から14カ月に短縮した際の開発工數や開発規模への影響を具體的に計算できます。「18カ月かかるところを14カ月でやれ！」とムチャをいわれ、「それは無理です!!」と反論したら、上層部から「工夫もしないで、できない何ていうな！」「できない何て答えは聞きたくない!!」とドヤされた……。そんなときの“究極の反撃法”がSLIMによる見積もりです！ ご期待ください。（次回に続く）