月額保守費で何をやってもらえるのか

「この作業も保守費に含まれますよね」と開発会社に確認したら、「それは保守の範囲外なので、別途お見積りになります」と返ってきた——毎月きちんと保守費を払い続けているのに、いざ何かを依頼するたびに追加費用の話が出てくる。この記事は、そんな戸惑いを感じたことがある担当者に向けて書いています。

結論を先に言うと、月額保守費で「何をやってもらえるか」は、契約書の中の対応範囲・作業時間・SLA(サービス品質保証、対応時間や復旧目標などのサービス水準を数値で定めた基準)の3点を突き合わせれば把握できます。逆に言えば、この3点を確認しないまま「保守費を払っているから何でもやってもらえるはず」という思い込みで運用していると、追加費用の請求のたびに驚くことになります。

すでに保守契約を結んでいる方に向けて、次のような疑問に答えていきます。今の契約でどこまでの作業が保守費に含まれているのかをどう調べればよいか。「軽微な修正」と「仕様変更」の境界はどこにあるのか。月の作業量に上限がある契約とない契約はどう違うのか。開発会社に確認すべきことを聞きにくいと感じたとき、どう切り出せばよいか。読み終える頃には、次に開発会社へ作業を依頼するとき、それが保守費の範囲内なのか追加費用が発生するのかを、事前にある程度予測できるようになっているはずです。

なお、これから保守契約を結ぶ、あるいは結ぶかどうかを検討している段階の方は、契約前に確認すべき事項を整理した『保守契約の内容を契約前に確認すべき理由』を先に読むことをおすすめします。この記事は、すでに契約を結んで運用している方が「今の契約で実際どこまでカバーされているか」を把握するための記事です。

この記事で分かること

月額保守費を払っているにもかかわらず、実際にどこまでの作業がその費用でカバーされているのかを把握できていない担当者に向けて、契約書の読み解き方と、開発会社とのやり取りの中で範囲を確認する実務的な方法を解説します。保守費に含まれる作業の典型的な内訳、対応範囲を分ける境界線の考え方、月の作業量に上限がある契約の仕組み、追加費用が発生しやすい典型パターン、そして開発会社に範囲を確認する際の具体的な聞き方までを扱います。「なんとなく払っている保守費」を、「どこまでカバーされているか説明できる保守費」に変えることがこの記事のゴールです。

なぜ「払っているのに追加費用」が起きるのか

まず、なぜこのようなすれ違いが起きるのかを整理しておきます。理由は大きく2つあります。

1つ目は、保守契約における「保守」という言葉の範囲が、法律や業界で統一的に定義されているわけではないという点です。ある開発会社にとっての「保守」は不具合修正のみを指し、別の開発会社にとっての「保守」は軽微な仕様変更や問い合わせ対応まで含む、というように、同じ「保守契約」という名称でも実際の中身は会社ごとに異なります。契約書に対応範囲が具体的に書かれていれば問題は起きにくいのですが、「システムの保守運用一式」といった抽象的な記載にとどまっている契約書も少なくありません。

2つ目は、契約を結んだ時点と、実際に運用が始まってからの間に時間差があるという点です。契約時には「不具合対応をお願いします」という認識合わせで済んでいたものが、半年、1年と運用が進むうちに、「この程度なら保守の範囲でやってもらえるだろう」という発注者側の期待値が、契約書に書かれた範囲よりも先に広がっていくことがあります。これは発注者側の落ち度というより、日々の運用の中で自然に起きる認識のズレです。

「保守契約を結んでいるから、何かあれば全部無償でやってもらえる」という理解は、契約書の実際の記載内容と一致しないことが多くあります。保守費は、決まった範囲の作業を継続的に提供するための対価であり、無制限のサポート契約ではありません。

この構図を理解したうえで、次章から実際に「何が保守費に含まれるのか」を具体的に見ていきます。

保守費に一般的に含まれる作業の内訳

保守契約の内容は会社ごとに異なりますが、多くの保守契約に共通して含まれやすい作業と、含まれないことが多い作業を整理すると、次のように分類できます。

保守費に含まれやすい作業

• 不具合修正：仕様書・要件定義書に記載された動作と、実際の動作が異なっている場合の修正
• サーバー・インフラの監視：稼働状況の監視、障害発生時の一次対応
• セキュリティパッチの適用：OSやミドルウェアの脆弱性対応(パッチマネジメント)
• 軽微な設定変更：管理画面の表示項目の並び替えなど、実装の変更を伴わない設定レベルの調整
• 定期的なバックアップの実施と確認
• 問い合わせ対応窓口の維持：「これはどう操作すればよいか」といった操作方法の質問への回答

