ITDD（ITデューデリジェンス）とは｜買い手経営者の判断軸と調査範囲

M&Aの検討が進み、財務DDは会計士に、法務DDは弁護士に依頼した。ところがITについては「見られる人がいない」まま、対象会社から出てきたシステム一覧を眺めただけで最終契約に進む——中小企業のM&Aでは、いまだに珍しくない光景である。

そしてクロージング後に発覚する。基幹システムのサポートがとうに切れていた。開発も運用も退職間近の一人のベテランに握られていた。ライセンス違反状態のソフトウェアが業務の中心にあった。どれも、買収前に半日ヒアリングすれば見えていたはずのものだ。

本稿は、買い手側の経営者・経営企画の方——とりわけ事業承継や中小M&Aで買収を検討する立場の方——に向けて、ITDD（ITデューデリジェンス）で何を見て、見つけた問題をどう買収判断に反映するかを整理する。チェックリストの逐条解説ではなく、依頼する側・判断する側の目線で書く。

ITDDとは ── 財務・法務と並ぶ調査の柱

ITDD（IT Due Diligence）とは、M&Aの検討過程で、対象会社のITシステム・技術資産・IT組織を調査し、その価値とリスクを買収判断に使える形で評価する工程を指す。財務DD・法務DDと並ぶ調査の柱であり、BDD（ビジネスDD）と一体で実施されることが多い。

BDDとITDDが一体になりやすいのには理由がある。事業の実態は、多くの場合システムに刻まれているからだ。受注から請求までの業務フローも、顧客データの持ち方も、属人化の度合いも、システムを見れば事業の実像が裏付けられる。逆に、事業計画上の成長シナリオが「いまのシステムでは物理的に捌けない」ことも、ITを見て初めて分かる。事業の強みがシステムに由来するのか、システムが事業の制約になっているのか——この見極めが、BDD×ITDDを一体で行う最大の目的である。

なぜ後回しにされ、なぜ後から効いてくるのか

ITDDが省略されやすい理由ははっきりしている。財務には会計士、法務には弁護士という定番の依頼先があるのに対し、ITDDは「誰に頼めばよいか」が買い手にとって自明でない。加えて、ITは管理部門の話であって買収判断を左右するものではない、という思い込みも根強い。

だが、ITの問題は性質上、買収後に効いてくる。財務の問題は価格交渉の段階で表面化するが、システムの老朽化や属人化は、クロージング直後の担当者退職、繁忙期のシステム障害、統合作業の見積もり超過という形で、所有者が変わった後に請求書が届く。中小M&AのDD全般に言えることだが、「DDの省略で浮いた費用」と「買収後に発覚した問題の対処費用」は、後者が桁違いに大きくなりがちである。M&A市場の拡大と失敗パターンの全体像は事業承継・中小M&AのDD実務で整理したとおりだ。

調査範囲 ── 5つの領域

ITDDの調査範囲は、おおむね次の5領域に分かれる。

領域	見るもの	典型的な発見事項
インフラ	サーバー、ネットワーク、クラウド利用状況	サポート切れOS、バックアップ未検証、単一障害点
アプリケーション資産	基幹システム、自社開発ソフト、技術的負債	古い言語での内製システム、ドキュメント不在、改修困難
セキュリティ	対策水準、インシデント履歴、認証・権限管理	退職者アカウントの放置、インシデントの未報告
契約・ライセンス	ソフトウェアライセンス、保守契約、外部委託	ライセンス数超過、チェンジオブコントロール条項
組織・属人性	IT人材、スキル分布、キーパーソン依存	特定個人しか触れないシステム、後継者不在

なお、契約・ライセンス領域で見落とされがちなのがチェンジオブコントロール（COC）条項である。株主の変更を契機に、重要なシステムの利用契約や保守契約が解除・再交渉の対象になる場合があり、M&Aそのものが契約上のトリガーになる。ここは法務DDとの連携領域だ。各領域の具体的なチェック項目・調査の流れ・費用感は、当サイト運営元が運営するDD専門サイトのIT-DD解説（調査範囲・流れ・費用と盲点）に詳しいので、実務に入る段階ではそちらを参照してほしい。

技術的負債の見抜き方 ── 経営者が聞くべき質問

技術的負債とは、短期的な都合で行われた設計・実装の「借金」が積み重なり、改修コストや障害リスクとして残っている状態を指す。ここが厄介なのは、決算書のどこにも載らないことである。見抜くには、技術者でなくても聞ける質問がいくつかある。

「このシステムに手を入れられる人は社内に何人いますか」。答えが一人なら、その人の退職リスクがそのまま事業リスクである。「最後に大きな機能追加をしたのはいつですか」。何年も前なら、触れなくなっている可能性を疑う。「仕様書やドキュメントは、いま入社した人が読んで分かる状態ですか」。属人化の度合いはここに表れる。「OSやミドルウェアのバージョンアップはどういう周期でやっていますか」。答えに詰まるなら、サポート切れの棚卸しから必要になる。

