保守会社を乗り換える手順：引き継ぎ資料とリスクの確認方法

保守会社の乗り換えを成功させる鍵は、「新しい会社を選ぶこと」よりも「今の会社から何を、どの順番で受け取るか」を先に固めることにあります。ソースコード、設計資料、サーバーやクラウドの管理権限、外部サービスのアカウント、運用の手順、過去の障害の記録。これらが揃わないまま契約を切り替えると、新しい保守会社はシステムの中身を手探りで調べることになり、その間に障害が起きれば復旧に時間がかかります。乗り換えは、現行の会社との関係が続いているうちに、並行期間を設けて段階的に進めるのが原則です。

この記事は、今の保守会社の対応や費用に不満がある、開発した会社が保守を続けられなくなった、社内の体制変更で保守の委託先を見直したい、といった事情で乗り換えを検討している事業責任者・情報システム担当・経営者の方に向けたものです。乗り換えを判断する基準、事前に確認すべき契約と権利、現行の会社に依頼する事項、引き継ぎ資料の一覧、並行期間の進め方、リスクの確認方法を順に説明します。

開発の途中で開発会社を変える場合の考え方は、開発会社を途中で変更するにはで詳しく扱っています。本記事は、すでに稼働しているシステムの保守を移すことに焦点を当てます。

保守会社の乗り換えを検討すべき状況

乗り換えには手間とリスクが伴います。まずは、本当に乗り換えが必要か、今の会社との話し合いで解決できないかを確かめます。乗り換えを検討する価値があるのは、たとえば次のような状況です。

• 障害時の連絡が遅い、復旧に時間がかかる状態が続き、改善を求めても変わらない。
• 担当者が一人しかおらず、その人が不在だと何も進まない。
• 依頼した改修がいつまでも終わらない、見積もりの根拠が説明されない。
• OSやライブラリの更新が行われておらず、指摘しても計画が出てこない。
• 保守会社が事業を縮小する、担当分野から撤退するなど、継続が難しくなった。
• 事業の拡大で、求める対応時間や改修の量が今の会社の体制を超えた。

一方で、不満の原因が契約の範囲の曖昧さにある場合は、乗り換えても同じ問題が起きます。たとえば「休日に対応してくれない」という不満は、契約に休日対応が含まれていないことが原因かもしれません。この場合は、契約の範囲を見直すほうが先です。保守契約の範囲の決め方はシステム保守契約に含めるべき内容を参考にしてください。

乗り換え前に確認する契約と権利

乗り換えの準備で最初に行うべきなのは、今の契約書を読み直すことです。特に次の点を確認します。

契約の終了条件

契約の期間、更新の方法、解約の申し入れ期限を確認します。解約の申し入れが一定期間前までに必要な契約も多いため、乗り換えの時期から逆算して、いつまでに申し入れる必要があるかを把握します。

ソースコードと資料の権利

開発時の契約で、ソースコードや設計資料の権利がどちらにあるかを確認します。発注側に権利が移る契約であれば、引き渡しを求められます。開発会社に権利が残る契約や、開発会社が独自に持つ部品が組み込まれている場合は、引き続き使えるのか、使う条件は何かを確認する必要があります。権利の扱いは契約の内容によって異なるため、判断に迷う場合は弁護士などの専門家に相談してください。

サーバーやアカウントの名義

サーバー、クラウド、ドメイン、SSL証明書、メール配信サービス、決済サービスなどのアカウントが、自社の名義か、保守会社の名義かを確認します。保守会社の名義で契約されている場合、乗り換えの際に名義の変更や移管が必要になり、手続きに時間がかかることがあります。

引き継ぎへの協力の取り決め

契約終了時に、引き継ぎに協力する義務や、その作業の費用について定めがあるかを確認します。定めがない場合は、引き継ぎの作業を別途依頼することになるため、早めに相談します。

現行の保守会社に依頼する事項

乗り換えは、今の保守会社の協力があるかどうかで難しさが大きく変わります。関係が悪化してから話を切り出すと、協力を得にくくなります。乗り換えを決めたら、早い段階で誠実に事情を伝え、引き継ぎへの協力を依頼します。

依頼する事項は、次のように整理して文書で伝えます。

• 引き継ぎ資料の作成と提出（後述の一覧を参考に）
• ソースコードの最新版の引き渡しと、本番で動いているものとの一致の確認
• サーバー、クラウド、各種サービスの管理権限の移管、または自社への名義変更
• 新しい保守会社への説明の場（システムの構成、運用の手順、注意点）
• 並行期間中の問い合わせへの回答
• 未対応の不具合や、進行中の改修の状況の共有

引き継ぎの作業には、現行の会社にも手間がかかります。契約で定めがない場合は、作業の範囲と費用について合意しておくと、途中で協力が止まる事態を防げます。

受け取るべき引き継ぎ資料の一覧

引き継ぎ資料は、新しい保守会社がシステムを理解し、障害時に対応できるようにするためのものです。最低限、次の資料を受け取ります。

