![[PukiWiki]](image/sandbox.gif "[PukiWiki]")
ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（3） http://www.ark-web.jp/sandbox/wiki/3025.html
ソフトウェア見積り−人月の暗黙知を解き明かす−読書メモ（3）
- 4章 見積り誤差はなぜ起きる？
- 見積りの不確実性の原因、不確実性のコーン（見積りプロジェクト自身に関する不正確な情報）
- 混乱した開発プロセス（プロジェクトを遂行する組織の能力に関する不正確な情報、正確な見積りをサポートするプロジェクト内の過剰な混乱）
- 不安定な要求（正確な見積りをサポートするプロジェクト内の過剰な混乱）
- アクティビティの見落とし（見積りプロセス自体から発生する不正確さ）
- 根拠のない楽観主義（見積りプロセス自体から発生する不正確さ）
- 主観と偏見（見積りプロセス自体から発生する不正確さ）
- 即興の見積り（見積りプロセス自体から発生する不正確さ）
- 保証されない精度（見積りプロセス自体から発生する不正確さ）
- 見積り誤差のその他の原因（見積りプロセス自体から発生する不正確さ）
- 4章の感想
- 関連コンテンツ
ソフトウェア見積り―人月の暗黙知を解き明かす
http://www.amazon.co.jp/dp/489100522X/miqqle-000-22/ref=nosim
の読書メモを記していきます。
※ 引用内の強調は筆者（進地）による。
※ 引用内の中略は（中略）で示す。
4章 見積り誤差はなぜ起きる？ †
見積り誤差を引き起こす原因は、一般的に４つある。 ■ 見積りプロジェクト自身に関する不正確な情報 ■ プロジェクトを遂行する組織の能力に関する不正確な情報 ■ 正確な見積りをサポートするプロジェクト内の過剰な混乱（つまり、移動するターゲットを見積もろうとすること） ■ 見積りプロセス自体から発生する不正確さ （p.38）
見積りの不確実性の原因、不確実性のコーン（見積りプロジェクト自身に関する不正確な情報） †
- 「それぞれに具体的な機能が詳細に理解できるまでは、ソフトウェアプロジェクトのコストを正確に見積ることは困難だ。「何か」が定義されていないのに、その何かを構築するために必要な作業量を見積ることはできない。(p.38）」
- 機能単位の見積りは、その機能の詳細、採用される設計とその複雑さ、実装方法・実装者のスキル、要求される品質レベル、担当者のデバッグスキル等で各々に10倍近い差が生じるため、累計して100倍以上の違いになって表れることもある。ソフトウェアプロジェクト全体においては、さらに要求の揺れがあり、各要求に複数の機能が含まれるわけなので、重大な不確実性に見舞われることになる。
- 「不確実性のコーン（円錐）」は、プロジェクトが進行するにつれて、見積りがどのように正確になっていくかを示している（p.39-40）」
- 不確実性のコーンはプロジェクトの初期コンセプトの策定から、製品定義の承認、要求の官僚、ユーザーインタフェイス設計の完了、詳細設計の完了、ソフトウェアの完了といったプロジェクトの意思決定が進行していくにしたがって、プロジェクトのスコープ（工数、コスト、機能）の見積りにおけるばらつきが収束していく様を示した図。（下図はイメージ）
4x ----
2x ---------
1.5x ----------
1.25x --------------
1.0x ----------
0.8x ---------------------
0.5x --------
0.25x --------
===============================================================
初期 製品定義 要求完了 ・・・ ソフトウェアの完了
x= ソフトウェア完了時の見積り（実績）
- 一般にプロジェクト初期に作成した見積りは多く見積った場合(上図の4x）と少なく見積った場合（上図の0.25x）で10倍以上もの差が生じる
- 「「見積り作業にもう１週間かけたら、不確実性を少なくするように詳細化できますか？」と、マネージャや顧客はよくたずねる。これは妥当な要望である。しかし残念なことに、この要望をかなえることは不可能だ。Luiz Laranjeiraの研究によると、ソフトウェア見積りの正確性は、ソフトウェア定義の詳細化レベルに依存する（Laranjeira 1990）。その定義が詳細化するほど、見積りはより正確になる（p.40-41）」
- 不確実性のコーンはプロジェクトのさまざまな時点における最良の正確な見積りを表現している。熟練した見積り作成者によって得られる最大の見積りのゆれが不確実性のコーンに表現されている。これより幅が悪く（広く）なることは無限に生じえるが、狭くすることは不可能。
- 不確実性のコーンの広がりはプロジェクト自体のばらつきの存在によって生じている。したがって、プロジェクト自体のばらつきを減らす（詳細化を進める）ことをしない限り、コーンは収束せず、プロジェクトも収束しない。この場合、不確実性のコーンは不確実性の雲になってしまうことがある（終盤になっても不確実性が収束しない様）。
- 「問題は見積りが収束しないことではない。プロジェクト自体が収束しないことなのだ。（p.43）」
- 不確実性のコーンは意思決定によってのみ収束する。ひとりでには決して収束しない。
- 不確実性のコーンを見積りに組み入れる方法
- 「最もありそうな（最有力な）」見積りでスタートして、その後、事前に定義された係数をかけて範囲を計算する方法。例えば、初期コンセプト時では不確実性のコーンより、少ない側の誤差は0.25x（-75%）、多い側の誤差は4.0x(+300%）とすれば、それぞれの係数を最有力値にかけて範囲を導出する。※ 0.25x、4.0xは組織や開発対象のソフトウェアによっても異なることに注意。
- 「いくらかかるかを知る」という見積りと、「いかに不確実かを知る」という見積りは異なるスキルであるという知見に基づき、「一人に範囲の最良ケースと最悪ケースを見積ってもらい、別の人には実際の結果がその範囲内に入るかどうかを見積ってもらう（p.44）」方法。
- 不確実性のコーンとコミットメント
- 「効率的な組織では、コーンを狭くする作業を終えるまでコミットメントを遅らせる。有意義なコミットメントは、プロジェクトの前半（進路のおよそ30%）で行うことが可能であり、適切である。（p.45）」
- 反復型開発プロセスを用いることで、各反復で不確実性のコーンがミニチュア化されるため、各反復のスタートから2〜3日でその反復の範囲においては不確実性が4xのばらつきから1.6xのばらつき等に減らすことができる。
- ただし、次のデメリットもある。「各反復の開始まで要求を定義しないでおく、というアプローチをしたときに諦めなければならないことは、長期の予測可能性である。（p.45）」プロジェクトが柔軟性に高い優先順位を与えるか、予測可能性に高い優先順位を与えるかによって反復プロセスの採用の良し悪しが決まる。
- 「完全な反復に代わる方法は反復しないことではなく、より少ない反復か、別の反復だ。反復しない方法は、ほとんど例外なく効果がないことがわかっている。多くの開発チームは、プロジェクトの初期に大部分の要求を定義して、設計・構築・テスト・リリースは短い反復で実行するという折衷案に落ち着く。言い換えると、プロジェクトはユーザーインタフェイス設計の完了というマイルストーン（プロジェクトのカレンダー時間のおよそ30%）まではシーケンシャルに進行し、そこから先は、反復型のアプローチにシフトすることになる。これは、コーンから発生するばらつきを約±25%まで抑えてから、反復型開発の主な利点を活用してターゲットに到達できる、十分優れたプロジェクトコントロールの方法だ（p.45）」
混乱した開発プロセス（プロジェクトを遂行する組織の能力に関する不正確な情報、正確な見積りをサポートするプロジェクト内の過剰な混乱） †
- 適正に運営されているプロジェクトでさえ、不確実性のコーンが示す不確実性にさらされている。混乱を抱えるプロジェクトではさらに多くの不確実性が生ずる。混乱の一般的な原因は次の通り。
■ 当初からあまりよく調査されなかった要求 ■ 要求検証におけるエンドユーザーの関与不足 ■ 多数のコードエラーの原因となる下手な設計 ■ 多数のバグ修正を生じさせる下手なコーディングプラクティス ■ 経験不足の要員 ■ 不完全あるいは未熟なプロジェクト計画 ■ 発言力の強すぎるチームメンバーの存在 ■ プレッシャーによる計画の断念 ■ 開発者によるゴールドプレーティング ■ 自動化されていないソースコード管理 （p.46） ※ ゴールドプレーティングは開発者が仕様にはないのに、ユーザが喜びそうな機能、または開発者の趣味を入れてしまうこと。
- 「良い見積りプラクティスを行えば、混乱したプロジェクトを正確に見積もれると思ってはいけない。コントロール不能なプロセスを正確に見積ることは不可能だ。先に混乱を修復する方が、見積りを改善するより重要だ（p.46）」
不安定な要求（正確な見積りをサポートするプロジェクト内の過剰な混乱） †
- 要求変更は二つの明確な見積りの課題を突き付ける。
- 要求が安定しない場合、不確実性のコーンは狭くならないため、見積りのばらつきはプロジェクトの最後まで大きいままになる。
- 「要求変更は追跡（トラッキング）されないことが多く、プロジェクトが再見積りされるべきなのに、それがしばしばなされないということだ（p.47）」
- これらの課題への対策は、「プロジェクトコントロールによる対処の方が、見積りによる対処よりも強力に働く（p.47）」
- もし、要求を安定させることが許されない状況なら、きわめて要求が変わりやすい状況で作業するように設計された開発手法を考えるべき。短い反復型、スクラム、XP、DSDM（Dynamic System Development Method）、タイムボックス開発など。
アクティビティの見落とし（見積りプロセス自体から発生する不正確さ） †
- [見積り誤差の最も一般的な原因の１つは、プロジェクトの見積りに必要な作業を入れ忘れることだ（Lederer and Prasad 1992, Coombs 2003）。（中略）ある調査によると、開発者は忘れずに見積りをした作業についてはかなり正確に見積るが、一方で、必要な作業の20〜30%を見落とす傾向にあるという。それが20〜30%の見積り誤差をもたらすことになる（van Genuchten 1991）(p.48)」
- 見落としには「要求の見落とし」、「ソフトウェア開発アクティビティの見落とし」、「ソフトウェア開発アクティビティ以外の見落とし」の３つがある。
- 「要求の見落とし」では特に非機能要求を見落としやすい
- 非機能要求＝正確性、性能、移植性、再利用性、拡張性、セキュリティ、ユーザビリティなど
- 機能要求でもセットアップ/インストールやヘルプシステム、データ変換ユーティリティ、エラー処理（異常系処理）などは見落としやすい
- 「見積りの中には、提示された要求だけでなく、暗黙に示されている要求や非機能要求、つまりすべての要求を含めなくてはいけない。ただで構築できるものは何もない。したがって見積りは、暗にそれができるというような書き方をしてはいけない。（p.49）」
- 「ソフトウェアの開発アクティビティの見落とし」で見落としやすいアクティビティがp.50に一覧されている
- 以下、筆者による一部抜粋。一部文言はオリジナルままではなく改変している。
- 新しいチームメンバーの立ち上げに必要な起動時間
- マネジメントとの調整/マネージャミーティング
- カットオーバー/配置
- 要求の明確化
- リビジョン管理システムの保守
- テストデータの作成
- レビュー
- 統合作業
- 変更要求の管理、調整、優先度決定のMtg
- プロジェクト期間中の前システム（既存システム含む）のサポート、メンテナンス
- 欠陥修正作業（デバッグ作業）
- 新しい開発ツールの学習
- ユーザードキュメントの作成とレビュー
- 顧客やユーザーに対するソフトウェアのデモ。展示会でのデモ。
- 計画、見積り、アーキテクチャ、詳細設計、段階計画、コード、テストケースのレビュー
- 以下、筆者による一部抜粋。一部文言はオリジナルままではなく改変している。
- 「ソフトウェア開発アクティビティ以外の見落とし」で見落としやすいものがp.51に一覧されている。
- 以下、筆者による一部抜粋。一部文言はオリジナルままではなく改変している。
- 休暇
- 祝日
- 病欠
- トレーニング（セミナーやイベント参加など）
- 週末
- 全社ミーティング
- 部署ミーティング
- 環境セットアップ（新しいパソコンのセットアップ、ツールのインストールなど）
- ハードウェアやネットワークのトラブルシューティング
- 以下、筆者による一部抜粋。一部文言はオリジナルままではなく改変している。
- この他にも、他プロジェクトの干渉（影響）や割り込みもあると思う
- 「数週間以上に及ぶプロジェクトでは、休暇、病欠、トレーニング、会社のミーティングなど、間接アクティビティのためのゆとりを持たせよう（p.51）」
根拠のない楽観主義（見積りプロセス自体から発生する不正確さ） †
- 「Microsoftの副社長Chris Petersは、プロジェクトの開発者側から次のように観察している。「開発者によって作られる見積りが悲観的になるのではないかと恐れる必要はない。なぜなら開発者は、常に楽観的すぎるスケジュールを生み出すものだからだ」（Cusumano and Selby 1995）。（p.51）」
- 「プロジェクトマネージャと経営陣は、30%も早くかつ安くプロジェクトが実現されることをたとえ想定していないとしても、より早くかつより安く実現されることを確実に望んでいるものだ。そしてそれこそが、一種の楽観主義なのだ。（p.52）」
- 取り上げられている楽観主義のバリエーション
- 前のプロジェクトよりも今回のプロジェクトの方が生産性が高いだろう
- 前のプロジェクトでは色々問題があったが、今回はそれほどの問題は起きないだろう
- 前のプロジェクトで得た教訓があり、慣れてきているのだからずっと早くプロジェクトを終わらせられるだろう
- 取り上げられている楽観主義のバリエーション
- 楽観主義の結託
- 「開発者は楽観的な見積りを提示する。経営陣は楽観的な見積りを好む。なぜならその見積りは、望ましいビジネスターゲットを達成できると言っているからだ。マネージャもその見積りを好む。なぜならそれは、経営上層部の目標をサポートできると言っているからだ。このようにして、ソフトウェアプロジェクトは、見積りが最初に十分な根拠に基づいていたかどうかについて誰も批判することなく、本格的に動き出す。（p.52）」
主観と偏見（見積りプロセス自体から発生する不正確さ） †
- 「顧客やマネージャが見積りとビジネスターゲットの不一致に気付いた場合、見積りやプロジェクトやプロジェクトチームに対してプレッシャーをかけることがある。スケジュールへの過度なプレッシャーは、巨大プロジェクトの75〜100%で発生している（Jones 1994）（p.52）」
- このような強いプレッシャーが発生している状況下で、見積りのコントロールノブ（＝微調整をする箇所）が多いほど、主観の紛れ込む機会が多くなり、見積りは不正確になる。
- 著者は17の工数乗数と5つのスケーリング係数を含むCOCOM�狂�積りモデルを取り上げ述べている「理論的には、これら22のコントロールノブによって、実質的にどのような見積りにも細かく合わせることができるはずだ。しかし実際には、そのコントロールノブは、見積りに誤差を紛れ込ませる22の機会をもたらしているようなものだった（p.53）」
- 17のコントロールノブを使った約100の見積りグループの誤差は1.7倍、しかし、コントロールノブ（主観的判断を入れる箇所）が一つだけにしたケースでは誤差が1.1倍に収まった。
- 「コントロールノブの多いことが良いことではない」という発見は、ソフトウェアの見積りという枠を超えて広がっている。（中略）「予測の研究からわかった最も永続的で役に立つ結論の一つは、一般に、簡単な手法は複雑な手法と同じくらい正確だということだ」（Armstrong 2001）（p.54）」
即興の見積り（見積りプロセス自体から発生する不正確さ） †
- 「最も安全な方策は、即興の見積りはしないことだ。ソフトウェアプロジェクトの見積りにおける直感と推測は、どちらもコストとスケジュール超過に関係する（中略）（Lederer and Prasad 1992）（p.55）」
- 即興の見積りの平均には、67%の平均相対誤差（MMRE=[（実際の結果 - 見積り結果） / 実際の結果 ]の絶対値）を持ち、これに対してレビュー済の見積りの平均には30%のMMREしかない。
- 即興の見積りを行うということは個人の記憶（過去にどれだけの時間、工数がかかったか）に頼って見積りをすることに等しい。しかし、「残念ながら、人は過去のプロジェクトの実績よりも、過去のプロジェクトの見積りを覚えているもの（p.56）」なので、今回の見積りの根拠に使う過去のプロジェクトの見積りが実績と大きく食い違っていた場合、既にして今回の見積りも正確性を甚だしく失っているということになる
- 「LeadererとPrasadは、直感と推測が、明らかにプロジェクトの超過と関係していることを発見する一方で、「記録された事実」の使用はプロジェクトの超過と負の関係があることを発見した。言い換えると、上司に即興の回答をすることと、「あまり考えずに答えることはできません。机に戻り、2〜3のメモをチェックさせてくだされば、15分で戻ってきます。それで大丈夫ですか？」と言うことには、天と地ほどの開きがあるということだ（Lederer and Prasad 1992, Jorgensen 1997, Kitchenham et al. 2002）。」
- 「即興の見積りはやめよう。たった15分の見積りでさえ、もっと正確だ（p.57）」
保証されない精度（見積りプロセス自体から発生する不正確さ） †
- 正確性と精度とは異なるもの
- 正確性は、ある数字が実際の値にどれだけ近いかを表す
- 精度は、単にある数字がどれだけ精密かを表している
- 例）3という数字は円周率πの有効数字一桁の正確な表現だが、精密ではない。3.37882は、3よりも精密なπの表現だが、もはや正確ではない。
- 「ソフトウェア見積りでは、正確性と精度を区別することが重要（p.58）」。精度はこの場合有効数字の桁数を示す。
- 「たとえば395.7日という見積りを提示すると、ステークホルダーたちは見積りが有効数字4桁まで正確だと見なす。395.7日よりも１年、４クォーター（四半期）、１３ヶ月などと見積る方が、正確性がよく反映されているかもしれないのだが、１年ではなく395.7日という見積りを使うことは、πを3.337882と表すようなものである。数字はより精密だが、実際あまり正確ではない（p.58）」
- 見積りの精度（有効桁数）を見積りの正確性と一致させるべき
見積り誤差のその他の原因（見積りプロセス自体から発生する不正確さ） †
- 本書で取り上げられているもの（p.58〜p.59）から筆者が気になったものだけいくつか取り上げる
- 未経験の技術分野
- 見積り時間からプロジェクト時間への不正確な換算（たとえば、プロジェクトチームが１日８時間、週５日はプロジェクトに集中するとみなすこと）
- 統計的概念の考え違い（特に、「最良ケース」の見積りや「最悪ケース」の見積りを合算すること）
- 規模と工数の正確な見積りを行いながら、それらをスケジュールの見積りに換算するときに紛れ込む誤差
- 見積りが経営層に報告されて予算プロセスに送り込まれるにつれて起こる、見積りの簡略化
4章の感想 †
- 「不確実性のコーン」という概念は有用だと思った。「不確実性のコーン」はプロジェクトの各段階においてこれ以上は正確性の幅が縮まることはないことを示すもので、正確性をあげるためには見積り技術の向上云々ではなく、意思決定を進めてソフトウェア定義の詳細化レベルをあげていくしかない。
- 「不確実性のコーン」を考慮すると、プロジェクトの前半（プロジェクトのカレンダー時間のおよそ30%）まではコミットメントを避け、かつ、そこまではシーケンシャルに進行させ（この段階でコーンから発生するばらつきを約±25%まで抑える）、そこから先は反復型のアプローチにシフトして、さらにコーンをミニチュア化して進めて不確実性をさらに収束させて進めていくのが一つの優れた方法と考えられる。特に、一般に高い予測可能性よりも、プロジェクトの柔軟性の方に高い優先順位を与える傾向にあるWeb制作のプロジェクトではこの手法がマッチするように思った。
- 「不確実性のコーン」が自組織ではどのような区切りでどのように収束していくかを調べるのが重要。
- 混乱した開発プロセスでは正確に見積れるわけがないというのは深く同意。まず混乱を収めることが大事。もう一つここで重要だなと思ったのは見積りの正確性は見積り技術だけで保証されるものではなく、プロジェクトコントロールとの両輪で進める必要があるということ。
- 見積りプロセス自体から発生する不正確さ（アクティビティの見落とし、根拠のない楽観主義、主観と偏見、保証されない精度、その他）は組織内で知識として共有、文化を醸成するとともに、ワークフロー化することでこうした不正確さに見舞われるリスクを減らすのが適切なのだろうと思った。特に見落としはワークフロー化しておくことで確実に防いでいけると思う。また、人間の弱さ（楽観主義や主観、偏見など）に抗するにもフローが決まっていることが大きな力になるように思う。
- 即興の見積りは絶対にやめるべし！！でも、そのためには過去の記録（実績）をとっておくことが非常に大事。
関連コンテンツ †
Menu
Movable Type用プラグイン Aシリーズ
ECサイト構築 Zen Cartハイエンド
Tag
A-Form
Ajax
CPAN
EC2
FastCGI
FlashLite
Flex
Google
Google Calendar
GoogleMaps
GoogleMapsAPIforFlash
Graph
JSON
JSONP
Jamal
JavaScript
MT
MTPlugin
MTテンプレート
MVCフレームワーク
Maple
Movable Type
MySQL
OpenSocial
PHP
Perl
Plugin
PukiWiki
RIA
RightFields
Ruby
Ruby on Rails
Skype
Spam
Twitter
Web2.0
WebAPI
gettext
prototype.js
script.aclo.us
selenium
trac
エクスペリエンス
オープンソース
スクレイピング
セキュリティ
ツール
テスト
ネットワーク
勉強会
最新の20件
2017-05-12
2014-04-30
2013-09-16
2013-02-21
2012-09-04
2012-04-03
2012-02-29
2012-02-06
2012-01-19
2011-12-19
2011-11-13
2011-08-08
2011-07-07
2011-02-17
2010-12-02
2010-11-04
2010-09-16
ARK-Webビジネスブログの最新記事
2014-01-08
2014-01-07
2014-01-06
2013-12-13
2013-12-11
2013-11-29
2013-11-28
2013-11-26
2013-11-19
2013-10-28
2013-10-18
2013-10-15
2013-10-11
2013-09-26
2013-09-24
