保守契約が切れたまま動いている先代システムのリスクと再契約の判断

先代から会社を継いだとき、株や登記の名義変更には税理士や司法書士が付いてくれます。ところが、経理ソフトや販売管理システムの「保守契約」については、誰も教えてくれません。気づけば見積書を出す基幹システムの保守契約が3年前に切れていて、それでも画面は普通に動いている——そんな状態のまま日々の業務を回している二代目・三代目経営者は少なくありません。

結論から言うと、「動いているから大丈夫」という判断は、承継直後の経営者が最も陥りやすい罠です。保守契約が切れたシステムは、壊れるまで誰も教えてくれないだけで、内部ではセキュリティパッチが止まり、対応できる技術者がいなくなり、法改正への追従も止まっています。再契約すべきかどうかは「壊れているか」ではなく「止まったら会社が止まるか」「今の契約範囲で本当に守られているか」で判断すべきです。本記事では、保守切れシステムの具体的なリスク、再契約前に確認すべきチェック項目、そして再契約以外の選択肢まで、非IT出身の後継社長が自分の言葉で判断できるように整理します。

こんな状態に心当たりはないか

まず、次のような状態に一つでも当てはまるなら、この記事は今のあなたに関係があります。

  • 先代が亡くなった、または引退してから、システムの保守費用を誰にいくら払っているか把握していない
  • 経理担当の古参社員に「あのシステム、まだ大丈夫?」と聞いたら「先代の時からずっとこれだから大丈夫」と返された
  • ベンダーから来る年次の保守更新の案内を、内容も確認せず経理が機械的に振り込んでいる(あるいは、逆に振込が止まっていることに誰も気づいていない)
  • システムを作った会社が今も存在するか、電話が通じるか分からない
  • パソコンを買い替えたら一部の機能が動かなくなったが、原因を追及せず放置している

このどれかに心当たりがあるなら、まずやるべきことは「契約書を引っ張り出すこと」です。次章から、なぜそれが急を要するのかを説明します。

「保守契約が切れている」とはどういう状態か

保守契約とは、システムに不具合が出たときの修正対応、法改正やOSアップデートへの追従、セキュリティパッチの適用、問い合わせ対応などを、開発会社やベンダーが提供し続けるための契約です。多くの業務システムはこの契約が年単位の自動更新、あるいは都度更新の形になっており、更新を止めた瞬間に「サポート外」の状態に切り替わります。

厄介なのは、保守契約が切れても、システムの画面自体は普通に動き続けることです。見積書は今日も印刷できるし、在庫データも今日も表示される。だからこそ、保守切れは「壊れて初めて気づく」問題であり、経営者が能動的に確認しない限り放置され続けます。ある調査解説記事は、開発会社との契約終了などによってシステムの内容を把握している人間がいなくなった状態を「システム孤児化」と呼んでいます(アレグビット)。保守切れは、システムというより「そのシステムを理解している人間」が先にいなくなる問題だと捉えると実態に近いです。

なぜ承継後にこの問題が表面化しやすいのか

保守切れの放置自体は、創業者が経営していても起こり得ます。しかし承継後の会社で特に深刻化しやすいのには理由があります。

第一に、先代とベンダーの間には、契約書に書かれていない口約束や信頼関係が積み重なっていることが多く、先代が引退すると同時にその関係も途切れてしまうからです。先代の携帯電話に登録されていた「システム屋の田中さん」の個人番号が、実は唯一の連絡手段だった、というようなケースは珍しくありません。

第二に、後継者自身が非IT出身であることが多く、保守契約の重要性を実感として持てないまま承継してしまうからです。株式評価や相続税、登記変更には専門家が付きますが、システムの保守契約には「担当の専門家」という概念が存在しません。

第三に、経理や総務を長く担当してきた古参社員が「先代の時からこうだから」という理由だけで契約内容を疑わずに運用を続けてしまうことです。属人化した運用は、担当者本人が退職・異動するまで問題が表面化しません。

