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

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

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

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

※ 引用内の強調は筆者（進地）による。
※ 引用内の中略は（中略）で示す。

3章 正確な見積りの価値 †

• 非現実的なターゲットと達成不可能なコミットメントによって見積りが不正確になり、プロジェクトが失敗するのは長年取り上げられている
  • 「多くのソフトウェアプロジェクトは、カレンダー時間の不足によって失敗している。これは他のすべての原因を合わせたものよりも多い（p.23）」（Brooks 1975）
  • 「締め切りのプレッシャーこそがソフトウェアエンジニアリングの最大の敵である（p.23）」（Costello 1984）
  • 「詰め込みすぎたスケジュールや不合理なスケジュールが、すべてのソフトウェアに最も破壊的な影響を与えていると考えられる（p.23）」（Jones 1994, 1997）

• 過大見積りと過小見積りはどちらがよいか？（より「まし」か？）
  • 過大見積りへの主な反対意見
    • 「パーキンソンの法則」（作業は、使用可能な時間を使い尽くすまで拡大する）が働く。4ヶ月でプロジェクトを完了できるプロジェクトチームに6ヶ月与えれば、チームは余った2ヶ月を使い尽くす方法を見つけて6ヶ月使い切るなど。(p.)
    • Goldrattの「学生症候群」（試験があることがわかっていても、試験直前まで勉強しないこと）が働いてダラダラと作業する。
    • 「必要以上に少ない見積りをしようとする動機は、開発チーム内に切迫感を植え付けたいという要求だ。（中略）私は3ヶ月というスケジュールをを主張する。実際に3ヶ月でそのプロジェクトを完成できると信じているわけではない。しかし、それを開発者たちに提示する。もし私が正しければ、開発者たちは4ヶ月から5ヶ月でやり遂げるだろう。最悪の場合でも、彼らが最初に見積もった6ヶ月以内でやり遂げるはずだ。（p.24）」
  • 過小見積りへの反対意見
    • プロジェクト計画の有効性が減少する。見積りはプロジェクト計画の土台になるものであるから、脆弱な見積りをベースに計画を作れば計画が足元から崩れる。プロジェクトコントロールもできない。「見積誤差が計画からわずか5〜10%程度外れているだけなら、それほど重大な問題を引き起こすことはないだろう。しかし、ソフトウェアの見積りはしばしば100%あるいはそれ以上に不正確であることが、多くの調査でわかっている（Lawlis, Flowe, and Thordahl 1995; Jones 1998; Standish Group 2004; ISBSG 2005）。（p.25）」
    • 開発者が作る見積りは、一般に実際の工数より20〜30%低くなる（van Genuchten 1991）。この見積りをそのまま使った場合、プロジェクト計画は実際より楽観的なものになる。そこから、さらに見積りを削れば予定通りに完了する確率がさらに減る
    • 少ない見積もりでは、上流アクティビティにほとんど時間を費やすことができない。品質の低い要求、設計でプロジェクトを進めれば、プロジェクト後期にやり直す羽目になり、結局、正確な見積りを使った場合に比べてずっと時間がかかる。
    • 遅延がプロジェクトをさらに破壊する。ひとたびプロジェクトが「遅延」するとプロジェクトが「予定」通りであれば発生しなかった数多くのアクティビティが発生してチームの時間をさらに奪う。具体的には、経営上層部との状況確認Mtg、プロジェクト後半の頻繁な再見積り、顧客への謝罪、宣伝用の暫定リリース版の制作、優先順位決定の議論（の増加）、切迫したスケジュールによる間に合わせ実装が引き起こす問題の解決など。「重要なことは、これらのアクティビティはプロジェクトがゴールを達成している場合には、まったく生じる必要のなかったものであることだ。（p.26）」

• Goldrattの「学生症候群」は、プロジェクトコントロールを通して対処すべきであり、見積りを少なくすることが解決策ではない
• 「パーキンソンの法則」は、確かに当てはまるが、プロジェクトを過小見積りすることが意味を持つのは、過大見積りによる不利益が過小見積りのそれを超える場合だけ。

• 「ソフトウェアにおいて、過大見積りの不利益は直線的で有限である。作業は使用可能な時間を使い尽くすまで拡大するだろう。しかし、それ以上は拡大しない。一方、過小見積りの不利益は直線的ではなく限界がない。計画の誤りや上流工程での手抜きによる多くの欠陥の作り込みは、過大見積りの場合よりも多くの損害を引き起こす。しかも、前もって損害の範囲を予測することはほとんど不可能だ。（p.27）」

