更新書類にハンコを押す前に、あなたは何を確認しているか
保守契約書が届いたのは、月曜の朝一番だった。総務担当が「今月中にご返送をお願いします」という一文にマーカーを引いて、社長のデスクに置いていく。金額は去年と同じ。契約期間も1年で自動継続。ここに判子を押せば、今年も業務システムは動き続ける。そう思って、後継社長は書類の最後のページにあるサインの欄だけを見て、ペンを取ろうとした。
先代が現役だった頃、この保守契約はいつも同じように更新されてきた。開発会社の担当者と先代は長年の付き合いがあり、「まあいつも通りで」という一言で全てが済んでいた。先代が何を確認していたのか、どんな条件で契約が結ばれているのか、後継社長は正直なところよく分かっていない。システムのソースコードがどこにあるのか、担当者が異動したらどうなるのか、契約を切ったら会社のデータはどう扱われるのか——そうした具体的な問いに、即答できる後継者は多くない。
これは決して珍しい光景ではない。中小企業の事業承継において、業務システムの保守契約は「先代と開発会社の間の暗黙の了解」で長年運用されてきたケースが非常に多い。後継社長が代表印を継承した瞬間から、その暗黙の了解は当然には引き継がれない。開発会社側の担当者も、契約書の文言も、承継のタイミングでは何も変わっていないように見える。しかし実際には、力関係も、情報の非対称性も、リスクの所在も、先代の時代とはまったく違う状態になっている。
保守契約の更新は、年に一度、あるいは複数年に一度しか訪れない「開発会社との関係を見直す唯一のタイミング」である。にもかかわらず、多くの後継社長はこの機会を「金額が変わっていないかの確認」程度で通過させてしまう。本稿では、なぜこの問題が起こるのか、その構造を丁寧に解説し、実際にどう対応すべきかを具体的なチェックリストとケーススタディで示す。
なぜこの問題が起こるのか——構造的な背景
1. 保守契約は「関係」の上に成立しており、契約書はその一部でしかない
多くの中小企業のシステム保守契約は、契約書に書かれている条項だけで運用されているわけではない。実際には、開発会社の担当者と発注側（多くは先代社長や、先代の右腕だった総務・情報システム担当者）との間に、契約書に明記されていない「口約束」や「暗黙の運用ルール」が積み重なっている。
例えば「障害が起きたら担当者の携帯に直接電話する」「軽微な修正は見積もりなしで対応してもらう」「決算期の繁忙期は優先的に対応してもらう」といった運用は、契約書のどこにも書かれていないことが多い。これらは担当者個人の裁量や、開発会社と先代との人間関係の蓄積によって成立してきたものである。
事業承継が起きると、この「関係」の土台が崩れる。後継社長は先代のような人間関係の蓄積を持っていない。開発会社側も、後継社長がどこまで技術に詳しいのか、どこまで強く言っても良い相手なのかを測りかねている状態からスタートする。つまり承継直後の保守契約更新は、双方が「白紙の関係」で向き合う、非常に不安定な局面なのである。この不安定さの中で、後継社長が「いつも通りで」と流してしまうと、先代時代の暗黙の了解のうち、発注側に有利だった部分（無償対応の範囲、優先対応など）は引き継がれず、開発会社に有利だった部分（不透明な見積もり、属人化した仕様把握など）だけがそのまま残るという非対称な結果になりやすい。
さらに厄介なのは、この「関係」が契約書という形式に落とし込まれていないがゆえに、承継のタイミングでその存在自体に気づきにくいという点である。後継社長は契約書を一読して「特に問題のある条項は見当たらない」と判断してしまうが、実際に会社を支えているのは契約書の条項ではなく、その裏側にある担当者の善意や慣行の積み重ねであることが多い。契約書だけを見て安心してしまうことこそが、この構造的な問題の入り口になる。先代がいた頃は、担当者が多少無理な対応をしてくれていたとしても、それは「先代との関係だから」という理由であり、後継社長に対して同じ厚意が自動的に継続される保証はどこにもない。後継社長がこの事実に気づくのは、たいてい何らかの依頼を断られた時、あるいは見積もりが急に厳格化された時であり、その時点ではすでに関係の力学が変わってしまっている。
2. 情報の非対称性が承継のタイミングで最大化する
システムの保守契約における最大の問題は、情報の非対称性である。発注側（会社）は自社の業務については詳しいが、システムの内部構造やソースコードの所在、開発言語やフレームワークのバージョン、データベースの設計については開発会社にしか分からない、という状態が一般的だ。
先代の時代は、この非対称性がある程度緩和されていた。なぜなら先代は長年、開発会社の担当者とやり取りを重ね、システムの経緯や過去の改修履歴、トラブル時の対応パターンをある程度肌感覚で理解していたからだ。契約書に書かれていない情報を、経験的な記憶で補完できていたということである。
後継社長にはこの「経験的な記憶」がない。しかも先代からの引き継ぎ資料に、システムの詳細な情報が残されているケースは少ない。多くの引き継ぎは経理・取引先・人事といった「見える経営資源」に集中し、システムという「見えにくい経営資源」は後回しになる。結果として、後継社長は自社の基幹システムについて、開発会社よりも圧倒的に情報を持たない状態で、保守契約という重要な意思決定に向き合うことになる。この非対称性が最大化するタイミングこそが、まさに承継直後の契約更新期なのだ。
情報の非対称性がもたらす具体的な弊害は、単に「知らないから不安」というレベルの話ではない。実務上は、見積もりの妥当性を判断できない、追加開発の提案を鵜呑みにするしかない、契約条項の不利な部分に気づけない、といった形で経営判断そのものの質を下げてしまう。開発会社側に悪意がなくても、発注側が情報を持たない状態が続けば、提案される選択肢は自然と開発会社にとって都合の良いものに偏っていく。これは開発会社の不誠実さというよりも、情報を持つ側が持たない側よりも強い立場に立つという、ごく普通の経済原理の結果である。後継社長がこの非対称性を放置したまま何年も契約更新を続けると、気づかないうちに会社の意思決定の自由度そのものが狭まっていく。しかも、この非対称性は時間が経てば経つほど自然に解消されるものではなく、後継社長が意図的に情報収集の努力をしない限り、むしろ開発会社側の知見が積み重なる分だけ広がっていく傾向がある。だからこそ、承継直後という「まだ非対称性が決定的に固定化していない」タイミングで、できるだけ多くの情報を掘り出しておくことが重要になる。
3. 「更新しない」という選択肢が事実上存在しない状況に置かれている
保守契約の更新において、発注側には理論上「更新しない」「他社に切り替える」という選択肢がある。しかし現実には、多くの後継社長にとってこの選択肢は事実上存在しない。
理由は明快だ。システムのソースコードや設計書、仕様書、データベースのスキーマ情報といった「システムの中身」を発注側が十分に保有していない場合、保守契約を切ることは「システムが動かなくなるリスク」を発注側自身が背負うことと同義になる。ソースコードが開発会社にしかない、あるいは開発会社の特定の担当者の頭の中にしかない状態(いわゆる属人化)であれば、契約を切る=いざ障害が起きても誰も対応できない、という恐怖と直結する。
この構造は、開発会社側からすれば強力な「ロックイン」である。悪意がなくとも、結果的に発注側は価格交渉力もサービス内容の交渉力もほとんど持てないまま、言われた条件で更新を続けることになる。後継社長がこの構造に気づかず、先代同様に「いつも通りで」と契約を続けていくと、毎年少しずつ保守料が上がっていても、それを止める材料を持たないという状態が固定化してしまう。
ロックインの厄介さは、当事者がそれを「選んでいる」ように見えてしまう点にもある。後継社長は、毎年の契約更新の書類にサインをするたびに、自分の意思でこの開発会社を選び続けているつもりになる。しかし実際には、他の選択肢を検討する材料(ソースコードの有無、移行コストの見積もり、代替の開発会社候補)を持たないまま「選んでいる」のであれば、それは実質的には選んでいるのではなく、選ばされている状態に近い。真に自由な選択とは、他の選択肢を検討した上でなお現状を選ぶことであり、他の選択肢そのものが見えない状態での継続は、経営判断としては脆弱である。後継社長が最初に取り組むべきは、契約を切るかどうかを今すぐ決めることではなく、「切るという選択肢が実際に存在するかどうか」を確認できる状態を作ることだ。
4. 契約更新のタイミングは「関係のリセット」の唯一の好機でもある
ここまではリスクの話だったが、構造的に見ればもう一つの側面がある。保守契約の更新のタイミングは、発注側にとって最も交渉力を持てる、数少ない瞬間でもある。なぜなら、この瞬間だけ開発会社側も「更新してもらえるかどうか分からない」という不確実性を抱えるからだ。日常のやり取りの中で急に条件変更を求めるより、更新のタイミングで正式に条件を確認・交渉する方が、開発会社側も応じやすい。
つまり保守契約の更新は、リスクが集中する局面であると同時に、後継社長が主導権を握り直す最大のチャンスでもある。この二面性を理解した上で、「何を確認すべきか」を体系的に押さえておくことが、事業承継後のIT実務において決定的に重要になる。
もう一つ重要な点は、開発会社側にとっても、長期的に安定した発注元との関係は経営上の資産であるということだ。開発会社は決して発注側を困らせたいと思っているわけではなく、多くの場合、継続的な保守契約は貴重な安定収益源であり、その関係を維持したいと考えている。したがって、後継社長が誠実に「会社としてリスク管理の体制を整えたい」という姿勢で条件確認や条項の明文化を求めれば、多くの開発会社は協力的に応じてくれる。この交渉は「対立」ではなく「健全化」のプロセスとして進めるべきものであり、後継社長が過度に身構えたり、逆に相手の顔色をうかがって何も言えなくなったりする必要はない。事務的に、淡々と、順番に確認していくという姿勢こそが、この局面で最も有効に機能する。
5. 後継社長が「技術が分からない」ことを理由に判断を放棄してしまう構造
多くの後継社長は、経理や営業、製造といった本業の実務には強いが、システムの技術的な内容には詳しくない。この「自分は技術が分からない」という自己認識が、判断そのものを開発会社に委ねてしまう心理的な逃げ道を作ってしまう。
しかし、保守契約の更新で本当に必要な判断は、プログラミング言語やアーキテクチャの技術的な理解ではない。「何を受け取っていて、何を受け取っていないか」「もし今この開発会社と縁が切れたら、会社は困るか」という、経営者としての基本的なリスク管理の視点である。この視点は、技術知識ゼロでも十分に発揮できる。むしろ後継社長がここで判断を放棄することが、最大のリスクを生む。
この構造は、他の経営領域における判断放棄と根本的には変わらない。例えば、後継社長が税務や労務の細部を全て理解していなくても、税理士や社労士に「今の顧問料は適正か」「うちの会社にとって必要な対応をしてもらえているか」を問いかけることはできる。ITの保守契約についても同じ発想で向き合えばよい。技術の詳細を理解する必要はなく、「自社にとって何が守られているべきか」という経営の言葉に翻訳して問いかければ十分である。多くの後継社長がこの翻訳作業を怠り、「技術の話だから開発会社に任せるしかない」という思考停止に陥ってしまうことが、この問題を長期化させる最大の要因になっている。実際、開発会社の担当者に「今のこの契約で、もし先生方(担当エンジニア)が全員いなくなったら、うちの会社はどうなりますか」と率直に尋ねてみるだけでも、多くの重要な情報が引き出せる。この問いは技術的な知識を一切必要としない、経営者としての当然の問いである。
ケーススタディで見る、契約更新の分岐点
ケース1:担当者の退職で仕様が「誰も分からないもの」になった製造業A社
従業員45名の金属加工業A社では、先代社長の時代から15年間、同じ開発会社に生産管理システムの保守を依頼していた。担当していたエンジニアは1人で、この15年間、ほぼ全ての改修とトラブル対応を1人で担ってきた。仕様書は最初の導入時のものしか存在せず、その後の追加開発はすべて「言った通りにやってもらう」形式で進められてきたため、正式な設計書は更新されていなかった。
後継社長が代表になって2年目、保守契約の更新時期にその担当エンジニアが開発会社を退職した。開発会社側は「後任を立てるので問題ありません」と説明したが、後任のエンジニアはシステムの全体像を把握するまでに数ヶ月を要し、その間に発生した軽微な不具合対応にも通常の数倍の時間がかかるようになった。年次の棚卸データ集計で異常値が出た際、原因調査に3週間もかかり、決算作業に支障が出た。
後継社長がこの契約更新のタイミングで振り返ってみると、A社は最新の仕様書やソースコードのバックアップを一切保有していなかったことが判明した。開発会社に「今のソースコードと仕様書一式を提供してほしい」と依頼したところ、開発会社は「別途費用が発生する」と回答した。属人化のリスクを軽視した結果、いざ担当者が変わった瞬間に、会社としての実務が直接的に停滞するという事態を招いてしまった。このケースは、更新前に「ドキュメントの現物提供」を確認していれば、少なくとも後任への引き継ぎ時間を大幅に短縮できたはずの典型例である。
さらにA社では、この一件をきっかけに、生産管理システムに紐づく発注データや在庫データの一部が、旧担当者が個人的に管理していたローカルの設定ファイルに依存していたことも判明した。後任のエンジニアがその設定ファイルの存在を知らなかったため、月次の在庫突合処理が一時的に正しく動かなくなり、現場の在庫担当者が手作業での突合を強いられる期間が生じた。後継社長は「たった1人のエンジニアの頭の中に、会社の基幹業務の一部が丸ごと依存していた」という事実に、退職の連絡を受けてから初めて気づいたと振り返っている。この経験を踏まえ、A社では以後、保守契約の更新時に必ず「現在の担当者が持っている非公式な運用ノウハウを含めて、ドキュメント化してもらう」という条項を追加し、年に一度、開発会社にシステムの現状把握レポートを提出してもらう運用に切り替えた。属人化は、担当者が優秀であればあるほど進行しやすく、かつ発覚しにくいという厄介な性質を持っている。優秀な担当者ほど「聞けばすぐ答えてくれる」ため、ドキュメント化の必要性そのものが見過ごされがちになるからだ。
ケース2:見積もりの根拠が不透明なまま10年間保守料が上がり続けた小売業B社
従業員20名弱の小売業B社は、POSシステムと在庫管理システムの保守を先代の代から同じ開発会社に委託していた。保守料は当初、月額5万円だったが、10年間で段階的に月額12万円まで上昇していた。値上げの都度、開発会社からは「サーバーの維持費が上がったため」「セキュリティ対応強化のため」といった説明があったが、具体的な内訳や作業時間の記録は示されないまま、口頭説明と請求書だけで運用されていた。
後継社長が代替わりを機に保守契約の内容を精査したところ、実際に開発会社が行っている作業は、月に1〜2回のログ確認と、年に数回の軽微なバグ修正のみで、契約上の「月額保守料に含まれる作業範囲」が具体的にどこまでなのか、契約書自体に明記されていないことが分かった。つまり10年間、何にいくら払っているのかを誰も正確に把握できていない状態が続いていたのである。
後継社長は保守契約の更新時に、初めて「作業報告書の月次提出」と「保守範囲の明文化」を要求した。開発会社側は当初渋ったが、最終的には応じ、結果として保守料は月額8万円まで下がった。これは開発会社が悪意を持って過大請求していたわけではなく、「何をどこまでやるか」が両者の間で一度も明確化されていなかったために生じていた曖昧な運用の帰結だった。承継を機に契約内容を可視化したことで、初めて適正なコストが見えてきたケースである。
興味深いのは、B社の後継社長が最初にこの交渉に踏み出した際、大きな心理的なハードルを感じていたという点である。先代が10年間、一度も疑問を口にせずに支払い続けてきた金額に対して、後継社長が「その内訳を教えてください」と切り出すことは、ある意味で先代の判断を否定するようにも感じられたという。しかし実際に開発会社の担当者に事情を尋ねてみると、担当者自身も「なぜこの金額になっているのか、契約時の詳細な経緯は自分も引き継いでいない」と答えた。つまり開発会社側も、値上げの根拠を担当者間で正確に引き継いでいなかったのである。この事実が分かったことで、後継社長は「疑うこと」ではなく「双方にとって不明確だったものを明確にすること」という位置づけで交渉を進めることができ、結果的に関係を悪化させることなく、適正な保守料への見直しにつながった。B社のケースは、承継後の契約確認が、必ずしも対立的な交渉である必要はなく、双方にとってのメリットになり得ることを示す好例でもある。
ケース3:契約解除後にデータを取り出せなくなりかけた運送業C社
従業員30名の運送業C社は、配送管理システムを外部の開発会社に開発・保守してもらっていた。後継社長は先代の代から取引のあった開発会社の対応品質に不満を持ち、承継後2年目に別の開発会社への切り替えを決断した。ところが契約解除を通知した際、既存の開発会社から「データの移行支援には別途費用がかかる」「ソースコードの提供は契約範囲外」という回答が返ってきた。
C社は配送先データや過去の配送履歴、顧客ごとの配送条件などをすべてこのシステムに蓄積していたが、それらをどのファイル形式で、どこに、どういう状態で保有しているのかを正確に把握していなかった。移行に際して開発会社と交渉を重ねる必要が生じ、結果的に想定より2ヶ月近く長く並走稼働(新旧システムを同時に動かす)せざるを得ない事態となり、余分なコストが発生した。
このケースの根本原因は、そもそも保守契約の更新時に「データのエクスポート形式」や「契約終了時のデータ引き渡し条件」を一度も確認していなかったことにある。もし更新のたびにこの点を確認し、契約書に明記していれば、切り替えの交渉はもっと短期間かつ低コストで完了できたはずである。事業承継後の「開発会社を変える」という選択肢自体は健全な経営判断だが、その選択肢を行使するための備えが平時にできていなかったことで、余計な負担を強いられた事例である。
さらにC社では、契約解除の通知タイミングそのものにも問題があった。契約書には「契約終了の4ヶ月前までに書面で通知すること」という条項があったが、後継社長はこの条項の存在を契約解除を決断してから初めて確認し、結果的に通知が2週間遅れる形になった。開発会社側はこの遅延を理由に、契約の自動更新が一部適用されるという主張を行い、最終的には双方の話し合いで解決したものの、余計な緊張関係を生む一因となった。もしC社が平時の契約更新のたびに解約条件を確認し、社内のカレンダーに通知期限をあらかじめ登録しておけば、こうした行き違いは避けられたはずである。C社のケースは、データという「資産の引き渡し」の問題と、契約条項という「手続き上の期限」の問題が同時に絡み合うと、切り替えの負担が一段と大きくなることを示している。事業承継後に開発会社の切り替えを検討する後継社長は多いが、切り替え自体の是非を検討する前に、まず「今、切り替えるとしたら何が障害になるか」を平時に確認しておくことが、実際の負担を大きく左右する。
保守契約更新前に受け取っておくべきもの——実務チェックリスト
ここからは、保守契約を更新する前に、後継社長が開発会社から受け取っておくべき具体的な項目を、実務的なチェックリスト形式で解説する。すべてを一度に揃えるのは難しくても、更新のたびに1つずつ埋めていくという発想で取り組んでほしい。
チェック項目1:ソースコード一式とその保管場所の明確化
まず最初に確認すべきは、現在稼働しているシステムのソースコード一式を、会社側が独自に保有しているか、あるいはいつでも取得できる状態にあるかという点である。開発会社のサーバーやGitHubなどのリポジトリにソースコードが置かれている場合、そのアカウントの権限が会社側にあるのか、開発会社の担当者個人のアカウントに紐づいているのかを確認する必要がある。担当者個人のアカウントに紐づいている場合、その担当者が退職・異動すればアクセスできなくなるリスクがある。契約更新の際には「直近版のソースコード一式を、会社が指定するクラウドストレージやリポジトリに定期的にバックアップとして提供する」という条項を明文化することが望ましい。
具体的な進め方としては、まず「現在のソースコードの最新版を、圧縮ファイルの形で一式送ってほしい」と依頼するところから始めるとよい。技術的な知識がなくても、送られてきたファイルの容量やファイル数、最終更新日を見れば、それが本当に最新のものかどうかをある程度確認できる。受け取ったファイルは、社内のパソコンやクラウドストレージなど、開発会社に依存しない場所に必ず保管しておく。これを1年ごとの契約更新のたびに繰り返すルーティンにしておけば、大きな負担なく、常に最新に近いバックアップを保持できる状態を維持できる。もし開発会社が提供に難色を示す場合は、その理由を必ず確認する。著作権の帰属が契約上明確でない、あるいは複数の顧客のコードが混在しているなど、理由によって対応の仕方は変わってくる。
チェック項目2:仕様書・設計書の現物提供と更新状況の確認
導入時の仕様書は存在しても、その後の改修履歴が反映されていないケースが非常に多い。契約更新の場では、「現時点の仕様と一致した設計書・仕様書が存在するか」を必ず確認する。存在しない、あるいは古いバージョンしかない場合は、更新契約の中に「現状仕様に合わせた仕様書の整備」を作業項目として組み込むことを検討すべきである。ドキュメントが古いまま放置される最大の理由は、追加開発のたびにドキュメント更新の予算が確保されていないことにある。保守契約の更新時こそ、このコストを正式に見積もりに含める好機である。
仕様書の確認で後継社長がよく戸惑うのは、「仕様書」という言葉が指す範囲が開発会社によって大きく異なる点である。ある開発会社にとっての仕様書は、画面のレイアウトを示した簡易な資料だけを指す場合もあれば、データベースの構造やAPIの連携仕様まで含む詳細な技術文書を指す場合もある。契約更新時には「今回提供いただく仕様書には、画面の仕様だけでなく、データベースの構造や外部システムとの連携部分も含まれていますか」と具体的に問いかけることで、資料の実質的なカバー範囲を確認できる。仕様書が不十分だと分かった場合、一度に全ての機能を整備するのではなく、まずは業務上最も重要な機能(例えば受発注や在庫管理、給与計算など、会社の根幹に関わる部分)から優先的にドキュメント化してもらうという段階的な進め方が現実的である。
チェック項目3:保守対応の範囲と、範囲外作業の料金体系
保守契約の「保守料に含まれる作業」と「別途費用が発生する作業」の境界線は、契約書上で曖昧になっていることが多い。「軽微な修正」「バグ対応」といった言葉の解釈が発注側と開発会社側で異なっていることも珍しくない。契約更新時には、過去1年間に発生した作業を全て棚卸し、それぞれが保守料の範囲内で対応されたのか、追加費用が発生したのかを一覧化してもらうことが有効である。この棚卸によって、保守料の適正さを初めて客観的に評価できるようになる。対応時間や復旧目安をどこまで契約に明記してもらうか迷う場合は、SLA（サービス品質保証）という考え方を手がかりに、開発会社と条件をすり合わせるとよい。
この確認を行う際には、単に「作業一覧をください」と依頼するだけでなく、それぞれの作業にどの程度の時間がかかったのか(作業時間の記録)も併せて確認することが望ましい。時間単価が明示されていない契約の場合、作業内容と時間の記録を積み重ねることで、実質的な時間単価を後から逆算でき、他の開発会社の相場と比較する材料にもなる。また、月によって保守作業が全く発生していない月がある場合、その月についても保守料が発生しているのであれば、「稼働がなかった月の保守料は何に対する対価なのか」を確認しておくとよい。多くの契約では、稼働の有無に関わらず「いつでも対応できる体制を維持していること」自体に対価が発生する、という説明がなされるが、この説明が具体的にどのような体制を指しているのかまで確認できれば、保守料の意味をより正確に理解できる。
チェック項目4:障害対応の体制と代替担当者の存在
現在の担当エンジニアが不在・退職・病気になった場合、誰が代わりに対応するのかを確認する。1人の担当者に依存した「一人体制」の場合、その担当者に何かあった瞬間にシステムが機能不全に陥るリスクが非常に高い。契約更新時には、開発会社に「バックアップ体制」の有無と具体的な内容(誰が、どの範囲まで代替対応できるのか)を確認し、可能であれば契約書または覚書にその体制を明記してもらう。障害発生時に誰にどこまで連絡し、どこまでの範囲を任せるべきかという初動の取り決め方は、承継後の障害対応、誰に連絡しどこまで任せるかの取り決め方で具体的に扱っている。
特に注意すべきは、開発会社の規模が小さく、社員数が数名程度である場合である。この場合、実質的に会社全体が「一人体制」に近い状態になっていることも多い。バックアップ体制が「社内の別の社員が対応する」とされていても、その社員が実際にどこまでシステムの詳細を把握しているのかは別問題である。契約更新時には、可能であれば「バックアップ担当者は、過去にどの程度このシステムに関わったことがあるか」まで踏み込んで確認しておくと、体制の実質的な強度が見えてくる。また、開発会社そのものが廃業・倒産するリスクについても、小規模な開発会社と取引している場合は無視できない。契約書に「開発会社が事業継続困難になった場合のソースコード等の取り扱い」についての条項(いわゆるエスクロー的な取り決め)が含まれているかどうかも、余裕があれば確認しておきたい項目である。
チェック項目5:データのエクスポート形式と契約終了時の引き渡し条件
前述のケーススタディでも触れた通り、契約を終了する際に自社データをどのような形式で受け取れるのかは、実際に契約を切る段階になってから慌てて確認するものではなく、平時の契約更新のたびに確認しておくべき事項である。CSVやSQLダンプなど、汎用的な形式でのエクスポートが可能かどうか、エクスポートに要する期間や費用感を事前に聞いておくことで、将来的な開発会社の切り替えや内製化の選択肢を実質的に保持できる。
理想的には、実際に契約を切るかどうかとは無関係に、一度試験的にデータのエクスポートを依頼してみることを推奨する。実際に依頼してみると、エクスポートにどの程度の時間がかかるのか、出てきたデータが本当に業務で使える形式になっているのか、想定外の追加費用が発生するのかといった実態が見えてくる。多くの後継社長は、契約書に「データはいつでも提出可能」と書かれていることに安心してしまうが、実際に試してみるまでその実現性は分からない。年に一度の契約更新のタイミングで、簡単なデータのエクスポートを実際に依頼し、その対応スピードと品質を確認しておくことは、いざという時の安心材料になるだけでなく、開発会社側の対応力そのものを評価する機会にもなる。
チェック項目6:利用しているサーバー・クラウド環境の契約者情報
サーバーやクラウドサービス(AWSやさくらインターネットなど)の契約が、会社名義ではなく開発会社名義になっているケースが少なくない。この場合、契約を切ると同時にサーバー自体が停止し、システムが完全に利用不可になるリスクがある。契約更新時には、インフラの契約者が誰になっているかを必ず確認し、可能であれば会社名義への切り替え、または契約者情報の透明化を求めるべきである。
インフラが開発会社名義になっている背景には、多くの場合、導入当初に会社側がクラウドサービスの契約手続きに不慣れだったため、開発会社が代行して契約したという経緯がある。この経緯自体は特別不自然なものではないが、時間が経つにつれて「誰の名義で契約されているか」という情報自体が社内で忘れられていくことが問題になる。契約更新時には、サーバーやドメイン、SSL証明書、外部APIの利用契約なども含めて、「このシステムが依存している外部サービスの一覧と、それぞれの契約者名義」を一度整理してもらうとよい。これができれば、仮に開発会社を変更する場合でも、インフラ部分は会社名義のまま維持し、開発会社だけを切り替えるという柔軟な対応が可能になる。逆にこの整理をしないまま契約を切ると、ドメインの更新すら誰にも分からなくなり、ある日突然会社のウェブサイトやシステムにアクセスできなくなるという、目に見えない形でのリスクを抱え続けることになる。
チェック項目7:保守料の値上げ根拠と過去の値上げ履歴
保守料が過去にどのような理由で、どの程度値上げされてきたのかを一覧で確認する。値上げの根拠が説明できない、あるいは説明が毎回異なるような場合は、金額の妥当性そのものを見直す材料になる。契約更新の場は、複数年分の値上げ履歴を並べて確認できる貴重なタイミングである。
値上げの履歴を確認する際には、単に金額の変遷だけでなく、その時々の社会的な背景(消費税率の変更、最低賃金の上昇、クラウドサービスの値上げなど)と、実際の値上げ幅がどの程度対応しているのかを比較してみると、値上げの妥当性がより具体的に見えてくる。例えば、ある年の値上げが「クラウドサービスの費用上昇」を理由にしているにもかかわらず、その年に実際にクラウドサービスの料金体系が変わっていない場合、その説明の根拠は薄いと判断できる。後継社長が先代の代からの請求書を全て保管している場合は、それを時系列で並べてグラフ化するだけでも、値上げのペースが一定なのか、ある時点から急激に加速しているのかが視覚的に分かり、交渉の材料として非常に有効である。
チェック項目8:契約期間・自動更新条項・解約条件の確認
保守契約の多くは1年単位の自動更新となっており、解約する場合は「契約終了の3ヶ月前までに書面で通知」といった条件が定められていることが多い。この解約条件を事前に把握していないと、契約を切りたいと思った時にすでに自動更新のタイミングを過ぎており、さらに1年間契約が継続してしまうという事態が起こる。契約更新時には、必ず解約に関する条項を読み直し、次回の通知期限をカレンダーに登録しておくことを推奨する。
さらに確認しておきたいのは、通知の方法が「書面」に限定されているのか、メールでの通知でも有効とされているのかという実務的な細部である。契約書に「書面による通知」と定められているにもかかわらず、実際にはメールだけで済ませてしまい、後から「正式な通知を受け取っていない」と主張されるトラブルも起こり得る。解約を検討する段階になった時は、契約書に定められた通知方法を厳密に守り、可能であれば内容証明郵便など、送付の事実が明確に残る手段を使うことが望ましい。またこの機会に、複数年契約になっていないか、途中解約時に違約金が発生する条項がないかも併せて確認しておくと、将来的な選択の自由度をより正確に把握できる。
チェック項目9:委託先の再委託(下請け)状況の確認
保守を委託している開発会社が、実際の作業を別の会社や個人エンジニアに再委託しているケースもある。この場合、実際の技術的な窓口が誰なのか、責任の所在がどこにあるのかが不透明になりやすい。契約更新時には、実際の作業者が誰なのか、再委託がある場合はその範囲と管理体制を確認しておくことが望ましい。
再委託の有無を確認する理由は、単に「誰が作業しているか知りたい」という興味本位のものではない。再委託先の個人エンジニアが実質的な業務を担っている場合、その個人が契約を離れた瞬間に、前述のA社のケースと同様の属人化リスクが発生する。また、情報セキュリティの観点でも、再委託先が会社の機密情報や顧客データにどこまでアクセスできる状態にあるのかを把握しておくことは、後継社長としての基本的な管理責任の範囲に含まれる。契約更新時には「再委託を行う場合は事前に発注元へ通知すること」といった条項が契約書に含まれているかどうかも確認し、含まれていなければこの機会に追加を依頼することが望ましい。
チェック項目10:セキュリティインシデント発生時の対応フローと責任範囲
システムに不正アクセスや情報漏洩などのセキュリティインシデントが発生した場合、開発会社と会社側のどちらがどこまでの責任を負うのか、対応フローがどうなっているのかを確認する。多くの中小企業向け保守契約では、この点が曖昧なまま結ばれていることが多い。契約更新時に、インシデント発生時の初動対応(誰にいつ連絡するか)と責任分担について、最低限の確認を行っておくべきである。
近年、中小企業を標的にしたランサムウェアや不正アクセスの被害が増えている中で、保守契約におけるセキュリティ対応の取り決めは、以前よりも重要性を増している領域である。確認すべき具体的な内容としては、平時のセキュリティパッチの適用は誰の責任で、どの頻度で行われているのか、インシデント発生時に24時間以内に連絡が取れる体制があるのか、顧客情報が漏洩した場合の対外的な説明や監督官庁への報告について、開発会社としてどこまで協力してもらえるのか、といった点が挙げられる。これらは平時にはなかなか話題に上がらない事項だからこそ、契約更新という定期的な機会を使って、必ず一度確認しておく価値がある。
よくある失敗パターン
失敗パターン1:「先代の時と同じでお願いします」で全て済ませてしまう
最も多い失敗が、契約更新の書類を精査せず「前回通りでお願いします」という一言で更新を終えてしまうケースである。この対応は一見、円滑な事業継続に見えるが、実際には先代の時代に積み重なった不透明な部分(値上げの根拠不明、作業範囲の曖昧さ、属人化リスクなど)をそのまま引き継いでしまうことを意味する。後継社長にとって、承継後の最初の契約更新は、こうした過去の不透明さを一度リセットする最大のチャンスである。このチャンスを「前回通りで」の一言で放棄してしまうと、次にこの機会が来るのは1年後、あるいは何らかの重大なトラブルが起きた時になってしまう。契約更新のたびに、最低でも上記チェックリストの数項目だけでも確認する習慣をつけることが重要である。
失敗パターン2:担当者との関係性を壊すことを過度に恐れて、必要な確認を避ける
後継社長の中には、開発会社の担当者と先代が長年築いてきた良好な関係を壊すことを恐れ、契約内容について踏み込んだ質問をすることを躊躇してしまう人が少なくない。「今さらそんなことを聞いたら、担当者に嫌な思いをさせるのではないか」「取引先との関係が悪化するのではないか」という懸念は理解できるが、これは経営判断としては本末転倒である。ソースコードの所在や作業範囲の確認は、健全な取引関係において当然行われるべき事務的な確認事項であり、これを尋ねることで関係が悪化するとすれば、そもそもその関係性自体に構造的な問題があると考えるべきだ。むしろ、こうした確認を丁寧に行うことは、開発会社側から見ても「この会社はきちんと自社のシステムを管理する経営体制になった」という信頼につながり、長期的な取引関係の質を高めることにもなる。確認の過程で実際に金額や対応範囲をめぐる意見の相違が生じた場合の交渉の進め方は、トラブル時の交渉術。感情的にならずに解決するを参考にしてほしい。
失敗パターン3:社内に技術に詳しい人材がいないことを理由に、確認自体を先延ばしにする
「自分も社内の誰も技術に詳しくないから、確認しても分からない」という理由で、契約内容の確認自体を先延ばしにしてしまうケースも多い。しかし前述の通り、保守契約の更新で必要なのは技術的な専門知識ではなく、「何を受け取っているか」「もし契約が切れたら会社はどう困るか」というリスク管理の視点である。この視点は経営者であれば十分に持ち得るものであり、技術知識の有無を理由に確認を放棄する必要はない。仮に自社に技術者がいない場合でも、税理士や商工会議所の経営相談窓口、あるいは第三者のITコンサルタントに、契約書の内容だけを見てもらい、リスクの所在を指摘してもらうという方法もある。専門知識がないことを、確認をしない理由にしてしまうのは、事業承継後のIT実務における典型的な落とし穴である。
よくある質問(FAQ)
Q1. 開発会社にソースコードの提供を求めたら、断られてしまいました。どう対応すればよいですか。
まず、断られた理由を明確に確認することが重要である。契約上、著作権や知的財産権の扱いがどうなっているかによって、開発会社側の立場も変わってくる。多くの受託開発契約では、納品物の著作権が発注者に譲渡される旨が定められている場合、ソースコードの提供を拒む正当な理由は乏しい。一方で、著作権が開発会社側に留保される契約になっている場合は、交渉の余地はあるものの、無償での提供を強制することは難しい。いずれの場合も、次回の契約更新時に「ソースコードおよび関連資料の定期的な提供」を契約条項に明記することを提案し、応じてもらえない場合は、他の開発会社への相談も含めて代替手段を検討する材料とすべきである。
Q2. 保守料が高いと感じますが、他社に切り替えるのはリスクが大きいと感じます。まず何から始めればよいですか。
切り替えを急ぐ前に、まずは現在の契約内容の可視化から始めるべきである。過去1年間の作業内容と費用の対応関係を棚卸しし、保守料が何にどの程度使われているのかを明確にする。これにより、単純な値下げ交渉の余地があるのか、それとも本当に他社への切り替えを検討すべき水準なのかを判断する材料が得られる。切り替えを検討する場合も、まずはソースコードとデータのエクスポート可否を確認し、並走稼働期間を含めた移行計画を立てた上で進めることが望ましい。
Q3. 先代からの引き継ぎ資料に、開発会社との契約書自体が見つかりません。どうすればよいですか。
契約書が見当たらない場合は、まず開発会社に契約書の写しを再送してもらうよう依頼する。これは通常の事務手続きの範囲内であり、応じてもらえないケースは稀である。同時に、今後は契約書や見積書、仕様書などのIT関連資料を一元的に管理するファイル(紙またはクラウドの共有フォルダ)を社内に作り、次の承継や担当者交代の際に同じ問題が起きないようにしておくことを強く推奨する。
Q4. 契約更新のタイミングで一度に全部確認するのは大変そうです。優先順位はありますか。
一度に全項目を確認する必要はない。優先順位としては、まず「担当者が不在になった場合に事業が止まるリスク」に直結する項目、すなわちソースコードの所在確認とバックアップ体制の確認を最優先で行うべきである。次に、データのエクスポート可否と契約解除条件を確認し、最後に保守料の内訳や値上げ履歴の精査に進むという順序が、実務上は取り組みやすい。1回の更新で1〜2項目ずつ着実に埋めていくという姿勢で十分である。
Q5. 開発会社との関係は良好で、特に不満もありません。それでもこうした確認は必要でしょうか。
関係が良好であることと、リスクが備えられているかどうかは、別の問題として考える必要がある。関係が良好であるからこそ、いざ確認を求めても円滑に応じてもらえる可能性が高く、今がまさに確認を進める好機であるとも言える。逆に、関係が悪化してから確認を求めようとすると、開発会社側も防御的な姿勢になり、協力が得にくくなることが多い。良好な関係のうちに、リスク管理としての基本情報を整理しておくことは、その良好な関係を将来にわたって維持するための保険のようなものだと捉えるとよい。
契約更新の交渉では、保守費の値上げを打診されるケースも珍しくない。先代が結んだ保守契約、値上げ打診を受けたときの判断基準で判断基準を整理している。
まとめ
保守契約の更新は、単なる事務手続きではない。事業承継後の後継社長にとって、開発会社との関係を主体的に組み直すことができる、数少ない好機である。先代の時代に積み重なった暗黙の了解や、情報の非対称性、属人化のリスクは、代替わりのタイミングで一度可視化しなければ、そのまま次の何年も引き継がれてしまう。
本稿で示したチェックリストは、技術的な専門知識を前提としない。必要なのは「何を受け取っているか」「もし契約が切れたら会社はどう困るのか」という、経営者としてのリスク管理の視点だけである。ソースコードの所在、仕様書の現状、保守範囲の明確さ、障害対応体制、データの持ち出し可否、契約解除の条件——これらを一つずつ確認し、契約書や覚書に明記していく作業は、地味であっても、会社の事業継続性を守るための最も基本的な経営行為である。こうして保守契約の土台を整えたあと、次の刷新プロジェクトまでどれくらいの間隔を空けるべきかで悩む場面も出てくる。その際は刷新完了後、次の刷新までどれくらい間隔を空けるべきかを判断の参考にしてほしい。
次に保守契約の更新書類が届いたら、サインの欄だけを見るのではなく、まずこのチェックリストを机の上に広げてほしい。それが、先代から引き継いだ会社を、後継社長自身の手できちんと守り抜いていくための、最初の一歩になる。