保守費に含まれないことが多い作業

• 新機能の追加開発
• 仕様変更を伴う修正：仕様書に記載のなかった動作への変更
• デザインの変更：見た目のレイアウトやデザインを作り直す作業
• 外部サービスとの新規連携
• 大量データの移行・加工作業
• 他社が開発した部分への調査・修正(自社が別のシステムを追加導入した場合など)

この分類はあくまで一般的な傾向であり、実際にどこまでが自社の契約に含まれるかは、契約書の「対応範囲」の条項を確認しなければ分かりません。次の章で、契約書のどこを見ればこの範囲が分かるのかを説明します。

契約書のどこを見れば分かるか

対応範囲を確認する際、多くの担当者が契約書の第1条(目的)や前文だけを見て「保守業務を委託する」という抽象的な文言しか見つけられず、そこで確認をあきらめてしまいます。しかし、対応範囲の具体的な記載は、多くの場合、契約書本体ではなく別紙のSOW（作業範囲記述書）や仕様書、あるいは見積書の内訳に記載されています。

確認すべき書類は主に次の3種類です。

契約書本体に対応範囲の詳細が書かれておらず、かつ別紙のSOWも見当たらない場合は、口頭やメールでの合意しか根拠がない状態である可能性があります。この場合、まずは開発会社に「対応範囲を明記した書面(別紙でもメールでの確認でも構いません)を共有してもらえないか」と依頼することをおすすめします。書面がないまま運用を続けると、追加費用が発生するたびに「言った・言わない」の水掛け論になりやすいためです。

「軽微な修正」と「仕様変更」の境界線

保守費の範囲を巡るトラブルで最も多いのが、「軽微な修正」だと思って依頼した作業が、開発会社側からは「仕様変更」として扱われ、追加費用を請求されるケースです。この境界線は、『リリース後の不具合、無償対応と有償対応の境界線』で詳しく解説した「無償対応と有償対応の境界線」の考え方がそのまま当てはまります。

境界線の基本原則は、仕様書・要件定義書に書かれていた内容と、実際の動作が食い違っているかどうかです。

• 仕様書に「合計金額は税込で表示する」と書かれているのに、実際は税抜で表示されている → 不具合。無償修正の対象になりやすい
• 仕様書に金額表示の税込・税抜について記載がなく、後から「税込表示にしてほしい」と依頼する → 仕様変更。追加費用の対象になりやすい

厄介なのは、発注者側の感覚では「ちょっとした調整」に見える依頼でも、開発会社側の実装工数としては決して軽微ではないケースがある点です。たとえば「ボタンの色を変えてほしい」という依頼は、担当者の感覚では数分の作業に思えても、実際にはデザインガイドラインの見直しや、他の画面との整合性確認、テストの実施を伴う場合があります。逆に、担当者からすると重大に見える不具合が、開発会社にとっては数行の修正で完了する場合もあります。

この感覚のズレを埋めるために有効なのが、依頼を出す際に「これは仕様書のどの記載と食い違っていますか、それとも新しい要望ですか」という切り口で尋ねることです。この質問自体が、開発会社側にも「今回の依頼が保守範囲内かどうか」を明確に回答する動機を作ります。

月の作業量に上限がある契約の仕組み

保守契約の中には、月額固定の料金の中に「月◯時間まで」「月◯件まで」という工数の上限が設定されているものがあります。この上限を超えた分は、追加費用が発生するか、翌月に繰り越されるか、あるいは単純に対応を待たされるかは、契約形態によって異なります。

工数上限の有無と、それを超えた場合の扱いは、次のようなパターンに分かれます。

• 上限なし・追加費用なし：対応範囲内の作業であれば、量にかかわらず月額固定で対応する契約。開発会社側のリスクが大きいため、料金が高めに設定されていることが多い
• 上限あり・超過分は追加費用：月◯時間までは月額に含み、超過分は時間単価で精算する契約。最も一般的な形態
• 上限あり・超過分は翌月繰り越し：使わなかった工数を翌月に持ち越せる契約。繁忙期と閑散期の差が大きいシステムに向く
• ポイント制・チケット制：作業内容ごとにポイントやチケットを消費し、保有分がなくなると追加購入が必要になる契約

自社の契約がどのパターンに該当するかを把握しないまま運用していると、「今月は依頼が多かったから請求が跳ね上がった」という状況に気づかず、翌月の請求書を見て初めて驚くことになります。月ごとの保守関連の請求額を記録しておき、変動があった月には理由を確認する習慣をつけておくと、こうした驚きを減らせます。

