この記事では、複数社の見積を比較したい企業に向けて、判断すべきポイントを実務目線で整理します。マクティズムでは、いきなり作り直すのではなく、延命・部分改善・パッケージ活用・周辺開発・スクラッチ再構築のどれが現実的かを、現行業務と帳票・データから確認することが重要だと考えています。
この記事で分かること
- 見積範囲
- 要件定義費
- データ移行
- 帳票数
- 連携数
- 保守費
- 比較資料
まず結論
基幹システムの見積を比較する際は、総額ではなく、対象範囲、前提条件、除外項目、追加費用の発生条件を確認します。各社の見積条件がそろっていなければ、金額を横並びにしても適切な比較にはなりません。
例えば、ある会社は現状調査から本番稼働後の支援まで含め、別の会社は開発作業だけを見積もっている場合があります。この二つを総額だけで比較すると、後者が安く見えますが、実際には調査、移行、教育、保守などが追加されます。
最初に、現行業務、利用部署、画面、帳票、データ、外部連携、例外処理を棚卸しし、今回どこまでを対象とするかを決めます。必須機能、導入後に追加できる機能、廃止できる機能を分けることも必要です。
そのうえで、初期費用だけでなく、ライセンス、インフラ、年間保守、追加改修、バージョンアップ、運用負担を含む総コストで比較してください。導入後5年程度の費用を試算すると、各案の違いが見えやすくなります。
よくある背景・失敗しやすい理由
見積比較で失敗しやすい背景には、現行システムの仕様や業務範囲が整理されていないことがあります。設計書が不足し、帳票やExcelの意味を説明できる人が限られていると、見積を依頼する会社ごとに解釈が変わります。
一社には帳票やデータ移行まで詳しく説明し、別の会社には概要だけを伝えている場合、提示される金額の前提は一致しません。また、「現行と同じように作る」という依頼では、開発会社が確認できない作業や例外処理が見積から漏れる可能性があります。
見積書に「一式」とだけ書かれている場合も注意が必要です。一式表記そのものが問題なのではなく、対象機能、作業内容、成果物、作業回数、対象外事項が分からないことが問題です。
最も安い会社を選んだ結果、要件定義後に追加費用が続くこともあります。反対に、高い見積には、リスクを見込んだ調査やテスト、移行支援が含まれている場合があります。金額差の理由を確認せずに判断してはいけません。
確認すべきポイント
1. 見積範囲
まず、見積に含まれる工程を確認します。一般的には、現状調査、要件定義、設計、開発、テスト、データ移行、教育、マニュアル、本番切替、稼働後支援などがあります。
同じ「システム導入」という見積でも、環境構築や操作教育を含む会社と、別料金とする会社があります。ハードウェア、クラウド利用料、ミドルウェア、バックアップ、セキュリティ対策の扱いも確認してください。
対象となる部署、拠点、利用者数、機能、帳票、データ量が明記されているかも重要です。利用者数や拠点数が増えた場合に、追加ライセンスや設定費が発生することがあります。
マクティズムでは、見積の対象と対象外を一覧化し、各社の条件をそろえて比較します。
2. 要件定義費
要件定義費は、単なる打ち合わせ費用ではありません。現行業務を整理し、新システムの機能、運用、帳票、連携、権限、移行方法を決める重要な工程です。
要件定義を安く抑えた見積では、調査回数やヒアリング対象が限定されている場合があります。営業部門だけでなく、物流、経理、情報システム、管理部門まで確認する前提になっているかを見ます。
成果物として、業務フロー、機能一覧、Fit&Gap、画面・帳票一覧、データ移行方針、連携一覧などが作成されるかも確認してください。成果物が不明確だと、後工程で認識違いが起きやすくなります。
要件確定後の変更をどこまで見積内で扱うかも重要です。変更回数や追加費用の算定方法を契約前に確認しておくと、予算超過を防ぎやすくなります。
3. データ移行
データ移行は、対象データ、件数、保有年数、変換内容によって費用が大きく変わります。取引先や商品などのマスタだけを移すのか、受注、売上、在庫、残高、過去履歴まで対象とするのかを確認します。
見積には、データ抽出、項目対応、コード変換、重複・欠損の確認、移行プログラム、リハーサル、本番移行、結果検証が含まれているかを確認してください。
データクレンジングを誰が行うかも重要です。開発会社が機械的に修正する範囲と、取引先の統合など自社が判断する範囲を分ける必要があります。
移行回数が一回だけなのか、複数回のリハーサルを含むのかでリスクは異なります。本番に近いデータ量で検証する費用が含まれているかも比較してください。
4. 帳票数
帳票は、単純な枚数だけでなく、レイアウトや集計条件の複雑さによって費用が変わります。請求書、納品書、一覧表などが同じ一帳票として数えられていても、取引先別の分岐が多ければ工数は増えます。
標準帳票をそのまま使うのか、項目追加やレイアウト変更を行うのか、完全な個別開発なのかを区別します。現在、出力後にExcel加工や手書き修正をしている場合は、その作業も要件として確認してください。
帳票の新規作成だけでなく、PDF出力、メール配信、再発行、送信履歴、電子保存への対応が見積に含まれているかも確認します。
見積前に帳票一覧を作り、必須・統合可能・廃止候補へ分類すると比較しやすくなります。
5. 連携数
外部連携は、システム数だけでなく、方向、頻度、方式、データ量で費用が変わります。一つの会計ソフトとの連携でも、売上、仕入、入金を別々に送る場合は複数の処理が必要です。
CSV、API、EDI、データベース連携など方式によって、開発、テスト、監視、保守の内容が異なります。リアルタイム連携か日次一括か、エラー時に再送できるかも確認してください。
連携先側の改修費が見積に含まれていないこともあります。基幹システム側だけでなく、受信先の設定やテストを誰が担当するかを明確にします。
仕様変更時の対応費、ログ保存、障害通知、接続先のAPI利用料など、運用後に発生する費用も比較対象です。
6. 保守費
保守費は月額や年額だけでなく、対象範囲を確認します。問い合わせ、障害調査、プログラム修正、法改正対応、バージョンアップ、バックアップ確認など、契約に含まれる作業は会社ごとに異なります。
対応時間が平日日中のみなのか、夜間や休日にも対応できるのか、初動時間や復旧目標が定められているかを確認してください。
軽微な帳票変更やマスタ追加が保守内か、都度見積になるかも長期費用へ影響します。問い合わせ回数や作業時間に上限がある場合は、その条件も確認します。
パッケージの場合は、メーカー保守と導入会社の保守が分かれていることがあります。どの窓口へ連絡し、障害原因を誰が切り分けるのかを整理してください。
7. 比較資料
見積比較では、各社の金額を並べるだけでなく、対象範囲、前提条件、成果物、スケジュール、体制、リスクを一覧化した資料を作成します。
初期費用、年間費用、5年間の総費用を分けると、ライセンスや保守費の違いを把握しやすくなります。追加費用が発生し得る項目も別欄に記載してください。
機能ごとに、標準対応、設定変更、カスタマイズ、周辺開発、対象外を整理すると、各社の提案方針を比較できます。
社内稟議では、価格だけでなく、導入期間、業務停止リスク、保守体制、将来の変更しやすさを示すことが重要です。
自社で整理できること・外部に相談すべきこと
社内では、対象業務、利用部署・人数、画面、帳票、データ、外部連携、現行の課題を整理します。各機能について、必須、導入後でもよい、廃止可能の三段階に分けると見積条件をそろえやすくなります。
各社へ同じ資料を渡し、回答期限、見積の有効期限、前提条件の記載方法も統一してください。質問への回答も全社へ共有すると、情報量の違いによる金額差を防げます。
現行仕様が不明、複数部門の要望が対立している、データ移行や外部連携が複雑な場合は、見積依頼前に第三者と現状整理を行う方法もあります。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 各社の見積範囲が異なる | 前提条件の統一 | 総額だけで比較しない |
| 一式表記が多い | 作業内訳・成果物の確認 | 対象外項目を明確にする |
| 要件が固まっていない | 現状調査・要件整理 | 概算と確定見積を区別する |
| 移行データが多い | 移行範囲・回数の確認 | クレンジングと検証費を確認する |
| 帳票・連携が多い | 一覧化と優先順位付け | 件数だけで工数を判断しない |
| 初期費用は安いが保守費が高い | 総保有コストの比較 | 複数年の費用を試算する |
| 判断が難しい | 比較表・評価基準の作成 | 価格以外のリスクも評価する |
この判断表は一般的な目安です。業種、利用人数、拠点数、データ量、帳票数、外部連携、求める保守水準によって適切な判断は変わります。安さだけでなく、対象範囲と将来費用を含めて比較してください。
相談前に準備しておく情報
- 現行システムの概要
- 利用部署・人数・拠点数
- 対象業務と機能の一覧
- 画面・帳票の一覧とサンプル
- 移行対象データと件数
- 外部システムとの連携一覧
- 現在利用しているExcel・Access・CSV
- 保守期限やサポート終了時期
- 現在の課題と改善したい業務
- 必須機能と優先順位
- 想定予算と導入希望時期
- 各社へ提示する見積条件
可能であれば、要件一覧、業務フロー、帳票サンプル、データ件数、連携仕様も準備してください。資料が不足している場合は、現状調査を見積へ含めてもらうことが重要です。
マクティズムの見解
マクティズムでは、基幹システムの見積は、金額表ではなく各社の提案範囲を示す資料だと考えています。同じ総額でも、含まれる調査、移行、テスト、教育、保守が異なれば、導入後のリスクも変わります。
見積を適切に比較するには、各社へ同じ業務範囲、データ量、帳票数、連携数、希望時期を伝え、前提条件をそろえることが必要です。現行と同じという曖昧な依頼では、各社の解釈に差が生じます。
マクティズムでは、見積前に現行業務を確認し、残す機能、標準化する業務、廃止する処理、周辺開発で補う範囲を整理します。そのうえで、機能、費用、期間、体制、保守、追加費用の条件を比較できる形にします。
最も安い見積が最適とは限りません。調査やテストを省いた結果、導入後に追加費用や障害が発生すれば、総コストは高くなります。一方、高額な見積でも、不要な機能や過剰な体制が含まれていれば見直しが必要です。
見積の内訳と前提を整理し、初期費用だけでなく、運用開始後の保守や変更費用まで含めて判断することが、費用対効果の高いシステム導入につながります。
よくある質問
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
