システム開発会社を変更する前に：引き継ぎの確認事項とチェックリスト

開発会社や保守会社を変えるかどうかは、不満の大きさではなく、変えたい理由、引き継ぐ範囲、受け手が運用できる条件を確かめてから判断します。まず、問い合わせへの対応の遅さ、保守の範囲、品質、費用、担当者の不在など、困っていることを日付や件数などの事実で記録します。発注側で仕様の決め方、優先順位、承認が整理されていないことが原因の場合もあるため、相手の会社に原因があると決めつけず、改善を依頼した内容と結果も残します。

選択肢は、会社を変えることだけではありません。次の3つを比べます。

表は横にスクロールできます →

保守先だけを変える場合も、引き継ぐ資料・権限・運用の手順がそろっていなければ、新しい会社は安全に保守を始められません。一方で、会社を変えるだけなら、クラウドの移行やDNSの変更、全面的な改修が常に必要になるわけではありません。改修や刷新を伴う場合の移行方式やデータ移行の確認は、レガシーシステム移行の進め方で扱っています。

今の会社との契約を終える前に、契約の期限と、引き継ぎに必要な協力・納品物・利用条件を確認します。契約の終了や更新の申し出に期限があると、確認の時間が足りなくなります。次の点を、基本契約、個別の契約、注文書、保守の契約などで確かめます。

• 期間と終了の条件：契約期間、更新、終了を申し出る期限。対応中の不具合や、未精算の費用の扱い。
• 引継ぎ協力の範囲と費用：資料の説明、質疑応答、移管の作業を、どの範囲・期間・費用で行うか。通常の保守に含まれるか、別の契約か。
• 納品物と形式：ソースコード、設計書、設定、手順書などのうち、何がどの形式で納品物とされているか。
• 利用・改変・第三者への共有：受け取ったソースコードや資料を、自社で使う、改変する、新しい会社へ渡すときの条件。
• 第三者製品・オープンソース：ライセンスの契約主体、利用の範囲、保守の期限。
• 資料・データの返還と削除：自社が提供した資料やデータを、どう返還・保管・削除するか。

ソースコードを受け取れること、著作権が誰にあるか、利用や改変の条件、実際に保守できる状態は、それぞれ別に確認します。IPAのモデル契約では、納入物の著作権について、受託した会社に残す案、委託料の完済で委託者へ移す案、共有とする案などが示されており、運用準備・移行の支援も別の個別契約として定める形になっています（IPA：情報システム・モデル取引・契約書）。代金を支払った、ソースコードを受け取った、というだけで、権利や保守できる状態がそろうとは限りません。今の会社が無償で引き継ぎに協力するとも限らないため、範囲と費用を確認します。

今の会社へは、たとえば次のように尋ねます。

1. 本番で動いている版のソースコード、設定、設計書は、どこに、どの形式でありますか。
2. それらを自社で利用・改変し、新しい会社へ共有する条件は、契約でどう定められていますか。
3. 引き継ぎの説明や質疑応答には、どの範囲・期間・費用で協力いただけますか。

ソースコードが手元にない場合も、すぐに「変更できない」「作り直すしかない」と結論を出さず、入手できる可能性と利用の条件から確かめます。契約の解釈や紛争への対応が必要な場合は、契約の担当者や弁護士などの専門家に相談します。

引き継ぎでは、資料やソースコードを受け取るだけでなく、受け手が本番の状態を再現でき、どの処理が誰の権限で動いているかを説明できることを確かめます。デジタル庁の標準ガイドラインも、政府の情報システム向けのルールとして、設計書に加えて作業の経緯や残っている課題の引き継ぎを求めています（デジタル庁：DS-100、本文p.74・p.87）。一般の企業が同じルールに従う義務はありませんが、何を引き継ぐかを考える参考になります。

次の表は、引き継ぐ対象と確認の方法を整理した例です。担当は役割の例で、自社の体制に合わせて決めます。

表は横にスクロールできます →

実際に使う管理表には、対象の環境、保管場所と版、確認日、状態、次の確認、担当と期限の欄を加えます。パスワードやAPIキーなどの値は管理表に書かず、受け手へ渡す方法、保管の責任者、見直す予定を記録します。この表は公式のチェック表や認定の基準ではないため、対象のシステムに合わせて行を足し引きします。

ソースコード一式や、管理画面のアカウントを受け取っただけでは、引き継ぎは完了しません。たとえばGitHubでは、リポジトリを移管しても、既存の協力者や、Webhook、シークレット、デプロイキーが残る場合があります（GitHub Docs：Transferring a repository）。他のサービスでも、接続の設定、権限、課金の契約を一つずつ確かめます。社内の担当者が退職するときの引き継ぎは、情シス担当者の退職時の確認リストで扱っています。

引き継ぎは、自社・今の会社・新しい会社の役割を決め、資料の受け渡しから受け手の確認、権限の整理までを段階的に進めます。

