NIKKEI SYSTEMS 2007.720

自信が持てる見積もり技術

特集1

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

三者三様の見積もり結果

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

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

標準技法には落とし穴がある穴をふさぐ現場ルールを作ろうFP 法やCOCOMOⅡといった標準的なソフトウエアの見積もり技法が普及してきた。ところがセオリー通りに見積もっても，ブレはいっこうになくならない。なぜブレるのか。その原因を探る。

見積もりがブレるメカニズム

1PART

会員管理システム

会員情報照会・印刷

会員ログイン認証

新規会員登録

退会

会員情報変更

【システム要件】

・基本設計の見直しからテスト完了まで【作業範囲】

・概略業務フローと画面イメージは，下図を参照・プラットフォームは汎用性が高いこと。クライアントはWebベースとすること・前提とするパッケージ・ソフトや製品がある場合はそれを明記すること・開発言語は汎用性の高いものを選択すること。利用する開発言語は 提案時に明記し合意を得ること・性能と信頼性は厳しい要件を設定しない。性能はストレスを感じない 程度とすること

例 題弊社では現在，会員の入退会や会員情報の変更をメールもしくは郵送で受け付け，それを弊社のオペレータが会員管理システム上のデータベースに登録している。今回のシステム開発では，会員向けのポータル・サイトを新たに開設し，会員自身がブラウザを介して各種処理を実施できるように変更したい。システム開発の工数とコストを見積もってほしい（ハードウエアやネットワークは含まない）

パスワード情報

会員情報

支部検索

スタッフ

トップ画面

会員

メニュー画面

ようこそ xx xx 様（会員＃nnnnnnnn）

会員情報変更

会員専用サービスメニュー

…

会員情報変更

住所検索

変更する 戻る

〒 xxx-xxxx郵便番号

○○県 xxxx▼住所

0xx-xxx-xxxx電話番号

0xx-xxx-xxxxFAX番号

xxx@xxx.co.jpメールアドレス

概略業務フロー 画面イメージ

各種会員サービス

ファイルに入る「→」はデータ更新を表す

会員番号，パスワードを入力しログイン

新規会員データ

ログイン情報

検索条件

検索結果

ようこそ xx xx 様（会員＃nnnnnnnn）

郵便番号を入力してクリックすると，住所情報を表示する

会員情報を変更してクリックすると，会員情報を更新する

クリックすると，会員情報を表示する

あなたも「見積もり」に挑戦してみよう図1 イラスト：ミオササノッチ（p.22，p.39 も）

21NIKKEI SYSTEMS 2007.7

特集1

自信が持てる見積もり技術

自信が持てる

見積もり技術

小沢勉さんの回答

基本設計 2人日詳細設計 10人日プログラミング 27人日テスト 5人日ユーザー教育，マニュアル作成 5人日

白井武彦さんの回答

コントロール 3000ステップ照会（10項目） 500ステップチェック（8項目） 500ステップI/O 2000ステップ印刷（10項目） 1000ステップ画面 1500ステップパスワード 500ステップ

大塚真一さんの回答

・画面 難易度（中）：800ステップ×5 既存部分の変更なので×20％ 800ステップ 難易度（小）：200ステップ×3 600ステップ 難易度（軽微）：100ステップ×2 200ステップ・業務ロジック 追加：6FP（1FP＝100ステップ） 600ステップ 大改造：6FP×75％ 450ステップ 中改造：10FP×10％ 100ステップ

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

（1人月＝20人日，人月単価80万円で計算）

2.45人月，196万円

（生産性係数3000ステップ/人月，人月単価100万円で計算）

3人月，300万円

（生産性係数2000ステップ/人月，人月単価120万円で計算）

1.375人月，165万円

