保守費高騰で運用断念した業務システム｜見えていなかったコストの話

業務システムの導入を決めた時、その会社の担当者は「これで現場が変わる」と本気で思っていた。導入費用は約400万円。3年もあれば元が取れる計算だった。

ところが5年後、そのシステムは静かに使われなくなっていた。理由は機能の問題ではない。維持するコストが、もう払えなくなっていたのだ。

この記事では、業務システムの「保守費高騰」という問題を、ある中小製造業の事例をもとに描いていく。失敗した担当者を責めるつもりはない。構造的に起きやすい問題だからこそ、知っておいてほしい話がある。

導入費400万円、3年後の保守費が年間200万円を超えた

埼玉県にある従業員30名ほどの部品加工メーカー。受発注と在庫管理を一元化するため、地元のシステム会社に業務システムの開発を依頼した。要件定義から納品まで約8ヶ月、費用は395万円だった。

最初の1〜2年は順調だった。現場の作業は確実に効率化され、担当者の手入力も減った。経営者も「やってよかった」と感じていた。

変化が始まったのは3年目からだ。システムが動いているOSのサポートが切れるという連絡が来た。対応の見積もりが届いた。金額は80万円。翌年、法改正に伴う帳票の修正が必要になった。見積もりは35万円。その次の年、連携していた会計ソフトがバージョンアップして連携が切れた。対応費用は45万円。

気づけば5年間で、保守・改修にかかった費用の累計が開発費を超えていた。そして担当者は決断した。「もうこのシステムへの投資はやめよう」と。

なぜ保守費はここまで高くなるのか

この事例は特別な失敗ではない。中小企業が独自開発のシステムを持つと、似たようなことが起きやすい。その背景には、構造的な理由がある。

コードが属人化すると、開発したエンジニア以外が触りにくい状態になる。担当者が変わったり、ベンダー側に異動や退職が起きると、内部を理解できる人間がいなくなる。理解できなければ、工数は余計にかかる。工数がかかれば、費用は上がる。

フレームワークが古くなる問題もある。開発当時に使われていた技術は、5年後には「古い技術」になっていることが多い。セキュリティ上のリスクが出てきたり、対応できるエンジニアが市場から減ったりする。古い技術を扱えるエンジニアは希少になるため、単価が上がる。

そしてベンダーの言い値になる。内部構造を知っているのが開発ベンダーだけという状況になると、比較検討ができなくなる。「このシステムはうちしか触れない」という構造ができた時点で、価格交渉の余地は消える。見積もりが来るたびに、承諾するしかなくなる。

発注前に聞いておくべき「保守費の問い」

開発費だけで判断するのは、初期費用だけを見て住宅を選ぶのと同じだ。管理費、修繕費、固定資産税、これらを含めてはじめて「住むコスト」がわかる。業務システムも同じで、開発後にかかるコストを先に聞いておくことが不可欠だ。発注前に確認しておきたい問いを挙げる。

月額の保守契約はあるか。ある場合、その範囲に何が含まれるか。OSやフレームワークのバージョンアップ対応は保守費に含まれるか。法改正や外部サービスの仕様変更への対応はどう扱われるか。小改修（項目追加・帳票変更など）の費用はどのくらいを想定すればよいか。開発後、別のベンダーに引き継ぎは可能か。ソースコードと設計書は納品されるか。5年後の維持費はどのくらいを見込むべきか、概算を出してもらえるか。

この問いに対して「わかりません」「ケースバイケースです」としか答えてもらえない場合は、慎重に判断したほうがいい。誠実なベンダーであれば、概算の根拠とともに答えられるはずだ。

保守費を下げるための設計判断

保守費が高くなりやすい構造は、設計と契約の段階でかなり変えられる。オープンソースの標準的なフレームワークを選ぶことで、対応できるエンジニアが市場に多くなり、ベンダーを変えることもしやすくなる。ソースコードだけでなく設計書・テーブル定義・操作マニュアルをセットで納品させることも重要だ。ドキュメントがあれば、別のエンジニアが引き継ぎやすくなり、競合見積もりが取れる状態になる。

保守範囲を契約書に明文化することも欠かせない。バグ対応だけなのか、バージョンアップも含むのか、小改修の上限はあるのかを曖昧なまま契約すると、あとで「それは別費用です」という話になる。月額保守の中に「月●時間までの軽微な改修を含む」という形にすると、都度見積もりの発生を減らせる。

よくある質問

システムの保守費はどのくらいが相場ですか？

一般的には、開発費の15〜20%程度が年間保守費の目安とされることが多い。開発費が300万円であれば、年間45〜60万円程度の感覚だ。ただしこれは「何もなければ」の話で、バージョンアップ対応や法改正対応が重なる年は大きく上振れることがある。保守費の「上限がない年」に備えて、年間予算に余裕を持たせておくことが現実的な対応だ。

保守費が高くなりすぎた場合、どうすればよいですか？

まずソースコードと設計書の所在を確認することが先決だ。自社に納品されていれば、別のベンダーに見積もりを依頼できる。並行して、現状の保守契約の内容を改めて精査し、どの費用が「契約範囲内」でどれが「別途請求」なのかを整理することで、次の交渉材料が見えてくる。

SaaSへの乗り換えは選択肢になりますか？

業務の標準化が進んでいる領域であれば、SaaSへの移行は有効な選択肢だ。保守費の概念が月額サブスクリプションに変わり、バージョンアップはベンダー側が行うため、維持コストの予測が立てやすくなる。一方で、自社固有の業務フローへの対応に限界があることや、データの可搬性を事前に確認しておく必要がある。