毎月の口座から、同じ開発会社への保守費が自動で引き落とされていく。金額を見るたびに「これは妥当な金額なのだろうか」と感じつつも、比較する材料がないまま今年も更新の稟議を通してしまった——そんな状態に心当たりはないでしょうか。総務や経理と兼務でシステム担当を任されている方の多くは、保守費という支出そのものを疑う機会がなく、請求書が来たら払う、契約更新の時期が来たら更新する、という受け身の運用を続けています。
先に断っておきたいのは、この記事は「保守費の相場は◯万円です」という金額を示す記事ではないということです。保守費は、対応範囲・対応時間・システムの複雑さ・利用人数といった複数の変数によって、同じような規模の会社でも数倍の開きが出ます。根拠のない相場観を示すことは、かえって判断を誤らせるリスクがあると考えています。
その代わりにこの記事で扱うのは、保守費という金額を実際に左右している構造そのものです。何が保守費を高くし、何が保守費を下げる余地になるのか。今払っている保守費の内訳を、どう分解して見直せばよいのか。見直しを切り出すとき、開発会社とどう対話すればよいのか。これらを一次情報と実務的な視点から整理します。読み終える頃には、「相場を知らないから判断できない」状態から、「自社の保守契約のどこを見直せばよいかが分かる」状態に変わっているはずです。
この記事で分かること
毎月支払っている保守費が高いのか妥当なのかを判断するために、金額そのものではなく、保守費を左右する構造を理解する記事です。保守費に含まれる作業の中身、対応範囲やSLAといった契約条件が金額に与える影響、契約形態による違い、そして実際に見直しを進める際の具体的な手順とチェックポイントまでを解説します。相場情報がないまま「なんとなく高い気がする」で止まっている状態から、自社の契約書と請求内容を材料に、見直すべきポイントを具体的に指させる状態を目指します。
なぜ保守費の「相場」を示せないのか
まず、なぜこの記事が具体的な金額を示さないのかを説明しておきます。保守費は、次のような要素の組み合わせによって決まります。
- 対応範囲：不具合修正だけなのか、軽微な仕様変更まで含むのか、問い合わせ対応まで含むのか
- 対応時間・SLA：平日日中のみの対応か、24時間365日対応か、障害発生から一次対応までの目標時間は何時間か
- システムの複雑さと規模：利用人数、機能数、連携している外部システムの数
- 契約形態：月額固定なのか、都度作業に応じた実費精算なのか、その組み合わせなのか
- 開発会社の体制：専任担当がつくのか、複数案件を掛け持ちする担当者が窓口になるのか
これらの組み合わせは会社ごとに無数のパターンがあり、同じ「顧客管理システムの保守」という契約でも、対応範囲が広く24時間対応を含む契約と、平日日中のみで不具合修正のみに絞った契約とでは、金額が数倍単位で変わって当然です。したがって、「保守費の相場は月◯万円」という情報をそのまま自社に当てはめることは、実態を見誤る原因になります。
この記事で目指すのは、相場という「他社の数字」を探すことではなく、自社の保守契約が上記のどの組み合わせに位置しているかを言語化し、その組み合わせが妥当なコストに見合っているかを自社の判断で評価できるようにすることです。保守費の内訳や費用感の目安については、システム保守費用の相場でも取り上げられているため、あわせて参考にすると自社の水準感をつかみやすくなります。
保守費に含まれている作業の中身を分解する
見直しの第一歩は、今支払っている保守費が、具体的にどんな作業の対価なのかを分解することです。「保守費」とひとくくりに請求されていても、実際にはいくつかの異なる性質の作業が含まれています。
障害・不具合対応
システムが正常に動作しなくなった場合の原因調査と修正です。多くの保守契約で最も重視される項目であり、SLA（サービス品質保証）（対応開始までの目標時間）が明記されているかどうかで、実際に障害が起きたときの対応スピードが変わります。
問い合わせ対応
「この操作の仕方が分からない」「このエラーメッセージの意味は」といった、不具合とは言い切れない利用者からの質問への対応です。保守契約によっては、これが無償の範囲に含まれる場合と、別途相談料が発生する場合があります。
軽微な仕様変更・改修
「この画面の表示項目を1つ増やしてほしい」といった小規模な変更要望への対応です。契約書に「軽微な変更は保守費の範囲内」と明記されている場合と、すべて別途見積もりになる場合とで、実質的な保守費の価値が大きく変わります。
セキュリティ対応・パッチ適用
OS・ミドルウェア・利用しているライブラリの脆弱性情報を監視し、必要に応じてパッチを適用する作業です。これはパッチマネジメントと呼ばれる領域で、保守契約に明記されていないと、実際には行われていないケースも珍しくありません。
バックアップの取得・確認
定期的なデータバックアップの取得と、リストア（復元）できる状態を保っているかの確認です。バックアップを取得しているだけで、実際に復元できるかを確認していない契約も見受けられます。
見直しの第一歩は、契約書または過去の請求書・仕様書を見返し、上記5項目のうちどれが「保守費の範囲内」として明記されているかをリストアップすることです。明記されていない項目は、実際には別料金で対応してもらっているか、あるいはそもそも対応されていない可能性があります。
保守費を左右する5つの構造要因
ここからは、保守費という金額を実際に押し上げたり抑えたりしている構造的な要因を、5つに分けて解説します。
要因1：対応範囲の広さ
前章で分解した5つの作業のうち、保守費に何が含まれているかは、そのまま金額に直結します。障害対応のみの契約と、問い合わせ対応・軽微な改修・パッチ適用・バックアップ確認まですべて含む契約とでは、後者の方が高額になるのが自然です。ここで重要なのは、「高い＝不当」ではなく、「自社が本当に必要としている範囲と、契約している範囲が一致しているか」という視点です。
たとえば、社内に一定のITリテラシーを持つ担当者がいて、簡単な問い合わせ程度は自己解決できる場合、問い合わせ対応まで含む手厚い保守契約は過剰である可能性があります。逆に、システム担当が総務との兼任で対応に割ける時間が少ない場合は、対応範囲の広い契約の方が結果的に安く済むこともあります。
要因2：SLA（対応時間の保証水準）
SLA（対応時間の保証水準）は保守費に大きく影響する要因です。「障害発生から30分以内に一次対応を開始する」といった保証水準を求めるほど、開発会社側は当番体制や緊急対応要員を確保する必要があり、コストが上がります。逆に「翌営業日中の対応で構わない」という条件であれば、開発会社は既存の体制の中で対応でき、コストを抑えやすくなります。
自社のシステムが止まった場合、どれくらいの時間、業務が止まっても許容できるかを考えてみてください。基幹システムのように止まると即座に業務が停止するシステムと、月次でしか使わない集計システムとでは、必要なSLAの水準がまったく異なります。すべてのシステムに同じ水準のSLAを求める必要はありません。
要因3：契約形態（請負契約か準委任か、月額固定か実費精算か）
保守契約は、大きく分けて「月額固定制」と「都度精算制（実費精算）」の2つの料金体系があります。
| 料金体系 | 特徴 | 向いているケース |
|---|---|---|
| 月額固定制 | 対応範囲内であれば作業量にかかわらず定額 | 障害・問い合わせの発生頻度が読みにくいシステム |
| 都度精算制 | 発生した作業ごとに工数×単価で請求 | 障害がほとんど発生しない安定稼働システム |
| 併用型 | 基本料金＋一定範囲を超えた作業を実費精算 | 上記2つの中間的な特性を持つシステム |
月額固定制は「使わなかった月も同額を払う」構造のため、障害がほとんど発生しない年でも一定額を払い続けることになります。一方で、突発的な障害が多い年には割安になる可能性があります。都度精算制はその逆で、平常時は安く済みますが、大きな障害が続くと想定外の費用がかさむことがあります。自社のシステムがどちらの傾向に近いかを、過去の障害発生履歴から振り返ってみる価値があります。
なお、保守業務が準委任契約（準委任契約）として結ばれているのか、個別の改修が都度請負契約として発注される形なのかによっても、費用の発生構造が変わります。準委任契約は「一定時間、対応可能な状態を確保してもらうこと」自体に対価が発生する形が一般的で、請負契約は「成果物の完成」に対して対価が発生します。保守契約は前者の準委任契約であることが多いため、「今月は何も起きなかったから払いたくない」という発想はそもそも契約の性質と噛み合わない点も理解しておくとよいでしょう。
要因4：システムの複雑さと利用規模
利用人数、画面数、外部システムとの連携数が増えるほど、障害発生時の原因調査に必要な工数が増え、保守費も上がりやすくなります。特に、複数の外部サービスとAPI連携しているシステムは、自社のシステム側に問題がなくても、連携先の仕様変更によって不具合が発生することがあり、原因の切り分けに時間がかかります。
また、開発から年数が経過したレガシーシステムは、ドキュメントが整備されていなかったり、当時の担当者が退職していたりすることで、同じ作業でも調査に時間がかかりやすく、結果的に保守費が高止まりする傾向があります。この場合、保守費そのものを値切る交渉よりも、システムの作り直しや部分的な刷新を検討した方が、中長期的なコストは下がる可能性があります。
要因5：ベンダーの体制（専任か掛け持ちか、1社独占か複数社分散か）
開発会社側が自社専任の担当者を置いているか、複数の顧客案件を掛け持ちする担当者が窓口になっているかによっても、費用構造は変わります。専任体制はコストが高くなりやすい一方、自社のシステムに関する理解が深まりやすく、対応の質とスピードが上がる傾向があります。
また、保守を1社に集約しているか、領域ごとに複数の会社に分散して発注するマルチベンダーの体制を取っているかによっても、保守費の内訳の見え方が変わります。1社独占の場合、価格交渉力が開発会社側に偏りやすい面がある一方、複数社に分散すると、責任の所在が曖昧になり、障害発生時に「うちの担当範囲ではない」とたらい回しにされるリスクも生まれます。この点は保守費という金額だけでなく、ベンダーロックインの観点からもあわせて考える価値があります。
保守費の内訳を可視化する：チェックリスト
ここまでの5つの要因を踏まえ、自社の保守契約を実際に見直す際のチェックリストを整理します。契約書と直近1年分の請求書・対応履歴を手元に用意して、順番に確認してみてください。
- [ ] 保守費に含まれる作業範囲（障害対応・問い合わせ対応・軽微な改修・パッチ適用・バックアップ確認）が契約書に明記されているか
- [ ] SLA（対応開始までの目標時間）が数値で明記されているか、それとも「速やかに対応します」といった曖昧な表現にとどまっているか
- [ ] 過去1年間で、実際に障害対応・問い合わせ対応を依頼した回数と内容を把握しているか
- [ ] 月額固定制か都度精算制か、契約形態を正確に把握しているか
- [ ] 保守費の中に、実際には使っていない対応範囲（例：夜間対応を含む契約なのに夜間の障害が一度も発生していない）が含まれていないか
- [ ] 過去の見積もり・請求書を比較し、金額が年々上昇していないか、上昇している場合はその理由の説明を受けているか
- [ ] 保守を依頼している会社以外に相見積もりを取ったことがあるか
このチェックリストを埋めていくと、多くの場合、「契約書に何が含まれているか自体を正確に把握していなかった」という事実に気づきます。見直しの出発点は、金額の高低を判断することではなく、まず契約内容を正確に把握することにあります。
保守費が「高い」と感じたときに、まず疑うべき2つの可能性
保守費に違和感を持ったとき、多くの方はすぐに「値下げ交渉」や「他社への切り替え」を考えがちですが、その前に確認しておきたい2つの可能性があります。
可能性1：対応範囲が過剰、または不足している
前述の通り、契約している対応範囲が自社の実態と合っていない可能性があります。過去1年間の障害・問い合わせ対応の実績を振り返り、契約している対応範囲のうち、実際に使った項目と使わなかった項目を洗い出してみてください。使っていない項目が多ければ、対応範囲を絞ったプランへの見直しが交渉材料になります。逆に、契約範囲外の作業を都度追加費用で依頼することが頻発している場合は、対応範囲を広げた契約に切り替えた方が、トータルでは安くなる可能性もあります。
可能性2：システムの複雑さ・老朽化が保守費を押し上げている
保守費が年々上昇している場合、開発会社側の値上げというより、システム自体の複雑さが増している（機能追加を繰り返した結果、構造が複雑化している）ことが原因のケースもあります。この場合、保守費そのものの交渉だけでは根本解決にならず、システムの整理・作り直しを検討すべき局面かもしれません。この判断については、老朽化したシステムの延命と作り直しをどう判断するかを扱った記事もあわせてご参照ください。
見直しの進め方：4つのステップ
保守費の見直しを実際に進める際の手順を、4つのステップに整理します。
ステップ1：契約内容と実績を棚卸しする
前章のチェックリストを使い、契約書に書かれている内容と、実際の対応実績を照合します。この段階では金額の交渉はせず、事実確認に徹してください。開発会社に対しても、「値下げしてほしい」ではなく「契約内容と実績を確認したい」というニュートラルな依頼として問い合わせる方が、建設的な対話につながりやすくなります。
ステップ2：社内での必要水準を再定義する
システムが止まった場合、どれくらいの時間、業務が止まっても許容できるか。問い合わせ対応をどこまで開発会社に依存する必要があるか。これらを社内で改めて言語化します。数年前に契約したときと今とで、業務の重要度やシステムへの依存度が変わっている場合、必要な保守水準そのものが変化している可能性があります。
ステップ3：他社の見積もりを取得する（RFP（提案依頼書）の活用）
現在契約している会社の金額が妥当かを判断する最も確実な方法は、同条件で他社に見積もりを依頼し、比較することです。ここで重要なのは、対応範囲・SLA・契約形態といった条件をできる限り揃えて依頼することです。条件が揃っていない見積もりを比較しても、金額の差が何に起因するのかが分からず、比較の意味が薄れてしまいます。
見積もり依頼時に伝えるべき情報を整理すると、次のようになります。
- システムの概要（利用人数、主要機能、開発言語やインフラ環境が分かれば併記）
- 希望する対応範囲（障害対応のみか、問い合わせ対応・軽微な改修も含めるか）
- 希望するSLA（対応開始までの目標時間）
- 現在の契約形態（月額固定か都度精算か）と、変更の希望有無
- 過去1年間の障害・問い合わせの発生頻度（分かる範囲で）
なお、既存の開発会社以外に見積もりを依頼する行為そのものが、著作権やソースコードの引き渡しといった別の論点に触れることがあります。他社に切り替える可能性を視野に入れる場合は、契約書のソースコード関連の条項もあわせて確認しておくことをおすすめします。
ステップ4：既存の開発会社と対話する
他社見積もりを取得したうえで、現在の開発会社と対話する場合、目的は「安い会社に乗り換える」ことだけではなく、「適正な範囲・水準で契約を結び直す」ことにあるという姿勢で臨むと、関係を損なわずに交渉しやすくなります。
対話の際に伝えるとよい内容の例です。
「契約内容を棚卸ししたところ、当社の実際の利用実態と、契約している対応範囲にズレがあるのではないかと感じています。過去1年間の対応実績を踏まえて、契約内容の見直しについて相談させていただけますか」
このような切り出し方であれば、一方的な値下げ要求ではなく、実態に基づく見直しの相談として受け止めてもらいやすくなります。開発会社側も、対応範囲が実態と合っていないことに気づいていないケースは意外と多く、対話によって双方にメリットのある見直しにつながることもあります。
見直しの結果、起こりうる3つのパターン
見直しを進めた結果、実際にどのような着地点があり得るかを整理しておきます。
- 対応範囲を絞り、保守費が下がるパターン：使っていない対応項目を契約から外すことで、コストが下がります。ただし、いざというときの対応が手薄になるリスクとのバランスを考える必要があります
- 対応範囲を広げ、保守費は上がるが総コストは下がるパターン：契約範囲外の都度作業が頻発していた場合、対応範囲を広げた契約に切り替えることで、月額は上がっても年間の総支払額が下がることがあります
- 金額は変わらないが、SLAや対応範囲が明文化されるパターン：金額交渉が難航した場合でも、これまで口頭・慣例で運用されていた対応範囲やSLAを契約書に明記してもらうだけで、次回以降のトラブル時の判断材料が明確になります
金額そのものが下がることだけを見直しの成功と捉えず、契約内容が可視化され、次に判断する材料が整うこと自体にも価値があると考えてください。
保守費削減のためにやってはいけないこと
見直しを進める過程で、コストを下げること自体が目的化してしまい、かえってリスクを高める判断をしてしまうケースがあります。特に注意したい3つのパターンを紹介します。
対応範囲を減らしすぎて、実質的に保守が機能しなくなる
保守費を下げるために対応範囲を極端に絞り込んだ結果、実際に障害が起きたときに「その対応は契約範囲外なので、別途見積もりになります」と言われ、緊急時にもかかわらず追加の交渉と時間が必要になるケースがあります。目先の月額費用を下げることと、いざというときに迅速に対応してもらえることは、トレードオフの関係にあります。削る対応範囲は、本当に発生頻度が低く、発生しても業務への影響が限定的なものに絞り込んでください。
バックアップ・パッチ適用など「見えにくい作業」から削ってしまう
障害対応や問い合わせ対応は目に見える形で発生するため、対応範囲から外したときの影響を想像しやすい一方、バックアップの取得確認やセキュリティパッチの適用は、平常時には何も起きないため、削っても当面は困らないように見えます。しかし、この2つはまさに「起きてからでは手遅れ」になりやすい作業です。ランサムウェアの被害や、パッチ未適用の脆弱性を突かれたサイバー攻撃は、発生してから対応するのでは遅く、事前の備えとしての価値がある作業です。保守費を削る際は、発生頻度の低さだけで判断せず、発生したときの影響の大きさもあわせて考慮してください。
金額の安さだけで開発会社を切り替え、引き継ぎコストを見落とす
他社の見積もりが大幅に安かったという理由だけで切り替えを決めると、実際には移行時の引き継ぎ作業（ドキュメントの整備、旧開発会社からの情報引き渡し、新しい開発会社がシステムを理解するための調査期間）にかかるコストや時間を見落としがちです。特に、システムの仕様書やドキュメントが十分に整備されていない場合、新しい開発会社が現状を把握するだけで相応の工数がかかり、その分の費用が別途発生することもあります。切り替えを検討する際は、月額の保守費だけでなく、移行にかかる一時的なコストも含めて比較してください。
見直しの過程で契約書もあわせて確認する
保守費の見直しは、金額や対応範囲だけでなく、契約書自体の記載内容を見直すよい機会でもあります。特に次の点は、保守費の議論と並行して確認しておくと、将来的なトラブルを防ぎやすくなります。
- 契約の自動更新条項の有無と、解約を申し出る際の通知期限
- 障害対応が遅れた場合のエスカレーション（現場担当者で解決できない場合に、より上位の担当者へ引き継ぐ仕組み）のルートが明記されているか
- 保守対象範囲外の作業を依頼した場合の見積もりの出し方・単価の目安が事前に共有されているか
- 契約不適合責任（契約不適合責任）に関する条項が、保守で発生した改修分にも及ぶか
これらの条項は、保守費という「金額」の議論とは別に、いざというときの対応品質を左右する重要な要素です。金額交渉と同じタイミングで確認しておくと、二度手間になりません。
内製化・部分内製という選択肢もあわせて検討する
保守費全体を外部に委託し続けるのではなく、対応範囲の一部を自社で担う「部分内製」という選択肢も、見直しの一環として検討する価値があります。たとえば、簡単な問い合わせ対応やマニュアルの整備は社内で行い、障害対応や複雑な改修のみを外部の保守契約に残す、という切り分けです。
内製化とアウトソースの判断は、単純にコストの比較だけで決まるものではなく、社内に対応できる人材がいるか、その人材が他の業務と兼務できる範囲かといった実務的な制約も踏まえる必要があります。ただし、保守費が高止まりしている要因の一部が「本来なら社内で対応できる問い合わせ」に費やされているのであれば、切り分けの検討自体には意味があります。
保守契約の情報を記録しておくことの重要性
見直しを一度行って終わりにするのではなく、今後も定期的に見直せるようにするためには、保守契約に関する情報を記録しておくことが欠かせません。契約先、契約形態、対応範囲、SLA、金額、更新時期といった情報をシステム管理台帳（システム管理台帳）にまとめておくと、担当者が異動・退職した場合でも、次の担当者がスムーズに契約内容を把握でき、見直しのタイミングを逃しにくくなります。
多くの企業では、保守契約に関する情報が特定の担当者の記憶や、過去のメールのやり取りにしか残っておらず、担当者が変わるたびに「そもそも今どんな契約になっているか分からない」という状態からやり直すことになります。この記事で行った棚卸しの結果を、そのまま台帳の形で残しておくことをおすすめします。
よくある失敗パターン
保守費の見直しを進める際に、実際によく見られる失敗パターンをいくつか紹介します。
失敗パターン1：金額だけを見て他社に切り替え、対応範囲が実は狭かった
見積もり比較の際に金額だけに着目し、対応範囲やSLAの条件を揃えずに安い会社に切り替えた結果、実際には障害対応の範囲が狭く、想定していた保守が受けられなかったというケースです。見積もり比較の際は、必ず対応範囲・SLA・契約形態を条件として明示し、揃えたうえで比較してください。
失敗パターン2：交渉の材料がないまま「高い」とだけ伝えてしまう
契約内容の棚卸しをせず、感覚的に「高い気がする」とだけ開発会社に伝えても、具体的な見直しにはつながりにくいものです。前述のチェックリストとステップに沿って、事実に基づいた材料を用意してから対話に臨むことをおすすめします。
失敗パターン3：見直しの結果を記録に残さず、数年後にまた同じ作業を繰り返す
せっかく契約内容を棚卸しし、見直しの合意に至っても、その結果をシステム管理台帳などの形で記録に残さないと、担当者の異動後に同じ作業をゼロからやり直すことになります。見直しのプロセス自体を、次回以降の担当者に引き継げる形で残しておくことが重要です。
まとめ：保守費の見直しは「相場探し」ではなく「構造の可視化」から
毎月の保守費が妥当かどうかを判断するために必要なのは、他社の相場を探すことではなく、自社の保守契約がどのような構造になっているかを可視化することです。この記事で解説した内容を振り返ります。
- 保守費には、障害対応・問い合わせ対応・軽微な改修・パッチ適用・バックアップ確認という異なる性質の作業が含まれており、何が契約に含まれているかを分解して把握する
- 保守費は、対応範囲の広さ・SLAの水準・契約形態・システムの複雑さ・ベンダーの体制という5つの要因によって決まる
- 見直しを進める際は、契約内容と実績の棚卸し→社内での必要水準の再定義→他社見積もりの取得→既存開発会社との対話、という順番で進める
- 見直しの結果は、金額が下がることだけでなく、対応範囲やSLAが明文化されることにも価値がある
- 見直しの結果は、システム管理台帳などの形で記録に残し、次回以降の担当者が同じ作業を繰り返さずに済むようにする
保守費は、一度契約すると数年単位で見直されないまま支払い続けられることが多い費用です。この記事をきっかけに、まずは契約書と請求書を手元に並べ、チェックリストの項目を一つずつ確認するところから始めてみてください。そして、見直しの結果、そもそも保守契約自体が実質的に機能していない、あるいは契約が切れたまま放置されていることに気づいた場合は、次に紹介する記事もあわせてご覧いただき、自社の状況に応じた対応を検討することをおすすめします。
