QLOOKアクセス解析
ホーム   »  スポンサー広告  »  スポンサーサイト   »  プロジェクトマネジメント  »  見積もりの難しさ

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

見積もりの難しさ

永遠のテーマですが「見積もり」についてです。

現在担当プロジェクトの振り返り作業を実施しており生産性の確認も行っているのですが
何を持って生産性が高いとするのか、低いとするのかが非常に難しいです。
ここが難しいということはパラメータがぶれるということで、次回の同様のプロジェクトの
見積もりも難しいという事です。

今回ですと既存システムのカスタマイズ対応だったのですが
LOCベースで生産性を確認すると前プロジェクトの半分程度の生産性になります。
しかし修正画面数や、修正クラス数といったパラメータで見てみると40%程度の改善が見られます。

LOCベースで生産性が低くなっている要因は前プロジェクトが新規案件であったのに対し
今回はカスタマイズ案件であり、影響範囲に比べ修正コード数が少なかった事が要因ですが
これだけ見方によって生産性に違いがあるということは、見積もりのパラメータを間違えると
とんでもない事になるということでもあります。

私の見積もり手法は、現在の現場ではお客様がLOC法をベースとされていることもあり
・積算法、WBS法
・LOC法
・過去プロジェクトの実績値
をMixした見積もり手法を取っていますが、この弱点は上記の見積もりパラメータを何にするか?
で何倍もの開きが出てしまう事です。
非常にやっかいですが今の現場ではもう少しお付き合いが必要そうです。

では、どうあるべきか?を考えましたが個人的にはやはりFP法が現在Betterな選択であると思っています。

・ユースケースに対して見積もりを行うので顧客との価値に乖離が少ない
 ユースケースが複雑な場合、見積もりも大きくなるが納得感がある。
・言語や設計に依存しない

が主な推薦理由です。
とはいっても顧客の価値が少なくても実装は大変・・・という場合もあるし・・
などと思っていた時もあるのですが、良く良く考えてみるとそういった場合は
ソフトウェアの設計がまずい場合が多いです。

なので基本的にはユースケース単位で見積もりを行い、
ユースケースの価値に対して実際のコストが多い場合は、そのソフトウェアは顧客の要求に
マッチしていない事が考えられるので設計を見直す・・のような流れが妥当ではないかと思いました。

少なくとも現在においてはLOC法は不適切ではないかと思います。
どちらかというと少ない行数で大きな価値を出せるソフトウェアの方が魅力的です。
LOCでステップ数が大きいと工数が大きくなる見積もりをしていると
そのプロジェクトではあまり創造性がでてこないんじゃないかなぁと思います。
Comment
Trackback
Trackback URL
Comment Form
管理者にだけ表示を許可する
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。