中小機構の解説では、後継者は「人の壁」(社内にITに詳しい人材がいない、社外の相談相手も分からない)、「システムの壁」(過去に導入した仕組みや慣習が変化を拒む)、「情報の壁」(自社にとって何が最適なITソリューションか分からない)という3つの壁に直面するとされています(中小機構「事業承継とIT」)。

保守契約の問題は、この3つの壁が同時に噴き出す典型例です。相談相手がいない(人の壁)、既存システムへの依存から抜け出せない(システムの壁)、何を基準に再契約や乗り換えを判断すべきか分からない(情報の壁)——このどれもが、承継直後の経営者を身動きが取れなくさせます。

保守契約が切れたまま放置する3つのリスク

保守切れを放置した場合に起こり得るリスクは、大きく3種類に整理できます。

保守契約が切れたまま放置することで生じる3つのリスクを整理したチェックリスト図。

リスク1:セキュリティパッチが止まり、外部攻撃の入口になる

保守契約が切れると、OSやミドルウェア、業務ソフト自体の脆弱性が発見されても修正パッチが提供されなくなります。攻撃者は既知の脆弱性を突いて侵入するため、パッチが止まったシステムは時間が経つほど攻撃対象として「狙いやすい」状態になっていきます。特に取引先とデータをやり取りする基幹システムや、顧客の個人情報を扱う販売管理システムが保守切れのまま外部ネットワークに接続されている場合、自社だけでなく取引先を巻き込む情報漏洩のリスクに直結します。

IPAの実態調査でも、サプライチェーン全体でのセキュリティ対策の不備が取引先にまで深刻な影響を及ぼすことが指摘されており、セキュリティ体制を整備している企業の方が新規取引につながりやすい傾向も明らかになっています(IPA「2024年度 中小企業における情報セキュリティ対策に関する実態調査」)。保守切れの放置は、単なる社内問題ではなく、取引先からの信用にも影響する経営課題です。

リスク2:トラブル発生時に「誰も直せない」状態になる

保守契約が生きていれば、不具合発生時にベンダーへ連絡すれば対応してもらえます。しかし契約が切れていれば、その窓口自体が存在しません。開発した会社がすでに廃業していたり、担当者が退職していたりすれば、システムの中身を知る人間がこの世に一人もいない、という事態も起こり得ます。

これは単一障害点(SPOF)の典型例です。特定の1台のPC、特定の1人の担当者、特定の1社のベンダーにしか動かせない仕組みは、その一点が失われた瞬間に業務全体が止まります。保守切れのまま放置されたシステムは、まさにこの単一障害点が顕在化した状態だと言えます。突然の保守打ち切りに備えた選択肢を事前に検討しておく重要性を指摘する専門会社の解説もあり、猶予期間なく業務停止に追い込まれる企業は少なくないとされています(ANSネット「突然の"保守打ち切り"がもたらすリスク」)。

リスク3:法改正・制度変更に追従できなくなる

インボイス制度や電子帳簿保存法のように、税務・会計まわりの制度は数年単位で変わり続けます。保守契約が生きているシステムであれば、こうした制度変更にベンダーが対応してアップデートを提供してくれますが、保守切れのシステムはこの追従が止まります。結果として、法改正後も旧仕様のまま帳票を出力し続け、知らないうちに制度非対応の書類を取引先や税務署に提出してしまうリスクが生まれます。

この3つのリスクに共通するのは、「表面上は動き続けているのに、内部の守りだけが静かに失われていく」という点です。壊れて初めて気づくのではなく、契約書を確認する段階で気づくべき問題です。

再契約すべきかどうかの判断基準

保守契約が切れていると分かったら、次に考えるべきは「同じベンダーと再契約するか、別の選択肢を取るか」です。ここで感情的に「先代が使ってきたものだから」と判断するのではなく、次の4つの軸で機械的に評価することをお勧めします。

保守契約を再契約すべきかどうかを判断する意思決定ツリー図。

