買収前のIT調査。「バックアップあり」を、業務が戻る証拠に変える

導入：一覧の丸印では、再開できるか分からない

買収候補の会社についてITの資料を読むとき、「バックアップは毎日取得しています」という回答を見ることがあります。取得の有無は大切ですが、それだけで受注や出荷を再開できるとは限りません。必要なファイルが対象から漏れている、復元するソフトの契約が切れている、復旧できる担当者が引継ぎ後には不在になる。こうした条件は、設備一覧や費用明細を眺めるだけでは見落とされます。

この記事では、買収前のデューデリジェンスで確認したい「復旧できることの証拠」を扱います。システムをどの製品へ統合するかではなく、現在の事業を支える情報が失われたとき、どの条件で仕事を戻せるのかという問いです。経営者、案件責任者、情報システム担当者が同じ論点を話せるよう、資料確認から限定的な試験、未確認事項の引継ぎまでを整理します。

公式資料の紹介と、編集部による実務上の提案を分けています。以下の手順や仮例は、法令上の一律の義務、調査の完全性、事故が起きないことを保証するものではありません。調査対象の権限者、法務担当、情報セキュリティの専門家と範囲を合意して使ってください。相手のシステムへ無断で接続したり、本番データを持ち出したりするための案内ではありません。

公式資料が示す範囲を先に押さえる

IPAの「中小企業の情報セキュリティ対策ガイドライン」は、経営者向けの指針と、対策を実践する手順・手法をまとめた資料です。公開ページでは第4.0版が案内され、基本的な対策にバックアップの取得が追加されたことを確認できます。今回の確認日は2026年11月10日です。確認日と資料の改訂日は同じではありません。[1]

同ガイドラインの本編は、取得と保管だけでなく、復旧計画を立て、正しく復旧できることを確認する観点を示しています。また、事業継続の要件に沿った目標復旧時間・目標復旧時点に合わせた準備と、訓練による実効性の検証を扱っています。一方、工場設備や制御システム等は対象外と明記されています。生産機械の制御まで同じ資料で確認済みにしてはいけません。[2]

中小企業庁のPMI案内では、買収目的や現状を踏まえた優先課題の整理、取組の担当と日程の管理に使うツールが公開されています。編集部は、この整理方法を、買収前に見つかった復旧上の未確認事項を買収後へ引き継ぐ際にも応用できると考えます。これは公式の買収判定基準ではなく、調査と実行の間で宿題を失わないための提案です。[3]

本記事は、特定製品の性能や企業の対策状況を評価しません。バックアップという言葉が同じでも、契約、設定、運用、保持期間、復元権限が異なります。一般資料を根拠に相手企業の状態を推定せず、その会社に関する証拠を別に確認することが出発点です。

一つの重要業務から、止まる順序をたどる

最初からすべてのサーバーを並べるより、買収後も止められない業務を一つ選びます。例えば、受注を受けて出荷を指示する仕事です。誰が注文を確認し、どのデータを参照し、どのシステムへ登録し、誰の承認で倉庫へ渡すのか。現場の担当者に、通常の一件を順番に説明してもらいます。技術担当だけでなく、復旧後に仕事を引き受ける人の視点が必要です。

次に、その仕事に必要な情報を具体化します。注文データだけでよいのか、商品番号の対応表、取引条件、配送先、未処理の変更指示、出荷履歴も必要なのか。表計算ファイルやメールに残った情報が実際の作業を支えていることもあります。ただし、その可能性を理由にメールや共有フォルダーを丸ごと取得しません。説明と目録から必要性を確かめ、閲覧する範囲を絞ります。

業務の順序が分かると、依存関係も確認できます。アプリが立ち上がっても、認証、ネットワーク、外部サービス、帳票、印刷などのどれかが使えなければ、業務を完了できないかもしれません。「データを戻す」作業と「仕事を再開する」条件を同じ欄に押し込まず、技術的な復元条件と業務側の確認条件を分けます。

そのうえで、通常期と繁忙期の違いを聞きます。週末に止まる場合と締日の直前に止まる場合では、影響が異なることがあります。ここで一律の許容停止時間を作る必要はありません。既に合意された契約上の条件、締切、代替手段があるかを確認し、判断の前提を記録します。未合意の目安は、経営判断が済んだ確定値として扱わないようにします。

五つの状態を区別して、証拠の強さを読む

