　この“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について解説してきました。

　具体的には、見積もり技法の基本として、過去の類似プロジェクトから予測する方法（類推法の一種）、LOC（Lines of Code）やFP（Function Point）を計測する方法（積み上げ法の一種）、SLIM（Software Life Cycle Management）による見積もり法（パラメトリックス法の一種）。さらに、FP試算法、トリアージュ、SLIMの3つの技法を駆使して、デスマーチ・プロジェクトに正面から立ち向かう方法も紹介しました。

　いよいよ、見積もり・シリーズの最終回です。今回は、これまでお届けしてきた内容から重要ポイントを抽出し、“総まとめ”といたします。

1．2つ以上の方法で見積もる

　ソフトウェアの「規模」「スケジュール」「コスト」を見積もる技法として、唯一無二の方法というものは存在しません。

　見積もりは、以下の3つの技法が基本となります。

類推法　……過去の類似プロジェクトから予測する方法
積み上げ法　……見積もりの王様的技法。開発対象のソフトウェアをモジュールに分解してLOCを見積もったり、ファイルやデータからFPを予測したりする方法（FP試算法）
パラメトリックス法　……数学的モデルを使う方法（パッケージになっていることが多い）

　そして、これらの技法の中から、1つではなく、“2つ以上”を使って見積もることが何より重要です。中でもオススメは、類推法とFP試算法の組み合わせです。特に、FP試算法は、30分程度で見積もり法を習得できる上に、ソースコード行数を見積もるよりもはるかに精度が高いので、ぜひ活用してみてください（FPアレルギーの人は、だまされたと思って、一度適用してみてください）。

2．デスマーチ・プロジェクトを視野に入れる

　ソフトウェア開発プロジェクトを成功に導くには、「いかに、デスマーチ・プロジェクトに対処するか」を常に考えねばなりません。

　仮に、高精度な見積もりができたとしても、デスマーチ・プロジェクト問題そのものが解決するわけではありません。なぜなら、デスマーチ・プロジェクトは、開発期間やコスト（人月）が政治的な理由であらかじめ決まっており、問答無用にこの「実現不可能なスケジュール（無理難題スケジュール）」を押し付けられてしまうからです。

　この無理難題スケジュールを提示された際に、開発側のプロジェクトマネジャーが「うーん。大変だけど、残業と休日出勤で頑張れば乗り切れる！」と判断したら……。発注側と開発側の双方が確実に共倒れします。

　プロジェクトマネジャーは、以下の4つのステップを実施する必要があります。

ステップ（1）　まず、発注側の要求仕様を「必須」「必要」「希望」の3つに分類します。全ての機能を実装する時間がない場合は、優先順位の高い機能から作ります（トリアージュ）。

ステップ（2）　要求仕様をベースに、3種類の見積もり法（類推法／積み上げ法（FP試算法）／パラメトリックス法）を駆使して開発対象規模を見積もります。ここでは、開発規模を水増ししていないことを発注側に証明するため、“客観性のある見積もり方法”、例えば、FP試算法を使うことが重要です。

ステップ（3）　開発規模から、SLIMを適用して、「最短開発期間（1万人のエンジニアを投入したとしても、この期間より絶対に短くならないという月数）」を求めます。発注側が提示したスケジュールの方が、最短開発期間よりも短い場合、このプロジェクトは確実に失敗します。

ステップ（4）　世界の6300以上のプロジェクトで、最短開発期間よりも短い日数で開発できた事例は1つもないことを発注側に理解してもらい、実装する機能の量（必須／必要／希望のうち、どの範囲を開発対象とするか）と、開発期間を発注側と調整します。