判断軸確認すること再契約が妥当なサイン見直しが必要なサイン
事業の中核度このシステムが止まると受発注・経理・給与のどれが止まるか止まると即日業務停止止まっても代替手段(手作業・別ソフト)で数日は回る
ベンダーの存続性開発会社が今も事業を継続しているか、担当者が在籍しているか会社として存続し、後任も育成されている実質1人の技術者に依存、会社の将来が不透明
技術基盤の古さ稼働しているOS・言語・データベースが公式サポート中かまだ数年はサポートが続く見込みすでにEOL(サポート終了)を迎えている、または迎える寸前
更新コストの妥当性再契約の年額と、乗り換え・刷新にかかる概算費用を比較したか再契約の方が総コストで明確に安い再契約を続けても数年後にはどのみち刷新が必要

まず「事業の中核度」を見てください。止まった瞬間に見積書も出せない、給与計算もできないというレベルの基幹システムであれば、保守契約の空白は一日たりとも許容できません。逆に、使用頻度の低い補助的なツールであれば、再契約を急がず刷新や廃止も含めて検討する余地があります。

次に「ベンダーの存続性」です。保守契約を再開しても、開発会社自体が数年以内に廃業したり、担当技術者が退職したりすれば、また同じ問題が繰り返されます。契約を再開する前に、開発会社の現在の従業員数や事業継続の見通しについて、遠慮せず直接尋ねるべきです。

「技術基盤の古さ」も見落とせません。すでにレガシーシステム化している基盤の上に保守契約だけ結び直しても、根本的な延命にしかならないケースがあります。たとえばサーバーOSやデータベースソフト自体がメーカーのサポート対象外になっていれば、保守契約を結んでもベンダーが対応できる範囲は限定的です。この場合は、保守再契約と並行してシステム刷新の計画を立てる必要があります。

最後に「更新コストの妥当性」です。年間の保守費用が数十万円だったとしても、それを5年続ければ数百万円になります。同じ金額感で、より新しい基盤へ刷新できる可能性があるなら、単純な再契約よりも刷新の方が長期的に合理的な場合があります。

再契約前に必ず確認すべき5つの項目

再契約の意思が固まったとしても、契約書にサインする前に確認すべき項目があります。先代の代から更新されてきた保守契約書は、内容が古いまま形骸化していることが少なくありません。

  1. 保守対象の範囲:契約書に記載されたシステム構成と、実際に稼働している構成が一致しているか。増設したPCや追加した周辺機器が対象外になっていないか。
  2. 対応時間とSLA:障害発生時に何時間以内に一次回答があるのか。平日日中のみの対応なのか、休日・夜間もカバーするのか。
  3. バックアップの取得主体:バックアップの取得と復旧テストは誰の責任範囲か。ベンダー任せにしていて、実際には誰も復旧テストをしていないケースは多い。
  4. 契約終了後のデータ移管条件:将来ベンダーを乗り換える場合、データを標準形式でエクスポートできる契約になっているか。ベンダーロックインの度合いを事前に確認する。
  5. 担当者の引き継ぎ体制:ベンダー側の担当者が退職・異動した場合、後任にどう引き継がれるか。属人化しているのは自社だけでなく、ベンダー側も同じ問題を抱えていることがある。

これらを確認せずに「とりあえず今まで通りの内容で」と再契約書にサインしてしまうと、次に問題が起きたときにまた同じ壁にぶつかります。

古参社員へのヒアリングで見えてくること

保守契約の実態を把握する近道は、経理や総務を長年担当してきた古参社員への丁寧なヒアリングです。ただし聞き方には注意が必要です。「このシステム、保守契約切れてるって知ってた?」と詰問するような聞き方をすると、古参社員は「自分の管理不行き届きを責められている」と受け取り、防御的になって情報を出し渡さなくなります。

代わりに、「先代の時からのやり方を教えてほしい」という姿勢で、次のような質問を投げかけると実態が見えてきます。

  • このシステムのトラブルが起きたとき、これまで誰に連絡していたか
  • 年に一度の更新の案内は、誰が何を見て判断して振り込んでいたか
  • パソコンやOSを入れ替えるとき、事前にベンダーへ相談していたか、それとも入れ替えてから動くか確認していたか

