以前、超概算見積もり を考えたのはすでに10年前になるので、この際だからバージョンアップ版をあげておこう。この超概算見積もりの手法は PMBOK で言うところの超概算見積もりとは違う。だが、おそらく現実に即しているはずだ。
ざっくり規模見積もりをしたいときに、機能から見積もり始めるのは間違いだ。特に受託開発の場合には、営業さんの云うところの「ざっくり見積もる」というのは、予算と期間になる。いわゆる、QCD で言うところのコストと期限（Delivery）になる。
このため、各種の見積もり手法では「規模見積もり」→「予算見積もり」→「スケジュール」の順番で見積もりをしていくのだが、実際のところ、
- 予算が限られている（Cost）
- リリース日などの期限が決まっている（Delivery）
ことが多いので、Cost と Delivery の制約を先に埋めてしまうほうがよい。
予算（コスト）が決まっている場合
お客や営業さんから「ざっくり予算はいくらでしょうか？」と聞かれることが多いだろうが、言っている人の中にはすでに「ざっくりとした予算」があることが多い。だから、「ざっくりとした予算は？」と聞かれたならば、「あれとこれとこれを組み合わせたら、最大で１億円ですね」と答えるとよい。当然「１億円なんて予算はないよ」という顔をするから（億円単位の大規模開発ならば別だろうけど）、「あれとこれを削って、ここだけ作れば100万円ですかね」と、あきらかに機能不足な話の低予算を提示するとよい。そうすると「そんなに機能が少ないんじゃあだめで、これとこれぐらいはないと」という回答が得られる。
つまり、最大限と最小限の間に「予算」は決まっているのは確かなことなのだ。
その間の部分で、仮決めで（相手の懐を予想しながら、あるいは直接「予算はどれくらいでしょうか？」と聞いても良い）、500万円ぐらいの予算で、と決めたとしよう。
人月計算をやりやすくするため単価100万円/月のソフトウェア開発者を割り当てるとすると、単純計算する超概算見積もりで「予算は500万円、開発期間は5か月」というプロジェクトが生まれる。開発期間は5か月が上限なので、これを超えるとプロジェクトは赤字だ。赤字なプロジェクトは受けてはいけない案件である（時と場合によるけど）。
これを自社で行っているソフトウェア開発手法で見積もってみる。
- スクラムのスプリントを使った場合、スプリントが2週間であれば10スプリント
- チケット駆動で、3チケット/日とすれば、3x20x5 = 300 チケット
- WBS やタスクで週平均3程度を想定すれば、20/3 x 5 = 33 WBS
このように スプリント/チケット/WBS/タスク の上限が決まってくる。
チケットの内容をすべて埋めなくても良い。ある程度チケットの内容を埋めてしまえば、
- 予算以内におさまりそうか（チケットが枯渇しなさそうか）
- 予算以上になりそうか（チケットが大幅に上回るだろうか）
ということがわかる。超過する場合には、500万円という予算を優先して（お客がそれしか出せないのだから仕方がない）、
- 機能（チケット）を減らす → 何か盛り込みすぎている
- 単価を下げる → 並行プロジェクトにより、スケジュールに余裕を持たせる。薄く引き伸ばす
ことになる。うすく引き伸ばす方法は、並行プロジェクトを使ったリスク分散の方法だ。これはまた別の機会に話す。
スケジュール（期限）が決まっている場合
年度末までに開発を終えるとか、元号対応だとか別の理由でスケジュールが決まっている場合がある。このときも「ざっくりと予算と期間はどのくらいですか？」と聞かれるのだが、期限は後ろに倒せない。
例えば、半年後にリリースが決まっている６か月のプロジェクトを想定しよう。すると、単価100万円/月の場合は、600万円の予算となる。ここからチケット数を決めて、概算で割り振ってみる方法は、予算優先の場合と同じだ。
期限内におさまりそうにない（必要なチケットの数が予想よりも多い）場合は、
- 人数を増やす → 単純に馬力を増加させる。当然、予算は増加する。
- 機能を減らす → 期限優先なので、優先度が低い機能は落としてしまう。
リリース日を後ろ倒しにできないので、保険（2割増しあるいは5割増し）を入れておいてリリース日に確実に間に合うようにすることを忘れずに。
予算（コスト）や期限（スケジュール）で概算する
最初から機能（FP法やCOCOMO2など）を使って予算や期間を見積もりしてしまと、結局のところお客が想定している予算や期限と食い違いがでてしまって「機能」自体の見積もりしなおしになる。だから、予算や期限から機能の方を逆算して、規模見積もりが分かったところから再び予算や期間を見積もり直せばよい。特に、客相手の受託開発の場合にはここがポイントになる。
プロジェクト実行時の再見積もり
超概算見積もりをした後に再チェックをして、予算や期間ができたとしよう。このときの見積もりの根拠は「機能」がベースになっているので、プロジェクト実行時にこの機能（規模見積もり）が正しいかどうかを再チェックする。
さきに書いた通り、受託開発では予算と期限が優先なのだから、プロジェクト実行時に注目するポイントは以下になる。
- 機能が増加していないか？
→ チケットが増えていないか？規模見積もりの前提条件がずれていないかをチェックする。 - チケットの消化数は適切か？
→ バーンダウンチャートでチケットを消化する傾きをチェックする。
→ 期限に間に合うか？ - 並行プロジェクトがある場合は、適切にチケットが消化されていないか？
→ 他方のプロジェクトに押されていないか？
→ 仕事の時間が増えていないか。生産効率が落ちていないか？
チケットの消化数を守るために、残業や休出をして補っている場合、勤務時間が増えているのだから「生産効率が落ちている」状態になる。生産量（この場合は消化するチケット数）は同じで、時間が掛かりすぎているのだから、仕事の効率が落ちているとみる。
これらをプロジェクト実行時にはチェックして、対処（人を増やす、予算を増やす、期限をずらす、機能を減らす）を行うのがプロジェクトマネジメントである。
計測のための数え上げに関しては、デマルコ氏の進捗管理やマコネル氏のWBS等の数え上げによる見積もり手法を参考にするとよい。