追加費用が発生しやすい典型パターン

実際の運用の中で、保守費の範囲を超えて追加費用が発生しやすい場面には、いくつかの典型パターンがあります。あらかじめ知っておくことで、依頼の前に「これは追加費用の対象かもしれない」と予測できるようになります。

• 法改正・制度変更への対応：インボイス制度や税率変更など、外部要因による仕様変更は、既存の仕様書に記載がなかった以上、仕様変更として扱われることが多い
• 利用人数・データ量の急増に伴う性能対応：想定を超えた利用者数やデータ量によって動作が重くなった場合の対応は、規模の見直しとして追加見積もりになりやすい
• 他社が導入した新しいSaaSとの連携：既存の保守対象システムに含まれない外部サービスとの連携は、新規開発の扱いになりやすい
• 旧システムのEOL（サポート終了）対応：使用しているソフトウェアやミドルウェアのサポート終了に伴う移行作業は、保守の範囲を超えた個別プロジェクトとして扱われることが多い
• ブラウザ・OSのバージョンアップへの追従：利用環境の変化に伴う動作確認・修正は、契約書に「動作環境の維持」が明記されていない限り、都度対応になることがある

これらはいずれも「発注者側の落ち度ではないが、契約の対応範囲には含まれていない」という点で共通しています。年に1度程度、こうした外部要因の変化がないかを振り返り、必要であれば開発会社と事前に相談しておくと、突発的な追加費用の請求を減らせます。

よくある勘違いのケーススタディ

対応範囲についての認識のズレは、抽象的に説明されてもピンと来にくいものです。ここでは、実際に起きやすい3つの場面を具体的に見ていきます。

ケース1：Excel帳票の書式が崩れた

経理担当者が使っている見積書出力機能で、ある日から金額の桁がずれて表示されるようになった。担当者は「不具合だから無償で直してもらえるはず」と考え、開発会社に連絡したところ、「OSのアップデートに伴うExcelの表示仕様の変化によるもので、当方の実装ミスではありません。動作環境の維持は契約範囲に含まれていないため、別途対応のお見積りとなります」という回答が返ってきた。

この場合、仕様書に「Excelのバージョンアップに追従して表示を維持する」という記載がなければ、開発会社側の説明にも一定の理があります。一方で、契約書に「動作環境の維持」が保守範囲に含まれる旨が明記されていれば、無償対応を求められる可能性があります。判断のカギは、やはり契約書・仕様書の記載内容に戻ってくることが分かります。

ケース2：問い合わせ対応のはずが仕様変更に発展した

「この画面の使い方が分からない」という社内からの問い合わせを受け、担当者が開発会社に操作方法を確認したところ、「その操作は現在の仕様では実現できません。実現するには機能追加が必要です」と言われた。当初は単純な問い合わせ対応(保守費に含まれる作業)のつもりが、結果的に機能追加(保守費に含まれない作業)の話にすり替わっていた、というケースです。

こうした場合、「今回の件は問い合わせ対応で完結するのか、それとも機能追加が必要な話なのか」を早い段階で切り分けて確認する習慣があると、後になって「いつの間にか追加費用の話になっていた」という驚きを防げます。

ケース3：軽微な文言修正のつもりが多数ファイルへの影響が判明した

サイト内の「お問い合わせ」という表記を「お問合せ」に統一してほしいという、担当者から見ればごく軽微な依頼が、実際には数十ページにまたがる文言修正であることが判明し、開発会社から「今回は文言統一のガイドライン整備も含めた対応になるため、別途お見積りします」と言われた。

この例のように、依頼の性質自体は「軽微な修正」に見えても、影響範囲の大きさによって工数が跳ね上がり、保守費に含まれる作業の想定を超えることがあります。依頼を出す前に、影響範囲がどの程度になりそうかを開発会社に概算で確認しておくと、こうした想定外の見積もりを減らせます。

保守費の範囲を確認すべきタイミング

対応範囲の確認は、思い立ったときに一度やれば終わりというものではありません。特に確認しておくべきタイミングが3つあります。

• 契約更新のタイミング：多くの保守契約は1年更新です。更新の稟議を通す前に、この1年で対応範囲の解釈にズレがなかったかを振り返り、次年度の契約に反映すべき点がないかを確認する
• 担当者の異動・引き継ぎのタイミング：後任者が保守契約の内容を正しく理解しないまま運用を引き継ぐと、同じ確認作業をゼロからやり直すことになる。引き継ぎ資料に対応範囲の要約を残しておく
• システムに大きな変化があったタイミング：利用人数の増加、新しい業務での利用開始、外部サービスとの連携追加など、契約時点と状況が変わった場合は、対応範囲がその変化に対応できているかを確認する

