買収前に技術組織をどう読むか——M&A担当者のための技術DD論点ガイド
「技術の話になるとついていけない」「CTOのプレゼンを聞いても本当のことを言っているかわからない」——M&Aのディールチームや事業開発担当が買収DDで感じる本音です。しかし技術的な深さがなくても、何を論点にすべきかを整理できれば 買収対象企業の技術組織の実力は見抜けます。
なぜ非エンジニアでも技術評価ができるのか
技術の品質は、コードの良し悪しよりも意思決定のパターンに現れます。優れた技術組織は「なぜその選択をしたか」を明確に説明できます。逆に危険な組織は、技術的な判断の根拠が「なんとなく」「流行っていたから」になりがちです。
つまり技術評価とは、「答えの正しさ」ではなく「思考プロセスの健全さ」を見ることです。この判断軸は、技術知識がなくても使えます。
面談前に確認すべき3つの定量指標
技術力の評価は面談の前から始まります。以下の指標は、口頭で説明を受ける前に確認できる客観データです。
1. デプロイ頻度
デプロイとは、開発者が書いたコードを実際にユーザーが使えるサービスとして公開・更新する作業です。プロダクトに新機能を追加したりバグを修正したりするたびに行われます。
デプロイを評価するときは、次の3つの観点を順番に確認してください。
① デプロイのライフサイクル（どのようなプロセスを経るか）
コードの変更が本番環境に反映されるまでの手順を確認します。自動テスト・コードレビュー・承認プロセスが整備されているかどうかが、技術組織の成熟度を映します。手動作業が多く、特定の担当者でなければデプロイできない状態は、属人化のリスクが高いです。
② リードタイム（コード変更から本番反映までの時間）
1つの変更が開発者の手元から実際のユーザーに届くまでの所要時間です。
| リードタイム | 評価 |
|---|---|
| 数時間〜1日 | 優秀。自動化が進んでいる |
| 2〜3日 | 許容範囲。レビュープロセスが機能している |
| 1週間超 | 要注意。承認の詰まりや手動作業の多さを疑う |
| 数週間〜 | 危険信号。プロセスが機能不全を起こしている |
③ デプロイ頻度（どのくらいの間隔で行うか）
リードタイムと組み合わせて評価します。リードタイムが短く、かつ高頻度なら理想的な状態です。なお、BtoCのコンシューマサービスとBtoBエンタープライズでは適切な頻度が異なるため、事業モデルと照らして解釈してください。
| 頻度 | 評価 |
|---|---|
| 毎日〜週複数回 | 健全。継続的な改善サイクルが機能している |
| 週1回 | 許容範囲。成長フェーズとして問題なし |
| 月1回以下 | 要注意。デプロイに恐怖感がある可能性 |
| 「大型リリース」のみ | 危険信号。技術的負債の蓄積が疑われる |
デプロイが怖い組織は、コードの品質に自信がなく、変更の影響範囲を把握できていないことを示しています。
2. エンジニア離職率
過去2年間で何名のエンジニアが退職したかを確認します。一般的にIT・ソフトウェア業界のエンジニア離職率は年15〜20%程度とされています（参考：米国Bureau of Labor Statistics「Job Openings and Labor Turnover Survey」、IPA「DX白書」等の各種業界調査より）。この水準を大幅に超え、年率30%を上回る場合は、技術組織に構造的な問題がある可能性があります。ただし、会社のフェーズ・規模・採用方針によって変動するため、数値単体でなく退職理由と合わせて確認することが重要です。
離職の理由として多いのは：
- 技術的負債が多くて生産性が低い（「直したくても直せない」）
- 意思決定が不透明で技術的な自律性がない
- CTOとの方向性のズレ
3. エンジニアの採用チャネルと採用率
求人に応募してきた候補者のうち、オファーを受諾した割合を確認します。優れた技術組織は、優秀なエンジニアから選ばれる企業です。優秀なエンジニアのネットワーク内での評判は、外部からは見えにくいですが、「どこで採用できているか」（リファラル比率が高いか）で間接的に確認できます。
面談で整理すべき4つの評価軸
面談では「答えの正しさ」よりも思考プロセスの健全さ を見ることが重要です。技術判断に根拠があるか、不確実性を正直に認められるか、課題を具体的に把握しているか——これらは技術知識なしでも観察できます。以下の4軸を念頭に置いて話を聞くと、論点が整理しやすくなります。
評価軸 1：技術的意思決定の質
技術選定・方向転換・課題認識の3点で判断します。
- 技術選定の根拠：使っている技術・ツールを選んだ理由が事業課題と結びついているか。「流行っているから」「自分が好きだから」という選定は、後の組織拡大時に負債になりやすい。
- 方向転換の経験：過去の失敗や大きな路線変更を具体的に話せるか。「うまくいっています」しか出てこないCTOは、課題を把握していないか、正直でないかのどちらかです。
- 現状課題の把握：「今すぐ直したい問題」を即座に挙げられるか。「特にない」という回答は認識不足のサインです。
評価軸 2：組織・プロセスの成熟度
技術組織の日常的な動き方を確認します。
- オンボーディング速度：新しいエンジニアが入社して初めてコードを本番に出すまでの日数。1〜2週間以内が目安で、1ヶ月を超える場合はドキュメントやプロセスの整備不足を疑います。
- インシデント対応：重大な障害をどう検知し、どう対処したか。「障害はない」という回答は、規模に照らして不自然でないか確認が必要です。対応の記録や振り返り（ポストモーテム）が習慣化しているかどうかが、組織の成熟度を映します。
- 技術リスクの経営への伝達：エンジニアが技術的な懸念を経営陣に伝えるルートが存在するか。「CTOが全部判断する」だけでは、現場のリスクが上に届かない構造になりやすいです。
評価軸 3：スケーラビリティへの備え
事業成長に技術が追いつける構造かどうかを確認します。
- ボトルネックの把握：ユーザー数・取引量が現状の10倍になった場合、どこが詰まるかを説明できるか。「大丈夫です」という根拠のない自信より、「ここが課題でこう対処する」という具体性が信頼の根拠になります。
- 外部依存リスク：決済・認証・インフラ等の外部サービスへの依存度と、各サービスが停止したときの影響を把握しているか。特定サービスへの過度な依存は事業継続リスクに直結します。
評価軸 4：技術への将来投資方針
成長局面で技術組織がどう機能するかを見ます。
- 技術投資の配分方針：買収後の技術投資をインフラ改善と機能開発にどう配分するつもりか。インフラ改善を後回しにし続ける組織は、成長とともに開発速度が鈍化します。
- 組織拡大の具体性：1年後の採用計画・組織構造・技術スタックの変化を連動させて語れるか。優れたCTOは3つの軸を切り離さずに考えています。
評価結果を買収判断とPMI方針に活かす
4軸の観察が終わったら、次のステップは結果を総合して判断に繋げることです。
判断の軸：個別の答えではなく全体のパターン
1つの回答で判断するのではなく、4軸を通じて浮かび上がるパターン全体を読みます。注目すべきは「何を知っているか」ではなく、「組織として自分たちの現状をどれだけ正確に把握しているか」 です。
強みと弱みの両方を具体的に語れる技術組織は、課題に対して打ち手を持っています。反対に、4軸すべてにわたって楽観的な回答しか出てこない場合は、課題の認識不足か、説明責任を持って話せていないかのどちらかです。どちらの場合も、買収後のPMIを難しくします。
ギャップが示す、PMI設計の切り口
評価で見えたギャップは、買収を見送る根拠にも、条件交渉の材料にもなりますが、買収後のPMI（統合計画）を設計する手がかり にもなります。
技術評価を「買収可否の判定」で終わらせるより、「どう支援すればこの組織は伸びるか」 の問いに転換することが、PMI後の価値創出に直結します。以下、4軸のギャップ別に具体的な打ち手とケースを整理します。
意思決定の質にギャップがある場合
主な打ち手
- 技術アドバイザー（フラクショナルCTO）を週1〜2日でアサインし、意思決定の根拠を構造化するプロセスを一緒に設計する
- ADR（Architecture Decision Records）など技術的意思決定の記録習慣を導入する
- 月次で買収側チームに「主要な技術判断とその根拠」を共有するルーティングを設定する
ケース例
面談でCTOが技術スタックの選定理由を「みんな使っているから」としか説明できなかった。クロージング後、外部技術アドバイザーとの週次1on1を設定。半年でADRが30本蓄積され、PMIレビューで技術選定の根拠を説明できるようになった。
組織・プロセスにギャップがある場合
主な打ち手
- EMの採用をクロージング後90日以内のPMI条件として設定する
- オンボーディングドキュメントの整備をマイルストーンに組み込む
- インシデント対応テンプレート（ポストモーテム）の導入をPMI支援として実施する
ケース例
新人エンジニアのオンボーディングが平均45日かかっており、リードエンジニアが対応を抱えていた。EM採用をPMI条件として設定し、採用後にオンボーディング体制を再設計。3ヶ月でオンボーディング期間が平均10日に短縮し、リードエンジニアが機能開発に戻れた。
スケーラビリティにギャップがある場合
主な打ち手
- 外部のアーキテクチャレビューをクロージング前に実施する
- ユーザー数・トランザクション量の成長シナリオ別にインフラコストを試算し、ボードで共有する
- スケールのボトルネックと対応状況をPMI会議の議題に設定する
ケース例
ユーザー10倍のシナリオを問うと「大丈夫です」という回答のみで根拠がなかった。追加DDとして外部技術専門家によるアーキテクチャレビューを実施。DBのN+1クエリ問題が判明し、パフォーマンス改善をクロージング条件のマイルストーンに追加した。
将来投資方針にギャップがある場合
主な打ち手
- 買収後の技術投資計画のうちインフラ改善への配分割合を買収条件として協議する
- 技術ロードマップを四半期ごとのボードレビュー項目に組み込む
- 技術的負債の可視化（スコアカード等）を半年ごとに実施し、開発速度の変化を追跡する
ケース例
買収後の技術投資計画を確認したところ、全額を機能開発に充てる予定だった。ボードで議論し、20%をレガシーコードのリファクタリングに充てるマイルストーンを設定。12ヶ月後、デプロイ頻度が月1回から週3回に改善した。
まとめ
技術の専門知識がなくても、論点を整理する視点があれば買収対象の技術組織の実力は評価できます。本稿のポイントを整理します：
- 定量指標から始める — デプロイのリードタイム・頻度・離職率・採用率は面談前に確認できる客観データ
- 4つの軸で論点を整理する — 意思決定の質・組織プロセス・スケーラビリティ・将来投資の方針
- 答えの内容より思考プロセスを見る — 不確実性を認められるか、根拠があるか
- 自己評価に限界を感じたら外部の専門家を使う — 技術が競合優位の核にある場合や複雑なシステムを抱える場合は外部技術DDが有効
お問い合わせから、具体的な評価方法についてご相談いただけます。