技法の穴をふさぐ：工数編 --技法の穴をふさぐ：工数編

「こんなはずじゃ…」と多くの人が首をかしげるのが、工数見積もり。技法の値や項目が現場の実態と乖離していることがままあるからだ。そんなとき、どうすればよいのか。先達の工夫に学ぼう。

　ソフトウエア開発の工数は、規模見積もりの値を「生産性係数（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）。

図4●生産性係数の適用範囲を工夫する

規模全体を標準的な生産性係数で単純に割ると、見栄えに凝った画面や複雑なロジックが含まれたときに工数が過小になる。リクルートの米谷氏らのチームはこうした機能を通常機能から切り離すほか、規模には含まれない作業工数をWBS法で算出。それらを合算して全体工数としている

標準の変動要因がそぐわない 現場の経験を合理的に加味する

　一方、変動要因の落とし穴は、あらかじめ用意されている変動要因の値や項目が現場にそぐわないことだ。変動要因とは「要件の不確実性」や「チームの知識・経験」など、工数を変動させる要因のこと。標準技法の中で定義されているものもあるし、企業によっては全社共通の変動要因を用意しているところもあるだろう。

　だが、こうした標準的な変動要因が、現場にそぐわないことは多い。実際、FP法にも「一般システム特性」という14の変動要因が用意されていたが、JFPUGでは2003年、現場の実態に合わないと判断。原則適用しない方針を打ち出している。

　日立製作所の幕田行雄氏（プロジェクトマネジメント技術開発部 担当部長）は2006年末、現場のメンバーとともに「全社標準の変動要因」にノーを突きつけた。きっかけは、流通部門のメンバーから挙がっていた「標準の変動要因が現場に合わない。自信を持って使えない」という声だった。標準的な変動要因が金融機関向けの大規模プロジェクトを想定して作られていたため、内容にピンとこなかったのだ。

　そこで幕田氏が取り組んだのが現場の経験をベースにした変動要因の設定だった。ここでは、CoBRA（Cost estimation、Benchmarking、and Risk Assessment）法と呼ぶ統計手法を活用。同手法を選んだのは、現場の経験をベースにしながら、みんなが納得できる変動要因を合理的に作ることができそうだと考えたからだ。

　具体的な手順は前ページの図5の通り。まず現場のプロジェクト・マネージャが集まり、開発工数を増減させる様々な要因を図を使って議論。次にそれぞれの要因が発生した場合の影響度を「最善」「平均」「最悪」の3段階で評価する。ユーザーの参加度合いがほとんどない場合、最善で10％、平均で30％、最悪で50％の工数が増加するという具合だ（数字は仮の値）。

図5●実態に近い変動要因を洗い出す

全社的な変動要因（工数の増減要因）が現場にそぐわないことは多い。日立製作所の幕田氏らは、CoBRA法と呼ぶ統計手法を使い、自分たちの経験に基づく変動要因を設定した（数字は仮の値）

[画像のクリックで拡大表示]

　各影響度の平均値を求めたら、それを評価3に設定。その上で評価2および評価1の値を推測する。この状態では同じ評価でも最善、平均、最悪という三つの数値がある。そこで3点見積もり法やモンテカルロ法といった統計手法を使い、一つの数値を導き出す。これにより、例えば「ユーザーの参加度合いが評価3の場合、工数に39.2％上乗せする」として見積もる。

判定基準が人によって異なる 迷わないように数字を使う

　変動要因のもう一つの問題は、人によって判定基準の解釈が異なってしまう点だ。本来同じレベルであるはずなのに、ある人は「評価3」を付け、別の人は「評価2」を付けるという状況が起こり得る。判定する人のスキルの問題と思われがちだが、日本ユニシスの佐藤富雄氏（生産技術推進室 グループマネージャ）は「判定基準が明確でなかったり、判断に迷うような表現だったりすることの方がむしろ問題」と指摘する。

　日本ユニシスでは2000年から、工数見積もりにCOCOMOIIを利用している。導入当初は「ベテランでさえ判定基準に迷っていた」と佐藤氏は言う。COCOMOIIには5種類のスケール要因と17種類のコスト要因がある。各要因には6段階の判定基準があり、これに基づいて評価をする。だがこの判定基準の表現があいまいなのだ。

　例えば、COCOMOIIには「開発の先例性」という変動要因がある。初めての開発では規模が増加するリスクが高まるので、その影響度を見積もりに加味するためのものだ。その判定基準を見ると、評価1の「全く先例がない」はまだしも、評価2は「大部分先例がない」、評価3は「いくらかの部分で先例がない」となっている。これでは担当者が迷うのも仕方ない。そこで佐藤氏らはCOCOMOIIの22項目すべての表現を独自に修正した（図6）。

図6●判定基準で迷わないようにする

ステップ数から工数を算出できるCOCOMOIIだが、スケール要因とコスト要因の判定基準があいまいで人によって評価が異なる。日本ユニシスの佐藤氏らは全22項目について、現場で判断を迷わないようにする表現に変更した

[画像のクリックで拡大表示]

　評価1は「業界初である」、評価2は「自社初である」という具合だ。さらに佐藤氏は「判断に迷わないためには数字で示すのがポイント」と説明する。開発の先例性では、評価3以降について具体的な「案件数」を示した。別の要因では、チェックリストを用意し、チェックした数で判定基準を決定できるようにした。