プロジェクト開発に関する見積について過去の振り返り

IT開発プロジェクトにおける規模見積について考えてみた。

IPA情報処理推進機構によると、見積の要素としては、以下の要素が挙げられている。

"

規模

　ファンクションポイント

　コード行数

 　機能数、画面数、テーブル数

その他見積りに影響を与えるもの（工数の変動要因）

　プラットフォーム/環境

　ハードウェア、オペレーティングシステム

 　言語、ツール、ユーティリティ

 　開発環境

プロダクト

　アプリケーション種別

　複雑度、要求される信頼性

　ライフサイクル

人材

　能力と経験

　総労働時間

"

見積は当初の計画時からどんどん増える方向に乖離していくものである。（残念ながら少なくなる方向に乖離していくことは経験したことがない。そういう事例はあるのだろうか？）多くの場合、計画（提案）時には、上記の要素の大部分はわからないことが多い。そこで、経験者、あるいはひどい場合は開発未経験の営業さんがエィっとドンブリ勘定で出すことが多い。さらには、「予算はこれぐらいと決まっているから。この範囲内でよろしく！」とどんなことをするのかも決まっていないのに型にはめられてしまうこともある。

自分が経験した中で一番優れた見積は、ある中規模SIベンダーさんで、上記のような要素を入力すると自動的にブレ幅も示した上で、開発規模を算出してくれるツールをもっていた。しかも過去の多数のプロジェクトの実績を加味しながら、そのツールは常に進化し続けていて、かなり精度の高い見積を出すことができたことがある。またそのプロジェクト独自の要素（今までに使ったことのない言語であるとか）も加味することができて非常に良くできたツールであった。

大規模SIベンダーさんであれば、過去事例も山ほどあるはずとおもうがそういったツールは、後にも先にも１度しか経験していない。（過去事例の要素を洗い出してみて、実績と突き合わせて分析すればかなり精度の高い見積が出せそうと思うのだけれども）

仮説に仮説を重ねて何らかの数字を出していってもほとんど意味のない数字になってしまう。が要件定義の具体的な個別タスクの工数の積算などそんなことをよくやった記憶がある。

成果物に対しての作業工数が測りにくい作業に対しては、作業の積み上げによる積算よりも、全体から俯瞰して算出したほうが良いような気がする。「考える」作業に対しての見積は一筋縄ではいかない。最終的には１ページの要件定義書であっても、それを作り上げる過程ではたくさんの会議があって、うんうんうなりながら考える時間がある。また会議で説得するための資料作りなどの作業もあまり目には見えない。なので細かい作業の一つ一つを洗い出して積み上げると、とんでもない工数となる。（それぐらいかかるのが現実に近いのだけれども）

大体のプロジェクトにおいては、もう「やりたいこと」がほとんど決まっていることが、前提になっている気がする。しかし実態は「やりたいことがわからない」ほうが多いと思う。「古いシステムと同じで！」というのも「やりたいことがわからない」に等しいと思っている。そういった場合には、要件定義の工数は際限なくかかっていく。そしてデスマーチへとつながっていく。