概算見積とは

概算見積とは

開発対象がまだ確定していない段階で、費用と期間の規模感を把握するために算出する見積もりです。
構想や企画の段階で、取り組みの費用が数百万円規模と数千万円規模のどちらになるのか、桁を確認するために利用します。

概算は要件定義の完了後に算出する詳細見積もりより、見積もりの基になる情報が少なくなります。
類似の過去案件や、想定される画面や機能の数から、数日から数週間で金額を算出します。
画面が20枚程度の業務システムなのか、100枚を超えるのかが分かれば、概算でおおよその桁を提示できます。

見積もりはどれだけ外れうるか

見積もりの外れ幅は開発対象の確定度合いに左右されます。
Construx社の 不確実性のコーン の解説は、熟練した担当者が見積もっても段階ごとに次の幅で外れうると整理しています。
段階の進行に伴って幅が縮小する形から、この名で呼ばれます。

見積もりを算出した段階	実際の費用の幅
構想段階	見積もりの0.25倍〜4倍
開発対象の範囲と目的を合意した段階	見積もりの0.5倍〜2倍
要件定義が完了した段階	見積もりの0.67倍〜1.5倍

構想段階で1,000万円と算出された概算は、実際には250万円から4,000万円までの幅があります。
これは熟練した担当者が見積もった場合の幅で、条件が悪ければ幅はさらに拡大します。
表の幅は上下対称ですが、見積もりは楽観的になりやすく、開発の途中で要望は増加しても減少することは少ないものです。
そのため実際の外れは上振れの方向が多くなりやすくなります。
予算の策定時は下振れを当てにしません。

幅は開発する範囲と開発しない範囲を決定した分だけ縮小します。
開発範囲を後から再検討すれば、幅は再び拡大します。

IPAの ITユーザとベンダのための定量的見積りの勧め は、最初の予算決定で利用した概算がその後も制約として存在し続ける例を紹介しています。
同資料は本来は2〜3倍、あるいは10倍の予算を必要とするプロジェクトが、その制約のため実現不可能な計画になると指摘しています。

利用できる場面と利用できない場面

利用できる場面

• 開始するかどうかを決定する。費用の桁が事業の効果に対して過大なら、要件定義に費用をかける前に中止できる
• 複数の案を比較する。全面開発か市販製品の組み合わせかといった方針の違いは、概算でも桁の差として判明する
• 要件定義やPoC（Proof of Concept）の予算を確保する。次の段階へ移行するための費用を申請する材料になる
• 自社がまだ決定していない事項を把握する。開発会社に前提条件や不確定な点の列挙を依頼すると、要件定義で決定すべき事項の一覧になる

利用できない場面

• 開発会社への発注金額を確定させる。開発範囲が未確定のまま金額を固定すると、開発会社は外れに備えて予備分を上乗せするか、範囲を限定的に解釈して追加費用で回収しようとする
• 事業計画の費用として1つの数字のまま記載する。一度記載した数字は以後の交渉や評価の基準になりやすく、上振れが失敗と評価されるおそれがある
• 稼働後の費用を見積もる。概算の多くは開発費だけで、保守費、クラウドなどのインフラ費、社内の担当者の作業時間は含まれていない。稼働後の費用は別に確認する

概算を依頼するときのコスト

• 受注を優先する開発会社は概算を低めに提示し、慎重な開発会社は高めに提示する傾向がある。金額の差は実力の差を反映するとは限らない
• 概算の算出にも開発会社の工数がかかる。無償の依頼を反復すると見積もりに工数をかける会社ほど辞退しやすくなる
• 概算で決定した予算に応じて開発範囲を縮小すると、稼働後に必要な機能を追加する費用が別にかかる

幅を縮小するために発注側が提供する情報

概算の精度の大部分は発注側が提供する情報に左右されます。
依頼時には次の情報を準備します。

• 開発の目的、どの業務の何を変更したいのか
• 利用者の種類と人数
• 想定する主な画面や帳票、既存のシステムとの連携先
• 対象とするデータの種類と量、既存システムからのデータ移行の有無
• 稼働させたい時期と、変更できない期限の有無
• 開発しないと決定した事項

開発しないと決定した事項は、依頼時に伝達されないことが多くあります。
範囲の外側が明確なら開発会社は予備分を縮小できます。

大規模な案件で複数の会社から比較可能な形で概算を収集したいなら、これらをRFP（Request for Proposal）に整理して提示します。

気にしなくてよい場面

• 料金表のあるSaaS（Software as a Service）を設定して利用し、追加開発がほとんどない導入
• 月単位で体制を確保して開発し、毎月の成果を確認して継続を決定する契約。この場合に継続の基準となるのは、概算の精度より月ごとに完成した成果物
• 費用が社内の決裁で個別に審議されない少額の改修

よくある誤解

開発会社が提示した概算はその会社の約束

概算は前提条件が変化しない範囲での見込みで、約束ではありません。
多くの概算書には前提条件と除外事項が記載されています。
金額だけを社内に回覧すると前提が欠落し、約束と同一視されます。
概算と実際の金額に差が生じたときに誰が負担するかは、その後に締結する契約の形態に依存します。
請負なら契約金額を超過した分は原則として開発会社が負担し、準委任なら延長した期間の費用を発注側が負担します。

時間をかければ概算の精度は向上する

概算の精度を向上させるのは開発範囲についての決定で、見積もりにかける時間の長さはほとんど関係しません。
未決定の事柄が多いまま開発会社に再見積もりを依頼しても、幅はほとんど変化しません。

一番安価な概算を提示した会社が一番安価に開発できる

最も安価な概算は最も限定的な範囲を前提にしていることが多くあります。
IPAの ITユーザとベンダのための定量的見積りの勧め も、価格だけで発注先を選定すれば、発注側・開発会社の双方に不利益が生じると指摘しています。