テック・デューデリジェンスの要点

「このソースコード、著作権は御社にありますよね？」

M&Aのテック・デューデリジェンス（技術査定）で、この質問に即答できないと、大きな問題になります。「たぶん…」「外注先に確認します」という回答は、買い手にとって レッドフラグ（警戒信号） です。

編集部がM&Aアドバイザー 6名 にヒアリングしたところ、 「技術DDで重大な問題が発覚した案件」 は、過去3年間で 38% に上りました。そのうち 15% は、問題が解消できず 破談 となっています。

本記事では、M&Aを視野に入れた経営者が、 テック・デューデリジェンス に備え、技術資産の権利関係をクリアにするための方法を解説します。

オープンソースライセンス違反のリスクチェック

オープンソースとライセンス

オープンソースソフトウェア（OSS） とは、ソースコードが公開され、自由に利用・改変・再配布できるソフトウェアのことです。ただし、 「自由」には条件 があります。それが ライセンス です。

代表的なOSSライセンス:

ライセンス	条件	リスクレベル
MIT	著作権表示を残せば自由	低
Apache 2.0	著作権表示 + 変更点の明示	低
BSD	著作権表示を残せば自由	低
GPL	派生物も同じライセンスで公開（コピーレフト）	高
LGPL	ライブラリとしての利用は緩和	中
AGPL	ネットワーク経由でも公開義務	最高

GPLライセンス違反の深刻さ

GPLライセンスは 「コピーレフト」 という条項を持ちます。GPLのソフトウェアを利用した場合、 自社のソフトウェアもGPLで公開する義務 が生じます。

違反した場合:

• 自社コードの 全公開を求められる 可能性
• 著作権者から 訴訟 を起こされる可能性
• M&Aにおいて 「知的財産リスク」 として大幅減額

実際の事例（海外）: 大手企業がGPL違反を指摘され、訴訟に発展。最終的に 和解金として数億円 を支払い、コードを公開することになった事例があります。

ライセンス違反のチェック方法

自社システムにOSSライセンス違反がないかチェックする方法です。

①使用OSSの棚卸し

• システムに含まれる全OSSをリスト化
• 各OSSのライセンスを特定
• GPL系（GPL, LGPL, AGPL）の有無を確認

②ライセンス条件の確認

• 各ライセンスの条件を確認
• 条件を満たしているか検証
• 違反の可能性がある箇所を特定

③ツールによる自動チェック

ツール	特徴	費用
FOSSA	商用、高精度	有料
Snyk	脆弱性チェックも可能	無料〜有料
WhiteSource	大規模対応	有料
FOSSology	OSS、無料	無料

開発委託先との契約における著作権帰属の確認

著作権帰属の重要性

システム開発を外注（業務委託）した場合、 著作権の帰属 が問題になります。

原則:

• 著作権は 「創作した者」 に帰属する
• 外注先が開発した場合、 外注先 に著作権がある
• 自社に帰属させるには、 契約で明記 する必要がある

著作権帰属のパターン

開発委託における著作権帰属のパターンです。

パターン	契約内容	M&Aへの影響
自社帰属（明記）	「著作権は甲（発注者）に帰属」と明記	問題なし
共同保有	「著作権は甲乙の共有」と明記	減額要因
外注先帰属	「著作権は乙（受注者）に帰属」または記載なし	重大リスク
不明確	著作権に関する記載なし	重大リスク

著作権が不明確な場合のリスク

著作権の帰属が不明確な場合のM&Aへの影響です。

リスク1: 使用権の問題

• 外注先が「使用を認めない」と主張する可能性
• M&A後の継続利用に支障

リスク2: 買い手への移転ができない

• 自社に著作権がなければ、買い手に移転できない
• 「技術資産」としての価値がゼロ

リスク3: 減額交渉の材料に

• 買い手は「著作権リスク」として減額を要求
• 10〜20% の減額が一般的

著作権の確認と整備

著作権を確認し、整備するためのステップです。