　銀行のシステム開発・運用を担当する小沢勉氏（仮名，46歳）の場合，最初にプロジェクトを「基本設計」「詳細設計」「プログラミング」といった工程別に分割し，それぞれに必要と思われる工数を積み上げた。ただ，小沢氏はWebシステムの開発に携わった経験がない。「ホスト系の開発と同じような感覚で素直に計算すると，実績とズレた値が出ると思った。なので，工数の一部を修正した」と言う。　中堅システム・インテグレータでリーダーを務める白井武彦氏（仮名，36歳）は「照会」「チェック」「印刷」など開発すべき機能を洗い出し，それぞれのプログラムの大きさをステップ数（プログラムの行数）で測定した。それを生産性係数（人月当たりのステップ数）で割り，工数を算出した。白井氏は「要件では明示されていないが，自分の経験からこの案件では印刷機能を新規に作る必要があると推測した」と話す。　大手メーカー SEの大塚真一氏（仮名，37歳）は「どこまでのテストを見積もりに含めればよいかが分からなかった。システムテストは対象外と仮定し，工数から抜いた」と言う。大塚氏は画面をLOC法注1で，業務ロジックをFP法注2

で測定。FP数をステップ数に換算して，基本設計から結合テストまでの生産性係数を使い工数を算出した。

　3人はそれぞれが得意とする見積もり技法を使って見積もった。結果を見れば明らかなように，技法を使っても見積もりはこれだけ乖

かい

離り

するのである。3人の「修正した」「推測した」「仮定した」という言葉に象徴されるように，実際には勘や経験とでも呼ぶべきものが，見積もりの過程には入り込んでいる。この勘や経験がブレの温床となる。　今回，講師をお願いした日立製作所の初田賢司氏（プロジェクトマネジメント技術開発部長）によると，同案件は過去の実績に照らすと2人月，200万円ぐらいが妥当だと言う。これと比べれば，3人が算出した結果は，工数で約23〜50％，コストで約2〜50％のブレがある。

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

　開発の現場では，見積もりのブレは品質（Quality），コスト（Cost），スケ

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

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

図2

注1）LOC法Lines of Code。ソースコードのステップ数を基に規模を算出する方法。機能数とソースコードの量が比例するという考え方に基づく。注2）FP法最初にシステムの範囲を決定し，その範囲内で論理ファイルや外部入出力などの五つの機能を計測する方法。改良版が複数あるが，IFPUG法が一般的。注3）WBS法Work Breakdown Structure。プロジェクト全体の作業を管理しやすい単位に分割し，その作業単位ごとに必要工数を算出して全体工数とする方法。

NIKKEI SYSTEMS 2007.722

自信が持てる見積もり技術

特集1

見積もりがブレるメカニズム1PART

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

時点ではそこまで分からなかった。

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

　ソフトウエアの見積もりがブレるのは昔からの悩みである。それを解決する手段として，FP法やCOCOMOⅡといった標準的な見積もり技法が注目されたのが，2000年前後。ここ数年でそうした技法が現場に定着した感がある。それでも見積もりのブレがなくならないのは，それだけ現場への標準的な技法の適用が難しいからである。　現場に対して標準的な技法を推進する立場にある日本ユニシスの佐藤富雄氏（生産技術推進室 グループマネージャ）はこう指摘する。「同じプロジェクトがない以上，標準的な技法では現場にそぐわない面が必ず出てくる。自分の現場とは違う現場を想定した技法

を使っていると考えるべきだ」。　日立製作所の石川貞裕氏（プロジェクトマネジメント統括推進本部 担当本部長）は，標準的な技法の“壁”を感じ始めているという。「標準的な技法をベースにした見積もり支援ツールを社内で整備し，それを使って現場で見積もるよう推進してきた。だが，ツールで算出した結果に納得できない，自信を持てないプロジェクト・マネージャ（PM）があまりにも多い」。　ソフトウェア・エンジニアリング・センター（SEC）で見積もり手法部会の委員を務める石谷靖氏（三菱総合研究所 主席研究員）は，標準的な技法に疑念を抱き始めている現場の声をこう代弁する。「これまでの勘や経験による見積もりを否定され，標準的な技法を使い始めた。ところがその見積もり

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

SE1 SE2 SE3

機能の数は同じみたいだけど…

直さない部分や薄く直す部分はどうしよう…

工数は一律10％ぐらいのアップで

足りるのだろうか…

歓迎！初めてのプロジェクト

赤字にしないためには、120万円ぐらい欲しいけど大丈夫かな…

