先代から会社を継いだとき、多くの後継社長が最初に驚くのが「保守契約」というものの存在です。基幹システムにも、ホームページにも、販売管理ソフトにも、たいてい年間契約や月額契約の「保守」がついています。しかし、その中身を細かく確認したことがある後継社長は、実はそれほど多くありません。先代が「昔からお願いしている業者さんだから」という理由で継続してきた契約を、意味もわからないまま引き継いでしまっているケースが非常に多いのです。
本記事では、なぜ保守契約は契約前（更新前）にしっかり内容を確認しなければならないのか、確認すべき具体的なポイントは何か、そして確認を怠るとどんな失敗が起きるのかを、事業承継直後の後継社長・後継者の目線で解説します。専門用語はできるだけ避け、避けられないものは都度説明を添えます。既存の取引先そのものを見直すか迷っている場合は、危険な開発会社のサイン10選、承継社長が見極めるポイントもあわせて確認してほしい。
なぜ「保守契約」は見落とされやすいのか
事業承継の場面では、株式や不動産、金融機関との取引、取引先との関係といった「目に見えやすいもの」の引き継ぎには時間がかけられます。一方で、システムの保守契約のような「毎月自動的に請求書が届くだけのもの」は、承継の優先順位が低くなりがちです。
先代経営者にとっても、保守契約は「よくわからないが、止めると何か困りそうだから払い続けているもの」という位置づけになっていることが少なくありません。実際に筆者らが後継社長からヒアリングする中でも、以下のような声が非常に多く聞かれます。
- 「月3万円のシステム保守費を払っているが、何をしてもらっているのか分からない」
- 「先代が亡くなってから、契約書自体がどこにあるのか分からない」
- 「システムが壊れたときに保守業者に連絡したら、契約範囲外だと言われて追加費用を請求された」
- 「保守契約を切ろうとしたら、業者から『データを人質に取られたような対応』をされた」
これらはすべて、保守契約の内容を契約前・更新前にきちんと確認していなかったことが遠因になっています。事業承継を機に、今一度すべてのシステム保守契約を棚卸しすることを強くおすすめします。
保守契約とは何か、まず基本を整理する
「保守契約」とひとくちに言っても、実際には性質の異なる複数の契約が混在していることがあります。契約書のタイトルだけで判断せず、中身を見て仕分けることが重要です。
保守契約に含まれがちな要素
- 不具合対応(バグフィックス) — システムが正常に動かなくなったときの修正
- 問い合わせ対応(ヘルプデスク) — 「これはどう操作すればいいか」といった質問への回答
- サーバー・インフラの維持管理 — サーバーの死活監視、バックアップ、セキュリティパッチ適用
- 軽微な改修 — 画面の文言修正、印刷レイアウトの微調整など
- 法改正対応 — 消費税率変更、インボイス制度対応など、外部要因で必要になる改修
- バージョンアップ対応 — OSやミドルウェアの更新に追従するための改修
これら6つが、月額いくらの契約の中にどこまで含まれているのかは、業者によって、そして契約書によってまったく異なります。「保守契約を結んでいるから安心」という思考停止が一番危険です。契約書に「善良な管理者の注意をもって保守を行う」といった抽象的な文言しか書かれておらず、上記のどこまでをカバーするのかが一切具体化されていない契約も珍しくありません。
保守契約と開発契約(請負契約)の違い
事業承継直後によくある混乱が、「新規開発の契約」と「保守契約」を混同してしまうことです。新しいシステムを開発してもらう際の契約は、多くの場合請負契約という形式で結ばれます。これは成果物(完成したシステム)を納品することを約束し、その対価として報酬が支払われる契約形態です。
一方、保守契約は「完成したシステムを一定の作業水準で維持し続けること」を目的とした契約であり、月々の作業内容や対応時間帯を約束する準委任的な性格を持つことが多くあります。この違いを理解していないと、「保守契約を結んでいるのだから、追加の機能開発も無償でやってもらえるはずだ」という誤解が生まれ、業者との関係がこじれる原因になります。請負契約と準委任契約そのものの違いをきちんと押さえておきたい場合は、請負契約と準委任契約、何がどう違うのかを参照してほしい。
保守契約を確認する際は、まず「これは既存システムの維持のための契約なのか、それとも新規の開発案件が保守という名前で紛れ込んでいるだけなのか」を切り分けてください。この切り分けができていないと、次に説明する費用トラブルに直結します。
契約前に確認すべき8つのポイント
ここからは、保守契約を新規に結ぶとき、あるいは既存の契約を更新するときに、必ず目を通すべき8つのチェックポイントを解説します。先代から引き継いだ契約書がある場合は、今すぐ引っ張り出して照らし合わせてみてください。
1. 保守の対象範囲(スコープ)が具体的に書かれているか
最も重要なのがこの点です。「システム全般の保守」というような曖昧な書き方ではなく、「対象システム名」「対象サーバー」「対象となる機能一覧」まで具体的に列挙されているかを確認してください。
開発を依頼する際に交わすSOW（作業範囲記述書）と呼ばれる文書があれば、そこに記載された機能一覧と保守契約の対象範囲が一致しているか突き合わせることをおすすめします。もし新規に開発会社を選ぶ段階であれば、保守フェーズに入る前の見積もり時点で、どこまでが保守費用に含まれ、どこからが追加費用になるのかを明文化してもらいましょう。
チェック例:
- 対象システムはどのサーバー上で稼働しているどのプログラム一式か、明記されているか
- 連携している外部システム(会計ソフト、決済代行、配送業者のAPIなど)の不具合は保守範囲に含まれるか、除外されているか
- スマートフォンアプリがある場合、iOS版・Android版それぞれが対象に含まれているか
2. 対応時間帯と対応スピード(SLA)
「保守契約を結んでいるから、何かあればすぐ来てくれる」と思い込んでいる後継社長は少なくありません。しかし実際には、平日9時〜18時のみの対応で、休日夜間は翌営業日回しという契約がほとんどです。小売業や飲食業など、休日・夜間にこそシステムが稼働している業種であれば、この時間帯の縛りは死活問題になり得ます。
- 障害発生から一次回答までの目安時間は何時間か
- 休日・夜間の緊急対応は可能か、可能な場合は別料金か
- 「軽微な不具合」と「システム停止を伴う重大な不具合」で対応優先度に差があるか
3. 保守費用に何が含まれ、何が追加費用になるのか
保守契約でもっとも揉めやすいのが費用の線引きです。以下のような作業が、月額保守費の範囲内なのか、それとも都度見積もり(追加費用)になるのかを、契約前に必ず書面で確認してください。
- 軽微な文言修正・画像差し替え
- 新しい商品カテゴリーの追加のような、データ構造に影響する変更
- 消費税率変更や法改正対応
- サーバーの引っ越し、ドメインの更新作業
- 年に1回程度発生する、外部連携先のAPI仕様変更への追従
先代の代からの契約書を見ると、「軽微な修正は保守費用に含む」とだけ書かれていて、「軽微」の基準が定義されていないケースが頻繁に見つかります。この場合、業者側の裁量で「これは軽微ではない」と判断されれば、いくらでも追加請求される可能性があります。目安として、作業時間で区切る(例:1件あたり30分以内の作業は保守費用に含む)、あるいは月あたりの上限工数を決める、といった具体的な基準を契約書に盛り込んでもらうよう交渉しましょう。
4. データやソースコードの所有権・持ち出し可否
これは保守契約というより、その前段の開発契約(請負契約)に関わる話ですが、保守契約の見直しのタイミングで必ずあわせて確認してください。「今のシステムのソースコードやデータベースの設計書は、自社が保有しているか、それとも保守業者だけが持っているか」という点です。
先代の代の契約書に、ソースコードの著作権の帰属や、契約終了時の成果物引き渡し義務が明記されていない場合、保守業者を乗り換えようとした瞬間に「データを人質」に取られたような状況に陥ります。実際には法的にはデータそのものを人質に取ることは許されませんが、ソースコードの提供を拒否されたり、極端に高額な「移管費用」を請求されたりする事例は現実に起きています。
確認方法:
- 契約書に「本件成果物の著作権は甲(発注者)に帰属する」という条項があるか
- 契約終了時、ソースコード一式・データベース設計書・サーバーの管理者権限を引き渡す義務が明記されているか
- 現時点で、自社がソースコードのバックアップを保有しているか(業者に預けっぱなしになっていないか)
これらが不明確な場合は、保守契約の更新交渉のタイミングで、「今後の契約終了時には成果物一式を引き渡すこと」という条項を追加してもらうよう申し入れることをおすすめします。
5. 契約期間・自動更新・解約条件
先代の代からの保守契約でよくあるのが、「1年契約・自動更新・解約は3ヶ月前までに書面通知」という条件です。この「3ヶ月前までに書面通知」を知らずに放置していると、解約したいタイミングを逃し、望まない状態でさらに1年間契約が継続してしまいます。
- 契約期間は何年(何ヶ月)か
- 自動更新条項があるか、ある場合は解約の通知期限はいつまでか
- 解約時に発生する費用(移管費用、途中解約違約金など)はあるか
事業承継のタイミングで、すべての保守契約についてこの「解約通知期限」を一覧化しておくことを強く推奨します。これを怠ると、「本当は別の業者に切り替えたかったのに、通知期限を過ぎていて、あと1年間は今の契約を続けるしかない」という事態が起こり得ます。
6. 検収の基準が明記されているか
保守契約の中で軽微な改修を依頼した場合、その改修が「完了した」とみなされる基準はどこにあるでしょうか。新規開発の契約では、納品物を発注者が確認して合格を出す検収という工程が一般的ですが、保守契約における軽微な改修では、この工程が省略されがちです。
省略されること自体は必ずしも悪いことではありませんが、「業者が『対応しました』とメールを送ってきたら、実際に画面を確認せずに費用を払っている」という運用になっている会社は要注意です。対応内容が実際に意図通りになっているかを確認する習慣がないと、不十分な修正のまま費用だけが積み上がっていくことになります。せめて月次の保守報告書に「対応した作業一覧」を明記してもらい、自社の担当者が目視確認するフローを設けることをおすすめします。
7. 再委託(下請け)の有無
保守契約を結んでいる相手の会社が、実際の作業を別の会社やフリーランスのエンジニアに再委託しているケースは珍しくありません。これ自体は違法でも悪いことでもありませんが、以下のリスクを把握しておく必要があります。
- 再委託先が変わることで、対応品質やレスポンスが急に変わることがある
- 情報漏洩のリスク(顧客データを扱う場合、再委託先の管理体制まで確認が必要)
- 元請け業者が倒産・撤退した場合、再委託先との関係が継続されない可能性がある
契約書に「再委託の可否」「再委託する場合は事前に発注者の承諾を得ること」という条項があるかを確認しましょう。
8. 保守業者が使っている技術・仕組みが自社にとってブラックボックスになっていないか
古いシステムほど、特定の技術者しか触れない独自の作り方(いわゆるフルスクラッチ開発で作られた古い言語のシステムなど)になっていることがあります。これ自体が悪いわけではありませんが、その技術に詳しい担当者が退職したり、業者自体が廃業したりした場合、誰も保守できなくなるリスクがあります。
- 保守を担当している技術者は何人体制か、属人化していないか
- 使用している技術(プログラミング言語、フレームワーク、サーバー環境)は現在も一般的に習得可能なものか
- 万が一その業者と契約を終了した場合、別の業者が保守を引き継げる状態にあるか
このあたりは技術的な話になるため、後継社長ご自身で判断するのが難しい場合は、契約の見直しのタイミングで第三者のITエンジニアやコンサルタントにセカンドオピニオンを求めることも検討してください。
よくある失敗パターン3選
ここでは、実際に事業承継後の会社で起きがちな失敗パターンを、具体的なシナリオで紹介します。自社に当てはまるものがないか、確認してみてください。
失敗パターン1:「保守契約=何でも屋」という誤解
先代の代から「保守契約を結んでいるから、システムのことは全部あの業者に任せておけば大丈夫」という認識で運用してきた結果、後継社長が新しい機能を追加したいと相談したところ、「それは保守契約の範囲外なので、別途要件を整理して見積もりを出します」と言われ、想定外の追加費用と時間がかかってしまうケースです。
この失敗を防ぐには、契約前(更新前)の段階で「保守契約でカバーされる作業」と「別途見積もりが必要な開発案件」の境界線を、書面で明確にしておくことが重要です。新しい機能追加を依頼する際は、口頭で「ちょっとこれ追加してほしい」と伝えるのではなく、依頼したい内容を簡単な文書にまとめて渡す習慣をつけると、後々の「言った言わない」のトラブルを防げます。
失敗パターン2:解約したくてもできない「ロックイン」状態
先代の代のシステムが古い独自技術で作られており、かつソースコードの引き渡し条項が契約書になかったため、別の業者に相見積もりを取ろうとしても、現行業者以外の誰も現行システムの中身を把握できず、事実上その業者以外に発注できない状態になっていたケースです。
この状態を「ベンダーロックイン」と呼びますが、事業承継後に気づいてから対処するのは非常に困難です。理想を言えば、システムを新規に発注する契約の段階から、ソースコードの帰属や引き渡し義務を明文化しておくべきです。もしすでにロックインされてしまっている場合は、無理に短期間で乗り換えようとせず、まずは現行業者との関係を維持しながら、並行してドキュメント化(仕様書の作成)を進めてもらうよう交渉する、という段階的なアプローチが現実的です。新規に開発会社へ相談する前に決めておきたいことは、刷新を開発会社に相談する前に、決めておきたい3つのことにまとめている。
失敗パターン3:先代の口約束が反映されていない契約書
先代経営者と保守業者の間で、契約書には書かれていない口頭の約束事(例:「繁忙期の1〜3月は優先対応する」「特定の得意先向けの帳票だけは無償で修正する」など)が存在していたものの、先代の引退・急逝により、その口約束の存在自体が後継社長に伝わっていなかったケースです。後継社長が契約書だけを見て「この業者は融通が利かない」と判断し、関係を打ち切ってしまってから、実は先代が個人的な信頼関係で無償対応してもらっていた部分が多くあったと気づく、という展開です。
これを防ぐには、事業承継の準備段階(できれば先代がまだ元気なうちに)、主要な取引業者との間でどのような口約束や慣習があるのかを、先代同席のヒアリングの場で洗い出しておくことが重要です。承継が済んでからでは、確認したくても確認できません。承継前にどの契約書から読み進めるべきか迷う場合は、雇用契約・リース契約・取引基本契約、承継前に読むべき順番も参考になる。
新規にシステムを発注し、保守契約もセットで結ぶ場合の注意点
事業承継を機に、老朽化した基幹システムやホームページを刷新しようと考える後継社長も多いでしょう。その場合、開発と保守がセットで提案されることが一般的です。この際に注意すべき点を整理します。
要件定義の内容が保守契約にも影響する
新規開発を依頼する際、発注者側の要望を整理して開発会社に伝える要件定義という工程があります。この工程で決めた仕様・機能の範囲が、そのまま将来の保守契約の対象範囲の土台になります。要件定義の段階で「この機能は将来的に自社で追加開発したい」といった方針がある場合は、あらかじめ開発会社に伝えておくことで、保守契約の設計にも反映してもらいやすくなります。
逆に、要件定義があいまいなまま開発が進んでしまうと、納品後の保守契約でも「この機能は保守対象なのか、別の追加開発なのか」があいまいなまま引き継がれてしまいます。事業承継直後は、既存システムの仕様書自体が存在しない、または古くて実態と合っていないというケースも多いため、新規発注のタイミングで現行仕様の棚卸しを兼ねた要件整理をしてもらうことをおすすめします。
補助金を使う場合の保守契約の扱い
システムの刷新にあたって、IT導入補助金の活用を検討する後継社長も多いはずです。補助金を使う場合、注意したいのは「補助対象経費」と「保守費用」が明確に区分されるという点です。多くの補助金制度では、導入時の開発費用は補助対象になっても、その後の月額保守費用は対象外、あるいは一定期間のみ対象、という制度設計になっています。
補助金の申請書類を作成する段階で、開発会社から提示される見積もりに「初期費用」と「月額保守費用」が明確に分かれているかを確認し、どちらが補助対象になるのかを申請前に必ず確認してください。ここが曖昧なまま申請してしまうと、採択後の実績報告の段階でつまずく可能性があります。
いきなり大規模刷新ではなく、小さく始める選択肢もある
老朽化したシステムを一気に全面刷新しようとすると、開発費用も保守契約の規模も大きくなり、リスクも比例して高まります。特に事業承継直後で、まだ自社のIT予算感覚や業者との信頼関係が固まっていない段階では、いきなり大規模な契約を結ぶのはおすすめしません。
まずは特定の業務領域に絞った小さな仕組みを試作し、実際に使ってみてから本格導入を判断する、という進め方があります。この最初の試作段階のことをMVP（実用最小限の製品）と呼びます。小さく始めることで、保守契約についても「まずは小規模な範囲で契約を結び、業者の対応品質や相性を見極めてから、本格的な保守契約に移行する」という段階的なアプローチが取りやすくなります。いきなり3年契約・自動更新の大型契約を結んでしまうと、後から「この業者とは合わなかった」と気づいても身動きが取れなくなるため、特に新しい業者と初めて取引する場合は、契約期間を短めに設定してもらう交渉も有効です。
契約前確認チェックリスト(保存版)
以下は、保守契約を新規に結ぶ、あるいは更新する前に確認すべき項目をまとめたチェックリストです。印刷して、担当者や顧問税理士・弁護士と一緒に確認しながら使ってください。
契約範囲について
- [ ] 対象システム・対象機能が具体的に列挙されているか
- [ ] 外部連携システムの不具合が保守範囲に含まれるか明記されているか
- [ ] 「軽微な修正」の定義(作業時間・工数の目安)が書かれているか
対応品質について
- [ ] 対応時間帯(平日のみか、休日夜間も含むか)が明記されているか
- [ ] 障害発生から一次回答までの目安時間が書かれているか
- [ ] 担当技術者の体制・人数を把握しているか
費用について
- [ ] 月額保守費用に含まれる作業と、追加費用が発生する作業の境界線が明確か
- [ ] 追加費用が発生する場合の見積もり手続きが明記されているか
- [ ] 補助金を使う場合、補助対象経費と保守費用が区分されているか
権利関係について
- [ ] ソースコード・データベース設計書の著作権の帰属が明記されているか
- [ ] 契約終了時の成果物引き渡し義務が明記されているか
- [ ] 自社でソースコード・データのバックアップを保有しているか
契約期間・解約について
- [ ] 契約期間と自動更新の有無を把握しているか
- [ ] 解約通知の期限(何ヶ月前までか)を把握しているか
- [ ] 途中解約時の違約金・移管費用の有無を確認したか
その他
- [ ] 再委託の可否・事前承諾条項があるか
- [ ] 月次の保守報告書など、対応内容を可視化する仕組みがあるか
- [ ] 先代からの口約束・慣習を書面化・引き継ぎできているか
このチェックリストで「分からない」「契約書に書かれていない」という項目が多いほど、契約更新のタイミングで業者と交渉し、条件を明確化していく必要があります。
業者との話し合いの進め方
チェックリストで問題点が見つかった場合、いきなり強い態度で業者に詰め寄る必要はありません。多くの場合、長年の付き合いのある業者は、こちらが具体的に何を確認したいのかを明確に伝えれば、誠実に対応してくれます。以下のような進め方をおすすめします。
- 現状の契約書を読み込み、上記チェックリストで不明点を洗い出す
- 不明点をリスト化し、業者に「確認したいことがある」とアポイントを取る
- 口頭でのやり取りだけでなく、確認した内容を議事録やメールで残す
- 契約更新のタイミングに合わせて、不明確だった条項の追記・修正を依頼する
- 修正した契約書は、可能であれば顧問弁護士や商工会議所の相談窓口にも目を通してもらう
事業承継直後は、先代の代からの取引先に対して「代替わりした途端にうるさいことを言い出した」と思われることを気にする後継社長も多いですが、契約内容を確認すること自体は経営者として当然の権利であり義務です。誠実な業者であれば、むしろ「きちんと確認してくれる発注者」として関係が良好になることも多いものです。承継1年目に契約書を自分で読むべきか顧問に確認してもらうべきか迷う場合は、承継1年目、システムの契約書は自分で読むか顧問に確認してもらうかも参考にしてほしい。
まとめ
保守契約は、日々の業務の中では意識されにくい「見えないコスト」であり、同時に「見えないリスク」でもあります。先代から引き継いだ保守契約をそのまま放置してしまうと、いざシステムトラブルが起きたときに「思っていた対応をしてもらえない」「想定外の追加費用を請求される」といった事態に直面しかねません。
事業承継のタイミングは、こうした「なんとなく続いてきた契約」を見直す絶好の機会です。本記事で紹介した8つの確認ポイントとチェックリストを使って、まずは自社が結んでいるすべての保守契約を棚卸しすることから始めてみてください。契約書の中身が分からない、専門用語が難しくて判断できないという場合は、無理に自分だけで判断せず、顧問税理士や中小企業診断士、あるいは信頼できるITの専門家に相談することも検討してください。
よくある質問(FAQ)
以下では、後継社長からよく寄せられる質問をまとめました。
Q. 保守契約の内容を確認したいと業者に伝えたら、機嫌を損ねないか心配です。
A. 誠実な業者であれば、契約内容の確認要請自体を嫌がることはまずありません。むしろ「代替わりを機にきちんと契約を見直したい」という姿勢は、経営者として自然な行動です。もし確認要請に対して非協力的な態度を取る業者がいるとすれば、それ自体が今後の取引を見直すべきサインかもしれません。
Q. 先代の代からの契約書が見当たりません。どうすればいいですか。
A. まずは業者側に「契約書の控えを再送してほしい」と依頼してみてください。多くの業者は自社の控えを保管しています。それでも見つからない場合は、現状の請求内容や作業実態をヒアリングし、新たに契約書を巻き直すことをおすすめします。口頭やなあなあの関係のまま契約が継続している状態は、双方にとってリスクです。
Q. 保守費用が高いと感じるのですが、値下げ交渉はできますか。
A. 交渉自体は可能ですが、値下げだけを求めるのではなく、まず「何にいくら払っているのか」を可視化することが先です。対応範囲や工数の内訳が明確になれば、無駄な部分を削って費用を下げる、あるいは同じ費用でより手厚い対応を依頼する、といった建設的な交渉がしやすくなります。相見積もりを他社から取ることも有効な交渉材料になりますが、その際は前述のベンダーロックインの問題(ソースコードが引き渡せるか)を先に確認しておく必要があります。
Q. システムを新しく作り直すタイミングで、保守契約はどう設計すればよいですか。
A. 新規開発の契約時点から、保守フェーズで何が保守費用に含まれるのかを開発会社とすり合わせておくことをおすすめします。開発を依頼する際に、開発内容を整理した文書を交わしておけば、その内容がそのまま将来の保守契約の対象範囲の基準になります。開発と保守を同じ会社に一括で依頼する場合でも、契約書は別々に、かつ具体的な内容で作成してもらうようにしましょう。
