2008年12月11日
ソフトウェア見積り-人月の暗黙知を解き明かすの第1部読了 - (1)
こんにちは、SEの進地です。
弊社では毎週木曜日の午前中 10:00~12:00を使って5%クラブなる活動を行っています。
この5%クラブでは、スタッフが各自、自分の興味のある分野の勉強を行い、これをアウトプットする時間に使うことができます。の5%版といったところです。
この5%クラブを使って進地は今、日経BPソフトプレス、Steve McConnell著の「ソフトウェア見積り―人月の暗黙知を解き明かす」を読み、読書メモを弊社のSandbox Wikiに書いていっています。
ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(1)
ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(2)
ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(3)
ソフトウェア見積り-人月の暗黙知を解き明かす-読書メモ(4)
今回の5%クラブでちょうど第1部 「見積りの考え方」(第1章~第5章)を読んで、読書メモを書き終えたので感想や思うことなどをまとめて2回にわけて取り上げてみたいと思います。
「見積り」、「ターゲット」、「コミットメント」
本書ではまず「見積り」、「ターゲット」、「コミットメント」の違いを区別することが強調されます。大雑把にいえば、「見積り」は分析と予測、「ターゲット」は目標、「コミットメント」は約束に相当します。これがごっちゃになっていると、「見積り」に先入観が入ってきて正確な見積りができなくなります。「見積り」そのものはプロジェクトにかかる期間やコストを予測する分析的なプロセスなので、特定の結果を追求する計画を立てる行為とは区別しないと正確性が著しく犠牲になるわけです。「見積り」と「計画」は異なるものですが、「見積り」が不正確だと「計画」が土台から崩壊しますので、この視点は非常に重要だと思います。
「見積り」は確率で表現される
正確な「見積り」はソフトウェアプロジェクトのあらゆる不確実性を考慮するため、確率が必ず含まれることも強調されます。幅を持たないシングルポイントの「見積り」は確率を考慮していないため、「ターゲット」と区別がなされていない懸念が強いことも指摘されます。シングルポイントの見積りをみたらそれは「ターゲット」になっていないかを検討するのは良いプラクティスだと思います。
「見積り」の正確性はプロジェクトコントロール抜きでは成り立たない
「見積り」は予言ではなく、正確な「見積り」であるほど不確実性を包含しているので、その正確性はプロジェクトコントロールなしには担保されないという指摘も、考えてみれば当たり前なのですが、はっとさせられる指摘でした。「見積り」はゴールとして正確性を求めるものですが、±5%の誤差に拘ることにあまり意味はありません。その誤差はプロジェクトコンロールで補うべきものだからです。
「良い」見積りはその見積りがどれだけプロジェクトの成功に寄与するかを基準にしなければならない
本書で述べられている「良い」見積りの定義です。また、「良い見積りとは、プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な始点を提供する見積りである。」とも述べられています。「見積り」は正確なだけでは意味がないということです。もちろん、正確であることは「見積り」の大前提ですが、不確実性を考慮すればあくまで「見積り」は確率を伴う分析結果であって、それ以上のものではないということです。だから、「見積り」には、実際に「ターゲット」や「コミットメント」を実現する「計画」を立てるベースの情報として必要十分な正確さがあることが大事ということになります。シングルポイントで見積ってそれが当たった外れたで一喜一憂しがちな「見積り」に対する考え方を改めなくてはいけませんね。
「90%確か」のあてにならなさ
本書には見積り能力チェックが載っています。これは、是非、見積りを行うことがある人すべてにやってみて欲しいです。自分の直感で「90%確か」はまったくあてにならないことがよーくわかります。自分もやってみて衝撃を受けました。また、このチェックの評価では受験者は勝手にプレッシャーを感じて見積り幅を狭くとる傾向も指摘されていて、実際、自分もそうでした。勝手にありもしないプレッシャーを感じているのではないかとチェックし、そういう傾向にあることを自覚して幅をもっと広くとることが大事ということにも、このチェックで気付くことができます。
過大見積りの不利益は過小見積りの不利益よりはまし
正確な見積りの価値の議論の中で、「過大見積りの不利益は非線形、過小見積りの不利益は線形であるため、過大見積りの方がまし」ということが指摘されます。つまり、過大見積りの不利益は予測の範囲内に収まりますが、過小見積りの不利益はどこまで大きくなるか予測がつかないということです。なぜなら、過小見積りでは計画が早々に崩壊し、プロジェクトコントロールが不可能になり、上流工程の時間を充分にとれないためプロジェクトの後期にやり直し、手戻りが多発し、このことがさらにまたプロジェクトコントロールを混乱させるという悪循環に嵌るからです。また、過大見積りの不利益は計画とプロジェクトコントロールで対処できるし、すべき問題であるため、その不利益を減じることができます。
そのため、コンペの場合など、見積りを下げるバイアスがどうしてもかかる状況がありますが、この場合でも見積りを下げるのではなく、スコープ再定義やチーム編成、機能選択等を行って調整するべきということになります。見積りを受取る立場の方も、不当に小さな見積りが提示された場合にはそれが過小見積りに陥っていないか留意するのがより良いプラクティスかと思います。過小見積りは結果的にコスト超過がおきる可能性が高いだけでなく、プロジェクトコントロールが崩壊するため、プロジェクトの予測可能性が著しく損なわれる可能性が高いためです。
いずれにしても、正確な見積りがプロジェクトコントロールの肝であるという認識がとても大切で、見積りはあくまで正確性を尊ばなくてはなくてはならないことを肝に銘じました。
まとめ
第1章~3章までで重要だと感じた点、感想などをまとめました。より詳細には冒頭でご案内したSandbox Wikiの各読書メモをご覧ください。次回に続きで、第4章~5章のまとめを行いたいと思います。
タグ:
« 前の記事:アークウェブのお手伝い事例:ロック&ポップスのオンラインCDショップ「カケハシ・レコード」のウェブサイトをリニューアル
» 次の記事:アークウェブお手伝い事例:お茶ブランド「うおがし銘茶」様の映像コンテンツ制作のお手伝いをさせていただきました
アークウェブの本
Zen Cartによるオンラインショップ構築・運用テクニック―オープンソース徹底活用

内容充実のZen Cart公式本(v1.3対応)がついに発表です。アークウェブのスタッフをはじめZen-Cart.JPの中心メンバーが共著で執筆しました。続きを読む
新着はてブ
カテゴリー
- Shopify(ショピファイ)オンラインショップ構築
- NGO・NPO向け情報
- スマートフォン
- だれもが使えるウェブコンクール
- mixiアプリ
- OpenSocial (システム開発)
- アークウェブのCSR
- A-Form, A-Member, A-Reserve(MTプラグイン)
- Ruby on Rails(システム開発)
- necoったー
- Miqqle
- WebSig24/7
- ecoったー
- ビッグイシュー(The Big Issue)
- CSR(企業の社会的責任)
- マッシュアップ
- RIA (システム開発)
- セキュリティ(システム開発)
- 唐松(アクセス解析)
- Ajax (システム開発)
- テスト(システム開発)
- データベース
- PukiWiki
- Web 2.0
- SEO・サーチエンジン最適化
- XP・アジャイル(システム開発)
- Web・ITニュースクリップ
- Webアクセシビリティ
- Webデザイン
- SEM・サーチエンジン広告
- Webユーザビリティ
- CMS・MovableType
- Zen Cart(オンラインショップ構築)
- Snippy(SNS・ソーシャルブックマーク)
- アークウェブ
- オープンソース
- CMS(コンテンツマネジメント・システム)
- Webマーケティング
- AMP
- SNS