1. 自社の対象と判断者を決める：判断する人、業務の責任者、引き継ぐ対象と目標の時期を決めます。
2. 契約と共有の条件を確かめる：「契約終了前に確認すること」の節で挙げた条件を確認し、資料と、必要な範囲に絞った権限、引き継ぎの協力と費用を調整します。
3. 不足を調べ、受入の条件を合意する：新旧の会社と一緒に、不足している資料や権限を洗い出し、受け入れで確かめる項目、担当、予定を合意します。
4. 試験環境で確かめる：合意した試験環境と確認用のデータで、再現、操作、連携、運用を確かめます。試験でメールや決済などが外部へ送られたり、本番のデータが変わったりしない条件も決めます。
5. 分担を記録し、完了と権限の整理へ進む：引き継ぎ中の窓口、作業の範囲、停止や延期の判断、未解決の事項を記録します。完了を確かめた後に、不要になった権限や接続の設定の整理と、契約の終了へ進みます。

引き継ぎの期間中は、問い合わせや障害の連絡を受ける窓口と、本番を変更できる会社を決めます。新旧の会社が同時に本番を変更すると、どちらの変更が原因か分からなくなります。契約の終了日が来た、資料が届いたというだけで完了にはしません。IPAの非機能要求グレードでも、移行の作業分担を決め、最終的な移行の結果は利用者側が確認するとされています（IPA：非機能要求グレード2018、付録D.5.1.1）。

今の会社に与えていた権限の終了は、依存している自動の処理と、代わりの権限を確かめてから段階的に進めます。人のアカウントを止めるために、処理やデータまで計画なく削除しないようにします。不正なアクセスが疑われる場合の緊急の対応は、この手順とは別に行います。今の会社の協力が得られない場合は、入手できた資料と自社が持つ権限の範囲で調べ、今の契約を当面続ける、変更を延期する、別の方式を検討する、などを判断します。権限のないシステムやデータにアクセスして情報を取り出すことは避けます。

引き継ぎの費用と期間は、システムの規模だけでは決まりません。調べる範囲、今の会社の協力、受け手が再現・確認する範囲によって変わります。見積もりを比べる前に、次の作業が含まれているかを確かめます。

• 現状の調査：資料・ソースコード・環境を調べ、不足を整理する作業。
• 今の会社の協力：説明、質疑応答、資料の作成や移管の作業。
• 環境の準備と再現：試験環境の用意、ビルドや起動の再現。
• 移管と権限の整理：契約や管理権限の移管、接続の設定の見直し。
• 受入と補修：受け入れの確認と、見つかった問題の修正。
• 継続の保守と契約の重なり：引き継ぎ後の保守の費用と、必要に応じて新旧の契約が重なる期間の費用。

今の月額の保守費だけから、移管の費用を推し量ることはできません。調査が必要な場合は、調査で作るもの（成果物）、対象外にすること、調査の後で追加になる条件を先に決めると、次の見積もりを比べやすくなります。協力の費用など、金額が分からない項目は0円とせず、確認できた小計とは別に管理します。見積もりの比べ方は、システムの見積もり・ベンダー提案の比較方法で扱っています。

引き継ぎの完了は、資料を受け取った日ではなく、新しい担当者が合意した範囲を運用できることを確かめて判断します。確かめる内容は、対象のシステムと業務に合わせて合意します。

表は横にスクロールできます →

確認の結果を記録することと、契約上の検収や業務での利用開始を決めることは分けて扱います。重大な未確認の事項が残る場合は、追加の調査、引き継ぎの延期、今の会社との契約の延長などを判断し、その理由を残します。すべてのシステムに共通の合格基準はないため、承認者が何を確かめて判断したかを記録します。バックアップからの復元の確かめ方は、バックアップ復元テストの進め方で扱っています。

仕様書が足りない場合は、作り直しを決める前に、今のシステムの動きを調べることから始めます。画面と入出力、設定、許可された範囲のログ、利用者の説明、ソースコードなどを突き合わせ、今の動きと、本来あるべき仕様を分けて記録します。IPAも、システムの再構築では現行システムの調査が必要で、専門の技術と費用・時間がかかると説明しています（IPA：モデル取引・契約書の見直しのポイント）。会社を変えるたびに再構築が必要になるわけではありませんが、調査の範囲と費用を先に決める考え方は同じです。利用の権限がない環境を調べることは避けます。

次の表は、受注管理のWebシステムを使い続け、保守先だけを変える場合を想定した記入例です。ソースコード一式は受け取ったものの、3つの点が未確認という状態です。

表は横にスクロールできます →

この時点では、どの行も完了にしません。未確認の事項ごとに担当と回答の期限を決め、そろった結果をもとに、新しい会社との受入の条件を合意します。

社内や外部に相談する前に、分かる範囲で次の点をまとめておくと、現状の整理と次の確認を進めやすくなります。資料がそろっていなくても、今分かっていることから相談できます。パスワードや契約書の本文を相談フォームに書く必要はありません。

• システムの用途と、利用している部署
• 変更を考える理由と、いつまでに決めたいか
• 契約・資料・管理権限について、把握できていることと未確認のこと