思えばここ数年，「ソフトウエア見積もり」というテーマを追い続けてきた。2004年9月，日経ITプロフェッショナル（現在は日経システム構築と統合して日経SYSTEMS）で「本当に使える見積もり技術」という特集記事を担当。多くのユーザー企業やベンダーに取材し，現場の問題意識の高さや見積もりの難しさを知った。日本ファンクションポイント・ユーザ会をはじめ関連団体の会合にも参加し，現場のエンジニアの生の声を聞いた。

　その特集が高スコアを得て，気をよくした記者は同タイトルの連載記事を企画（寄稿者は日立製作所の初田賢司氏）。2005年5月から11回にわたって，同連載の編集を担当した（おかげ様でこの連載も大変好評だった）。そしてこの10月2日，同連載をベースに大幅に加筆・修正した単行本を刊行する（要求定義に関する単行本も同時に刊行）。今回の記者の眼では，これまでの取材や編集などを通じて，見積もりについて“クリア”になったことを述べてみたい。

見積もりには「タイミング」がある

　取材を通じて記者が強く感じたのは，今求められている見積もりは「受注の取れる見積もり」ではなく，「プロジェクトを成功させる見積もり」ということだ。見積もりが甘ければ，たちまちプロジェクトは混乱する。だから，ユーザー企業もベンダーも，見積もりに対して非常に敏感になっている。

　しかし，ソフトウエア見積もりは難しい，とよく言われる。その理由は様々だが，最も大きいのは「前提条件」が曖昧なことだろう。見積もりの段階で「何を作るか」や「どう作るか」といったことは，非常に曖昧な場合が多い。この曖昧な前提条件をベースに見積もるのは至難の業である。

　話が少々飛ぶが，記者はその昔，ある製造業の生産管理部で「見積もり」の仕事をしていた。と言っても，ソフトウエアの見積もりではない。金型部品の見積もりである。金型の寸法や材質から材料費を算出し，加工の種類や数，難易度に応じて加工費を積算する。詳細なCAD図面を見ながらの見積もり作業はとても面倒だったが，判断に迷うことはなかった。なぜなら「前提条件」がはっきりしていたからだ。

　ところが，ソフトウエア見積もりの場合はそうはいかない。引き合いの段階では，システムの詳細など決まっていない場合がほとんどだ。そのため，過去の類似案件をベースにおおよその数値を出す。これが見積もりの最初のタイミングに当たる「試算見積もり」である。

　ただ，この前提条件は議論や時間が進むにつれて，次第に明確になっていく。つまり，現実には見積もりのタイミングがいくつかあり，そのタイミングに応じたやり方で見積もることがポイントになる。

　例えば，ユーザー企業は予算執行の段階になると，RFP（提案依頼書）などを作成・提示（もちろん出さないケースもある）して，ベンダー選定に入る。RFPには，試算見積もりのときと比べれば格段に詳細化されたシステムの概要が示される。これを前提条件として算出するのが「概算見積もり」だ。

　ベンダー選定が終わると，契約に当たってさらに前提条件を詰めていく。これをベースに作成するのが三番目の「詳細見積もり」である。この段階では，プロジェクトを実施するに当たり，基準（ベースライン）となる規模や工数，期間，体制，コストなどを明らかにする必要がある。

　問題なのは，概算見積もりや詳細見積もりの段階で「試算見積もり」のやり方をしたり，詳細見積もりの段階で概算見積もりの方法を採用したりすること。確かに幾度も同様の開発プロジェクトを経験したエンジニアなら，類推法でも精度高く見積もることができるかもしれない。だが，全く同じシステム開発など存在しないし，「プロジェクトを成功させる見積もり」とするのは難しい。

　前提条件が明確になるに従って，「試算見積もり」→「概算見積もり」→「詳細見積もり」というタイミングで見積もる。さらにそれに合わせて見積もり技法を変える――。これが，見積もりをうまくいかせるためのポイントと言える。