テクニカル DD の
進め方と評価観点。

M&A の成否を分けるのは、財務 DD でも法務 DD でもなく、テクニカル DD であるケースが増えています。買収で価値を毀損した企業ほど、IT・テクノロジーの統合計画を欠いていたと指摘されています[1]。AI・SaaS 時代の M&A では、技術評価の比重がさらに高まると考えて臨むべきです。テクニカル DD を依頼する側（買い手・PE・VC）が押さえるべき進め方と評価観点を、Kmetric が実際の DD で使っているフレームワークに沿ってまとめます。

1. テクニカル DD は何を見ているか

テクニカル DD（Technology Due Diligence）は、買収・投資対象企業の技術資産・技術的負債・組織能力を体系的に評価するプロセスです。技術的負債とは、先送りにしてきた設計の見直しや修正が積み残っている状態を指します。財務 DD が数字の裏付けを、法務 DD が契約の中身を確認するのに対し、テクニカル DD は「買収後もプロダクトを同じ品質で動かし続けられるか」「買い手のシステムや組織と統合できるか」を確かめます。

主な目的

• 買収後に必要な追加投資額の見積もり
• 技術リスク（セキュリティ・拡張性・外部サービスへの依存）の特定
• 買収後の統合計画（PMI）に必要な前提情報の整理
• 買収価格の妥当性の検証
• クロージング条件の根拠づくり

費用と価値

テクニカル DD の費用は、取引金額からすればわずかな割合にとどまります。一方、DD で見抜けなかった技術的負債やシステム統合の問題は、買収後に想定外の追加投資となって表面化する可能性があります[2]。その損失と比べれば、DD にかける費用は十分に見合います。

2. 5つの評価観点

Kmetric がテクニカル DD で標準的に評価する5つの観点です。実際の DD レポートもこの構成で書いています。

2.1 システム全体の設計（アーキテクチャ）

対象企業のシステム全体を見渡し、設計に無理がないか、拡張しやすいか、買い手のシステムと統合しやすいかを評価します。具体的には、システムを機能ごとに小さく分けた構成（マイクロサービス）か、一つの大きな構成かを見ます。あわせて、外部サービスへの依存が一部のサービスに集中していないか、特定のクラウド事業者にどこまで頼っているかを確認します。データの流れを全体として追えるか、開発・検証・本番の環境がきちんと分かれているかも見ます。ここで得た情報が、買い手のシステムとの統合シナリオを描く出発点になります。

2.2 コードの品質

ソースコードの健全性を数字で測ります。主な指標は、自動チェックツールによる検査スコア、テストカバレッジ（自動テストで確認できているコードの割合）、コードの複雑さ、重複したコードの割合、サポートが終了した外部ライブラリの数です。

2.3 セキュリティ

買収後の事業継続に直結するため、特に重視する領域です。まず、よく狙われる脆弱性への対策状況を、業界標準の指針である OWASP Top 10 に照らして確認します。そのうえで、ログインと権限管理（シングルサインオン・多要素認証など）の実装品質、データの暗号化、パスワードや API キーなど機密情報の管理、過去のセキュリティ事故の履歴を見ます。法令や外部認証への対応（GDPR・個人情報保護法・セキュリティ認証の SOC2 など）も確認します。

2.4 拡張性

買収後の事業の成長に、今の設計が耐えられるかを評価します。まず、現在のアクセス規模に対して処理能力にどれだけ余裕があるか、事業が3〜5倍に伸びたときにどこで性能が頭打ちになるかを見ます。あわせて、データベース設計の限界、データの一括処理にかかる時間、利用拡大に伴うインフラ費用の増え方も確認します。

2.5 属人化リスク

特定の人に頼らず開発を続けられるかを見る観点です。実務では、コードの品質以上に重視されます。「このリーダーが辞めたら何が止まるか」は必ず確認します。具体的には、担当者一人が抜けたときに止まる業務の範囲、設計の意図が後任に引き継がれているか、運用手順書の品質、新しいメンバーが戦力になるまでの期間、採用計画と組織計画を見ます。

