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

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

1章見積りとは
- 良い見積りとは？
- 1章の感想
2章見積り能力のチェック
- 2章の感想

ソフトウェア見積り―人月の暗黙知を解き明かす
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

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

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

Tag

最新の20件

2017-05-12

RecentDeleted

2014-04-30

JavaScript/クラス名を後から取得する方法

2013-09-16

ドメイン駆動開発/DDD体験ワークショップに参加しました（PHPカンファレンス2013）

2013-02-21

MenuBar

2012-09-04

2012-04-03

Ruby on Rails/rvm+passenger+mod_proxyの設定

2012-02-29

システム勉強会

2012-02-06

FrontPage

2012-01-19

2011-12-19

ネットワーク/socks5経由でsftp

2011-11-13

wakame/wakame-0.5.1 on Ubuntu-server 10.04 LTS Lucid Lynx

2011-08-08

mysql/groonga on Ubuntu-server 10.04 LTS Lucid Lynx

2011-07-07

2011-02-17

JavaScript/jQuery_Cycle_Pluginでメインビジュアルを作っていくチュートリアル

2010-12-02

paypalの決済の種類とビジネスモデルについて聞いてきました

2010-11-04

jQuery Mobileの使い方と挙動のまとめその１

2010-09-16

jQTouchの使い方とclass指定による挙動のまとめ

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

2014-01-08

Zen Cartのセキュリティー保守・脆弱性パッチ適用などでお困りなら

2014-01-07

コンテンツ・マーケティング：ダイナミックコンテンツ、スマートコンテンツという潮流

2014-01-06

新年あけましておめでとうございます（2014年最初のご挨拶）

2013-12-13

年末年始の休業期間のお知らせ（2013年～2014年）

2013-12-11

Zen Cartハイエンド版のモジュール：social_buttonsによりコンテンツを共有する

2013-11-29

「Zen Cartのカスタマイズ」ページを公開しました

2013-11-28

Zen Cartハイエンド版のモジュール：am_ajax_addressで郵便番号による住所自動入力をサポート

2013-11-26

北米NGO/NPOの７割はコンテンツマーケティングを去年より強化、第一目的はファンドレイジング、Facebookをよく使う（CMIのレポートから）

2013-11-19

Zen Cart1.3.0.2 EUC-JP版とPHP5.4の組み合わせで日本語（マルチバイト文字）が表示されない障害

2013-10-28

【Movable Type】MT6の最新情報と活用ポイント紹介のセミナーに登壇します

2013-10-18

【消費税増税】Zen Cartで消費税を変更するには：1.3.0.2系と1.5.1系の場合

2013-10-15

【脆弱性対応】A-Form 3.7.7 / A-Member 3.7.7 / A-Reserve 3.7.7をリリースしました。

2013-10-11

【重要なお知らせ】MTプラグインA-Form・A-Member・A-Reserveの脆弱性について（2013年10月11日三版）

2013-09-26

Zen Cartハイエンド版のモジュール：product_csvで商品データの一括インポート・一括エクスポートをする

2013-09-24

NGO、NPOや震災被災企業・団体の方へ：弊社MTプラグインがすべて「無償」になりました

Last-modified: 2008-10-30 (木) 12:13:04 (5657d)

アークウェブのサービスやソリューションはこちら

サービス

Zen Cartソリューション

Movable Typeソリューション

その他ソリューション

アークウェブのCSR(企業の社会的責任)

アークウェブのCSR指針