Ajaxを駆使した

WebシステムのFP数の

数え方が分からない

保守開発のステップ数の

数え方が人と違う

初体験のシステム開発の

リスクをどの程度

反映すべきか悩む

短納期プロジェクトの

SE単価をいくらに

設定すべきか迷う

23NIKKEI SYSTEMS 2007.7

特集1

自信が持てる見積もり技術

自信が持てる

見積もり技術

結果に納得できない，実際に勘や経験で見積もった方がむしろ精度が高かったという声さえ出てきている」。

技法の限界を知る

　今回，取材から浮かび上がったのは，見積もり技法の落とし穴とでもいうべき限界である。見積もり技法の「解釈が難しい」「範囲が限られる」「情報を集めるのが大変」などといった限界に悩む現場は多い。　図3のイラストを見てほしい。それぞれのケースで，あなたは自信を持って見積もれるだろうか。　Ajaxを駆使したWebシステム（左上）。通常のHTML画面に比べれば開発工数は膨らむはずだ。しかし，FP法には動的な画面の作りを考慮する観点が含まれていない。セオリー通り見積もれば，実際よりも小さい数字しか出てこないだろう。　どこにでもある保守開発（左下）。5000ステップのプログラムのうち1500ステップを改修し，2000ステップを削除する場合，開発規模を表すステップ数はどう数えるか。LOC法ではルールが規定されていない。　経験のない技術や製品を使った新規開発（右上）。経験豊富な案件よりリスクが大きくなるため，工数を上乗せする必要があるとは誰もが思うだろう。だが何％上乗せすればよいのか。　ベンダーが開発を受注しようとしている案件（右下）。人月単価100万円では赤字が出るため，120万円で設定したいが高すぎないだろうか。　技法はこうした疑問に答えてくれな

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

ブレるポイントは三つ

　国内で利用される標準的な見積もり技法は図4上のようになる。まず要件に基づいてFP数やステップ数といった「規模」を測定する。次に，規模を生産性係数で割って「工数」を算出する注4。最後に，算出した工数に人月単価を掛けて「コスト」とする。規模がブレれば工数がブレる，工数がブレるとコストがブレるという関係にある。　一連のプロセスの中でブレるポイントは大きく三つある（図4下）。　規模見積もりは「技法の解釈」によってブレる。具体的には，ルールの解釈が人によって異なる，技法がカバーし

ていない部分がある，早い段階で技法が適用しづらい――というのがブレの原因だ。　工数見積もりは「条件の設定」でブレることが多い。典型的な例としては，生産性係数の適用を誤る，標準の変動要因がそぐわない，判定基準が人によって異なる――というものがある。　コストのブレは「相場観の欠如」に尽きる。人月単価は職種や工程，地域，スキル・レベルによって大きく変わる。相場を意識せずに単価を設定すれば，コストのブレは当然起きる。　次ページからのPART2では，こうしたブレるポイントに対して，根拠を持って見積もるための現場の工夫を紹介しよう。PART3では，世界最大級の統合プロジェクトを指揮したPMに，標準技法の適用の難しさやそれを乗り越えるための苦労を聞いた。PART4では，見積もり技法の年表を示す。それぞれの標準技法の特徴，技法の進化の歴史を知ることで，見積もり技法の良さと限界をつかめるだろう。

技法の解釈でブレる・ルールの解釈が人によって異なる・技法がカバーしていない 部分がある・早い段階で技法が適用しづらい

条件の設定でブレる・生産性係数の適用を誤る・標準の変動要因がそぐわない・判定基準が人によって異なる

相場観の欠如でブレる・地域別・職種別の相場観が 異なる・工程別の相場観が異なる・スキル・レベル別の相場観が 異なる

要件 規模

FP法，LOC法，画面/帳票による計測

基準値法，WBS法，COCOMOⅡ

人件費，経費，予備費

工数 コスト＝計測⇒ ÷生産性係数×変動要因＝

×単価＝

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

図4

注4）工数の算出ほかにWBSを使った工数の積み上げ，COCOMOⅡを使った係数モデルによる工数の推定などの技法がある。