これらの質問への答えが曖昧であればあるほど、保守契約の運用自体が属人化していた可能性が高いと考えられます。属人化した運用は、担当者が退職・異動・体調不良で不在になった瞬間に、誰も状況を説明できなくなります。承継直後の今だからこそ、この属人化を解きほぐすチャンスでもあります。

実際にあった放置パターンから学ぶ

保守契約の放置には、いくつか典型的なパターンがあります。自社に近いものがないか、照らし合わせてみてください。

パターン1:経理担当者の一存で更新が止まっていたケース

先代の時代に経理を任されていたベテラン社員が、コスト削減の一環として「今どき紙の見積書もほぼ出さないし、保守はもういいだろう」と自己判断で更新を止めていたケースがあります。先代には事後報告すらされておらず、後継者が決算資料を整理していて初めて、数年前から保守料の支払いが消えていることに気づいたという例です。悪気があったわけではなく、担当者なりの節約意識が裏目に出た形ですが、結果としてシステムは3年近く無防備な状態で稼働し続けていました。

パターン2:ベンダーが廃業していたことに誰も気づいていなかったケース

年に一度の保守更新の請求書が突然来なくなったのに、誰も疑問に思わずそのまま数年が経過していたケースもあります。後になって調べると、開発を担当していた小規模なシステム会社が代表者の高齢化を理由に廃業しており、請求自体が止まっていただけだったと判明します。保守契約が「自然消滅」していたにもかかわらず、システムが動き続けていたために誰も異変に気づけなかった典型例です。

パターン3:先代の口約束が引き継がれず、再契約の条件が不明だったケース

先代がベンダーの社長と個人的に親しく、「何かあったら電話一本で対応してもらえる」という口約束のような関係で保守が成り立っていたケースもあります。契約書には最低限の内容しか書かれておらず、実際のサポート範囲や対応スピードは、あくまで先代とベンダー社長との人間関係に依存していました。先代が引退すると、この暗黙の合意は引き継がれず、後継者は契約書に書かれた薄い内容だけを頼りに交渉をやり直す羽目になりました。

これらのパターンに共通するのは、どれも「誰かが悪意を持って隠していたわけではない」という点です。属人化した運用が積み重なった結果、誰も全体像を把握しないまま時間が過ぎていっただけです。だからこそ、後継者自身が能動的に契約書と請求履歴を洗い出す作業を避けて通ることはできません。「触ると壊れる」と言われ続けてきたシステムを調査する具体的な順番は、「触ると壊れる」と先代に言われ続けたシステムを調査する順番で解説している。

現場の自作ツールや個人所有ソフトが保守契約の外側にあることも

保守契約の対象を確認する際、見落とされがちなのが「契約書に載っていない周辺ツール」です。基幹システム本体は正式な保守契約の対象になっていても、その周りで実際の業務を支えている表計算ソフトの自動処理機能を使った集計シートや、特定の社員が個人的に導入した業務ツールは、そもそも契約の対象外であることが珍しくありません。

これらは多くの場合、先代の時代に「ちょっと便利だから」と現場主導で作られたもので、作成した本人以外は中身を理解していないことがほとんどです。基幹システムの保守契約を再確認する作業の延長として、こうした周辺ツールの棚卸しも同時に行うことをお勧めします。基幹システムを守っても、その周りにある個人依存のツールが先に壊れてしまえば、結局は同じように業務が止まります。

セキュリティパッチが止まった状態を放置した場合の実務上の影響

ここまで抽象的に「セキュリティリスク」と述べてきましたが、実務でどのような影響が出るのかをもう少し具体的にイメージしておきましょう。

まず、ウイルス対策ソフトの定義ファイルは更新され続けていても、OS自体のセキュリティパッチが止まっていれば、既知の脆弱性を突く攻撃には無力です。取引先とのデータ連携用に開放しているポートや、リモートアクセス用のVPN機器が保守切れのまま放置されていれば、そこが侵入経路になり得ます。

