この素晴らしい本の内容を忘れてはいけない。
そういう強い思いから、ここに自分が特に覚えておきたいと思う、ソフトウェア見積もり技術の要点を書き記す。
■見積もり、ターゲット、コミットメント
○ 見積もり
ソフトウェアプロジェクトにかかる以下を予測することである。
- コスト
- 期間
○ ターゲット
ビジネス上の目標である。
（例）
- ○○日までにこの機能を完成させたい
- ××円以内のコストで次期バージョンをリリースしたい
○ コミットメント
以下についての約束。
- 機能
- 納品日
- 品質
■見積もりと計画の違い
○ 見積もり
作成するソフトウェアの規模に応じて決まってくる必要人員、必要日数のこと。目的の機能をリリースするために必要なコストを知るために行う。
○ 計画
ターゲットを達成するためのプロセスのこと。見積もりで出したコストが高過ぎる場合に重要度の低い機能を削ったり、見積もったスケジュールで納品が間に合わない場合に最小限の機能で一次リリースを行い、重要度の低い機能を二次リリースに回したりする。見積もり情報を参照しながら、適切な計画を立てる。
■見積もりには幅を持たせよ
この機能は14日間で完成する見込み、というようなシングルポイントの見積もりをしてはいけない。この機能は12日間～16日間で完成する見込み、と言う風に見積もりに幅を持たせること。
- シングルポイントの見積もり：14日間で完成
- 幅のある見積もり：12日間～16日間で完成
■良い見積もりの指標
『ソフトウェア見積もり』からそのまま引用する。
良い見積りのアプローチとは、実績値の75%のケースで誤差が25%以内に収まる見積りを提供することである（Conte、Dunsmore、Shen1986）。
ここで書かれている誤差25%とは、見積もったスケジュールの全期間を100%と見たときの値である。例えば、見積もり10日間のプロジェクトがあったとすると以下である。
8日間で完成：-20%の誤差
13日間で完成：+30%の誤差
つまり、10日間のプロジェクトなら、7.5日～12.5日の期間でプロジェクトが完了すれば、誤差25%以内に収まったことになる。
> 実績値の75%のケース
こちらは、見積もったプロジェクトが複数あるとして、それら複数のプロジェクトのうち、75%のケースで目標値を達したら、良い見積もりと見做すという意味である。
例えば、見積もったプロジェクトが100件あるとすると、75件で目標値である誤差25%をクリアしている必要がある。
■見積もりの目的
良い見積りとは、プロジェクトの責任者がプロジェクトのターゲットを達成するためのコントロールを行ううえで、適正な意思決定ができる明確な視点を提供する見積りである。(Kindleの位置No.707-708)
見積もりの目的は、プロジェクトマネジメントの基礎となる情報を提供することにあると思う。この情報を元に、計画を立て、人員を割り当て、提供する機能を決定していくことになる。従って、見積もりは正確である必要がある。しかし、それは厳密さを要求するものではなく、上記の目的を達するために有用な程度の正確さがあれば良い。
■プロジェクトコントロールによるリカバリの限界
ビジネス上のターゲットに対して、スケジュールおよびそのターゲット達成に必要な工数のギャップが大きすぎる場合は、問題として認識すべきである。私の経験では、初期ターゲットと初期見積りの差異がおよそ20％以内であれば、プロジェクトマネージャが、仕様項目、スケジュール、チームの人数などのパラメータをやりくりして、プロジェクトのビジネスゴールを達成できる余地がある。(Kindleの位置No.687-691)
つまりターゲットと見積もりに20%以上の差異がある場合、プロジェクトコントロールではリカバリできない。それは「無理な計画」である。
■過少見積もりと過大見積もり
○ 過少見積もりによる悪影響
- プロジェクト計画の有効性が減少する (Kindleの位置No.857)
- 予定どおりに完了する機会が統計的に減少する (Kindleの位置No.867)
- 必要な作業が行えなくなる
（例）要求開発、要件定義、テスト
要するに最低限必要な作業であるコーディング以外の作業をすっ飛ばすために、開発作業の後半で多くの手戻りに襲われたり、リリース後のバグに苦しめられたりすることになる。 - スケジュール遅延による不要な作業が発生する
暫定版のリリースや、顧客への謝罪と打ち合わせ、再スケジュールなど
■見積もりに関する興味深い統計調査結果
・ソフトウェアの見積りは、しばしば100％あるいはそれ以上に不正確であることが、多くの調査でわかっている（Lawlis,Flowe,andThordahl1995;Jones1998;StandishGroup2004;ISBSG2005）。(Kindleの位置No.863-864)
・開発者が作る見積りは、一般に実際の工数よりも20〜30％低くなるものだ（vanGenuchten1991）。(Kindleの位置No.868)
・Standishグループは「カオスレポート（TheChaosReport）」と呼ばれる2年ごとの調査を発行している。これは、ソフトウェアプロジェクトの実績を記述したものだ。2004年のレポートによると、プロジェクトの54％が遅れ、18％が完全に失敗し、当初の予定期間と予算内で開発されたのは28%とされている。（中略）Standishグループのデータで注目すべきなのは、「早く終わったプロジェクト」については、そのカテゴリさえないということだ。起こり得る最良の実績は、期待に沿うこと（予定どおり/予算どおり）なのだ。その他の実績は、すべてそこからの下り坂だけだ。(Kindleの位置No.914-920)
■見積もりの困難性
大きな規模の開発の方が、小さな規模の開発よりも失敗しやすい。
また、見積もりは「もしかしたら終わらせることができる最も早い日」（DeMarcoによる「見積り」の定義）になりやすい。つまり実行可能な最小コストになってしまうということである。
■正確な見積もりの利点
- 状況が可視化される
- 品質の向上
ソフトウェアのエラーの約40％はストレスによって引き起こされることがわかっている。これらのエラーは、適切にスケジューリングをして、開発者にあまりストレスを及ぼさないようにすれば、回避できるものだ（Glass1994）。スケジュールが極端に切迫している場合、そこでリリースされたソフトウェアは、切迫していない状況で開発されたソフトウェアに比べて、約4倍もの欠陥が報告されている（Jones1994）。理由の1つは、チームがソフトウェアをリリースするために、予定期間内に必ず完成しなければならない機能を、間に合わせのバージョンで実装するということだ。過度のスケジュールの切迫は、きわめて費用がかかり間違いの発生しやすいモジュールができる最大の原因であることがわかっている（Jones1997）。(Kindleの位置No.968-974) - ソフトウェア以外の業務部門との連携が良くなる (Kindleの位置No.978)
これは最近実感している。連携がスムーズになると共に開発部門に対する信頼が向上するので、精神衛生上良い。 - 予算が良くなる。
ソフト開発にかかる費用の見積もりが正確になる。言うまでもなく、開発コストが見通せるようになるからだ。 - 早期にリスク情報が得られる
見積もりをした段階で、スケジュールが間に合わない、費用が掛かり過ぎるなどのリスクが見えた場合、その場で何かしらの手を打つことができる。これは見積もりなしに開発を始めて、ターゲットに到達しないのが誰の目にも明らかになってからどたばたするより、ずっと有難い状況だ。
これらの利点は要するに、「これから起きる事が分かっていたら、こんな事ができる」という話である。地図を手に旅をするのと、地図なしに旅をすることの違いだ。見積もりは旅人に地図を提供する。
