規模見積もりの女王様「FP見積もり」【前編】：山浦恒央の“くみこみ”な話（36）
「ソフトウェア技術者の最高の能力は、見積もりだ！」――今回は、積み上げ法の中でも、少しアカデミックな雰囲気のある「FP（Function Point）」による規模見積もりについて解説。まずは、FPの概要・特長を理解しよう。
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。
今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。
見積もり技法は「類推法」「積み上げ法」「パラメトリックス法」の3つに分類することができます。前回は、世界のソフトウェア開発プロジェクトでよく使う「積み上げ法」に触れ、最も人気のある「LOC（Lines of Code）」による見積もりを解説しました。
今回から、同じ積み上げ法の中でも、少しアカデミックな雰囲気のある「FP（Function Point）」による規模見積もりに進みます。かなりの大ネタですので、今回と次回の2回に分けて紹介していきます。
FP見積もりの概要
FPという言葉をよく聞くようになったのはこの10年のような気がしますが、実は、意外に歴史が古く、IBMのアレン・J・アルブレヒト（A.J. Albrecht）氏が1979年に考案した手法です。FPが目的とするのは、「仕様をベースにして、設計方式やプログラミング言語に依存せずに、開発対象となるシステムの“機能”の規模を『FP』という単位で計測すること」です。
FPという言葉を聞いて、「特別な知識が必要」「計算に1週間はかかる」など、否定的に考える人が少なくありません。これは一種の“食わず嫌い”といえます。FPにはいろいろなバリエーションがあり、30分程度で理解でき、計算に1、2時間しかかからない“お手軽版”があります。このお手軽バージョンの正式名称を「FP試算法」と呼び、計算が簡単な割に意外と精度が高く（LOCより高精度）、オブジェクト指向との相性が抜群という優れモノです。今回と次回でFPの基本に触れつつ、FP試算法の具体的な手順について述べます。
FPでの「機能」とは？
FPという言葉から、「機能」の数を計測して規模計算を実施している印象を受けますが、実は、データ構造から規模予測をしています。すなわち、「機能」の規模は、データ要素（ファイルの数やデータ要素数）から測定できるとの見解を取っているのです。「対象開発のシステムが扱うファイルやデータベースの種類が多いと、開発規模が大きくなる」が基本姿勢です。
LOCがプログラムの制御の流れをベースにして規模を見積もるのに対して、FPは、ソフトウェアが扱うデータ構造から大きさを予測します（ですので、“ファンクション・ポイント”という名前は、私としては、少し風呂敷を広げ過ぎでは？ と思います。“データポイント”あたりが妥当ではないでしょうか？）。
FPでは、データ要素のみ考慮し、内部処理の複雑性は考慮していません。従って、データ処理中心のシステムとは相性が良く、特に、オブジェクト指向とは抜群の相性を誇ります（また、LOCとオブジェクト指向の相性の悪さを指摘する研究者もいます。このあたりの事情のせいか、オブジェクト指向による設計が盛んになった時期と、FPの人気が上昇した時期が重なるように思います）。
その半面、計算のお化けのようなプログラム、例えば、図形処理、OSのような制御系、シミュレータ、統計計算とは相性が良くない（悪い）というのが一般の理解です。ただし、これを是正するため、いろいろな改良モデルが発表されています（LOCに比べると、FPの人口はまだまだ少なく、その悔しさがFP愛好家のエネルギー源になっているように思います。FPには熱烈な研究者が多く、いろいろなモデルや改良版を精力的に発表しています。この熱意はLOCには見られません）。
FPでは、開発対象となる情報処理システムの「機能」は、プラットフォームや実現方法が変わっても、変化しないとの立場を取っています。ただし、「機能」は変化しなくても、実現するための内部仕様、工法、品質要求が変化すると、開発工数、開発期間、コストが変わります。同じ2階建ての家を建てる場合であっても、豪華な建築材料を使い1mmの狂いもなく作るのか、あるいは、最低限、雨風を凌げればよいという家を作るかでコストや建築期間は大きく変わります。また、見習いの大工さんが2人で作るのか、経験20年の棟梁が10人で建築するのかでも大きな違いが出るでしょう。FPは、この「不変の機能」を計測することを目的としています。
FPと知能指数
LOCの単位は、「行」です。一方のFPには、知能指数や貨幣単位と同様、単位はありません。このあたりから、話は少しずつ強引というか、怪しさが出てきます。
知能検査では、「知能とは何か？」を定義していません。逆に、「この検査方法で計測した数値が知能指数だ」と大上段に構えた定義をしています。「オレがルール・ブックだ」というわけですね。
知能測定の場合、知能を構成していると思われる要素、例えば、記憶力、理解力、想像力を個別に測定し、重みを付け、標準化して算出します。従って、FPには、知能指数と同じ危険性があると指摘する人もいます（とはいえ、きちんとした証明が必須の理学とは異なり、工学の場合は、科学的証明がなくても役に立つのなら受け入れるとの土壌があり、FPの科学的な根拠を求めない人も多数います）。
FPの長所と短所
LOCによる見積もりの強力なライバルがFPです。以下、LOCと比較しながら、長所と短所を解説します。
（1）測定方法がきちんと手順化されている
LOCの場合、「コメント行を含む・含まない」「複数行にまたがる命令語の扱い」「1行に複数命令を記述した場合の扱い」「ヘッダー行の扱い」などが会社や組織によって異なりますが、FPの場合、非常に明確で、紛れがありません。
（2）自動算出ツールがなく、手計算に頼らざるを得ない
LOCをカウントする場合、専用のツールが用意されていますが、FPの場合、手計算に頼らざるを得ません。これが、FP愛好家の劣等感の源になっている感があります。また、爆発的にFPが普及しない最大の原因でしょう。
（3）評価者によるばらつきが少ない
LOCは、見積もる個人により、±50％以上の誤差が出ますが、FPの場合、評価者による違いは、10％前後だといわれています。これは、計算のベースになるファイル、データ要素に客観性があるためで、顧客に見積もり結果を見せる場合、大きな説得力があります。
（4）FPからLOCへ変換できる
計算したFPは、ソースコード行数に変換することが可能です。ソフトウェア工学の大家、Capers Jones氏によりますと、1FPは、COBOLで記述すると100行、C++では50行と述べています。VB（Visual Basic）では70行、Javaでは35行とのデータもあります。推定したFPを基に、工数、開発期間、コストへの変換が可能となります。
FPの種類
FPを算出する方法にはいろいろあります。代表的なのは、以下の3つです。
（1）IFPUG法
最も普及している方式がこれで、通常、FPといえば、この“フル・バージョン”を指します。開発対象のシステムが扱うファイルだけでなく、入出力データ、参照データも全て考慮するため予測精度は高いのですが、計算が非常に煩雑で1週間程度の時間がかかります。一般のFPのセミナーでは、この方式を解説することが多く、受講生が「FPは難しい、時間がかかる」とのイメージを持つ原因となります（なので、本連載では扱いません。余力があったら、自分で学習してみてください）。ソフトウェアの開発フェーズの比較的後ろの時期、例えば、外部設計フェーズ以降で適用できます。
（2）FP概算法
IFPUG法の簡略版です。とはいっても、うたい文句ほど簡単ではありません（なので、IFPUG法と同様、本連載では扱いません）。適用可能な時期は、IFPUG法より上流で、要求仕様定義、設計フェーズ以降となります。
（3）FP試算法
最も簡略版のFP算出法がこれです。開発対象システムが、どんなファイルやデータベースを使うかだけを考えてFPを予測するため、複雑な基礎知識は一切不要。また、計算も1、2時間もあれば可能です。開発対象のシステムの概要しか決まっていないシステム化計画の時期や、要件仕様定義フェーズから適用可能です（社長2人がゴルフをしながら、「12月1日までに、こんなシステムを開発してもらいたいんだけど」「ああ、いいですよ」という程度の話から見積もることも可能です）。推定の精度は、“IFPUG法＞FP概算法＞FP試算法”の順に高くなり、簡単さは逆（FP試算法＞FP概算法＞IFPUG法）になります。FP試算法は、非常に強力な推定法であり、本連載では、このFP試算法だけを扱うこととします。
次回は、FP試算法の具体的な計算手順について解説します。お楽しみに！ （次回に続く）
東海大学 大学院 組込み技術研究科 助教授（工学博士）
関連キーワード
デスマーチ | 組み込み開発 | 組み込み開発プロセス改善 | 組み込み開発の混沌から抜け出そう | 現場の声からプロセス改善を深掘りする | 山浦恒央の“くみこみ”な話 | バグ | 開発プロセス | ソフトウェアテスト | システム開発
Copyright © ITmedia, Inc. All Rights Reserved.
デスマーチ・プロジェクトでの正しい手の抜き方