見積もり仮想体験の旅へ、いざ出発！：プロジェクトの闇、見積もりに光を！（3）（3/3 ページ）

[佐藤大輔（オープントーン），＠IT]

WBS法のメリットとデメリット

　WBS法のメリットとしては、以下のものが挙げられます。

1. 工期と工数、体制（人件費）までを同時に見積もれる
2. 個々のタスクは非常に正確
3. タスクの深さであるテストの段階数やドキュメント化の程度を完全に取り込める
4. 客観的であり理解しやすい

　対してデメリットを挙げると、以下のようなものがあります。

A.タスクごとにバッファを取ってしまい、コストやスケジュールが過重になりやすい（後述）

B.設計の精度をかなり進める必要がある。概算という使い方が困難

C.実績のないシステムではタスクごとの見積もりの類推が困難

　一般的なタスクからの見積もり方法について解説します。この手法は特に方法論化されているわけではなく、ごく一般的に用いられている方法です。

　ここでは、SEが1人、プログラマ（TT1、TT2）2人のほか、SEのアシスタント（いわゆる新人ぐらい）が1人というチーム構成を例とします。その4人にフェイズごとのアクティビティや、可能であれば具体的な細かい作業を表すタスクにまで作業を分解し、その作業ごとに工数を見積もっていきます。

　ただし、例えばある機能の実装に本当に5日かかるのかどうかは、実績がなければ判断しにくいものです。そういった場合は、一般的に以下のようなアプローチで見積もりを行います。

a.徹底的に作業を細かく分解する

b.その作業ごとに実務担当者と入念に話し合い、工数を割り出す

　まず作業を分解することにより、新機能の「見積もりが見えない」部分をとにかく最小化します。そのうえで、見えない部分に調査を行い、担当者が少しでも精度を上げられるように工夫してみてください。

　工数の見積もりの結果、全員の作業は287人日。1人月を20日とすると、14人月少々になります。

表4　見積もり書タスク図は、見積もりの全体スケジュールを把握できる。表の項番は、一部だけ記載し、ほかは省略している

　それが新規開発ではなく機能追加などであれば、1機能当たりの工数などは関係者が推測しやすいものです。そのような場合は推測した値を利用することはよくあることです。

ユースケースポイント法による見積もり

　ユースケースポイント法による見積もりも、機能の広さから推測をします。ただし、その機能をある程度まとめて、ユースケースとして見積もりをしているのが特長です。

　ユースケースとアクターを推し量り、それにチームの能力などの環境要因を加味することで見積もりを出していきます。

　この見積もりでは、ユースケースの粒度がある程度細かい必要はあります。とはいえ、機能のくくりという粒度までユースケースを割り出せれば、ある程度の見積もりを出すことができます。

表5　左のActor名とユースケース名から係数と呼ばれるFPに近いポイントが算出する。次に右の要因によって、係数（ポイント）を加減する。この値は、プロジェクトの事情、例えば、チームの経験度などにより上下し、最終的なユースケースポイントが算出される。本表は、オブジェクト倶楽部のダウンロードページにある「Use Case Point法による工数見積ワークシート」を参考にした

　また、見積もり結果にある程度タスクの深さや品質の重さを含ませる係数を用いることで、COCOMO II法のような機能外の要素もカバーできるようになっています。

複数の見積もり手法を比較する

　ここまで解説してきた方法で、見積もりを計算すると、次のようになります。最後はプロジェクト後に計算した実際の数値とします。

見積もり手法	見積もりで算出された工数
FP（ISBSG）法＋COCOMO IIの係数を利用した場合	12.5人月で、工期は7カ月
WBS法	14.75人月
ユースケースポイント法	11人月
（注）実コストは、10人月で工期は6カ月

　こうしてさまざまな方法を比較しながら見積もりを計算すると、各見積もり手法の特長が見えてきます。

　まず、適合する場面が違います。一般的に商談を進める際には、概算見積もり、詳細見積もり、正式見積もりというふうに進んでいきます。その状況にも見積もり方法ごとに向き不向きがあります。

　例えば、概算見積もりの際にはユースケース法は向いていますが、WBS法はあまり向いていません。そして正式見積もりに近づくほど、WBS法を採用している現場が多いのは事実です。

　では、今回採用した3つの見積もり結果をあらためて比較して見ましょう。

＠IT情報マネジメント編集部からのお知らせ
「＠IT Ondemand-book」で著者の記事を販売中！

開発現場の天国と地獄！ 佐藤 大輔著、アイティメディア、2008年11月26日発売、945円（税込み）

※booknest購入ページへ

　WBS法による見積もりは、一般的にユースケース法やFP法より工数が膨らみます。WBS法の欠点ともいえるのですが、見積もり作業者は1タスクずつに少しずつバッファを積んでしまう傾向があることです。

　その結果、細かく分けられたタスクごとにバッファが積み上げられると、全体の工数を出す際にバッファだけで数人月分になってしまうことが多いためです。

　ただし、WBS法特有のタスクの深さという視点で見たときに、ユースケースポイント法やFP法では出ない要素があります。例えば今回の開発ではパフォーマンスに対する要求が厳しいため、1人月程度のパフォーマンステストの期間を設けています。

　その結果、ユースケース法やFP法では、見えない作業の深さが見えなくなってしまいました。その点WBS法は洗い出しに成功しています。

　つまり、機能の広さから見積もるようなケースの場合、必然的にタスクの深さや品質の重さは別に計上しなければいけません。

いまこそきちんと見積もりを

　今回紹介した見積もり手法ですが、実際に弊社が実務で用いている手法です。

　見積もりは正確に行わねばいけません。しばしば、技術者も営業も「結局、顧客の予算次第」といって見積もり算出を投げ出してしまう光景を見かけます。しかし、それは大きな間違いです。最終的な「営業的売価」がいくらになるにせよ、コストやスケジュールのコントロールのためには見積もりは絶対必要です。

　必要な予算やスケジュールを確保できなかったとしても、それがどの程度不足しているのか、スケジュールにはどの程度の無理があるのかを把握しなければいけません。

　そうしなければ、経営陣や営業は技術者に「頑張れ、頑張れ」というだけで、実際の効率化や合理化の機会を失います。デスマーチになるたびに「頑張らないからだ」といわれ続ければ、当然モチベーションも下がってしまいます。

　ますます、競争が厳しくなり、予算も削られるからこそ、生産性の向上や合理化は必須です。そのためには合理化すべき方向性や手法を決めるためにもコストコントロールは必須となります。

　筆者は、こうした企業努力で0.5％ずつでも開発効率を良くしていく会社が、最後には20％、30％と効率の良い組織に育っていくのだと思っています。

　いまこそ、きちんとした見積もりに取り組んでみてはいかがでしょうか？

（注1）ファンクションポイント（FP）

筆者プロフィール

佐藤 大輔（さとう だいすけ）

株式会社オープントーン社長。会社設立前は大手システム会社などで多くのシステム開発に、主にマネージャとして携わった経験を持つ。

「プロジェクトの闇、見積もりに光を！」バックナンバー

• 見積もり仮想体験の旅へ、いざ出発！
• 見積もり仮想体験、準備から始めるべし
• 見積もり、まずはざっくり理解せよ