買収したプロダクトの技術状態を診断する観点
「買収は成立したが、プロダクトの中身が本当に大丈夫か分からないまま統合作業が始まった」というご相談をよく受けます。事業DD（財務・法務・ビジネスモデル）は精緻にやったのに、技術DDは「動いているようです」の一言で済ませてしまい、クロージング後に負債の実態が発覚するパターンです。
技術は財務諸表に出てきません。動いているコードの中に何年分の借金が埋まっているかは、外から見ただけでは分からないという性質があります。この記事では、買収前・買収後それぞれの技術診断で見るべき観点と、統合の進め方を整理します。
なぜ技術DDが甘くなりがちか
事業買収のDDは会計士・弁護士が担当することが多く、技術は「エンジニアがいれば大丈夫だろう」で済まされがちです。しかし技術的負債は財務諸表に載らない負債で、買収後に初めて顕在化します。
- 売り手側のエンジニアは「引き継ぎがうまくいってほしい」動機があり、問題点を積極的には出さない
- 買い手側に技術責任者がいても、短期間で他社のコードベースを評価するのは専門外の作業
- ソースコードを見せてもらえるのはクロージング直前、期間は数日〜1週間ということが多い
この非対称性のせいで、「動いている画面を見て、開発者に質問して終わり」という表層的な確認になりやすいのが実情です。
買収前の診断：短期間で何を見るか
クロージング前は時間もアクセス権も限られます。優先順位をつけて確認すべきは以下です。
1. ソースコードの実在と完全性
意外と見落とされるのが「本当に全部のコードがあるか」です。外部委託先が持っている部分、退職者の個人環境にしかないスクリプト、ビルド時にしか生成されない設定ファイルなどが抜け落ちていないかを確認します。git log の最終コミット日と本番の稼働バージョンが一致しているかも要チェックです。
2. 依存ライブラリとフレームワークのEOL状況
Gemfile.lock や package-lock.json（あるいは同等のロックファイル）を提出させ、主要フレームワークがサポート切れ（EOL）にどれだけ近いかを機械的に確認します。目安として、フレームワークのメジャーバージョンがリリースから3年以上経過している、あるいは既にEOLを迎えている場合は、統合後1〜2年以内に強制的なアップグレードコストが発生すると見ておくべきです。
3. インフラの所有権
ドメイン、SSL証明書、クラウドアカウント（AWS/GCP等）の請求先、外部API（決済・地図・AI等）の契約主体が「誰の名義か」を確認します。これが売り手個人や別会社名義になっていると、統合後に権限移管が滞りサービス停止リスクになります。実際、この確認を怠りクロージング後にAWSアカウントへのアクセス権を売り手が渡さず、1ヶ月近く運用が止まったケースもあります。
4. キーパーソン依存度
「このプロダクトを本当に理解している人は誰か」を特定します。CTOや主要エンジニアが買収後も残留する契約になっているか、残留しない場合はその人物以外に仕様を説明できる人がいるかを確認します。属人化の度合いは、ドキュメントの有無だけでなく「その人が抜けたら何が止まるか」で測ります。
5. ライセンスと知財
OSSライセンス（GPL系など商用利用に制約のあるものが混入していないか）、外部ベンダーとの契約でコードの著作権がどちらに帰属するか、外注先が作った部分の権利関係が整理されているかを確認します。この点は法務DDと連携が必須です。
短期間の技術DDでは、コードを1行ずつ読む時間はありません。「壊れたら事業が止まるものは何か」を先に特定し、そこだけ重点的に見るのが現実的なアプローチです。
買収後の診断：統合前提での棚卸し
クロージング後はアクセス権が全面的に得られるため、より深い診断が可能になります。ここでの目的は「統合計画を立てられる粒度でリスクを可視化する」ことです。
- コードの構造: 変更の影響範囲が予測できる作りか、1つの変更が広範囲に波及する密結合な設計か
- テストカバレッジ: テストがあるか、あるならCIで実際に通っているか。「昔書いたが今は失敗し続けている」テストは実質ゼロカバレッジと同じ
- セキュリティ: 既知の脆弱性を含む依存バージョンで固定されていないか（
bundle auditやnpm auditで機械的に検出可能）、認証・認可の実装に穴がないか - 運用体制: デプロイが自動化されているか、それとも「担当者が手でSSHして再起動」の属人運用か。障害時のアラート・監視体制の有無
- データ: 顧客データの保存形式・暗号化状況、既存システムとのデータ連携方式（統合するシステムがある場合、スキーマの互換性）
買収後診断のアウトプットは「問題リスト」ではなく、「統合ロードマップに落とし込める優先順位付きリスク一覧」であるべきです。「このリスクは統合の何ヶ月目までに対処しないと事業影響が出るか」まで踏み込んで初めて、経営判断の材料になります。
リスクの棚卸しと優先順位のつけ方
診断で出てきたリスクは、影響度と対処コストの2軸で整理します。
- 即時対応（統合前〜統合直後）: セキュリティの重大な脆弱性、インフラ所有権の未移管、EOL間近のフレームワークで既に脆弱性報告がある場合
- 中期対応（統合後3〜6ヶ月）: キーパーソン依存の解消（ドキュメント化・ペアでの引き継ぎ）、テストのない主要機能への回帰テスト追加
- 長期対応（統合後6ヶ月〜1年）: フレームワークのメジャーアップグレード、密結合な設計の段階的な整理
ここで陥りがちな失敗が「全部を統合直後に一気に直そうとする」ことです。事業を止めずに統合を進める以上、機能開発を止めて技術的負債の解消だけに専念する期間を長く取るのは現実的ではありません。業務影響のあるリスクだけ先に潰し、それ以外は通常の開発サイクルに織り込みながら段階的に返済する方針が、買収後統合では機能します。
外部の第三者診断を入れる価値
技術DDを社内の技術者だけで完結させようとすると、2つの限界にぶつかります。1つは、買い手側の技術者が売り手のコードベースを短期間で正確に評価するスキルセットは、実は「新しいプロダクトを作る」スキルとは別物であること。もう1つは、社内政治的な力学（M&Aを推進したい側の圧力、統合後の人間関係への配慮）が診断の結論を歪めるリスクがあることです。
第三者の技術診断チームを入れる価値は、この2点への対処にあります。利害関係のない立場でコードとインフラを評価し、統合可否や統合コストの見積もりに使える資料を出すことができます。特に、買収候補が複数ある場合の比較評価や、経営陣への説明資料としてのアウトプットが必要な場面では、外部診断のほうが説得力を持ちます。
torcheees では、買収前後どちらのタイミングでも技術診断をお受けしています。買収前は限られたアクセス権の中での短期集中診断、買収後は統合ロードマップに落とし込める詳細診断と、状況に応じて診断の深さを調整します。実装力を持つチームが診断するため、「直すとしたらどれくらいの工数・費用か」まで具体的な見積もりとして提示できるのも特徴です。モダナイゼーションや開発コンサルティングのサービスとして提供しています。
既存プロダクトの改善全般の考え方は 既存プロダクトの改善、外部チームが最初に見る観点 で、事業譲渡・引き継ぎで得たSaaSのロードマップ立て直しについては 引き継いだSaaSのロードマップを立て直す でそれぞれ詳しく解説しています。
まとめ
- 技術的負債は財務諸表に載らない負債であり、買収前の短期DDでは「壊れたら事業が止まるもの」に絞って重点的に確認する
- 買収後の診断は統合ロードマップに落とし込める粒度でリスクを棚卸しし、即時・中期・長期に優先順位をつけて段階的に返済する
- 社内の技術者だけでは評価スキルや社内力学の面で限界があり、利害関係のない第三者診断が統合判断の材料として有効
買収したプロダクトの技術状態に不安がある、あるいはこれから買収を検討していて技術DDの体制を組みたいという場合、torcheees では技術診断から、その後の継続的な改善支援まで一貫してご相談いただけます。お問い合わせフォームからお気軽にご連絡ください。