はじめに
ITデューデリジェンス（IT-DD、システムDD、ITDDとも表記）は、M&Aにおいて対象会社のIT資産・システム・セキュリティ・IT人材の実態を調査するプロセスです。ビジネスDDや財務DDが「その会社に価値があるか」を評価するとすれば、ITデューデリジェンスが問うのは「買収後に、そのITと一緒にやっていけるか」という点——システム統合コスト、技術的リスク、PMIの実行可能性を見極める作業です。財務諸表には表れない隠れたコストがここに集中しています。
ITデューデリジェンスは、M&Aの現場で後回しにされやすい領域です。財務DDや法務DDが先行する中で「ITは後で確認すればいい」という判断になりがちですが、その結果としてPMIフェーズで想定外のコストと遅延が発生するケースを何度も見てきました。
ここで取り上げる7つは、標準的なチェックリストでは見つけにくく、事前に把握できていれば対処できたにもかかわらず、後から問題になったものです。特定の業種や規模に限った話ではなく、M&A全般で繰り返し出てくるパターンです。
「システム一覧」に載っていないシャドーITの存在
対象会社から提出されるシステム一覧は、IT部門が把握している公式システムのみです。現場部門がIT部門の承認なく導入したSaaSやクラウドツール——いわゆるシャドーIT——が業務の中核を担っているケースは、実際にかなり多いです。
買収後に発生しやすいこと
- 「実はこのツールが基幹業務に使われていた」と判明し、ライセンス再契約や移行コストが発生する
- シャドーITに顧客データや機密情報が格納されており、セキュリティ上の問題が後から浮上する
- 特定の担当者しか使い方を知らないツールが業務継続上のボトルネックになっている
どう調べるか
IT部門へのヒアリングだけでは不十分で、営業・経理・人事など各現場部門に「普段どんなツールを使っているか」を直接聞くことが必要です。法人クレジットカード明細や、もしあればSaaS管理ツールのログから、IT部門の管轄外の契約を洗い出す方法も実際に使っています。
BDDは大手、システムDDはゼロ——よくある落とし穴
業務効率化を目的としたM&Aで、ビジネスDDには大手アドバイザリーが入っていたにもかかわらず、IT領域が全く調査されていなかった案件を複数件見てきました。
結果として、買収後のシステム改修・業務統合に多大なコストと時間が発生し、当初想定していたシナジーが完全に打ち消された、どころかマイナスになったケースもあります。BDDの品質が高くても、システムDDが抜け落ちていればPMIは必ず苦労します。
特に取引先が多い物流・製造系の企業では、EDI・WMS・TMS・受発注システムなど取引先ごとに接続するシステムが増えていきます。DD時点では「システム一覧」に記載のないものも多く、PMIに入って初めて全容が明らかになり、統合作業が当初見込みの数倍になるというケースは珍しくありません。
技術的負債の「見えないコスト」
財務DDではオフバランスの簿外債務が重視されますが、技術的負債（テクニカルデット）は財務諸表に一切現れません。古い言語で書かれたコード、ドキュメントのないシステム、属人化した運用——これらは将来の費用として潜んでいます。厄介なのは表面上は動いているため、DD段階では目に見えないことです。
PMI後に出てくること
- システム改修・刷新コストが当初想定の2〜5倍になる
- 古いシステムを保守できるエンジニアが市場にほぼおらず、採用コストが跳ね上がる
- コード品質が低く、新機能の開発速度が著しく落ちる
見るべきポイント
主要システムの稼働年数・使用言語・フレームワークのバージョン・ドキュメント整備状況を確認します。可能であればソースコードのレビューや外部エンジニアによる簡易評価で規模を定量的に掴みます。使用しているライブラリのサポート状況は特に見落としやすい点で、後述のコラムで実例を紹介しています。
「ちゃんと動いている」システムの落とし穴
デジタルマーケシステム提供会社のシステムDDで、対象会社の主力システムはデモでも本番でも問題なく稼働していました。担当エンジニアからも「特にトラブルはない」という説明があり、ヒアリング段階では大きな懸念はありませんでした。
しかし外部エンジニアによるコードレビューに入ったところ、基幹機能の一部でメーカーのサポートが数年前に終了したライブラリが複数使われていることが判明しました。現時点では動いているものの、セキュリティパッチが提供されない状態が続いており、医療情報を扱うシステムとして法的・コンプライアンス上のリスクが潜在していたのです。
買収後にライブラリの入れ替えと動作検証を行うことになり、当初のPMIスケジュールから大幅に遅延しました。「動いている」と「問題がない」は別の話で、特にセキュリティや規制対応が絡む業種では、サポート期限切れのコンポーネントがどこかに潜んでいないかを必ず確認する必要があります。
ベンダー契約の「変更禁止条項」と買収時の扱い
ライセンスやクラウドサービスの内容がITデューデリジェンスで精査されることはあっても、「チェンジオブコントロール条項（CoC条項）」の確認が漏れるケースがあります。会社の支配権が変わった場合——つまりM&A完了時——に、契約継続に相手方の同意が必要になる、または自動解除される条項です。法的解釈は法務DDの仕事ですが、「どのシステムが止まると業務が止まるか」という業務インパクトの評価はITデューデリジェンス（IT-DD）側が担います。
見落とすと何が起きるか
- 基幹システムのライセンスがM&A完了と同時に失効し、業務が止まる
- ベンダーから再交渉を求められ、条件が大幅に悪化する
- SaaSのSSO設定が組織変更後に機能しなくなる
対処の仕方
業務上クリティカルなシステムを先にリストアップし、法務DDチームと連携してCoC条項の有無を確認します。売上・顧客接点に関わるシステムから優先し、必要であればクロージング前にベンダーへの事前通知・同意取得をスケジュールに入れておきます。
クロージング翌日に基幹システムが止まりかけた案件
SaaS系企業のITデューデリジェンスで、主要な営業管理システムの契約書にCoC条項が含まれていることをDD完了後に法務チームが発見しました。ITデューデリジェンスの段階でシステム一覧は確認していましたが、契約書の精査は法務DDの領域として分業していたため、連携が取れていなかったのです。
発覚のタイミングがクロージング2週間前だったため、急ぎベンダーへ事前通知を行い、同意取得のための交渉を並行させることになりました。結果的に追加費用150万円で契約を継続できましたが、これは「うまくいった」ケースです。発覚がクロージング後だったら、と思うと今でも背筋が寒くなります。そういう案件を、筆者は別の会社で実際に見ています。
サイバーセキュリティの「過去の痕跡」
セキュリティ対策の現状（ファイアウォール・EDR・脆弱性スキャンの実施有無など）は確認されることがあっても、「過去にインシデントがあったか」「適切に処理されたか」まで踏み込まれないことがあります。現在の対策が整っていても、過去の痕跡が残っていれば買収後にリスクとして顕在化します。
過去を調べない場合に起きること
- 過去の不正アクセスやマルウェア感染が完全に駆除されておらず、潜伏したまま買収してしまう
- 情報漏洩が将来の法的責任（GDPR・個人情報保護法）として後から浮上する
- ダークウェブに流出した認証情報が買収後に攻撃者に利用される
調査の進め方
過去3〜5年のインシデント記録・社内外への報告履歴・対処内容を確認します。対象会社のドメインやメールアドレスのダークウェブ流出状況を専門ツールで確認することも実務上よく使います。重大な案件では独立した第三者によるペネトレーションテストを検討してください。
「セキュリティ対策は万全」と言われた会社のダークウェブ流出
ITデューデリジェンスのヒアリングで「EDRを導入済み、脆弱性スキャンも定期実施している」と説明を受けた会社で、念のためダークウェブの流出状況を確認したところ、2年前に流出したと思われる社員メールアドレスとパスワードのセットが12件見つかりました。
対象会社の担当者に確認すると、過去にフィッシングメール被害があったことは把握していたものの「すぐにパスワードを変更させた」として報告書の中では軽微な事案として処理されていました。しかし流出した認証情報の中には、クラウドの管理者アカウントに近い権限を持つものも含まれており、買収後のセキュリティリスクとして改めて評価し直すことになりました。現在の対策状況だけ見ていれば気づかなかった論点です。
IT人材の「実態」——人数と開発能力は別物
開発力強化を目的としたM&Aでは、エンジニアの人数や肩書きがそのまま「開発能力」として評価されるケースがあります。しかしBDD担当者にIT知見がない場合、エンジニアが多数在籍していても実際の開発力を正確に評価できず、買収後に想定と大きく乖離することがあります。
エンジニアが20名いても、開発できる人間は2名だった
PMI文脈で携わった、システム会社のM&Aで、買収側の目的は「自社サービスの開発スピードを上げたい」という開発力強化でした。対象会社には20名超のエンジニアが在籍しており、BDD担当者のヒアリングでは「豊富な開発リソースがある」という評価でDDを終えていました。
しかし買収後に蓋を開けると、実態は全く異なりました。40名のうち大半は運用・保守専任で、新規開発の経験がほぼありませんでした。自社で受けていた既存システムの保守業務をこなすことはできても、新機能を一から設計・実装できるエンジニアは数名にすぎませんでした。残りは外部委託と密接に組み合わさった運用体制で動いており、「自走できる開発チーム」という想定とはかけ離れていたのです。
この案件が示す教訓は二つあります。一つは、エンジニアの人数・役職だけでなく、「何ができる人材か」をスキルセット・開発実績・外部委託依存度の観点で個別に評価する必要があること。もう一つは、IT知見を持つ専門家がシステムDDに関与しないと、BDDの段階でこうした実態の見極めが難しいということです。
確認すべきポイント
- エンジニアのスキルセット分類：開発（新規）・運用保守・インフラの役割別に人数と実績を確認する
- 開発実績の具体的な確認：直近1〜2年で内製した機能・システムの規模と担当者を特定する
- 外部委託依存度：どの工程を外注しているか。内製化の範囲と外注先との契約継続性を確認する
- 退職リスク：実際に開発を担える人材の勤続年数・転職意向・報酬水準を確認する
※エンジニアのスキル評価は、IT知見のない担当者では難しい領域です。BDDとシステムDDの連携、またはIT専門家への相談を検討することをお勧めします。
ベンダー依存度と「ロックイン」リスク
現在稼働しているシステムの機能や安定性には目が向きがちですが、「そのシステムから将来抜け出せるか」という視点は後回しになりやすいです。PMI後に親会社のシステムへ統合しようとした段階で初めて、ロックインの深刻さに気づくことがあります。
気づいた時には遅い、というパターン
- 特定ベンダーの独自仕様で構築されており、乗り換え時のデータ移行コストが膨大
- カスタマイズが深く入りすぎており、バージョンアップやサポート終了時に対応できるベンダーが実質1社
- ソースコード・データの所有権がベンダー側にあり、交渉力が著しく低い
- 統合を試みたところ、技術的・契約的に移行が困難で費用が膨大になる
事前に見ておくこと
ソースコード・データの所有権、標準的なAPIやデータ形式への準拠状況、代替ベンダーが市場に存在するかを確認します。過去の契約更新時に価格交渉が可能だったかという実績も、依存度を測る目安になります。
PMI統合で「移行できない」と分かった基幹システム
製造業のM&Aで、買収後に買い手側の基幹システムへの統合を進めようとしたところ、対象会社の生産管理システムが特定ベンダーの独自フォーマットで深くカスタマイズされており、データのエクスポートすら標準機能では対応できない状態でした。ITデューデリジェンスの段階では「現在問題なく稼働している」という評価で留まっており、将来の統合可能性は検証されていませんでした。
ベンダーに移行支援を依頼したところ、「独自開発のため対応費用は別途見積もり」と言われ、最終的に数千万円規模の移行コストが発生しました。PMIの統合スコープが決まった段階でロックインの深刻さが明らかになるケースは少なくありません。ITデューデリジェンスの段階で「このシステムから出られるか」を確認しておくことが、PMIの計画精度を大きく左右します。
クラウド・SaaSのコスト構造の「実態」
クラウドやSaaSの費用は「ITコスト」として集計されますが、契約上の表示費用と実際の運用コストが乖離していたり、事業成長に伴うコスト増が計算されていないケースは少なくありません。財務DDでITコストを確認していても、実態とずれていることがあります。
よく見つかる問題
- 従量課金型クラウド（AWS・GCP・Azure）の実費が見積もりと大きくずれており、想定外のコストが発生している
- SaaSのシート数・利用量が実態と合わず、過剰契約または利用規約違反の状態になっている
- 事業規模が拡大するとクラウドコストが非線形に増加し、収益性を圧迫する構造になっている
- 部門ごとにバラバラにSaaSを契約しており、全体像を把握している担当者が社内にいない
具体的に何を見るか
直近12ヶ月のクラウド・SaaS実費の月次推移を確認し、急増したタイミングとその理由を把握します。主要SaaSのシート数・契約プランと実際の利用者数を照合し、過不足を確認します。事業成長シナリオ（例：売上2倍）でITコストがどう変化するかをシミュレーションしておくと、バリュエーションの前提として使えます。
7つを振り返って
ITデューデリジェンス（システムDD）は、システム一覧とコスト表を確認して終わりではありません。「今動いているから問題ない」という判断が、PMI後に大きな代償になるケースを繰り返し見てきました。財務DDや法務DDと連携しながら、「この会社のITを買収した後、何が起きるか」という視点で設計することが大事です。
ここで挙げた7つは、どれも事前に把握できれば対処できたものです。シャドーITの棚卸し、ライブラリのサポート状況確認、エンジニアの実際の開発能力評価——どれも地味な作業ですが、PMIで発覚した後のコストと比べれば安いです。
DD-AXでは、こうした論点をAIによる情報横断と専門家の知見を組み合わせて洗い出す支援を行っています。「どこから手をつければいいか分からない」という段階からご相談いただけます。