毎月の請求書を見るたびに感じる、あの違和感
毎月25日。経理から回ってくる支払明細の中に、決まって同じ行がある。「システム保守費 月額80,000円」。先代の頃からずっと払い続けてきたその項目を、後継社長になって初めて自分の目でじっくり見たとき、多くの人はふと手を止める。
これは何に対する費用なのか。ホームページは去年から更新していない。基幹システムは去年、軽微な不具合が一件出ただけだ。それでも毎月8万円、年間で96万円が出ていく。先代に聞いても「昔からそういう契約になっている」としか返ってこない。担当していた開発会社に聞いても、「保守契約ですので、何かあったときにすぐ対応できる体制を維持するための費用です」という、輪郭のはっきりしない答えが返ってくるだけだ。
事業承継を経て社長の椅子に座った人の多くが、この「保守費という名前の請求書」の前で立ち止まる。金額の大小以前に、その内容が見えないことが不安なのだ。先代は現場のことを深く知らず、開発会社との関係も「昔からの付き合い」で維持してきた。契約書を読んでも、「保守業務一式」「軽微な修正対応」といった抽象的な言葉が並ぶだけで、具体的に何が保守範囲に含まれ、何が追加費用になるのかが判然としない。
ある地方の建材商社の三代目社長は、代替わりのタイミングで全契約書を洗い直した。基幹システムの保守費が月12万円、ホームページの保守費が月3万円、合計で年間180万円。これが高いのか安いのか、判断する基準すら持っていなかった。同業の知人に聞いても、「うちは保守なんて頼んでいない、壊れたら都度払いだ」という会社もあれば、「うちは月50万円払っている」という会社もあり、相場観がまるでつかめなかった。
この記事では、後継社長・後継者が最初にぶつかる「保守費は何に対する対価なのか」「相場はどう考えればいいのか」という問いに、構造から答えていく。保守契約という仕組みがなぜ生まれ、なぜ内容が見えにくくなりがちなのか。何を基準に高い・安いを判断すればよいのか。そして、実際に開発会社と向き合うときの具体的なステップまで、順を追って解説する。
なぜ保守費の内容が見えなくなるのか、その構造的な理由
保守契約が本来カバーする範囲
まず前提として整理しておきたいのは、システムの保守という業務が、実際には複数の異なる性質の作業を一つの請求項目にまとめて呼んでいるという事実だ。ひとくくりに「保守費」と呼ばれているものの内側には、少なくとも次のような異なる作業が混在している。
一つ目は、サーバーやドメインなど、システムが動き続けるための土台の維持費だ。サーバーのレンタル料、SSL証明書の更新、ドメインの年間更新といった、システムが存在するために最低限必要な費用がここに含まれる。これはシステムを使い続ける限り、誰がどう管理しても必ず発生するコストであり、開発会社の技術力とはあまり関係がない。
二つ目は、セキュリティ更新や不具合対応といった、システムを安全に動かし続けるための作業だ。使用しているソフトウェアのバージョンが古くなれば脆弱性が見つかることがあり、それを塞ぐための更新作業が必要になる。また、稀に発生する表示崩れや動作不良といった不具合を修正する作業も含まれる。これは発生頻度が不規則で、月によっては全く作業が発生しないこともあれば、大きな不具合が出た月には数時間の対応が必要になることもある。
三つ目は、軽微な修正や更新代行といった、日常的な運用サポートだ。「この文章を直してほしい」「この画像を入れ替えてほしい」といった、月に数回発生する小さな依頼にすぐ対応してもらえる体制のことを指す。この作業量は会社によって大きく異なり、更新が頻繁な会社ではここが保守費の大部分を占めることもある。
四つ目は、有事の際にすぐ相談できる「窓口を確保しておく」という価値そのものだ。何か問題が起きたときに、事情を知らない新しい会社に説明し直すのではなく、システムの経緯を知っている担当者にすぐ連絡できる。この安心感、いわば保険的な価値は、月々の作業量には表れないが、保守費の中に確実に組み込まれている。
これら四つの要素の配分比率は、会社ごとに、契約ごとに全く異なる。ところが請求書に書かれるのは「システム保守費 月額○○円」という一行だけであり、この中に四つの要素がどのような比率で含まれているかは、多くの場合、契約書にも明記されていない。これが「何に対して払っているのか分からない」という感覚を生む最大の構造的原因だ。
先代の時代に契約が「固まった」まま動いていない
もう一つの構造的な問題は、保守契約が締結された時点と、今の会社の実態が大きくズレていることだ。多くの中小企業では、ホームページや基幹システムの保守契約は、システムを新規に構築した直後に開発会社側から提示され、そのまま長年見直されずに継続している。
システムを構築した当初は、更新頻度も高く、不具合も出やすく、開発会社側の稼働も相応にかかっていた。だからその時点の見積もりで保守費が設定されるのは自然なことだ。しかし数年が経ち、システムが安定稼働するようになると、実際の作業量は当初より大きく減っていくことが多い。ところが保守費という契約は、内容を見直すきっかけがない限り、当初の金額のまま自動更新され続ける。
先代がその会社を経営していた時代、保守費の見直しに時間を使う優先度は低かったということも大きい。日々の売上や資金繰り、取引先対応に比べれば、月数万円の保守費が適正かどうかを検証する作業は、後回しにされやすいテーマだった。結果として、後継社長が引き継いだ時点で、実態とかけ離れた保守契約が「そういうものだから」という理由だけで存続しているケースが少なくない。
開発会社側にも「説明しにくい」事情がある
開発会社の立場から見ても、保守費の内訳を明確に説明することには一定のハードルがある。保守費は多くの場合、個別のプロジェクトの利益率が薄い分を補う、安定収益源としての役割を担っている。極端に細かく内訳を開示すると、「今月は何もしていないのだから無料にしてほしい」という交渉が発生しやすくなり、逆に「今月は大きな作業をしたのに保守費に含まれるのか」という不満も生まれやすくなる。
そのため、多くの開発会社は保守費を「一式」として提示し、月々の作業量の増減を平均化して吸収する運用を好む傾向がある。これは開発会社側の経営判断として合理的ではあるものの、発注側からすると「何をしてもらっているか分からないまま払い続けている」という不透明感につながる。
さらに、担当者が長年変わっていない場合、双方とも「今さら聞くのも気まずい」という心理的な壁ができてしまう。先代と長年の付き合いがあった開発会社の担当者に対して、後継社長が「そもそも何の費用ですか」と聞くのは、思った以上に勇気が要る。この心理的なハードルもまた、内容が見えないまま契約が続いてしまう一因になっている。
相場が「ない」ように感じられる理由
保守費の相場について調べようとしても、はっきりした基準に行き当たらないのには理由がある。保守費は、対象となるシステムの種類、規模、更新頻度、開発会社の体制によって、要素の組み合わせが毎回異なるからだ。
たとえば静的なコーポレートサイトの保守と、日々受注データが動く基幹システムの保守では、必要な監視レベルも対応スピードも全く異なる。月に一度更新すればいい会社と、毎週キャンペーンページを差し替える会社では、運用サポートの負荷が桁違いに変わる。サーバーを自社で契約しているか開発会社が管理しているかによっても、費用構成は変わる。
つまり保守費の「相場」は、単一の数字として存在するのではなく、「自社のシステムに何が必要で、そのうちどれをどこまで頼んでいるか」という組み合わせの結果として、初めて意味を持つ数字になる。この記事の後半で、その組み合わせを自分で確認するための具体的な手順を示す。
ケーススタディで見る、保守費の実態
ケース1:年間96万円払っていたが、実質は「サーバー代の付き添い」だった食品加工業の事例
従業員35名の食品加工業を営むB社は、先代からホームページと受注管理システムの保守費として、月額8万円を10年以上払い続けていた。二代目社長が就任して最初の決算で、この年間96万円という金額の重さに気づき、内容を確認することにした。
開発会社に問い合わせたところ、送られてきた回答は「サーバー費、SSL証明書更新、月次の死活監視、不具合発生時の一次対応」という内訳だった。実際に過去2年分の対応履歴を開示してもらうと、不具合対応は年に1〜2件、それぞれ数時間程度の作業しか発生していなかった。サーバー費自体は市場価格で見れば月数千円程度で調達可能なものであり、残りの大部分は「何かあったときのための待機費用」として計上されていたことが分かった。
このケースで重要なのは、開発会社が不正に高額請求をしていたわけではないという点だ。B社のシステムは10年前の構築当初、頻繁な機能追加や更新作業が発生していた時期の稼働量をベースに保守費が設定されており、その後システムが安定してからも金額が見直されていなかった。B社の二代目社長は開発会社と交渉し、監視体制とサーバー管理は維持しつつ、待機費用の比率を見直してもらい、月額を8万円から4万5000円に引き下げる合意に至った。
この事例が示すのは、保守費が高いか安いかを判断する前に、まず「その保守費が何に対する対価として設定された金額なのか」という設定当時の背景を確認する必要があるということだ。設定当時の作業量と現在の作業量にギャップがあるなら、それは見直しの余地があるという合理的なサインになる。なお、開発会社の返信が遅く関係がぎくしゃくしている場合は、先代の代からの開発会社の返信が遅い。関係が壊れる前にできる対処も参考にしてほしい。
ケース2:保守費を削って痛い目に遭った印刷会社の事例
もう一つの事例は、保守費の見直しを急ぎすぎて失敗したC社のケースだ。印刷業を営むC社の後継者は、就任後すぐに全ての固定費を見直すプロジェクトを立て、システム保守費についても「高すぎる、削れるはずだ」という前提で開発会社に一方的な減額を要求した。
開発会社側は減額に応じたものの、その代わりに保守範囲を「サーバー監視のみ」に縮小することで合意した。数か月後、受注管理システムに軽微な不具合が発生し、注文データの一部が正しく反映されないという問題が起きた。以前の契約であれば、保守費の範囲内で即日対応してもらえたはずの内容だったが、範囲縮小後は「保守範囲外の対応」として、別途見積もりと追加費用が必要になった。結果的に、対応が完了するまでに1週間近くかかり、その間に受注ミスによる顧客対応のトラブルが複数発生した。
最終的にC社は、削減した保守費の何倍にも相当する損失を、顧客対応の人件費とお詫び対応で被ることになった。後継者は振り返って、「保守費という数字だけを見て、その中に何が含まれているかを確認せずに削ってしまったのが失敗だった」と語っている。
このケースが示す教訓は明確だ。保守費の見直しは、単に金額を下げることが目的ではなく、「自社にとって本当に必要な保守範囲を見極め、その対価として適正な金額を払う」ことが目的でなければならない。範囲を確認せずに金額だけを交渉すると、必要なサポートが失われるリスクを見落としてしまう。
ケース3:複数の開発会社に同時発注していた運送会社の事例
三つ目の事例は、少し異なる角度の問題だ。運送業を営むD社では、先代の時代にホームページ制作会社、配車管理システムの開発会社、給与計算システムの導入会社という3社と、それぞれ個別に保守契約を結んでいた。三代目の後継者が就任して契約を洗い直したところ、3社合計で月額22万円、年間264万円の保守費が発生していることが分かった。
さらに詳しく調べると、3社のうち2社が提供する保守内容に重複があった。ホームページ制作会社とは別に、配車管理システムの開発会社もサーバー全体の監視サービスを提供しており、実質的に同じ範囲のセキュリティ監視を二重に契約し、二重に払っていたことが判明した。
D社の後継者は、3社それぞれに保守範囲の内訳を提出してもらい、重複部分を特定した上で、一方の監視契約を解約する交渉を行った。結果、年間で約40万円のコスト削減につながった。こうした交渉が難航してトラブルに発展しそうな場合の進め方は、トラブル時の交渉術。感情的にならずに解決するで解説している。この事例が示すのは、複数のシステムを複数の会社に発注している中小企業では、保守契約が「誰が何をカバーしているか」の全体像を誰も把握していないまま積み重なっていくという、承継期特有のリスクだ。先代の時代からの積み重ねを一枚の表に落とし込むだけで、見えていなかった重複や空白が見つかることが多い。
実務対応:保守費を「見える化」するための具体的ステップ
ここからは、後継社長・後継者が実際に着手すべき手順を、チェックリスト形式で示していく。順番通りに進めることで、感覚論ではなく事実に基づいて保守費の適正さを判断できるようになる。
ステップ1:現在契約している保守契約を全てリストアップする
最初にやるべきことは、自社が現在契約している保守契約を、システム単位・会社単位で全てリストアップすることだ。ホームページ、基幹システム、給与システム、勤怠管理システム、POSレジ、クラウドサービスなど、月額費用が発生しているもの全てを対象にする。
このとき見落としがちなのが、経理担当者しか把握していない小さな契約や、先代個人の名義で契約されていたクラウドサービスなどだ。過去1年分の口座取引履歴やクレジットカード利用履歴を確認し、「システム」「保守」「サポート」「ライセンス」といった名目の定期支払いを全て洗い出す作業から始めるとよい。ケース3のD社のように、複数会社への重複発注は、この段階で表を作らない限り発見されない。
ステップ2:各契約について「保守範囲」を開発会社に文書で確認する
リストができたら、契約している各開発会社に対して、現在の保守費で具体的に何をカバーしているのかを文書で開示してもらう。口頭の説明ではなく、後から見返せる形で残すことが重要だ。確認すべき項目は次の通りだ。
サーバー・ドメイン・SSL証明書などの基盤維持がいくらの比率で含まれているか。セキュリティ更新やソフトウェアのバージョンアップ対応は、月に何回、どの範囲まで含まれているか。軽微な修正依頼は月に何回まで、どの程度の作業量までが保守費の範囲内で、それを超えるとどこから追加費用になるのか。不具合発生時の対応スピードはどの程度保証されているか、平日日中のみか、休日や夜間も対応可能か。過去1〜2年間の実際の対応履歴、対応した作業の一覧を開示してもらえるか。
この確認を丁寧な依頼として行うことが重要だ。「先代の時代からお世話になっている御社との関係を大事にしたいので、これから引き継ぐにあたって内容を正確に理解しておきたい」という姿勢で依頼すれば、多くの開発会社は協力的に応じてくれる。むしろ、この機会に開発会社との関係を再構築する良いきっかけにもなる。
ステップ3:過去の対応履歴と保守費の金額を照らし合わせる
開示してもらった対応履歴を見て、実際の作業量と保守費の金額感が見合っているかを確認する。ここで重要なのは、単月ではなく最低でも過去1年分、できれば2年分のデータで見ることだ。保守費は本来、作業が少ない月と多い月を平均化して設定されているものなので、単月の作業量が少ないからといって即座に「高すぎる」と判断するのは早計だ。
年間を通して見て、対応件数が極端に少ない、あるいは開発会社側の記録自体が曖昧で「対応履歴が残っていない」という場合は、保守契約の実態が形骸化している可能性が高い。逆に、頻繁に更新依頼をしていて開発会社側が毎回迅速に対応してくれているなら、その保守費は十分に機能を果たしていると評価できる。
ステップ4:自社の更新頻度・リスク許容度を洗い出す
開発会社側の情報だけでなく、自社側の実態も洗い出す必要がある。ホームページや基幹システムに、今後どの程度の頻度で更新や修正の依頼が発生しそうか。システムが一時的に止まった場合、自社の事業にどの程度の損害が発生するか。たとえば受注管理システムが1日止まった場合の損失と、単なる会社案内サイトが1日止まった場合の損失は、性質が全く違う。
このリスク許容度の把握が、保守範囲の選択に直結する。損失が大きいシステムほど、迅速な対応が保証された手厚い保守契約に価値があり、逆に更新頻度が低く止まっても大きな損害が出ないシステムなら、監視のみの軽量な保守で十分というケースもある。ケース2のC社が陥った失敗は、この見極めをせずに保守範囲を縮小してしまったことにある。
ステップ5:複数の開発会社から相見積もりを取り、比較する軸を統一する
内容が見える化できたら、必要であれば他の開発会社にも同じ条件で見積もりを依頼し、比較する。ここで重要なのは、比較する軸を統一することだ。単に「月額いくらか」だけを比較すると、保守範囲が異なる見積もりを同じ土台で比べてしまい、正しい判断ができない。
比較すべき軸は、基盤維持費の範囲、セキュリティ対応の範囲と頻度、軽微な修正の許容範囲(月に何時間分、何件まで)、不具合対応の保証スピード、追加費用が発生する境界線の5点だ。この5点を全ての見積もりで揃えて並べることで、初めて金額の比較が意味を持つようになる。相見積もりを取る目的は、必ずしも会社を変えることではない。今の開発会社との交渉材料を持つこと、そして自社にとっての適正な相場観を掴むことが、より大きな目的になる。
ステップ6:見直し後の契約内容を文書化し、定期的な見直しのサイクルを作る
保守内容の確認と交渉が終わったら、合意した内容を必ず文書に残す。口頭やメールでのやり取りだけで終わらせず、保守範囲、対応時間、追加費用の境界線を明記した契約書、または既存契約の付則として整理する。これにより、次に社長が変わったときや担当者が変わったときにも、同じ確認作業を繰り返す必要がなくなる。
さらに、この確認作業を一度きりで終わらせず、1年から2年に一度は保守範囲と実際の作業量を照らし合わせる見直しのサイクルをカレンダーに組み込んでおくとよい。システムの利用状況は時間とともに変化するため、一度適正化した保守費も、数年後には再びズレが生じる。定期的な見直しの仕組みを持つこと自体が、承継後の会社運営における一つの資産になる。
チェックリストのまとめ
以上のステップを、実務で使えるチェックリストとして整理すると次のようになる。まず、自社が契約している保守契約を、システム単位・発注先単位で全てリストアップしたか。次に、各契約の保守範囲(基盤維持・セキュリティ対応・軽微修正・不具合対応・待機費用)の内訳を、開発会社から文書で開示してもらったか。過去1〜2年分の実際の対応履歴を確認し、契約金額と作業量のバランスを検証したか。自社の更新頻度とシステム停止時のリスク許容度を洗い出したか。必要に応じて他社から同一条件での相見積もりを取得したか。最終的に合意した保守内容を文書化し、次回見直しの時期をあらかじめ決めたか。この6点を一つずつクリアしていくことで、保守費という不透明な項目を、根拠のある納得できる費用に変えていくことができる。
よくある失敗パターン
失敗パターン1:金額だけを見て即断する
最も多い失敗は、保守費の金額の大小だけで「高い」「安い」を判断してしまうことだ。同業他社が月3万円と聞けば、自社が月8万円なら「高すぎる」と結論づけたくなる気持ちは理解できる。しかし前述の通り、保守費には基盤維持・セキュリティ対応・軽微修正・不具合対応・待機費用という異なる要素が組み合わさっており、その配分は会社ごとに全く異なる。他社の金額だけを基準に自社の契約を評価するのは、比較対象がそもそも違う可能性が高く、誤った判断につながりやすい。金額を比較する前に、必ず保守範囲の内訳を確認するという順序を守ることが重要だ。
失敗パターン2:交渉を急いで関係を損なう
二つ目の失敗は、承継直後の勢いで、開発会社との交渉を急ぎすぎることだ。新しい経営者として「無駄を削る」という姿勢を示したい気持ちは自然だが、長年システムの経緯を把握してきた開発会社との関係を、性急な減額要求で損なうと、後々の対応の質が下がるリスクがある。ケース2のC社のように、削減した金額よりも大きな損失を後で被ることもある。交渉の前には必ず内容の開示を求め、事実に基づいた対話を心がけることが、結果的に良い条件を引き出す近道になる。
失敗パターン3:見直しを一度きりで終わらせる
三つ目の失敗は、就任直後に一度契約内容を洗い直しただけで満足し、その後の見直しをしなくなることだ。システムの利用実態は数年で変化するため、一度適正化した保守費も再びズレが生じる。特に、事業が成長して更新頻度が増えた場合や、逆にシステムの利用が縮小した場合には、保守範囲を再調整する必要がある。見直しを一度きりのプロジェクトとして終わらせず、定期的な確認のサイクルに組み込むことが、長期的に見て最も効果の大きい対策になる。
よくある質問
Q1. 保守契約を結んでいないと、システムに何かあったときにどうなりますか。
保守契約を結んでいない場合、多くの開発会社は不具合対応や修正依頼をその都度の見積もり・都度の請求で対応する形になる。緊急性の高い不具合が起きた場合でも、他の顧客の対応状況によっては優先順位が下がり、対応まで時間がかかる可能性がある。保守契約はこの優先順位を確保し、対応スピードをあらかじめ約束してもらうための仕組みでもある。自社のシステムが停止した場合の損失が大きいなら、保守契約なしで運用するリスクは相応に高いと考えたほうがよい。
Q2. 保守費を下げる交渉をすると、開発会社との関係が悪化しませんか。
内容を確認せずに一方的な減額要求をすれば関係が悪化するリスクはあるが、事実に基づいた対話であれば、多くの開発会社は誠実に応じてくれる。長年の付き合いがある取引先であれば、承継のタイミングで契約内容を確認したいという申し出自体は、むしろ自然な経営行為として受け止められることが多い。重要なのは、金額だけを一方的に要求するのではなく、保守範囲の内訳を確認した上で、双方が納得できる形を一緒に探る姿勢だ。
Q3. 保守費が「相場より高い」と分かった場合、すぐに開発会社を変えるべきですか。
すぐに会社を変えることは推奨しない。長年の付き合いがある開発会社は、システムの経緯や過去の変更履歴、社内の運用ルールなど、契約書には残っていない多くの情報を持っている。会社を変えると、その情報の引き継ぎに相応の時間とコストがかかり、引き継ぎの過程で新たな不具合が生じるリスクもある。まずは今の開発会社と内容を確認し、交渉の余地があるかを探ることが先で、それでも折り合いがつかない場合の選択肢として、他社への切り替えを検討するのが順序として妥当だ。
Q4. 保守費の見直しは、承継直後のどのタイミングで着手すべきですか。
理想的には、就任後半年から1年以内、決算を一度経験して固定費全体を把握したタイミングで着手するのがよい。就任直後すぐに着手すると、社内の他の業務の引き継ぎに手が回らず、確認作業が中途半端になりやすい。一方で数年放置してしまうと、いつの間にか実態と契約内容のズレが更に広がってしまう。決算という自然な棚卸しの機会に合わせて、固定費の一項目として保守費を確認するのが、無理のない着手タイミングだ。1年目に開発会社と初めて顔合わせする場面で何を話すべきかは、1年目に開発会社と初めて顔合わせするとき、何を話すべきかも参考にしてほしい。
まとめ
保守費という毎月の請求書は、後継社長にとって最初に向き合う「正体不明の固定費」であることが多い。しかしその不透明さは、開発会社が不誠実だから生まれているわけではなく、保守という業務そのものが基盤維持・セキュリティ対応・軽微修正・不具合対応・待機費用という複数の異なる要素を一つの請求項目にまとめているという構造から生まれている。この構造を理解した上で、自社の保守契約の内訳を開発会社に開示してもらい、過去の対応履歴と照らし合わせることで、初めて金額の妥当性を判断できるようになる。
金額の大小だけで即断せず、範囲を確認し、自社のリスク許容度を洗い出し、必要であれば相見積もりで相場観を掴む。そして一度きりで終わらせず、定期的な見直しのサイクルに組み込む。この一連の手順を踏むことで、先代の時代から続いてきた「よく分からないけれど払い続けている費用」を、根拠のある納得できるコストへと変えていくことができる。それは単なるコスト削減にとどまらず、開発会社との関係を、後継社長自身の言葉で再構築する機会にもなる。保守費の見える化は、承継後の経営者が最初に取り組むべき、地味だが確実な一歩だ。
