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

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

図1●あなたも「見積もり」に挑戦してみよう
図1●あなたも「見積もり」に挑戦してみよう
イラスト:ミオササノッチ
[画像のクリックで拡大表示]

三者三様の見積もり結果

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

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

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

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

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

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

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

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

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