レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

見積もりの良し悪し

プロジェクトマネージメントで四苦八苦しながら考えてることをまとめていきたいと思います。


マネージメントに首を突っ込んだ当初「見積」をどうやっていいかわからなくて困った。
「不確実な未来をどう見積もったら良いのか?」に非常に苦しむ。
見積段階は、システム構築に必要な情報がそろっているはずがなく、
要件定義すら完了していない初期段階であることが多い。
そもそも完璧な未来予想など出来るはずがない。と半ばサジを投げて、

適当に要求に重みを付けて、リスク係数を掛け、人月を積み重ねるやり方をしていた。
しかし、これでは結局あてになりそうもない数字が飛び出てびっくりする。

この問題に間接的に光をくれた書籍が以下だ。

成功する要求仕様 失敗する要求仕様

成功する要求仕様 失敗する要求仕様

著者アランいわく

P23
(抜粋)
・・・もうひとつ気になるのは、要求がスケジュールをきめるのか、それともスケジュールが要求を決めるのかという点だ。私は、スケジュールが要求を決めるべきだと強く感じている。
(中略)
「コスト優先設計(Design To Cost)」の考え方に非常によく似ている。

要求をフルに実現するために必要な人月を予想しても意味を成さないから、
コストを先に割り当て、その範囲で要求をマネージメントするべきなのだと読み取った。

不確実な未来をどのように予想するかを必死で考えても、それは土台無理な話しである。
要求に対する期間的、金額的許容範囲と全体でのバランス、進め方などを
「見積もる」のではなく「計画する」という意識で考えると、未来がよりはっきりしてくる。

コストを決め、コストに収まる要件を定義し、常にコストをコントロールするほうが、
発注側・受注側共に納得のいく結果が得られるだろう。