システムの保守だけ別の会社に切り替えられる？引き継ぎ前に確認する契約・引渡し物と進め方

「開発してくれた会社とは別の会社に、保守（＝公開後の不具合対応や更新作業）だけお願いしたい」。そう考えても、今の開発会社がきちんと引き継いでくれるのか、途中でシステムが止まらないかが不安で、なかなか動けない発注者は少なくありません。

先に結論をお伝えします。システム保守の切り替え・引き継ぎは、契約の確認と「引き継ぐものの一覧」づくりを先にやれば、多くの場合は計画的に進められます。順番は「契約を読む → 引き継ぐものを棚卸しする → 新しい保守会社に調査・見積もりを頼む → 並行期間を設けて権限を移す → 今の会社との契約を終える」です。

この記事では、保守会社の切り替えで発注者が確認すべき契約のポイント、引き継ぐものの一覧表、スケジュールの例、やりがちな失敗、今の開発会社と良い関係のまま終えるコツを解説します。

システム保守の切り替えで引き継ぎが不安になる3つの理由

理由1：何を「持っていない」のかが分からない

システムが動いている限り、発注者はサーバーやドメイン（＝サイトの住所にあたる「〇〇.co.jp」などの名前）の契約を意識しません。いざ切り替えようとして初めて、「サーバーは誰の名義？」「管理画面のパスワードは誰が知っている？」と分からないことに気づくケースがよくあります。

理由2：契約書に引き継ぎのことが書かれていないことがある

開発時の契約書は、作ることを中心に書かれています。保守を終えるときの手順や、引き継ぎへの協力まで決めていない契約も珍しくありません。決めていないことは、今の開発会社にとっても「どこまでやればいいのか」が分からない状態です。

理由3：引き継ぎには今の開発会社の手間がかかる

資料の整理や新しい会社への説明は、今の開発会社にとって追加の作業です。契約で決まっていない作業であれば、別途費用の相談になるのは自然なことです。「協力してくれない」のではなく、作業範囲と費用が決まっていないだけという場合も多いと考えておきましょう。

ステップ1：まず契約書で確認したい3つのポイント

最初にやるべきことは、開発時の契約書と保守契約書を手元にそろえることです。見るべきポイントは次の3つです。

契約期間・自動更新・解約予告

保守契約には「期間満了の◯か月前までに申し出がなければ同じ条件で更新する」といった自動更新の定めが入っていることがあります。IPA（情報処理推進機構）が公開しているモデル契約書の保守運用の仕様書サンプルにも、このような自動更新の書き方の例や、中途解約の際に◯か月前までに書面で通知し、中途解約料金を定める例が載っています。

📰 出典：IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」

自社の契約の「更新日」「解約予告の期限」「中途解約時の費用」を確認し、カレンダーに書き込んでおきましょう。ここから逆算してスケジュールを立てます。

成果物・ソースコードの権利と引渡し

ソースコード（＝プログラムの設計図にあたる文章）の著作権がどちらにあるかは、契約によって異なります。IPAのモデル契約書は、すべての著作権をベンダ（開発会社）に帰属させる案、汎用的に使えるプログラム等はベンダに・それ以外はユーザ（発注者）に帰属させる案、それ以外を共有とする案という複数の選択肢を示しています。

同じ資料の中でIPAは、著作権を持たないユーザでも、情報システム子会社などの別の会社に保守運用を委託することは可能だという整理を示しています。また、ソースコードや関連資料の交付を受けるには、納入物にソースコードを明記する方法などがあると説明しています。

📰 出典：IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」

つまり確認したいのは「著作権がどちらにあるか」だけでなく、「納入物にソースコードや設計書が含まれていたか」「実際に受け取っているか」です。

引継ぎへの協力や資料の返還の定め

契約終了時に資料を返す・引き継ぎに協力する、といった定めがあるかも確認します。定めがなければ、引き継ぎ作業は新たにお願いする業務として、範囲と費用を相談することになります。

なお、契約書の読み方は契約ごとに異なります。解約料や権利の扱いで判断に迷う場合は、弁護士などの専門家に確認してください。この記事の説明は一般的な考え方の紹介です。

