ソフトウェアの見積もりって難しい

今日からMOTのケース演習は新たな課題が始まります。

僕はソフトウェア・プロジェクトマネジメントを選択したので、これから１ヶ月間は「ITプロジェクトの見積もり」についてケーススタディを行っていきます。キーワードはFunction Point法らしいのですが、hsurはFunction Point法のことを良く知らないので興味深々です^*1。

宿題はRFPに対する提案書作成なので、ちょっときついです。っていうか、これ、仕事でやっていることそのまんまって感じ。まぁ、ケーススタディとしてはリアリティがありすぎる内容なのでそれはそれで面白いですが。

† ITプロジェクトの見積もりは難しい

ITプロジェクトの見積もりは難しい・・・・というか、不可解な部分が多いです。特にソフトウェアの開発では大部分が人件費になるのですが、その算定根拠がかなり怪しかったりします。以前にも書きましたが、ソフトウェアの生産性は計ることが出来ないというところにそもそもの問題があると思っています。

† さらに難しいプライシング

さらにプライシングの話になるともっと不可解なことが増えてきます。何せ「１円入札」があったりするわけですから^*2。

人のことばかり言っていても何なので、うちのオフィスがやっているプライシングの話を少し。基本的には収益分配型の料金体系になっています。売上の何パーセントとか、利益の何パーセントとかそんな感じ。それに個別の事情に応じたオプションがつきます。そういうプライシングは個人的にわかりやすくてよいと思っているのですが、どうでしょうか。

† 見積もり技法のいろいろ

PMBOK Guideによれば見積技法は３つに分類されるようです。
ＦＰ法は係数モデル見積もりになるのでしょうか。

　・類推見積 ( Analogous Estimating )
　　　過去の事例、経験から類推して見積もる
　　　この経験というのが曲者で、属人的な技法である
　　　一般的には精度が一番悪いとされているが、上記の要因でかなり変動がある^*3
　　　プロジェクトの企画段階など、具体的な内容が決定される前はこれしかやりようが無い

　・係数モデル見積 ( Parametric Modeling )
　　　係数モデル（数式）に当てはめて算出
　　　モデルはあくまで一般解であり、状況にあわせてチューニングの必要がある
　　　モデルは万能ではない

　・ボトムアップ見積 ( Bottom-up Estimating )
　　　(WBSなどで)作業を分割して積み上げる
　　　一つ一つの粒度が小さいので、見積もり結果はかなり高くなる
　　　精度が高いといわれているが、プロジェクトが固まってこないとそもそも使えない

そのほかにも良くない方法として以下の方法があるようです。

　・Price to Win法
　　　見積もりはお客様の予算で決まる

　・Perkinson法
　　　見積もりは開発設備（チームに参加する開発人員）によって決まる
　　　時間があれば仕事量が増える

お客さまのお財布を無視して見積もりを考えるのは現実離れしているし、チームのようなものが存在すればのその一部だけで何かをするのは難しいのでそんなに人がいらないけど全員参加になってしまうっていうのはありがちだし、時間も３ヶ月のプロジェクトと６ヶ月のプロジェクトでは盛り込まれる機能が違うし・・・・っていうことを考えると、現実的にはこういう見積もりが多いような気がしますが、どうなんでしょうかね。

† 最適開発期間

個人的に面白く感じたのは規模に応じた最適開発期間の話でしょうか。ある人の統計によれば納期を半分にすると、コストは５倍になるそうです。

いつも開発に関わっているという立場からいえば、開発期間が３ヶ月だと思えば３ヶ月になりますが、２ヶ月といわれれば２ヶ月に収められるようにしてしまいます。そこに、効率とか負荷というファクターを導入して、それらの最適が存在するという考え方が面白かったですね。

† 参考