システム開発会社と連絡が取れないときは？保守引き継ぎとデータ確保の進め方

システム開発会社と連絡が取れないときは、業務を続けられる状態を確認し、データと正当な管理権限を保全することから始めます。連絡不通だけで契約終了やデータ消失が確定するわけではありません。一方、受注・請求・予約などが止まっている場合は、会社選びと並行して、社内の業務担当者・契約担当者・技術担当者が影響を整理する必要があります。

対象は、すでに稼働している業務システムです。現会社とは連絡でき、対応速度や保守費を理由に変更を検討している場合は、緊急復旧ではなく、契約・引き継ぎ条件と選択肢の比較から進められます。

最初に確認するのは「止まっている業務」と期限

管理画面が開くかだけではなく、登録・承認・出力まで実際に必要な業務が進んでいるかを確認します。二重請求や二重通知につながる操作は、確かめるために繰り返さないでください。最後に正常だった時刻と、いま確認できる事実を分けて記録します。

現在の状態	優先して整理すること
業務が止まっている	止まった処理、影響する取引・利用者、最後の正常時刻、実行済みか不明な操作。代替受付と復旧判断の担当者を決める。
画面は使えるが一部が不明	定期処理、通知、請求連携、バックアップの実行結果。見えない部分も正常とは決めつけない。
動いているが期限が迫る	サーバー・SaaS・ライセンス等の支払先、更新日、契約者、公式窓口。停止予告の有無を確認する。

例えば予約の受付を紙へ切り替える場合は、受付番号、日時、担当者を残し、復旧後にどちらを正しい記録として取り込むかを決めます。システムが裏側で処理を続けている可能性があるため、代替運用と本番処理の重複を防ぐ必要があります。

連絡経路と契約名義をたどり、権限を確認する

担当者個人への連絡だけで終えず、契約書・請求書にある法人窓口、保守窓口、これまでの連絡記録を確認します。送信した日時と返答の有無を残してください。サーバーやSaaSが別事業者なら、その契約者と正式な問い合わせ経路も調べます。

自社名義でない契約を、ログインできるという理由だけで変更・解約してはいけません。管理画面の権限、クラウドの契約者権限、プログラムやデータを他社へ渡す権限は別です。締結済み契約と利用規約から確認し、争いがある権利関係や解除の判断は契約担当者・専門家へ相談します。

引き継ぎ先の調査では、まず必要な範囲の閲覧権限などを検討します。AWSのバックアップ向けアクセス制御の説明も、業務に必要な権限だけを与える考え方を示しています。共通の管理者パスワードを配るのではなく、誰に何を許可したか追跡できる方法を選びます。

データ確保は「ダウンロードできた」で終わらせない

確認や取得は、権限のある担当者が、稼働への影響を把握して行います。受注一覧のCSVを保存できても、明細・添付ファイル・履歴・設定まで戻せるとは限りません。CSVは業務の代替や照合に使う資料であり、それだけでシステム全体のバックアップになるわけではありません。

確保・確認する対象	確認したい内容
業務データ	受注と明細、顧客、請求、予約、添付ファイル等の所在、対象期間、件数、取得時点。関連するデータ同士の対応。
動かすための資産	ソースコード、設定、依存ソフト、データベース定義、構築・更新手順。第三者製品の利用条件。
バックアップ	保存先、取得日時、対象、保持期限、取得結果、復元先。暗号化されている場合は復号に必要な権限・鍵の管理者。
処理の記録	操作ログ、エラー、定期処理の結果、外部連携の送受信結果。取得者と取得日時も残す。

本番の古いバックアップへの上書き復元、不要と判断したログの削除、原因不明の再起動は、状況を悪化させる可能性があります。データを保全する前に、再インストールや一括更新を行わないでください。復旧の担当者と方針を決めるまでは、取り出せた資料と現状を保全します。調査用のコピーにも個人情報が含まれるため、保存先と閲覧者を限定してください。

仕様書がなくても、業務の流れから不明点を絞る

仕様書がないことと、調べる材料がないことは同じではありません。現場の操作、入力項目、帳票、既存の設定、承認された範囲のログから、「誰が何を入力すると、どこへ反映されるか」を整理します。ただし、画面で見える動作だけを全仕様だとは扱わないでください。

AWSのアプリケーション調査ガイドは、構成に加え、データの流れ、定期処理、外部サービスへの依存、運用の周期を確認対象にしています。本記事ではその観点を引き継ぎ時の整理に応用しています。次の月次処理が未確認なら、今日動いたという確認だけで移管完了にはしません。

IPAの再構築に関する説明でも、現行仕様を明らかにするための調査が必要とされています。不明点は無理に埋めず、調査できた範囲と、元会社への確認が必要な範囲を分けます。

復元と再開は、本番への副作用を防いで確認する

バックアップがあっても、実際に戻すための権限や設定が欠けていることがあります。AWSの復元試験の指針は、復元可能性を定期的に確かめることを求めています。引き継ぎでも、技術担当者が管理する本番から切り離した環境での確認を検討します。

復元先からメール、決済、会計連携、請求書発行などが実行されないよう、通信先・定期処理・待機中のジョブを確認します。データが読めること、必要な権限で操作できること、帳票や件数が想定と合うことを順に確かめます。いきなり本番へ戻して試してはいけません。

再開する際は、どの時点のデータを使うか、その後に発生した取引をどう照合するか、途中まで実行された処理を再実行してよいかを決めます。許容できる停止時間と、どこまでのデータを失わずに戻したいかは、業務側が判断する条件です。

引き継げる範囲を調べてから、再構築の要否を決める

個別開発のシステムは、プログラム・データ・環境・権利条件が揃えば、他社が保守を引き継げる可能性があります。資料不足、対応できる技術者の不在、第三者製品の制限などで、一部だけの継続や置換が必要になる場合もあります。

SaaSでは、支援会社が不通でも提供事業者のサービスは動いている場合があります。公式窓口で管理者や契約の扱いを確認し、支援会社の変更とサービス乗換えを分けます。パッケージでは、製品の保守と独自改修部分の担当を区別します。IPAの契約資料も取引形態を分けているため、自社の契約がどれに近いかを確認する入口になります。

調査を依頼する際に確認したい項目

緊急時でも、変更してよい対象を明確にします。次の項目は、調査を依頼するときの確認例です。実際の調査範囲と報告内容・費用は、着手前に依頼先と確認してください。

• 止まっている業務と、現在動いていると確認できた範囲。
• データ・プログラム・権限の所在と、取得・確認できなかったもの。
• 継続利用、保守引き継ぎ、一部置換、再構築それぞれの条件。
• 復元・移行で確かめる項目、元会社や提供事業者への追加確認、次の判断に必要な調査。

相談では、困っている業務と情報の所在を伝える

ENOLは、業務システム開発と既存システムからの乗り換えを案内しています。画面・データ・帳票・運用ルールを確認し、必要な移行を検討する進め方です。連絡不通のシステムについても、まず対象業務と手元の資料から相談できます。個別環境の引き継ぎ可否や復旧方法は、実際の情報を確認して判断します。

今のシステムを引き継げるか相談するには、止まっている業務、最後に正常だった時刻、開発会社への連絡状況、契約・管理権限・バックアップの所在を記載してください。パスワード、秘密鍵、顧客名簿、本番データは貼り付けず、必要な共有方法を別途確認します。企業サイトやドメイン中心の問題は、ホームページの引き継ぎガイドを参照してください。