「見積もり」にも色々あって、大別すると、「金額見積」と「期間見積」があります。
金額見積のほうは、単価×人員数ということで、いわゆる「人月計算」で使います。経営的、経済的な視点から見れば、社員の給与（あるいは外注費）は、さほど期間に依存するものではありません。期間にあまり依存しないというのは、開発期間が１、２日違ったところで、実は「人月単位」でしか変化しないといういうことです。また、社員なり派遣社員なりの場合には、月次という形で計算するのが普通（あるいは、複数プロジェクトで按分）ですから、時間単価、日単価でちまちまと計算するよりも、大枠の予算にあわせる（あるいは、合わせてプロジェクトが負われるか）に注力したほうが賢明です…が、まぁ大人の事情もありますから、人それぞれ。
さて、ここで話すのは「期間見積」のほうです。開発期間が、１年間なのか、６ヶ月なのか、という見積ですね。
勿論、１人で１年間の期間見積をしたとしても、２人で半年…になるはずもなく（これは自明ですよね、多分）、コミュニケーションコストなり、管理コストなりが掛かって、単純な「単価×人数」にはなりません。
ここで、「どの位の期間でできるのか？」という質問に対して、２つの記述があります。
- リリース日が、固定であるのか？
- リリース日は、できるだけ早くがいいのか？
ということで、リリース日が固定というのは、例えば４月から運用開始、とか年末までに仕上げて年始にWebで大々的に発表とかいう、運用リリース、プレスリリースが決まっているものです。リリース固定の場合は、開発期間の見積の優先度として、「リリース日までに終わるのか？」という優先項目があります。
逆に、できるだけ早くというパターンがあり（多分、ベンチャーとかね）、機能やデザインを作成するまでにどのくらいの期間がかかるのか？という見積です。優先事項は、「開発スピード」ということになります。
この２種類を取り違えてしまうと、
- リリース前にできあがったけど、暇になった。
- 正常にリリースされたけど、機会を逸してしまった。
というパターンに陥ります。
さて、どちらの期間見積であっても、その見積をする期間（時間）はどのくらいとればよいでしょう？という問題があります。マネージメントの立場からすれば、機能の洗い出し、機能の積み重ね、お客への返答機嫌、などを考えると、2週間と思われるのですが、実のところは先の金額見積もりの制限とあいまって「３日間」ぐらいが限界です。さらに、「ざっくりとした金額」を求められる場合は、即日だったりします。
なので、この１～３日間にどのくらいの正確な見積をすればよいのか？という問題ですが、先の「リリース日までの制限」を見極めて、「単価×人数」で計算した後に、「リスクに対して、どのくらいのパワーを突っ込めるか？」というリスク管理と、「難解な機能があった場合、どの位の期間/予算で解決できるのか」という能力の問題があります。
このあたりの期間見積に関しては、パレートの法則を使った概算を使います。「機能の 20% が全体の 80% を占める」のであれば、全体の 2 割の機能を見積もって、1.2 倍すればよいわけです。全体の 2 割というのは、例えば、ざっくりとした構造設計（機能設計でもよい）をした後に、上位の 2 割だけを正確に見積もればよいのです。あるいは、10 機能という風に数を決めておいて（全体が 50 機能になる）、その部分だけ細かく見積もります。
この上位 2 割の機能をピックアップするときには、
- マスター系の機能は外す。
- 移行のための機能は外す。
のように、既知のものは外していきます。既知の機能は、前例があるからこそ「既知」なので、期間見積のぶれはそう大きくないという前提があります。また、何らかのリスクが発生した場合であっても、「既知」だからこそ過去のプロジェクトなり、過去の人員なりでフォローする可能性が高くなります。
そんな訳で、「未知」のものに対して概要的な設計をして、FP などを使い規模が大きいのか、小さいのかを見極めます。「未知」のものが規模的に少ないのであれば、安定したプロジェクトとして単純に「単価×人数」で計算します。「未知」の部分は、リスク管理として別枠で予算／期間を取ります。
逆に「未知」の部分の規模が大きい場合は、先の「リリース日」に合わせて、リリース可能かどうかの照らし合わせをしたのちに、期間から逆算します。逆算してしまうのは、「未知」ゆえのブレをあらかじめ見積もったところで正確には見積もれないのは明らか（ですよね、多分）なので、「リリース日」という制限を優先した後に、リリースに間に合うかどうかを優先させます。
このあたり、後で図解でも書きますか。フロー的に書けると思うので。