編集部は、調査メモに「説明あり」「設定確認」「取得記録あり」「復元確認」「業務確認」の五つを区別することを提案します。これは認証制度や採点表ではありません。何を見たかを短く表すための区分です。「担当者が毎日取得と説明した」と「直近の取得記録を見た」を分けるだけでも、次に何を確かめるべきかが見えてきます。

説明は、対象や運用の全体を理解する材料になります。設定画面や手順書は、意図された対象と方法を示します。取得記録は、特定の時点に処理が動いたことを確かめる手がかりになります。しかし、記録の成功表示が、必要な情報を漏れなく含むことや、業務で使える状態に戻ることまで意味するかは別の確認です。

復元確認には、対象、実施日、用いた世代、復元先、実施者、確認方法、例外が必要です。業務確認では、復元された情報で必要な作業を完了できたかを見ます。試験用の一件が開けたことを、全データの整合や全拠点の再開まで広げません。対象外だった処理が分かる記録ほど、次の判断に使いやすくなります。

証拠の強さを単純な点数にまとめると、重要な違いが消える場合があります。古い環境での詳細な試験と、現在の環境での限定的な確認では、意味が異なります。点数よりも、現在の構成との一致、業務とのつながり、再現に必要な条件、確認できなかった範囲を短く説明する欄を設ける方が実務的です。

目標と実績を混ぜず、時間と時点を測る

目標復旧時間は、どの程度の時間で、どの業務レベルへ戻したいのかという計画上の要件です。目標復旧時点は、どの時点の情報まで戻すことを目指すのかに関わります。IPAの資料に示された用語を使う場合も、その数字が会社として承認された目標なのか、担当者の想定なのか、試験で測った結果なのかを区別します。[2]

例えば「数時間で復旧」という回答があっても、作業開始からファイルが復元された時点までなのか、障害の発見、連絡、判断、作業、業務確認までを含むのかで意味が変わります。起点と終点を決めずに時間だけ比較すると、買い手と売り手で違う状態を見ているまま合意してしまいます。

データの時点についても、最後にバックアップした時刻だけでは足りません。その後の注文、取消し、入金照合などをどう再構成するのかが残ります。復元したデータと、止まっている間に別の方法で受け付けた作業を、誰がどう照合するのか。再開後の二重処理や未処理を防ぐ確認まで含めて、業務担当と話し合います。

速さだけを優先しないことも大切です。安全性や整合性が確認できない状態で再開すれば、復旧したつもりで問題を広げるおそれがあります。停止時間を短くする目的と、再開してよい条件は分けて定義します。試験で目標を満たさなかった場合は、数字を書き換えるのではなく、原因、改善案、判断者、再確認の条件を残します。

試験前に、許可・対象・中止条件を決める

買収を検討しているというだけで、候補企業のシステムを変更する権限が生じるわけではありません。実地の復元試験に進む前に、対象、作業内容、閲覧者、使用データ、実施環境、時刻、持ち出す記録を、権限を持つ関係者と確認します。第三者サービスの利用条件や委託契約に関係する場合は、その確認も必要です。

可能であれば、まず既存の訓練記録や、担当者による画面共有で確認できる範囲を検討します。調査のために新しい接続経路や大量のデータ複製を作ると、調査そのものが追加の管理負担になります。証拠を得る方法は一つではありません。質問の重要性に応じて、必要な確認と、相手の事業への影響を比較します。

試験を行う場合も、本番と区別した安全な環境、必要最小限のデータ、関係者が合意した手順を用意します。どの時点で試験を中止するか、想定外の情報や不具合を見つけたときに誰へ連絡するかを決めます。実施者が困ったときに、本番へ勝手に切り替えたり、設定を追加変更したりしないための線引きです。

ここまでの整理が難しい場合は、業務の重要度、未確認事項、実施できる範囲をまとめ、専門家と調査計画を見直してください。「試験しなければ買えない」「試験さえすれば買える」と二択にするのではなく、証拠の不足が、判断や実行計画にどのような影響を持つかを検討します。

仮例：受注システムの復元で分かった、別の宿題

以下は考え方を説明するための架空の例です。ある小規模卸売会社では、受注システムについて毎日のバックアップがあると説明されました。調査担当は、製品名だけを確認して終了せず、受注一件を出荷指示まで進めるために必要な情報を聞き取りました。すると、商品コードの変換表は別の共有フォルダーに保存され、担当者が手作業で更新していることが分かりました。

権限者と範囲を合意したうえで、既存の訓練記録を読み、別環境での限定的な確認を行う想定にします。受注データを開くことはできましたが、変換表は訓練対象に含まれていませんでした。この場合、受注データの復元結果を否定する必要はありません。一方で「出荷業務の復旧まで確認した」ともいえません。確認した事実と、残った業務条件を分けて記録します。

