アークウェブシステム開発SandBox

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（1） へ行く。
  • 1 (2008-10-30 (木) 11:40:35)

ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（1）

ソフトウェア見積り―人月の暗黙知を解き明かす
http://www.amazon.co.jp/dp/489100522X

の読書メモを記していきます。

1章 見積りとは †

• 見積りの精度を向上させるためには、「見積り」、「ターゲット」、「コミットメント」を区別して考えることが重要(p.3)

見積り

プロジェクトにかかる期間やコストを予測すること

ターゲット

実現したいビジネスの目標。達成可能なものとは限らない。

コミットメント

定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束。コミットメントと見積りが同一のものである場合もあるが、コミットメントと見積りが同一で「なければならない」と考えてはいけない。

• 見積りは先入観に縛られない分析的なプロセスであり、ゴールはあくまで正確性であって、特定の結果を追求することではない。一方、計画のゴールは特定の結果を追求になる。「見積りとは計画を立てることではないし、計画は見積りを作ることではない(p.4)」

• 見積りと計画は全く異なるものであるから、求められているものが見積りなのか計画であるのかを意識することが重要。

• シングルポイント（＝幅のない）の見積りは、結果と計画値が一致する確立を100%としていて、現実的じゃない。たいてい、シングルポイントの見積りをみたらそれは見積りではなく、ターゲットなのではないか見極める必要がある。

良い見積りとは？ †

• 「ソフトウェアプロジェクトが直面するあらゆる不確実性を考慮するのが、正確なソフトウェア見積りというもの(p.7)」

• 見積りには不確実性が存在するから、プロジェクトの完了は確立分布に従う。ただし、プロジェクトがうまくいくことには限界があり、うまくいかないことには限界がないため、確立分布はスケジュールが縮まる方向には詰まった形、スケジュールが伸びる方向にはしっぽが伸びた形になる。

• あらゆる見積りには確率が含まれており、確率を明示した見積りが良い見積り。

• 良い見積りには専門家によって様々な提案がされている
  • プロジェクトのコントロールが適正であれば、見積りに対してプラスマイナス10%の正確性を達成することが可能である（Capers Jones）
  • 良い見積りのアプローチとは実績値の75%のケースで誤差が25%以内に収まる良い見積りを提供することである（S.D. Conte、H.E. Dunsmore、V.Y. Shen）

• CMMレベルが向上されるほど、見積りと実績値との誤差が改善されていく
  • 「見積り結果の正確さは、見積り作業のみによって達成できるものではない」(p.12)。プロジェクトコントロールが同時に存在する必要がある。

• 見積りは害宇宙のどこかに鎮座する予言ではない。プロジェクトに降りかかるさまざまな変更に影響を受ける。

2章 見積り能力のチェック †

• 以下の見積り能力のチェックテストが掲載されていて、実際にやってみたところ自分の正解数はたった3問^^;

それぞれの問題について、正解は90%の確度でこの範囲内にあると自分が考える範囲の上限と下限を記入すること。範囲の大きすぎたり、逆に小さすぎたりしないように気をつける。自分の最善の判断として、正解が含まれることが90%は確かだと思える幅を記入すること。このクイズはあなたの見積りスキルを見るものであり、調査スキルは関係ない。したがって、答えを調べたりしてはいけない。それぞれの問いにあなたなりの答えを記入すること。空欄は誤答として扱う。回答時間は10分以内。(p.17)

見積り能力のチェック（一部抜粋）

• 本によると著者が試した直近600名の平均正解数は2.8問。8問以上の正解者はわずか2%、全問正解者はいない。著者が述べている「常人が直感的なセンスで考える「90%確か」は、実際には「30%確か」にほぼ近いと言わざるを得ない。(p.19)」、「「90%」といった特定のパーセンテージは、何らかの統計的な分析の裏付けを持たない限り、意味がない(p.19)」をチェックによって身体で理解したよ^^

• 以上から、著者は自分達の作る見積りは一般に幅が狭く見積られており（なんせ全問正解者はいなし、90%の確度を見積るこのチェックにおいて9問以上の正解は2%以下なのだから）、かつ幅の狭い見積りの方が、幅の広い見積りよりも正確だと信じがちな傾向があることを指摘している。裏づけもないままに見積り幅を狭めてはいけない、もっと広げないといけないということか。しかし、自分がチェックを行った時はできるだけ幅を狭めないといけないという意識を感じながらチェックを行ってたなぁ。

• チェックテストの問題文には「幅は広すぎても狭すぎてもいけない」とあるのに、回答者の多くは「できるだけ見積り幅を狭く設定しないといけない」というプレッシャーを感じるらしい。自分も先に書いたように感じた。つまり、このプレッシャーは個人の勝手な思い込みに起因しているということ。著者は以下のように述べて、見積り幅を狭くするプレッシャーを感じたら、それが自分の思い込みでなく実際に存在するものかどうか確認することを進めている。

  　プレッシャーの一部は、プロフェッショナルとしてのプライドに起因する。幅の狭さが良い見積りの条件だと誰もが誤解しているのだ。また、プレッシャーの一部には、不必要に幅の狭い数値を要求するボスや顧客とのやり取りの経験から生じるものもある。

2章の感想 †

• 自分の「90%確か」はまったくあてにならない！！
• 無意識に幅の狭い見積りが正しい（＝正確）な見積りであり、それが期待されていると思い込んでいる。実際はもっと幅を広げないといけないのだなぁ
• しかし、そうはいうものの、実際の業務での見積りにおいて「○○機能は5〜20人日です！」みたいな見積りは出しにくい、というかほとんど無理じゃなかろうか。こう考えること自体が幅の狭い見積りが正しいという思い込みなんだろうけども。発注側の立場に立つとどうなのかなぁ。
• ともかく勝手にプレッシャーを感じていないかチェックするというのは良いプラクティスと思う。