見積もり手法について本気出して考えてみた

見積もり手法をまとめてみた。

KKD手方

経験(K)・勘(K)・度胸(D)で見積もり担当者が「エイッ」と出す見積もり。
後付けでもっともらしい理由はちゃんと記述しておきましょう。
小規模なプロジェクトであったりとか、過去に類似で関わったことのあるプロジェクトであればざっくりと出すことが可能だが、プロジェクトの規模が大きくなってきた場合は誤差が出やすくなる。
システム開発というととても近代的なイメージがあるかもしれないが、実は一番多く使われている手法だったりする・・ww

ユースケースポイント方

システムの機能量を最初に見積もった後に、それにシステムの技術的な複雑さや環境的な難易度を掛け合わせてユースケース図に掛け合わせて算出する方法

ユースケース図が欲しい方はこちらから
http://www.objectclub.jp/download/

ファンクションポイント方

DBのテーブルやフィールド数を数えて「データファンクション」を算出した後に、画面や帳票の項目数を数えて「トランザクションファンクション」を算出する。
その後上記2つを合計して「未調整ファンクションポイント」を求める。
「未調整ファンクションポイント」を14項目に分けて開発対象の規模を表す「調整済みファンクションポイントを求める」

タスク分解方

機能ごとに必要なタスク(「設計」「ロジック実装」「テスト」等々)を分解して、必要だと思われる「工数」を算出する。KKD手法と合わせてよく使われる。

line見積もり

私の師匠が使っている見積もり手法。
1つのシステムを「line」という機能の繋がり毎に分離して、そのline数につき見積もる手法。
1lineの目安とては、1つのWEBアプリケーション群を「入力->確認->完了」のように分離できる機能のつながり毎に仕分けたもの。
1lineの実作業の割り当ては、「打ち合わせ 1/3」「設計 1/3」 「実装 1/3」と割り当てる。
通常、全体の期間としては。「1人あたり2週で3line」程度が目安。


こうして見てみると、いろいろな見積もり手法がある。もちろんこれ以外にも数々の見積もり手法が存在する。
どのような見積もり手法であれ、結局はクライアントが満足するかどうかってのが大前提で、その上で如何にして正確に見積もるかって部分が重要。
結局人が作る以上は、ある程度は理屈でなくて勘と経験に頼らなければいけない部分ってのもあるし。

実際に業務で何を使うのが正解っていうのは、プロジェクトの規模とクライアントによるのかなぁ。

あと見積もりを出すときに、機能別にいくらって出すか、工数で時間を計算していくらって出すかは結構悩むところだが、これは正解がある。

システムに詳しくない相手に対して見積もりを出す際は機能別(登録機能いくらみたいな)に算出するのが概ね受け入れられやすくて、システムに詳しい相手の場合は工数(基本設計いくらみたいな)で見積もりを出すと受け入れられやすい。