［見積もり編］いつも同じ見積もり技法を使ってはいけない

　見積もりを依頼されると，常に同じ見積技法を使って見積もりを作成するプロジェクト・マネージャ（PM）がいる。使い慣れた見積もり技法の方が手早く出来て時間もかからない。また，概算見積もりであれば，見積もりに必要な情報も少なく，おのずと見積技法も限られてくる。そのため，同じような見積もり技法に偏ることはあるかもしれない。

　しかし，詳細見積もりとなるとそうとは言えない。特に基本設計フェーズ完了時に行う見積もりの場合，経験的な見積技法，計数的な見積技法，定量的な見積技法など，どの見積技法であってもそれなりの情報が手に入るはずである。従って，PMが詳細見積もりを行う場合には，プロジェクトの特性に応じた技法を使って行うべきである。

いつもWBS法だけを使っていたEさん

　筆者の友人でもあるEさんは入社15年を超すベテランのPMである。若いころのプロジェクトで見積もり不足から大失敗をした経験がある。そこで見積もりについて猛勉強し，WBS法をマスターし愛用している。

　Eさんが，T社の在庫管理システムを構築する際のエピソードである。このシステムはユーザーの要望により，開発手法をオブジェクト指向開発で行うことが前提とされていた。Eさんはこれまでオブジェクト指向開発については，一度だけだが小規模Webシステムの開発で経験していた。進め方としては，要件定義フェーズまでは，ユーザーのシステム部門が主体となって実施し，基本設計以降をEさんの会社が一括請負で受注することとなっていた。そこでEさんは，要件定義フェーズでは，準委任契約の下，ユーザーがドキュメントを作成する手伝いを行うこととなった。

　開発がスタートした直後から，Eさんは戸惑った。なぜならユーザーはすべてのドキュメントをUMLで書くことを前提としていたからである。EさんはこれまでUMLについてユースケース図くらいは書いたことがあったが，それ以外のドキュメントについては経験がなかった。しかしEさんは，UMLで書くことが決まった直後から猛勉強し，要件定義フェーズが完了するきおろには，ユーザと一緒にUMLを書けるところまできていた。

　要件定義フェーズも無事に完了し，次フェーズ以降の見積もりを行うこととなった。Eさんは，いよいよ自分の出番とばかりに得意のWBS法で見積もることにした。しかし，これまで自分が見慣れたドキュメントと異なる形のドキュメントに戸惑い，WBS法の算定根拠となる成果物ベースのワークパッケージの定義に手間取ってしまったのだ。Eさんは試行錯誤しながら，この規模程度の見積もりであれば通常1～2日で終わるところ，入念に5日かけて見積もりを行った。

　一方，ユーザーのシステム部門でも予算化のために見積もりを行っていた。この見積もりを担当したのは入社5年目ではあるがオブジェクト指向開発を専門に行ってきたF君だった。F君は，要件定義フェーズの成果物を基にわずか2日で見積もりを算出していた。

　Eさんが見積を行っている最中に，T社から参考資料としてF君の見積もり結果がEさんに公開された。Eさんは，自分の見積もりが完了したあと，F君の見積もり結果と自分の算定値を比べてみた。すると，F君の見積もり結果は，Eさんのそれに比べ30％ほど工数が多かった。

　しかしEさんとしては，F君の年齢や今回見積もりにかけた時間などから，彼の見積もり結果は間違っていると信じた。そのため，T社に対しても自分が見積もった値に10％のリスクを上乗せする形で見積もりを提出したのだった。

　T社としては，自社のF君が見積もった結果よりも低い工数が提示されたことから，何の異論もなくEさんの工数をベースに契約を締結した。

　その後，このプロジェクトはどうなったか。Eさんの見積った工数＋30％の工数がかかってしまった。F君が算定した工数に近い工数が必要だったのだ。これは決して，顧客が非協力的であったとか，プロジェクトの進捗管理が悪かったとかいうものではなかった。純粋に当初見積もった工数に対して実績工数がオーバーしたのだ。

　工数がオーバーしたと言っても，PMとしては優秀なEさんである。T社に対して約束した納期を守り納品を行った。しかし，プロジェクトとしては想定原価を大幅に上回り，赤字のプロジェクトとなってしまったのである。これによって，Eさんは，自社内におけるWBS見積もりの第一人者という信用を失ってしまった。

　後で分かったことだが，F君はユースケースポイント法という見積もり技法を使ったのである。ユースケースポイント法とは「Applying Use Case Driven Object Modeling With UML」(Doug Rosenberg著, Kendall Scott著)の中に紹介された Gustav Karner氏による見積もり手法で，ユースケースを基にシステムの規模を見積もる定量的見積もり技法の一つである。

複数の見積もり手法を併用すべし

　EさんはWBS法による見積もりには絶対的な自信を持っており，WBS法こそが全てのシステムの見積もりに対応する手法であると確信していた。しかし，彼の失敗原因は，WBS法にこだわったことにあるのだ。

　EさんはUMLで書かれたユースケースシナリオから，成果物のイメージを作成しWBSに割り当てようとした。しかし，この成果物の洗い出しに漏れが生じてしまったのだ。さらに，洗い出した成果物をベースに定義したWBS工数にも大きなブレが発生してしまった。

　Eさんは，WBS分解し最小ワークパッケージの単位を決め，それぞれの工数を決定する際に，システムの規模感やメンバーの習熟度などを考慮していた。しかし，今回の場合，WBS単位の工数を算定するには，インプットとなるUMLドキュメントについてあまりにも不慣れだったのだ。

　Eさんの例の場合，WBS法だけに頼るのではなく，少なくともF君の見積もった値について真摯に受け止めて検討する必要があった。F君の経験が浅いので信頼が置けないとしても，Eさん自身が標準タスク法で見積もったり，オブジェクト指向開発経験者を交えたデルファイ法で見積もったりと，WBS法以外の見積もりを行う必要があったのだ（表）。そうすれば，WBS法による工数と別の見積もり技法による工数との差が発覚し，その差について深く検討することになったはずである。

　何かしらの見積もり技法をマスターすることは非常に重要でありPMにとっては大きな武器となる。しかし，一つの技法だけにとらわれていると，時として大きな失敗を犯してしまう。見積もり結果はその後のプロジェクト全体の運命を左右する。

　PMたるものマスターしている見積もり技法だからこそ，それによって得られた結果を疑い，その妥当性を別の見積技法にて証明するべきである（図）。

図●見積もり手法の種類

上田 志雄 ティージー情報ネットワーク 技術部 共通基盤グループ マネージャ 日本国際通信，日本テレコムを経て，2003年からティージー情報ネットワークに勤務。88年入社以来一貫してプロジェクトの現場を歩む。国際衛星通信アンテナ建設からシステム開発まで幅広い分野のプロジェクトを経験。2007年よりJUAS主催「ソフトウェア文章化作法指導法」の講師補佐。ソフトウェア技術者の日本語文章力向上を目指し，社内外にて活動中。