次の宿題は、ただバックアップ製品を増やすこととは限りません。変換表がなぜ別に管理されているのか、更新者と確認者は誰か、バックアップ対象へ入れる必要があるか、復元した表と受注時点の関係をどう確認するかを検討します。業務上の理由を知らずにファイルを一か所へ移すと、かえって日常作業を壊す可能性があります。

買い手への説明では「バックアップに不備あり」という大きな一言で終えず、「受注データは限定的に復元確認済み、変換表と出荷指示の整合は未確認」と伝えます。解決に必要な担当、見積りが必要な作業、次の確認日を添えれば、取引上の判断をする専門家も、買収後に引き継ぐ担当者も、同じ事実から検討できます。

クラウドと委託先は、製品名の外側まで確認する

外部サービスを使っている場合、提供元がバックアップしているという説明と、自社が必要な情報を取り戻せることは同じとは限りません。契約上どの機能が利用できるか、復元の依頼窓口、対象、手順、期間、追加費用の扱いを確認します。これらはサービスごとに違うため、一般論で補わず、現行の契約や公式の案内へ戻ります。

また、利用者がファイルを元に戻せる機能と、障害時に事業全体を復旧する仕組みは区別します。履歴が残る範囲、削除後の保持条件、管理者の操作が必要な場面などを、確認できた範囲で整理します。管理画面の機能名だけを見て、設定や契約の状態まで同じだと判断しないことが重要です。

委託先が作業する場合は、連絡可能な時間、担当者不在時の対応、必要な承認、作業の前提資料を確認します。ただし、連絡先を知っていることは、緊急時の対応が契約に含まれる証拠ではありません。対応範囲と費用が未確認なら、その状態を残し、調査担当が勝手に依頼や契約変更を行わないようにします。

買収により契約名義や利用者が変わる可能性がある場合も、個別条件の確認が必要です。現在の担当者の個人アカウントだけに復元権限が依存している、ライセンスの利用主体が異なる、といった点は法務と技術の両面へ引き継ぎます。認証情報を資料へ貼り付けて共有する方法ではなく、正式な管理・引継ぎの手続きを検討します。

調査の結果を、買収判断とPMIへ渡す

復旧の調査結果は、良い会社か悪い会社かを判定するラベルではありません。確認された状態、事業への影響、必要な対応、費用や日程の不確実性を、取引全体の検討へ渡す材料です。買収価格や契約上の扱いは、この記事だけで決めるものではなく、担当の法務・会計等の専門家と検討する領域です。

編集部の提案として、一つの論点に「対象業務」「確認した証拠」「残る不確実性」「実行前の対応候補」「実行後の担当」「再確認条件」を並べます。実行前に確認するか、実行後へ残すかは、重要度、実施可能性、契約、事業影響によって異なります。調査担当が便宜的に期日を付けただけの予定と、当事者間で合意された条件を混ぜません。

買収後へ残す課題には、受け取る担当者が必要です。DD報告書の中に書いてあるだけでは、現場の作業計画へ落ちないことがあります。関連する手順書、設定の説明、試験結果の保管場所を案内し、権限を与えられた担当者が参照できるかを確かめます。資料共有では、秘密情報や個人情報へのアクセスを必要な範囲に限定します。

改善の費用を見積もる場合は、機器代だけでなく、設計、設定、訓練、業務側の確認、保守などの範囲を明確にします。見積書の版が変わったら、復旧のどの条件が変わるのかを残します。関連するFUNDNOTEの面談記録の記事は、確認の場で得た回答と自社の解釈を分け、残った宿題を担当と期限へつなぐ方法を考える際の補助になります。特定の融資や設備購入を勧める趣旨ではありません。

よくある判断の飛躍を避ける

「事故がなかったから大丈夫」という説明は、過去の経験としては重要ですが、現在の復旧能力の確認とは別です。「有名な製品を導入している」「外部へ委託している」「取得処理が成功している」といった情報も、確認の入口にはなりますが、業務を再開できる証拠を置き換えるものではありません。

逆に、古い資料や一度の試験失敗を見て、改善不能と決め付けることも避けます。失敗が示したのは、特定の条件で何ができなかったかです。前提を整理し、再確認できる部分と、取引の判断時点までに確認できない部分を分けます。原因を調べずに試験だけを繰り返すと、負担を増やしても意思決定に必要な情報は増えません。

