【ビジネス、キャリア】開発工数の見積もり手法とWBS作成の手法を少しまとめてみた

はじまり

見積もりプロセス

見積もりプロセスは、まず要件定義とスコープ定義から始まり、

規模→生産性→工数→費用および期間の順番に見積もっていきます。

商談時の見積もりでは、精度はそこまで求められない傾向にあります。

精度の目安としては、以下のようです。

• 超概算見積もり：-25%〜+75%
• 概念見積もり：-15〜+50%
• 予算見積もり：-10〜+25%
• 確定見積もり：-5〜+10%

見積もり手法

見積もり手法は、上記したように、大きく３種類に分けることが出来ます。

• トップダウン見積もり
• パラメトリック見積もり
• ボトムアップ見積もり

それぞれ、長所と短所を抱えていて、ざっと図にまとめるとこんなイメージになります。

それでは、詳しく紹介していきます。

トップダウン見積もり（類推見積もり）

トップダウン見積もりは、とある分野において専門的知識を備えている人や、プロジェクトに対して経験豊富な人などの、知識、経験は然ることながら、勘や度胸などを利かせて見積もる手法になります。

そのため、見積もりに必要な情報は少なく済みますし、その分かかる見積もりに必要な時間も少なくて済みます。

しかし、それを見積もった人の特性に依存したり、見積もりの精度としては粗くなります。

商談の段階プロジェクトの発足時など、話のタネとして本当に大まかに見積もり工数を算出したい時は、この見積もり方になるでしょう。

パラメトリック見積もり（係数見積もり）

パラメトリック見積もりというのは、作業を数値にして、その作業数を乗じたりして、客観的なデータで工数を見積もる手法となります。

例えば、工程や成果物にかかる工数を大・中・小の３段階などに工数を何個かの数値に分けて、それらにその大・中・小にそれぞれ分類された作業の数を乗じたりなどします。

メリットとしては、具体的な数値に落とし込むため、客観性の取れた見積もりになります。

そして、その見積もったプロジェクトとは違ったプロジェクトをまた見積もることになっても、類似の作業があれば、その既に行った見積もり方を踏襲することが出来ます。

しかし、この数値に落とし込む段階で、業務への理解度がある程度必要だったりします。

なぜなら、例えば、作業の大・中・小の比率を見極めるために、「大」の作業が「小」の作業の2倍かかるはずなのに、「大」を「小」の1.5倍などで見積もると、見積もり値が変わってくるためです。このズレ・差は、プロジェクトの規模が大きくなればなるほど、無視できないレベルに大きくなっていきます。

ボトムアップ見積もり

ボトムアップ見積もりは、WBSを作成してその工程毎などで区切った作業時間から工数を算出する見積もり手法です。

その作業について、経験や知識がない場合など、初めてゼロから見積もりを行う方はこの手法になるのではないでしょうか。僕も初めてシステム保守の作業を見積もった時は、この手法で見積もりました。

この見積もり方の利点は、見積もり精度が高く、作業の漏れや抜けが先に挙げた２つの見積もり手法よりも少なく抑えられることにあります。

そのため、作業を詳細に議論する時はこの手法が用いられがちな傾向にあります。

しかし、精緻な見積もり結果が得られる反面、やはりその算出に時間がかかります。

そして、このボトムアップ見積もりで用いられる「WBS」に対して、もう少し深く掘り下げます。

WBS作成プロセス

WBSとは、プロジェクトの成果物やそこに至るまでの作業を・工程を分解して、階層的に体系化したものになります。

体系化する時は、おおよそ以下のことに気を付けます。

• 同一階層内では全ての要素の粒度が揃っていること
• MECE（Mutually Exclusive and Collectively Exhaustive）であること
• 分野・次元・素性が統一されていること

プログラミング的に言い換えると、

• 配列内に、文字列型や数値型が並んでいるところに、オブジェクトを入れると見にくいのでやめておこう。
• 宣言している内容が重複している変数は置かないようにしよう。
• 文字列型と数値型を混ぜるよりは、どちらかに統一した方が良い。

と、なるかと思います。

WBSは、NoSQLよりもRDB（リレーショナルデータベース）的な考え方なので、表として整理することが出来る情報に区別する方が見やすい図式になります。

WBSの種類

WBSの作り方には、大きく分けて２種類あります。「成果物指向」と「プロセス指向」のものです。

「成果物指向」のWBS

「成果物指向」のWBSは、成果物に対して工数を計上するので、作業を行ってもらう側として見積もりやすい手法です。

何を最終的に成果物として提供できるのかが可視化しやすいです。そのため、発注側に成果物の規模→費用と提示しやすい情報になり得ます。

しかし、成果物以外に対する作業工数が漏れるフォーマットになっています。

「プロセス指向」のWBS

「プロセス指向」のWBSは、作業・工程に対して工数を計上するので、作業する側としては工数を見積もりやすいです。

他のプロジェクトを請け負った場合でも、そのWBSを流用しやすく標準化しやすいです。

しかし、最終的な成果物は見えにくいところが欠点です。

「成果物指向」と「プロセス指向」の比較

両者の関係性としては、このようになります。

WBSを作る時は「プロセス指向」と「成果物指向」を相互展開させる

システム開発プロジェクトは、成果物を分解して自動的に作業が決まるわけではありません。
言い換えれば、分解したサブシステムをどのようなプロセス（作業）で開発するかは、採用する開発手法や、規定されている開発標準に依存します。

したがって、どちらも一長一短な「成果物指向」と「プロセス指向」ですが、それらの双方を取り入れた「相互展開」および「相互作用」的なWBSを作成していく必要があります。

例えば、「要件定義」→「概要設計」→「詳細設計」のプロセスからなる開発標準（プロセス指向）がある場合、以下のように対応できます。

Lv	プロセス	成果物
1	要件定義	主要機能
2	概要設計	サブシステムなど
3	詳細設計	詳細設計書など

おしまい

以上になります！