システムの引継ぎでは、ファイルを受け取るだけでなく、「どの資産を」「誰から誰へ」「いつまでに」「どの状態で渡すか」を決める必要があります。ソースコードを受領しても、本番の最新版か分からない、サーバーへ入れない、外部サービスの契約名義を変更できない状態では、保守を開始できません。
引継ぎの抜け漏れを防ぐには、確認項目を契約終了直前にまとめるのではなく、契約解除前、資産受領中、動作確認中、完了判定の時点に分けます。未完了の項目は、担当者、期限、代替策、業務への影響を記録します。
本記事では、稼働中の業務システム・Webシステムを別会社へ移管する際の一般的なチェック項目を、実務の順番で整理します。すべての項目が必要とは限りません。対象システム、契約、インフラ、外部サービスに合わせて調整してください。
1. システム引継ぎは4つの時点で確認する
引継ぎ作業は、次の4段階に分けると進捗を判断しやすくなります。
- 契約解除前：契約条件、権利、引渡し範囲、移管先の受入条件を確認する
- 資産受領中：ソースコード、DB、サーバー、アカウント、資料を安全に受け取る
- 動作確認中：受領資産で現行動作を説明・再現できるか確認する
- 完了判定：未解決事項と責任分界を合意し、保守窓口を切り替える
旧会社との契約終了日だけを完了日にしないことが重要です。新しい会社が資産を受け取っても、内容を確認できていなければ、障害や改修へ対応できる状態とはいえません。
チェックリストには「受領済み」だけでなく、「内容確認済み」「不足あり」「対象外」「確認担当」「期限」を設けます。これにより、形式的にファイルを受け取った状態と、実際に使える状態を分けられます。
2. 契約解除前に確認すること
現行会社へ解約を通知する前に、契約と移管条件を確認します。解約後は担当者の確保や追加説明が難しくなる場合があるためです。
契約と権利
- 契約期間、自動更新、解約通知期限
- 保守対象と対象外作業
- ソースコード、設計書、データの提供条件
- 著作権、利用権、改変権の範囲
- 第三者ライブラリ、フォント、画像等の利用条件
- 契約終了時の引継ぎ支援と追加費用
- 秘密保持と移管先への情報開示条件
- 現行会社が保有するデータの返却・削除方法
個別契約の法的判断が必要な場合は、自社の法務担当者や専門家へ確認します。技術的に移管できても、利用権や契約名義の問題で継続利用できないことがあります。
引継ぎ範囲と日程
対象システム、関連サイト、バッチ、外部連携、サーバー、監視、問い合わせ窓口を一覧にします。旧会社が説明する範囲、新会社が調査する範囲、自社が用意する情報を分けます。
契約終了日から逆算し、資産一覧の確認、受領、質疑、動作確認、未解決事項の合意に必要な期間を確保します。現行会社との打合せ回数や質問期限も決めておくと、最後に確認が集中するのを避けられます。
保守会社を変更すべきか、新しい会社をどう選ぶかを検討している段階では、システム保守会社を変更する際の判断・事前確認も参照してください。
3. 受領するシステム資産
資産は「存在するか」だけでなく、「本番で使われている最新版か」「自社または新会社が利用できるか」を確認します。
アプリケーションとデータ
- 本番稼働中のソースコードとリポジトリ履歴
- リリース済みプログラム、ビルド成果物
- DB本体、定義、文字コード、バックアップ
- アップロードファイル、画像、帳票テンプレート
- 設定ファイル、環境変数、定期処理
- ビルド、デプロイ、ロールバックの手順
- テストコード、テスト仕様、検証用データ
ソースコードは受領日とコミット、リリース中のバージョンを対応させます。DBバックアップはファイルの存在だけでなく、取得日時、対象、暗号化、復元方法を確認します。
インフラと外部サービス
- サーバー、クラウド、ネットワーク構成
- OS、Webサーバー、DB、ミドルウェア
- ドメイン、DNS、SSL証明書、メール
- 監視、ログ、バックアップ、ストレージ
- 外部API、SaaS、決済、地図、認証、通知
- ライセンス、契約プラン、利用上限、請求先
アプリケーションだけを引き継いでも、DNSや証明書、外部APIを管理できなければ運用に支障が出ます。契約者が現行会社の場合は、名義変更、新規契約、設定移行のどれが必要かをサービスごとに決めます。
受領資産は一つの台帳で管理します。項目名、保管場所、管理者、受領日、確認者、本番との一致、利用期限を記録し、パスワードや秘密鍵の値そのものは台帳へ平文で残しません。ファイル名だけでは内容を判別できない場合は、旧会社へ確認できるうちに用途と対象環境を明記します。
運用・業務情報
- システムの利用目的と重要業務
- 利用部門、利用者、利用時間帯
- 日次・月次・年次の定期作業
- 問い合わせ、障害、変更依頼の受付方法
- 障害履歴、改修履歴、既知の不具合
- 手作業で補っている例外処理
- 停止時の代替手順と連絡先
設計書に記載されていない運用は、利用部門や管理者へのヒアリングで確認します。特に月末や年度末だけ実施する処理は、短い引継ぎ期間では見落としやすい項目です。
4. アカウントと権限を移管する
パスワードの一覧をメールで渡すだけでは、安全な引継ぎになりません。サービスごとに管理者、契約名義、現在の利用者、二要素認証の受取先を確認します。
- 自社名義の管理者アカウントを確保する
- 新会社には必要最小限の個別アカウントを発行する
- 共有アカウントの使い回しを避ける
- 秘密鍵やパスワードは安全な方法で共有する
- 退職者・旧会社の権限を停止する時期を決める
- 権限変更前後の作業ログを残す
- 緊急時の管理者と復旧手段を確認する
旧会社の権限を先に削除すると、説明や最終確認ができなくなる場合があります。新会社の接続確認と必要資産の受領後に、責任者の承認を得て停止します。
5. 役割と責任分界を決める
移管期間中は、障害対応、データ変更、リリース、問い合わせの担当が曖昧になりやすい時期です。旧会社、新会社、自社担当の役割を作業単位で決めます。
- 本番環境を変更できる担当者
- 障害の一次受付と連絡先
- 調査、復旧、利用部門への連絡担当
- データ抽出・受渡しの実施者と確認者
- 移管中の改修を受け付けるか
- 緊急変更の承認者
- 旧会社と新会社の並行対応期間
- 未解決事項を誰が引き取るか
「保守全般」のような表現だけでなく、アプリケーション、インフラ、外部サービス、利用者対応に分けます。対象外作業や別契約となる条件も、保守開始前に共有します。
6. 受領後の動作確認とテスト
新会社は、受領資産を読み取れるか、接続できるか、主要な動作を説明できるかを確認します。本番へ変更を加える前に、可能であれば検証環境または読み取り権限で調査します。
最低限確認する内容
- リポジトリへアクセスし、対象バージョンを取得できる
- 設定と依存関係を確認できる
- DBへ必要な権限で接続できる
- ログと監視結果を確認できる
- バックアップの取得状況と復元手順を確認できる
- 主要画面と重要な定期処理を確認できる
- 外部API・SaaSの接続先と失敗時の扱いを確認できる
- リリース・切り戻し方法を説明できる
すべての機能を短期間で再テストできない場合は、事業影響の大きい業務、利用頻度の高い機能、障害履歴のある処理から優先します。正常動作の基準がない場合は、現在の結果、利用部門の確認、既知の不具合を分けて記録します。
テスト結果は合格・不合格だけでなく、実施した環境、入力条件、確認者、未確認範囲を残します。たとえば画面から登録できても、夜間バッチや外部サービスへの送信までは確認できていないことがあります。「主要画面を確認した」ことをシステム全体の受入完了と扱わないようにします。
7. 並行運用と切替時の確認
旧会社と新会社が並行して対応する期間を設ける場合は、同じ障害へ二重に対応したり、互いに設定を変更したりしないよう窓口を一本化します。
- 問い合わせ先と切替日時を利用部門へ案内したか
- 移管期間中の変更を共有する場所があるか
- 本番変更の承認手順が一本化されているか
- 監視通知が新しい担当へ届くか
- 夜間・休日を含む緊急連絡先が有効か
- 旧会社が保持するデータと権限の削除日を決めたか
- 切替後に問題が出た場合の連絡・復旧方法があるか
並行運用の目的は、責任を二重にすることではなく、説明と確認の空白を減らすことです。誰が最終判断を行うかを必ず決めます。
8. 引継ぎ完了を判断する
契約終了日やファイル受領日だけで完了とせず、受入条件を満たしたかで判断します。
- 対象資産の受領と内容確認が完了している
- 必要なアカウント・権限を確保している
- 主要機能、ログ、バックアップ、外部連携を確認している
- 問い合わせ・障害・変更の窓口が切り替わっている
- 対象外、未解決、追加調査が記録されている
- 旧会社の権限停止とデータ削除の予定が決まっている
- 自社、新会社、必要に応じて旧会社が完了条件を共有している
不足項目をゼロにできない場合は、未完了のまま放置せず、影響、暫定対応、担当者、期限を記録します。新会社が対応できない領域があれば、別事業者との分担や刷新も検討します。
完了時には、資産台帳、権限一覧、未解決事項、問い合わせ窓口を関係者が参照できる場所へ保存します。担当者だけが把握している状態に戻さないため、今後の改修や障害対応で更新する責任者も決めます。引継ぎ後に見つかった不足は、誰がどの契約範囲で調査するかを明確にしておきます。
9. 相談前に用意する情報
引継ぎ計画を相談する際は、次を分かる範囲で整理します。
- システムの用途と停止時の業務影響
- 現行契約の終了希望時期
- 旧会社から受け取れる資産と説明範囲
- ソースコード、DB、サーバー、資料、アカウントの有無
- 利用部門、主要機能、外部連携
- 現在の障害、改修予定、期限
- 新会社へ依頼したい保守・改修範囲
すべてが揃っていなくても、不明な項目を明示すれば、追加調査と現行会社へ確認すべき事項を切り分けやすくなります。契約解除前に受入条件と日程を確認し、移管中の対応空白を避けてください。
