「相場」が一言で言えない理由
「システム保守費用の相場はいくらですか」という質問はよくいただきますが、正直なところ、金額だけを一言で答えることはできません。同じ「販売管理システムの保守」でも、作られた年代、使っている技術、利用者の人数、止まったときの業務への影響によって、必要な作業量がまったく違うからです。
業界では「年間の保守費は、開発費の15%前後」という目安がよく語られます。ただし、これはあくまで業界でよく言われる目安であって、根拠となる統一された基準があるわけではありません。実際には、次のような理由で当てはまらないケースも多くあります。
- 20年前に作ったシステムで、当時の開発費が分からない、または今の物価とかけ離れている
- 開発費は安かったが、古い技術を使っているため対応できる技術者が少なく、保守の単価が高くなる
- 保守費にサーバーの利用料やソフトウェアのライセンス料が含まれているかどうかで、総額が大きく変わる
- ほとんど問い合わせがない安定したシステムなら、目安より大幅に低くても十分なことがある
つまり、相場を気にするよりも、「自社の保守費用が何に対して払われているのか」を分解して把握することのほうが、適正かどうかを判断する近道になります。
他社の金額と比べる前に、まず自社の保守費を項目ごとに分けてみましょう。項目が分かれば、「この部分は払いすぎかもしれない」「この部分は逆に手薄で危ない」という判断ができるようになります。
保守費用の内訳|6つの項目に分けて考える
保守費用は、多くの場合、次の6つの項目に分けて考えることができます。見積書では「保守費 一式」とまとめられていることも多いのですが、その中身はおおむねこの組み合わせです。
1. 障害対応
システムが動かない、エラーが出る、データがおかしいといったトラブルが起きたときに、原因を調べて復旧させる作業です。保守契約の中心となる部分で、「何時から何時まで対応するか」「連絡から何時間以内に着手するか」によって費用が変わります。夜間・休日も対応する契約は、当然ながら高くなります。
2. 問い合わせ対応
「この画面の操作方法が分からない」「月末の締め処理の手順を確認したい」といった、利用者からの質問に答える作業です。障害対応と同じ窓口で受けることが多いですが、件数が多い会社では費用に大きく影響します。電話・メール・チャットなど受付方法によっても負担が変わります。
3. 定期点検・監視
トラブルを未然に防ぐための作業です。たとえば、サーバーのディスク容量の確認、バックアップが正しく取れているかの確認、ログ(システムの動作記録)のチェック、セキュリティ更新の適用などが含まれます。月1回の点検報告書が出てくる契約もあれば、何もしていないのに費用だけ発生している契約もあるため、実施内容を具体的に確認すべき項目です。
4. 軽微な改修
帳票のレイアウト変更、入力項目の追加、消費税率や法改正に伴う小さな修正などです。「月◯時間まで」「年◯件まで」と上限を決めて保守費に含める契約もあれば、毎回別途見積もりになる契約もあります。どこまでが「軽微」なのかの線引きが曖昧だと、後でもめる原因になります。
5. インフラ費
システムを動かすための土台にかかる費用です。社内に置いたサーバー(オンプレミス)なら、ハードウェアの保守契約や、数年ごとの機器更新費用。クラウドを使っているなら、毎月の利用料です。保守会社がクラウド利用料を立て替えて、保守費に上乗せして請求していることもあります。
6. ライセンス費
OS(Windows Serverなど)、データベース(SQL Serverなど)、パッケージソフトの利用権にかかる費用です。年額で払うもの、買い切りのもの、サポート期限が切れた後に延長サポートを有償で購入するものなど、形態はさまざまです。
| 項目 | 主な中身 | 金額を左右するもの |
|---|---|---|
| 障害対応 | 原因調査、復旧、再発防止 | 対応時間帯、着手までの時間、システムの古さ |
| 問い合わせ対応 | 操作方法の回答、手順の確認 | 利用者数、問い合わせ件数、受付方法 |
| 定期点検・監視 | バックアップ確認、容量確認、更新適用 | 点検の頻度、監視の範囲、報告の有無 |
| 軽微な改修 | 帳票・画面の小修正、制度変更への対応 | 含まれる時間・件数の上限 |
| インフラ費 | サーバー保守、クラウド利用料、機器更新 | オンプレミスかクラウドか、構成の規模 |
| ライセンス費 | OS、データベース、パッケージの利用権 | 製品の種類、利用者数、サポート期限 |
手元にある保守の見積書や請求書を、この表の6項目に当てはめてみてください。どの項目にも当てはまらない金額や、どこにも書かれていない項目が見つかったら、それが確認すべきポイントです。
契約形態で変わる費用の性格|定額・チケット・スポット
保守費用は、金額だけでなく「どういう払い方をするか」によっても性格が変わります。中小企業でよく見られるのは、次の3つの形態です。
定額(月額固定)型
毎月決まった金額を払い、契約で定めた範囲の対応を受ける形です。予算が立てやすく、「何かあったらすぐ相談できる」安心感があります。一方で、問い合わせがほとんどない月でも同じ金額がかかるため、安定したシステムでは割高になりがちです。また、契約範囲が曖昧なまま長年続いていると、実際に何をしてもらっているのか誰も説明できない状態になりやすい点にも注意が必要です。
チケット(時間・回数パック)型
「年間20時間分」「10回分」などをまとめて先に購入し、使った分だけ消化していく形です。使い道が見えやすく、必要な分だけ払う感覚に近くなります。ただし、使い切れなかった分の扱い(翌年への繰り越しができるか、失効するか)や、1回の問い合わせで何時間分を消費するのかの計算方法は、契約前に確認しておくべきです。
スポット(都度見積もり)型
トラブルや修正の依頼があるたびに見積もりを取り、その都度払う形です。普段の固定費はかかりませんが、障害が起きたときにすぐ対応してもらえる保証はありません。相手の都合で着手が数日後になることもあり、業務が止まると困るシステムには向きません。
| 形態 | 向いているケース | 注意点 |
|---|---|---|
| 定額型 | 毎日使う基幹システム、止まると業務に直結するもの | 範囲が曖昧だと「払っているだけ」になりやすい |
| チケット型 | 問い合わせや修正が年に数回程度のもの | 余った分の扱い、消費時間の計算方法 |
| スポット型 | 止まっても数日待てる補助的なツール | 緊急時の対応保証がない |
実際には「最低限の監視と障害対応は定額、改修はチケットやスポット」のように組み合わせることも可能です。自社のシステムごとに「止まったら何時間で困るか」を考えると、適した形態が選びやすくなります。
保守費用を押し上げる要因
同じような規模のシステムでも、保守費用に差が出るのには理由があります。自社のシステムが次のどれに当てはまるかを確認すると、見積額が高い理由を理解しやすくなります。
古い技術を使っている
20年以上前の開発言語やデータベースで作られたシステムは、扱える技術者が年々減っています。人が少なければ単価は上がりますし、調査にも時間がかかります。開発した会社自体が「もう対応できない」と保守を断るケースもあります。
設計書やソースコードが残っていない
ソースコード(システムの設計図にあたるプログラムの文章)や仕様書がないと、ちょっとした修正でも「まず中身を調べる」作業が必要になり、そのぶん費用が増えます。担当者の頭の中にしか情報がない状態も同じです。
サポート期限の切れたOSやソフトの上で動いている
OSやデータベースのメーカーサポートが終わると、セキュリティ更新が提供されなくなります。たとえばWindows Server 2016は2027年1月12日(日本時間)に延長サポートが終了し、その後は有償の延長セキュリティ更新プログラム(ESU)を最大3年購入する選択肢があります。SQL Server 2016も2026年7月14日に延長サポートが終了しており、ESUの対象です。こうした延長費用や、期限切れの環境を慎重に扱う手間が保守費に反映されます。最新の期限は、Microsoftの公式ライフサイクルページで確認してください。
対応時間・対応速度への要求が高い
「24時間365日対応」「1時間以内に駆けつけ」といった条件は、技術者を待機させておく必要があるため高額になります。本当にその水準が必要か、業務の実態と照らし合わせて見直す価値があります。
改修が積み重なって複雑になっている
長年の部分的な修正で、どこを触るとどこに影響するのか分からない状態になっているシステムは、修正のたびにテストの範囲が広がり、費用がかさみます。
保守費が高いと感じても、単純に「安い会社に乗り換える」だけでは解決しないことがあります。費用が高い原因が「古い技術」や「資料がない」ことにある場合、どの会社に頼んでも調査の手間はかかります。原因を見極めたうえで、改善(資料の整備、環境の更新)と合わせて考えることが大切です。
見積書の読み方|確認すべきポイント
保守の見積書を受け取ったら、金額の大小を見る前に、次のポイントを確認してください。分からない点は遠慮なく保守会社に質問して構いません。質問に具体的に答えてくれるかどうかも、相手を見極める材料になります。
- 「保守費 一式」ではなく、作業項目ごとに金額や内容が分かれているか
- 対象となるシステム・機器・ソフトウェアの範囲が明記されているか
- 対応時間帯(平日日中のみか、夜間・休日もか)が書かれているか
- 障害の連絡から着手・復旧までの目標時間が書かれているか
- 定期点検の頻度と、報告書が出るかどうかが書かれているか
- 軽微な改修が含まれるか、含まれる場合の上限(時間・件数)はどれくらいか
- 「軽微」と「別途見積もり」の線引きが説明されているか
- クラウド利用料やライセンス料が含まれているか、別請求か
- チケット型の場合、余った分の繰り越しや失効のルールがあるか
- 契約期間、自動更新の有無、解約の申し出期限が書かれているか
- 値上げの条件や、改定の通知時期が決められているか
- 契約終了時に、ソースコードや設定情報・資料を引き渡してもらえるか
「一式」表記には中身を確認する
「システム保守 一式 月額◯円」とだけ書かれた見積書は珍しくありません。これ自体が悪いわけではありませんが、中身を聞かないまま契約すると、後で「それは保守の範囲外です」と言われる原因になります。前の章の6項目のどれが含まれているのか、一覧にして回答してもらいましょう。
毎月の作業報告を求める
定額型の契約では、「今月は何をしたのか」を月次で報告してもらうことをおすすめします。問い合わせ件数、対応時間、点検結果が分かれば、翌年の契約更新時に「この内容ならチケット型の方が合っている」「この範囲は減らせる」といった判断ができます。
契約終了時の引き継ぎ条件を必ず確認する
見落とされがちですが、もっとも重要な項目のひとつです。ソースコードや設定情報が保守会社の手元にしかなく、契約終了時に渡してもらえない条件になっていると、他社への乗り換えが事実上できなくなります。そうなると、値上げを提示されても受け入れるしかありません。契約書の条文の解釈に不安がある場合は、弁護士など専門家に確認することも検討してください。
保守費用を適正にするための進め方
最後に、いまの保守費用を見直したいときの進め方を、手順として整理します。いきなり保守会社に値下げ交渉をするのではなく、まず自社側で現状を把握することから始めます。
手順1:保守しているシステムを一覧にする
販売管理、生産管理、勤怠、会計、社内の共有サーバーなど、保守費を払っているものを一覧にします。それぞれについて、保守会社名、月額・年額、契約期間、更新日を書き出すだけでも、「同じような内容で二重に払っていた」といった発見があることがあります。
手順2:過去1年の利用実績を集める
問い合わせを何回したか、障害は何回起きたか、改修を何件頼んだかを振り返ります。保守会社に対応履歴を出してもらえる場合は依頼しましょう。たとえば社員30名の卸売業で、年間の問い合わせが数件しかない販売管理システムに手厚い定額保守をかけている、といった状況が見えてくることがあります。
手順3:「止まったらどれだけ困るか」で優先度をつける
製造業の生産管理システムのように、止まると出荷が止まるものは、対応速度を重視した契約が必要です。一方、月に一度しか使わない集計ツールなら、スポット対応でも十分かもしれません。システムごとに必要な保守の厚さを決めると、費用のかけ方にメリハリがつきます。
手順4:費用が高い「原因」に手を打つ
サポート期限切れの環境、資料のないシステム、担当者しか分からない部分など、保守費を押し上げている原因が分かったら、それを解消する計画を立てます。たとえば資料を整備するだけでも、調査にかかる時間が減り、将来の保守費や乗り換えのしやすさが変わってきます。
手順5:更新時期の数か月前から相談を始める
契約の自動更新日の直前に見直しを始めても、比較や交渉の時間が足りません。更新の3〜6か月前を目安に、現在の保守会社への条件確認や、他社への相談を始めると、落ち着いて判断できます。
保守費用の見直しは「下げること」だけが目的ではありません。実態に対して手薄すぎる保守(バックアップの確認がされていない、障害時の連絡先が不明など)が見つかれば、むしろ費用をかけるべき部分です。払う金額と守られる範囲のバランスを取ることが目標です。
まとめ
- 保守費用の「相場」は一言では決まらない。「開発費の15%前後」は業界でよく言われる目安にすぎない
- 保守費は「障害対応・問い合わせ対応・定期点検・軽微改修・インフラ費・ライセンス費」の6項目に分けて把握する
- 定額・チケット・スポットの契約形態は、システムが止まったときの影響の大きさで選ぶ
- 古い技術、資料不足、サポート期限切れの環境は、保守費を押し上げる原因になる
- 見積書は「一式」の中身、対応時間、改修の範囲、契約終了時の引き継ぎ条件を必ず確認する
- 見直しは自社の現状把握から始め、更新時期の数か月前に動き出す