これらのタイミングを逃さないためには、社内のカレンダーやシステム管理台帳に、保守契約の更新月や確認事項をあらかじめメモしておくことが有効です。年に一度、決まった時期に振り返る仕組みを作っておけば、担当者の記憶や気づきだけに頼らずに済みます。

保守費以外の費用と混同しないための整理

保守費の範囲を考えるうえで、もう1つ注意しておきたいのが、保守費とは別枠で発生している他の費用との混同です。中小企業のシステム運用では、次のような費用が保守費と一緒に請求書に並んでいることがあり、どこまでが保守費でどこからが別費用なのかが分かりにくくなっている場合があります。

• サーバー・クラウドの利用料：AWSやレンタルサーバーなど、インフラそのものの利用料。保守費とは別に、実費として請求されることが多い
• ドメイン・SSL証明書の更新費用：年単位で発生する費用で、保守費に含まれている場合と、別途請求される場合がある
• 外部SaaSのライセンス費用：システムが連携している外部サービスの月額利用料
• ライセンス費用の代行請求：開発会社が代理で契約しているソフトウェアのライセンス費用を、保守費と合算して請求している場合

請求書の内訳が「保守費一式」とまとめて記載されている場合、この中に何が含まれているのかが見えづらくなります。可能であれば、請求書の内訳を保守作業分とインフラ・ライセンス実費分とで分けて記載してもらうよう依頼すると、保守費そのものの妥当性を評価しやすくなります。

開発会社に範囲を確認する際の聞き方

対応範囲を確認したいと思っても、「今さら契約内容を聞くのは気まずい」「専門用語が多くて何を質問すればよいか分からない」と感じて、確認を先延ばしにしてしまう担当者も少なくありません。しかし、対応範囲の確認は、契約している当事者として当然の権利であり、遠慮する必要はありません。

具体的には、次のような聞き方であれば、開発会社側も回答しやすくなります。

「現在の保守契約で対応いただける作業の範囲を、あらためて書面(別紙やメールでの整理で構いません)で確認させていただけますでしょうか。今後の依頼の際に、保守範囲内か追加見積もりが必要かを事前に判断できるようにしておきたいと考えています」

このように「疑っている」のではなく「事前に判断できるようにしたい」という前向きな理由を添えると、開発会社側も協力的に対応しやすくなります。実際に確認すべき項目は、次のチェックリストにまとめます。

1. 現在の保守費に含まれる作業の種類(不具合修正、軽微な設定変更、問い合わせ対応など)を書面で確認する
2. 月あたりの工数上限の有無と、超過時の扱い(追加費用・繰り越し・翌月対応)を確認する
3. 「軽微な修正」と「仕様変更」を分ける社内の判断基準があれば教えてもらう
4. 障害発生時のSLA（サービス品質保証）、特に一次対応までの目標時間を確認する
5. 追加費用が発生する場合の見積もりプロセス(誰が承認し、どの程度の期間で見積もりが出るか)を確認する
6. 保守の窓口担当者と、対応できない場合のエスカレーション先を確認する

これらの確認は、一度に全部を聞く必要はありません。次回の定例のやり取りや契約更新のタイミングに合わせて、少しずつ確認していく形でも十分です。重要なのは、確認した内容を書面やメールの形で残しておくことです。口頭での回答だけでは、後で「そう言った・言っていない」の水掛け論になりかねません。

保守費の範囲を可視化しておく効果

対応範囲を確認し、書面として残しておくことには、追加費用の予測ができるようになる以外にも実務上のメリットがあります。

まず、担当者の異動や引き継ぎの際に、後任者が保守契約の内容をゼロから開発会社に確認し直す必要がなくなります。属人的な口頭理解に頼っていた保守運用の実態を、書面という形で残しておくことは、属人化対策の一環にもなります。社内のシステム管理台帳や引き継ぎ資料に、保守契約の対応範囲を要約して記載しておくと、こうした引き継ぎの負担を大きく減らせます。

また、保守費が適正かどうかを見直す際の材料にもなります。対応範囲が明確になっていれば、他社に見積もりを依頼する際の比較条件をそろえやすくなり、見直しの議論が具体的になります。保守費そのものの見直しについては、『月額保守費の相場と見直し方』で詳しく扱っていますので、対応範囲を把握したうえで金額の妥当性を検討したい場合は、あわせて参照してください。

