「ソフトウエアの見積もりは難しい」とよく言われます。見積もり作業は複雑であり，意思決定の連続になるからです。しかし，複雑なものを複雑なままとらえていては，なかなか解決策が見つかりません。

　私は現在，プロジェクトマネジメントの世界で仕事をしていますが，ここで教えられたことがいろいろ役に立ちます。その一つが「複雑なものはばらして考える」というものです。

　「分割して統治せよ」という言葉があります。作業を分解して小さな範囲でコントロールするWBS（Work Breakdown Stracture）はその典型でしょう。見積もり作業も同じように分割できます。「規模見積もり」「工数見積もり」「コスト見積もり」「価格設定」というものです。そして，「規模見積もり」→「工数見積もり」→「コスト見積もり」→「価格設定」という順序で進めていきます。実際には，これに「見積もりの準備」や「見積もり資料のまとめ」など関連する作業が加わります。

　なぜこのように作業を分割し，かつこの順序で進めるのでしょうか。このヒントもプロジェクトマネジメントにあります。見積もり作業はマネジメントの基準となる「ベースライン」を作る作業と言い換えることができます。そして，このベースラインには，決めていく順番があるのです。それは「成果物スコープ」→「プロジェクト・スコープ」→「コスト」という順序です。

　成果物スコープは，最終成果物に備えるべき機能やサービスを整理したものです。ここでは，プロジェクトに含むものと含まないものを明確にする必要があります。いわば成果物スコープは「何を作るか」を決めたものですね。

　これに対してプロジェクト・スコープは，プロジェクトで実行すべき「作業」について，含むものと含まないものを明確にしたものです。つまりプロジェクト・スコープは「どう作るか」を決めたものと言えます。

　もうお分かりですね。「何を作るか」が決まらないと「どう作るか」は決まりません。「どう作るか」が決まらないとコスト，すなわち「いくらかかるか」も決まりません。

　ベースラインの変更もこの順序で行います。仕様変更があって成果物スコープのベースラインが変わったら，それに伴う作業も増減してプロジェクト・スコープのベースラインが変わります。作業が増減すればコストのベースラインも変わってきます。

　このように考えると，なぜ「規模見積もり」→「工数見積もり」→「コスト見積もり」→「価格設定」という順番で見積もるかが見えてきます。