売却価格を、
技術で守る。

M&A の成否を最終的に左右するのは、しばしば「技術」です。買収で価値を毀損した企業の多くが、IT・テクノロジーの統合計画を欠いていたと指摘されています[1]。買い手が技術統合のリスクを重く見るほど、技術面の不安は売却価格の減額に結びつきます。裏を返せば、売り手が事前に技術面を整えておけば、減額の幅を一定程度小さくできるということです。

本稿は、買い手 DD が始まる6ヶ月前から進める、減額を防ぐための「守り」⁠の実務手順です。これと対になるのが「攻め」の設計です。CTO 代行（フラクショナル CTO：非常勤で関わる社外の CTO）を据えて18ヶ月以上かけ、技術投資で売却価値そのものを継続的に高めます。詳しくはフラクショナル CTO がプロダクト価値を引き上げる5つの領域 — Exit に効く技術投資の優先順位で整理しています。

1. なぜ売却価格は技術で削られるのか

買い手は M&A の DD で、技術リスクを掘り下げます。その結果は投資判断の根拠になり、同時に価格交渉の武器にもなります。実務でよく出る指摘は、次の7つに集約されます。

買い手 DD で見つかる7つの典型的な指摘

1. アーキテクチャ（システム全体の設計）の硬直性 — 全体が一体化していて一部だけを直せない構造、テストしにくい設計、機能を足すたびに開発コストが膨らんでいく兆候
2. 技術的負債の把握不足 — 後回しにしてきた「直したい場所」が暗黙知のままで、優先度や影響度が経営者にも開発リーダーにも見えない状態
3. 属人化リスク — 1〜2名の退職で開発が止まるリスク、設計意図がコードにしか書かれていない状態
4. セキュリティ・脆弱性 — すでに公表されている脆弱性（セキュリティ上の弱点）への未対応、ログインや権限管理の弱さ、暗号化の不備
5. 拡張性の限界 — 現在のユーザー数の3〜5倍を想定したときに見えてくるボトルネック
6. ライセンス・コンプライアンスの問題 — ソースコードの公開義務を伴うオープンソースライセンス（GPL 系）の混入、商用利用範囲の不明瞭さ、SaaS 利用規約違反
7. テストカバレッジ（自動テストで確認できている範囲）の不足 — 主要な機能に自動テストがなく、改修で既存の機能が壊れても気づけない状態

これらは、買い手が「買収後に追加投資が必要」だと判断する根拠になり、そのまま買収価格の交渉に使われます。深刻度が「Critical（もっとも高い）」「High（高い）」に分類されるリスクが、十数項目見つかることも珍しくありません。それだけの指摘が並べば、買い手は強い立場で値下げを求められます。売り手から見れば、その値下げ分は、事前にリスクを潰しておけば守れたはずの金額です。

2. DD 開始までの6ヶ月を、逆算で組む

売却プロセスは、多くの場合6〜12ヶ月かかります。技術整備のスケジュールを売却時期から逆算して組めるかどうかで、価格交渉での立場が変わります。Kmetric が推奨する標準タイムラインを、1枚の表にまとめました。表の「◯ヶ月前」は、買い手の DD が始まる時点から数えた目安です。

6ヶ月前：自己 DD と棚卸し

買い手が DD で確認するであろう項目を、先に自社ですべて点検します。Kmetric ではこの段階を「Exit 前監査」と呼び、2〜4週間の集中作業で進めます。点検の観点は、システム全体の設計（アーキテクチャ）、コードの品質、セキュリティ、拡張性、属人化リスクの5つです。

3ヶ月前：修正とドキュメント整備

リスクマップに沿って、Critical と High のリスクから順に対処します。主な作業は、緊急度の高い脆弱性の修正、アーキテクチャ上の致命的な箇所のコード整理（リファクタリング）、ドキュメントがない領域の整備、テストカバレッジの底上げです。目安として、3ヶ月集中して取り組めば、技術的負債の指標やテストカバレッジを実用に耐える水準まで引き上げられます。

1ヶ月前：監査資料のとりまとめ