• 結論としては、以下になる。
  • 過小見積りの問題は過大見積りより深刻で予測可能性が著しく低い
  • 過大見積りの問題は計画とプロジェクトコントロールで対処すべき

• 正確な見積りは過大にも過小にも大きく誤差を生じない見積りだが、私たちは過大にも過小にも見積もることがあるといった偏りのない見積りをしているというのは誤解。「業界のデータは、ソフトウェア業界に過小見積りの問題があることを明確に示している。私たちは見積りをもっと正確に行う前に、まず見積りをもっと多くすることから始める必要がある（p.30〜31）」

正確な見積りの利点 †

• 正確な見積り（過大にも過小にも大きく誤差を生じない見積り）の利点
  • 状況の可視化。予定の進捗が不正確であれば計画と実績の比較が無意味になる。
  • 品質の向上。「正確な見積りは、スケジュールのストレスによる品質問題の回避に役立つ。ソフトウェアのエラーの約40%はストレスによって引き起こされることがわかっている。(中略)（Glass 1994）（p.31）」。「スケジュールが極端に切迫している場合、そこでリリースされたソフトウェアは、切迫していない状況で開発されたソフトウェアに比べて、約4倍もの欠陥が報告されている（Jones 1994）（p.31）」
  • 他部門との連携改善。「もしソフトウェアプロジェクトが作るスケジュールが信頼できないものだと、関連する業務を悪化させる可能性があり、それはプロジェクト全体のスケジュールを悪化させる可能性につながる。（p.32）」
  • 予算が正確になり、予測性が向上する
  • 開発チームの信頼向上。チームが正確な見積りを主張し、計画を達成することで組織内でのチームの信頼が向上する。
  • 早期のリスク情報の取得。本には大きな展示会があるから4ヶ月で仕上げろというスポンサーと、最良の見積りでは6ヶ月かかるというプロジェクトリーダーが、見積り交渉の果てにチームが4ヶ月でスケジュールを達成するコミットメントをさせられる例が載っている。これを受けて筆者「残念！とんだ的外れだ！プロジェクトのゴールとプロジェクトの見積りとの間にミスマッチが発覚したら、それは、きわめて有益で得がたいプロジェクトの早期のリスク情報であると解釈しなくてはならない。(中略) 早期に検出できれば、多くの修正アクションが可能であり、そのほとんどは高い効果がある。（p.32）」具体的にはプロジェクトスコープの再定義、スタッフ増員・変更、開発機能の調整、プロジェクトそのものの実施有無の判断などが可能。

予測可能性の価値 †

• ビジネスでは多くの場合、開発期間、コスト、柔軟性（機能、品質）よりも予測可能性が重視される
  • 「経営陣との議論の中で、私は頻繁にたずねる。「あなたにとってより重要なのはどちらですか。機能に対する方針を変えることですか。それともコスト、スケジュール、機能を事前に知ることですか？」すると、10回のうち少なくとも8回は、「コスト、スケジュール、機能を事前に知ることだ」という答えが返ってくる。これは言い換えると、予測可能性だ。（p.33）」
  • 「4ヶ月、ただし+-1ヶ月の誤差あり」と「5ヶ月、ただし、+-一週間」とでは後者が選ばれる

3章の感想 †

• 過大見積りの不利益は非線形、過小見積りの不利益は線形であるため、過大見積りの方が「まし」というのはなるほどと思った。コンペの場合など、見積りを下げるバイアスがどうしてもかかる状況があるが、この場合でも見積りを下げるのではなく、スコープ再定義やチーム編成、機能選択等を行って調整するべきということ。

• 正確な見積りはプロジェクトコントロールの肝なんだなぁ。当たり前といえば当たり前だけど。1章で述べられていた、見積り、ターゲット、コミットメントの識別が非常に重要ってことだ。見積りはあくまで正確性を尊ばなければならない

• 予測可能性が最も重要というのは連携すべき業務や計画があることを考慮すれば納得のいく話。早けりゃいいってものじゃない。しかし、見積りや計画作成時には忘れがち。要注意。予測可能性を高めるというのは、コミットメントの達成率を上げる、約束を守るということだから、信頼で成り立つビジネスでは死活的に重要。その意味で、正確な見積りを尊ばない企業文化は信頼のできない企業文化ともいえる。

関連コンテンツ †

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

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

|

Menu

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

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

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

Tag

最新の20件

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