資料が揃わない場合も少なくありません。特に、設計書が開発当初のまま更新されていない、運用の手順が担当者の頭の中にしかない、というケースはよくあります。資料がないこと自体を責めるのではなく、並行期間中に説明を受けながら、新しい保守会社とともに資料を作り直す前提で計画を立てます。運用手順の残し方は運用手順書（Runbook）の作り方が参考になります。

乗り換えの手順と並行期間の進め方

乗り換えは、次の手順で段階的に進めます。

1. 乗り換えの目的を決める：対応の速さ、費用、体制、技術力など、何を改善したいのかを書き出します。目的が曖昧なまま新しい会社を選ぶと、同じ不満が繰り返されます。
2. 現行の契約と権利を確認する：前述の終了条件、ソースコードの権利、アカウントの名義、引き継ぎの取り決めを確認します。
3. 新しい保守会社の候補を探す：目的に合う会社を探し、システムの概要を伝えて相談します。この段階では、詳細な資料がなくても、構成の概要と課題を伝えれば、引き受けられるかの見当はつきます。
4. 現状調査を依頼する：候補の会社に、ソースコードや構成を確認してもらい、引き受けにあたってのリスクや、最初に必要な作業を洗い出してもらいます。調査には費用がかかることが多いですが、見えないリスクを把握するために欠かせません。
5. 新しい保守会社を決め、契約する：対応の範囲、時間、費用、引き継ぎ期間中の役割を決めて契約します。
6. 現行の会社に乗り換えを伝え、協力を依頼する：解約の申し入れの期限に注意しながら、引き継ぎの依頼事項を文書で伝えます。
7. 権限を移す：アカウントの管理権限を自社に集め、新しい保守会社に必要な権限を付与します。現行の会社の権限は、並行期間が終わるまで残しておきます。
8. 並行期間を設ける：一定期間、現行の会社と新しい会社の両方が関わる期間を設けます。新しい会社は、説明を受けながら公開作業や定期作業を実際に行い、手順を確かめます。
9. 切り替える：新しい会社が単独で対応できることを確認したら、問い合わせ窓口と障害の連絡先を切り替えます。
10. 旧権限を整理する：現行の会社のアカウントや権限を削除し、パスワードや認証情報を変更します。

並行期間に確かめること

並行期間は、資料だけでは分からないことを確かめるための期間です。新しい保守会社に、次の作業を実際に行ってもらいます。

• 検証環境でソースコードから動かせるか
• 公開（デプロイ）の手順を最後まで実行できるか
• バックアップから復元できるか
• 定期的な処理や月次の作業を手順どおりに行えるか
• 障害の連絡を受けてから、ログを確認し、原因を調べられるか

これらを一度も試さないまま切り替えると、最初の障害や公開作業のときに初めて問題が見つかることになります。

並行期間の長さは、システムの規模、資料の揃い具合、定期作業の周期によって決めます。月次の処理があるシステムであれば、少なくとも一度はその処理を新しい会社が行う期間を含めるのが安全です。

乗り換えのリスクと確認方法

乗り換えには、次のようなリスクがあります。事前に確認する方法とあわせて整理します。

本番のソースコードと受け取ったソースコードが違う：本番に直接修正が加えられていて、管理されているソースコードに反映されていないことがあります。新しい会社に、受け取ったソースコードから検証環境を作り、本番と同じ動きをするかを確かめてもらいます。

知らないアカウントや連携が残っている：外部サービスとの連携や、定期的に動く処理の中に、資料に書かれていないものがあることがあります。サーバーの設定や外部サービスの管理画面を一つずつ確認し、一覧と突き合わせます。

認証情報の期限切れ：外部サービスとの連携に使う認証情報や証明書には、有効期限があるものがあります。期限と更新の手順を確認し、乗り換え直後に期限が来ないかを確かめます。

古い技術が使われている：サポートが終わったOSやライブラリが使われていると、新しい保守会社がすぐに更新作業を提案してくることがあります。これは乗り換えのせいではなく、もともとあったリスクが見えるようになっただけです。更新の計画はライブラリ更新を放置するリスクを参考に立ててください。

切り替え直後の障害：新しい会社が慣れていない時期に障害が起きると、対応に時間がかかります。切り替えの時期は、繁忙期や大きなキャンペーンの前を避けます。

具体例：開発会社から保守を引き継いだ場面

ここでは架空の一般例として、数年前に開発会社に作ってもらった会員制のWebサービスを運営している会社を想定します。

開発会社は少人数の会社で、保守も同じ担当者が続けていました。ある時期から、その担当者が別の大きな案件にかかりきりになり、問い合わせへの返事が数日後になることが増えました。障害が起きた週末にも連絡がつかず、会社は乗り換えを検討し始めました。

まず契約書を確認すると、ソースコードの権利は発注側に移る契約になっていたものの、クラウドのアカウントとドメインは開発会社の名義で契約されていました。そこで、開発会社に事情を伝え、乗り換えの意向と、名義の変更を含む引き継ぎへの協力を依頼しました。開発会社側も体制の限界を感じていたため、協力的に応じてくれました。

