ソフトウェア見積り - Liberal Arts Life

ソフトウェア見積り―人月の暗黙知を解き明かす
スティーブマコネル Steve McConnell 田沢恵

日経BPソフトプレス 2006-10
売り上げランキング : 4338
おすすめ平均

今やっている仕事で開発工数を見積もらなければならなくなったのでこの本を読みました。

かつて私がプログラマーだったころ、まだ新人だったこともあって見積りという作業が必要であること自体知りませんでした。
先輩や上司もちゃんと根拠のある見積りをしていたわけではなく勘で見積もっていたようでした。
そんな状態だったので当時何回も火を噴くプロジェクトを経験して精度の高い見積りの必要性を骨身にしみて感じました。
そのときは自分なりの方法で見積り方法を考え出しましたが、この本は自分で考えた方法よりも網羅的で正確な見積りを出す方法がいろいろ紹介されています。

見積りの基本は工数の元となる要因の可視化と数値化です。
どういうことかというと、例えば機能が増えたりDBのテーブルが増えるといった作業工数が増える要因を割り出して工数に変換して足していきます。

ただ現状調査や要件定義などプロジェクトの初期段階では明確な工数は割り出せません。
なので工数を例えば100工数から200工数といった感じである範囲で予測してプロジェクトが進むにしたがって範囲を狭めて精緻化していくという方法をとります。
そもそもプロジェクトの初期段階で正確なコストを見積ることなどできないのですが、多くの企業では結構あて推量で見積もっているのが現状のようです。
しかしビジネスをやっていく上ではそうも言ってられない状況があると思います。
そんなときに著者が勧める見積り方法はマーケットファクターで見積もるという方法です。
例えばある製品で販売する上で販売時期が機能よりも重要なら機能を削ってリリースを早めることができないかといったことです。

　よく営業販売部門ではこの時期には絶対完成してほしいというのがあるので開発側の都合に関係なくスケジュールを強制してくることが結構あります。
これを見積りと勘違いしている会社が結構ありますが、これは見積りではなくターゲットです。
見積りとは人の意思に関係なく純粋にプロジェクトで必要となるリソースの合計です。
このターゲットと見積りのギャップをいかに縮めるかがプロジェクトの成功のためには重要になります。
この本ではターゲットと見積りのギャップを50%以下に収めないとプロジェクトが破綻する可能性が高くなると書かれています。

このあたりはSEのコミュニケーション能力が問われるところだと思います。
そんなときに営業側と議論するときは営業担当者にわかる切り口で状況を説明する必要があります。
例えばこの機能を実装するためにはこれだけのコストがかかるが、それだけの利益がその機能があることによって見込めるのかといった感じです。

営業側はがんばってとってきた仕事なので開発チームはちょっと無理でもやってくれてもいいじゃないかという気持ちがあるのでしょう。
また、営業は受注できれば自分の仕事が終わりなので後のことには関心がないのもあるかもしれません。
しかし、無謀なプロジェクトは会社にとって甚大な損害を与えることがあります。
それは顧客の信用をなくすことはもちろんのこと、優秀な人材が離職することにもなりかねません。

ソフトウェア見積りは目に見えなくて不確定なものを予測する作業です。
それはいろんな要因で変化する未来を予測することなのですから正確に予測するなんてどだい無理なことです。
しかし、論理的な方法をとればある程度妥協できる確度で予測することは可能です。
また開発する側にとっては無理なプロジェクトをごり押しで進めようとする力に対抗するためにも根拠のある反論ができます。
ソフトウェアというのは目に見えないので人間の認知能力では規模感が感じにくいものです。
それを誰にでもわかる形で伝えることはプロジェクト成功の重要なファクターだと思います。
この本はその方法のヒントを与えてくれるものとして一読する価値があると思います。