システム見積もりの前提条件｜対象範囲・未決事項・再見積もり条件を整理

システムの見積もりを確認するときは、金額と期間に加えて、何を前提に算出したかを確かめましょう。対象の機能、データ、環境、利用者側の作業が曖昧だと、同じ金額を見ていても、想定している仕事が異なることがあります。

この記事では、技術担当と見積もりを取りまとめるIT営業向けに、前提条件の残し方を整理します。価格相場や契約条項のひな形ではなく、算出に使う情報を共有するための方法です。

見積時点で分かっていることを区別する

IPAの見積もり手法に関するアーカイブは、見積時期やプロジェクトの特性によってリスクや適用条件が異なることを説明しています。2004〜2008年度の研究をまとめた資料であり、現在の単価を示すものではありません。IPAの見積もり手法

初期相談の段階と、調査を終えた段階では、使える情報が異なります。概算か詳細な見積もりかという名称だけでなく、確認できた情報と、仮置きした条件を添えましょう。

前提表では、少なくとも次を分けます。

「対象外」と「未確認」は同じではありません。必要かどうか分からない作業を、説明せず対象外へ移すと、後で確認すべき論点が消えてしまいます。

「顧客管理機能」のような機能名だけでは、設計、移行、テスト、教育、運用準備のどこまでを含むかが分かりません。成果物と、それを完成させるための作業を対応づけます。

この表は確認案であり、すべての案件に同じ作業が必要という意味ではありません。含めない項目も、理由と担当を説明できるようにします。

架空の案件で、毎日データを別システムへ渡す機能を見積もるとします。単に「連携機能一式」と書くのではなく、入力形式、処理する範囲、受け側の仕様、エラー時の再処理を分けます。

この例に金額を当てはめても、実案件の見積もりにはなりません。実際の資料と担当者の確認に置き換え、技術担当が算出した根拠へつなげます。

不明点を列挙するだけでなく、回答がないと何が決まらないかを説明します。「データ件数を確認したい」なら、処理方法、検証環境、作業期間などのどこへ影響するかを技術担当と確認します。

回答期限も一律にせず、見積確定や作業開始に必要な順番で整理します。期限までに確認できない場合は、その条件を含む範囲だけ保留する、調査を先に行う、仮定を明記して再確認する、といった選択肢を関係者で合意します。

不明な条件を根拠なく数値で埋めると、見積もりが確定したように見えます。幅や条件付きの提示を使う場合も、幅の根拠と確定に必要な情報を説明してください。

前提が変わったら、まず変更した条件と影響する作業を確認します。すぐに全体を作り直すのではなく、変更箇所、追加調査、金額・期間への影響を担当者が整理し、判断者へ提示します。

以前の見積もりは版と前提を残し、新しい版との違いを追えるようにします。実際の変更や合意の手続きは、案件で定めた方法に従ってください。

提出前には、見積書だけでなく提案書の約束と範囲が一致しているかも点検します。RFP回答の対応表とつなげると、求められた内容、提案した内容、算出に含めた作業を同じ論点で確認できます。