新しい保守会社の候補には、ソースコードと構成の調査を依頼しました。調査の結果、本番の設定ファイルに資料に書かれていない外部連携があること、いくつかのライブラリがサポート終了に近いことが分かりました。新しい会社と契約した後、クラウドとドメインの名義を会社に移し、二か月の並行期間を設けました。並行期間中に、新しい会社が公開作業、月次の請求処理、バックアップからの復元を一度ずつ実施し、問題がないことを確かめてから窓口を切り替えました。

切り替えの後は、新しい会社とともに運用の手順書を作り直し、サポート終了が近いライブラリの更新を計画的に進めています。名義の変更と並行期間を省いていたら、切り替え直後の障害で身動きが取れなくなっていた可能性があります。

乗り換えでよくある失敗と避け方

関係が悪化してから切り出す：不満が積もって関係がこじれてから乗り換えを伝えると、引き継ぎへの協力を得にくくなります。乗り換えを決めたら、早い段階で誠実に伝えます。

解約を先に申し入れてしまう：新しい会社が決まる前に解約すると、空白の期間が生まれます。新しい会社との契約と並行期間を確保してから、解約の時期を決めます。

資料だけで引き継いだつもりになる：資料を受け取っても、実際に作業してみないと分からないことが多くあります。並行期間中に、主要な作業を新しい会社が実際に行う機会を作ります。

アカウントの名義を確認しない：保守会社の名義で契約されたアカウントは、移管に時間がかかります。最初に一覧を作り、自社の名義に集めます。

旧権限を残したままにする：切り替えた後も、旧保守会社のアカウントや認証情報が残っていると、情報管理上のリスクになります。切り替えの完了とともに整理します。

乗り換えのチェックリスト

• 乗り換えの目的が書き出されている
• 不満の原因が契約の範囲の問題でないことを確認した
• 契約の終了条件と、解約の申し入れ期限を把握した
• ソースコードと資料の権利の扱いを確認した
• サーバー、クラウド、ドメイン、外部サービスの名義を一覧にした
• 新しい保守会社に現状調査を依頼し、リスクを把握した
• 現行の会社に、引き継ぎの依頼事項を文書で伝えた
• 引き継ぎ資料を一覧に沿って受け取った
• 受け取ったソースコードが本番と一致することを確認した
• 並行期間中に、公開・定期作業・復元を新しい会社が実施した
• 切り替え時期が繁忙期や大きな施策の前と重なっていない
• 切り替え後に、旧保守会社の権限と認証情報を整理した

よくある質問

Q. 開発した会社以外に保守を頼んでも大丈夫ですか？

大丈夫です。ソースコードと構成の情報があれば、他の会社でも保守を引き受けられます。ただし、新しい会社がシステムを理解するまでの期間が必要で、その間は対応に時間がかかることがあります。現状調査と並行期間を設けることで、このリスクを小さくできます。

Q. 現行の会社が引き継ぎに協力してくれない場合はどうすればよいですか？

まずは契約書で、引き継ぎへの協力やソースコードの引き渡しについての定めを確認します。定めがある場合は、それに基づいて依頼します。定めがない、または協力が得られない場合は、自社で持っている権限と情報から引き継げる範囲を確認し、必要に応じて弁護士などの専門家に相談してください。

Q. 乗り換えにはどのくらいの期間がかかりますか？

システムの規模、資料の揃い具合、アカウントの名義変更の手続き、定期作業の周期によって大きく変わります。小規模なシステムで資料が揃っていれば比較的短い期間で済みますが、資料がない、名義の移管が必要、月次の処理があるといった場合は、並行期間を含めて数か月を見込むのが安全です。

Q. 乗り換えを機にシステムを作り直すべきですか？

乗り換えと作り直しを同時に進めると、リスクが重なります。まずは今のシステムを安定して保守できる状態に引き継ぎ、そのうえで、新しい保守会社の調査結果を踏まえて、改修で対応するか作り直すかを判断するのが安全です。判断の基準はシステムを作り直すべきタイミングでまとめています。

Otsumuに相談できること

現行の保守会社との関係が良好で、ソースコードや資料、アカウントの権限が自社の手元に揃っている場合は、この記事の手順に沿って新しい保守会社を選び、並行期間を設けて切り替えるだけで、自社で十分に乗り換えを進められます。保守会社の候補に現状調査を依頼すれば、リスクも事前に把握できます。

一方で、資料がほとんど残っていない、アカウントが誰の名義か分からない、システムの構成を社内で誰も把握していない、といった状況では、乗り換えの前にまず現状を調べる必要があります。調査の結果によっては、乗り換えと同時に更新作業や部分的な改修が必要になることもあります。

Otsumuは自らも事業を手がける立場から、事業への影響を起点に乗り換えの計画を立て、既存システムの現状調査、引き継ぎ資料の整備、並行期間の運用、乗り換え後の保守と改善までを一気通貫で支援しています。既存システムの保守の引き継ぎは保守・運用でご相談いただけます。範囲に応じて個別にお見積もりします。

乗り換えを決めきれていない段階でも構いません。今の契約書やシステムの概要をお持ちいただければ、確認すべき点を一緒に整理できます。まずは30分の無料相談をご利用ください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01