システム開発の見積もりは、金額だけでは比較できません。同じ「購買管理システム」でも、承認の例外処理、既存データの移行、運用開始後の対応まで含むかで内容が変わります。まず共通の依頼資料を用意し、各社に前提条件と対象外の作業を明記してもらいましょう。
機能名ではなく、一連の業務を伝える
例えば購買申請なら、担当者が申請し、上長が承認し、購買部門が発注し、倉庫が入荷を登録するところまでを書き出します。差し戻し、分納、入力間違いの訂正も対象です。「購買モジュール一式」だけでは、開発会社ごとに解釈が分かれます。
各工程について、担当者、入力情報、判断ルール、処理結果、例外を整理します。実際の帳票を共有する場合は、個人情報や取引情報を伏せた見本を使います。商品・仕入先などのマスターをどのシステムで管理するかも決めておきます。
見積書で比較する6項目
- 機能範囲：対象業務、利用者権限、帳票、対応端末。初回リリースと追加候補を分けます。
- 外部連携：接続先、データの方向、更新頻度、連携失敗時の対応。
- データ移行：データ整備、項目対応表、移行リハーサル、開始残高の確認を誰が担当するか。
- 検収条件：合格すべき業務シナリオ、検証環境、不具合の扱い、承認者。
- 引き継ぎ：ソースコード、サーバー管理権限、運用資料、保守担当を変更する場合の手順。
- 継続費用：サーバー、外部サービス、従量料金、バックアップ、保守対応。概算と契約範囲を区別します。
曖昧な要望を検収できる条件に変える
「上長が申請を承認できる」だけでは、権限の範囲が不明です。「申請部門を担当する上長が承認・却下でき、申請者は理由を確認できる。権限のない利用者は承認できない」とすれば、見積もりとテストの基準が近づきます。金額による承認条件は、自社のルールが決まってから追記します。
最初から詳細設計を完成させる必要はありません。不明点が多ければ、要件整理を先行工程にし、その成果物と費用を明確にする方法もあります。
比較表では「未確認」を残す
業務ごとに、含まれる処理、対象外、前提条件、検収資料、初期費用、月額・年額費用を並べます。未確認の項目をゼロ円として扱わないことが大切です。移行や操作説明が別料金なら、導入全体の費用に加えて比較します。
仕様変更を誰が承認し、追加費用や納期への影響をどう記録するかも確認します。口頭で追加した要望が、完成直前に認識のずれを生むことがあります。
発注前の最終確認
- 自社が着手前に準備する資料は何か。
- 見積もりが変わる可能性のある連携・データ条件は何か。
- 完成までの途中段階で、動く画面を確認できるか。
- 検収後に見つかった不具合への対応範囲は何か。
すぐに確定金額が必要な場合は？ 前提が不明なまま固定額を求めるより、範囲を絞った要件整理と条件付きの概算を依頼すると判断材料が増えます。
Webシステム開発やERP開発をご検討の場合は、現在の業務、必要な連携、初回リリースの優先事項をお問い合わせからお知らせください。