ITデューデリジェンス（IT-DD・システムDD）とは——調査範囲・流れ・費用と7つの盲点

ITデューデリジェンス（IT-DD、システムDD、システムデューデリジェンス、ITDDとも表記）とは、M&Aで対象会社のIT資産・システム・セキュリティ・IT人材・クラウドコストの実態を調べ、買収後の統合コストとリスクを見極める調査です。ビジネスDDや財務DDが「その会社に価値があるか」を評価するとすれば、ITデューデリジェンスが問うのは「買収後に、そのITと一緒にやっていけるか」——システム統合コスト、技術的リスク、PMIの実行可能性です。財務諸表には表れない隠れたコストが、ここに集中しています。

ITデューデリジェンスは、M&Aの現場で後回しにされやすい領域です。財務DDや法務DDが先行する中で「ITは後で確認すればいい」という判断になりがちですが、その結果としてPMIフェーズで想定外のコストと遅延が発生するケースを何度も見てきました。

ITデューデリジェンスの調査範囲——5つの領域

実務では、対象会社のITをおおむね次の5領域に分けて見ていきます。後で挙げる7つの盲点も、この5領域の中で特に見落とされやすい論点を抜き出したものです。

まずシステム資産・ベンダー契約では、基幹システム・SaaS・シャドーITを棚卸しし、支配権変更で失効する契約条項の有無まで踏み込みます（Section 01・03・06）。次に技術的負債として、コード品質・サポート切れライブラリ・属人化した運用を見ます（Section 02）。セキュリティは現在の防御態勢だけでなく、過去のインシデントや認証情報流出の痕跡まで確認します（Section 04）。

加えてIT人材は、エンジニアの人数ではなく新規開発・運用保守それぞれの実力と退職リスクで評価し（Section 05）、最後にクラウド・SaaSコストとして従量課金の実費推移と、事業拡大時の非線形なコスト増を押さえます（Section 07）。

調査の進め方と全体の流れ

ITデューデリジェンスは、IT部門へのヒアリングを起点に、システム一覧・契約書・コスト明細・コードの順で実態を突き合わせていきます。財務DD・法務DDと並行して進むため、「どのシステムが止まると業務が止まるか」を早い段階で共有しておくと、後工程の手戻りが減ります。DD全体の流れ・期間・他のDDとの関係はデューデリジェンスとはに、自社で担うか外部に出すかの線引きは自社対応か外注かに整理しています。

ここで取り上げる7つは、標準的なチェックリストでは見つけにくく、事前に把握できていれば対処できたにもかかわらず、後から問題になったものです。特定の業種や規模に限った話ではなく、M&A全般で繰り返し出てくるパターンです。

対象会社から提出されるシステム一覧は、IT部門が把握している公式システムのみです。現場部門がIT部門の承認なく導入したSaaSやクラウドツール——いわゆるシャドーIT——が業務の中核を担っているケースは、実際にかなり多いです。

買収後に発生しやすいこと

• 「実はこのツールが基幹業務に使われていた」と判明し、ライセンス再契約や移行コストが発生する
• シャドーITに顧客データや機密情報が格納されており、セキュリティ上の問題が後から浮上する
• 特定の担当者しか使い方を知らないツールが業務継続上のボトルネックになっている

どう調べるか

IT部門へのヒアリングだけでは不十分で、営業・経理・人事など各現場部門に「普段どんなツールを使っているか」を直接聞くことが必要です。法人クレジットカード明細や、もしあればSaaS管理ツールのログから、IT部門の管轄外の契約を洗い出す方法も実際に使っています。

財務DDではオフバランスの簿外債務が重視されますが、技術的負債（テクニカルデット）は財務諸表に一切現れません。古い言語で書かれたコード、ドキュメントのないシステム、属人化した運用——これらは将来の費用として潜んでいます。厄介なのは表面上は動いているため、DD段階では目に見えないことです。

PMI後に出てくること

• システム改修・刷新コストが当初想定を大きく上回る（筆者の体感では2〜3倍に膨らむことも珍しくない）
• 古いシステムを保守できるエンジニアが市場にほぼおらず、採用コストが跳ね上がる
• コード品質が低く、新機能の開発速度が著しく落ちる

見るべきポイント

主要システムの稼働年数・使用言語・フレームワークのバージョン・ドキュメント整備状況を確認します。可能であればソースコードのレビューや外部エンジニアによる簡易評価で規模を定量的に掴みます。使用しているライブラリのサポート状況は特に見落としやすい点で、後述のコラムで実例を紹介しています。

