ソフトウェア見積り－人月の暗黙知を解き明かす－読書メモ（1） http://www.ark-web.jp/sandbox/wiki/3077.html

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

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

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

1章 見積りとは †

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

見積り

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

ターゲット

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

コミットメント

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

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

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

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

良い見積りとは？ †

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

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

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

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

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

• 見積りは外宇宙のどこかに鎮座する予言ではない。プロジェクトに降りかかるさまざまな変更に影響を受ける（要求が変わったり、メンバーが変わったり、優先度が変わったり、スコープが変わったり、そもそもターゲットが変わったり、etc...）。だから、「「良い」見積りはその見積りがどれだけプロジェクトの成功に寄与するかを基準にしなければならない(p.13)」

• 「ソフトウェア見積りの主目的は、プロジェクトの結果を予言することではない。見積りを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである。(p.14)」

• 「良い」見積りの実務的な定義を著者は以下にあげている

  良い見積りとは、プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な始点を提供する見積りである。(p.15)

1章の感想 †

• 「見積り」、「ターゲット」、「コミットメント」の違いはちゃんと意識できていなかった。ざっくりいえば「見積り」は分析と予測、「ターゲット」は目標、「コミットメント」は約束。これを区別しておかないと、見積りに先入観が入ってきて、計画が拙いものになったり、求められているものとピントがずれた回答をしてしまうということか。

• 見積りと計画は違うという意識は重要。見積りはあくまで客観的に確率を意識して分析して行わなければならず、計画はそうした見積りを行った上でコントロールも考慮したプロセスを提案できないといけない。

• 見積りは予言でなない（だから+-5%の正確性に拘るようなことはあまり意味がない）というのははっとする考え方だった。プロジェクトコントロールなしに見積りの正確さを担保できないというのも言われれば確かにその通りなのだけど、見積り中はそう思っていないことが多々あるなぁと感じた。

• 見積りは正確であることが全てに優先すると思っていた。確かに、正確をゴールとして求めるものなのだけど、「見積り」の正確性はあくまでターゲットを達成するためのプロジェクトコントロールに適正な意思決定を与えるための信頼できる視点を与える程度に必要十分であればよいということ。プロジェクトの成功に寄与しない正確なだけの見積りはあまり意味がないのだなぁ。

• 確率を見積りに表現していくというのは、うまい手法を考えないと。シングルポイントで明示される見積りに見積りを要求する側もなれているだろうから。「このプロジェクトは14週～20週の範囲で90%以上の確率で完了できます」とかって報告の仕方は少なくとも日本の商習慣の中ではあまりアリになっていないような。。。いや、これは見積りというより計画を報告するときの工夫か。

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人日です！」みたいな見積りは出しにくい、というかほとんど無理じゃなかろうか。こう考えること自体が幅の狭い見積りが正しいという思い込みなんだろうけども。発注側の立場に立つとどうなのかなぁ。
• ともかく勝手にプレッシャーを感じていないかチェックするというのは良いプラクティスと思う。

投稿者進地 | パーマリンク

|

Menu

• システム勉強会
• オープンソース・ライセンスなツールなど
• Plaggerでみんなのブックマークをアグリゲート

Movable Type用プラグイン Aシリーズ

ECサイト構築 Zen Cartハイエンド

Tag

最新の20件

ARK-Webビジネスブログの最新記事