Step 1: 契約書の確認

• 過去の開発委託契約書を全て収集
• 著作権に関する条項を確認
• 「帰属が不明確」な契約をリスト化

Step 2: 外注先との交渉

• 帰属が不明確な場合、外注先と協議
• 「著作権譲渡契約」を締結
• 必要に応じて、譲渡対価を支払う

Step 3: 今後の契約の見直し

• 新規の開発委託契約では、著作権帰属を明記
• 「著作権は発注者に帰属」を標準条項に
• 契約書テンプレートを整備

キーエンジニアへのヒアリング対策と引き留め策

キーマンリスクとは

M&Aにおいて、 キーマンリスク（キーパーソンリスク） は重大な問題です。特に、システムの設計・運用を担う キーエンジニア の存在は、技術資産の価値を大きく左右します。

キーエンジニアがいなくなると:

• システムの運用・保守ができなくなる
• 障害発生時の対応ができなくなる
• 改修・機能追加ができなくなる
• 結果: 技術資産の価値が大幅に下がる

買い手がキーエンジニアに求めること

M&Aにおいて、買い手がキーエンジニアに求めることです。

確認項目	目的
在籍意向	M&A後も継続して働く意向があるか
技術理解度	システムをどの程度理解しているか
属人性	この人がいないと運用できないか
引継ぎ可能性	他者に引き継げるか

キーエンジニアへのヒアリング対策

テック・デューデリジェンスでは、買い手がキーエンジニアに 直接ヒアリング することがあります。その対策です。

①事前説明

• M&Aの可能性について事前に説明（タイミングは要検討）
• 買い手からのヒアリングがあることを伝える
• 回答すべき内容、避けるべき内容を共有

②想定質問と回答の準備

想定質問	回答のポイント
「このシステムの全体像は？」	ドキュメントを用意し、説明できるように
「M&A後も働く意向は？」	本人の意向を事前に確認しておく
「困っていることは？」	ネガティブな回答は事前に把握し、対策を
「他に担当できる人は？」	バックアップ体制を説明できるように

キーエンジニアの引き留め策（リテンション）

キーエンジニアをM&A後も引き留めるための施策です。

施策	内容	効果
リテンションボーナス	M&A後の一定期間在籍で支給	高
ストックオプション	株式報酬の付与	中〜高
昇格・昇給	M&Aを機にポジションアップ	中
業務環境改善	裁量拡大、リモートワーク等	中

リテンションボーナスの目安:

• 年収の 50〜100% が一般的
• 在籍条件: 1〜2年
• 支給タイミング: 在籍条件達成後

キーマンリスクがM&A価格に与える影響

キーエンジニアの退職リスクがある場合、買い手は リテンション費用 を見込み、その分を 価格から差し引き ます。

リスクレベル	減額幅（目安）
低（在籍意向あり、バックアップあり）	0〜5%
中（在籍意向あり、バックアップなし）	5〜10%
高（在籍意向不明、属人性高い）	10〜20%
最高（退職予定、代替不可）	20%以上または破談

まず明日やるべきこと：テック・デューデリジェンスへの備え

テック・デューデリジェンスに備えるために、以下の3ステップを実行してください。

□ Step 1 : 使用OSSのライセンスを棚卸しし、違反リスクを確認する

• システムに含まれる全OSSをリスト化
• 各OSSのライセンスを特定
• GPL系ライセンスの有無を確認し、違反がないか検証
• ライセンスチェックツールの導入を検討

□ Step 2 : 開発委託契約の著作権条項を確認し、不備があれば是正する

• 過去の開発委託契約書を全て収集
• 著作権帰属条項の有無を確認
• 「帰属不明確」 な契約については、外注先と交渉し、著作権譲渡契約を締結

□ Step 3 : キーエンジニアを特定し、リテンション施策を検討する

• システム運用に不可欠な人材を特定
• 属人性を下げるためのドキュメント整備を推進
• リテンションボーナス等の施策を 予算化