システム開発の見積書を比較するとき、多くの方が注目するのは「開発費」です。しかし、システムは作って終わりではなく、リリースしてからの運用が続きます。その間に発生するのが「保守費」と「運用費」です。見積書がこの部分を含んでいない、あるいは「保守 月◯万円」とだけ書かれている場合、リリース後にどこまで対応してもらえるのかが読み取れません。
本記事は連載第4回として、保守費・運用費の読み方を整理します。開発費だけで会社を選んでしまうと、リリース後に「この対応は契約に含まれていない」というずれが起きやすくなります。発注前に範囲を確認しておくことが重要です。
まず結論
- 開発費だけで比較すると、リリース後の保守費・運用費が見えないまま発注してしまいます。
- 「保守 月◯万円」は、範囲、受付時間、一次対応目安、機能追加の扱い、クラウド費の有無まで分けて確認します。
- 自社に必要な保守水準は、システム停止時の業務影響、利用時間、社内対応力で決めると過不足を抑えやすくなります。
| 見る項目 | 判断のしかた | 発注前の確認ポイント |
|---|---|---|
| 保守範囲 | 不具合修正・問い合わせ・軽微改修の扱い | 機能追加が含まれるかを確認 |
| SLA | 受付時間と対応目安 | 平日日中か、夜間休日も含むか |
| 運用費 | クラウド・監視・バックアップ | 保守費と別建てか確認 |
OUTCOME BLUEPRINT
AI/DX投資の前に、成果KPIと発注条件を整理しませんか？
補助金、SaaS選定、開発見積、PoCの前に、業務要件・費用レンジ・RFP・合格条件を成果起点で整理します。
この連載での位置づけ
- 前に読む記事：連載第3回：要件定義費
- 次に読む記事：連載第5回：安い見積と高い見積
- 比較表で整理する：連載第11回：比較表
- 発注前の質問に落とし込む：連載第12回：開発会社への20問
保守費と運用費の違い
保守費と運用費は混同されやすいですが、対象が異なります。
| 区分 | 主な内容 | 目的 |
|---|---|---|
| 保守費 | 障害対応、不具合修正、軽微な改修、問い合わせ対応 | システムを正常に使い続けるため |
| 運用費 | サーバー・クラウドの監視、バックアップ、稼働管理 | システムを止めずに動かし続けるため |
保守は「直す・手を入れる」側、運用は「動かし続ける・見守る」側、と整理すると分かりやすいかもしれません。見積書では両者が一体になっていることもあれば、分かれていることもあります。どちらの場合も、何が含まれるかを確認することが大切です。
「保守 月◯万円」だけでは読み取れないこと
保守費が「月◯万円」とだけ書かれている場合、次の点が読み取れません。
- バグ（不具合）の修正は含まれるか
- 機能追加・仕様変更は含まれるか、別途見積か
- 障害が起きたとき、どのくらいの時間で対応してくれるか
- 対応してくれる時間帯（平日日中のみか、夜間・休日も含むか）
- 問い合わせの窓口と、対応の回数や上限
同じ「月5万円」でも、含まれる範囲によって内容はまったく異なります。安く見える保守費が、実は「軽微な問い合わせ対応のみ」で、不具合修正は別費用、というケースもあります。逆に、手厚い保守が含まれていて妥当な金額のこともあります。重要なのは、金額の大小ではなく範囲が定義されているかどうかです。
SLA（サービスレベル合意）という考え方
保守・運用の品質を言葉で定義したものが、SLA（Service Level Agreement、サービスレベル合意）です。たとえば次のような項目を取り決めます。
- 障害発生時の連絡から一次対応までの目標時間
- 対応する時間帯（受付時間）
- 対象とする障害の範囲（どこまでを保守対象とするか）
- 月次の稼働状況の報告の有無
SLAが明確だと、「どこまでを、どのくらいの速さで対応してもらえるか」が事前に分かります。中小企業向けのシステムでは、過剰に手厚いSLAが必ずしも必要とは限りません。自社にとって「システムが止まると困る時間帯はいつか」を整理し、それに見合う水準を選ぶのが現実的です。
保守費・運用費で抜けやすい項目
見積書で抜けやすい、あるいは別途になりやすい項目を整理します。
- OS・ミドルウェア・ライブラリのバージョンアップ対応
- セキュリティ更新への対応
- クラウド・サーバーの利用料（運用費とは別に実費がかかることがある）
- ドメイン・SSL証明書の更新
- データのバックアップと、復旧（リストア）の対応
- 法改正などに伴う仕様変更（制度対応）
これらは、見積の「開発費」にも「保守 月◯万円」にも含まれていないことがあります。とくにクラウドの利用料や外部サービスの費用は、連載第8回で扱うように、月額で継続的に発生します。
自社に必要な保守水準の決め方
保守は、手厚いほど安心ですが、その分費用もかかります。過不足のない水準を決めるには、「システムが止まると、どの業務が・どのくらい困るか」から逆算するのが現実的です。たとえば、受発注に直結するシステムなら早い障害対応が必要ですが、社内の集計用なら翌営業日対応でも支障が小さいかもしれません。自社にとっての影響の大きさを整理してから、それに見合う保守を選ぶと、納得感のある契約になります。
次の観点で整理すると、自社に必要な保守水準が見えてきます。
| 確認観点 | 自社で整理すべきこと |
|---|---|
| 業務への影響 | システム停止でどの業務が止まるか、影響の大きさは |
| 利用時間帯 | 平日日中のみか、夜間・休日も業務利用するか |
| 社内対応力 | 問い合わせ窓口や一次対応を社内で担える人がいるか |
| 改修の頻度 | リリース後にどの程度の改修・追加が見込まれるか |
| 運用期間 | 何年使い続けることを想定するか |
これらを整理してから保守の水準を決めると、過剰でも不足でもない契約を選びやすくなります。
保守契約の形を知っておく
保守契約には、いくつかの形があります。違いを知っておくと、見積の前提が読み取りやすくなります。
| 形 | 概要 | 向いている場面 |
|---|---|---|
| 定額保守 | 毎月一定額で一定範囲を対応 | 継続的に手を入れたい |
| 都度対応 | 発生した作業ごとに費用 | 改修の頻度が低い |
| 準委任での運用支援 | 稼働時間に応じて支援 | 運用を継続的に任せたい |
どの形が適しているかは、改修の頻度や、社内で運用を担える人がいるかによって変わります。複数の形を組み合わせることもあります。
開発費と保守費の関係を発注前に見ておく理由
開発費だけで複数社を比較すると、保守費が低い会社を選んだはずが、リリース後の対応範囲が小さく、都度の対応費が積み上がるケースがあります。逆に、開発費に保守が含まれているような見積では、発注後に「保守の範囲を縮小したい」という調整が難しくなることもあります。
発注前の段階で「開発後にかかるコスト」を見積に含めて比較することで、初期費用だけでなく、使い続ける期間全体でのコスト感が判断しやすくなります。見積書に保守費の記載がない場合は、開発会社に「リリース後の保守はどのような形で対応していただけますか」と確認しておくことが、後のずれを防ぐ最初の一歩です。
保守費・運用費を含めた総合的なコスト感については、システム開発の見積書の内訳ガイドも参考になります。
発注前チェックリスト（保守費・運用費）
- 保守費・運用費が見積書に含まれているか、別契約かが分かるか
- 保守の範囲（不具合修正・機能追加・問い合わせ）が定義されているか
- 障害対応の受付時間と、一次対応の目標時間が示されているか
- 機能追加・仕様変更が、保守に含まれるか別見積かが分かるか
- クラウド・サーバーの利用料が、保守費とは別に明示されているか
- バックアップとデータ復旧の対応が含まれているか
- OS・ミドルウェアの更新対応の扱いが分かるか
- 保守契約の期間と、更新・解約の条件が分かるか
- 保守契約の形（定額保守・都度対応・準委任）が何かが分かるか
- 法改正など制度変更に伴う仕様変更の扱いが示されているか
- リリース直後の無償保証期間（バグ修正の無償範囲）が明示されているか
開発会社に確認する質問
- 「保守費には、不具合修正・機能追加・問い合わせのどこまでが含まれますか」
- 「障害が起きたとき、受付時間と一次対応の目安を教えてください」
- 「クラウドやサーバーの利用料は、保守費とは別に発生しますか」
- 「データのバックアップと、復旧の対応は含まれますか」
- 「OSやライブラリの更新、セキュリティ対応はどのように扱われますか」
- 「リリース直後のバグ修正は、無償保証期間として扱いますか。期間はどのくらいですか」
- 「保守契約の形（定額保守・都度対応など）と、その根拠を教えてください」
- 「法改正などで仕様変更が必要になった場合、対応の費用はどのように扱われますか」
保守の範囲を具体的に説明できる相手は、リリース後の運用も見据えて提案している傾向があります。
相談前に整理しておくとよい情報
- システムが止まると困る時間帯・業務（影響の大きさ）
- 社内で運用・問い合わせ対応を担える人がいるか
- データのバックアップに求める安心の水準
- 想定している運用期間（何年使う想定か）
- すでに受け取っている見積で、保守がどう書かれているか
これらを整理すると、自社に必要な保守の水準が明確になり、過不足のない保守契約を検討しやすくなります。
GXOの発注前レビューで見る実務メモ
GXOが見積書の相談を受けるときは、最初から「高い」「安い」を判定せず、見積の前提を分解します。まず初期費用、月額費用、追加費用、発注側作業、リスク項目の5区分に分けます。そのうえで、3社比較、5年TCO、社内稟議、契約条件の順に確認します。これにより、金額の差が価格差なのか、範囲差なのか、リスクの見込み方の差なのかを説明しやすくなります。
発注側で用意しておくとよいのは、完璧な要件定義書ではありません。現行業務の流れ、利用者数、画面・帳票・連携の数、希望時期、予算の幅、社内決裁者、止められない業務、個人情報や機密情報の有無です。これらが曖昧なまま見積を取ると、開発会社ごとに前提が変わり、相見積もりの比較が難しくなります。
| 確認領域 | 発注側が用意する情報 | 見積で確認すること |
|---|---|---|
| 業務範囲 | 対象部署、利用者数、現行フロー | どこまでが開発対象か |
| 機能規模 | 画面数、帳票数、API本数 | 工数の根拠が説明できるか |
| データ | 移行対象、件数、クレンジング要否 | 移行費・移行リハーサルの有無 |
| 運用 | 利用時間、障害時の影響、社内担当 | 保守範囲、SLA、月額費用 |
| 契約 | 請負/準委任、検収、知財、再委託 | 責任分界と追加費用の条件 |
| 稟議 | 予算上限、比較対象、判断基準 | 3社比較や5年TCOで説明できるか |
この整理を先に行うと、AI開発、セキュリティ要件、補助金活用を含む案件でも、見積の前提を同じ粒度にそろえやすくなります。特に補助金を使う場合は、対象経費と対象外経費、発注前着手の可否、証憑の残し方を見積段階で確認しておく必要があります。
参考にすべき一次情報・確認観点
見積書を社内稟議やベンダー比較に使う場合は、一般論だけで判断せず、公式資料と自社データを照合してください。特に契約形態、責任分界、DX投資の目的、セキュリティ要件は、見積金額より前にそろえるべき前提です。
- IPA「情報システム・モデル取引・契約書」：請負、準委任、成果物、検収、責任分界を確認する際の参考になります。
- 経済産業省「DX推進指標」：経営課題、ITシステム、組織体制を分けて、DX投資の目的を確認する際の参考になります。
- 自社の見積比較では、3社比較、5年TCO、月額5万円・10万円・15万円、画面20件、帳票10件、API3本、移行データ1000件、受入テスト5日、操作研修2回、障害受付24時間、初期予算500万円・1000万円など、仮でも数字を置いて前提をそろえます。
- AI開発、セキュリティ要件、補助金活用を含む案件では、機能要件だけでなく、ログ保管、個人情報、権限管理、証跡、補助対象経費の切り分けも見積条件に入れてください。
よくある質問
Q. 保守費は必ず契約しないといけませんか。
A. 必須ではありませんが、リリース後の不具合対応や問い合わせに備える意味があります。社内で対応できる範囲を整理し、足りない部分を保守でカバーする、という考え方が現実的です。自社にとってシステムが止まると困る度合いから、必要な水準を決めるとよいです。
Q. 「保守 月◯万円」だけの見積は、どう読めばよいですか。
A. 金額だけでなく範囲を確認します。不具合修正・機能追加・問い合わせのどこまで含むか、障害対応の受付時間はいつか、を聞くことで、同じ金額でも内容の違いが見えてきます。範囲が定義されているかどうかが、金額の大小よりも重要です。
Q. クラウドの利用料は、保守費に含まれますか。
A. 含まれないことが多く、別に実費がかかる場合があります。保守費と、クラウドや外部サービスの利用料を分けて確認しておくと、運用後にかかる費用を正しく見通せます。
Q. リリース直後にバグが見つかった場合、費用はかかりますか。
A. 多くの場合、リリース後一定期間は無償保証期間として、開発過程に起因するバグの修正に対応します。ただし、その期間の長さや「無償対象とするバグの定義」は会社によって異なります。発注前に「無償保証期間はどのくらいか」「仕様変更との区別はどうするか」を確認しておくと、リリース後の費用感が明確になります。
Q. 保守は途中で解約できますか。
A. 保守契約の更新・解約の条件は会社や契約の形によって異なります。定額保守の場合は契約期間の定めがあることが多く、途中解約に条件が設けられているケースもあります。発注前に「契約期間と解約条件」を確認しておくと、長期的な関係を見据えた判断ができます。
まとめ
保守費・運用費は、開発費に比べて見積書での扱いが小さくなりがちですが、システムを使い続けるうえで継続的に発生する費用です。「保守 月◯万円」という表記の裏にある範囲・SLA・障害対応の定義を確認し、抜けやすいクラウド利用料やバックアップの扱いも合わせて読むことで、リリース後の認識のずれを抑えられます。次回は、安い見積と高い見積の違いが、どこから生まれるのかを扱います。
関連記事
システム開発の見積・相見積もりを整理しませんか
GXOでは、システム開発の見積書、相見積もり、要件定義、開発会社選定について、発注前の整理をご支援します。総額だけでなく、工数、保守範囲、追加費用、体制、契約条件まで確認し、自社に合う進め方を一緒に整理します。
※ 初回相談では、営業資料の説明よりも見積内容と発注前の論点整理を優先します。
