DX

保守費が妥当か分からない業務システム――内訳・相場・打ち手の順で見直す

目次

毎月届く保守の請求書を眺めて、「この金額、本当に妥当なんだろうか」と思う。けれど、内訳の説明を求めてもよく分からない返事が返ってくるか、「全部込みです」と言われて終わってしまう。結局その月もそのまま支払いを通す。こうした場面は少なくありません。

高い気がする。でも、何を基準に高いと言えるのかが分からない。そのため交渉に踏み込めず、ベンダーを替える判断にも踏み切れない。システム保守の費用の問題が厄介なのは、金額そのものよりも、判断材料が手元にないことにあります。

保守費の中身を分解する視点、業界の相場感の読み方、ベンダーロックインを抜けるための現実的な打ち手を、開発と保守の両方を手がける立場から順に整理していきます。読み終わるころには、次の打ち合わせで何を聞けばよいかが見えているはずです。

なぜ「保守費が高い気がする」のに動けないのか

「高い気がする」という感覚は、たいてい正しい入り口です。ただ、そこから先に進めない理由がいくつか重なっています。

まず、保守費の中身が分かれていないため、何にいくらかかっているのかが見えません。請求書に「システム保守料 月額○○円」とだけ書かれていて、内訳がない。これでは交渉のしようがありません。

次に、相場が手元にありません。「同業他社はいくら払っているのか」「自社の規模なら何円が妥当なのか」が分からないので、提示された金額を基準なしに飲み込むしかなくなります。

そしてもう一つ、ベンダーを替えづらいという構造的な事情があります。今のベンダーしか中身を知らないため、別の会社に乗り換えようとしても引き受け手がいない、あるいは引き継ぎに別途費用がかかる。経済産業省が2018年に公表したDXレポートでも、ベンダーがいなければシステムの修正もデータの取り出しもできないベンダーロックインの状態が、日本企業の構造的な課題として指摘されています（出典: 経済産業省「DXレポート 〜ITシステム『2025年の崖』克服とDXの本格的な展開〜」）。

「高い気がする」段階で動けないのは、ベンダーが不当に儲けようとしているという単純な話ではなく、内訳・相場・代替手段の3つが揃わないと判断ができないからです。逆に言えば、この3点を順に埋めていけば、判断は前に進みます。

保守費に含まれる5つの中身

最初に手をつけたいのは、内訳を見える化することです。システム保守の費用は、おおまかに次の5つの要素に分解できます。請求書の合計額だけを見ても判断は進みませんが、この5つに照らすと「どこにいくら払っているのか」の輪郭が見えてきます。

  • インフラ運用費: サーバー・クラウドの利用料、監視ツールの利用料、バックアップの保存費など。月額が固定で読みやすい部分。
  • アプリケーション保守費: 軽微な不具合修正、OSやミドルウェアのアップデート追従、ライブラリの脆弱性対応など、コードに手を入れる作業の人件費。
  • 問い合わせ対応費: ヘルプデスク窓口、業務時間中の質問・操作支援への対応工数。月によって波がある部分。
  • セキュリティ対応費: 脆弱性情報のウォッチ、パッチ適用、SSL証明書の更新、不正アクセスの検知対応など。
  • 待機費（オンコール費）: 障害が起きたときに即応するための、技術者の待機時間に対する費用。SLAの厳しさで金額が変わる。

このうち、月額として固定されやすいのはインフラ運用費と待機費です。一方、アプリケーション保守費と問い合わせ対応費は、本来は工数に応じて変動するはずの部分です。にもかかわらず、契約上は全部まとめて月額固定になっていることが多く、ここが「何に払っているか分からない」の正体になりがちです。

近年は、この構造を切り分けて、アプリケーション保守費や問い合わせ対応費を**実働ベース（従量課金）**で持つ契約形態も出てきました。実際に動いた時間に対してだけ請求し、使わない月は費用がかからない、という考え方です。月額固定の安心感とは別の選択肢として、見直しの議論をするときに知っておくと、契約の組み直し方の幅が広がります。

まずは現在の契約書と請求書を並べ、この5つの内訳のうち、自社がどれを買っているのかを書き出してみてください。書けない項目があるなら、それは契約上明確になっていないということ。そこが見直しの起点になります。

