「こんなはずじゃ…」と多くの人が首をかしげるのが，工数見積もり。技法の値や項目が現場の実態と乖離していることがままあるからだ。そんなとき，どうすればよいのか。先達の工夫に学ぼう。
ソフトウエア開発の工数は，規模見積もりの値を「生産性係数（1人月当たりの開発規模）」で割って算出する。ただ，プロジェクトは品質要件や技術要件がそれぞれ異なるため，「変動要因」を加味し，実態に即した値に補正する。これが一般的に使われている工数見積もりのセオリーで，基準値法と呼ぶ。
規模から工数を見積もる計算式は
| 規模÷生産性係数×変動要因＝工数 |
となる。ソフトウエアの規模が「100FP」，生産性係数が「1人月当たり5FP」，変動要因が「＋20％」であれば，開発に必要な工数は「100FP÷5FP/人月×120％＝24人月」となるわけだ。
TISの井上智史氏（生産技術部 統括マネジャー）は「かけ算やわり算はテコのように利くので，値を間違えるとブレ幅が大きくなる」と指摘する。
工数見積もりでは，生産性係数，変動要因それぞれに落とし穴がある。生産性係数では，生産性係数の適用を誤る。変動要因では，標準の変動要因がそぐわない，判定基準が人によって異なる――という問題がある。現場の工夫を見ていこう。
生産性係数の適用を誤る サンプルは量より質と心得る
生産性係数は，過去の開発実績を基に設定する。ところが，現場に開発案件が無尽蔵にあるわけではないから，少ない実績の値を平均して係数にせざるを得ない。こんなことをしていてはいつまで経っても生産性係数の精度を上げられない――。そう考えて悩む見積もり担当者は多い。
「その考えは間違っている」と，難関プロジェクトを数多く手掛けてきたPMリサーチの岡村正司氏（社長）は指摘する。「生産性係数は量より質が大事だ。サンプルの数を増やして性格の違うプロジェクトのデータが入り込む方が，むしろ精度が悪くなる」（岡村氏）。JAL/JAS統合プロジェクトでは，過去の案件をたった1件しか参照していないが，正確に見積もってプロジェクトを成功に導いた（PART3を参照）。
大成建設で見積もりを担当する井上良悟氏（情報企画部 課長）も，生産性係数の質を重視する。かつてFPをベースとした生産性係数の精度が上がらないことに苦心していた。そこで限られた実績データから，精度の高い生産性係数を作れないかを考えた。
工夫したのが生産性係数の細分化である。生産性係数を算出する際，JavaやCなど言語別に6種類，経理や営業，土木など業務別に8種類に分類した。生産性係数は言語別と業務別を掛け合わせるため，全部で48種類の係数があることになる。「経理系システムはデータ項目や関連システムが多く，他のシステムに比べて生産性が低下する。業務別に分ければ現場でより適用しやすくなる」（井上氏）。
土木系システムなどはサンプル数が2件しかない。それでも，一緒くたにしたものよりも精度は高いという。
技術の進歩で適用が困難に
リクルートの米谷修氏（FIT システム基盤推進室 フェデレーションオフィサー）は生産性係数を適用する範囲に工夫を凝らしている。「最近の情報システムは規模と工数が比例しなくなってきた。一つの生産性係数で一つのシステムの工数を算出するのは無理がある」（米谷氏）。
例えば，Web系のシステムでは，AjaxやFlashを使ったリッチなユーザー・インタフェースが増えている。これらは通常の画面に比べて開発工数が膨らむ。だが，FP法ではリッチな画面も静的な画面も区別しないため規模は膨らまない。規模が同じソフトウエアであっても実装形態により工数に大きな差が出るという矛盾が生まれる。
FP法でも「複雑度」という形で機能の粒度を調整する仕組みは用意されている。だが，技法が規定された当時は，ここまでの開発技術の進歩や複雑なロジックの実装は想定していなかったため，現場と技法の乖離は埋まらない。技法の不足部分を埋めるために，米谷氏は技法の適用場所を絞った。
具体的には，生産性係数を適用しやすい通常機能の部分と適用しにくい例外機能の部分に分離。例外機能の部分は，生産性係数を使わずWBS法で算出する。それを，生産性係数で割った通常機能の工数と合算する（図4）。
