見積もりがブレるメカニズム--標準技法には落とし穴がある 穴をふさぐ現場ルールを作ろう

FP法やCOCOMOIIといった標準的なソフトウエアの見積もり技法が普及してきた。ところがセオリー通りに見積もっても、ブレはいっこうになくならない。なぜブレるのか。その原因を探る。

　突然だが、図1の＜例題＞に挑戦してほしい。ある会社の会員管理システムの一部を修正するための見積もり依頼である。システム要件とともに、概略業務フローを表すDFD（Data Flow Diagram）と画面イメージを示した。工数とコストはいくらになるか。

図1●あなたも「見積もり」に挑戦してみよう

イラスト：ミオササノッチ

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

三者三様の見積もり結果

　5月某日、現役のSE3人を集め、例題に挑戦してもらった。その結果、工数とコストはそれぞれ「2.45人月、196万円」「3人月、300万円」「1.375人月、165万円」と、三者三様の回答となった（図2）。

図2●現役SE3人が例題の見積もりに挑戦

三者三様の見積もり結果となった。工程別に工数を積み上げるやり方、ステップ数を生産性係数で割って工数を算出するやり方、FP法を使うやり方など見積もりプロセスはまちまち。コストの見積もり結果も165万円から300万円までと、大きな差があった

　3人はいずれも10年以上のキャリアを持つベテランSEである。にもかかわらず、見積もり結果には大きな開きが出た。なぜこんなに差が出たのか。彼らが使った手順とそのコメントから考えてみよう。

　銀行のシステム開発・運用を担当する小沢勉氏（仮名、46歳）の場合、最初にプロジェクトを「基本設計」「詳細設計」「プログラミング」といった工程別に分割し、それぞれに必要と思われる工数を積み上げた。ただ、小沢氏はWebシステムの開発に携わった経験がない。「ホスト系の開発と同じような感覚で素直に計算すると、実績とズレた値が出ると思った。なので、工数の一部を修正した」と言う。

　中堅システム・インテグレータでリーダーを務める白井武彦氏（仮名、36歳）は「照会」「チェック」「印刷」など開発すべき機能を洗い出し、それぞれのプログラムの大きさをステップ数（プログラムの行数）で測定した。それを生産性係数（人月当たりのステップ数）で割り、工数を算出した。白井氏は「要件では明示されていないが、自分の経験からこの案件では印刷機能を新規に作る必要があると推測した」と話す。

　大手メーカー SEの大塚真一氏（仮名、37歳）は「どこまでのテストを見積もりに含めればよいかが分からなかった。システムテストは対象外と仮定し、工数から抜いた」と言う。大塚氏は画面をLOC法注1で、業務ロジックをFP法注2で測定。FP数をステップ数に換算して、基本設計から結合テストまでの生産性係数を使い工数を算出した。

1時間で見積もりを作成した（講師は日立製作所の初田賢司氏）

　3人はそれぞれが得意とする見積もり技法を使って見積もった。結果を見れば明らかなように、技法を使っても見積もりはこれだけ乖離するのである。3人の「修正した」「推測した」「仮定した」という言葉に象徴されるように、実際には勘や経験とでも呼ぶべきものが、見積もりの過程には入り込んでいる。この勘や経験がブレの温床となる。

　今回、講師をお願いした日立製作所の初田賢司氏（プロジェクトマネジメント技術開発部長）によると、同案件は過去の実績に照らすと2人月、200万円ぐらいが妥当だと言う。これと比べれば、3人が算出した結果は、工数で約23～50％、コストで約2～50％のブレがある。

見積もりの精度がQCDに直結

　開発の現場では、見積もりのブレは品質（Quality）、コスト（Cost）、スケジュール（Delivery）の超過という形で表れる。中堅システム・インテグレータDTSの田中哲明氏（産業第一事業 部 産業第三部 グループマネージャ）は、見積もりのブレによって後で苦労した。ある会社の開発プロジェクトで基本設計を担当した際、その工数をWBS法注3によって算出。ところがプロジェクトが始まってみると、ステークホルダー（利害関係者）が予想以上に多く、レビュー待ちや設計の見直しが頻発。予定の期間を3カ月オーバーした。「レビューの回数しか考慮していなかった。出席者の数まで考えて工数を算出していれば、状況は変わっていたはず」（田中氏）と振り返る。

　NTTデータの藤貫美佐氏（SIコンピテンシー本部 SEPG 設計積算推進担当 課長）も見積もりで手痛い経験をした。あるシステム開発に参加したとき、見積もり上は信頼性が「中レベル」の生産性係数を使っていた。だが、開発現場ではそれ以上のレベルの信頼性を確保していた。当然、開発生産性は大きく低下。2割近くも工数が膨れた。「高レベルになることを最初から見込んで生産性係数を設定するべきだった」と藤貫氏は悔やむ。それが無理だったとしても「中レベルであることを見積書の前提条件の欄にきちんと明記していれば、現場の暴走を止められたはず」と言う。だが、見積もりの時点ではそこまで分からなかった。

