【ITDD事例】開発会社を買う前に、技術の"中身"はここまで分かる ｜ テクカリ for ITDD・PMI

M&Aにおいて財務DD・法務DDはやって当たり前ですが、ITデューデリジェンス（ITDD）は「具体的に何をするのかイメージがわかない」と言われることがまだ多い領域です。

今回、当社がM&A実行支援会社様からのご依頼で担当した、受託開発企業のITDDの実例をもとに、どういう流れで、何を明らかにして、買い手の何に役立ったのかをご紹介します。

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

ITDDで何を評価し、見つけたリスクをどう買収判断やPMIにつなげるのか、進め方までを解説します。

テクカリ

案件の概要

登場するのは3社です（いずれも社名は非公開です）。

• 買い手: IT関連事業を展開する事業会社
• 対象会社（売り手）: 受託システム開発企業。少数の正社員と業務委託エンジニアで構成される開発体制
• 当社: M&A実行支援会社様からのご依頼でITDDパートを担当。財務・法務など他領域のDD専門家と連携

買収の狙いは、案件リードの相互送客・開発人材の連携・コスト圧縮といったグループシナジー。統合方針は「人事・文化はそのまま残し、最低限のガバナンスとセキュリティだけ揃える」というものでした。

ここでポイントになるのは、対象会社が自社プロダクト（ソフトウェア資産）を持っていないことです。つまり、ソフトウェア資産の価値を査定するDDではありません。見るべきは人材や開発体制、デリバリーの再現性、コスト構造。事業価値が人と仕組みにある会社で、受託開発・SES企業のM&Aでは一番よくあるパターンです。

エンジニアが見ると、どこまで深く確かめられるのか

人材や体制、コスト構造を見るのであれば、「それは財務・ビジネスDDの領域では？」と思われるかもしれません。実際、ITDDのすべてにエンジニアが必須というわけではありません。デプロイ頻度や離職率といった定量指標の確認や、経営者の説明に根拠があるか・課題を正直に語れているかといった観察は、エンジニアでなくても十分にできます。

ただし、面談で得られるのはあくまで経営者の説明のみです。たとえば業務委託中心の体制で品質が保てているのか、工数見積もりが仕組みとして機能しているのか属人的な勘なのか、AIを使った開発にどんなリスクがあるのか。この裏付けには、開発ドキュメントやGitHub、タスク管理ツールの運用実態、エンジニアのスキルセットまで踏み込んで、説明と実態のギャップを確かめる作業が必要になり、ここから先は開発の実務を知る人間でないと精度が出ません。

特にソフトウェア資産がない会社では、価値の中身が人と開発の仕組みそのものなので、説明と実態を突き合わせ、裏付けることがDDの本丸になります。

ITDDの流れ：約2週間・経営者ヒアリングは1時間

今回のDDは、キックオフからドラフトレポートの読み合わせまで約2週間。流れは次の5ステップです。

① 論点設計

最初にやるのはコードを読むことではなく、買い手の統合方針から逆算して、何を確認すべきかを決めることです。今回は、シナジーは本当に出るのか、買収後に何を整えるべきか、という問いを、キーパーソン依存・人材調達の仕組み・見積もりの精度・品質担保の実態・コスト構造・AI活用とセキュリティ、といった論点に分解しました。

② 資料分析とQ&A

確認すべき観点をQ&Aシートにまとめて対象会社へ送付し、開示資料（財務資料・営業データ・人材のスキルセット・技術ドキュメント等）とあわせて分析。資料で分かることは、この段階ですべて潰します。

③ 経営者ヒアリング（約1時間）

資料では分からないことだけを、対象会社の経営者に約1時間で聞き切ります。売り手は通常業務を回しながらDDに応じているため、負荷を最小限にする設計です。

④ 実データでの裏取り

ヒアリングの回答を鵜呑みにせず、実際の開発データを直接確認します。品質はこう担保している、という説明が実態と合っているか、説明にはなかったリスクが潜んでいないかを、開発の現場データで確かめます。

⑤ レポート・読み合わせ

調査結果を、買収の意思決定と、買収後にやるべきこととして整理し、依頼元と読み合わせて完成させます。

明らかにしたこと

レポートで買い手に提示した内容を、4つに要約してご紹介します。

1. 大きなリスクに見えたものが、実は限定的だった

DD開始時点で最大の懸念は、対象会社のCTOが退任していたことでした。しかし調査の結果、その役割は複数名にすでに分散して引き継がれており、事業への実影響は限定的と評価できました。「CTO退任」という字面のインパクトに引きずられて、過度なディスカウントや検討中止に向かうことを防げます。

2. 強みが「仕組み」として再現性を持つことを確認できた

対象会社には、精度の高い工数見積もりのフレームワークや、中間マージンのない人材調達モデルといった明確な強みがありました。これらが特定個人の職人芸ではなく仕組みとして機能していることを確認し、買収後も維持できること、さらに買い手側へ横展開できる可能性まで示しました。

3. シナジー仮説に、定量的な裏付けを与えた

財務・営業データの分析から、対象会社の最大の投資領域がリード獲得費であることを特定。買い手からの案件送客でこのコストを大きく圧縮できるという、買収の狙いそのものを裏付ける根拠を示しました。

4. 買収後に整えるべきラインを、具体的なToDoにした

一方で、セキュリティポリシーやAI利用ルールが未整備で個人のリテラシーに依存していること、コードレビューを必須としない運用によるAI生成コードのリスクなど、放置すべきでない事項も発見しました。ただし、これらは買収をやめる理由ではなく、PMI（買収後統合）の初期で対応すべき具体的なToDoとして整理しています。

何に役立ったのか

今回のITDDで買い手が持ち帰ったものを挙げると、

• 懸念事項が実際にどの程度の影響を持つのか
• 強みが買収後も維持・再現できるという裏付け
• シナジー仮説を支える定量的な根拠
• 買収後、最初に何から整えるべきかの優先順位

よくある「指摘事項のリスト」とはだいぶ性格が違って、「買うべきか」「買った後どう経営するか」の判断にそのまま使えるものです。

対象がIT企業・開発会社の場合、事業価値の大半は人と開発の仕組みにあります。ここは財務DDでは見えない部分で、「この会社の開発力は買収後も維持できるのか」という問いに答えを出すには、技術が分かる人間が中に入る必要があります。