ソフトウエア見積もり
「ソフトウエア見積もり」−人月の暗黙知を解き明かす
Software Estimation:Demystifying the Black Art
Steve McConnell
田沢 恵、溝口 真理子 訳
久手堅 憲之 監修
日経BPソフトプレス(2006)
★★★★★
Don't reduce developer estimates
--they're probably too optimistic already.
McConnellの最新作。ソフトウェア関係者の必読書であると思います。さまざまな手法、考え方の集大成ですから、これ1冊読めば、見積もりは、ほぼ完璧です。勘と経験と度胸から決別する最初の1歩でしょう。米国の業界標準のデータも貴重です。これからの見積りが劇的に変わりそうです。
ポイント20：開発者の見積もりを削ってはいけない。なぜなら、既に十分楽観的すぎるからだ。
第1章 見積りとは
ポイント1：「見積り」「ターゲット」「コミットメント」はそれぞれ異なるものであると認識しよう。
ポイント2：見積りを求められたときは、実際に見積もりを行うのか、ターゲットの達成方法を尋ねられているのかを判断すること。
見積りにとって重要なことは。完璧なまでに正確であることより、有用な情報を提供することである。
第7章 数えて、計算して、判断する
ポイント30：できるときはいつでも、まず数えよう。数えられないときには、計算しよう。判断だけに頼るのは最後の手段だ。
第8章 補正と過去のデータ
ポイント36：「うちのチームは平均以下かどうか」という前提から議論するような政治的圧力のかかった見積りを避けるために、過去のデータを使用しよう。
ポイント37：見積りに使用する過去のデータを収集するときは、小さな規模で始め、自分が何を収集しているのか理解して、一貫性を持ってデータを収集しよう。
ポイント38：プロジェクトが終わったら、できるだけ早くプロジェクトの過去のデータを収集しよう。
ポイント41：できるだけプロジェクトのデータまたは過去のデータを使用して、見積もりを補正しよう。できれば業界平均データは避けよう。過去のデータを使用して補正すると、より正確な見積もりができるだけでなく、生産性に関する前提の不確実性から生じる見積りのばらつきを減らすことができる。
第9章 専門家の判断
ポイント43：タスクレベルの見積もりは、実際に作業に携わる者が見積りを作成しよう。
タスクレベルの見積もりを行うときは、長くても2日程度の工数のタスクにまで見積もりを分解する。それより大きいタスクだと、想定外の作業が隠れる場所が多すぎる。見積もりは4分の1日、2分の1日、丸1日といった粒度で行うとよい。
ポイント44：最良ケースと最悪ケースの見積もりを作成して、起こり得るすべての範囲の結果について考えるきっかけにしよう。
ポイント45：見積りのチェックリストを使用して、個々の見積もりを改善しよう。自分の個人的なチェックリストを開発して保持し、自分の見積もりの正確性を改善しよう。
ポイント46：実績を見積もりと比較して、時間とともに個々の見積もりを改善できるようにしよう。
第10章 分解して、また組み立てる
ポイント47：大きな見積もりを小さい部分に分解して、「大数の法則」の恩恵にあずかろう。プラスの誤差とマイナスの誤差は、ある程度まで互いに打ち消しあう。
ときどき、「忘れ去られた機能」という形で、目に見えない作業が隠れていることがある。「忘れ去られたタスク」という形で隠れていることもある。タスクを忘れないようにするには、活動基準WBSを使用するとよい。見積もり対象のプロジェクトと似たような過去のプロジェクトを比較して、大きいか小さいかを考える時の微調整にも役立つ。新しいプロジェクトと過去のプロジェクトをWBSのカテゴリごとに比較すると、どの部分が大きくてどの部分が小さいかを細かく評価できる。
ポイント49：タスクが10個以下の見積もりの場合、最良ケースと最悪ケースから意味のある総見積りを計算するには、簡単な標準偏差の公式を使用しよう。
ポイント51：個々のタスク見積りに使う標準偏差を得る時には、最良ケースから最悪ケースまでの範囲を6で割ってはならない。見積もりの範囲の正確性に応じて、除数を選択しよう。
ポイント52：期待ケースの見積もりを正確にしよう。個々の見積もりが正確ならば、そこから得た値は問題を起こさない。個々の見積もりが正確でなければ、正確に求める方法が見つかるまで、そこから得た値には多くの問題がある。
第11章 類推見積り
ポイント53：新しいプロジェクトを見積もるときは、過去の似たようなプロジェクトと比較して、できれば5つ以上の部分に分解して見積もろう。
見積りの焦点は、正確さに合わせるべきで、慎重な保守主義をとればよいというものではない。見積もりの焦点がいったん正確さから離れると、さまざまな原因から先入観が混入し、見積もりの価値を下げてしまう。不確実性に最もうまく対処するためには、見積もりから先入観を排除することだ。それと同時に、根底にある不確実性を正確に表現することも必要だ。
第12章 代替指標による見積り
ポイント59：Tシャツのサイズ分けを使用すると、プロジェクトが「不確実性のコーン」の広い部分にある間、非技術系のステークホルダーが要求機能を線引きして取捨選択するのに役立つ。
第13章 専門家グループによる判断
ポイント62：グループレビューを行うと、見積もりの正確さを改善できる。
ポイント63：プロジェクトの初期の見積もりをするとき、あるいは馴染みのないシステムを見積もるとき、またはプロジェクトそのものにさまざまな分野がかかわるときは、広域デルファイ法を使用しよう。
第14章 ソフトウェア見積もりツール
ポイント64：見積りツールを使用して、手作業で作成された見積もりが正しいかどうかチェックしよう。大規模なプロジェクトほど、市販の見積もりツールを活用すべきである。
ポイント65：ソフトウェア見積もりツールの出力結果を神の信託のように扱ってはならない。見積もりツールのアウトプットも、他の見積もりと同じように、正しさをチェックしよう。
第15章 複数の見積もりの使用
ポイント66：複数の見積もり技法を使用して、それらの結果が集中しているか分散しているかを調べよう。
ポイント67：異なる見積もり技法によって別々の結果が生じるときは、その結果が生じる原因を探してみよう。異なる技法から生じる結果の差が5%以内に集中するまで、再見積りしよう。
ポイント68：複数の見積もりが一致したのに、ビジネスターゲットが一致しなかった場合は、見積もりの方を信頼しよう。
第16章 うまくいく見積りのフロー
ポイント69：見積りのアウトプットについて議論してはいけない。アウトプットはそのまま受け入れよう。アウトプットを変更してよいのは、インプットに変更があったときか、または再計算した場合だけである。
ポイント70：まず、規模の見積もりに焦点を合わせよう。次に、工数、スケジュール、コスト、機能を、規模の見積もりから計算しよう。
ポイント72：プロジェクトの進行に従って、それほど正確でない見積もりアプローチから、より正確な見積もりアプローチへと移行しよう。
ポイント73：具体的な開発タスクを配分して割り当てる準備ができしだい、ボトムアップ見積りに切り替えよう。
ポイント74：デッドラインを達成できなくて再見積りするときには、プロジェクトの進行計画ではなく、実際の進行に基づいて、新しい見積もりを作成しよう。
ポイント75：プロジェクトの進行につれて見積り幅が狭くなるような方法で、見積もりを提示しよう。
ポイント76：プロジェクトのステークホルダーには、前もって再見積りの計画を伝えよう。
第17章 標準化された見積もり手順
ポイント79：プロジェクトの見積もりと見積もりプロセスをレビューしよう。それによって、見積もりの正確性が改善され、見積もりを作成するために必要な工数が最小化される。
第18章 規模の見積もりの課題
ポイント80：規模を見積もるために、コード行を使おう。ただし、簡単な指標が持つ一般的な制限と、コード行特有のハザード（危険性）を忘れてはいけない。
ポイント81：ファンクションポイントを数えて、プロジェクトの初期に正確な規模の見積もりを手に入れよう。
ポイント84：適正な見積もり技法を使えば、規模の見積もりは他の見積もりの基礎となる。構築中のシステムの規模は、単体として最も大きなコストドライバである。正確に規模を見積もるためには、複数の見積もり技法を使おう。
第19章 工数の見積りの課題
ポイント85：規模の見積りから工数の見積りを正確に換算するために、見積りのサイエンスに基づくソフトウェアツールを使おう。
ポイント86：業界平均の工数グラフを使って、「不確実性のコーン」の広い部分で、大まかな工数の見積りを手に入れよう。プロジェクトが大規模なほど、強力な見積もり技法へ投資する正当性が容易に証明されることを覚えておこう。
ポイント88：すべての見積り技法が等しい結果を出すとは限らない。見積り間の集中と分散を調べる場合は、もっとも正確な結果を作り出す技法の結果を重視しよう。
第20章 スケジュールの見積りの課題
ポイント90：過去のプロジェクトと非公式に比較する公式をつかって、小〜大規模プロジェクトのスケジュールを早い時期に見積もろう。
ポイント93：スケジュールの見込値を25％以上短くしてはならない。すなわち、見積もりを不可能ゾーンに入れてはならない。
ポイント94：スケジュールを長くして、小さなチームでプロジェクトを実行して、コストを減らそう。
ポイント95：中規模の業務システムプロジェクト（35,000〜10万LOC）では、チームの人数が7人を超えてはならない。
ポイント97：見積り間の集中や分散を調べる前に、過度に一般的な見積もり技法の結果をデータセットから取り除くこと。
第21章 計画パラメータの見積り
計画パラメータの見積りは、あくまでも見積りである。つまり、粒度を細かくしたターゲットの設定と、粒度を細かくした見積りとが強く相互作用しながら、何度も繰り返されるべきものである。この段階における見積りのゴールは、初期の計画が現実的であることを確かめることであり、そこから先は、見積もりよりも、計画とプロジェクトコントロールが優先するはずだ。
最終的に、開発者とテスト担当者の構成比は、見積もりよりも計画によって安定する。つまり、あなたが「そうなるだろう」と予測することよりも、「そうあるべきである」と思っていることによって決まる。
「信頼性を95%から99%に向上させたいなら、スケジュールの本体に25%を加えるべきである。」「信頼性を99%から99.9%に改善したいなら、スケジュールにもう25%を加えるべきである。」
ポイント102：バッファ計画の出発点として、顕在化したリスク（RE)の合計を使おう。プロジェクトの具体的なリスクの詳細を見直したうえで、REの合計よりも大きなバッファを計画すべきか、小さなバッファを計画すべきかを最終的に判断しよう。
事務サポートの工数として、ベースとなる見積もり工数に5〜10%を加える。
ITサポート（ラボのセットアップ、新しいソフトウェアのインストールなど）の工数として、ベースとなる見積もり工数に2〜4%を加える。
構成管理と構築のサポートには、ベースとなる見積もり工数に2〜8%を加える。
月あたり1〜4%の要求の増加を想定する。
新しい言語およびツールを使った初めての開発を行う場合は、精通した言語およびツールで同程度の開発を行う場合に比べて、20〜40%の工数増加を想定する。
新しい環境で初めての開発を行う場合は、精通した環境で同程度の開発を行う場合に比べて、20〜40%の工数増加を想定する。
第22章 見積りのプレゼンテーション
ポイント104：見積りに組み込まれた前提条件は、文書化して伝えよう。
ポイント106：ごくわずかな可能性しかないプロジェクトの見積りなら、プロジェクトのステークホルダーには提示しない。
第23章 政治、交渉、問題解決
ポイント112：コミットメントは交渉できるが、見積もりを交渉の対象にしてはならない。
ポイント114：見積りの議論を、「交渉」ではなく、「問題解決」としてとらえよう。プロジェクトのステークホルダーたちは、全員がテーブルの同じ側にいる。全員が勝つか、全員が負けるかどちらかだ。