買い手に提示する自己 DD レポートを作成します。アーキテクチャ図、技術スタック（使っている言語や製品）の一覧、依存関係マップ、セキュリティポリシー、インシデント履歴、開発プロセスと組織図を含めます。買い手の DD が始まる前に提示しておくと、交渉の主導権を取りやすくなります。

DD 期間中：質問対応と回答準備

DD 期間中は、買い手からの質問に速く的確に答えられるかどうかで、信頼が大きく変わります。質問が来てから慌てて整理せずに済むよう、想定 Q&A 集を事前に用意しておきます。

3. 負債は全部直さない — 価格交渉に効く部分を選ぶ

技術的負債の解消では、コードをやみくもに整理するより、価格交渉に効く部分を選んで集中的に投資するほうが、限られた期間で成果が出ます。進め方は3段階です。負債を見える化し、許容できる負債と価格を削る負債を区別したうえで、対処の優先度を付けます。

技術的負債の見える化

まず、コードの品質を機械的に測る解析ツールで、コード全体を調べます。処理が複雑すぎる箇所、コードの重複率、テストカバレッジ、セキュリティ上の要注意箇所、手を入れにくいファイルを、数値で把握できます。買い手はこの解析結果そのものを見たがるので、自社で解析して先に提示しておくのが理想です。

「許容できる負債」と「価格を削る負債」の区別

区別の目安は4つです。めったに触らない部分の負債は、安定して動いていれば許容できます。一方、頻繁に手を入れる部分の負債は、優先して減らします。セキュリティに関わる負債は、すぐに修正します。アーキテクチャ全体に響く構造的な負債は、段階的に減らします。最初の1つが「許容できる負債」、残りの3つが「価格を削る負債」にあたります。

対処の優先度の付け方

Kmetric が現場で使うのは、対処にかかるコストと、価格交渉へのインパクト（影響の大きさ）の2軸で、負債を4つに分ける整理法です。それぞれの高低の組み合わせで、対処の優先度を決めます。

4. 属人化リスク — 買い手が警戒する「人」への依存

買い手が技術面で特に警戒するのは、コードよりも「人」⁠です。DD では、「このリーダーが辞めたら何が止まるか」が必ずといってよいほど問われます。

属人化リスクの評価方法

• 属人化の度合い：チームの何人が同時に抜けるとプロダクトが立ち行かなくなるか
• 設計意図の継承：アーキテクチャに関する主な判断の背景が、コード以外（ドキュメントや設計レビューの記録）に残っているか
• 運用の対応力：特定の1〜2名以外のメンバーでも、本番運用に対応できるか
• 新メンバーの立ち上がり期間：経験の浅いメンバーが戦力になるまでの平均日数

知識の引き継ぎとドキュメント化

整備するドキュメントの典型は4つです。主要な機能ごとの設計判断の記録（ADR）、運用手順書（障害対応・本番環境への反映・不具合が出たときに元の状態へ戻す方法）、データ構造の解説、外部依存先の連絡先と契約条件です。これらを社内で共有できる場所に集約し、新しく入ったメンバーが1週間でシステムの70%を理解できる状態を目指します。

属人化リスクの改善

属人化リスクを下げる打ち手は4つあります。設計や実装を複数人で進める習慣をつくること、コードレビューを必ず複数人で行うこと、主要機能の担当を定期的に入れ替えること、そして採用によって特定の人に頼らない体制を整えることです。

5. ドキュメント整備 — 監査資料の作り方

買い手から「ドキュメントを見せてください」と言われたときに出すべきものは、ほぼ決まっています。次の6種を DD 前に整えておくことで、交渉を有利に進められます。

必須ドキュメント6種

1. アーキテクチャ図 — システム全体、主要な構成要素、各要素の内部という3段階で描いた構成図（C4 model の上位3階層に相当）
2. 技術スタック一覧 — 画面側・サーバー側・インフラ・運用のすべての層で使っている技術と、その選定理由
3. 依存関係マップ — 主要な機能どうしの呼び出し関係と、外部 SaaS との連携
4. セキュリティポリシー — ログインと権限管理、データの暗号化、操作記録（ログ）の管理、脆弱性への対応手順
5. インシデント履歴 — 過去12〜24ヶ月の重大障害と、その根本原因分析（RCA）
6. 自己 DD レポート — 上記すべてをまとめた、買い手向けの説明資料

