はじめに

見積りの妥当性について説明してほしいと言われ返答に窮した経験はないでしょうか。

今までソフトウェア業界ではシステム開発の価格や原価を説明するための尺度として、人月やプログラム行数が多く使われてきました。これらの尺度は、発注側と受注側で、開発環境や開発方法についての共通認識が確立している場合は有効でしたが、昨今これらが多様化するにつれ、人月やプログラム行数による見積りでは共通認識が得られにくくなっています。なぜならば、人月やプログラム行数は実装方法により左右され、見積りの入力情報である発注側の要求仕様との関連が希薄になってきているからです。

そこで、システム開発の上流において何を作るかという視点で、要求仕様のボリュームについて共通認識を得るためのツールとして、ファンクションポイント法（以下FP法）をシステム開発の見積りに活用することの有効性について述べます。

ソフトウェアシステムの見積りとは

　ソフトウェアシステムの開発コストや開発期間を見積る際は、システムに対する要求仕様から規模、工数、コストへと展開する方法が一般的です。

（1）仕様の補完

上流工程においては要求仕様の詳細は不明確なことが多く、見積りを行う前に要求仕様を補完しなければなりません。この仕様の補完は見積り方法によらず必要な作業であり、この作業には業務ノウハウや類似システムの経験が求められます。

（2）規模見積り

補完された要求仕様から規模を見積ります。

（3）工数見積り

見積った規模に対して生産性を乗じて工数を見積ります。その際に非機能要件や実現方法による影響を反映します。

（4）開発コスト、開発期間の見積り

工数から人件費やその他の経費、各作業の所要期間等から、開発コストと開発期間を見積ります。

規模見積りにおけるFP法の位置づけ

システムの要求仕様は機能要件と非機能要件に分けられます。機能要件は、利用者の要求を満たすためにソフトウェアが実現しなければならない、利用者の業務および手順に関する要件です。非機能要件は機能要件以外の要求仕様であり、性能、信頼性、セキュリティ等に関する要件を指します。FP法は、機能要件の大きさを定量化する手法であり、非機能要件も含めた実装結果であるプログラム行数を見積る方法ではありません。

FP法による規模見積りでは、仕様補完された機能要件にFP法を適用しFP数を見積ります。一方プログラム行数による規模見積りでは、補完された機能要件に、実装方法を想定し出来上がりのプログラム行数を見積ります。この見積り作業では、機能要件だけでなく非機能要件も入力となり、実装方法に関する経験や知識に基づく推定が必要となるため、標準化は難しくなります。

FP法による規模見積りのステップ

広く国内外で使用されているFP法であるIFPUG法を使用した場合の、規模見積りの概要は以下の通りです。

• ○仕様補完した機能要件から、ファンクションタイプを抽出します。
• ○各ファンクションタイプの複雑度を判定してFPを算定します。
• ○各ファンクションタイプのFPを集計します。

ファンクションタイプは外部入力（EI）、外部出力（EO）、外部照会（EQ）、内部論理ファイル（ILF）、外部インターフェースファイル（EIF）の5つです。各ファンクションタイプの大きさやFPの算定基準は測定ルールにて定められているので、見積り作業を標準化できます。

コミュニケーションツールとしてのFP法

FP法を見積りにおいて活用すると次のようなメリットがあります。

（1）コミュニケーションがとりやすい

FP法による見積りは、“何を作るか”という機能要件そのものを定量化するため、利害関係者間の共通認識を醸成するコミュニケーションツールとして有効です。

（2）仕様補完しなければならない情報が明確になる

FP法による見積りでは、その入力情報が測定規則によって明確になっているため、仕様補完において何を補完すべきかが明解であり、利用者に何を聞くべきかをガイドしてくれます。

（3）非機能要件を分離できる

FP法による見積りでは、非機能要件を機能要件から分離させて別々に議論するので、利害関係者間のコミュニケーションの焦点を絞ることが可能となります。

（4）異なる実装方法の生産性を比較できる

プログラム行数をベースとした生産性では、行数自体に実装方法による影響が含まれているため、異なる実装方法間の生産性を比較できませんが、FP数をベースとした生産性では比較することができます。同じ機能を違う言語で開発した場合、下表に示すとおり、プログラム行数による生産性では比較できません。実装方法が日々進歩する現状においては、FP数をベースとした生産性データを蓄積し、見積りに活用してください。

このようにFP法による見積りは、技術的な知識のない人も含めて、利害関係者間のコミュニケーションを促進し共通認識を醸成する有効なツールです。また実装方法に踏み込まないため習得も容易です。

FP法による見積りの注意点

FP法は万能ではありません。下記の事項に注意し見積りに活用してください。

（1）適用分野

IFPUG法をはじめとしたビジネスアプリケーション向きのFP法は、ソフトウェアシステムへの入出力に着目し、機能要件の大きさを定量化します。よって、内部ロジックや処理の複雑さ等は反映できません。

（2）FP当たりの生産性は一律ではない

FP当たりの生産性は一律に決められるものではありません。非機能要件の厳しさ等によって生産性に数倍以上の開きが出てきます。

“当てる見積り”から“見える見積り”へ

メインフレームの時代には、比較的変動の少ない実装方法を用いて、プログラミング技術者の経験や勘に基づいて見積りが行われていました。

しかし昨今は、オープン化に伴いソフトウェアシステムを構築する上での実装方法の選択肢が増加する一方、ソフトウェアシステムが社会に与える影響が大きくなり、性能や信頼性、セキュリティ等の非機能要件に対する要求レベルも厳しくなってきています。したがって、ソフトウェアシステムの開発リスクが増大し、見積りは一段と難しくなっています。このような現状において、まず利害関係者間で共通認識を持ち、要求仕様をコントロールしていくための“見える見積り”が重要となってきています。

ITスペシャリスト登場
自動車SCM改革への挑戦が生んだIT戦略デザイン手法へ