新たなプロジェクトを始めるにあたり、何はともあれ最初にやらなくてはならないのは、要件定義と作業全体の見積もりです。どちらも重要なフェイズですが、要件定義はプロジェクトの途中でも仕様変更できないわけではないため、より失敗できないのは見積もり作業の方だと言えるでしょう。
あまり高い見積もりを出すと契約が取れませんし、かと言って安すぎる見積もりを出してしまうと、人員や納期に余裕のない、地獄のような案件になってしまいます。
正しく工数を見積もるためには、どのような点に注意すれば良いのでしょうか。そのいくつかのポイントをご紹介していきます。

タスク一覧の作成

見積もりでまず行わなければならないのは、全作業の一覧化です。
何を当然のことを、と思われるかもしれませんが、実はこれがなかなかの難題です。設計書やプログラムの製造などをリストアップするのはもちろん、それらのレビューやフィードバック対応、定例の打ち合わせ、各種申請書の作成や押印など、ありとあらゆるタスクを細かく挙げていくのは大変な作業です。
できれば3人くらいで総掛かり的に行い、リスト漏れを防ぎたいところですね。

人数での工数を見積もる

見積もりにおいて大切なのは、あくまで「工数」の見積もりであって、「期間」の見積もりではない、ということを理解することです。
例えば設計書を一つ作るのに「作成に3日、レビューに2日、フィードバックに1日」かかるという想定をした時、見積もり時に「6人日」と計算して良いのでしょうか？
答えはノーです。
レビューは一人ではできないので、日数×人数で見積もらなくてはなりません。もしもレビュワーが2人いるのなら、「作成3人日＋レビュー3×2人日＋フィードバック1人日」で、合計10人日となるわけです。
このように見積もりとスケジュール組みを混同してしまうと、正確な工数を計算できなくなってしまいますので、注意しましょう。

大作業は内訳を作る

重く複雑な資料、例えばプロジェクト開始時の計画書など、一つのアクションに10人日以上必要になる作業の場合は、見積もりの内容を細分化して書きましょう。
各工程を大よその工数で積んでしまうと、ともすれば過剰に積んでしまい、クライアントからクレームを受ける可能性もあります。
見やすく内訳を作り、可能な限り無駄を省くよう気をつけてみてください。

バッファを用意する

リスクマネジメントの観点からすると、ギリギリの工数で見積もりするのは論外です。日々トラブルが発生する可能性を見越し、それに対応するためには、本来の工数の10%ほどのバッファを積んでおくと良いでしょう。
この時注意しておきたいのは、工数とバッファは別の項目にして、フェイズごとに一覧化しておくことです。そうすることで、バッファの妥当性をクライアントにアピールできるようになるでしょう。
また、調査が難しくて工数を見積もりきれない、プロジェクト以外の状況でやることが変わってくるというと会う時には、ブラックボックス用のバッファを別に用意しておくと、さらに安心ですね。

見積もりはチーム全体で行うもの

ここまで挙げた通り、工数の見積もりには多角的な視点が必要です。管理者だけ、あるいは開発者だけで工数を見積もろうとすると、必ずどこかで歪みが生まれ、きついスケジュールのプロジェクトになってしまうことでしょう。
見積もりを行う際は、必ずチーム全体で取り掛かり、漏れなく正確なスケジュールを立てなくてはならないのです。