前々回、前回と2回にわたって、ファンクションポイント法の有効な使い方を説明してきましたが、かといって決して万能な手法というわけではありません。ファンクションポイント法には不得意な分野もあります。以下、ファンクションポイント法の不得意な分野について説明しましょう。
処理の複雑さをうまく反映できない
ファンクションポイント法では、ルールに従ってファンクションを3段階に分類すると説明しましたが、その分類ルールでは処理の複雑さが考慮されていません。ですから、とても複雑なロジックを伴う入力機能と、単純な入力機能が同じFP数になってしまうこともあります。
科学技術計算やシミュレーションなど、複雑な処理が主体となるシステムにファンクションポイント法を適用すると、過少な規模となります。ファンクションポイント法は、入出力を主体としたビジネスアプリケーションに適した手法なのです。
細かな管理は苦手
ファンクションポイント法はファンクション(機能)の単位がユーザーにとっての最小単位であるため、細かい管理には向きません。
例えば、モジュールはFPの最小単位よりも小さいので、モジュールごとのFP数を出すことはできないのです。よって、モジュール単位の品質管理にファンクションポイント法を尺度として使用することはできません。
ファンクションポイント法は良くも悪くも粗い尺度ですので、細かい仕事は苦手です。
非機能要件は守備範囲外
ファンクションポイント法は機能要件を定量化する技法です。これはISOやJISで決められた定義です。よって、性能や信頼性、セキュリティなどの非機能要件をFP数で表すことはできません。
しかし、非機能要件のグレードによってFP当たりの生産性は大きく異なります。FP数を出せば標準的な生産性によって工数を見積もれるというような単純な話ではありません。
この場合、非機能要件のグレードを考慮した生産性を使用するか、機能要件にかかるコスト、非機能要件にかかるコストと分離して見積もるか、といった対処が必要となります。
ファンクションポイント法と「生産性のパラドックス」
そもそもファンクションポイント法は「生産性のパラドックス」に疑問を覚えたアラン・オールブレクト氏が提唱した手法に端を発しています。
生産性のパラドックスとは、ソフトウェアの生産性をプログラム行数/人月などの単位で表現すると、冗長なコーディングをしてプログラム行数を稼いだ人の方が、コンパクトで効率的なプログラムを書いた人より生産性が高く見えてしまうという現象を指します。
その昔はプログラマーによる違いでしたが、昨今は開発環境の違いによって生産性のパラドックスが起きています。つまり、高水準言語を使用して少ないプログラム行数で実装すると、生産性が低く見えてしまうということです。
これでは新しい技術を採用した際の効果が見えないだけでなく、プログラム行数の作成だけがシステム構築コストとして見られてしまうため、過少見積りの原因ともなってしまいます。執筆者プロフィール
藤貫美佐 (Misa Fujinuki)
株式会社NTTデータ SIコンピテンシー本部 SEPG 設計積算推進担当 課長。IFPUG Certified Function Point Specialist。日本ファンクションポイントユーザー会の事務局長を務める。
『出典:システム開発ジャーナル Vol.5(2008年7月発刊)』
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは
異なる場合があります。ご了承ください。
