現在の保守会社から切り替えたいものの、「他社が開発したシステムを別の会社へ任せられるのか」「変更すると業務が止まらないか」と判断できず、検討が止まることがあります。
システム保守会社の変更は可能です。ただし、どのシステムでも同じ条件で引き継げるわけではありません。現行契約、ソースコードやデータベースの有無、サーバーや各種アカウントの管理状況、現行会社の協力範囲によって難易度が変わります。
契約を解除してから引継ぎ先を探すのではなく、先に契約とシステム資産を確認し、新しい会社が受け入れ可能かを判断することが重要です。本記事では、変更を検討すべきケース、変更前の確認事項、新しい保守会社の選び方、移管時の注意点を整理します。
1. システム保守会社は変更できる
システムを開発した会社と、運用開始後の保守を担当する会社は、必ずしも同じである必要はありません。必要な資産や権限があり、現行システムを調査できる会社であれば、他社開発システムの保守を担当できる場合があります。
ただし、「会社を変更できること」と「問題なく引き継げること」は別です。判断には、少なくとも次の3点が必要です。
- 現行契約の解約・引継ぎ条件に問題がないか
- ソースコード、DB、サーバー、管理アカウントなどを確保できるか
- 新しい会社が現行システムを調査し、受入可否を判断できるか
資料や権限が不足している場合は、調査範囲が広がったり、移管以外の対応が必要になったりします。「必ず引き継げる」とは考えず、契約解除前に受入可否を確認してください。
2. 保守会社の変更を検討すべきケース
担当者との相性だけで変更を決めるのではなく、事業継続や運用への影響から判断します。次の状態が続いている場合は、現行会社との改善協議と並行して変更を検討します。
問い合わせや障害対応の見通しが立たない
連絡がつかない、回答期限が示されない、障害時の担当や対応範囲が不明な状態は、業務停止時のリスクを高めます。契約上の対応内容と実際の運用にずれがないか確認します。
システムの状況が共有されていない
改修履歴、障害履歴、バックアップ、サーバー構成が共有されていない場合、運用が特定の会社や担当者に依存します。担当者の退職や契約終了が保守停止につながらないかを確認します。
改修や事業変更へ対応できない
小さな変更にも長期間かかる、見積の前提が説明されない、外部サービス連携やセキュリティ対応を進められない場合は、今後の事業要件に対応できる体制かを見直します。
保守範囲と費用条件が分かりにくい
保守に含まれる作業、追加費用の条件、障害時の責任分界が曖昧だと、問題発生時に対応の空白が生まれます。料金だけでなく、誰がどこまで担当するかが明文化されているかを確認します。
3. 変更前に確認すべき契約・システム資産
保守会社の変更で避けたいのは、契約解除後に必要なデータや権限を取得できない状態です。現行会社へ解約を通知する前に、次の内容を確認します。
契約の確認
- 契約期間、自動更新、解約通知期限
- 現在の保守対象と対象外作業
- ソースコード、設計書、データの提供条件
- 著作権、利用権、改変権に関する条項
- 契約終了時のデータ返却、削除、引継ぎ支援
- アカウントやライセンスの名義
- 移管先への情報開示条件
個別契約の法的判断が必要な場合は、自社の法務担当者や契約の専門家へ確認してください。
システム資産の確認
確認対象はソースコードとサーバーだけではありません。システムを動かすために必要な資産と、その管理者を整理します。
- ソースコード、リポジトリ、リリース済みプログラム
- DB、バックアップ、データ項目の説明
- サーバー、クラウド、ネットワーク、監視設定
- ドメイン、DNS、SSL、メール環境
- 外部API、SaaS、決済、通知などの連携先
- OS、ミドルウェア、ライブラリのライセンス
- 管理画面、クラウド、リポジトリなどの管理アカウント
- 設計書、運用手順、定期処理、障害・変更履歴
各資産について、存在だけでなく「誰の名義か」「自社で管理者権限を確保できるか」「契約終了後も利用できるか」を確認します。現行会社名義の契約がある場合は、名義変更、新規契約、設定変更のどれが必要かを事前に協議します。
4. 他社開発システムでも引継ぎできるか
引継ぎ可否は、開発会社名ではなく、現在残っている資産とシステムの状態から判断します。
ソースコード、データ、サーバー権限、主要な設計情報があり、動作確認できる環境があれば調査の見通しを立てやすくなります。一方、ソースコードがない、管理者アカウントへ入れない、外部サービスの契約者が不明といった状態では、追加調査や別の対応が必要です。
仕様書がなくても、残っているソースコード、実行環境、データ、画面から調査できる可能性はあります。ただし、受入可否は個別の状態で変わり、「仕様書がなくても引き継げる」とは断定できません。
移管の全体像は、現状確認、受入可否の判断、契約と役割の整理、必要資産の受領、動作確認、保守開始です。
5. 新しい保守会社を選ぶ際の確認項目
新しい会社は、「同じ言語で開発できるか」だけでは選べません。他社が作ったコードや構成を読み解き、現在の業務を止めずに運用できるかを確認します。
受入前の調査範囲を説明できるか
ソースコード、サーバー、DB、外部連携、定期処理のどこまでを確認するか、調査結果をどう共有するか、受入不可となる条件は何かを聞きます。不明点を確認済み・未確認・リスクに分けて説明できる会社かも重要です。
アプリケーション以外の運用も確認できるか
障害には、サーバー容量、証明書、DNS、メール、バックアップ、外部APIが関係することもあります。自社で対応する範囲と、外部事業者と連携する範囲を確認します。
保守開始後の運用と責任分界が明確か
問い合わせ窓口、対応時間、優先度、障害時の連絡、変更管理、バックアップ確認をどのように運用するかを聞きます。月額保守の対象外や追加見積となる条件も、契約前に揃えます。
情報を継続して共有できるか
新しい会社への依存を繰り返さないため、改修履歴、構成情報、アカウント一覧、運用手順をどのように更新・共有するかを確認します。
開発会社を比較する一般的なポイントは、システム開発会社を選ぶ際のポイントも参考にしてください。
6. 保守移管で発生しやすい問題
保守移管では、技術より先に情報や責任の空白が問題になることがあります。
現行会社から十分な情報を受け取れない
担当者の退職、資料の未更新、短い契約終了期間によって、説明を受けられる範囲が限られる場合があります。解約通知前に、新しい会社が判断に必要とする情報を整理しておきます。
アカウントや契約の名義を変更できない
サーバー、ドメイン、SSL、メール、外部APIが現行会社名義の場合、パスワードの受領だけでは移管できないことがあります。契約主体と変更方法をサービスごとに確認します。
保守開始までに対応の空白が生まれる
旧会社の契約終了日と新会社の開始日が連続していても、新会社がシステムを理解する時間がなければ実質的な空白が生まれます。受入調査に必要な期間を見込み、旧会社と新会社の対応範囲を明確にします。
正常動作の基準が分からない
テスト仕様や正常時の結果が残っていない場合、移管時点の状態を判断しにくくなります。重要業務と主要機能を優先し、既知の不具合と移管後に確認する事項を分けて記録します。
7. 費用・期間を左右する要素
保守会社変更の費用と期間は、主に次の条件で変わります。
- ソースコード、設計書、運用資料の整備状況
- サーバーやクラウドへのアクセス可否
- 使用言語、フレームワーク、OS、DBの状態
- 機能数、利用部門、利用者数
- 外部APIやSaaSなどの連携数
- 定期処理、監視、バックアップの複雑さ
- テスト環境と確認方法の有無
- 現行会社から説明を受けられる期間
- 障害などにより移管を急ぐ事情
- データ移行やサーバー移行を同時に行うか
見積は金額だけでなく、初期調査の範囲、保守開始前に解消する問題、月額保守の対象、追加費用の条件を揃えて比較します。具体的な費用や期間は、対象システムと契約条件の確認が必要です。
8. 相談前に整理しておく情報
新しい保守会社へ相談する際は、次の情報を分かる範囲で整理します。
- システムの用途と、停止時に影響する業務
- 保守会社を変更したい理由と、現在の問題
- 利用者数、利用部門、利用時間帯
- システムのURL、主要機能、外部連携
- 分かる範囲の言語、サーバー、クラウド、DB
- ソースコード、設計書、契約書、管理アカウントの有無
- 現行契約の終了希望時期と、今後の改修予定
すべての資料が揃っていなくても、分かる範囲と不明な項目を分けることで、引継ぎに必要な追加調査を切り分けやすくなります。「資料がない」「何を確認すべきか分からない」という状態も、推測で埋めず、そのまま整理してください。
現行契約を解除する前に、確保できている資産と不足している情報を把握し、新しい保守会社へ受入可否と調査範囲を確認することが、変更後の対応空白を避ける第一歩です。
