見積の科学

皆さんは公私共に見積ってしてますよね？試算と言い換えても良いです。
プライベートだとマイホームの購入や子供の教育費とか。
仕事だとプロジェクト開始前には必ず行いますよね。あとは年度予算を決める時とかも必ずだと思います。
今回はその中でもシステム開発プロジェクトにおける見積のお話です。
因みに私はシステム開発のプロジェクトマネジャーを務めることが多いのですが、発注側及び受注側両方の経験があります。

見積の目的

こちらは発注者側のお話です。
見積と一言で言っても、その見積を取得する目的に応じてその内容は変わってきます。
発注者はプロジェクトが段階の時に何を目的として見積を依頼するのでしょうか。
　最初はプロジェクト企画段階で、目的は予算取得になります。
企業の多くは年度毎に予算を組みます。そして消化した予算と成果を集計して利益の計算をします。システム開発プロジェクトもこの流れで進みますので、プロジェクト企画段階において予算取得を目的とした見積が必要になります。
ただ、この時点では要件は曖昧であることが多く精度の高い見積は不可能です。進化の早いデジタル領域では参考となる他社事例は多くないので、実は根拠のない見積だったということも珍しくないのでは？と思います。
　次にプロジェクト実行前に取得する予算執行を目的とした見積です。
これを取得する頃にはRFPやそれに準ずる情報が開発ベンダに渡っている状態なので、先の見積よりは精度が高くなります。
小規模であったりシンプルなプロジェクトであれば、この見積に対して発注是非を検討することになります。
大規模になってくると、更に見積精度を高めるためにもう一度見積を取得します。発注側が予算の一部を使って要件定義というフェーズを経ます。そしてより精度の高い見積を取得することになります。
だったら最初から要件定義を行えば良いと思われるかもしれませんがそれは難しいのです。なぜなら先の見積は複数の企業から取得しているので、発注する可能性の低いパートナー企業と有償の要件定義を行いたくないからです。
　最後にプロジェクト期間中に取得する更なる予算執行をするための見積です。
業務が複雑化していて変化が早い昨今、プロジェクト期間中に要件が変わったり増えたりすることは避けられません。プロジェクトの早い段階で変化に気付き、先手先手で見積を取得して対応する必要があります。

見積の内容

こちらは受注側のお話です。
発注側が何を目的としているかで見積の内容が変わります。変わる点は大きく二つで見積の精度と時間です。この二つはトレードオフの関係にあるので、場合に応じてどちらにどの程度の重心を置くのかがキモになります。
　先ずは試算見積でクライアントが予算取得を目的としているときに作成する見積です。こちらはスピードが何より重要です。そして言わずもがな精度は高くなりません。
しかし、もしこちらからの提示した見積でクライアントが予算取得をしてくれた場合は、競合に対して大きくリードできるので手は抜けません。
私は精度は高くないがその後の見積が大きく変わるポイント見極めて、複数パターンの見積をするようにしています。
　次が概算見積でRFPやそれに準ずる依頼に対して行います。この見積が競合と比較されて採用/不採用が決まるので、クライアントの予算内でなおかつ最高の成果物が期待できる見積をする必要があります。
概算見積もリードタイムは短く情報も限定的なので、精度よりも時間が優先されます。また、選考の都合から複数の見積は受け取ってもらえないことも多いです。そのため、見積変動要因については前提条件として見積に記述してリスクヘッジします。
　次は要件定義後に行う詳細見積です。ここでようやく精度の高い見積が可能になります。逆の言い方をすると要件定義を行わなければ詳細見積を行うことは出来ません。仮定に対して見積もることになるので、経験と勘でリスク工数を算出します。根拠がないので私は好きではありません。
　プロジェクトは生き物です。想定と違うことが起こることは十分に予想されます。その時に取得するのが再見積や追加見積です。
期初に取得していた予算内であれば良いのですが、そうでない場合は取り扱い注意の見積となります。
アクションとしては予算外の費用で同期に実行するか翌期の予算として申請するかなのですが、経営も投資家も計画と実行の差異を嫌うのでとにかく説明が大変なのです。

それぞれの契約形態

最後に契約形態についても触れておきます。
システム開発プロジェクトは大雑把に3段階で構成されます。そして一般的にはそれぞれの段階における契約形態は以下の通りです。
要件定義：準委任契約
設計、実装：請負契約
テスト：準委任契約
しかし、昨今は準委任契約といっても『成果型』と『履行割合型』があり、その中でも『成果型』は請負契約と似ていると感じます。誤解によるトラブルにならぬよう、発注側も受注側もしっかり勉強したら良いのにと思う。