さらに、仕様変更や追加開発の依頼を出す際にも、事前に「これは保守の範囲外である」という前提を持って相談できるため、開発会社とのやり取りがスムーズになります。仕様変更や追加要望の伝え方そのものについては、『仕様変更・追加要望の正しい伝え方と追加費用の考え方』で詳しく扱っていますので、あわせて確認しておくとよいでしょう。

複数の開発会社に分かれて保守を委託している場合の注意点

自社のシステムが1社ではなく、複数の開発会社にまたがって保守されている場合、対応範囲の確認はさらに重要になります。たとえば、基幹システムはA社、社内で使っているVBAマクロ(Excel等で業務を自動化するために書かれたプログラム)はB社、Webサイトの保守はC社、というように分かれているケースは中小企業では珍しくありません。

このような体制で問題になりやすいのが、システム間の連携部分で不具合が起きたときに、どちらの保守範囲に該当するのかが曖昧になることです。

• A社のシステムから出力したCSVを、B社が管理する社内ツールが読み込めなくなった場合、原因はA社の出力形式の変更にあるのか、B社の読み込み処理の不具合にあるのか、切り分けに時間がかかる
• どちらの会社も「自社の担当範囲では正常に動作している」と主張し、対応の押し付け合いになる

こうした事態を避けるためには、複数の開発会社が関わるシステム構成である場合、それぞれの保守契約で「どこからどこまでが自社の担当範囲か」を明記してもらい、連携部分の不具合が起きた際にどちらが一次窓口になるかを、契約時点であらかじめ取り決めておくことが有効です。すでに複数社体制で契約を結んでしまっている場合も、次の更新のタイミングで、この連携部分の責任分界点を確認しておくことをおすすめします。社内のシステム管理台帳に、どのシステムをどの会社が保守しているかを一覧化しておくと、こうした確認や、担当者交代時の引き継ぎがスムーズになります。

保守費の交渉で「範囲を広げる」という選択肢

ここまでは、現在の保守契約の範囲を正確に把握することを中心に説明してきましたが、把握した結果、「今の対応範囲では業務上不安が残る」と感じることもあるはずです。その場合、単に保守費を値切る方向だけでなく、保守費を適正に上げてでも対応範囲を広げるという選択肢も検討する価値があります。

たとえば、次のようなケースでは、対応範囲を広げる交渉が現実的な選択肢になります。

• 現在は平日日中のみの対応だが、業務上、休日や夜間にシステムが止まると大きな支障が出る
• 軽微な仕様変更のたびに都度見積もりが発生し、その都度の事務手続きの負担が大きい
• 問い合わせ対応の窓口が不明確で、緊急時にどこに連絡すればよいか分からない

対応範囲を広げる交渉をする際は、「なんとなく不安だから」ではなく、「過去にこのような場面で困った」という具体的な事例を根拠として示すと、開発会社側も必要性を理解しやすくなります。あわせて、対応範囲を広げることで保守費がどの程度上がるのかを事前に見積もってもらい、社内の予算と照らし合わせたうえで判断することをおすすめします。

まとめ

月額保守費で何をやってもらえるのかを把握するために、最も重要なのは「対応範囲」「工数上限の有無」「軽微な修正と仕様変更の境界」の3点を、契約書または開発会社への確認を通じて言語化しておくことです。

• 保守費に含まれる作業は会社ごとに異なり、契約書の抽象的な記載だけでは分からないことが多い
• 対応範囲の具体的な記載は、契約書本体よりも別紙のSOWや見積書に書かれていることが多い
• 「軽微な修正」と「仕様変更」の境界は、仕様書に書かれていた内容と実際の動作が食い違っているかどうかで判断する
• 月あたりの工数上限の有無と、超過時の扱いを把握しておくと、請求額の変動に驚かずに済む
• 対応範囲の確認は書面で残し、担当者の異動時にも引き継げる状態にしておく

保守費の範囲を把握することは、一度確認して終わりではなく、システムの利用状況やビジネス環境の変化に応じて、定期的に見直していくべきものです。次に開発会社へ何かを依頼するときは、この記事で整理した観点を手元に置きながら、「これは保守の範囲内か、それとも追加費用の対象か」を事前に確認する習慣をつけてみてください。

実際に不具合や修正依頼が発生した際、検収の段階でどこを確認し、どう報告すればスムーズに対応してもらえるかについては、『検収で見るべきポイントと不具合対応の依頼方法』で具体的な手順を解説しています。あわせてご覧ください。