Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

見積のことをもっと知りたい ~犬も歩けばCOSMICに当たる~

TDD の勉強会で LT させていただいたところ、少しアクセスが増えています。
当ページをご紹介下さった方、ありがとうございますm(_ _)m

LT では「見積のことをもっと知りたい」的なことをしゃべりましたが、
見積関連の情報にいろいろあたってみてました。


『ソフトウェア見積り―人月の暗黙知を解き明かす』と『アジャイルな見積りと計画づくり』を
再読しましたが、あらためて感じたのは、

 「これは私がやっている "見積" ではないのでは?」

ということでした。これらの本で言われていることは

 結局、見積もプロジェクトをコントロールするためのパラメータの1つにすぎない
 都度見直しして、プロジェクトの先行きを考えよ

ということです。アジャイルであろうがなかろうが。
尤もなことなのですが。

翻って「私の(必要とする)見積」とは、

 受注額や開発期間を決めるために、事前に明らかにしなければならないもの

なのです。この違いは大きい。

本の書かれている背景として「内製のカルチャー」があり、
一方、我々は「一括請負のカルチャー」の中にいるという、立ち位置の違いがあるように思いました。


さらに私を悩ませたのがこの議論です。

 そもそも見積なんてしないほうがいい
 時間の無駄だし、未来のことなんて誰にもわからない

以下、ネットからいろいろ抜粋。

『ザ・ゴール』から学ぶプロジェクト型組織変革~TOC/CCPMで組織を変える~

「全体計画を詳細に定義することは不可能である」

なぜプロジェクトの進行計画はいつも壊れるの? 「クリティカルチェーン・プロジェクトマネジメント」とは

不確実性の高い作業を詳細に分解しても、不確実性をすべて抑え込めません。
むしろ細かくすればするほど「創作」や「作文」が多くなり、精度は悪化します。
要するに作業をどれだけ分解しても、開発工程の時間見積もりは正確にはできないということなのです。

ストーリーポイントは複雑さや時間と関係があるか?

見積りはムダです。(...)
始めてしまった方がずっといいのに、みんな細かいことを議論するのに時間を費やしています。

Scrumでのプロジェクト初期の見積もり

ちなみに見積もりなんてあたんないので(もちろん当てる努力はするし、
当たった方がいいのは勿論なんだけど)、そのつもりで考えたほうが良いです。
例えば競馬で一点買いして毎回的中すると思う幸せな人はあまりいないけど、
一方でプロジェクトの見積もりは毎回当たると考えちゃうのはどうかしてる。

見積もりは無駄なプラクティスか?

コストの見積もりを行い管理するのに費やされるエネルギーは、それらをもつ価値を上回ります。

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?PurposeOfEstimation

何でもいいのでアジャイルの勉強会へ行ってみて下さい。そしたら、見積もりなしに効果的に仕事をするチームの話を聞くことができるでしょう。いつもこれは上手くいきます。なぜなら、彼らと彼らの顧客が、見積もりをすることが重要な決定に影響を与えることにはならないと分かっているからです。

ソフトウェア開発プロジェクトをとりまく6つの誤解

 誤解:正確な見積もりを出すことが出来る の項

「始める前にざっくりで良いんで見積もり出来ますか?」

(...)

果たして、ざっくりの見積もりに本当に意味はあるのでしょうか。もし、ざっくりの見積もりで予算を超過するというならば、どうするのでしょう。無い袖を振ることはできません。

だからといって、どの機能を削ればどの位のコスト削減になるのか、といった話をするためには、ざっくりの見積もりで出来るとは思えません。


見積も、作ることも、私たちの仕事ですが、やっぱり 見積 < 開発そのもの のはずです。
こんなに悩むくらいなら、作ってしまうほうがラクだ。。。

「そもそも見積は当たらないもの」という前提で、お客様とお話しが進められるといいのですが。
社内でもそういう合意の中で会話ができるといいのですが。

(余談になりますが、ここを避けるために「見積前提」なる言い訳をたくさん並べるのも
見積が徒労感の多い仕事になってしまう一因だと思うのです、スコープを限定するためではありますが。
結局それも、お客様との認識の擦り合わせをするための材料であり、
見積は「たたき台なんだよ」というもっと有意義なものになればいいだけなのです。)


やはり行き着くところは、ここでも「銀の弾丸」ということなのでしょうか?

IT業界の中では、見積り手法に対する過大な期待があります。 これは、
「ある日、天から降ってきた黄金の方程式によって○%以内の精度でピタリと当たる手法が現れるはず」
という期待です。しかし、そのような"銀の弾丸"はありません。
なぜならば、見積り手法はパラメータと係数から構成されており、
この係数は見積り手法を開発した人が入手した実績データから作成されているからです。

 (「脱・ベンダー任せ!! "見積力"養成塾」より)

今回いろいろ資料を読んだことで「見積手法とはこういうことなのだ」ということをあらためて学びました。

私が見積をもっとうまくやりたいと思うのは、
プロジェクトの成功のために「どうやったら見積の精度は上がるのか」「もっと軽量な見積手法はないのか?」
というところから始まったものです。
だから、もうちょっとだけがんばって、見積手法そのもののことをちゃんと知っておきたい。


組込み向きのファンクションポイント法として「COSMIC法」というのに出会いました。

日本ファンクションポイントユーザ会のサイトより
COSMIC法マニュアル

東芝情報システム株式会社
COSMIC-FFP法による組込み系ソフトウェアの規模測定

このへんの資料にざっと目を通して、今はこちらを読み始めています。

『ファンクションポイントCOSMIC‐FFP法実践ガイド 組込み系・リアルタイム系に最適なソフトウェア規模・工数の見積り方法』

COSMIC法については、整理してまた書きたいと思います。