業界の相場感――「開発費の○％」をどう読むか

内訳が見えたら、次は相場との照合です。

業界では、年間保守費を「初期開発費の何%」で示す表現がよく使われます。複数の開発会社が公表している目安を並べると、おおよそ次の幅に収まります。

両者を合わせると、おおむね年間保守費 ＝ 開発費の10〜20%あたりが、業界で語られている参考線です。ただし、これはあくまで参考線で、契約に含まれる範囲（24時間対応か業務時間内か、改修工数を月何時間まで含むかなど）で大きく振れます。

開発費1,000万円のシステムなら、年間100〜200万円、月額にして8〜17万円あたりが目安になります。これを大きく超えているなら、超過分が何に対しての支払いなのかを説明できるかどうかを確認したいところです。

ここで気をつけたいのは、相場より高いこと自体が悪ではないという点です。たとえばSLAが厳しい（夜間障害も30分以内に一次応答する等）契約なら、相場の上限を超えてもおかしくありません。逆に、サポートをほとんど使っていないのに相場の上限を払っているなら、契約と実態がずれている可能性が高いです。相場は、契約内容とセットで読みます。

保守費の妥当性を見るための3つの判断軸

相場と照らしたうえで、最終的に「自社にとって妥当か」を見るための判断軸を3つに整理します。

1. 対応範囲が契約書に書き切られているか

最初に確認したいのは、何が保守料に含まれていて、何が含まれていないかが文書で明確になっているかどうかです。

  • 月何時間までの作業が含まれるのか
  • 「軽微な改修」と「機能追加」の線引きはどこか
  • 一次応答までの時間、復旧までの時間（SLA）はどう定義されているか
  • 営業時間外の対応は含まれるのか、別料金か

ここが曖昧なまま「全部込み」で契約されていると、ベンダー側は安全側に倒して見積もりを膨らませがちです。逆に、対応範囲を絞れば、保守料を下げる余地が出てきます。

2. 作業ログが共有されているか

毎月、何にどれだけの工数を使ったかが、報告書として共有されているかどうかも重要な判断軸です。

報告書がないか、あっても「今月も問題なく稼働しました」程度の一行で済まされている場合、実際の作業量と支払額の対応関係が見えません。健全な保守契約では、月次で対応一覧（チケット番号・内容・工数）が出てきます。これがないなら、まず月次レポートを出してもらうところから始めるのが現実的です。

3. 古い技術コストが妥当に乗っているか

3つ目は、システムの技術スタックの古さに対する人件費の上乗せです。

10年以上前のPHPやJava、サポートが切れたOSの上で動いている業務システムは、扱えるエンジニアが減っているため、保守の単価が現役技術より高くなりやすい傾向があります。これ自体は構造的な事情で、ベンダー側が悪意で高くしているわけではありません。

ただし、上乗せが大きいなら、「いつまでこの技術で維持するのか」「マイグレーションするとしたらいつ・いくらか」をベンダーに尋ねる材料にはなります。保守料の見直しは、技術選択の見直しと地続きです。技術スタックの古さと保守費の関係を整理する考え方は、システムの保守はなぜ必要か｜放置で起きる3つのことでも触れています。

この3つの判断軸を表にすると、次のように整理できます。

妥当な方向（健全な契約）見直しの方向（要確認）
対応範囲が契約書に明示されている「全部込み」で線引きが書かれていない
月次で作業ログ・工数が共有される報告書が出ないか、ごく形式的
技術スタックと保守単価の関係が説明できる高単価の理由が「昔からそうだから」
SLAの水準と料金が対応しているサポートをほぼ使っていないのに高料金

「高い」の前に確認したい、保守契約書の3か所

判断軸が見えても、実際に動くためには契約書を読み直す必要があります。経営者・情シス担当者がまず確認したい箇所は次の3つです。

1. 契約期間と解約予告期間

多くの保守契約は1年単位の自動更新で、解約には3か月から6か月前の予告が必要です。「来月から替える」が物理的にできない期間がある、ということです。見直しを始めるなら、解約予告期間を逆算して動き出します。

2. 仕様書・ソースコード・データの帰属

