今回は見積りを不正確にする原因について書くつもりでしたが、前回のBlogが長かったので少しコーヒーブレイクをとりたいと思います（私が？）。前回同様『ソフトウェア見積り―人月の暗黙知を解き明かす』より、シンプルだけど非常に重要な概念をご説明します。

見積りなんて意味ないよ

ソフトウェア業界でよく言われ皮肉に以下があります。

• 参考に出したはずのざっくり見積りがそのままスケジュールになる
• リリース日はあらかじめ決定されており、見積りはそれに合わせて作られるものだ

私にも経験がありますがこれらはソフトウェア業界の実態を言い表しています。こういうことが続くと自然と「見積りなんて意味ないよ・・」というマインドになるもの無理からぬところでしょう。

上述の問題は、ビジネス上のいくつかの概念を全て「見積り」という１つの概念で表現しようとしていることに端を発しているように見えます。その概念とは「ターゲット」、「見積り」、「コミットメント」の３つです。

ターゲット、見積り、コミットメント

これらの概念は通常あまり区別されませんが改めて区別してみると非常に納得感があります。以下それぞれについて説明します。

ターゲット

• 実現したいビジネス上の目標
• 例）年末商戦までにこのバージョンをリリースする必要がある。

見積り

• プロジェクトにかかる期間やコストの予想
• 例）調査の結果、このバージョンをリリースするには12ヶ月必要です。

コミットメント

• 定義された機能を特定の品質レベルを確保しながら期日までに納品するという約束
• 例）年末商戦までにこのバージョンの全機能の60%をリリースしましょう。

ビジネス上の観点から、ターゲットを見積りよりも早い地点に設定することが重要な場合もあります。ただしそれが達成可能かどうかは別問題です。コミットメントは見積りとターゲットを意識した上で決定されます。見積りより挑戦的だったり保守的であったりすることもあります。

まずは区別する

ほとんどの場合、上記の3概念は明確に区別されず話されているのではないでしょうか。特に開発者でない人はこの3つを同義語として捕らえてしまう傾向があるかも知れません。これらの概念を明確に区別すると以下のリスクヘッジが図れます。

• 見積りに対するターゲットの乖離度がわかる
• 見積りに対してコミットメントがどの程度強気なのかがわかる

 自分たちの身を守るために、ひいては会社を変な方向に導かないためにもこれらの概念を明確に区別した上でプロジェクトを進行させることをお勧めします。