ライセンスやクラウドサービスの内容がITデューデリジェンスで精査されることはあっても、「チェンジオブコントロール条項（CoC条項）」の確認が漏れるケースがあります。会社の支配権が変わった場合——つまりM&A完了時——に、契約継続に相手方の同意が必要になる、または自動解除される条項です。法的解釈は法務DDの仕事ですが、「どのシステムが止まると業務が止まるか」という業務インパクトの評価はITデューデリジェンス（IT-DD）側が担います。

見落とすと何が起きるか

• 基幹システムのライセンスがM&A完了と同時に失効し、業務が止まる
• ベンダーから再交渉を求められ、条件が大幅に悪化する
• SaaSのSSO設定が組織変更後に機能しなくなる

対処の仕方

業務上クリティカルなシステムを先にリストアップし、法務DDチームと連携してCoC条項の有無を確認します。売上・顧客接点に関わるシステムから優先し、必要であればクロージング前にベンダーへの事前通知・同意取得をスケジュールに入れておきます。

セキュリティ対策の現状（ファイアウォール・EDR・脆弱性スキャンの実施有無など）は確認されることがあっても、「過去にインシデントがあったか」「適切に処理されたか」まで踏み込まれないことがあります。現在の対策が整っていても、過去の痕跡が残っていれば買収後にリスクとして顕在化します。

過去を調べない場合に起きること

• 過去の不正アクセスやマルウェア感染が完全に駆除されておらず、潜伏したまま買収してしまう
• 情報漏洩が将来の法的責任（GDPR・個人情報保護法）として後から浮上する
• ダークウェブに流出した認証情報が買収後に攻撃者に利用される

調査の進め方

過去3〜5年のインシデント記録・社内外への報告履歴・対処内容を確認します。対象会社のドメインやメールアドレスのダークウェブ流出状況を専門ツールで確認することも実務上よく使います。重大な案件では独立した第三者によるペネトレーションテストを検討してください。

開発力強化を目的としたM&Aでは、エンジニアの人数や肩書きがそのまま「開発能力」として評価されるケースがあります。しかしBDD担当者にIT知見がない場合、エンジニアが多数在籍していても実際の開発力を正確に評価できず、買収後に想定と大きく乖離することがあります。

確認すべきポイント

まずエンジニアのスキルセットを分類し、開発（新規）・運用保守・インフラの役割別に人数と実績を確認します。そのうえで開発実績を具体的に掘り下げ、直近1〜2年で内製した機能・システムの規模と担当者を特定します。役割と実績の両面を見て初めて、肩書きと実力のずれが見えてきます。

加えて外部委託依存度として、どの工程を外注しているか、内製化の範囲と外注先との契約継続性を確認します。最後に退職リスクを見て、実際に開発を担える人材の勤続年数・転職意向・報酬水準を押さえておきます。

※エンジニアのスキル評価は、IT知見のない担当者では難しい領域です。BDDとシステムDDの連携、またはIT専門家への相談を検討することをお勧めします。

現在稼働しているシステムの機能や安定性には目が向きがちですが、「そのシステムから将来抜け出せるか」という視点は後回しになりやすいです。PMI後に親会社のシステムへ統合しようとした段階で初めて、ロックインの深刻さに気づくことがあります。

気づいた時には遅い、というパターン

• 特定ベンダーの独自仕様で構築されており、乗り換え時のデータ移行コストが膨大
• カスタマイズが深く入りすぎており、バージョンアップやサポート終了時に対応できるベンダーが実質1社
• ソースコード・データの所有権がベンダー側にあり、交渉力が著しく低い
• 統合を試みたところ、技術的・契約的に移行が困難で費用が膨大になる

事前に見ておくこと

ソースコード・データの所有権、標準的なAPIやデータ形式への準拠状況、代替ベンダーが市場に存在するかを確認します。過去の契約更新時に価格交渉が可能だったかという実績も、依存度を測る目安になります。

クラウドやSaaSの費用は「ITコスト」として集計されますが、財務DDで見るのは過去から現在までの実績値で、買収後に効いてくるのは「事業を伸ばしたときにこのコストがどう跳ねるか」のほうです。表示費用と実際の運用コストの乖離に加え、この将来側の感応度が抜けたまま投資判断に進んでしまうことがあります。

よく見つかる問題

• 従量課金型クラウド（AWS・GCP・Azure）の実費が見積もりと大きくずれており、想定外のコストが発生している
• SaaSのシート数・利用量が実態と合わず、過剰契約または利用規約違反の状態になっている
• 事業規模が拡大するとクラウドコストが非線形に増加し、収益性を圧迫する構造になっている
• 部門ごとにバラバラにSaaSを契約しており、全体像を把握している担当者が社内にいない

