システム開発の工数見積りの実態

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

一例にすぎませんが、参考まで。

見積り式の例

あるシステム機能の開発工数を見積る際に、その機能の「難易度」や「規模」を(どうにかして)たたき出し、それらしい指標や係数を駆使する場合があります。

これを数式として表すと、こんな感じです。

  • 開発工数 = 規模×難易度に応じた係数÷生産性

例えば、とある機能αの開発規模を2KS、難易度Aの係数を1.2、チームの生産性を1KS/月だとしたとします。

この場合、機能αの開発工数は2.4人月(=2KS×1.2÷1KS/月)となります。

見積りは妥当なのか?

さて、ここで?マークがたくさんでてきます。

この開発規模をどうやって見積もったのか?難易度はどうやって決めたのか?係数は妥当なのか?生産性はどうやって決めたのか?担当者が変われば生産性も変わるのではないか?オーバーヘッドは含まれているのか?・・・などの疑問です。

私の経験上、このような多数の”?”に対する万人が納得する答えはありません。

実際には、これらの要素(開発規模や難易度、生産性など)は、見積り担当者の経験と勘と度胸で決められているものであり、また、その組織独自のガイドラインのようなもので決められています。

ガイドラインは過去のシステム開発プロジェクトなどの実績データを参考に作られていることが多いのですが、通常、プロジェクトの置かれた状況はまるっきり違いますので、どこまであてにしていいかは疑問です。

ともかく、それらしいガイドラインがあり、そこから大きく逸脱しない程度に見積り担当者の経験と勘と度胸で決めている、というのが開発工数見積りの実態です。

工数見積りの実態

開発工数を開発規模や難易度などの要素に分解しているのは、経験による勘の精度を高めるためでもあり、見積りの根拠とするためでもあります。

「分解による精度の向上」とは、どういうことかといいますと、「今いる場所から富士山の頂上までいく場合の所要時間を算出する」というようなケースを想像すればお分かりになるでしょう。

このように分解して、システム機能毎に開発規模や難易度を予測しているわけですが、実は、このように分解する前に答えを持っていたりもします。

頭の中では、

  • (直感だと)この機能だったら、だいたいこれくらいの工数かな。
  • では次に規模と難易度と生産性から工数を算出してみよう。
  • うん、だいたい同じ数値だな。じゃあ、そんなに外れはないだろう。

というようなことをやっていたりします。

仮に、直感ではじき出した工数と要素から算出した工数が大きく違う場合は、より細かく要素分解したりその機能に潜む不確定要素やリスクを洗い出します。

それで納得できる数値を出したら「では、これくらいの工数とするために、規模と難易度(と場合によっては生産性)をこれくらいの数値にしよう」というようなことをやるわけです。

見積りは意思表明

こう書くと「なんていい加減なんだ!」と思う方もいるかもしれません。しかし、そもそも見積もりなんてどうやったっていい加減なものです。

野球選手が、打率3割は約束できないが、打率8割や打率1割にはならないよ、と言うのと同じようなものです。

結局、見積りとは「この機能ならこの工数でやれる、やる」という意思表明です。

あーでもないこーでもないといろいろ考えたあげく、意を決して、プロとして意思表明するからこそ 、その数値を遵守しようと努力するわけです。

そういう意味で、見積りする人(見積工数の遵守に対する圧力がかからない人)と開発する人(見積工数の遵守に圧力がかかる人)が違うプロジェクトがありますが、これは最悪だと思います。せめて、見積りを外に出してしまう前に、十分に摺り合せるべきです。

こちらのエントリーも参考にどうぞ。
ソフトウェア開発の見積りと実行は分業してはならない

参考文献

もう少しまじめにソフトウェア開発の見積もりについて学びたい方はこちらの本がよろしいかと。メジャーどころのITベンダーの見積もり方式の例も掲載されていて資料集みたいなものですが、こういう(見積り工学のような)世界があることを知っておくことはよろしいんじゃないかと思います。

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

カテゴリーIT