[2018/07/01 追記] 過去に話題になったこともあり、このページに辿り着く方が多いようなのだが、係数導出の手法については継続的に改善を行っている。現時点では、「工数見積りの海を彷徨う・征服」というエントリに記載した「分位点回帰」を使うのがベストではと考えている。50%分位点が中央値にあたるため係数も安定しており、現在の見積りが過去のプロジェクトと比較してどのくらいの工数なのかが明確でわかりやすい。合わせて参考にしていただきたい。
工数見積りが難しいのはわかっているのだが、そうは言っても根拠は欲しい。この業界に入ってからずっと考え続けているのだが、やはり難しい。
この手の工数、工期という話題の時、役に立つのは次の資料だ。
素晴らしいことにどちらも PDF 版は無料で配布されているので、ダウンロードして見ることができる。システム開発サイドだけでなく、エンドユーザ側でも有用な資料だと思う。
特に標準工期や各工程の割合に関しては、データの安定性が高くそのまま使える。例えば、標準工期は、人月工数の三乗根に2.4～2.5をかけた数字となる。JUASによれば、標準工期を30%以上下回るプロジェクトは無謀とのことだが、あなたのプロジェクトはいかがだろうか。
問題は、工数見積りだ。工数は単価をかければそのまま金額になるわけだし、標準工期のベースともなる。一番重要な指標と言える。しかし工数については、データを見ても分散が大きく、IPAでも、あくまで目安として50%の信頼幅に収まっているかを見るのに使ってください、というスタンスを取っている。
JUASはもう少し踏み込み、毎年データから回帰分析を行い総工数の見積りに使える式を算出しているのだが、各年の結果がかなり異なる。例えば、2007年度版では、総工数＝1.55×画面数だと書かれている一方、2009年度版では、総工数＝1.09×画面数となっている。ここ数年の版に至っては、画面数だけの分析は削除され、画面と帳票での分析のみが掲載されている。同じ機能数なのに工数が50%も違うのでは、見積りチェック用途だとしても使いづらい。
とはいえ以前、システム開発はもっと明朗会計にならなければいけないでも書いたように、FP法と総工数には、分散はあるものの明らかに正の相関が認められる。FP法は「機能」をポイント化しているわけだから、工数は機能を正しく見積ることができればある程度予測できることが想像できる。
このことから考えると、面倒ではあるが、まじめに FP を求めろという話ではあるのだが、実際には FP 法での見積りは次のような理由があって難しい。
- 概算見積りを求められるのは、RFP(Request For Proposal)提示時など要件定義前の早いタイミングでありエンティティと言った詳細な設計まではとても落とせない。
- FP法は、機能ごとの見積りではないため、機能数の削減が工数に与える影響を見積るのが極めて困難である。この機能を削るからいくら安くします、などという交渉が難しくなる。
そのため、JUAS 同様、画面、帳票、バッチなどの機能数から概算見積りに落としこむことはできないかと考えてきた。
今まではベースとなる数値はかなり直感に頼って決めていたのだけれど、昨晩 IPA 公開のデータを見ていたら、画面数⇒総工数、帳票数⇒総工数、バッチ数⇒総工数については個別のデータが取得できる事に気づいた。
IPAでは、（画面数、帳票数、バッチ数、総工数）の組み合わせデータは公開されていないが、総工数はプロジェクトごとに異なるわけだからマッチングすれば概ね元通り復元できる（数件、総工数の重複したデータが存在したため、それらについては機能数が多い方に寄せて対処した）。このデータを元に何らかの計算式を導出できないかと考えてみた。
まず、正攻法で重回帰でパラメータを導出してみたのだけれど、帳票の工数が画面より大きかったり、外れ値にかなり影響されていたりとおよそ使える式にはならない。
世の中には様々なシステムが存在しているわけで、とても簡単な画面を大量に作るプロジェクトもあれば、1画面が20人月を越えるような複雑なシステムもあるだろう。また、アンケート形式であるので、データ自体どこまで信頼できるかわからない。画面数がわからないのでメニュー数を使っているケースや数十シートを持つEXCELを1帳票として数えていることも十分に考えられる。
目的としては、一般的で標準的な機能群を持つシステムのために見積の基準を決めたいというところにある。そこで、考え方を変え、次の基準に従って制約を加えることにした。
- 機能⇒工数ではなく、機能⇒FP⇒工数という過程を通して見積る
- 画面数、帳票数、バッチ数の標準工数に重みを付ける
- 機能あたりのFPが離れたものを外れ値として除外する
- 工数の範囲を一般的なプロジェクトと考えられる10～1000人月の間に制限する
まず、FP⇒工数については、IPA の資料から工数[開発5工程／人時]＝4.85×FP^1.13をそのまま使う。
次に画面数、帳票数、バッチ数の重みであるが、以下のような仮定を置いてみる。
- 標準的な画面の工数は、標準的な帳票の工数の 1.5 倍程度だろう（JUAS の資料でもどこかで、この仮定を置いていたのを見た気がするが、感覚的にはそんなものだろう）
- 標準的なバッチとしてCSV出力するようなものが考えられる。そのような処理は帳票で言えば簡単なものに括られる。すなわち、標準的なバッチと簡易な帳票の工数は同等だろう。
- 機能の難易度はIFPUGでは高、中、低の三段階となっており、概ね高＝中×1.5、低＝中×0.7となっている。
このような仮定を置くと、標準的な画面、帳票、バッチの工数比が 1.5:1.0:0.7 となることが導出できる。
この二つが決まれば、工数から想定FPを逆算した上で、工数比をかけた画面、帳票、バッチ数から単位FPを求め、箱ひげ図を使って外れ値を除外することができる。通常、箱ひげ図を使う場合は、内境界点の外にあるデータを外れ値とするが、画面辺り3人月のようなデータも残ってしまう。そこで25～75パーセンタイルに収まらないデータを外れ値として扱うことにした。
そうやって、ようやくたどり着いたのが次の式となる。
工数[開発5工程／人時]＝4.85×(13.77×画面数＋9.18×帳票数＋6.42×バッチ数)^1.13
難易度を考慮するなら、機能数＝1.5×難易度高＋難易度中＋0.7×難易度低とすればよいかもしれない。なお、括弧の中の数字はそのままIFPUGのFP値となっているはずなので、実測のFP値と比較してみることもできる。
さて、実際のところこの数式は使い物になるのだろうか。もし、使ってみて高く出すぎる、低く出すぎるなどあれば、感想を教えてもらえるとありがたい。
【2016/4/26追記】
FP⇒工数の算出式はIPAのものをそのまま用いていたがデータセットは合わせた方がよいだろうという気になり、工数範囲を10～1000人月、FPあたりの工数で外れ値の除外を行った結果、FP⇒工数はほぼ直線となった。規模による工数増が消えてしまったわけだが、規模が増えるにつれて分散が大きく上振れしがちという事情が影響しているということなのかもしれない（単に外れ値除去の結果、平均化されてしまっただけかも）。
結果としては式はシンプルになった。
工数[開発5工程／人時]＝12.13×(14.68×画面数＋9.79×帳票数＋6.85×バッチ数)
前回の式より数値は10%ほど上振れしている。ただ、こちらの方が単純な掛け算なのでわかりやすいかもしれない。１画面あたり 1.11 人月というのは意外と大きいなという印象なのだが、そんなものだろうか。
