「実践ファンクションポイント法」とオブジェクト指向技術

written by

(株)エヌ・ケー・エクサ　　児玉公信

ファンクションポイント（FP）法は、ソフトウエアの規模を計測する手法の一つです。FP法では、ソフトウエアの規模を「ファンクションの規模」と見て、「ファンクションポイント」と呼ぶ単位でそれを計測します。この「ファンクション」は、データに関するものと処理に関するものに大別されます。識別された個々のファンクションについて、その「複雑さ」を評価して、定められた係数を掛けて累積します。これがFP値です。これが有効かどうかは、ここからさまざまな（プロジェクトなどの）管理指標が見積れるだろうという仮説を受入れるかどうかにかかっています（ちょっとシニカルに書きましたが）。

このような説明を聞いて、なぜこれがオブジェクト指向技術に関係があるのか、いぶかる方も多いでしょう。確かに、FP法の起源は、1975年頃の米国IBMでの活動にあるので、OOに関係がないというのはそのとおりです。しかし、現在の私たちにとっても、いえ、現在だからこそ、多様な開発環境／手法に対応した管理指標が必要なのです。そういう点では、OOと無関係ではありません....と、私もしばらくは、その程度にしか思っていませんでした。しかし、実は、もっと根元的な意味でOOと関係があるのです。

プロジェクトの早期段階では、見積りのために、「システムに割り付けられた要求」を識別します。そして、管理指標の一つとして、これを実現するためのコスト（多くは工数）を推定します。しかし、推定が実績に対して許される変動幅に収まることは、少なかったと言わざるを得ません。残念ながら、たいていの場合は、実績の方が大きくなるのです。これはなぜでしょう。あとから要求が変化したり追加されたりするからでしょうか。では、そうされないようにするにはどうすればよいでしょう。もちろん、（早期段階で）要求を凍結するというのは愚の骨頂です。

そこで私は、見積りのためにはある程度の分析が必要であると考えました。ただし、この分析に十分な時間はかけられません。FPを計測するのに必要最小限の分析でよいのです。具体的には、データのファンクションを計測するために型（タイプ）図を、処理のファンクションを計測するためにDFD（レベル0）を書けばよいということがわかりました。実際、これで直ちにFP値は求まります。それに、モデルが記述されていれば、メンバ間で理解を共有できますし、第三者のレビューが容易になります。ただ、ここで重要なことは、この2つのモデルが十分に妥当なものでなければならないということです。

そして、私はそれらを妥当なものとするためのプラクティスをいくつか提案しました。それ自身について、拙著をご覧いただくとして、ここで述べません。このプラクティスを導く過程で、OOの知見、たとえば、型図についてはFowlerのアナリシスパターンが、DFDについてはJacobsonのusecaseの考え方が非常に有効でした。特に、DFDのプロセスにおけるアクタの存在やシステム境界、外部と内部の考え方などは、「要求」を考える上で本質的なものでした。

このように妥当なモデルができることで、要求に対する理解が深まり、大きな漏れを防止できます。これによって、安定した規模の計測が得られ、それに基づいて妥当な目標値としての管理指標が得られます。そして妥当な納期が設定されて、われわれは恒常化している残業から解放されるのです。それだけではありません。FPに対する信頼性が上がれば、FP値で取引ができるようになり、現在のように費やした工数で対価を得るのではなく、ソフトウエア規模によって対価が得られるようになるのです。安く作って、規模に応じた市場の価格で売るということができるのです。つまり、高い生産性や開発力（capability）が利益に直結するのです。これが、私の考えるこの業界のあるべき姿です。

ともあれ、FP法が計測しているのは「ファンクションの規模」として表現された「要求の規模」であることはおわかりいただけると思います。すなわち、これは実装方式とは独立なのです。従来型の実装でも、OOによる実装でも、要求が同じであればFP値は同じなのです（当然，管理指標の方は実装方式に左右されます）。したがって、理屈上はOO開発の見積りも、FP法を適用できるはずなのです。実は、OO開発の事例を分析して、OO開発についても良い精度で計測できそうな見通しが得られています。

このとき、DFDに代わるものとしてusecaseが使えないかという疑問は当然です。実際、私もそう思います。しかし残念ながら、今のところ書かれたusecaseが、見積りの目的から見て妥当なのかどうかを検証することは難しいと感じています。上の事例をusecase-pointで計測してみても、うまくいきませんでした。各事例で、usecaseの大きさが一致していないのです。DFDを使うときも、粒の大きさを統制するプラクティスを得るのに工夫が必要でした。ヒントは、（少なくともFPの計測のためには）DFDを機能分割や処理手順といった仕様の観点で見てはいけないというものです。概念の観点で、アクタの持つ目的と要求の記述としてとらえなければなりません。usecaseもそうあるべきだと思うのですが、皆さん、合意していただけますか。そして、そうしたusecaseのとらえ方や大きさについての基準について、うまい工夫があったら、ぜひ教えていただきたいと思います。

著書実践ファンクションポイント法

HOME

TOP