具体的に何を見るか

直近12ヶ月のクラウド・SaaS実費の月次推移を確認し、急増したタイミングとその理由を把握します。主要SaaSのシート数・契約プランと実際の利用者数を照合し、過不足を確認します。事業成長シナリオ（例：売上2倍）でITコストがどう変化するかをシミュレーションしておくと、バリュエーションの前提として使えます。

ITデューデリジェンス自体の実施費用は、スコープの広さと、コードレビューやペネトレーションテストといった専門作業をどこまで含めるかで大きく変わります。ここでいう費用は「対象会社が毎月支払っているITコスト」（Section 07）とは別物で、買い手がDDの調査に支払う費用を指します。

レンジに幅があるのは、対象会社のシステム本数・内製と外注の比率・規制業種かどうかで作業量が一桁変わるためです。筆者の体感では、取引先ごとに接続するシステムが多い物流・製造系や、医療・金融のように規制対応が絡む業種は、同じ売上規模でも標準版の上限に振れやすい傾向があります（業種別のDD落とし穴）。

費用を抑える現実的な順番は、まず社内で棚卸しできる範囲を埋め、判断に直結する論点だけを外部のIT専門家に依頼する、という分担です。DD種類別の費用相場の全体像はM&AのDD費用相場に、自社対応との線引きは自社対応か外注かに整理しています。

もう一段、費用を左右するのが工程の分担です。契約書やシステム構成図の横断整理、SaaS課金明細の分析、認証情報の流出痕跡の一次収集といった定型工程はAIで圧縮でき、コード品質の妥当性・業務クリティカル度・属人性リスクの判断は経験を積んだIT専門家が握る。この切り分けをとれば、ITに詳しくない買い手でも、大手にフルスコープで頼むより安く・速く、品質を落とさずITデューデリジェンスを回せます。なぜ安く・速いのに品質が落ちないのかはAIで安く・速いのに品質が落ちない理由に、非エンジニアがはじめてシステムDDを外注するときの進め方ははじめてのIT-DD発注ガイドに整理しています。

ITデューデリジェンス（システムDD）とは何ですか？

M&Aで対象会社のIT資産・システム・セキュリティ・IT人材・クラウドコストの実態を調べ、買収後の統合コストとリスクを見極める調査です。IT-DD、システムDD、システムデューデリジェンスは、ほぼ同じ意味で使われます。ビジネスDDが「価値があるか」を見るのに対し、ITデューデリジェンスは「買収後にそのITと一緒にやっていけるか」を見ます。

システムDDとITデューデリジェンスは違うものですか？

実務上はほぼ同義です。「システムDD」はシステム資産や技術面を強調した呼び方、「IT-DD／ITデューデリジェンス」はIT人材・セキュリティ・コストまで含めた広めの呼び方として使われることが多いですが、調査範囲は大きく重なります。ここではまとめてITデューデリジェンスと呼んでいます。

ITデューデリジェンスの費用はどれくらいですか？

ドキュメント中心の簡易レビューなら数十万円から、標準的なIT-DDで100万〜300万円前後が目安です。コードレビューや第三者ペネトレーションテストまで含めると300万円を超えることもあります。種類別の費用相場はM&AのDD費用相場もあわせてご覧ください。

自社でITデューデリジェンスはできますか？

システム一覧・契約・コスト明細の棚卸しまでは社内でも進められます。ただしコード品質やエンジニアの開発力の評価はIT知見がないと難しく、ここを誤るとPMIで大きくつまずきます。判断に直結する論点だけ外部のIT専門家に依頼する分担が現実的です（自社対応か外注か）。

対象がSaaS・AI企業や受託開発の場合、見るところは変わりますか？

変わります。SaaSならARR・チャーン・NRRやAI耐性（AI・SaaSのDD）、受託開発・SIerならAI普及後も単価が残るか（SIer・受託開発のDD）が焦点になります。DD作業そのものへのAI活用の可否はM&AのDDにAIをどう使うかに整理しています。

ITデューデリジェンスはいつ実施しますか？

財務DD・法務DDと並行して、基本合意の後からクロージング前までに実施するのが一般的です。チェンジオブコントロール条項のように、クロージング前でないと手当てできない論点もあるため、後回しにせず早めに着手するほど打ち手の幅が広がります。DD全体の流れと期間はデューデリジェンスとはに整理しています。