毎月、保守費用を口座から引き落とされている。金額の妥当性も、何にいくら払っているのかも、実はよく分かっていない。そんな状態で業務システムを運用している経営者や情報システム担当者は、決して少なくありません。
契約時には「何かあったらすぐ対応します」「安心の保守サポートです」といった言葉に納得して押印したはずです。しかし実際にトラブルが起きたとき、「それは保守契約の対応範囲外です」「別途お見積りになります」と言われて初めて、自分たちが何にお金を払っていたのかを思い知る。この記事の読者の中にも、心当たりのある方がいらっしゃるのではないでしょうか。
この記事では、保守契約という「よく分からないまま払い続けているもの」を、契約書のどこを見て、何を確認し、何を交渉すればいいのかという具体的な行動に落とし込みます。問題を嘆くための記事ではなく、今日から契約書を開いて実践できるチェックリストとしてお使いください。
なぜ保守契約は「よく分からないまま」になりやすいのか
業務システムの保守契約が曖昧なまま結ばれてしまう背景には、いくつかの構造的な理由があります。
まず、システム開発の契約交渉は「作ってもらう」ことに意識が集中しがちです。要件定義、機能一覧、納期、開発費用。ここには経営者も担当者も時間をかけて確認します。しかし保守契約は、多くの場合、開発契約の最後に「あわせて保守契約もお願いします」という形で付随的に提示されます。すでに開発会社との信頼関係ができている状態で、しかも導入の疲労と安堵が入り混じったタイミングで提示されるため、細部まで読み込む気力が残っていないというのが実情です。
次に、保守契約は専門用語が多く、法務的な文言で書かれていることも一因です。「別紙記載の範囲を超える改修は別途協議」「営業日ベースでの対応を基本とする」といった表現は、一見丁寧に見えても、実際に何を意味するのかが読み手には伝わりにくく作られています。悪意があるとは限りませんが、結果として発注側に不利な解釈の余地を残したまま契約が成立してしまいます。
さらに、保守契約は「使わなければ損しない」という性質のサービスであるため、実際に不具合や追加要望が発生するまで、契約内容の粗さが表面化しません。トラブルが起きて初めて「これは対象外です」と言われ、そこで初めて契約書を読み返すことになる。しかしそのときにはすでに、システムはその会社に依存した状態になっており、交渉力を持ちにくいという悪循環が生まれます。
だからこそ、トラブルが起きる前、あるいは契約更新のタイミングという「まだ交渉できる余地があるとき」に、契約内容を能動的に点検しておく必要があるのです。
見落としがちな5つの条件
ここからは、実際に契約書を開いて確認すべき5つのポイントを具体的に解説します。手元に契約書がある方は、ぜひ実際に該当箇所を探しながら読み進めてください。
1. 対応範囲の明確さ
最も重要でありながら、最も曖昧にされやすいのが「保守の対象範囲」です。契約書に「システムの保守運用を行う」とだけ書かれていて、具体的に何が含まれ何が含まれないのかが列挙されていない場合、注意が必要です。
確認すべきは、次のような項目が明文化されているかどうかです。
- 不具合（バグ）の修正は保守範囲に含まれるか。含まれる場合、どのような不具合が対象か
- OSやミドルウェア、外部サービスの仕様変更に伴う追随対応は含まれるか
- 軽微な画面表示の調整や文言修正は含まれるか、それとも別料金か
- 操作方法に関する問い合わせ対応は含まれるか
- サーバーやデータベースの死活監視、バックアップの実施状況の確認は含まれるか
- 「軽微な改修」と「新規機能追加」の境界線がどこにあるか
特に見落とされがちなのが、最後の「軽微な改修」と「新規機能追加」の線引きです。この線引きが契約書に書かれていないと、発注側が「ちょっとした修正」と思っているものが、システム会社側では「新規開発」として別見積りされるという食い違いが頻発します。可能であれば、時間単位(工数目安)や具体例を契約書、あるいは覚書に残してもらうことをお勧めします。
2. レスポンスタイムの保証
「何かあったらすぐ対応します」という営業トークは、契約書に落とし込まれて初めて意味を持ちます。口頭の約束は、トラブル時には何の効力もありません。
確認すべきは以下の点です。
- 問い合わせをしてから、初回の返答(一次回答)までの時間は何時間、あるいは何営業日以内と定められているか
- その時間は「受付時間」であって「解決時間」ではないことを理解しているか(多くの契約では一次回答の速さのみを保証し、解決までの時間は保証していません)
- 障害の深刻度によって対応時間に差があるか(システム全体が停止する重大障害と、一部機能の軽微な不具合を同じ扱いにしていないか)
- 営業時間外、休日、深夜の障害発生時の対応体制と、その場合の追加費用の有無
- 担当者が不在・退職した場合のバックアップ体制があるか
特に中小企業の場合、システム会社側の担当者が実質的に一人しかいないというケースも珍しくありません。契約書に「担当者不在時も対応可能な体制を敷く」旨が書かれているか、あるいは口頭でも確認しておくことは、事業継続の観点から非常に重要です。
3. 追加費用が発生する境界線
保守契約でのトラブルの多くは、「追加費用が発生するかどうかの境界線」が曖昧なことに起因します。月額の保守費用に何が含まれ、何を超えると別料金になるのか。この境界線は、契約書上で数値化されているべきです。
確認したいポイントは次の通りです。
- 月あたり、あるいは年あたりの無償対応工数(時間)の上限があるか。上限を超えた場合の単価はいくらか
- 「軽微な改修」の定義に、作業時間や変更行数などの客観的な基準があるか
- 見積りが必要な作業について、見積り自体に費用は発生するか
- 緊急対応(休日・深夜)の場合の割増料金の有無と料率
- 外部サービス(決済代行、地図API、送信サービスなど)の仕様変更対応にかかる費用は、保守費用に含まれるか、都度請求か
特に、無償対応の工数上限が契約書に明記されていない場合は要注意です。上限がない代わりに「常識の範囲で」といった曖昧な表現になっているケースでは、システム会社側の裁量で「これは範囲外」と判断されるリスクが常に残ります。数字で書かれていない条件は、交渉の武器にもならないと考えておくべきです。
4. 契約更新時の値上げ条項
保守契約は多くの場合、1年ごとなどの自動更新となっています。ここで見落とされがちなのが、更新時の価格改定に関する条項です。
- 「更新時に協議のうえ料金を見直すことができる」といった条項が入っていないか
- 値上げの通知は、更新の何ヶ月前までに行われることになっているか
- 値上げに応じない場合、契約を解除できる猶予期間はどの程度あるか
- 過去の更新で値上げが発生した実績があるか、システム会社に確認したことがあるか
「協議のうえ」という表現は、一見公平に見えますが、実質的にはシステム会社側が一方的に金額を提示し、発注側が受け入れるかどうかしか選べない状態になっているケースが少なくありません。特にシステムの中身をシステム会社しか把握していない状態(いわゆるブラックボックス化)が進んでいると、値上げを拒否した場合の乗り換えコストが高くつくため、実質的に交渉力を失っています。
この状態を避けるためには、後述する「契約更新のタイミング」で、値上げの根拠を具体的に確認する習慣をつけることが重要です。
5. システム会社が倒産・撤退した場合の取り扱い
最後に、多くの経営者が想定していないリスクが、保守を担っているシステム会社そのものがなくなってしまう場合の取り扱いです。中小企業向けのシステム開発会社は、決して大手ばかりではありません。倒産、廃業、あるいは事業方針の転換による保守サービスからの撤退は、現実に起こり得ます。
確認すべきポイントは次の通りです。
- ソースコードの所有権、または少なくとも閲覧・入手できる権利が契約書に明記されているか
- システム会社が倒産・撤退した場合に、ソースコード一式が発注側に引き渡される取り決めがあるか(エスクロー契約のような形が理想です)
- 設計書やデータベース定義書など、他社が保守を引き継ぐために必要な資料が最新の状態で保管・共有されているか
- サーバーやドメインの契約名義が発注側にあるか、システム会社名義になっていないか
このリスクは発生確率こそ低いものの、いざ起きたときの損害は甚大です。ソースコードが手元になく、設計書もない状態でシステム会社が消えてしまえば、事実上そのシステムは使い続けられなくなり、ゼロから作り直すしかなくなります。これは保守契約の一項目というより、事業継続計画(BCP)の一部として捉えるべき問題です。
5つの条件を一覧で確認する
ここまで挙げた5つの条件は、それぞれ単独で見ると当たり前のことのように思えるかもしれません。しかし実際に契約書と照らし合わせると、5つのうち2つか3つしか明文化されていない、というケースがほとんどです。手元の契約書を開いて、次の観点で丸をつけながら確認してみてください。
- 対応範囲が、具体例を挙げて列挙されているか(単に「保守業務一式」とだけ書かれていないか)
- 一次回答までの時間、および障害の深刻度ごとの対応時間が数値で書かれているか
- 無償対応の工数上限、または「軽微な改修」の客観的な基準が数字で示されているか
- 更新時の値上げについて、通知時期と協議の進め方が具体的に定められているか
- ソースコードや設計書の引き渡しについて、システム会社の廃業・撤退時の取り決めがあるか
この5つのうち、ひとつでも「該当する記載が見当たらない」という項目があれば、それは今後トラブルになり得る空白地帯です。空白のまま放置するのではなく、次の契約更新のタイミング、あるいは今すぐにでも、システム会社に確認の連絡を入れることをお勧めします。多くの場合、システム会社側も悪意があって曖昧にしているわけではなく、単に契約書のひな形が古いまま更新されていないだけ、ということも少なくありません。率直に尋ねれば、覚書という形で条件を追記してもらえるケースも多いのです。
社内で契約を確認する体制をどう作るか
保守契約の内容を一度確認しただけでは、根本的な解決にはなりません。担当者が異動や退職をすれば、また同じように「よく分からないまま払い続ける」状態に戻ってしまうからです。そこで重要になるのが、契約内容を組織の記憶として残す仕組みです。
具体的には、次のような取り組みが有効です。
まず、保守契約の内容を、契約書そのものとは別に、社内向けの一枚のサマリーにまとめておくことです。対応範囲、レスポンスタイム、追加費用の境界線、更新時期、緊急連絡先。これらを箇条書きで整理し、誰が見ても数分で理解できる状態にしておきます。契約書の原本を読み込まなくても、このサマリーを見れば「今、自社がどんな保守を受けているか」が分かる状態を作ることが目的です。
次に、実際にシステムに関するトラブルや問い合わせが発生した際には、その都度、対応内容と、無償だったか有償だったかを簡単に記録しておきます。これが冒頭で触れた「更新時の交渉材料」になるだけでなく、担当者が変わった際の引き継ぎ資料にもなります。エクセルやスプレッドシートに数行書き足すだけで構いません。継続することに意味があります。
そして、契約更新の時期を、担当者個人のスケジュールではなく、会社としてのタスクとして管理することです。属人化した記憶に頼っていると、担当者の異動や退職とともに、更新のタイミングを逃し、内容を確認しないまま自動更新されてしまうリスクが高まります。カレンダーや業務管理ツールに、更新の1〜2ヶ月前にリマインドが立つよう設定しておくだけでも、大きな違いが生まれます。
契約更新のタイミングで確認・交渉すべきこと
保守契約を見直す最も現実的な機会は、契約更新のタイミングです。すでに動いている契約を途中で変更してもらうのは心理的なハードルがありますが、更新時であれば「次の1年をどうするか」という自然な話し合いの場として交渉を持ち出せます。
更新の連絡が来たら、次のことを実行してください。
まず、この1年間で実際に発生した保守対応の履歴を洗い出します。何件の問い合わせがあり、そのうち何件が無償対応で、何件が追加請求になったか。追加請求になったものの内訳は何だったか。これを整理するだけで、自社のシステムにとって本当に必要な保守内容が見えてきます。使っていない機能のための保守費用を払い続けている、というケースは意外と多いものです。
次に、値上げが提示された場合は、その根拠を具体的に尋ねます。「物価上昇のため」「人件費の高騰のため」という説明だけで納得せず、対応工数や対応件数の実績と照らし合わせて妥当かどうかを判断します。根拠を説明できない値上げには、応じる必要はありません。
そして、この1年で見えてきた不満や懸念(レスポンスが遅かった、対応範囲の認識にズレがあった、担当者が変わって引き継ぎが悪かったなど)を、更新のタイミングでまとめて伝え、契約書または覚書に反映してもらうよう依頼します。口頭でのやり取りだけで終わらせず、書面に残すことが次のトラブルを防ぎます。
最後に、他社への相見積りを取ることも選択肢として持っておくべきです。実際に乗り換えるかどうかは別として、市場価格の相場観を持っているだけで、現在の契約が適正かどうかの判断材料になり、交渉においても発注側の姿勢が変わります。
保守契約が適正かどうかを見極める視点
個別の条件を確認したうえで、最終的に「この保守契約は適正か」を判断するには、次のような視点で全体を眺めることが役立ちます。
ひとつは、支払っている金額と、実際に受けているサービスの量・質が見合っているかという視点です。月々の保守費用に対して、実際の問い合わせ対応件数や対応時間がどの程度か。これがほとんどゼロに近いのであれば、それは「安心料」として妥当な金額なのか、それとも払い過ぎなのかを冷静に考える必要があります。逆に、対応件数が多いのに費用が据え置かれている場合は、システム会社側が無理をして安価に対応してくれている可能性もあり、その関係性が長続きするかどうかも考慮すべきです。
もうひとつは、契約内容が「言葉で説明できる」状態になっているかという視点です。対応範囲、レスポンスタイム、追加費用の境界線、これらすべてを自社の担当者が他の人に説明できる状態になっていれば、その契約は適正である可能性が高いといえます。逆に、担当者自身が「よく分からないけれど、とりあえず払っている」状態であれば、それは契約が曖昧である証拠です。
そして最後に、システム会社との関係性が対等かどうかという視点も見逃せません。良い保守契約とは、単に安い契約のことではなく、何かあったときに率直に相談でき、無理な要求には無理だと言ってもらえ、かつ根拠のある提案をしてもらえる関係性の上に成り立つものです。金額の多寡だけでなく、こうした関係性が築けているかどうかも、適正さを見極める重要な材料になります。
陥りやすい失敗
最後に、保守契約をめぐって多くの企業が陥りがちな失敗のパターンを挙げておきます。
最も多いのが、「言われるがままに更新し続ける」失敗です。契約更新の通知が来て、金額もこれまでと大きく変わらなければ、内容を確認せずにそのまま押印してしまう。これを何年も繰り返すうちに、契約は時代に合わなくなり、自社の利用実態ともかけ離れていきます。毎年、たとえ5分でも契約書に目を通し、この記事で挙げた5つの条件を確認する習慣を持つだけで、この失敗は避けられます。
次に多いのが、「トラブルが起きてから交渉しようとする」失敗です。障害が発生し、対応が遅い、追加費用を請求されたというタイミングで初めて契約書を持ち出して交渉しようとしても、感情的な対立が先に立ってしまい、建設的な話し合いになりにくいものです。交渉は、平時の、契約更新というニュートラルなタイミングで行うのが得策です。
また、「一社に依存しきってしまう」失敗も見逃せません。相見積りも取らず、他の選択肢を検討することもなく、目の前のシステム会社との関係だけに頼り続けると、いざというときの交渉力を完全に失います。良好な関係を保ちながらも、常に他の選択肢を知っておくというバランス感覚が必要です。
逆に、「安さだけで乗り換えを繰り返す」ことも失敗につながります。保守契約は、システムの内部構造を理解している担当者との信頼関係があってこそ機能する部分が大きく、安易な乗り換えは、かえって引き継ぎコストや初期対応の遅さという形で跳ね返ってくることがあります。金額だけでなく、この記事で挙げた条件全体を総合的に見て判断することが大切です。
さらに見過ごされがちなのが、「担当者間の口約束を契約書に反映しない」失敗です。日々のやり取りの中で、システム会社の担当者から「次からはこういう対応にしますね」「今回は特別に無償でやっておきます」といった柔軟な対応をしてもらえることがあります。これ自体はありがたいことですが、その内容を書面に残さず、口頭のやり取りだけで終わらせてしまうと、担当者が変わった瞬間になかったことにされてしまいます。良い条件を引き出せたときほど、それをメールの記録やちょっとした覚書として残しておく習慣が、将来の自社を守ります。
まとめ
保守契約は、一度結んでしまうと見直す機会が少なく、気づけば何年も「よく分からないまま」払い続けてしまうものです。しかし、対応範囲、レスポンスタイム、追加費用の境界線、更新時の値上げ条項、システム会社撤退時の取り扱いという5つの条件を具体的に確認するだけで、この状態から抜け出すことができます。
大切なのは、完璧な契約書を目指すことではありません。自社にとって何が必要で、何にいくら払っているのかを、経営者自身の言葉で説明できる状態にしておくことです。それができていれば、トラブルが起きても、値上げを打診されても、冷静に、対等な立場で話し合うことができます。
私たちオルアナは、システムを作って終わりにするのではなく、それを使い続ける経営者や現場の担当者が、日々の運用の中で不安を抱えずに前へ進めることを大切にしています。契約書の条項ひとつひとつは細かく地味な話に見えるかもしれませんが、その先には、システムを武器にして事業の壁を越えていこうとする経営者の姿があります。保守契約の見直しは、そのための小さくても確かな一歩です。もし今の契約に少しでも違和感があれば、私たちにご相談ください。曖昧なままにせず、次の一歩を一緒に確認していきましょう。
この記事はシステム開発の費用相場 完全ガイドの一部です。