ITベンダーから「システム開発費500万円」という見積を受け取り、「思っていたより高い」と感じることがあります。経営者としては、まず値下げできないか考えたくなるかもしれません。
しかし、システム開発の見積は総額だけでは妥当性を判断しにくいものです。同じ500万円でも、開発する機能、移行するデータ、求める可用性やセキュリティ、テスト範囲、導入支援などが異なれば、実施する作業も変わります。
見積が高いと感じたときに最初に確認したいのは、「この金額で、何を・どの品質で・どこまで実施するのか」です。
本記事では、500万円の見積のうち200万円がデータ移行だった架空例を使い、値下げ交渉の前に確認したいポイントを整理します。
システム開発の見積は総額だけで判断しない
システム開発費は、単純にプログラムを書く時間だけで決まりません。
- 現在の業務・システムの調査
- 要件整理
- 設計・開発
- 他システムとの連携
- データ移行
- テスト・品質確認
- セキュリティ対応
- 導入・切替
- プロジェクト管理
- 運用・保守の準備
など、複数の作業で構成されます。
そのため、「500万円だから高い」「人月単価が高いから割高」といった一つの数字だけでは、見積全体を評価できません。
1. まず見積の前提とスコープを確認する
最初に確認したいのは、どの条件を前提として金額を算出しているかです。
- 対象となる業務
- 利用者数・利用部門
- 必要な機能
- データ量
- 連携する外部システム数
- 利用する端末・ブラウザ
- 移行対象
- 導入予定時期
例えば同じ「販売管理システム」でも、単一拠点で20人が利用する場合と、複数拠点で数百人が利用し会計・在庫システムとも連携する場合では、必要な設計・テスト・運用が変わります。
要件がまだ曖昧な段階では、ベンダー側も一定の前提を置いて見積もることがあります。その前提と自社の想定が一致しているかを確認します。
2. 「何を納品する見積か」を確認する
見積書に「システム開発一式」とだけ記載されている場合、細かな作業時間をすべて開示してもらう必要はありませんが、少なくとも何が成果物に含まれるのかは確認したいところです。
- 要件一覧・設計書
- システム本体
- データ移行ツール
- テスト結果
- 利用者向けマニュアル
- 管理者向け資料
- 導入支援
「何をするか」と「何を受け取るか」を整理すると、価格差の理由を確認しやすくなります。
3. 機能以外の品質要求が費用へ影響する
システムへの要求には、「受注を登録できる」「検索できる」といった機能要件だけでなく、非機能要件があります。非機能要件とは、可用性、性能、セキュリティ、運用・保守性、移行性など、システムの品質や運用条件に関する要求です。
IPAの非機能要求グレードでも、可用性、性能・拡張性、運用・保守性、移行性、セキュリティなどを整理し、発注者と開発者で要求水準を確認する考え方が示されています（IPA, 2018）。
例えば、「営業時間中に多少停止してもよいシステム」と「停止すると受注業務が止まるシステム」では、バックアップや冗長化、監視、復旧に求められる水準が変わります。
見積が高く見える場合には、高い要求水準が暗黙に含まれていないか、逆に必要な要求が漏れていないかを確認します。
4. 500万円のうち200万円がデータ移行だった架空例
架空の中小企業が業務システム刷新の見積を取得し、総額が500万円だったとします。そのうち200万円が「データ移行」です。
経営者としては、「データを移すだけで200万円は高いのではないか」と感じるかもしれません。
しかし、この数字だけでは200万円が高いとも安いとも判断できません。まず、何を実施する費用なのかを確認します。
移行対象は何か
- 顧客マスタ
- 商品マスタ
- 受注データ
- 過去の取引履歴
- 添付ファイル
何年分を移行するか
直近1年分だけなのか、10年以上の履歴をすべて移すのかでも条件が異なります。
現在のデータ品質はどうか
重複、欠損、表記揺れ、古いコード体系などがあれば、単純なコピーでは済まない可能性があります。
5. データ移行費は何にかかっているのか
データ移行では、旧システムと新システムでデータ構造が異なることがあります。その場合、旧項目を新項目へ対応付ける「データマッピング」や、形式を変更する変換処理が必要です。
また、本番移行前に試験移行を行い、件数・金額・マスタ等が正しく移ったか照合する作業も考えられます。本番切替に失敗した場合に旧環境へ戻す方法も、業務停止リスクが高いシステムほど重要です。
反対に、移行対象が少量で単純な形式にもかかわらず、200万円に何の作業が含まれるのか説明できないのであれば、価格交渉より先に対象範囲を確認する意味があります。
費用を調整する方法として、すべての過去データを新システムへ移すのではなく、直近データのみ移行し、古い履歴は別途参照可能な状態で保存する方法も考えられます。ただし、法令、契約、業務上の検索要件、旧環境の維持費などを確認した上で判断します。
6. テスト・プロジェクト管理費をどう見るか
見積の中で、テストやプロジェクト管理費が大きく見えることもあります。
テストには、個別機能を確認する単体テスト、複数機能やシステム連携を確認する結合テスト、システム全体を確認する総合テスト、利用企業が業務上の要件を確認する受入テストなどがあります。
「テスト費を減らしたい」と考える場合は、金額だけを削るのではなく、どのテストをどこまで減らすのか、その結果どの品質リスクを受け入れるのかを確認します。
プロジェクト管理も、会議を開催するだけではありません。進捗、課題、変更要求、品質、複数ベンダー間の調整などが含まれる場合があります。規模や複雑性によって必要な管理作業は変わるため、「管理費だから不要」と一律には判断できません。
7. 保守・クラウド・ライセンスを分けて考える
初期導入費が妥当でも、導入後に継続費用が発生します。そこで、初期費用と継続費用を分けます。
| 費用区分 | 例 |
|---|---|
| 初期費用 | 要件整理、設計・開発、データ移行、テスト、導入 |
| 継続費用 | クラウド、ライセンス、保守、監視、問い合わせ対応 |
| 将来費用 | 機能追加、仕様変更、データ増加、他システム連携、終了・移行 |
このようにライフサイクル全体で必要となる費用を総保有コスト（TCO）として見ると、「最初の開発費が最も安い提案」が長期的にも低コストとは限らないことが分かります。
また、開発時の不具合を一定期間修正する保証と、導入後の問い合わせ、監視、障害対応、アップデートなどを継続する保守は分けて確認します。
8. 見積の「含まれないもの」を確認する
見積を読む際は、含まれるものだけでなく、除外事項も重要です。
- データクレンジング
- 手作業によるデータ登録
- 社員向け研修
- 操作マニュアル作成
- ネットワーク変更
- 端末・周辺機器
- 第三者製品のライセンス
- 要件変更に伴う追加開発
こうした作業が後から必要になれば、最初の見積が安くても総額は増えます。
特に要件が変わった場合、「どこから追加費用になるのか」「変更時にどのような手続きで再見積するのか」を確認しておくと、導入途中の認識差を減らしやすくなります。
9. 値下げするなら「何を変えるか」を明確にする
見積内容を確認した結果、予算に収まらない場合もあります。そのとき、単価だけを下げてもらう以外にも選択肢があります。
- 初期導入する機能を絞る
- 第2段階へ回す機能を決める
- 移行する過去データを見直す
- 既存SaaSで代替できる部分を確認する
- 非機能要件の水準を再確認する
- 保守・サポート水準を見直す
- 導入時期・スケジュールを調整する
例えば要求を「必須」「できれば必要」「今回はなくてもよい」「将来対応」に整理すると、単なる値引きではなく、必要なスコープへ合わせた再見積を依頼しやすくなります。
10. 相見積もりは同じ条件に近づけて比較する
相見積もりを取ることは、選択肢を比較する方法の一つです。しかし、総額だけを横に並べても正しく比較できない場合があります。
例えばA社500万円にはデータ移行、テスト、社員研修、保守準備まで含まれ、B社350万円は開発本体のみというケースなら、150万円の価格差だけでは評価できません。
| 比較項目 | A社 | B社 |
|---|---|---|
| 対象範囲 | 確認 | 確認 |
| データ移行 | 確認 | 確認 |
| テスト | 確認 | 確認 |
| セキュリティ | 確認 | 確認 |
| 教育・マニュアル | 確認 | 確認 |
| 保守 | 確認 | 確認 |
| 除外事項 | 確認 | 確認 |
同じ要求条件にできるだけ近づけ、それぞれ何を含むかを確認してから価格を比較します。
見積が高いと感じたら、値下げを依頼する前に、「この項目には何の作業が含まれるか」「何を成果物として受け取るか」「どの前提で見積もっているか」「何が含まれていないか」の4点を確認してみてください。
金額を削る場合も、どの作業・要求水準を変更するのか明確にした上で再見積を依頼すると、価格とリスクの関係を確認しやすくなります。
システム見積確認チェックリスト
| 確認項目 | 確認すること |
|---|---|
| 前提条件 | 利用者、データ量、対象システム、期間等が自社認識と合っているか |
| 対象範囲 | 何を実施し、何を実施しないか明確か |
| 成果物 | 最終的に何を受け取れるか |
| 非機能要件 | 可用性、性能、セキュリティ等の水準は適切か |
| データ移行 | 対象、変換、試験、照合、本番切替の範囲が分かるか |
| テスト | どの種類・範囲のテストを行うか |
| 管理 | 進捗・品質・課題・変更管理の範囲が分かるか |
| 継続費用 | クラウド、ライセンス、保守等を把握しているか |
| 除外事項 | 別途必要になる作業・費用を把握しているか |
| 変更条件 | どのような変更で追加費用が生じるか |
| 優先順位 | 必須・任意・将来対応を整理したか |
| 相見積もり | 各社の対象範囲・条件を揃えて比較しているか |
まとめ
システム開発の見積が高いと感じても、総額だけで妥当・不当を判断することは難しいものです。
まず、前提条件、スコープ、成果物、要求品質、データ移行、テスト、プロジェクト管理、保守、除外事項、追加費用条件を確認します。
500万円のうち200万円がデータ移行だった場合も、「200万円は高い」と即断するのではなく、移行するデータ、現在のデータ品質、変換、試験移行、照合、本番切替、失敗時の復旧まで何を含むか確認することが先です。
その上で予算を超えるのであれば、機能、移行範囲、要求品質、導入時期、サポート水準などを見直し、「何を変えた結果、いくらになるのか」を確認します。
SCI総合研究所株式会社のKAMUSHIRUBEでは、「ITベンダーから見積を受け取ったが妥当性を判断できない」「移行・テスト・保守の費用がなぜ必要なのか整理したい」「値下げ交渉の前に、ベンダーへ確認すべき事項を整理したい」といった段階から相談できます。
価格の高低そのものを鑑定するのではなく、提案内容、対象範囲、要求品質、移行・運用条件などを整理し、自社で判断するための確認事項を明確にします。
参考文献
- 独立行政法人情報処理推進機構（IPA）. 2018. 非機能要求グレード2018.
- 独立行政法人情報処理推進機構（IPA）. 2019. ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ.
- ISO/IEC/IEEE. 2018. Systems and software engineering — Life cycle processes — Requirements engineering. ISO/IEC/IEEE 29148:2018. DOI: 10.1109/IEEESTD.2018.8559686.