「初期費用の見積もりばかり比べて決めたのに、稼働してみたら保守で毎月それなりの額が乗ってきた。しかも、直したいことがあっても作った会社としか連絡が取れず、返事も遅い」——従業員40名ほどの会社で受発注の管理システムを入れた総務の方から、こんな相談を受けたことがあります。契約書を見せてもらうと、開発の範囲は細かく書かれているのに、保守については「別途月額◯万円」の一行だけ。何にいくら払っているのか、当のご本人も把握できていませんでした。
業務システムは、作って納品された瞬間から「使い続けるためのお金」が発生します。ところが発注の場面では初期開発費に注意が集中し、保守・運用の中身は後回しになりがちです。この記事では、納品後に毎月かかる保守費用の正体と、システムを塩漬けにしないための契約の考え方を、発注者の視点で整理します。初期費用や請負／準委任の切り分けそのものはシステム開発の発注ガイドで扱ったので、ここでは「稼働後のフェーズ」に絞ります。
毎月の保守費に何が乗っているのか
まず、「保守費用」という一語にまとめられているものを分解します。中身は大きく次の区分に分かれます。
- 障害対応・バグ修正: システムが止まった、想定外の挙動をした、という際の一次対応と原因調査、修正。
- 問い合わせ・操作サポート: 使い方の質問対応。件数や受付時間帯によって負荷が変わりやすい部分です。
- 予防保守: サーバーやアプリの監視、バックアップ、セキュリティパッチの適用など、壊れる前に手を打つ作業。
- 適応保守: 法改正、OS・ミドルウェア・ライブラリのバージョンアップなど、外部環境の変化に合わせてシステムを追随させる作業。
- 改善・機能追加: 新しい要望に応じて機能を足す作業。これは通常、月額保守とは別の見積もりになります。
見落とされやすいのが適応保守です。外から見ると何も変わっていないのに、裏側で使っている部品は日々古くなり、対応をやめた瞬間にセキュリティや動作の保証が切れていきます。この「見えないメンテナンス」を止めると何が起きるかは、Web サイトを例に「作って終わり」の放置リスクでも書きました。業務システムでも構図は同じです。
なぜ相場が「幅」でしか語れないのか
保守費用の目安として、業界では「初期開発費の年10〜15%程度」という数字がよく挙げられます。たとえば開発費が1,000万円のシステムなら、年間およそ100〜150万円が一つの目安になります（システム幹事などが同様の相場観を示しています）。
ただし、この15%はあくまで幅の中央あたりの話で、実際の金額は保守の中身で大きく動きます。区分ごとに費用感を並べると、その理由が見えてきます。
| 保守の区分 | 主な作業 | 費用の目安（年・対開発費） |
|---|---|---|
| 予防保守 | 監視・バックアップ・パッチ適用 | おおむね5%前後 |
| 適応保守 | 法改正・OS/ライブラリ更新対応 | 案件により20〜50%と幅が大きい |
| 改善保守 | 機能追加・性能向上 | 10〜30%程度、都度見積もりが基本 |
（出典: 株式会社GeNEE の内訳解説などをもとに整理）
料金体系も、定額制（毎月固定でこの範囲を面倒みる）と従量制（作業した分だけ請求）で性格が違います。24時間365日の監視のように定常的に発生するものは定額に、突発的な機能追加は従量に振り分けるのが合理的です。だからこそ「保守は開発費の何%」という一律の数字を鵜呑みにせず、自社のシステムでどの区分にどれだけ手がかかるかを見積もることが先になります。
契約書で必ず確認しておく条項
保守は準委任契約になるのが一般的です。ここで押さえておきたいのは、「何をどこまでやってくれるのか」が契約に書かれているか、という一点に尽きます。曖昧なまま結ぶと、期待と実際の提供品質にギャップが生まれます。
確認しておきたい主な観点は次のとおりです。
- 対応範囲と除外規定: 障害対応は含むが機能追加は別途、といった線引きが明記されているか。
- SLA（サービスレベル）: 障害をどのくらいの時間で検知・通知し、応急対応に着手するのか。時間の約束がないと「即対応」の期待だけが独り歩きします。
- 対応時間帯: 平日日中のみか、夜間・休日も含むか。ここで月額が大きく変わります。
- 成果物とソースコードの権利: ソースコード・設計書の著作権や使用権が誰にあるか、他社への提供や改変が認められているか。
とくに最後の権利まわりは、後述する塩漬けを避けるための生命線になります。契約が存在しない状態でのスポット対応は、ベンダー側に即応する義務がなく、いざという時に高額な緊急対応費を請求されるリスクもあります。
塩漬けとベンダーロックインを避ける設計
冒頭の「作った会社としか連絡が取れない」状態が、いわゆるベンダーロックインです。ベンダーロックインは技術・運用・契約の三つの面から複合的に生じるとされます。独自技術や非公開の仕様に依存していること（技術面）、ドキュメントが整備されず作業が属人化していること（運用面）、ソースコードの権利や引き継ぎの条件が契約に書かれていないこと（契約面）が、それぞれ引き継ぎを難しくします（EC-CUBE の解説が原因とリスクを整理しています）。
こうなると、保守費が高いと感じても他社に相談できず、値上げや対応遅延を受け入れるしかなくなります。回避のために発注側ができることは、実はそれほど複雑ではありません。設計書・運用手順書を成果物として必ず受け取ること、ソースコードと権利の所在を契約で明確にしておくこと、そして特定の一社にすべてを預けきらない体制を意識することです。内製と外注のどちらにどこまで任せるかという判断は内製か外注かの切り分けでも触れていますが、保守フェーズではこの「引き継げる状態を保つ」という視点が特に効いてきます。
私たちが受託で既存システムの保守を引き継ぐ際も、最初にやるのはコードを読むことより、ドキュメントと権利関係の棚卸しです。設計意図が残っていないシステムは、直すたびに毎回調査コストがかかり、それがそのまま保守費に跳ね返ります。逆に、引き継ぎを前提に整理されたシステムは、ベンダーを変えても費用が急騰しません。
自社に合う保守の選び方
保守の形は、システムの重要度で選び分けるのが現実的です。止まると業務が回らない基幹システムなら、監視と即応を含む定額の保守契約を結び、SLA で応急対応の時間を約束してもらう価値があります。一方、止まっても数日は待てる補助的なシステムなら、定額を薄くしてスポット併用でコストを抑える選択もあります。判断の軸は「止まったら困る度合い」と「変更の発生頻度」です。
いま契約中の保守がブラックボックスになっていると感じるなら、次の一歩として、手元の保守契約書で二つだけ確認してみてください。ひとつは対応範囲とSLAが書かれているか、もうひとつはソースコードと設計書の権利が自社にあるか。この二点が曖昧なら、それが将来の塩漬けリスクの所在です。既存システムの引き継ぎや、保守費が妥当かのセカンドオピニオンが必要な場合は、受託でそこから伴走することもできますので、まずは現状の棚卸しからご相談ください。
