Column
コラム
ITデューデリジェンスとは?調...
デューデリジェンス
ITデューデリジェンスとは?調査項目・進め方・M&Aで確認すべきリスクを解説
M&Aでは、財務状況や契約関係だけでなく、対象会社が利用しているシステムやITインフラ、情報セキュリティ、運用体制なども確認する必要があります。
対象会社の業績が良好でも、基幹システムが老朽化していたり、特定の担当者や外部ベンダーに運用が依存していたりすると、買収後に多額の追加投資が必要になる可能性があります。
また、買い手と対象会社のシステムを統合できなければ、期待していた業務効率化やコスト削減を実現できないこともあります。
こうしたITに関するリスクや資産価値を、M&Aの実行前に調査する手続きがITデューデリジェンスです。
この記事では、ITデューデリジェンスの目的、主な調査項目、進め方、必要資料、調査結果をM&Aの条件に反映する方法について解説します。
法人向けの各種調査・探偵のご相談・ご依頼はこちら
- ITデューデリジェンスとは
- ITデューデリジェンスの目的
- システム監査との違い
- M&Aのどの段階で実施するのか
- M&AでITデューデリジェンスが必要な理由
- 買収後の想定外のIT投資を防ぐため
- 情報漏洩やシステム障害のリスクを把握するため
- 買い手と対象会社のシステムを統合できるか確認するため
- IT資産やデジタル面の強みを評価するため
- ITデューデリジェンスで確認する主な項目
- IT戦略・投資計画
- システム・アプリケーション
- サーバー・ネットワークなどのITインフラ
- IT組織・人員・外部委託体制
- ITコスト・将来の追加投資
- 情報セキュリティ・個人情報管理
- データ管理・バックアップ・BCP
- ベンダー契約・ソフトウェアライセンス
- 進行中のシステム開発プロジェクト
- 買収後のシステム統合・切り離しの可能性
- 買収後に発覚しやすいITリスク
- ITデューデリジェンスの進め方
- 1.調査目的と範囲を決める
- 2.調査チームを編成する
- 3.必要資料の開示を依頼する
- 4.資料を分析して課題を整理する
- 5.経営者やIT担当者へインタビューする
- 6.リスクと対応費用を評価する
- 7.調査結果を報告書にまとめる
- ITデューデリジェンスで確認する主な資料
- システム構成・IT資産に関する資料
- ITコスト・投資計画に関する資料
- 組織・運用体制に関する資料
- セキュリティ・障害履歴に関する資料
- 契約・ライセンスに関する資料
- ITデューデリジェンスの結果をM&Aにどう反映するか
- IT更新・統合に必要な費用を取引条件に反映する
- システムの切り離しが必要な場合はTSAを検討する
- ITに関する課題をPMI計画に反映する
- ITデューデリジェンスで特に注意すべき点
- 資料と実際の運用状況を照合する
- 費用試算の前提と不確実性を明確にする
- ITデューデリジェンスは誰に依頼する?
- 自社のIT部門だけで対応できるケース
- 外部専門家への依頼が必要なケース
- 依頼先を選ぶ際の確認ポイント
- まとめ
ITデューデリジェンスとは
ITデューデリジェンスとは、M&Aや出資を実行する前に、対象会社のITシステム、インフラ、運用体制、コスト、情報セキュリティなどを調査する手続きです。「IT DD」と略されることもあります。
関連記事:デューデリジェンスとは?M&Aで行う目的・種類・流れ・注意点を解説
対象会社が現在利用しているシステムに問題がないかを確認するだけでなく、買収後に必要となる追加投資や、買い手側のシステムとの統合可能性も評価します。
調査対象には、基幹システムや業務アプリケーションだけでなく、サーバー、ネットワーク、データ管理、IT人材、外部委託先、ソフトウェアライセンスなども含まれます。
ITデューデリジェンスの目的
ITデューデリジェンスの主な目的は、対象会社のIT環境に潜むリスクと資産価値を把握し、買収後の追加費用や事業上のトラブルを防ぐことです。
システムの老朽化、セキュリティ、運用体制、将来のIT投資、買い手側との統合可能性などを確認し、調査結果を買収価格や契約条件、PMIの計画に反映します。
システム監査との違い
システム監査は、企業の情報システムが適切に管理・運用されているかを評価する手続きです。
一方、ITデューデリジェンスでは、対象会社のシステム管理状況だけでなく、M&A後に発生する費用や統合上の課題、事業計画への影響まで確認します。
例えば、システム監査ではアクセス権限やバックアップ体制に問題がないかを調べます。ITデューデリジェンスでは、それに加えて、買収後にシステムを継続利用できるか、統合にどの程度の費用や期間が必要かまで評価します。
調査項目が一部重なることはありますが、ITデューデリジェンスはM&Aの意思決定に重点を置いている点が異なります。
M&Aのどの段階で実施するのか
ITデューデリジェンスは、一般的に基本合意の締結後から最終契約の締結前までに実施します。
買い手は、売り手から開示された資料や担当者へのインタビューをもとに、対象会社のIT環境を調査します。
調査結果は、買収価格、表明保証、補償条項、クロージング条件などの交渉材料になります。そのため、最終契約の内容を決める前に、重要なITリスクを把握しておく必要があります。
ただし、限られた期間ですべてのシステムを詳細に調査することは困難です。初期段階では重要なリスクを優先的に確認し、買収後に追加調査を行うケースもあります。
M&AでITデューデリジェンスが必要な理由
ITは、現在の企業活動を支える重要な経営基盤です。
販売、会計、在庫管理、顧客管理、製造、物流、人事などの業務がシステムに依存している企業では、ITの問題が事業継続に直接影響します。
対象会社の財務状態だけを確認しても、買収後に必要となるシステム更新費用や統合費用までは分かりません。そのため、M&AではITを独立した調査対象として確認する必要があります。
関連記事:財務デューデリジェンスとは?調査項目・進め方・費用をわかりやすく解説
買収後の想定外のIT投資を防ぐため
対象会社のシステムが古くても、現在は問題なく動作している場合があります。
しかし、OSやソフトウェアのサポートが終了していたり、交換部品を入手できなくなっていたりすると、買収後すぐにシステム更新が必要になる可能性があります。
また、対象会社がIT投資を先送りしていた場合、過去の利益は高く見えても、買収後に買い手が多額の費用を負担することになります。
ITデューデリジェンスでは、現在の運用費だけでなく、システム更新、データ移行、セキュリティ改善、人材確保、システムの統合・切り離しに必要な将来支出も見積もります。先送りされてきた投資を把握することで、買収後の負担を企業価値評価に反映できます。
情報漏洩やシステム障害のリスクを把握するため
対象会社の情報セキュリティが不十分な場合、買収後に情報漏洩やサイバー攻撃が発覚する可能性があります。
過去に不正アクセスを受けていたにもかかわらず、十分な調査や対応が行われていないケースもあります。
また、バックアップ体制や災害対策に問題があると、システム障害が発生した際に業務を復旧できないおそれがあります。
ITデューデリジェンスでは、セキュリティ規程の有無だけでなく、実際の運用状況や過去のインシデント、アクセス権限、バックアップ方法などを確認します。
買い手と対象会社のシステムを統合できるか確認するため
M&Aでは、買収後に会計、人事、販売管理、顧客管理などのシステムを統一することがあります。
しかし、買い手と対象会社で異なるシステムを利用している場合、簡単に統合できるとは限りません。
対象会社のシステムが大幅にカスタマイズされていたり、データ形式が異なっていたりすると、統合に時間と費用がかかります。
また、統合を急ぐことで、業務停止やデータ消失などの問題が発生する可能性もあります。
ITデューデリジェンスでは、システムの技術的な互換性だけでなく、業務プロセスやデータ構造も含めて統合可能性を評価します。
IT資産やデジタル面の強みを評価するため
ITデューデリジェンスは、問題を探すだけの調査ではありません。
対象会社が独自に開発したシステムやデータ、デジタルサービスが、競争力の源泉になっていることもあります。
例えば、独自の顧客データ、業界特化型の業務システム、効率的な在庫管理システムなどは、企業価値を高める要素になります。
ただし、独自システムやデータの価値を評価する際は、知的財産権の帰属、外部ベンダーとの契約、運用を担う人材の継続性も確認します。技術的な優位性があっても、買収後に自由に利用・改修できなければ、想定した価値を得られないためです。
ITデューデリジェンスで確認する主な項目
ITデューデリジェンスの調査範囲は、対象会社の業種、規模、システムへの依存度、M&Aの目的によって異なります。
一般的には、次の項目を確認します。
IT戦略・投資計画
対象会社のIT戦略が、事業計画や経営方針と整合しているかを確認します。
具体的には、IT投資計画、システム更新計画、デジタル化の方針、経営会議でのITに関する意思決定などが調査対象です。
計画上は新システムへの移行を予定していても、予算や担当者が確保されていない場合、実現可能性は低いと考えられます。
将来の事業成長に対して、現在のシステムが十分な処理能力や拡張性を持っているかも確認します。
関連記事:ビジネスデューデリジェンスとは?調査項目・進め方・分析方法を解説
システム・アプリケーション
対象会社が利用している基幹システムや業務アプリケーションの種類、役割、稼働状況を確認します。
主な確認対象は次のとおりです。
会計システム
販売管理システム
在庫・生産管理システム
顧客管理システム
人事・給与システム
グループウェア
自社開発システム
クラウドサービス
システムのバージョン、保守期限、障害履歴、カスタマイズ状況なども確認します。
特に、長年の改修によって仕様が複雑になっているシステムは、更新や統合が難しくなる可能性があります。
サーバー・ネットワークなどのITインフラ
サーバー、ネットワーク、データセンター、パソコン、モバイル端末などのITインフラを確認します。
オンプレミス環境の場合は、設備の老朽化、保守期限、予備機の有無、災害対策などが重要です。
クラウドサービスを利用している場合は、契約内容、利用料金、アカウント管理、データの保存場所などを確認します。
また、通信回線やネットワーク構成に問題があると、拠点統合や業務拡大に支障が出る可能性があります。
IT組織・人員・外部委託体制
IT部門の組織体制、人員数、担当者の経験やスキルを確認します。
特に注意が必要なのは、重要なシステムの運用や仕様を一人の担当者しか把握していないケースです。
その担当者が退職すると、障害対応やシステム改修が困難になる可能性があります。
外部ベンダーへ運用を委託している場合は、委託範囲、契約期間、費用、再委託の有無なども確認します。
特定のベンダーに過度に依存している場合、契約変更や費用削減が難しいことがあります。
ITコスト・将来の追加投資
現在のITコストが適正か、買収後にどの程度の追加投資が必要になるかを確認します。
調査対象には、次のような費用が含まれます。
システムの開発費
運用・保守費
サーバー・端末費
クラウド利用料
ソフトウェアライセンス費
外部委託費
IT部門の人件費
通信費
セキュリティ対策費
現在のコストが低くても、必要な更新や改善が先送りされている場合は注意が必要です。
また、買い手側の方針に合わせてセキュリティやシステム構成を変更する場合、その費用も見積もります。
情報セキュリティ・個人情報管理
情報セキュリティの管理体制、社内規程、システム上の対策、従業員教育などを確認します。
主な確認項目は次のとおりです。
アクセス権限の管理
パスワードや認証方法
ウイルス・不正アクセス対策
ログの保存・監視
端末や外部記録媒体の管理
個人情報の保存方法
セキュリティインシデントの履歴
外部委託先の管理
規程が整備されていても、実際の運用が伴っていないケースがあります。
例えば、退職者のアカウントが削除されていない、複数人で同じIDを利用している、管理者権限が必要以上に付与されているといった問題です。
データ管理・バックアップ・BCP
顧客情報、取引情報、会計情報などの重要なデータが、適切に管理されているかを確認します。
バックアップを取得していても、同じ建物内にしか保存していなければ、災害時に利用できない可能性があります。
また、バックアップデータから実際に復旧できるかをテストしていないケースもあります。
ITデューデリジェンスでは、バックアップの頻度、保存場所、復旧手順、復旧テストの実施状況などを確認します。
システム停止時に重要業務をどの程度の時間で再開できるかも重要です。
ベンダー契約・ソフトウェアライセンス
システムの開発・保守契約、クラウドサービス契約、ソフトウェアライセンスなどを確認します。
M&Aによって支配権が変更された場合、契約の継続に相手方の同意が必要になることがあります。
また、対象会社が利用しているソフトウェアのライセンスが、買収後もそのまま引き継げるとは限りません。
自社開発システムについても、プログラムや設計書の権利を対象会社が保有しているか確認する必要があります。
外部ベンダーが著作権を保有している場合、買収後の改修や利用に制限が生じる可能性があります。
進行中のシステム開発プロジェクト
新しいシステムの導入や既存システムの刷新など、進行中のプロジェクトがある場合は、その状況を確認します。
主な確認項目は次のとおりです。
プロジェクトの目的
予算と支出済み費用
進捗状況
稼働予定日
遅延や仕様変更の有無
ベンダーとの関係
残りの支出見込み
社内の利用準備状況
計画上は順調でも、担当者へのインタビューによって重大な遅延や品質問題が判明することがあります。
買収後にプロジェクトを継続するのか、中止するのかも含めて評価する必要があります。
買収後のシステム統合・切り離しの可能性
対象会社をグループに統合する場合は、買い手側のシステムとの親和性を確認します。
一方、事業譲渡や子会社売却では、売り手の親会社やグループ共通システムから対象事業を切り離さなければならないことがあります。
対象会社が親会社の会計、人事、メール、ネットワークなどを利用している場合、独立したシステムを新たに構築する必要があります。
切り離しが完了するまで、売り手のシステムを一時的に利用するTSAを締結するケースもあります。
統合や切り離しには時間がかかるため、必要な期間、費用、人員を買収前に見積もることが重要です。
買収後に発覚しやすいITリスク
ITデューデリジェンスが不十分だと、対象会社のIT上の問題が、買収後に追加費用や業務停止として表面化する可能性があります。
代表的なリスクは次のとおりです。
保守期限を過ぎたシステムの更新に多額の費用がかかる
設計書や仕様書がなく、システムを改修できない
特定の担当者やベンダーがいなければ運用を継続できない
親会社のシステムから切り離せず、独立運営が遅れる
過去の情報漏洩やセキュリティ上の不備が判明する
開発中のプロジェクトの遅延や追加費用を引き継ぐ
これらの問題は、対象会社のシステムが現在稼働しているだけでは判断できません。資料の確認に加え、担当者へのインタビューや契約内容の調査を行い、買収後の事業運営への影響を評価する必要があります。
ITデューデリジェンスの進め方
ITデューデリジェンスは、限られた期間で重要なリスクを把握する必要があります。
一般的には、次の流れで進めます。
1.調査目的と範囲を決める
最初に、M&Aの目的や対象会社の特徴を踏まえて、調査範囲を決めます。
例えば、システム統合によるコスト削減を目的とするM&Aでは、買い手とのシステム親和性が重要です。
IT企業の買収では、システムの技術力、開発体制、知的財産、セキュリティなどの重要性が高くなります。
すべての項目を同じ深さで調査するのではなく、取引への影響が大きい領域を優先します。
2.調査チームを編成する
調査目的に応じて、社内のIT部門、M&A担当者、外部のIT専門家などでチームを編成します。
システムの技術面だけでなく、財務、法務、事業との関係も確認する必要があります。
例えば、ITコストは財務デューデリジェンス、ライセンスやベンダー契約は法務デューデリジェンスと連携して調査します。
それぞれの調査結果を共有し、全体としてリスクを評価することが重要です。
3.必要資料の開示を依頼する
調査項目に基づいて、対象会社に資料の開示を依頼します。
システム構成図、IT資産台帳、契約書、費用明細、セキュリティ規程など、必要な資料をリスト化します。
売り手側から自発的にすべての重要資料が提出されるとは限りません。
提出された資料を確認し、不足があれば追加資料や質問への回答を求めます。
機密性の高い情報を扱うため、閲覧権限や保存方法を含めた情報管理も必要です。
4.資料を分析して課題を整理する
開示された資料をもとに、システム構成、運用体制、費用、契約関係などを分析します。
資料同士の内容に矛盾がないか、情報が古くないかも確認します。
例えば、システム一覧に記載されているアプリケーションと、費用明細に記載されている保守契約が一致しない場合、追加確認が必要です。
この段階で、重要なリスク、追加質問、インタビューで確認すべき事項を整理します。
5.経営者やIT担当者へインタビューする
資料だけでは分からない事項について、経営者、IT部門、各業務部門の担当者などにインタビューします。
資料上は問題がないように見えても、実際には手作業で補っていたり、担当者が頻繁に障害対応していたりすることがあります。
また、システムに対する経営陣の認識と、現場の評価が異なるケースもあります。
事実確認だけでなく、システム運用上の課題や将来計画についても聞き取ります。
関連記事:M&Aで必要な調査とは?デューデリジェンスだけでは見えない企業リスクの調べ方
6.リスクと対応費用を評価する
見つかった問題を、発生可能性、事業への影響、緊急性、対応費用などに基づいて分類します。
重大な問題については、買収後に必要な対応策と費用を概算し、価格交渉やPMI計画に利用できる形で整理します。
7.調査結果を報告書にまとめる
調査結果は、経営陣やM&A担当者が意思決定に利用できる形で報告書にまとめます。
技術的な問題を列挙するだけではなく、次の点を明確にすることが重要です。
問題の内容
発生する可能性
事業や取引への影響
必要な対応
対応費用
対応時期
買収条件への反映方法
重大な問題については、買収前に対応すべきか、買収後のPMIで対応するかも整理します。
ITデューデリジェンスで確認する主な資料
ITデューデリジェンスでは、対象会社から開示された資料をもとに調査を進めます。
必要資料は調査範囲によって異なりますが、主に次の資料を確認します。
システム構成・IT資産に関する資料
システム構成図
ネットワーク構成図
アプリケーション一覧
サーバー・端末一覧
IT資産台帳
システムのバージョン・稼働開始時期
障害履歴
システム開発・改修履歴
データ連携図
資料が更新されていない場合は、実際の環境と一致しているか追加確認が必要です。
ITコスト・投資計画に関する資料
IT予算
過去数年のIT費用
システム別の運用・保守費
クラウド利用料
ソフトウェアライセンス費
外部委託費
将来のIT投資計画
進行中プロジェクトの予算・実績
一時的な費用と継続的に発生する費用を分けて確認します。
組織・運用体制に関する資料
IT部門の組織図
IT担当者一覧
担当業務・役割分担表
運用手順書
障害対応手順
外部委託先一覧
システム運用に関する会議資料
IT人材の採用・退職予定
重要な業務が特定の担当者に集中していないかも確認します。
セキュリティ・障害履歴に関する資料
情報セキュリティ規程
個人情報保護規程
アクセス権限一覧
セキュリティ監査結果
脆弱性診断結果
インシデント履歴
バックアップ手順
BCP・災害対策資料
従業員向けセキュリティ教育資料
資料の有無だけでなく、規程どおりに運用されているかをインタビューなどで確認します。
契約・ライセンスに関する資料
システム開発契約書
保守・運用契約書
クラウドサービス契約
ソフトウェアライセンス
データセンター契約
外部委託契約
親会社やグループ会社とのシステム利用契約
自社開発システムの権利関係を示す資料
M&Aによって契約が解除されたり、相手方の承諾が必要になったりしないかを確認します。
ITデューデリジェンスの結果をM&Aにどう反映するか
ITデューデリジェンスで把握した課題は、買収価格や契約条件だけでなく、買収後のシステム移行・統合計画にも反映します。
IT更新・統合に必要な費用を取引条件に反映する
対象会社のシステム更新やセキュリティ改善、データ移行などに多額の費用がかかる場合は、その負担を企業価値評価や買収価格に反映します。
必要に応じて、重要なベンダー契約の継続、ソフトウェアライセンスの取得、アクセス権限の是正などをクロージングの条件にすることもあります。
問題が重大で、価格調整や契約条件では対応できない場合には、M&Aを見送る判断も必要です。
システムの切り離しが必要な場合はTSAを検討する
対象会社が売り手の親会社やグループ共通システムを利用している場合、クロージング直後に独立したシステムへ移行できないことがあります。
その場合は、一定期間、売り手からシステム利用や運用支援を受けるTSAを締結します。
TSAでは、利用するサービス、提供期間、料金、障害時の対応、データの取扱い、終了方法などを定めます。終了までにシステムの移行や新規構築を完了できるよう、具体的な計画を作成することが重要です。
ITに関する課題をPMI計画に反映する
ITデューデリジェンスで確認した課題は、買収後のPMIの予算とスケジュールに組み込みます。
システム統合、セキュリティ改善、ベンダー契約の見直し、IT組織の再編などについて優先順位を決め、事業運営への影響を抑えながら進めます。
特に基幹システムの統合やデータ移行は、業務停止につながる可能性があります。技術面だけでなく、業務部門への影響も考慮して計画する必要があります。
買収価格の調整や表明保証など、デューデリジェンスで問題が見つかった場合の一般的な対応については、「デューデリジェンスとは?意味・種類・進め方・注意点を解説」で詳しく解説しています。
ITデューデリジェンスで特に注意すべき点
ITデューデリジェンスでは、資料に記載されたシステム構成と実際の運用状況が一致しているとは限りません。また、将来のIT費用は、統合方針や改修範囲によって大きく変わります。
資料と実際の運用状況を照合する
システム構成図や運用手順書が古く、現在の環境を正確に反映していないことがあります。
正式な手順が定められていても、実際には担当者が手作業で処理していたり、特定の社員だけが障害対応を行っていたりするケースもあります。
資料の確認だけで終わらせず、IT担当者やシステムを利用する業務部門へのインタビューを行い、実際の運用状況と照合することが重要です。
費用試算の前提と不確実性を明確にする
ITデューデリジェンスは限られた期間と資料で行われるため、システム更新や統合に必要な費用を正確に算出できないことがあります。
費用を概算する際は、対象システム、改修範囲、統合方針、作業期間などの前提を明確にし、一定の幅を持たせて示します。
追加調査や統合方針の変更によって金額が変わる可能性も併記し、試算額だけを前提にM&Aの判断を行わないよう注意が必要です。
ITデューデリジェンスは誰に依頼する?
ITデューデリジェンスは、自社のIT部門が中心となって実施する場合と、外部の専門家に依頼する場合があります。
取引規模や対象会社のシステム構成、社内の人員などを踏まえて判断します。
自社のIT部門だけで対応できるケース
対象会社の規模が小さく、利用しているシステムも一般的なクラウドサービスが中心であれば、自社のIT部門で対応できる場合があります。
また、買い手が同業種で、対象会社のシステムや業務内容に詳しい場合も、社内で調査しやすいでしょう。
ただし、通常業務と並行して調査を行うと、十分な時間を確保できないことがあります。
社内対応の場合でも、調査範囲と担当者を明確にして進める必要があります。
外部専門家への依頼が必要なケース
次のような場合は、外部のIT専門家への依頼を検討します。
対象会社のシステム構成が複雑
独自開発システムが事業の中核になっている
買収後に大規模なシステム統合を予定している
セキュリティリスクを詳しく確認したい
システム更新や統合費用を試算したい
自社にITデューデリジェンスの経験者がいない
調査期間が短く、社内だけでは対応できない
技術的な調査だけでなく、M&A条件やPMIへの反映まで支援できる専門家を選ぶことが重要です。
依頼先を選ぶ際の確認ポイント
依頼先を選ぶ際は、ITの知識だけでなく、M&Aや対象業界への理解があるかを確認します。
主な確認ポイントは次のとおりです。
ITデューデリジェンスの実績
対象業界のシステムに関する知識
セキュリティやクラウドへの対応力
システム統合・切り離しの経験
対応費用を試算できるか
財務・法務など他のDDチームと連携できるか
調査結果を経営判断向けに整理できるか
専門用語を並べるだけでなく、問題が企業価値や買収後の事業運営にどう影響するかを説明できることが重要です。
まとめ
ITデューデリジェンスは、M&Aの実行前に、対象会社のシステム、ITインフラ、組織、コスト、情報セキュリティなどを調査する手続きです。
システムが現在正常に稼働していても、老朽化、属人化、ベンダー依存、セキュリティ上の不備などにより、買収後に追加費用や業務上の問題が発生する可能性があります。そのため、問題の有無だけでなく、対応費用、必要期間、事業への影響まで評価することが重要です。
調査結果は、買収価格や契約条件、TSA、PMI計画などに反映します。対象会社の業種やITへの依存度に応じて調査範囲を設定し、買収後の運営まで見据えて確認しましょう。
エスプレッソ情報調査室では、M&Aに伴う企業実態調査やデジタルフォレンジックなどに対応しています。開示資料だけでは確認しにくいリスクがある場合は、お気軽にご相談ください。
一覧ページに戻る
一覧ページに戻る


