ITデューデリジェンスとは？M&Aで見落とされる技術リスクと、評価の進め方

ITデューデリジェンスとは？

M&AにおけるITデューデリジェンス（ITDD）とは、対象企業の技術や開発組織を、買収前に評価するプロセスです。財務DDや法務DDと並ぶ観点として、近年その重要性が高まっています。

DXの進展により、多くの企業がソフトウェアを事業に取り入れるようになりました。さらに生成AIの普及によって、ソフトウェアをつくるハードルも年々下がっています。

一方で、見た目は動いていても、保守性やセキュリティ、コスト構造まで十分に設計されていないシステムも増えています。そのため、ソフトウェアの品質やエンジニア組織の実態を確かめないまま買収するリスクは、これまで以上に大きくなっています。

実際、買収後になって初めて表面化する技術リスクは少なくありません。たとえば、特定のエンジニアしかシステムを理解しておらず、退任後に開発が進まなくなる。AIが生成したコードを十分にレビューせず運用しており、脆弱性や保守性に懸念が残る。技術負債が多く、改修コストが想定以上に膨らむ。

こうした問題は、PMIの段階で初めて発覚し、想定外のコストや遅延として跳ね返ってきます。

このようなリスクを買収前に可視化するのが、ITDDです。

ITDDで評価すること

ITDDでは、プロダクト、システム、開発プロセス、セキュリティ、エンジニア組織、契約やライセンス、コスト構造などを横断的に調査し、買収判断や統合計画に必要な粒度で評価します。

調査では、開示資料の確認をはじめ、経営者やCTO、現場のエンジニアへのヒアリングも行います。設計の背景や属人性、開発・運用の実態、資料に書かれている内容との整合性を確認しながら、技術判断の健全性や、買収後も継続して開発・運用できる体制があるかを見ていきます。

たとえば、技術負債があっても、事業の立ち上げ期にスピードを優先した結果であり、当時の状況を踏まえた合理的な判断であれば、直ちに大きなリスクとは限りません。一方で、現時点でシステムに大きな問題がなくても、特定のエンジニアに設計や運用の知識が集中していれば、その人物の離脱によって買収後の開発や運用に支障が出る可能性があります。

また、調査の重点は、M&Aの目的によって変わります。プロダクトそのものが事業価値の中心にある場合は、アーキテクチャや技術負債、リリース頻度、拡張性、買収後にどのような改修や統合が必要になるかが中心になります。エンジニア組織の獲得が目的であれば、人材構成や開発体制、キーパーソンへの依存度が中心になります。

見つけたリスクを、どう解決につなげるか

ITDDでは、見つかったリスクを、買収判断やPMIで扱える具体的な論点に落とし込みます。

リスクは、買収前に対応すべきもの、契約条件や買収価格に反映すべきもの、買収後の改善計画に組み込むものに整理します。そのうえで、影響範囲、対応コスト、優先順位を明確にし、クロージング前の是正事項やPMI計画に反映できる形にします。

また、ITDDではリスクへの対応だけでなく、対象企業の技術や開発組織の強みをどう活かすかも整理します。買収後にどのような支援や改善があれば、より価値を発揮できるのかまで見ておくことで、PMI後の価値創出につなげやすくなります。

ITDDの進め方

一般的には、次の流れで進みます。

1. 関係者で評価の目的と論点を整理する
2. 開示資料リストとQ&Aリストを送付する
3. 開示資料を確認する
4. 経営陣やCTOへヒアリングを実施する
5. リスクと改善余地をレポートにまとめる

中でも、最初に関係者と論点を擦り合わせておくことが重要です。論点を絞れば、簡易的なITDDで足りる場面もあります。たとえば、統合によるコスト削減の余地や、セキュリティの最低ラインを確認するだけであれば、短期間・低コストで実施することも可能です。