M&A直前にソースコードの個人管理が発覚したときの初動対応

2026.07.05

導入

中小企業のM&Aでは、決算書や顧客リストだけでなく、「会社の事業が本当に引き継げる状態か」が厳しく見られます。

特にソフトウェア会社では、ソースコード、仕様書、保守手順、顧客別カスタマイズ、障害対応履歴が会社の重要資産です。

ところが、長年キーマンに依存してきた会社では、主力システムの一部が個人PCや個人クラウドで管理されていることがあります。

これを軽く見ると、M&A価格の減額だけでなく、買い手との信頼、既存顧客の保守、社員の不安、キーマン離脱まで一気に問題化します。

私は、この問題の本質は「技術部長からコードを取り上げるかどうか」ではなく、会社資産・顧客責任・M&A開示・キーマン感情を同時に整理することだと考えます。

相談事例

ある業務用ソフトウェア会社での話です。

この会社は、製造業向けの在庫管理システムや受発注管理システムを長年提供してきました。

地元製造業からの信頼は厚く、保守契約も安定しています。

しかし、社長は63歳。

後継者はおらず、子どもも会社を継ぐ意思がありません。

若手社員もまだ経営を任せられる状態ではありませんでした。

そこで、同業の中堅IT企業へのM&Aが進んでいました。

買い手企業は、この会社の顧客基盤と保守契約を評価していました。

社長も、次のように考えていました。

「顧客と社員を守るには、体力のある会社に引き継ぐのがよい」

ところが、デューデリジェンスの途中で問題が見つかります。

主力システムの一部ソースコードが、会社の共有リポジトリに入っていなかったのです。

• 顧客別カスタマイズ部分
• 帳票出力モジュール
• 主要顧客向けの受発注連携プログラム
• ライセンス認証の一部
• 緊急修正用のスクリプト
• 過去の障害対応履歴メモ

これらが、技術部長の個人PCや個人契約のクラウドストレージで管理されていました。

技術部長は、創業初期から会社を支えてきたNo.2です。

主力システムの多くを設計し、顧客トラブルにも長年対応してきました。

社長も、次のように思っています。

「彼がいなければ会社はここまで来られなかった」

しかし、買い手企業から見れば話は別です。

会社が買収対象として売ろうとしているシステムの一部を、会社自身が管理できていない。

しかも、技術部長が退職すれば保守が止まる可能性がある。

これは重大なリスクです。

買い手企業は、買収価格の見直しや条件変更を示唆しました。

社長は焦りました。

専務は技術部長に強い不信感を持ちました。

「会社の仕事で作ったものを、なぜ個人が握っているのか」

「M&Aを人質にしているように見える」

そう感じたのです。

一方で、技術部長にも感情があります。

「この会社のシステムはほとんど自分が作ってきた」

「買収後に自分がどう扱われるのか決まっていない」

「全部渡したら、自分の価値がなくなる」

そう考えていました。

さらに、技術部長は若手社員に対して、次のように話していました。

「A社に買われたら、我々は保守要員として使い潰されるかもしれない」

社内には不安が広がります。

若手社員は期待と不安が入り混じり、古参社員は技術部長側に傾き始めます。

営業部長も困っていました。

主要顧客B社のクラウド移行調査が迫っていたからです。

そのB社向け連携プログラムは、技術部長しか十分に理解していません。

M&Aが壊れるのも困る。

しかし、技術部長が退職してB社対応が止まるのはもっと困る。

会社は非常に難しい局面に立っていました。

この問題の本質

私は、この問題の本質は「ソースコードを誰が持っているか」だけではないと考えます。

もちろん、会社の主力システムのコードが個人管理されている状態は危険です。

しかし、それだけではありません。

この問題には、少なくとも次の論点が重なっています。

• 会社資産としてのソースコード管理
• 顧客別カスタマイズの権利帰属
• 個人クラウド内の顧客情報
• 買い手企業への情報開示
• M&A価格や表明保証
• 主要顧客B社の保守継続
• 技術部長の退職・独立リスク
• 若手社員への影響
• 社長の後継者不在

これらを分けずに、「会社のものだから返せ」とだけ言えば、技術部長は強く反発するでしょう。

逆に、技術部長の感情に配慮しすぎて個人管理を放置すれば、買い手企業の信頼を失います。

だからこそ、最初に必要なのは感情的な対立ではなく、棚卸しです。

よくある失敗

この場面でよくある失敗は、技術部長に対していきなりコード返還を迫ることです。

方向性としては、会社管理に戻す必要があります。

しかし、初手で強制的に回収しようとすると、技術部長は「自分が疑われている」と感じます。

その結果、退職、独立、若手への不満拡散、顧客引き抜きに進む可能性があります。

もう一つの失敗は、買い手企業への開示を恐れて問題を曖昧にすることです。

M&Aでは、隠すことは最も危険です。

後から問題が発覚すれば、表明保証違反や補償請求につながる可能性があります。

ただし、事実関係が整理されていない段階で、ただ「問題があります」とだけ伝えても、買い手企業の不安を大きくします。

必要なのは、確認済み事実、未確認事項、是正計画をセットで整理することです。

また、技術部長を厚遇する条件だけで収めようとするのも危険です。

本人を安心させることは重要ですが、会社資産の個人管理が続くなら、根本解決にはなりません。

私ならどう考えるか

