「今年から保守料を2割上げます」という連絡が、長年付き合ってきた保守会社から届く。値上げの根拠を聞いても「人件費の高騰」としか説明されず、妥当なのか判断がつかない。かといって、他社に切り替えようにも、古い基幹システムの中身を分かっている会社が他に見つかるかも分からない。毎年の保守料を払い続けながら、こうしたモヤモヤを抱えている担当者は少なくありません。
結論から言うと、基幹システムの保守料は「内訳」を分解して見なければ妥当性を判断できません。相場のパーセンテージだけを鵜呑みにすると、本来削れる費用まで払い続けることになります。そしてもうひとつ、保守料の問題の先には「サポート終了（保守切れ）」という、より大きな判断が待っています。値上げの是非だけを見ていると、この根本的な判断を先送りにしてしまいがちです。この記事では、保守料の内訳の確認方法と値上げ交渉の論点、サポート終了時に取れる選択肢を、発注側の目線で整理します。
この記事のポイント
- 保守料の相場は年間契約額（初期開発費）の15〜25%が目安だが、内訳を分解しないと妥当性は判断できない
- 値上げの打診には「何がどれだけ増えたか」を項目別に説明させることが交渉の起点になる
- 基幹システムは老朽化・属人化により保守費が高止まりしやすい構造がある
- サポート終了後は延命・第三者保守・刷新の3択から選び、保守契約の見直しにつなげる
目次
基幹システムの保守料は妥当か？相場と内訳の見方
保守料が高いか安いかを議論する前に、まず押さえておきたいのは「相場は目安にしかならない」ということです。同じ基幹システムでも、保守範囲やサポート時間帯、稼働年数によって適正な金額は変わります。相場を知った上で、自社の契約がその内訳のどこに当てはまるのかを確認する作業が欠かせません。
保守料の相場は年間契約額の15〜25%が目安
一般的な目安として、システムの保守料は初期の開発費に対して年間15〜25%程度が業界標準とされています。24時間365日対応やオンサイトでの緊急対応を求める場合は、これより高くなるのが通常です。基幹システムのように止まったときの業務影響が大きいシステムでは、上限に近い水準で契約しているケースも珍しくありません。
ただし、この15〜25%という数字は、あくまで新規契約時の目安です。長年運用してきた基幹システムでは、当初の契約からいつの間にか範囲が広がっていたり、逆に使っていない保守項目にまで払い続けていたりすることがあります。相場の数字を確認したら、次は自社の契約が何にいくら払っているのかを、内訳レベルで洗い出す必要があります。
保守料の内訳を4項目で確認する
保守料の見積もりは、大きく「運用監視」「ハードウェア保守」「ソフトウェア保守」「サポート対応」の4項目に分解できます。運用監視は稼働状況を常時確認する費用、ハードウェア保守は物理機器の故障対応、ソフトウェア保守はOSやミドルウェアの更新対応、サポート対応は問い合わせやトラブル時の窓口対応です。
この4項目のうち、自社が実際にどれだけ使っているかを棚卸ししてみてください。たとえば夜間・休日のオンサイト対応を契約に含めているのに、過去数年で一度も使っていないなら、その部分は縮小の余地があります。逆に、障害対応の窓口が平日日中のみなのに、実際には夜間のトラブルで自社担当者が対応に追われているなら、契約と実態が合っていないサインです。内訳が見積書に明記されていない場合は、保守会社に項目別の内訳を出すよう依頼してください。
金額の目安としては、運用監視が月額5万〜20万円程度（規模により35万円を超えることもある）、ハードウェア保守が月額2万〜10万円程度、サポート対応が月額3万〜15万円程度というレンジで語られることが多く、24時間対応やオンサイト保証を足すとさらに上乗せされます。自社の契約金額をこの4項目に割り振ってみて、どこか一項目だけ突出して高い場合は、その項目を重点的に問い合わせる対象にしてください。
値上げを打診されたときに確認すべきこと
保守会社から値上げの連絡が来たら、まず確認すべきは「何が」「どれだけ」増えたのかという内訳レベルの説明です。「物価上昇のため」といった大枠の理由だけで金額を受け入れず、人件費なのか、部材費なのか、対応範囲の拡大なのかを項目ごとに聞いてください。理由が明確に説明できない値上げは、交渉の余地があります。
交渉の材料になるのが、他社の相見積もりや、業界の相場データです。ただし、旧環境に対応できる保守会社は限られるため、相見積もりを取ること自体が難しい場合もあります。その場合でも、契約範囲を見直して不要な項目を削る、複数年契約に切り替えて単価を下げる、といった交渉の選択肢は残っています。値上げ幅が大きい場合は、次で触れる第三者保守への切り替えも視野に入れて交渉するほうが、保守会社側も現実的な着地点を探りやすくなります。
交渉の場では、金額の上げ下げだけでなく、保守レベルを段階分けする提案も有効です。たとえば、すべての機能を同じ手厚さで保守するのではなく、業務停止に直結する中核機能だけを最優先の保守対象にし、周辺機能は一段階落とした対応でよしとすれば、全体の保守料を抑えられる場合があります。どの機能を止められないかを事前に整理しておくと、この段階分けの交渉がスムーズに進みます。
保守費が高止まりする基幹システム特有の要因
基幹システムの保守費は、他のシステムに比べて高止まりしやすい構造的な要因を抱えています。ひとつは老朽化です。稼働年数が古いシステムほど、部品の調達や技術的な対応が難しくなり、保守側のコストが上がります。もうひとつは属人化です。仕様を理解している技術者が限られていると、保守会社は代替要員を確保しにくく、その希少性が価格に転嫁されます。
この2つの要因は、値上げ交渉だけでは根本的に解決できません。技術者が本当に減っているなら、保守会社を変えても同じ理由で高くなる可能性があります。値上げの理由が「対応できる人が業界全体で減っているから」である場合、これは一時的な交渉では覆せない構造的な変化です。目先の値上げに対応しつつ、並行して「あと何年この保守体制で持つのか」という長期的な視点を持っておくことが、次に説明するサポート終了への備えにつながります。
属人化の度合いを測る簡単な方法は、保守会社に「この基幹システムを担当できる技術者は何人いますか」と直接聞いてみることです。答えが1〜2人であれば、その技術者が退職・異動した瞬間に保守の質が大きく落ちるリスクを抱えていることになります。人数が少ないと分かった時点で、次の保守体制をどうするかの検討を始める合図と捉えてください。担当者が1人しかいない状態は、値上げ交渉の材料にもなります。相手にとってもリスクである以上、体制強化や引き継ぎ計画の提示を求める根拠になるからです。
サポート終了で基幹システムの保守料はどうなるか
保守料の話を突き詰めていくと、いずれ「メーカーや開発会社が保守を打ち切る」というサポート終了の局面に行き当たります。ここでは、サポート終了後に取れる選択肢と、それぞれの向き不向きを整理します。
サポート終了後に取れる3つの選択肢
サポート終了（EOL・EOSL）を迎えた基幹システムには、大きく3つの選択肢があります。ひとつ目は、保守なしのまま使い続ける延命です。新規投資を避けられますが、障害発生時に長期停止するリスクとセキュリティ上の懸念を抱えたまま運用することになります。
ふたつ目は、メーカーや従来の保守会社以外が提供する第三者保守への切り替えです。同等以上の保守水準を、従来より抑えた費用で受けられる場合があり、システムを延命させながらコストを見直す選択肢として近年広がっています。みっつ目は、システムそのものを作り替える刷新です。根本的な解決になりますが、費用も期間も最も重くなります。
選択肢ごとの向き不向きと費用感
どれを選ぶべきかは、あと何年その基幹システムを使うつもりかで変わります。1〜2年以内に刷新を予定しているなら、無理に投資をせず延命でつなぐ判断もあり得ます。ただし、障害時の停止が業務に致命的な影響を与えるなら、延命だけでその期間を乗り切るのはリスクが高すぎます。
3〜5年程度は今のシステムを使い続ける前提であれば、第三者保守への切り替えが有力な選択肢になります。従来の保守会社が撤退・値上げしたタイミングで検討されることが多く、複数の第三者保守会社から見積もりを取り、対応可能な範囲と実績を比較して選びます。刷新の判断基準そのものについては、基幹システムのリプレイスとは？進め方と発注側の判断基準で詳しく整理しています。すでに移行方式まで検討している場合は、基幹システムの移行方式はどう選ぶ？3つの選択肢と費用の見方もあわせて確認してください。
第三者保守を検討する際に見落とされがちなのが、対応できる範囲の境界線です。メーカー保守と違い、第三者保守は基本的にハードウェアの保守が中心で、ソフトウェアのバージョンアップやライセンス関連の対応は含まれないことが多くあります。「保守費が下がったのに、いざというとき対応してもらえなかった」という事態を避けるため、契約前にハードウェア・ソフトウェアそれぞれの対応範囲を明確にし、書面で確認しておく必要があります。また、第三者保守はメーカーの正式なサポートではないため、法改正対応やセキュリティパッチの提供が止まっている状態は変わりません。あくまで延命のための選択肢であり、恒久的な解決策ではないことを踏まえたうえで、次の刷新までの時間を確保する手段として位置づけてください。
保守契約を見直す・切り替えるときに確認すること
保守会社を切り替える、あるいは第三者保守を導入する際は、対応範囲の空白を作らないことが最優先です。旧保守契約の終了日と新契約の開始日を必ず重ねて設定し、切り替えのタイミングでサポートが途切れる期間を作らないようにしてください。切り替え直後は、新しい保守会社がまだシステムの癖を把握しきれていない時期でもあるため、最初の数か月は障害対応の記録を細かく残しておくと、後々のトラブルシューティングが早くなります。
また、切り替え先の保守会社が、自社の基幹システムの言語や機種（RPG・COBOL・特定のオフコン機種など）にどこまで対応した実績があるかも、契約前に具体的な事例で確認する必要があります。「対応可能」という言葉だけでなく、過去にどんな障害にどう対応したかを聞くと、実力が見えてきます。見積もりの前提条件がそろっているか不安な場合は、見積もりの危険サインを見抜く60項目チェックシートを使うと、抜けやすい項目をまとめて点検できます。