ドキュメントの品質基準

品質の目安は4点です。まず、曖昧な表現を避け、誰が読んでも同じ理解になるように書きます。図と文章の割合は、おおむね3対7にします。各文書には最終更新日を明記し、用語は文書全体で統一します。

6. セキュリティ — 1件でも価格を大きく削る要因の潰し方

セキュリティの問題は、1件でも売却価格を大きく削る要因になりえます。事前の対応は、自社での脆弱性診断、リスクの分類、外部の侵入テストの順に進めます。

自社での脆弱性診断

外部の診断会社に頼む前に、まず自社で診断します。主な内容は、外部ライブラリの脆弱性を自動で監視する仕組みの導入、Web アプリの代表的な脆弱性をまとめたチェックリスト（OWASP Top 10）による点検、ログインと権限管理の流れの見直しです。

リスクの分類（深刻度と業務への影響度）

発見した脆弱性は、CVSS スコア（脆弱性の深刻度を0〜10で表す業界共通の指標）[2]⁠で4段階に分け、そこに業務への影響度を加味して対応の優先度を決めます。下の表は、CVSS スコアによる目安です。

侵入テスト（ペネトレーションテスト）の活用

可能であれば、外部のセキュリティ会社に侵入テスト（攻撃者の視点で、実際にシステムへの侵入を試みる検査）を依頼し、発見された問題をすべて修正した状態で買い手に提示するのが理想です。費用は数十万円〜数百万円ですが、案件によっては、買収価格を数千万円〜億円単位で守ることにもつながります。

7. 価格交渉で使える自己 DD レポート

DD 後の価格交渉に向けて、技術面の強みや買収後の伸びしろ（アップサイド）⁠を説明できる材料を用意します。その中心になるのが、1ヶ月前に作成する自己 DD レポートです。

自己 DD レポートの構成

• エグゼクティブサマリー（経営者向け、A4 で1ページ）
• アーキテクチャの全体像
• 技術資産の詳細（コードの行数、テストカバレッジ、利用している外部ライブラリの数などの定量データ）
• リスクのある領域の正直な開示と、対処の状況
• 統合シナリオの提案（買い手のシステムとどう統合するか）

交渉力を生む情報の出し方

問題は隠さずに開示し、そのうえで対処計画を必ず添えます。説明は数値で行い、抽象的な表現は避けます。DD で出そうな質問への回答は、2章で触れた想定 Q&A 集にまとめておきます。

統合後の価値提案

「買収後にこういう統合ができます」という提案を技術側から出せると、買い手の評価は上がりやすくなります。たとえば、買い手の SaaS との統合シナリオ、データをどう統合するかの方針、買収後にチームが合流するときの受け入れ計画などです。

8. Kmetric の M&A 売却準備

Kmetric はテクニカル DD を買い手側・売り手側の両方で提供する、技術 M&A の専門ファームです。買い手側の DD で得た知見を売り手側の準備に生かせるので、DD の現場で何が確認されるかを踏まえて対策できます。

提供範囲

• フェーズ1：評価（2〜4週間） — 自己 DD の実施、リスクマップの作成
• フェーズ2：整備（1〜3ヶ月） — 優先度の高いリスクから対処
• フェーズ3：資料のとりまとめ（2〜4週間） — 自己 DD レポートの作成、想定 Q&A の整備

成果物

• リスクマップ（Critical・High・Medium・Low）
• 整備計画書（タイムライン、コスト、優先度）
• 自己 DD レポート（買い手への提示用）
• 統合シナリオの提案（オプション）

期待効果

• 買い手 DD による減額の縮小（事業の特性によって差はありますが、減額幅を30〜50%縮めることを目安にしています）
• DD 期間の短縮（買い手の作業負担が減り、信頼も得やすくなるため）
• 価格交渉での主導権の獲得