次に、万が一情報漏洩が発生した場合、個人情報保護法上の対応(本人への通知、個人情報保護委員会への報告など)に加えて、取引先への説明責任も発生します。保守契約が切れていたことが判明すれば、「分かっていて放置していたのではないか」という信用問題にも発展しかねません。実際に取引先からセキュリティ対策の状況について書面での確認を求められる場面は増えており、保守切れの放置はいざというときの説明力そのものを弱めます。

さらに、ランサムウェアに感染した場合、保守契約が生きていればベンダーによる復旧支援やバックアップからのリストア支援を受けられる可能性がありますが、契約が切れていれば、その支援すら得られません。身代金を払うか、データを諦めるかという二択に追い込まれる前に、保守契約の有無を確認しておく価値は十分にあります。

再契約の交渉で後継者が使える「聞き方」

保守契約を再開する際、多くの後継者は「専門用語が分からないまま、ベンダーの言いなりで契約書にサインしてしまう」ことを恐れています。しかし、専門知識がなくても、次のような聞き方をすれば、ベンダー側の説明の質を見極めることができます。

  • 「このシステムが止まったら、うちの業務はどこまで止まりますか」と聞き、答えが具体的かどうかを見る
  • 「先代の時の契約と、今回提案いただく契約で何が変わりましたか」と聞き、比較で説明できるかを見る
  • 「もし御社が今後事業を続けられなくなった場合、うちのデータはどうなりますか」と聞き、誠実に答えるかを見る
  • 「見積もりの内訳で、人件費相当分と部品・ライセンス費相当分はそれぞれどのくらいですか」と聞き、内訳を開示する姿勢があるかを見る

誠実なベンダーであれば、これらの質問に対して業界用語を並べるのではなく、平易な言葉で具体的に答えてくれるはずです。逆に、質問をはぐらかしたり、「今まで通りで大丈夫です」としか言わないベンダーであれば、再契約後も同じ不透明さが続くと考えた方がよいでしょう。

経営者保証や事業承継税制との関係を混同しない

保守契約の話をしていると、事業承継における経営者保証の解除や、事業承継税制の特例措置など、金融・税務まわりの制度と混同してしまう経営者も見られます。しかし、これらはまったく別の制度です。経営者保証の解除は金融機関との交渉、事業承継税制は税理士が扱う相続・贈与税の猶予制度であり、いずれもシステムの保守契約とは直接の関係はありません。

ただし、間接的なつながりはあります。金融機関から融資を受ける際や、M&Aで会社を売却する際には、システムの管理状況やセキュリティ体制がデューデリジェンスの対象になることがあります。保守契約が切れたまま放置されているシステムは、この場面で「管理が行き届いていない会社」という評価につながりかねません。日々の業務のためだけでなく、将来の資金調達や事業売却の選択肢を狭めないためにも、保守契約の整理は早いうちに済ませておく価値があります。M&Aで承継した会社が攻めのIT投資に踏み出す前に確認すべき順番は、ガイドM&Aで承継した会社が、攻めのIT投資に踏み出す前に確認すべき順番も参考になる。

再契約以外の選択肢も並べて考える

保守契約の再契約は唯一の答えではありません。状況によっては次の選択肢も比較検討に値します。

  • 縮小移行:同じベンダーに保守を依頼しつつ、対象範囲を必要最小限に絞り込んでコストを抑える
  • 他社への乗り換え:既存システムのデータ形式を活かしたまま、保守体制がより安定した別のベンダーに切り替える
  • クラウドサービスへの置き換え:自社専用に作られたオンプレミスのシステムを、保守がベンダー側で自動的に行われるクラウド型のサービスに置き換える
  • 段階的な刷新:全面刷新は費用もリスクも大きいため、優先度の高い機能から段階的に新しいシステムへ移していく

