システム開発の見積書を受け取ったら何を確認する？
同じシステムについて二つの見積もりを受け取ると、まず総額を比べたくなるものです。しかし、同じ「顧客ポータル」でも、一方は機能開発だけ、もう一方は過去データの移行、稼働開始、社員への操作説明まで含んでいるかもしれません。
そのため、金額差だけでは、どちらが適しているかは判断できません。各社が引き受ける作業、受け取れる成果物、金額の前提条件を先に理解する必要があります。それらが明確になれば、見積もりを比較し、別途必要な費用も見通しやすくなります。
本記事は、開発会社を選ぶ方や、依頼先との調整を担当する方に向けたものです。顧客ポータルは説明用の例であり、Fenixの実際の案件ではありません。必要な詳細さは検討段階によって異なります。未確定の項目は、含まれると考えず記録しておきましょう。
1. 範囲と受け取る成果物を理解する
機能一覧が十分に見えても、解釈の余地は残ります。顧客向けサポートポータルの「ログイン」は、管理者が作るアカウントだけを指すかもしれません。別の見積もりには、新規登録、認証、パスワード再設定、既存アカウントシステムとの接続まで含まれる場合があります。同じ機能名でも、作業量は異なります。
「問い合わせ履歴の表示」も同様です。稼働後の新しい依頼だけを表示するのか、何年分もの過去データを移して表示するのかで作業は変わります。機能数よりも、誰が使い、何を操作し、どのデータを扱い、どんな結果が必要かを話し合いましょう。
すべての見積書に詳細仕様が必要なわけではありません。ただし、双方が参照する要件資料や範囲の版は特定しておくべきです。決まっていない点は記録して確認を続けます。不明点の多い案件では、実装範囲を決める前に調査が必要な場合もあります。
機能に加え、各工程で何を受け取るかも具体化します。確認用の設計、試験環境で動くソフト、それとも利用可能なシステムでしょうか。文書、合意したソースコード、操作説明も含むのでしょうか。これを確認することで、「開発完了」を社員がすぐ仕事を始められる時点と誤解せずに済みます。
2. プログラミング以外の作業を確認する
機能と成果物を理解したら、それを使える状態にするまでの作業を見ます。機能一覧がほぼ同じでも、見積もりに差が出やすい部分です。
要件分析と設計
開発前には、実際の業務をシステムでどう支えるかを合意します。そのため、要件の明確化、画面設計、処理方法の確認が含まれるかを確かめましょう。発注側が用意する資料の詳しさ、承認者、レビューの機会も共有します。
責任が曖昧だと、発注側は開発会社が細部を整えると思い、開発側は確定した要件や設計を待つことがあります。事前に協業方法を決めることで、それぞれの作業を理解してから開始できます。
他ソフトとの連携とデータ移行
ポータルには、既存のサポートシステムから情報を取得する機能が必要かもしれません。連携が見積もりに含まれるか、どの技術資料をもとに算定したかを確認します。既存システムの提供会社が参加するなら、その費用や作業は別に考える場合があります。
過去データは、種類、対象期間、取得元、移行後の確認方法を決めます。「移行支援」だけでは、誤りや欠落のある記録を誰が整えるかは分かりません。移行時に気付くのではなく、事前に責任を合意しておきましょう。
テストと受入確認
利用前に検証は必要ですが、「テスト」の一行だけでは範囲が分かりません。開発会社が何を試し、発注側がどこに参加し、業務の場面に沿った確認を支援するかを明確にします。合意範囲の不具合修正と、修正後の再確認も示しておきます。
負荷試験やセキュリティ評価が必要なら、その目的と範囲を記載します。「テスト」という項目があるだけで、あらゆる確認が含まれると解釈しないようにします。
稼働開始とその後の支援
完成したソフトにも、動かす環境が必要です。サーバーやホスティング、ドメイン設定、環境構築、リリースを誰が担当するか決めます。基盤、メール配信、外部ツールの費用は開発費に含まれない場合があるため、予算検討時に把握しておきましょう。
稼働後の不具合はどこへ報告し、保証や保守はいつまで続き、新しい要望はどう扱うのでしょうか。範囲、期間、窓口を具体化すれば、受けられる支援が分かります。
3. 算定の根拠と前提条件を明確にする
含まれる作業が分かったら、次は金額の根拠を確認します。範囲を固定した見積もりなら、その価格が適用される作業の定義が必要です。人員や時間で算定する場合は、単位、役割、作業時間の確認方法、予算の追跡方法を明らかにします。
どの方式も、費用の妥当性を自動的に保証するものではありません。要件の明確さと、双方の管理方法に合うかを見ます。人月を使うなら具体的な換算を聞きましょう。総工数は、体制、順序、並行できる作業に左右されるため、そのまま暦上の月数には読み替えられません。
見積もりには、データが指定形式で提供される、発注側が一定期間内に回答する、第三者が接続を提供する、対応言語は記載数に限る、といった前提がある場合もあります。どの条件で価格が適用されるかを説明するものです。実際の条件が異なれば、範囲や計画の調整が必要になることがあります。
条件を読むだけでなく、変更時の扱いも合意します。誰が依頼を記録し、影響を評価し、着手前のどの時点で双方が確認するのでしょうか。明確な進め方があれば、作業後に追加費用を知るのではなく、実施中の変更を把握できます。
4. 同じ範囲で比較し、不足点を確認する
ここまでが明確になったら、業務群ごとに各見積もりを並べます。ポータルなら、アカウント、過去データ、連携、テスト、環境、教育、支援を分けます。それぞれに各社の範囲、発注側の作業、不足情報を記載します。
例えば一社が移行を含めていないなら追加を依頼するか、初期比較では双方から外して条件をそろえます。未確認の費用は別に残します。表を埋めるためだけに推測の数字を入れる必要はありません。
この照合は作業の違いを理解するためのもので、依頼先の評価全体に代わるものではありません。能力、協業方法、実績の根拠は別に検討します。
次の打ち合わせ前に、五つの問いで不明点を整理できます。
• どの要件資料と条件に基づく見積もりか。
• 各工程で何を受け取り、どう確認するか。
• 発注側や第三者が行う作業は何か。
• 記載金額以外の継続費用や対象外は何か。
• 要件や条件が変わったら、双方で影響をどう確認するか。
回答は共通資料へ反映し、特に範囲と費用に関わる点を残します。価格を確定できる情報が足りなければ、追加調査の対象と、その成果物を決めましょう。
明確な見積もりは、何を受け取り、何を準備し、何が未決かを理解できるものです。それが、開発会社と話し合い、実際の業務に合う案を選ぶための土台になります。
