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

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

ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（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ヶ月でスケジュールを達成するコミットメントをさせられる例が載っている。

3章の感想 †

関連コンテンツ †