どの選択肢を取るにしても、共通して必要なのが「今、何がどう動いているか」を一覧化した記録です。保守契約の有無、稼働しているソフトやOSのバージョン、担当者の連絡先などを一枚の台帳にまとめておけば、次に保守契約を検討するタイミングでも、後任の担当者に引き継ぐときでも、判断のスピードが格段に上がります。逆に言えば、こうした台帳がないまま「先代の時からのやり方」を踏襲し続けている限り、同じ問題は形を変えて何度でも起こります。この管理台帳の具体的な作り方は、属人化した先代システムを防ぐ、承継後の管理台帳の作り方にまとめている。

相談先がいない孤独をどう解消するか

株式の評価や登記の変更であれば、税理士や司法書士という明確な相談先が存在します。しかし、保守契約が切れたシステムをどう扱うべきかを相談できる専門家は、承継の場面ではほとんど紹介されません。結果として、後継社長は一人でベンダーとの契約書を読み解き、一人で再契約の是非を判断する羽目になりがちです。

この孤独感は、決して大げさな表現ではありません。中小機構が指摘する「人の壁」——社内にITに詳しい人材がいない、社外の相談相手も分からないという壁——は、まさに保守契約の場面で最も強く現れます。相談先が見つからないまま放置すれば、リスクは静かに積み上がり続けます。名義や契約が前任者・退職者に紐づいたまま残っているという意味では、先代の退職者PCとアカウント、承継前にやる棚卸しの手順も同じ根の問題を扱っている。

もし社内に判断材料がなければ、次の一歩として、既存のベンダーとは別に、第三者の立場でシステム構成や契約内容を評価できる専門家に一度だけでも見てもらうことをお勧めします。利害関係のない第三者の目が入るだけで、「本当に再契約すべきか」「刷新のタイミングは今か将来か」という判断の解像度は大きく上がります。

承継直後の1ヶ月でやっておきたい確認手順

最後に、実際に手を動かす手順として、承継直後の忙しい時期でも取り組める確認の流れをまとめます。専門知識がなくても、次の順番で進めれば、保守契約の実態はおおむね把握できます。

保守契約切れシステムについて承継直後1ヶ月で行う確認手順を示すフロー図。

ステップ1:契約書と請求書を1ヶ所に集める

経理の書類棚、先代のデスク、クラウドストレージなど、保守契約に関する書類が散らばっている場所すべてから、契約書と過去2〜3年分の請求書・振込記録を集めます。この段階では内容を精査する必要はなく、まず「存在するかどうか」を確認するだけで構いません。

ステップ2:稼働中のシステム一覧と契約書を突き合わせる

社内で実際に使っているシステムやソフトを箇条書きで洗い出し、集めた契約書と突き合わせます。契約書が見つからないシステム、契約書はあるが更新日が数年前で止まっているシステムを、それぞれ別に印をつけて分類します。

ステップ3:古参社員に運用の実態をヒアリングする

前述の聞き方を参考に、経理・総務の担当者へ丁寧にヒアリングします。特に「トラブルが起きたとき誰に連絡していたか」という質問は、実質的な保守の生死を判断する上で最も重要です。

ステップ4:優先順位をつけて再契約・見直しの計画を立てる

事業の中核度が高く、かつ保守契約が切れているシステムから優先的に対応します。中核度が低いものは、後回しにするのではなく「いつまでに判断するか」の期限だけ先に決めておくと、先送りが際限なく続くことを防げます。

ステップ5:判断に迷うものは第三者に見てもらう

自社の判断だけでは技術的な妥当性が分からない場合、無理に社内だけで結論を出そうとせず、利害関係のない第三者の専門家に一度相談することをお勧めします。相談すること自体にコストがかかるとしても、誤った判断で数百万円規模の損害や業務停止を招くリスクと比べれば、多くの場合は割に合う投資です。

この5つのステップは、特別なIT知識がなくても、通常の経営判断のプロセスと同じように進められます。むしろ大切なのは、専門知識よりも「誰も確認していない領域を放置しない」という姿勢そのものです。

先代の判断を否定せず、今の時代に合わせて更新するという考え方