3. DD は何週間かかるか

標準的なテクニカル DD の流れを整理します。Big4 系の標準工程が4〜8週間であるのに対して、Kmetric は2〜4週間で完了させます。期間の差は、調査範囲の違いから生まれます。Big4 系はガバナンスまで含めて幅広く見る総合 DD で、Kmetric はソースコードとシステム構成に絞って深く掘り下げる DD です。以下の週数は、4週間で進める場合の目安です。

フェーズ1：調査範囲の確定（1〜2週目）

• キックオフの実施と NDA（秘密保持契約）の締結
• 資料の依頼（Q&A シートの送付）
• 主要メンバーへのインタビューの設計
• 評価フレームワークの選定（5つの観点の重み付け）

フェーズ2：詳細評価（2〜4週目）

• ソースコードへのアクセスと、自動チェックツールによる検査
• アーキテクチャのレビュー会
• セキュリティ評価（リモートでの診断と、必要に応じた現地調査）
• 主要メンバーとの個別面談（CTO・開発リーダー・運用責任者）
• ソフトウェアのライセンスとコンプライアンスの監査

フェーズ3：レポート作成（最終週）

• リスクマップの作成（Critical・High・Medium・Low）
• 統合シナリオの提案
• 追加投資の見積もり
• クロージング前提条件の提案
• クライアントへの報告会

4. レポートの構成とリスクマップ

テクニカル DD の中心となる成果物は、経営層向けに要点を絞ったリスクマップです。見つかったリスクをすべて4段階に分類し、価格交渉の根拠としてそのまま使える形に仕上げます。

レポートは通常、次の順で構成します。経営層向けサマリー（1〜2ページ、CEO・CFO が読む想定）、5つの観点ごとの詳細評価、リスクマップ、追加投資の見積もり、統合シナリオの提案、クロージング条件への反映案、付録です。

5. 見つけたリスクを対処計画につなげる

DD の報告は、見つけたリスクに統合後の対処計画を添えてはじめて、買い手が次の手を打てる材料になります。典型的な対処は、クロージング前に行うセキュリティ上の重大な脆弱性の修正、主要メンバーの引き留め計画、6〜12ヶ月かけて技術基盤を統合するロードマップ、ドキュメントの整備計画、採用と組織再編の計画の5つです。

6. Big4 と専門ファームの比較

Big4（PwC、KPMG、Deloitte、EY）もテクニカル DD を提供しています。Kmetric のような専門ファームとは得意領域が違うため、案件の性質に応じて使い分けたり、両者を並行して起用したりするのが効果的です。

規模が大きいディールや、複数の領域にまたがるディールでは、Big4 と専門ファームの2社で分担する体制が有効です。Big4 がガバナンスと統制プロセスを、専門ファームがシステム構成とソースコードを評価します。詳しくは Big4・専門ファーム・受託会社 — テクニカル DD の発注先の選び方をご参照ください。

7. Kmetric ができること

Kmetric はテクニカル DD を、買い手側・売り手側の両方の立場で提供するエンジニアリングスタジオです。

提供範囲

• フェーズ1：調査範囲の確定（1〜2週目）
• フェーズ2：詳細評価（2〜4週目、5つの観点をすべて評価）
• フェーズ3：レポート作成（最終週、経営層向けと詳細版）

成果物

• リスクマップ（Critical・High・Medium・Low）
• 統合後の対処計画
• 追加投資の見積もり
• クロージング前提条件の提案
• 投資判断に向けた提言

売り手側の準備については、売却価格を技術で守る — Exit 前に進める M&A 技術整備の実務ガイドで解説しています。買い手がどこを見るかを踏まえて、売り手が事前に押さえておくべき点を整理した記事です。