売り手側の経営者自身が自社のITの実態を把握していない、というのも中小M&Aでは普通のことだ。だから質問は経営者だけでなく、現場でシステムを触っている担当者に直接届ける必要がある。資料と現場の証言の食い違いこそ、DDで拾うべき情報である。

見つけた問題を、買収判断にどう反映するか

ITDDの成果は「問題リスト」ではなく、買収判断への反映で完結する。反映のルートは主に4つある。

第一に、価格への反映。老朽システムの刷新費用や、クラウド移行のコストが確実に発生するなら、それはバリュエーションの調整要因になる。第二に、契約への反映。ライセンス遵守やセキュリティインシデントの不存在について表明保証を求める、特定リスクに特別補償を付ける、といった手当てである。第三に、買収後の投資計画への反映。どうせ直すなら統合方針と合わせて設計したほうが安く済む。そして第四に、まれではあるがディールブレーカーの判定。事業の中核システムが再構築不能で、事業計画の前提が崩れる水準なら、見送る判断も要る。

大企業のカーブアウト案件であれば、親会社のシステムから切り出すための移行サービス契約（TSA）の設計もITDDの守備範囲に入ってくるが、中小M&Aでまず押さえるべきは上の4ルートである。いずれにも共通するのは、問題を「知った上で」値段と契約と計画に落とす、という一点だ。知らずに買うことだけが、避けるべき失敗である。

PMI・他のDDとの接続

ITDDで見た論点は、そのままPMI（買収後統合）の計画に引き継がれる。システム統合の方式——存続会社側に寄せるか、対象会社側を残すか、両方を刷新するか——は統合コストと期間を大きく左右し、DDの段階で当たりを付けておくべき論点である。

また、DDの構成要素は年々広がっている。ESG DDが標準セットに加わりつつある動き、中小案件で過剰にならない範囲のESGリスク評価の設計、そしてDD実務そのものへのAI活用——ITDDはこれらと並行して走る。AIによる資料読み込みでDDの網羅性が上がるほど、逆に「現場に足を運んで人に聞く」部分の価値が相対的に上がっている、というのが実感に近い。

DDの社会的意義 ── 会社は誰のものか

最後に、原点の話をしたい。会社は誰のものか、という問いがある。法律的・一義的には株主のものだろう。ただ、経営者や従業員、取引先、そして社会のものという側面を否定することもできない。

M&Aで所有者が変わるとき、影響を受けるのは株主だけではない。買収が失敗すれば、買った側では従業員が積み上げてきた利益が減損として消え、買われた側では働く人たちが混乱の中で苦労することになる。上場企業の開示を見れば、買収後の減損や業績悪化の例は枚挙にいとまがない。適切な会社を、適切な価格で、実態を知った上で買う——DDはそのための工程であり、単なる買い手のリスクヘッジを超えて、M&Aに関わる人たちを守る社会的な意味を持つと考えている。

よくある質問（FAQ）

Q. ITDDはどんなM&Aでも必要ですか。 事業がシステムに依存する度合いで濃淡を付けます。SaaS企業や受託開発会社の買収では中核工程ですが、システム依存の小さい事業でも、基幹業務が特定のソフトウェアや担当者に載っている場合は、最低限の確認を省くべきではありません。規模に応じた簡易版で実施する選択肢もあります。

Q. ITDDとBDD（ビジネスDD）はどう違いますか。 BDDは事業の実態と将来性を、ITDDはそれを支えるシステムと技術組織を見ます。実務では切り離せません。事業の強みがシステムに由来するのか、システムが事業の制約になっているのかは、両方を突き合わせて初めて判断できるためです。

Q. ITDDで重大な問題が見つかったら買収をやめるべきですか。 即中止となる例はむしろ少数です。多くは、改修・移行コストを買収価格に織り込む、表明保証や特別補償を契約に入れる、買収後の投資計画に組み込む、のいずれかで対処します。重要なのは、問題を「知った上で」値段と契約と計画に反映することです。

まとめ

ITDDは、対象会社のシステム・技術的負債・IT組織を調査し、買収判断に反映する工程である。財務・法務と違って定番の依頼先が見えにくいため後回しにされやすいが、ITの問題は買収後に請求書が届く。調査範囲は5領域——インフラ、アプリケーション資産、セキュリティ、契約・ライセンス、組織・属人性——で、見つけた問題は価格・契約・投資計画・ディールブレーカー判定の4ルートで判断に落とす。BDDと一体で見て、PMI計画へ引き継ぐところまでがITDDの仕事である。

ビジネスDD・ITDDの実施体制や依頼先の設計について外部の知見を必要とする場面では、当サイト運営元の株式会社KI Strategyへ相談を申し込むことができる。DD領域の詳しい解説はDD-AXのナレッジにもまとめている。

もしも本記事の論点について具体的にご相談されたいことがございましたら、お気軽にご連絡くださいませ。

本記事は2026年9月時点の情報をもとに、2026年1月公開の記事を全面改稿した。

#MA #ITDD #デューデリジェンス #経営戦略 #事業承継