ステップ2：引き継ぐものを一覧にする（棚卸し表）

次に、引き継ぐべきものを一覧にします。以下の表を自社用に写して、「誰の名義か」「どこにあるか」を埋めていきましょう。

分類	引き継ぐもの	確認したいこと
プログラム	ソースコード・リポジトリ（＝ソースコードの保管場所と変更履歴）	最新版か、どのアカウントで管理しているか
資料	設計書・仕様書・構成図	最新の状態に更新されているか
サーバー	レンタルサーバー・クラウドの契約	契約名義・支払者・管理者アカウント
ドメイン	ドメイン名の登録情報	登録者の名義・管理している事業者・更新期限
SSL証明書	通信を暗号化する電子証明書	契約者・更新方法・有効期限
外部サービス	メール配信・決済・地図・分析ツールなど	契約名義・APIキー（＝サービスをつなぐ鍵）の管理者
権限	管理画面・サーバー・データベースの管理者権限	誰が持っているか、共有パスワードはないか
データ	データベース・バックアップ	取得の頻度・保管場所・戻し方
運用手順	更新・リリース・定期作業の手順書	手順が文書になっているか
履歴	障害・問い合わせ・改修の履歴	過去のトラブルと対処内容

特に大切なのはサーバーとドメインの名義です。開発会社の名義で契約されている場合、名義変更や契約の移し替えが必要になり、時間がかかることがあります。

たとえば「.jp」ドメインの管理事業者を変更する手続きには、ドメインごとの認証コード（AuthCode）が必要で、手続きの開始から終了まで数日程度かかる場合があるとJPRS（日本レジストリサービス）は案内しています。

📰 出典：JPRS「ドメイン名の管理指定事業者の変更」

ドメインやサーバーの手続きは種類ごとに異なるため、どの手続きが必要かは今の開発会社・新しい保守会社の両方に確認しましょう。

ステップ3〜5：保守会社を切り替える進め方とスケジュール例

ステップ3：新しい保守会社に調査と見積もりを依頼する

新しい保守会社は、ソースコードや構成を見ないと正確な見積もりが出せません。秘密保持契約（NDA）を結んだうえで、棚卸し表と資料を渡し、「現状調査」から依頼するのが一般的な進め方です。調査の結果、古い部品の更新や資料の作り直しが必要と分かることもあります。

保守会社の比べ方は開発会社の選び方の記事、保守費用の中身の見方は保守費用の内訳の記事も参考にしてください。

ステップ4：並行期間を設けて権限を移す

いきなり切り替えるのではなく、今の会社と新しい会社が両方関わる「並行期間」を設けると安心です。この期間に、今の会社から説明を受ける・新しい会社が試しに小さな作業をする・管理者権限やアカウントを発注者の名義に移す、といった作業を進めます。

ステップ5：今の開発会社との契約を終える

引き継ぎが終わったことを確認してから、今の会社の権限を外し、共有していたパスワードを変更します。資料の返還やデータの削除についても取り決めどおりに進めます。

スケジュールの例（解約予告が3か月前の場合）

以下は、よくある流れを再構成した一例です。実際の期間はシステムの規模や契約内容によって変わります。

時期	やること
解約予告の前	契約書の確認、棚卸し表の作成、新しい保守会社の候補探し
予告〜1か月目	今の会社へ切り替えの相談・通知、新しい会社の現状調査と見積もり
2か月目	新しい会社と契約、引き継ぎ説明、名義・権限の移し替え
3か月目	並行期間（新しい会社が作業し、今の会社が補助）、動作確認
契約終了日	今の会社の権限削除、パスワード変更、資料の返還・データ削除の確認

解約予告の期限に間に合わせるために新しい会社選びを急ぐと、調査が不十分なまま契約することになりかねません。予告期限の数か月前から準備を始めるのが理想です。

保守の切り替えでやりがちな失敗