買い手側の基準をそのまま押し付けることも注意点です。規模、業務、契約、設備が違えば、必要な対策や現実的な実施方法も違います。共通化したい理由を説明し、現在の運用が守っている条件を理解してから比較します。復旧の改善と、グループ共通システムへの移行は、関連していても別の判断として扱えます。

試験記録に未確認欄が残ることは、調査が無意味ということではありません。重要なのは、不明点を見えるようにし、そのまま進める場合の影響を判断できることです。「問題なし」にまとめてしまうより、確認範囲と限界を具体的に残す方が、次の担当者にとって役立ちます。

報告書を受け取る側も、結論の条件を読む

買い手の経営会議で報告を受ける場合は、技術用語を理解することだけを目標にしないようにします。どの業務が、どの条件で、どこまで再開できると確認されたのか。担当者にこの三点を説明してもらえば、追加の調査を依頼する目的が明確になります。確認の不足と、経営として引き受けると決めたリスクを混同しないことが重要です。

報告の対象日から買収の実行日までに、機器、外部サービス、担当者、データ量が変わる場合もあります。調査時点で有効だった確認を、そのまま実行時点の保証として扱わず、何が変わったら再確認するかを決めます。すべてを最初から調べ直すのではなく、変更によって影響を受ける復旧条件へ戻る考え方です。

例えば、以前の試験では外部委託先の担当者が復元したものの、その委託契約が実行後も続くか未確定だったとします。技術的な復元結果は記録として残りますが、実行後に同じ手順を使えるかは別の宿題です。契約の確認、引継ぎの範囲、代替担当の育成など、関係者が判断する事項を分けて並べます。契約や権限の変更を、調査担当が独断で先に進めないようにしてください。

報告書の版を更新するときには、前回から追加された証拠、変わった前提、取り下げた判断が分かるようにします。最新の結論だけを上書きすると、過去の会議で何を前提に判断したかが分からなくなることがあります。保存すべき記録の範囲は案件の方針に沿って定め、必要な人が最新版へたどれる状態と、過去の判断を追える状態を両立させます。

記録を残すときは、再確認できる粒度にする

調査メモには、資料を受領した日と、その資料が表している運用の時点を分けて書きます。昨日受け取った手順書でも、内容はシステム更新前のものかもしれません。作成日だけでなく、現在の構成と照合した人、照合できた範囲を残します。古いから無効、新しいから正確と機械的に扱うのではなく、今回の問いに答えられる情報かを確認します。

試験結果の記録には、単なる成功・失敗に加えて、準備に必要だった作業、途中で受けた支援、予定外に使った資料、手作業で補った処理を含めます。特定の担当者の記憶で補えた部分を、通常の手順で再現できた部分と区別すると、引継ぎや教育で優先すべき点が分かります。担当者の能力を評価するためではなく、仕組みとして再現できる条件を整理するためです。

画面の画像を保存する場合は、何の証拠として必要かを先に考えます。個人情報や顧客情報が映る画面をそのまま報告書へ貼らず、必要な項目だけを確認できる方法を検討します。結果の記録に必要な範囲と、実データの内容を大量に保存することは別です。保存先、閲覧者、保管期間も案件の情報管理方針に合わせます。

最後に、記録を読んだ別の担当者が「次に何を確認すればよいか」を説明できるかを点検します。元の担当者へすべて聞き直さなければ進められないなら、結論に至った条件が不足している可能性があります。反対に、膨大な操作ログを添付して重要点が分からなくなる場合は、本文には判断に必要な要約を置き、根拠の保管場所へたどれるようにします。

次の打合せで確認すること

最初の打合せでは、重要業務を一つ選び、その業務に必要な情報と依存する仕組みを聞きます。次に、バックアップの対象、直近の取得記録、復元確認の実施日、業務側が確認した範囲を並べます。すべての資料を求める前に、何を判断するために必要なのかを一つずつ説明できる状態にします。

実地確認が必要なら、実施権限、対象、環境、取扱うデータ、中止条件、結果の共有先を合意します。試験後は、目標と実績、技術的復元と業務の再開、確認済みと未確認を分けて記録します。改善に進む場合も、実施した事実と、有効性を再確認した事実を区別してください。

M&Aで引き継ぐのは、システムの一覧だけではありません。仕事が止まったときに、必要な情報を使える形へ戻し、役割を持つ人が判断できる状態も、事業を続けるための重要な条件です。「バックアップあり」という一行を否定するのではなく、その一行が何を意味し、何をまだ意味しないのかを確かめる。そこから、実行可能な引継ぎの準備を始められます。