セオリー通りでも精度は上がらず

　ソフトウエアの見積もりがブレるのは昔からの悩みである。それを解決する手段として、FP法やCOCOMOIIといった標準的な見積もり技法が注目されたのが、2000年前後。ここ数年でそうした技法が現場に定着した感がある。それでも見積もりのブレがなくならないのは、それだけ現場への標準的な技法の適用が難しいからである。

　現場に対して標準的な技法を推進する立場にある日本ユニシスの佐藤富雄氏（生産技術推進室 グループマネージャ）はこう指摘する。「同じプロジェクトがない以上、標準的な技法では現場にそぐわない面が必ず出てくる。自分の現場とは違う現場を想定した技法を使っていると考えるべきだ」。

　日立製作所の石川貞裕氏（プロジェクトマネジメント統括推進本部 担当本部長）は、標準的な技法の“壁”を感じ始めているという。「標準的な技法をベースにした見積もり支援ツールを社内で整備し、それを使って現場で見積もるよう推進してきた。だが、ツールで算出した結果に納得できない、自信を持てないプロジェクト・マネージャ（PM）があまりにも多い」。

　ソフトウェア・エンジニアリング・センター（SEC）で見積もり手法部会の委員を務める石谷靖氏（三菱総合研究所 主席研究員）は、標準的な技法に疑念を抱き始めている現場の声をこう代弁する。「これまでの勘や経験による見積もりを否定され、標準的な技法を使い始めた。ところがその見積もり結果に納得できない、実際に勘や経験で見積もった方がむしろ精度が高かったという声さえ出てきている」。

技法の限界を知る

　今回、取材から浮かび上がったのは、見積もり技法の落とし穴とでもいうべき限界である。見積もり技法の「解釈が難しい」「範囲が限られる」「情報を集めるのが大変」などといった限界に悩む現場は多い。

　図3のイラストを見てほしい。それぞれのケースで、あなたは自信を持って見積もれるだろうか。

図3●自信が持てない見積もりの例

イラスト：ミオササノッチ

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

　Ajaxを駆使したWebシステム（左上）。通常のHTML画面に比べれば開発工数は膨らむはずだ。しかし、FP法には動的な画面の作りを考慮する観点が含まれていない。セオリー通り見積もれば、実際よりも小さい数字しか出てこないだろう。

　どこにでもある保守開発（左下）。5000ステップのプログラムのうち1500ステップを改修し、2000ステップを削除する場合、開発規模を表すステップ数はどう数えるか。LOC法ではルールが規定されていない。

　経験のない技術や製品を使った新規開発（右上）。経験豊富な案件よりリスクが大きくなるため、工数を上乗せする必要があるとは誰もが思うだろう。だが何％上乗せすればよいのか。

　ベンダーが開発を受注しようとしている案件（右下）。人月単価100万円では赤字が出るため、120万円で設定したいが高すぎないだろうか。

　技法はこうした疑問に答えてくれない。現場ではそんな技法の落とし穴を埋めなければならない。普通はこれを属人的な勘や経験で埋めている。だが、勘や経験をそのまま使っていては説得力に欠けるし、自分でも納得感を得られない。そこにどうやって根拠を持たせるかがポイントなのだ。今、勘や経験に根拠を持たせるためのルール作りが、現場ごとに始まっている。それがうまくできれば、自分の見積もりにも自信を持てるだろう。

ブレるポイントは三つ

　国内で利用される標準的な見積もり技法は図4上のようになる。まず要件に基づいてFP数やステップ数といった「規模」を測定する。次に、規模を生産性係数で割って「工数」を算出する注4。最後に、算出した工数に人月単価を掛けて「コスト」とする。規模がブレれば工数がブレる、工数がブレるとコストがブレるという関係にある。

図4●見積もりがブレる三つのポイント

セオリー通りに見積もっても、解釈の違いや適用ミスによりブレは起きる。現場の経験を形式知化し、技法に組み込むことが大切だ

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

　一連のプロセスの中でブレるポイントは大きく三つある（図4下）。

　規模見積もりは「技法の解釈」によってブレる。具体的には、ルールの解釈が人によって異なる、技法がカバーしていない部分がある、早い段階で技法が適用しづらい――というのがブレの原因だ。

　工数見積もりは「条件の設定」でブレることが多い。典型的な例としては、生産性係数の適用を誤る、標準の変動要因がそぐわない、判定基準が人によって異なる――というものがある。

　コストのブレは「相場観の欠如」に尽きる。人月単価は職種や工程、地域、スキル・レベルによって大きく変わる。相場を意識せずに単価を設定すれば、コストのブレは当然起きる。

　次ページからのPART2では、こうしたブレるポイントに対して、根拠を持って見積もるための現場の工夫を紹介しよう。PART3では、世界最大級の統合プロジェクトを指揮したPMに、標準技法の適用の難しさやそれを乗り越えるための苦労を聞いた。PART4では、見積もり技法の年表を示す。それぞれの標準技法の特徴、技法の進化の歴史を知ることで、見積もり技法の良さと限界をつかめるだろう。