• 解約を先に通知してから準備を始める：新しい会社の調査や名義変更が終わる前に契約が切れ、誰も対応できない期間ができてしまいます
• 「ソースコードをください」だけ伝える：設計書・手順書・外部サービスの設定がないと、新しい会社は動かせません。棚卸し表で範囲を具体的に伝えましょう
• パスワードをメールで一括送付してもらう：情報漏えいのもとになります。受け渡し方法を決め、引き継ぎ後は必ず変更しましょう
• ドメインやSSL証明書の更新期限を見落とす：切り替えの時期と重なると、更新漏れでサイトが表示されなくなることがあります
• 不満を理由として並べる：切り替えの理由を感情的に伝えると、協力を得にくくなります

今の開発会社と良い関係のまま切り替えるコツ

保守の切り替えは、今の開発会社を否定することではありません。社内体制の変化やコストの考え方など、発注者側の事情で保守の形を見直すのはよくあることです。

「早めに相談してもらえれば、引き継ぎ資料の整理もしやすいです。急に『来月から』と言われるのが一番困ります」

• 早めに、直接伝える：解約予告の期限ぎりぎりではなく、余裕をもって相談します
• 理由は簡潔に：「社内の方針で保守体制を見直すことになった」など、事実を短く伝えます
• 引き継ぎ作業は費用も含めて相談する：契約外の作業なら、見積もりをお願いするのが自然です
• これまでの対応にお礼を伝える：将来、過去の経緯を問い合わせる可能性もあります

IPAのモデル契約書も、システムの所有者であるユーザには、必要に応じてベンダの協力を得ながら、業務や設計のノウハウの円滑な引継ぎなど適切な管理が求められる、としています。引き継ぎは発注者が主体となって進めるもの、と考えておくとよいでしょう。

📰 出典：IPA「情報システム・モデル取引・契約書（受託開発（一部企画を含む）、保守運用）＜第二版＞」

発注者がやることチェックリスト

• ☐ 開発契約書・保守契約書をそろえ、更新日・解約予告の期限・中途解約の費用を確認した
• ☐ ソースコードや設計書が納入物に含まれるか、実際に受け取っているかを確認した
• ☐ 引き継ぐものの棚卸し表を作り、名義と保管場所を埋めた
• ☐ サーバー・ドメイン・SSL証明書・外部サービスの契約名義と更新期限を把握した
• ☐ 新しい保守会社とNDAを結び、現状調査と見積もりを依頼した
• ☐ 並行期間を含むスケジュールを、解約予告の期限から逆算して立てた
• ☐ 引き継ぎ後に今の会社の権限削除とパスワード変更を行う段取りを決めた
• ☐ 権利や解約料で迷う点を弁護士などの専門家に確認した

開発会社への質問例

今の開発会社に聞く質問

• 「保守体制の見直しを検討しています。引き継ぎをお願いする場合、どのような資料をお渡しいただけますか？」
• 「サーバー・ドメイン・外部サービスの契約名義と管理者アカウントの一覧をいただけますか？」
• 「引き継ぎの説明や資料整理をお願いする場合、作業範囲と費用のお見積もりをいただけますか？」

新しい保守会社に聞く質問

• 「引き継ぎ前の現状調査では、何を確認し、どのくらいの期間と費用がかかりますか？」
• 「並行期間はどのくらい必要だと考えますか？その間にどんな作業をしますか？」

まとめ：保守会社の切り替えは「契約確認」と「棚卸し」から

保守だけ別の会社に切り替えることは、準備をすれば計画的に進められます。ポイントは次のとおりです。

• 契約書で、更新・解約予告・権利と納入物・引き継ぎへの協力を確認する
• 引き継ぐものを一覧にし、特にサーバー・ドメインの名義を把握する
• 新しい会社の調査・見積もり → 並行期間 → 権限の移し替え → 契約終了の順で進める
• 今の開発会社には早めに、理由を簡潔に伝え、引き継ぎ作業は費用も含めて相談する

まずは契約書を探し出し、棚卸し表の「名義」の欄を埋めるところから始めてみてください。切り替えを最終的に決めなくても、自社のシステムの持ち物を把握しておくこと自体が、将来のトラブルへの備えになります。

あわせて読みたい関連記事