ソフトウェア開発の見積りと実行は分業してはならない

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

ソフトウェア開発の見積りは当初仮説にすぎない

ソフトウェア開発の見積りは非常に難しいものです。基本的には一品モノの生産となるからです。ソフトウェアの見積り手法には、昔からいろんなものがありますが、言ってしまえば全て勘によるものです。

かかる期間と要員数を掛け合わせて算出したり、画面や帳票に難易度を設定し、難易度に応じた係数を掛け合わせたり、作業WBSや成果物WBSを策定してWBSごとに○人日としたり、、、といった具合です。更に、こうやってはじき出した数値に、何パーセントかの管理費用をのせたりもします。

FP法やCOCOMOⅡ、類推法という言葉に置き換えられますが、機能数や画面数、難易度、規模、どれもこれも結局は勘によるところが大きいのです。

※見積りという行為が無駄だといっているわけではありません。売買契約を行う上で見積りは必要かつ需要な行為です。実績払いになるとしても、目安は知りたいものです。

当初仮説を真だと思い込むのは不幸

このように勘によるところが大きい見積もりですが、結局はそれでプロジェクトの予算が決まります。予算が確定したあとはそれが勘であろうが何であろうが遵守すべきものになります。

更に、プロジェクトの原価を見積もった人と、実際にプロジェクトを推進する人が違うと、後々嫌な思いをすることになります。

予定原価を超過した場合、プロジェクトを推進していた人は当初の見積りが甘かったと思いますし、見積りを行った人はプロジェクトの進め方に問題があったと考えます。まずこの時点で面白くありません。

そして、もし原価悪化したら(予定原価を大幅に上回ったら)、その時点でプロジェクトを推進している人が糾弾されます。仮に当初の見積りが大甘だったとしても、まずは推進者が責められます。

この時、裏では甘い見積りを出した人は(何の責任もとらず)「受注に貢献した!」という評価になっていることもあります。

見積りを行う人と実行する人を分けてもいいことはない

これではモチベーションはガタ落ちです。まじめにやるのがバカらしくなっても仕方ありません。分業には能率を高める効果があることは認めますが、このように分業してはならない部分もあります。

見積りは当初仮説に過ぎないことを十分に理解し、プロジェクトをマネジメントすることが大事です。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

“ソフトウェア開発の見積りと実行は分業してはならない” への1件の返信

コメントは受け付けていません。