契約書のどこかに、開発成果物（ソースコード・設計書・データベース構造）の著作権や利用権の取り決めがあるはずです。ここが「ベンダーに帰属」となっていると、別の会社へ引き継ぐとき、コードを渡してもらえない、あるいは別途買い取り費用が発生する可能性があります。

3. SLA（サービスレベル合意）の水準

応答時間・復旧時間・稼働率の取り決めです。たとえば「稼働率99.9%、一次応答1時間以内」と書かれていれば、それは24時間体制の待機を前提とした料金になります。自社の業務に対して過剰なSLAになっていないか、ここで確認します。逆にSLAが書かれていない契約は、いざ障害が起きたときに「ベストエフォート」で終わってしまう可能性があり、これも見直しの対象です。

この3か所を確認するだけで、「いつから動けるか」「替えるとき何が引き継げるか」「今のサービス水準と料金は釣り合っているか」が分かります。保守費の交渉に入る前の準備として、まず手元の契約書を取り寄せてください。

それでも妥当性が判断できないときの第三者の使い方

ここまでの内訳・相場・契約書の確認をやってもなお、「自社の場合はどう判断すべきか」が見えないことはあります。技術の中身が絡む話なので、経営者・情シス担当者だけで結論を出しきれないのは当然です。

そのときに現実的なのが、別の開発会社にセカンドオピニオンを依頼するという選択肢です。今のベンダーに直接ぶつける前に、第三者にソースコードと契約書、月次の作業ログを見てもらい、「この内容で、この金額は妥当か」を診断してもらう。これは弊社にも実際にご相談いただく依頼の形です。

セカンドオピニオンを使うときに気をつけたいのは、相談先に「全面リプレースしかない」と言われない会社を選ぶことです。診断の結果、保守を別会社に引き継ぐ方が良い場合もあれば、現在のベンダーとの契約を整理し直す方が良い場合もあります。どちらに転んでも答えが出せる相手に頼むのが、結果として一番遠回りになりません。

引き継ぎ先としての開発会社の選び方は、社内SEが退職したら？システム保守を任せる開発会社の選び方でも整理しています。保守の引き取りを前提にしたときに、何を見て会社を選ぶかの観点です。

弊社にご相談いただくケースでは、契約上のSLA水準と実際に発生している障害頻度が乖離していて、契約条件を整理し直すだけで負担が見直せる余地が見つかることもあります。保守費の削減という言葉だけが先に立つと「ベンダーを叩く」話になりがちですが、実際は契約と実態のずれを点検するだけで前に進むことも少なくありません。契約条件を整理する余地があるかを点検することが、まず現実的に動ける一歩です。

保守をいま放置するとどうなるか、保守の必要性をもう一段深く考えたい方は、中小企業がシステム保守を後回しにできない3つの理由や自社システムの老朽化リスクとは？中小企業がとるべき3つの対策とコストもあわせてお読みください。

なお、見積もり全体が高すぎる、リプレース提案が一択で出てきている、というご相談は業務システムのリプレース見積もりが高すぎる時の妥当性を見極める3つの基準で別途整理しています。保守費の見直しと一時費用の見直しは、判断の軸が違うので分けて考えると整理しやすいです。

まとめ

システム保守の費用が妥当かどうかは、金額だけを見ても判断がつきません。確認したいのは、内訳が5つの要素に分解できているか、相場の参考線（開発費の10〜20%）と契約内容を照らしたときに辻褄が合うか、そして契約書の対応範囲・成果物の帰属・SLAの3か所がきちんと書かれているか、という点です。

ここまでを自社で揃えたうえで、判断がつかなければ第三者の診断を入れる。順序としてはこれが、無理なく動ける道だと考えています。「保守費が高い気がする」という感覚を、判断と打ち手につなげるための材料にしていただければと思います。

業務システムの保守費の見直しや、引き継ぎ先の検討でお困りの方は、弊社の以下のサービスもご検討ください。料金は月額固定ではなく、実際に動いた分だけ請求する実働ベース（従量課金）です。使わない月は費用が発生しません。

システムレスキュー

開発会社が廃業した、担当者が退職した、仕様書が残っていない。そんな業務システムを引き取り、保守・改修を継続します

/service/system-rescue/

関連記事