私なら、まず技術部長が管理しているものを一覧化します。

• 個人PCにあるコード
• 個人クラウドにある資料
• 顧客別カスタマイズ
• B社向け連携プログラム
• ライセンス認証部分
• 障害対応履歴
• 緊急修正スクリプト
• 顧客情報
• 仕様メモ
• 過去の納品物

これらを一つずつ確認します。

次に、権利関係を分けます。

• 会社が明確に保有しているもの
• 顧客契約上、確認が必要なもの
• 共通モジュールとして会社が再利用しているもの
• 顧客固有の成果物と考えられるもの
• 技術部長の個人管理から会社管理へ移すべきもの

この分類がないままでは、買い手企業にも説明できません。

同時に、B社の保守リスクを確認します。

• B社対応に必要なコードは何か
• 仕様を理解している社員は誰か
• 技術部長が抜けた場合、どこが止まるのか
• 来月のクラウド移行調査に支障が出るのか

ここを早急に整理します。

さらに、技術部長との面談では、最初から責めるべきではありません。

「あなたが会社を支えてきたことは理解している」

「ただし、顧客と社員を守るためには、コードと資料を会社管理に移す必要がある」

「買収後の役割や移行協力条件は整理する」

この順番で話すべきです。

功労者として尊重することと、会社資産の個人管理を認めないことは両立できます。

最善策

私が最初に優先すべきだと考えるのは、次の対応です。

技術部長が管理しているコード、顧客別カスタマイズ、契約書上の権利帰属、個人クラウド内の顧客情報、B社保守リスク、退職・独立リスクを棚卸しする。

同時に、コード回収、アクセス管理、買い手企業への追加開示方針、技術部長の移行協力条件を整える。

これが最善です。

M&Aを進めたいからといって、問題を隠してはいけません。

技術部長が大事だからといって、会社資産の個人管理を放置してはいけません。

買い手企業に信頼してもらうには、問題がないふりをするのではなく、問題を把握し、是正計画を示す必要があります。

なぜ法律だけでは解決できないのか

このケースでは、著作権、職務著作、営業秘密、個人情報、秘密保持、競業避止、M&A契約、表明保証などが問題になります。

法律面の整理は非常に重要です。

しかし、法律だけでは会社は守れません。

仮に法的には会社の著作物だとしても、技術部長が協力しなければ、保守移管は進みません。

仮に契約上は会社に権利があるとしても、仕様書がなく、本人しか理解していないなら、顧客対応は止まります。

仮に買い手企業に開示義務を果たしても、是正計画がなければ、価格は大きく下がるかもしれません。

重要なのは、権利を主張することだけではありません。

• 顧客保守が続く状態にすること
• 買い手が安心して引き継げる状態にすること
• 社員が不安で離職しない状態にすること
• 技術部長の力を、会社のリスクではなく移行資産に変えること

実務上のチェックポイント

このようなケースでは、私は次の点を確認します。

1. 個人管理されているコードと資料の範囲

どのコードが会社リポジトリに入っていないのか。

どの顧客に関係するのか。

2. 顧客契約書

成果物の権利が誰に帰属するのか。

共通モジュールの再利用ができる契約になっているのか。

3. 個人クラウド内の顧客情報

顧客担当者名、障害履歴、ログ、問い合わせ内容などが含まれていないかを確認します。

4. 主要顧客B社の保守体制

技術部長が抜けた場合、誰が対応できるのか。

引き継ぎ資料はあるのか。

5. 技術部長の感情と条件

退職を考えているのか。

買収後に何を不安に思っているのか。

どのような役割なら協力できるのか。

6. 買い手企業への開示方針

確認済みの事実、未確認事項、是正スケジュール、技術部長の協力見通しを整理して伝える必要があります。

まとめ

M&A直前に、主力システムのソースコードが技術部長の個人PCや個人クラウドで管理されていたことが発覚した。

このような場面では、社長や専務が焦るのは当然です。

「会社の資産を個人が握っているのではないか」

「買い手企業に不信感を持たれるのではないか」

「技術部長が辞めたら顧客対応が止まるのではないか」

そう考えるのは自然です。

しかし私は、このケースで最初にやるべきことは、技術部長を責めてコードを強制回収することでも、M&A交渉を即停止することでもないと考えます。

まず、技術部長が管理しているコード、顧客別カスタマイズ、契約書上の権利帰属、個人クラウド内の顧客情報、B社保守リスク、退職・独立リスクを棚卸しすること。

同時に、コード回収、アクセス管理、買い手企業への追加開示方針、技術部長の移行協力条件を整えること。

この順番です。

重要なのは、誰が悪いかではありません。

会社として引き継げる状態を作れるかです。

社長の引退、買い手企業の安心、社員の雇用、顧客の保守継続。

これらを守るには、感情ではなく、資産とリスクを見える化する必要があります。

私は、それがこの場面での最善の経営判断だと考えます。

免責文

本記事は、中小企業におけるM&A、ソースコード管理、知的財産、顧客情報管理、キーマン依存、事業承継に関する経営判断を考えるための一般的なケーススタディです。

実際の事案では、雇用契約、就業規則、顧客契約、成果物の作成経緯、情報管理体制、M&A契約条件、関係者の発言内容などによって判断が異なります。

個別案件では、事実関係を丁寧に確認したうえで対応方針を検討する必要があります。