BLOGあります

　見積もりをするに当たって最も重要なのは、システム・ソフトウェアの目的です。 開発されるシステムやソフトウェアには達成すべき目的があり、これらをまとめたものが要件定義となります。しかし、現実問題として、 要件定義書に記載された内容を達成するのに必要な時間、開発コストを見積もらないことには先には進めません。

　ここで前回のエントリーでも出てきた「人月」という単語がキーワードになります。人月とは、一人の作業者が実施可能な作業量です。 ここには個人差もあるのですが、たいていは平均的な数値を割り当てます。組織によって異なりますが、 1人月で作業可能な時間は決まっています。例えば1ヶ月の稼働日が21日ならこれに1日の作業時間(ここでは6Hとします)をかけると、 126Hの作業時間があります。これが基準となります。

　さて、ここからがさまざまな方法論によって評価が分かれるところですが、 要件仕様書に定義された機能などを実際の作業時間に落とし込む必要があります。ある方法論では、 プログラムのステップ数(LOC法)に着目し、ある方法論ではソフトウェアの機能を換算します(ファンクションポイント法)。

　いずれの方法論にしても、経験や個人差によるところが多く、正確な見積もりは困難です。また、どのような方法論を使っても、 要件を時間やお金に換算することには変わりません。通常は機能を作業時間に換算します。

　機能ごとの作業時間が得られれば、それを元に1人月の基準作業時間(先の例だと126H)を使って、 開発全体に必要な時間を求められます。この段階では、開発にかかる概算のコストも割り出されています。

　吉田はこの見積もり方法には2つの問題があると思っています。

(1) 評価基準が作業時間

　工数がかかればかかるほど、コストが高くなります。要求仕様による満足度や、品質、 実際の納期より早く仕上がった作業スピードなどの評価は加味されません。もし、 報酬がプロの技と製品の品質に対して支払われる性質のものであれば、作業工数をベースにした見積もりは好ましいものとは言えません。 この方法を使う場合、見積もりの工数を多めにとって、より早い時間で終らせ、差分を成果報酬と考える他はないからです。すると、 慢性的に見積もり時間は長くなり、見積もりの精度(作業内容に対する作業時間の見積もり)はどんどん悪くなっていきます。

(2) 要求を工数に直す精度

　ソフトウェアの規模で見積もるにせよ、機能で見積もるにせよ、判断基準は過去の経験と知識です。前提条件として、 過去に類似の作業をこなしていないと見積もれません。また、見積もりをした人と、作業をする人が違う場合、 技術と経験の差が見積もりの誤差として乗ってくる場合があります。
　一件客観的な評価に基づいた計算式に見えても、作業の複雑さなど主観による評価が混入します。

見積もりの問題に対する答えは見つかっていません。

　吉田の場合は、作業者＝見積もり者であることが多いため、作業工数に直す精度はまずまずだと思いますが、 飛び込みの仕事や優先順位によるスケジュールの遅延には対処法を見つけられていません。