保守契約の見直しを検討していると、「先代が選んだシステムやベンダーを変えるのは申し訳ない」という感情が湧いてくることがあります。しかし、先代がそのシステムやベンダーを選んだのは、あくまで当時の状況における最善の判断であったはずです。時間が経てば、事業規模も、扱うデータの量も、外部の脅威の水準も変わります。当時は十分だった保守体制が、今の会社の規模やリスクに対して不足しているのは、誰のせいでもなく単なる時間の経過の結果です。

古参社員に対しても同じことが言えます。先代の時代のやり方を守り続けてきたことは、決して間違いではなく、むしろ会社を支えてきた誠実さの表れです。後継者がすべきことは、その誠実さを否定することではなく、「今の会社に合わせて更新する」という前向きな提案として保守契約の見直しを進めることです。この姿勢の違いは、古参社員からの協力を得られるかどうかに大きく影響します。

まとめ:動いているからこそ、今のうちに確認する

保守契約が切れたシステムは、壊れるまで沈黙しています。だからこそ、経営者自身が能動的に契約書を引っ張り出し、ベンダーの存続性を確認し、古参社員にヒアリングをして実態を洗い出す必要があります。判断基準は「壊れているかどうか」ではなく「止まったら会社がどれだけ止まるか」「今の契約が本当に守ってくれているか」です。

先代から引き継いだシステムは、先代が信頼して選んだものであり、それ自体を否定する必要はありません。しかし、その信頼関係は先代とベンダーの間で築かれたものであり、後継者であるあなたとベンダーの間で改めて確認し直す価値があります。今日、保守契約書を引き出しから取り出すことが、数年後の業務停止を防ぐ最初の一歩になります。

よくある質問

Q1. 保守契約が切れていても、今まで一度もトラブルが起きていません。それでも急いで確認すべきですか。

A. はい、急いで確認すべきです。トラブルが起きていないのは「運が良かった」だけの場合が大半で、保守切れの間もセキュリティ上の脆弱性は静かに蓄積しています。トラブルが起きてから動くのでは、対応できるベンダーを探すだけで数週間かかることもあります。動いている今のうちに契約状況を洗い出すことが、最もコストの低いタイミングです。

Q2. 先代が契約していたベンダーと連絡が取れません。どうすればいいですか。

A. まず会社の登記情報や請求書の発行元情報から、ベンダーが現在も事業を継続しているかを確認してください。廃業や休眠が確認できた場合は、システムの中身を理解している人間が社外にいない状態と考え、早急に第三者のIT専門家にシステム構成の調査を依頼することをお勧めします。このような、開発会社と連絡が取れなくなったシステムの調査・引き継ぎ・保守を専門に引き受ける会社(システム引き継ぎ・レスキュー、運営会社ゼットリンカーの受託メニュー)もあります。データのバックアップが手元にあるかどうかも同時に確認してください。連絡が取れなくなった開発会社に対してまず確認すべきことは、先代の代からの開発会社と連絡が取れなくなったとき、まず確認すべき3つのことにまとめている。

Q3. 保守契約を再開する費用と、システムを刷新する費用、どちらを優先すべきですか。

A. まずは事業の中核度とシステムの技術的な古さを見てください。基幹業務が止まると即座に困る場合は、応急的にでも保守契約を再開して時間を確保するのが現実的です。一方で、稼働基盤がすでにサポート対象外の古い仕組みである場合、保守契約を結んでもベンダーが対応できる範囲は限られるため、再契約と並行して刷新の計画を立てるべきです。両者は二者択一ではなく、段階を分けて両方進めるのが実態に即した判断です。

Q4. 古参社員に契約の実態を聞いても「よく分からない」としか言われません。どう進めればいいですか。

A. 古参社員個人を責めても情報は出てきません。契約書の原本、過去の請求書、振込履歴といった「紙とデータの記録」から実態を洗い出す方が確実です。それでも情報が不足する場合は、現在稼働しているシステムそのものを外部の専門家に見てもらい、ログや設定から実態を逆算してもらう方法もあります。属人化した記憶に頼らず、記録と現物から判断材料を集める姿勢が重要です。