見積もりを作成する際に,定量的な見積もり技法を用いることがある。特に最近ではファンクションポイント法(FP法)が定着しつつあり,現場で用いられる機会も増えている。FP法はシステムの工数規模が定量的な数値となって表現されるため,発注側と受注側の双方の共通の物差しとして用いられる。また1人月当たりの生産性指標として用いられることもある。

 しかし,FP法で計測された値を過信すると大きな失敗を犯す。実際の現場でも,FP法の数値だけが一人歩きしてしまい大変な結果となったケースがある。

FP法は「ユーザーが識別しない機能」を数えない

 Dさんは,中規模SIベンダーV社の中堅社員である。数年前にFP法(IFPUG法)について外部研修を受け,見積もりの根拠として必ずFP値を提出していた。

 今回,V社は大手携帯電話会社U社から,販売店に対するリベートを支払うシステムの再構築を受注した。契約の形態としては,要件定義フェーズについては準委任契約で行い,基本設計以降については一括請負契約で行う2段階方式であった。一括請負契約分の金額については,要件定義フェーズ完了時点で再見積もりを行い,提案時点で提出した金額と合致しなければ再度V社からU社に見積もりを提出することが許されていた。

 V社はDさんをPMとするチームを構成し,要件定義に着手した。要件定義フェーズが終了にさしかかるころ,当初の合意通り,次フェーズ以降の見積もりを作成することになった。当初V社が提出した提案書に記載された見積もり金額は,U社担当のアカウントSEが過去の事例と自分の経験を基に作成したものであり,その算出に当たりDさんは全く関与していなかった。また金額の根拠について,それなりの理由書は書いてあるものの,定量的な根拠については示されていなかったのである。そのため,Dさんは当初からこの金額を疑っていた。今回,再見積もりを行うにあたり,Dさんは,得意とするFP法を用いて再見積もりを行うこととした。

 実際に見積もりを始めてみると,意外と難航することに気がついた。要件定義フェーズが完了した時点では,FPを算出するために必要な情報が完全にそろわないためであった。これまでDさんは,基本設計フェーズまでを準委任契約で行い,その時点で再見積もりを行うことが多かったのだ。

 そこでDさんはユーザーが識別する単位である,入出力画面のモックアップを作成し,ユーザー部門と大まかな合意を得ることにした。これで,FP法で算出するための最低限の情報はそろった。なお各ファンクションの複雑度については,全て「中」として算出することにした。これは「ある程度の規模以上のFPを算出する場合には,複雑度を一律『中』とした場合と,正しく複雑度を計測した場合とでも,得られたFP値の差は大きく開かないと」いうDさんの経験則からである。

 Dさんによる再見積もりの結果,FP値は約6000FPであった。そこでDさんは,見積もり金額として,FP値をV社の標準生産性(1人月=15FP)で割り返した400人月という値を算出した。これは当初アカウントSEが算出した500人月よりも20%も低い値であった。

 Dさんは自身が計算したFPに自信があったこともあり,基本設計フェーズ以降の見積もりについて,20%減額して再提出するように社内に働きかけた。V社としては,当初U社から受注した際の金額よりも減額となるためちゅうちょしたが,当初想定した利益が減額とはならないことや,何と言ってもPMであるDさんの熱意を感じ,今後のU社との関係も考慮した結果,当初提示金額よりも10%減額した金額をU社に再提出した。

 U社としては,当初見込んでいた予算の10%削減ができたことを喜び,契約を締結した。しかし,そのプロジェクトはDさんが描いていたほど順調には進まなかった。基本設計フェーズの中盤で,手数料精算を行うロジックは,そのほとんどが内部ロジックであることが判明したのだ。V社が扱う数多くの製品と,様々なサービス・メニューの組み合わせにより,手数料計算を行う必要がある。このことはDさんも理解していた。しかし,実際にはFP計算で算出対象としない「ユーザーが識別しない機能」に費やす工数が膨れあがったのである。

例えば,次のような機能である。
・製品ごとに計算する内部ロジック
・サービスごとに作成する中間ファイル
・前日の売り上げデータを抽出して本日分のテーブルにマージするバッチ
・上記内容を販売店単位で合算したり店舗ごとに分割したりする内部ロジック

 DさんはFP法算定のセオリー「ユーザーが識別しないものは,機能とは見なさない。たとえファイルや要素処理がプログラム内部で使用されようとも,それが外に見えないなら,実装方法の一つに過ぎないため数えない」に従ってFP値を算定した。しかし,今回,これが裏目に出てしまったのである。

 このシステムは,ユーザーが識別しない機能が全体の70%を超えていた。つまり,このシステムはユーザーからは見えない中間ファイルやバッチを集めて最終結果を算定する巨大バッチシステムであったと考えてもよかったのだ。

 結果的に,プロジェクトは520人月かかり,納期こそは何とか間に合わせたものの,予定工数に対して70人月の赤字となってしまった。これによって,V社内部におけるDさんの信用が落ちただけでなくFP法についても疑われることになった。