アプリ開発会社・受託開発会社の売却準備完全ガイド｜180日前からの実務ロードマップ

アプリ開発会社の売却は、決算書と株主名簿をそろえれば進む仕事ではありません。買い手が本当に引き継ぐのは、顧客との信頼、エンジニアの判断力、ソースコード、クラウド環境、ストア運用権限、保守契約、開発中案件、再委託先との関係、そして経営者の頭の中にある暗黙知です。これらが「誰のものか」「譲渡後も使えるか」「経営者が抜けても回るか」を説明できなければ、好調な会社でも評価は不安定になります。

本稿は、売却を考え始めたアプリ開発会社、SaaS事業者、受託開発会社、SES・常駐支援会社、保守運用会社の経営者を対象にした実務ガイドです。まだ仲介会社へ相談していない段階でも使えるよう、想定するクロージング日の180日前から、基本合意、デュー・ディリジェンス、最終契約、さらに譲渡後90日までを時系列で整理します。

この記事の対象読者

• アプリ開発会社を第三者へ承継し、社員と顧客の将来を守りたい創業経営者
• 受託開発とSES、保守など複数の収益モデルを持ち、何を分けて説明すべきか迷っている経営者
• 自社アプリやSaaSの伸びは示せるが、KPI、契約、知財、セキュリティの資料化が遅れている経営者
• 地域の自治体、医療法人、製造業、流通業などとの長期取引を、買い手へ正しく伝えたい経営者
• 売却を急いではいないものの、後継者不在や採用難に備えて選択肢を持ちたい株主

この記事で分かること

1. 売却180日前から何を、どの順番で整えるべきか
2. SaaS、自社アプリ、受託開発、SES、保守運用で準備資料がどう違うか
3. データルームに入れる資料と、最初から開示してはいけない情報の分け方
4. 契約、知財、個人情報、クラウドアカウント、開発資産を引き継げる状態にする方法
5. 社員、顧客、金融機関、再委託先への説明時期をどう設計するか
6. 基本合意、デュー・ディリジェンス、最終契約で経営者が判断すべき論点
7. Day1、30日、90日で事業を止めないための引き継ぎ計画

結論サマリー

売却準備の要点は、会社をよく見せることではなく、事実を整理し、買い手が再現可能性を検証できる状態にすることです。180日前には株主の希望条件と譲渡範囲を決め、150日前までに事業別の売上・粗利と契約を棚卸しします。120日前までには案件別採算、受注残、未検収、正常収益を説明できるようにし、90日前から契約、知財、コード、クラウド、個人情報、情報セキュリティをデータルームに格納できるよう段階的に資料を整えます。60日前からはキーパーソンと顧客の引き継ぎ設計を作り、30日前以降の候補先探索では、匿名情報、秘密保持後の詳細情報、独占交渉後の機微情報を分けて開示します。

高く売るための準備と、成立後に揉めないための準備は同じです。売上の強みだけでなく、赤字案件、口頭合意、属人化、未処理の知財、アカウントの個人名義、退職懸念なども早めに把握して対処すれば、買い手はリスクを値引きではなく具体的な統合計画として扱いやすくなります。

1. なぜ「180日前」から始めるのか

中小M&Aの期間は案件ごとに異なり、180日で必ず完了するわけではありません。本稿の180日は、クロージングを約半年後に置いたときの準備開始点です。実際には買い手探索に時間がかかることも、法務・税務・会計上の論点で日程が延びることもあります。だからこそ、売却期限を先に固定して資料を急造するより、会社を平常運転したまま検証可能な状態へ近づける時間を確保します。

アプリ開発会社では、決算書に現れない資産と負債が多くあります。優秀な社員、顧客との継続関係、独自の運用ノウハウ、再利用できるライブラリは価値の源泉です。一方、代表者しか解除できない多要素認証、退職者の個人アカウントに紐づくストア、ライセンス条件を確認していないOSS、検収条件が曖昧な案件、工数超過が集計されない準委任契約は、引き継ぎを難しくします。これらは一週間の資料作成では解決しません。

180日前から始めるもう一つの理由は、売却準備のために本業を崩さないためです。経営者と管理部門が数週間にわたり資料集めへ偏ると、営業判断、採用、品質管理が遅れ、直近業績が落ちることがあります。週一回の準備会議、責任者、保存場所、更新日を決め、通常業務の一部として進める方が、結果として速く正確です。

最初に決める三つの原則

第一に、事実と見通しを分けます。 確定した売上、受注済みの未検収、提案中の商談、経営者の期待を一つの数字に混ぜません。見通しには確度と前提を付けます。

第二に、数字と原資料を結びます。 月次売上の表から、会計元帳、請求書、契約書、工数記録、検収書へ辿れる状態を作ります。表だけが立派でも、質問のたびに数字が変われば信頼は下がります。

第三に、開示は段階化します。 早期に必要な情報と、相手を絞ってから見せる顧客名、ソースコード、個人情報、脆弱性情報を分けます。秘密保持契約があるからといって、全情報を一度に渡す必要はありません。

2. まず自社を五つの収益モデルに分解する

「IT会社」という一括りでは、買い手は継続性を判断できません。同じ法人の中でも、収益の発生条件、必要人員、契約リスク、成長投資が違うためです。最初の棚卸しでは、最低でも次の五類型に分けてください。

SaaS・サブスクリプション

SaaSでは、契約社数や売上だけでなく、MRR、ARR、解約、アップグレード、ダウングレード、値引き、無料期間、滞納、粗利の推移を見ます。MRRは月次経常収益、ARRは年次経常収益を表す代表的な指標ですが、何を経常とするかを固定しないと比較できません。初期導入費、スポット開発、従量課金、返金を含めるかを定義書に記載します。

GRRは既存顧客群の売上が解約や減額でどれだけ残ったかを見る指標、NRRは増額も反映する指標です。分子と分母、観測期間、税・一時金の扱いを固定します。ロゴチャーンは顧客数の解約、売上チャーンは金額の減少を捉えるため、大口一社の解約が顧客数では小さく、売上では大きく見えることがあります。月別と顧客獲得月別のコホートを用意すると、最近獲得した顧客ほど定着しているかを説明できます。

自社アプリ・デジタルサービス

自社アプリでは、ダウンロード数だけで価値を説明しません。アクティブ端末、セッション、継続率、課金者、平均売上、返金、広告収益、ストア手数料、顧客獲得費、サーバー原価、サポート負荷を時系列で示します。AppleのApp Store Connect AnalyticsやGoogle Play Consoleでは複数の指標を確認できますが、指標の定義、プライバシー設定、集計条件が異なるため、社内独自集計と無理に一致させず差異の理由を説明します。

さらに、アプリ本体だけでなく、デベロッパーアカウント、署名鍵、証明書、プッシュ通知、ドメイン、API連携、広告アカウント、分析基盤、カスタマーサポート、利用規約、プライバシーポリシーを一つのサービス構成図にします。譲渡対象が株式か事業かによって、各契約・アカウントの承継方法は変わるため、プラットフォームの現行手続と専門家の確認が必要です。

受託開発

受託開発では売上より先に、案件別の契約形態、受注額、外注費、実工数、進捗、検収、瑕疵対応、追加要望の扱いを確認します。請負と準委任では負う義務や収益の認識条件が異なり得るため、契約書の表題ではなく実態も整理します。固定価格案件で工数超過を把握していない会社は、全社損益が黒字でも案件別には赤字が隠れます。

受注残は、単なる「見込み」ではなく、契約締結済みで今後売上化する部分、発注書待ち、口頭内示、提案中を区別します。未検収は売上計上の妥当性だけでなく、品質問題や顧客との認識差が潜んでいないかも確認します。買い手が知りたいのは大きな受注残ではなく、引き継ぎ後に予定どおり完了・請求・回収できる受注残です。

SES・常駐支援

SES・常駐支援では、稼働人数、契約単価、給与・社会保険・採用費を含む人材別粗利、稼働率、待機、契約更新月、商流、顧客・上位会社への集中、再委託、指揮命令の実態を確認します。契約名だけで適法性を断定せず、現場運用と契約の整合を労務・法務の専門家と点検します。

単価の高い一人が利益の多くを生む場合、その人の退職は顧客売上と採用コストの両方へ影響します。人員一覧は氏名を初期から開示せず、職種、等級、勤続、スキル、単価、粗利、契約更新、退職懸念を匿名IDで整理し、候補先を絞った段階で本人情報の開示方法を決めます。

保守運用・ストック型受託

保守運用は継続収入に見えますが、自動更新の有無、中途解約、SLA、対応時間、夜間休日、障害履歴、担当人数、赤字顧客を確認する必要があります。月額料金が長年据え置かれ、クラウド費や人件費だけ上昇している契約は、売上が安定していても粗利が悪化します。

また、顧客固有の古い環境を一人のベテランだけが保守している場合、契約は続いてもサービス提供能力を承継できません。手順書、監視設定、構成図、復旧訓練、エスカレーション、顧客連絡先を案件ごとに整えます。

3. 売却準備の全体ロードマップ

時期	主目的	経営者が決めること	主な成果物
180〜151日前	目的と条件の明確化	譲渡理由、範囲、譲れない条件、経営者の残留	希望条件表、株主・組織図、論点一覧
150〜121日前	事業と契約の棚卸し	収益モデル別の切り分け、契約の優先順位	事業別損益、顧客・契約台帳、サービス構成図
120〜91日前	財務と案件採算の整備	正常収益、受注残、未検収、運転資金	月次推移、案件別採算、売上ブリッジ
90〜61日前	データルームと技術・知財の整備	開示範囲、是正の優先順位	資料索引、権限台帳、IP・OSS・セキュリティ資料
60〜31日前	人材・顧客・地域関係の引き継ぎ設計	誰にいつ伝えるか、キーパーソン対策	人材マップ、顧客引き継ぎ表、説明シナリオ
30日前〜候補探索	段階開示と相手選び	候補先基準、情報開示、経営者面談	匿名概要、企業概要書、質問回答台帳
基本合意〜DD	前提の検証	独占交渉、価格前提、論点の解決方針	基本合意書、DD回答、論点管理表
最終契約〜クロージング	条件の確定と実行	表明保証、補償、支払、経営者保証、前提条件	最終契約、手続一覧、資金決済表
Day1〜90	事業継続と統合	発表、権限、顧客対応、統合の速度	Day1台本、30日・90日計画、課題台帳

この表は順序の目安であり、必ず直線的に進むわけではありません。たとえば名義株式、経営者保証、許認可、重大な情報事故が見つかれば早期から専門家対応が必要です。逆に、顧客名や社員名のような機微情報は、資料が完成しても相手と段階が整うまで開示しません。

4. 180〜151日前：売る理由と譲れない条件を言語化する

「なぜ今か」を一枚にまとめる

買い手は売却理由を、価格交渉の材料だけでなく、事業の継続可能性を読む情報として確認します。「年齢のため」だけでは、後継者がいない理由や、経営者が担う仕事が分かりません。「採用と営業を単独で拡大する限界がある」「大手の販売網と組み合わせてサービスを伸ばしたい」「社員のキャリアを広げたい」「個人保証を含む資本政策を整理したい」など、経営判断として説明できる形にします。

ただし、きれいな物語へ寄せる必要はありません。健康、家族、資金繰り、株主間の事情がある場合も、どこまで、いつ、誰に伝えるかを支援者と整理します。後から重要事実が分かる方が信頼を損ねます。

希望条件を「必須・重要・希望」に分ける

価格だけを希望条件にすると、複数の提案を比較できません。次の項目を三段階に分けます。

• 社名、サービス名、拠点を維持する期間
• 全社員の雇用・処遇、退職金、在宅勤務、地域勤務の扱い
• 顧客契約、開発中案件、保守義務の引受け
• 経営者が残る期間、役割、競業避止、報酬
• 株式譲渡か事業譲渡か、一部事業を残すか
• 譲渡対価の支払時期、分割、条件付支払の許容度
• 借入、個人保証、担保、役員貸付・借入の整理
• 社員・顧客への発表時期と共同説明の方法

「社員全員の雇用を永久に保証してほしい」のように相手が実行を約束しにくい条件は、一定期間の雇用維持、処遇変更時の協議、配置転換の範囲、統合後の育成策などへ分解します。実現可能な条項と、相手の方針を評価する質問を分けるのが実務的です。

株主、株式、事業用資産を確認する

株主名簿、定款、登記、過去の株式移動、種類株式、ストックオプション、株主間契約を照合します。創業時の名義株主、相続未了、所在不明株主があれば時間がかかる可能性があります。会社が使う自宅兼事務所、代表者個人所有のサーバー、車両、ドメイン、商標、ソフトウェアがあれば、売却対象に含めるか、賃貸・移転するかを検討します。

ここで「会社のものだと思っていた」をなくします。法人カードで払っていてもアカウント名義が個人、会社のPCで開発していても著作権の帰属規定が不十分、顧客向けサービス名の商標が別会社名義ということがあります。所有、契約当事者、支払者、実際の管理者を別列で記録してください。

支援者を選ぶ際の確認事項

中小企業庁の中小M&Aガイドライン第3版は、手続、支援機関、手数料、秘密保持、DD、最終契約などの留意点を幅広く整理しています。仲介会社やFAを選ぶ際は、知名度だけでなく、誰の立場で助言する契約か、手数料の算定基礎、最低手数料、着手金・中間金、相手方からの手数料、専任条項、直接交渉の制限、テール条項、途中解約、担当者のIT案件経験を確認します。

また、弁護士、税理士、公認会計士、社会保険労務士、技術DDの専門家をいつ起用するかを先に決めます。仲介担当者一人へ法務・税務・技術判断を集中させず、役割と責任を明確にします。

180〜151日前チェックリスト

• 売却理由を事業承継と成長の両面から説明できる
• 希望条件を必須・重要・希望に分けた
• 全株主、潜在株式、過去の株式移動を把握した
• 会社利用の個人資産・個人名義アカウントを一覧化した
• 経営者が残れる期間と、残れない事情を整理した
• 家族、共同創業者、主要株主の意向を確認した
• 支援者の契約、手数料、利益相反、解約条件を比較した
• 売却準備の社内責任者と週次会議を決めた

5. 150〜121日前：売上ではなく「事業の仕組み」を棚卸しする

事業別損益を作る

会計上の部門がなくても、SaaS、自社アプリ、受託、SES、保守へ売上と直接費を割り当てます。直接費には外注費、クラウド原価、ストア手数料、広告費、案件へ直接配賦できる人件費を含め、共通費の配賦ルールは別記します。最初から精緻な管理会計を目指すより、決算書合計へ一致する再現可能なルールを作ります。

売上表には、顧客ID、サービス、契約種別、開始・終了、更新、月額・一時、請求、入金、粗利、担当者、解約条件を持たせます。顧客名は内部版だけに置き、匿名版は「地域製造A」「医療法人B」のようにします。買い手候補へ開示する際、地域、規模、業種、契約年数、売上構成だけで顧客が特定されることがあるため、組合せによる再識別にも注意します。

売上ブリッジで増減理由を説明する

前年から今年へ売上が増えたなら、既存顧客の増額、新規顧客、単価改定、スポット案件、解約、減額に分けます。減った場合も同じです。「大型案件が終了したため」では、予定どおりの終了か、失注か、品質問題かが分かりません。顧客別・サービス別の増減と、経営者の説明を一致させます。

SaaSでは期首MRRから新規、拡張、縮小、解約、再開を足し引きして期末MRRへつなぎます。受託では期首受注残、当期受注、売上計上、失注・契約変更から期末受注残へつなぎます。SESでは期首稼働、入場、退場、単価変更、待機から期末稼働へつなぎます。モデル別のブリッジが、事業の動きを最短で伝えます。

顧客集中を金額と粗利で見る

上位顧客の売上比率だけでなく、粗利比率、契約更新月、サービス提供に必要な社員、経営者との関係を確認します。売上20％の顧客が粗利40％を占める場合と、売上20％でも赤字の場合では、依存リスクの意味が違います。グループ会社を別顧客として数えず、最終的な意思決定主体も把握します。

地域企業では、一社との取引が別の紹介につながり、数字以上の信用を生むことがあります。一方、代表者同士の個人的な関係だけで続く契約は、譲渡後に自動継続するとは限りません。紹介経路、決裁者、現場責任者、契約更新、競合、満足・不満、次回提案を顧客カルテへ記録します。

契約台帳を原本と突合する

契約台帳は、顧客・仕入先・再委託先・従業員・ライセンス・クラウド・オフィス・借入を対象にします。顧客契約では、契約期間、自動更新、中途解約、支払、検収、知財、再委託、秘密保持、個人情報、損害賠償、保証、SLA、チェンジ・オブ・コントロール、譲渡禁止を抽出します。

重要なのは、条項があるかだけでなく、実運用とのずれです。契約上は再委託禁止なのに常時外注している、検収書が必要なのにメール承認だけ、仕様変更の書面合意がなく追加開発している、といったずれを洗い出します。見つけた事実を隠さず、是正できるもの、顧客承諾が必要なもの、買い手と対応を決めるものに分けます。

サービス・システム構成図を作る

一枚目には、利用者、アプリ、API、データベース、外部サービス、決済、分析、通知、監視、バックアップを配置します。二枚目には、誰がどのアカウントを管理し、契約・請求名義が誰で、障害時に誰が対応するかを配置します。専門的な構成図と、経営者が説明できる事業構成図を分けると、買い手の経営・技術双方へ伝わります。

150〜121日前の失敗例

ある受託会社が「保守売上が半分あるので安定」と説明したものの、契約を確認すると多くが一か月更新で、夜間対応を一人の役員が無償で担っていました。売上の継続性より、人材と採算のリスクが大きい状態です。対策は、過去の更新実績、解約履歴、実工数を整理し、SLAと料金の見直し余地、複数担当化の計画を示すことです。

別のSaaS会社では、年額一括入金を入金月のMRRへ全額計上していたため、月次推移が大きく変動していました。買い手の質問後に定義を変えた結果、過去資料との不一致が生じました。最初に請求・入金と経常収益を分け、定義変更時には全期間を同じルールで再計算し、旧数値との差異表を残します。

6. 120〜91日前：財務、案件別採算、正常収益をつなぐ

月次試算表を早く締める

直近三期の決算書、税務申告書、勘定科目内訳、総勘定元帳に加え、当期の月次試算表を用意します。締めが二か月以上遅れる会社は、買い手が最新状況を把握しにくいため、売却準備中だけ急ぐのではなく、証憑回収、経費精算、請求、外注計上の締切を整えます。

月次推移では季節性と一時要因を説明します。アプリの年末需要、自治体の年度末検収、製造業の設備投資、採用費の集中、大型案件終了などです。前年同月、計画、直近見込みと比較し、差異理由を短文で残します。

正常収益は「都合のよい足し戻し」にしない

正常収益とは、過去の会計利益を将来の収益力として読み替えるための考え方です。役員報酬、私的経費、一過性の事故対応費、補助金、資産売却益、過少な人件費、未計上の残業、無償の役員作業などを検討します。ただし、譲渡企業に有利な費用だけを足し戻してはいけません。経営者が退任するなら代替人材の採用費を引き、老朽化した開発環境の更新、セキュリティ強化、値上がりしたクラウド費も将来負担として考えます。

調整表には、会計利益、調整項目、金額、対象期間、根拠証憑、将来も発生するか、買い手によって変わるかを記載します。正常収益は唯一の正解ではなく、前提の置き方で変わります。だからこそ、金額そのものより、元数字からの橋渡しを明確にします。

案件別採算を工数から検証する

受託案件ごとに、契約額、追加契約、外注費、実工数、標準人件費、進捗、売上計上、請求、入金、検収、残作業を並べます。工数記録が不完全なら、カレンダー、Gitの履歴、チケット、請求書、担当者ヒアリングから推計し、推計であることと精度を明示します。過去を完璧に復元するより、今後の記録を今日から正しくする方が重要です。

赤字案件は、見積不足、要件追加、品質不良、再作業、稼働不足、外注単価、マネジメント不在など原因を分類します。再発防止策として、見積レビュー、変更管理、着手条件、週次の原価予測、完了基準を定めます。単に「特殊案件だった」と片づけず、同じ条件の案件が受注残にないかを確認します。

受注残と未検収を四段階に分ける

受注残は、契約締結済み、発注書受領済み、基本契約のみ、口頭内示、提案中に分けます。法的な扱いは契約ごとに確認が必要ですが、経営管理上は確度を混ぜないことが重要です。金額だけでなく、売上化予定月、必要工数、予想粗利、担当者、顧客側前提、解約・変更条件を示します。

未検収案件では、納品済みか、顧客テスト中か、修正が残るか、検収期限があるか、請求可能か、紛争の兆候があるかを確認します。期末に集中する案件は、売上の期間帰属と工数見込みを会計専門家と点検します。

運転資金と資金繰りを示す

買い手は利益だけでなく、譲渡後に必要な資金を見ます。売掛金の回収サイト、前受金、買掛・外注費、賞与、税・社会保険、年額クラウド契約、ストア入金のタイムラグを月次で整理します。売掛金年齢表を作り、長期滞留は顧客確認、請求漏れ、相殺、品質問題など理由を記録します。

自治体案件では契約・検収・支払が年度単位に寄り、受託では外注費が売上回収より先行することがあります。SaaSの年額前受は現金を生みますが、将来サービス提供義務も伴います。現預金が多いから運転資金が不要と単純化せず、月別の最低資金を見ます。

120〜91日前チェックリスト

• 決算書合計と事業別損益が一致する
• 直近月次の締め日と精度を説明できる
• 売上・粗利の前年差を顧客・サービス別に説明できる
• 正常収益の加算と減算に証憑と前提がある
• 全受託案件の実工数または推計根拠がある
• 赤字案件と再発防止策を把握している
• 受注残を契約確度、売上時期、予想粗利で分けた
• 未検収、長期売掛、返金・クレームを一覧化した
• 前受金を将来売上と二重に評価していない
• 賞与、税、外注、クラウド更新を含む資金繰り表がある

7. 90〜61日前：データルームを「質問に答える仕組み」にする

フォルダではなく索引から設計する

データルームはファイル置き場ではありません。資料番号、名称、対象期間、基準日、責任者、機密区分、更新日、補足を持つ索引を先に作ります。買い手からの質問と回答、根拠資料、追加開示日をQ&A台帳で結びます。同じ質問に担当者ごとに違う回答をしないことが目的です。

標準的な分類は、会社・株式、財務・税務、顧客・売上、仕入・再委託、人事・労務、法務・契約、知財、製品・技術、情報セキュリティ、個人情報、許認可・補助金、保険、紛争、借入・担保、事業計画、PMIです。ただし、自社の重要リスクを一番深くします。SaaSならKPIとデータ基盤、受託なら案件採算と検収、SESなら人材・契約、保守ならSLAと障害です。

開示レベルを四段階にする

レベル0は社内準備用。 実名、個人情報、脆弱性、パスワードを含む可能性があり、外部共有しません。

レベル1は匿名概要。 売上規模、地域、業種、強み、譲渡理由など、会社を直ちに特定しにくい情報です。

レベル2は秘密保持後。 会社名、詳細財務、顧客構成、社員構成、契約要旨、技術概要を、必要性に応じて開示します。

レベル3は候補先限定。 顧客名、個別契約、ソースコード、詳細な脆弱性、個人別情報などです。独占交渉、DD範囲、アクセス者を確認し、閲覧のみ、ダウンロード制限、透かし、ログなどを検討します。

パスワード、秘密鍵、APIキー、本番認証情報はデータルームへ置きません。承継時の移管手順と責任者を示し、実際の秘密情報は安全な方法でクロージング時にローテーションします。

契約と知財の権利チェーンを確認する

開発資産ごとに、企画者、開発者、雇用・委託契約、著作権等の帰属、顧客との契約、OSS・商用ライセンス、商標、ドメインをつなぎます。社員が就業時間中に作ったから自動的にすべて問題ない、外注費を払ったから権利が当然移転した、と決めつけません。契約と適用法を専門家が確認できる資料をそろえます。

受託会社の共通部品は特に注意します。顧客へ成果物の権利を譲渡する契約の下で作ったコードを、別案件のテンプレートとして使っていないか。逆に、自社の既存ライブラリまで顧客へ譲渡したように読める契約がないか。案件ごとに「顧客固有」「自社既存」「第三者」「OSS」を区分し、由来を追えるようにします。

OSSについては、利用コンポーネント、バージョン、ライセンス、利用箇所、配布形態、改変、通知義務、脆弱性対応を一覧化します。自動生成した一覧をそのまま完成品にせず、重要コンポーネントと提供形態を人が確認します。

コード、クラウド、ストアの権限台帳

Gitリポジトリ、CI/CD、クラウド、ドメイン、DNS、証明書、App Store Connect、Google Play Console、決済、分析、通知、監視、サポート、デザイン、パスワード管理の各サービスについて、契約名義、所有者、管理者、請求先、管理者数、多要素認証、復旧方法、退職者権限、引き継ぎ可否を記録します。

代表者一人だけが管理者なら、平時から複数管理者と緊急復旧手順を整えます。ただし、権限を増やすこと自体が安全とは限りません。最小権限、定期棚卸し、操作ログ、退職時停止を組み合わせます。個人メールを業務アカウントへ変更できるものは早めに変更し、変更が難しいサービスは公式の移管手続を確認します。

技術負債を隠さず、影響と返済計画を示す

技術負債は古い言語を使っていることだけではありません。テスト不足、手動デプロイ、担当者しか知らない設定、サポート終了の依存、監視不足、データ移行不能、複雑な顧客別分岐、ドキュメント欠如も含みます。負債一覧には、対象、事象、事業影響、発生条件、暫定対応、恒久対応、概算工数、優先度を記載します。

すべて直してから売る必要はありません。重大なセキュリティ問題、サービス停止につながる単一障害点、引き継ぎ不能な個人アカウントは優先して是正します。UIの全面刷新や大規模リファクタリングは、買い手の製品戦略と重複する可能性があるため、選択肢と工数を示して協議します。

個人情報とセキュリティの整理

個人情報を扱う場合は、取得目的、取得項目、同意・通知、利用、第三者提供、委託、保管場所、アクセス権、保存期間、削除、漏えい等対応をデータフローにします。個別案件は個人情報保護委員会のガイドライン（通則編）その他の関係資料と専門家の助言を踏まえて確認してください。M&A検討だから顧客・従業員情報を無制限に渡せるとは考えず、目的、必要性、匿名化・集計化、契約、アクセス制御を検討します。

セキュリティ資料には、規程、資産台帳、権限棚卸し、バックアップ、復旧試験、脆弱性管理、インシデント履歴、委託先管理、教育、監査・認証があればその範囲を含めます。「事故はない」だけではなく、検知・記録できていたかを説明します。過去事故は、発生日、影響、報告、顧客対応、原因、再発防止、完了確認を時系列にします。

データルーム品質チェック

• すべての資料に対象期間と基準日がある
• 索引から原資料へ迷わず辿れる
• 同じKPIを複数ファイルで違う定義にしていない
• 顧客名・社員名を必要以上に早く開示していない
• パスワードや秘密鍵を保存していない
• 契約台帳と契約原本の件数が一致する
• 口頭合意、期限切れ、未締結を明示した
• 権利帰属を社員・外注・顧客・第三者まで辿れる
• 退職者の権限と個人名義アカウントを確認した
• Q&Aの回答者、承認者、根拠を記録している

8. 60〜31日前：キーパーソン、社員、顧客、地域の関係を設計する

キーパーソンを肩書ではなく業務で特定する

代表取締役、CTO、営業責任者だけがキーパーソンとは限りません。自治体の入札手続を知る事務担当、製造ラインの古い端末を保守できるエンジニア、医療顧客の運用を理解するサポート担当、ストア審査の差し戻し対応を担う社員など、止まる業務から逆算します。

人材マップには、担当業務、代替者、顧客関係、保有権限、文書化、育成期間、退職懸念、本人のキャリア希望を記載します。本人へ売却検討を伝える前に、通常の事業継続策として複数担当化、手順書、休暇時の代行を進めます。秘密を守るために属人化を放置するのは逆効果です。

社員への説明は「早いほどよい」でも「最後まで隠す」でもない

説明時期は、漏えいリスク、法的手続、DD協力の必要性、社員への影響、買い手との合意を踏まえて個別に決めます。初期から全社員へ話せば不確実性が長期化し、噂や退職につながることがあります。一方、クロージング直前まで重要メンバーにも伏せると、信頼を損ね、引き継ぎが間に合いません。

説明シナリオには、なぜM&Aか、買い手は何者か、雇用・給与・勤務地・評価・福利厚生は現時点でどうなるか、何が未定か、顧客へいつ話すか、質問窓口、外部発信のルールを含めます。未定事項を推測で断定せず、回答期限と決定者を示します。マネージャー向け、全社員向け、個別面談向けを分けます。

リテンションを現金だけで考えない

一時金や残留条件は有効な場合がありますが、社員が残る理由は、仕事内容、上司、技術選択、顧客、勤務地、評価、成長機会でも決まります。買い手とともに、統合後の役割、プロダクト方針、開発体制、キャリア、意思決定権を具体化します。

退職しそうな人を「忠誠心がない」と扱わず、懸念を聞きます。大企業の承認速度を嫌う、地域勤務を守りたい、自社サービスに集中したいなど、条件調整で解決できることがあります。逆に、残留を強要するような説明は長期的な信頼を損ねます。

顧客引き継ぎは契約と関係性の二本立て

顧客ごとに、契約上の通知・承諾、実務上の説明、説明者、買い手同席、想定質問、次回更新、未解決課題を整理します。チェンジ・オブ・コントロール条項や譲渡禁止条項の解釈・対応は専門家と確認します。株式譲渡だから顧客連絡が不要、事業譲渡だから全契約が同じ手続、と一律に決めません。

説明では、M&Aそのものより、担当者、窓口、SLA、価格、データの扱い、開発計画がどうなるかを顧客は気にします。「何も変わりません」と言い切るのではなく、変わらない事項、改善する事項、検討中の事項を分けます。地域顧客には、買い手の本社が遠くても、現地対応と雇用をどう維持するかが重要です。

再委託先・フリーランスを忘れない

開発力の一部を再委託先へ依存する場合、基本契約、個別発注、知財、秘密保持、個人情報、安全管理、再々委託、単価、稼働、代替可能性を確認します。長年の口頭関係で続いているフリーランスには、急に譲渡の書類へ署名を求めるのではなく、平時の契約整備として進めます。

特定の外注先が自社コードの大部分を管理し、自社にはレビュー能力がない場合、買い手は実質的な提供能力を懸念します。成果物、リポジトリ権限、設計資料、テスト、連絡経路を自社側にも保持します。

金融機関と経営者保証

借入契約、当座貸越、リース、保証協会、代表者保証、担保、財務制限条項を一覧化します。M&Aに伴う通知・承諾や保証解除の進め方は契約と金融機関判断によるため、買い手の資金計画と併せて早期に支援者へ相談します。クロージング日に自動的に個人保証が外れると思い込まないでください。

金融機関へ伝える時期は、秘密保持と手続必要期間のバランスを取ります。担当者との口頭確認だけで完了とせず、必要書類、審査、決裁、実行条件を記録します。役員借入金、会社から経営者への貸付、個人所有資産の賃料も同時に整理します。

9. 地域企業の暗黙知を「引き継げる資産」に変える

自治体・外郭団体との取引

自治体案件では、入札参加資格、契約年度、予算、仕様書、再委託承認、情報セキュリティ要件、検収、実績報告、補助事業との関係を確認します。過去の担当者との信頼は価値ですが、それだけに依存しないよう、調達スケジュール、意思決定者、利用部門、年度替わりの担当変更、必要書式を手順化します。

買い手の規模や所在地が変わることで入札資格・地域要件・共同企業体の扱いへ影響がないかは、案件ごとに確認します。予定価格や競合情報など機微な情報を不適切に扱わず、公開情報、契約資料、自社実績を分けます。

医療・介護との取引

医療・介護分野では、患者・利用者情報、委託先管理、端末・ネットワーク、障害時の業務継続、現場の操作負荷が重要です。法令・各種ガイドラインの適用はサービス内容で異なるため専門家と確認します。買い手には、データ項目、保管、アクセス、ログ、バックアップ、問合せ、事故履歴を具体的に示します。

「院長との関係が強い」だけではなく、事務長、情報担当、現場リーダー、委託ベンダーとの役割を記録します。診療時間を避けた作業、紙運用への切替、緊急連絡など、地域の現場で培った運用知識が継続契約の源泉です。

製造業との取引

製造業向けでは、生産停止の影響、古いOS・機器、工場ネットワーク、設備ベンダー、保全時間、現場固有のコード・品番を整理します。クラウドへ移せば直ちに良くなるとは限らず、停止許容時間、回線、端末、セキュリティ、検証環境を踏まえます。

熟練社員が「音」や「いつもの手順」で判断している保守は、障害事例、判断基準、連絡順、代替部品、復旧実績へ落とします。買い手が中央集約を望んでも、現地訪問が必要な工程と遠隔化できる工程を分けると、地域拠点の価値を説明できます。

地域金融機関・商工団体・紹介ネットワーク

地域の紹介経路は帳簿に載りません。金融機関、商工会議所、大学、IT団体、士業、元請企業から、どのような相談が入り、誰が一次対応し、どの案件へ発展したかを記録します。個人名の名簿をむやみに共有するのではなく、関係の種類、接点頻度、紹介実績、引き継ぎ方法を整理します。

譲渡後に買い手の看板だけで関係が続くとは限りません。譲渡企業経営者が一定期間同行し、新責任者を紹介し、地域での方針を説明する計画を作ります。雇用や拠点を重視する地域では、短期の効率化より、約束と実行を積み重ねる方が事業価値を守ります。

10. 30日前〜候補探索：段階開示と相手選び

匿名概要は「特定されない具体性」を目指す

匿名概要には、事業モデル、概算規模、地域を広めにした商圏、顧客業種、社員構成、強み、譲渡理由、希望時期を記載します。固有の受賞歴、唯一の自治体案件、アプリ名を推測できるユーザー数などは、組み合わせると特定につながります。公開情報と照合して特定されないかを確認します。

一方、抽象的すぎると適切な買い手が判断できません。「IT企業、安定売上」ではなく、「地域製造業向け基幹・現場アプリの受託と保守が中心」「保守は複数年の更新実績」「自社開発の業務アプリを併売」のように、価値の構造を伝えます。

買い手候補を価格以外で評価する

候補先評価表には、資金確度、意思決定速度、IT事業の理解、雇用・拠点方針、顧客との競合、製品の重複、技術統合力、情報管理、過去買収後の実績、経営者に求める残留、提示価格の前提を含めます。最高額の意向表明が、手取り、支払確度、条件、補償、アーンアウトを含めても最良とは限りません。

競合企業は業界理解が深い一方、顧客名や価格、技術の開示リスクがあります。開示範囲、担当チーム、情報遮断、目的、候補から外れた場合の取扱いを支援者と設計します。

企業概要書で事実と計画を分ける

企業概要書には、沿革、株主・組織、事業、顧客、競合、サービス、技術、人材、財務、KPI、成長機会、リスク、譲渡理由、希望条件を含めます。事業計画では、基準ケース、上振れ、下振れを用意し、採用人数、解約率、単価、開発投資、営業期間など前提を明記します。

過去未達の計画がある場合は削除せず、なぜ外れ、今の計画にどう反映したかを示します。「市場が大きいから売上が倍」ではなく、対象顧客数、営業経路、商談化、受注、導入期間、必要人員へ落とします。

経営者面談で確認されること

経営者面談では、数字の説明だけでなく、意思決定の質と誠実さが見られます。最大顧客が離れる可能性、退職しそうな人、最も失敗した案件、競合に負ける理由、買い手でなければできない成長、経営者退任後に困ることを、自分の言葉で答えられるよう準備します。

知らない質問へ推測で答えず、「確認して何日までに資料とともに回答する」とします。面談後は質問、回答、未回答、責任者、期限をQ&A台帳へ入れます。口頭で伝えた重要事実が最終契約の開示資料へ反映されるか、法務担当と確認します。

11. 基本合意：価格より「前提」と「次の進め方」を読む

基本合意書や意向表明書の名称・拘束力は文書ごとに異なるため、署名前に専門家へ確認します。一般に検討される事項には、取引形態、概算価格、価格前提、スケジュール、DD範囲、独占交渉、秘密保持、費用負担、経営者・社員の処遇、クロージング前提条件があります。

概算価格だけを見ず、現預金・借入・運転資金・未払費用の調整、正常収益、受注残、解約、退職、DD発見事項でどう変わる可能性があるかを確認します。「企業価値」「株式価値」「譲渡対価」が同じ意味で使われていないこともあるため、定義と計算例を求めます。

独占交渉は、買い手がコストをかけてDDするために合理的な場合がありますが、期間、延長、買い手が進めない場合の終了、譲渡企業が対応すべき事項を確認します。期限だけが長く、買い手のマイルストーンがない状態は避けます。

基本合意前の判断質問

1. 提示額は何を前提にし、どの項目で調整されるか
2. 資金調達と社内決裁はどの段階か
3. DDの担当、範囲、期間、追加質問の運用はどうするか
4. 社員・顧客への説明はいつ、誰が行うか
5. 経営者に求める残留期間、職務、競業避止は何か
6. 個人保証、担保、役員貸借はどう解消する想定か
7. 買い手の統合責任者と、買収後100日の仮説はあるか
8. 破談時に情報と複製資料をどう扱うか

12. デュー・ディリジェンス：発見を恐れず、論点を管理する

DDは譲渡企業を試す場ではなく、取引前提を検証する工程です。財務、税務、法務、ビジネス、人事・労務、技術、情報セキュリティ、知財などに分かれます。依頼資料をただ送るのではなく、質問の意図、担当、回答、根拠、開示レベル、期限を管理します。

財務・税務DD

売上の実在性と期間帰属、案件原価、売掛金回収、前受、未払、引当、固定資産、関連当事者取引、簿外債務、税務申告、繰越欠損、補助金などが確認されます。受託では検収と進捗、SaaSでは請求と提供期間、SESでは稼働と請求、保守では将来義務を説明します。

質問後に帳簿を恣意的に書き換えず、誤りが見つかれば原因、影響期間、訂正方法、再発防止を整理します。事実発見を隠すより、経営管理が改善できることを示す方が信頼につながります。

法務・人事DD

会社、株式、契約、訴訟・クレーム、知財、許認可、個人情報、労務を確認します。未締結の業務委託、固定残業、未払残業の可能性、就業規則、36協定、社会保険、フリーランスとの実態、競業・秘密保持などが論点になり得ます。法的評価は専門家が行い、譲渡企業は事実と証拠をそろえます。

従業員一覧は、雇用形態、入社、職種、給与、賞与、労働時間、有休、休職、退職、懲戒、評価、保有権限を必要範囲で整理します。個人情報へのアクセスは限定し、匿名情報で足りる段階を見極めます。

技術・セキュリティDD

プロダクト構成、ロードマップ、コード品質、テスト、開発プロセス、インフラ、可用性、監視、バックアップ、復旧、脆弱性、権限、OSS、データ、技術組織が確認されます。見栄えのよい資料より、実リポジトリと運用記録に整合することが重要です。

技術担当者には「全部問題ない」と答えさせず、既知の制約と優先順位を説明してもらいます。買い手側の標準に合わせる改修と、譲渡前から必要な是正を分けます。コード閲覧は、候補先、目的、環境、アクセスログ、複製制限を決め、本番秘密情報を除いた方法で行います。

DDでの回答原則

• 質問文の範囲を確認し、分からない推測を混ぜない
• 基準日と対象会社・事業を明示する
• 「該当なし」は確認した範囲と担当者を残す
• 口頭回答もQ&A台帳へ記録する
• 不利な事実ほど、影響・原因・対応をセットにする
• 数字を修正したら旧版との差異と理由を残す
• 顧客・社員・脆弱性情報は必要最小限にする
• 回答速度のために承認手順を飛ばさない

13. 最終契約とクロージング：経済条件と将来責任を一緒に見る

最終契約では、譲渡対象、対価、支払、前提条件、誓約、表明保証、補償、解除、競業避止、秘密保持、役員・社員の扱い、経営者の引き継ぎなどを定めます。条項の意味とリスクは案件ごとに異なるため、必ず専門家と確認してください。

表明保証と開示資料

表明保証は、一定時点の事実について当事者が表明する仕組みです。範囲、重要性、知識限定、期間、上限、免責、開示済み事項の扱いを確認します。データルームに格納しただけで、自動的にすべてが開示済みになるとは限りません。どの事実を、どの資料で、誰に、いつ開示したかを最終契約の定義と整合させます。

「契約違反は一切ない」「すべてのソフトウェアに欠陥がない」のように現実的に確認できない表現へ安易に同意しません。事実調査の範囲と、既知事項を専門家へ正確に伝えます。

アーンアウト・分割払い・価格調整

将来業績に応じた支払や分割払いを含む場合、指標定義、会計方針、買い手の経営裁量、予算・人員、判定期間、情報閲覧、紛争解決を確認します。売上目標でも、値引き、グループ間取引、製品統合、営業担当変更で結果が変わります。達成可能性だけでなく、譲渡企業がコントロールできない要因を検討します。

運転資金や現預金・借入を基準に価格調整する場合、基準額、勘定科目、正常水準、計算日、会計方針を数値例で確認します。契約文だけでなく、想定貸借対照表を使って試算します。

クロージング手続表

実行日までに必要な取締役会・株主総会、株券、譲渡承認、登記、契約承諾、金融機関、保証、資金決済、役員辞任、印章、通帳、アカウント、原本、社員・顧客発表を一覧化します。各項目に責任者、期限、前提、証跡、未完了時の対応を付けます。

アプリ事業では、ストアやクラウドの移管を「当日にログインを渡す」作業にしません。公式手続、審査、契約変更、課金・入金、税務情報、ユーザーへの影響、ダウンタイム、秘密情報のローテーションを事前に確認し、株式譲渡で法人が同じ場合も管理権限と請求を見直します。

14. Day1：社員と顧客が迷わない一日を作る

Day1は派手な統合施策の日ではなく、事業継続を確認する日です。社員が出社・接続でき、給与・経費・休暇の手続が分かり、顧客の問合せが通常どおり届き、デプロイと障害対応が止まらない状態を優先します。

Day1台本の構成

1. 経営者と買い手責任者の共同メッセージ
2. M&Aの目的と、顧客・社員へ約束できる事項
3. 雇用、給与、勤務地、評価、組織の当面の扱い
4. 誰が何を決めるかという暫定ガバナンス
5. 顧客、再委託先、金融機関への連絡順序
6. メール、チャット、VPN、経費、承認の利用方法
7. インシデント・問い合わせの連絡先
8. 未決定事項と回答予定日

発表前にFAQを用意しても、すべての質問には答えられません。質問受付、回答責任者、全社共有の方法を決めます。社員が顧客へ異なる説明をしないよう、外部向け短文とエスカレーション先を配布します。

当日に変えない方がよいもの

ブランド、価格、開発ツール、組織、評価制度、顧客窓口を一斉に変えると、問題の原因が分からなくなります。法令・安全上直ちに必要な変更を除き、現状を観察し、変更理由、影響、戻し方を設計してから進めます。買い手の標準化は目的ではなく、顧客価値と運営品質を高める手段です。

15. Day30：暗黙知を移し、早期の約束を検証する

30日までに、主要顧客面談、キーパーソン面談、権限棚卸し、資金・請求、案件レビュー、障害体制、採用計画を一巡します。譲渡企業経営者は、単に人を紹介するだけでなく、「誰がどの情報を持ち、どの場面で判断するか」を買い手へ移します。

30日レビュー項目

• 上位顧客の反応、更新・解約兆候、未解決課題
• 開発中案件の進捗、予算、品質、検収見込み
• キーパーソンの役割、負荷、残留意向、代替育成
• 管理者アカウント、退職者権限、秘密情報の更新
• 売上・粗利・MRR・稼働率など主要KPIの定義統一
• 買い手と譲渡企業の承認衝突、意思決定の遅れ
• Day1で約束した事項の実行状況

統合の成果を売上だけで測ると、短期案件を詰め込み品質を落とすことがあります。顧客継続、納期、障害、社員負荷、採用、ドキュメント化も併せて確認します。

16. Day90：統合するもの、残すものを決める

90日頃には、観察結果に基づいて中期計画を更新します。営業チャネル、クロスセル、採用、開発ロードマップ、インフラ、バックオフィス、ブランド、拠点を、統合、連携、独立維持に分けます。

たとえば経理・購買を統合しても、地域顧客のサポート窓口は残す。認証基盤は統一しても、プロダクトチームのリリース判断は一定期間残す。大手顧客への営業は買い手と連携しても、小規模顧客の迅速な見積フローは維持する。このように能力単位で決めます。

譲渡企業経営者の役割も、顧客紹介、採用、技術判断、承認、地域活動へ分解し、移管完了条件を定めます。「一年残る」だけでは終わりが見えません。後任が単独で判断できる、主要顧客が新責任者へ直接連絡する、月次会議を後任が主催するなど、卒業条件を明確にします。

17. 収益モデル別・売却準備の重点表

モデル	最重要資料	よくある誤解	引き継ぎの核心
SaaS	MRRブリッジ、GRR・NRR、コホート、粗利	ARRが大きければ十分	定義の一貫性、解約理由、運用組織
自社アプリ	ストア指標、課金・広告、継続、アカウント台帳	ダウンロード数が資産価値	ストア・鍵・データ・外部連携の承継
受託開発	案件別採算、受注残、未検収、変更履歴	売上と受注残が同じ質	見積、要件変更、品質、顧客関係
SES・常駐	人材別粗利、稼働、更新、商流、待機	在籍者数がそのまま売上	人材残留、契約実態、採用再現性
保守運用	契約更新、SLA、障害、実工数、手順	月額売上はすべて高粗利	複数担当、価格適正化、復旧能力

複合モデルの会社では、共通人員の配賦を完璧にするより、誰がどのモデルに何割関与しているかを示します。SaaSの赤字が投資なのか、受託の利益で隠れた構造的赤字なのかを分けます。買い手との相乗効果も、「SaaS顧客へ受託を売る」「受託顧客へ自社アプリを展開する」のように、対象顧客、提案、担当、期間へ具体化します。

18. 売却準備で起きやすい十二の失敗と修正方法

失敗1：売上上位顧客を実名のまま多数へ開示する

競合や取引先へ情報が広がると、関係を損ねます。匿名概要、秘密保持後、候補限定の三段階を作り、実名が本当に必要な相手と時点を決めます。

失敗2：KPIの定義を面談ごとに変える

MRRへ初期費用を入れたり外したりすると、成長率より信頼が問題になります。定義書、計算元データ、変更履歴を作り、全期間を同じ定義で再計算します。

失敗3：赤字案件を合計利益で隠す

買い手は案件別に確認します。早期に原因を分類し、残作業、損失見込み、再発防止、同条件の受注残を示します。

失敗4：外注コードの権利を確認しない

請求書だけでは権利関係を十分に説明できません。業務委託契約、個別発注、成果物、リポジトリ、利用OSSを結び、専門家へ確認します。

失敗5：ストアやクラウドが代表者の個人名義

移管に時間がかかり、本人不在時の復旧も困難です。公式手続を確認し、法人管理、複数管理者、復旧手順、支払名義を整えます。

失敗6：秘密保持を理由に社員の属人化を放置する

売却を言わずにできる事業継続策は多くあります。通常の品質改善として手順化、ペア担当、休暇時代行、権限棚卸しを進めます。

失敗7：経営者の無償労働を利益として扱う

退任後には代替コストが必要です。経営者の週次業務、時間、必要能力を可視化し、後任人件費や買い手側で吸収できる業務を分けます。

失敗8：大規模な製品刷新を売却直前に始める

リリース遅延、障害、コスト増で直近実績が不安定になります。安全上必要な是正を優先し、戦略的刷新は選択肢と工数を買い手へ示します。

失敗9：顧客へ「何も変わらない」と約束する

統合後に変更が生じると信用を失います。維持事項、改善事項、未定事項を分け、回答責任者と期限を示します。

失敗10：最高価格だけで独占交渉先を決める

支払条件、資金確度、DD前提、社員・顧客方針、経営者の拘束を比較します。手取りと実行可能性を含む比較表を作ります。

失敗11：経営者保証の解除を最後に確認する

金融機関の手続に時間がかかることがあります。借入・保証・担保一覧を早期に共有し、買い手の資金調達と併せて進捗を管理します。

失敗12：クロージングをゴールにする

顧客、社員、システムは翌日も動きます。Day1、30、90の責任者と成果物を最終契約前から作り、譲渡企業経営者の移管完了条件を決めます。

19. 180日準備を週次で回す経営会議

準備会議は60分程度を基本とし、冒頭に通常業績を確認します。売却準備で本業が落ちていないかを最初に見るためです。次に資料進捗、未解決論点、開示判断、専門家への質問、翌週の担当を確認します。

週次ダッシュボード例

• 通常業績：売上、粗利、受注、MRR、解約、稼働、障害、採用・退職
• 資料：未収集、要更新、レビュー待ち、開示可能の件数
• 重要論点：株式、契約、知財、税務、労務、技術、保証の状態
• 機密管理：外部開示先、アクセス、誤送信・持出しの有無
• 意思決定：経営者・株主・買い手・専門家の判断待ち
• 次週：担当者、期限、完了条件

進捗率を上げるために空の資料を「完了」とせず、完了条件を定めます。契約台帳なら、原本確認済み、重要条項抽出済み、未締結・期限切れ識別済みで完了です。KPIなら、定義書、元データ、計算、会計との照合、更新手順までそろえて完了です。

20. 経営者が今日から作るべき十の成果物

1. 希望条件一枚表：価格以外の必須・重要・希望を整理する。
2. 収益モデル別損益：SaaS、自社アプリ、受託、SES、保守を分ける。
3. 顧客・契約台帳：売上、粗利、更新、担当、重要条項を結ぶ。
4. 案件別採算表：受注、工数、外注、進捗、検収、残作業を示す。
5. KPI定義書：MRR、ARR、GRR、NRR、チャーンなどの算式を固定する。
6. サービス構成図：システム、外部連携、運用、権限を見える化する。
7. 知財・ライセンス台帳：社員、外注、顧客、OSSの権利チェーンを示す。
8. キーパーソンマップ：止まる業務、代替者、育成期間を把握する。
9. 段階開示表：誰に、いつ、どの粒度で見せるかを決める。
10. Day1・30・90計画：成立後の事業継続と引き継ぎを先に設計する。

これらは買い手に見せるためだけの資料ではありません。途中で売却を見送っても、採算改善、事故予防、採用、権限管理、事業承継に役立ちます。M&A準備を「会社の健康診断」として行う価値はここにあります。

21. 譲渡企業手数料0円を、準備の質へ振り向ける

アプリ開発M&A総合センターは、譲渡企業から着手金・中間金・成功報酬を含めて手数料をいただかない、譲渡企業手数料0円の仕組みです。相談しただけで費用が発生する、途中で中間金が必要になる、成立時に成功報酬が差し引かれるという譲渡企業側の負担はありません。

手数料体系は支援会社によって異なり、算定基礎、料率、最低手数料、提供業務も同じではありません。比較時は総額と支援範囲を必ず確認してください。たとえば大手仲介会社が公開する料金説明には、譲渡金額を基準にした例として「5億円×5％＝2,500万円」となる階層が示されていますが、実際の報酬は契約条件や算定方式によって異なり、当センターとの単純比較ではありません。出典はストライクの公開料金ページです。

譲渡企業手数料0円だから準備を省くのではありません。むしろ、契約・知財・労務・税務の個別確認、データ整備、社員と顧客の引き継ぎに経営資源を向けられるようにする考え方です。売却を決めていない段階でも、どこから整理すべきかを確認できます。

22. 実務ケース：地域の複合型開発会社が半年で整えたこと

ここでは、特定企業の実例ではなく、地域のアプリ開発会社で起こりやすい論点を組み合わせた架空ケースで準備の流れを確認します。譲渡企業は社員28人、売上の内訳は受託開発45％、保守25％、SES20％、自社SaaS10％です。代表者は営業、見積承認、最大顧客の障害判断を兼務し、後継者候補はいません。主要顧客は地域製造業、医療法人、自治体関連です。

180日前：会社全体を売るか、SaaSだけを売るか

代表者は当初、自社SaaSだけを売れば受託会社を家族へ残せると考えていました。しかし、SaaSの開発・運用社員が受託案件も兼務し、共通認証基盤とクラウド契約も同じでした。分離すると、人員、コード、顧客サポート、共通費の切り分けに時間と追加契約が必要です。

そこで「会社全体の株式譲渡」「SaaSを含む事業譲渡」「SaaSだけの譲渡」の三案を、譲渡範囲、社員、契約、税務、資金、代表者の残留で比較しました。この段階では結論を急がず、専門家が検討できる資産・契約一覧を作りました。結果として、社員と地域顧客を一体で承継することを最優先とし、会社全体を中心に候補探索する方針を決めました。

150日前：安定売上の中に赤字保守を発見

会計では部門別粗利を管理していなかったため、顧客別請求と工数を照合しました。すると、月額保守のうち三契約は、夜間連絡と古い端末対応を含めると赤字でした。さらに、担当者が工場設備の癖を個人メモだけで管理していました。

譲渡企業は契約を急に解約せず、障害件数、対応時間、訪問、クラウド原価を三か月記録しました。契約更新時の料金改定案、対応範囲の明確化、二人目の担当育成、復旧手順を作りました。買い手には「保守売上が安定」という表現だけでなく、契約別の採算と改善スケジュールを開示しました。赤字発見はマイナス情報ですが、測定と改善が始まったことで、将来負担を具体的に検討できる状態になりました。

120日前：SaaSのMRRを再定義

従来の社内資料は、月額利用料、初期設定、個別カスタマイズをすべてSaaS売上としていました。そこで経常部分と一時部分を分け、月初MRR、新規、増額、減額、解約、月末MRRのブリッジを24か月分作りました。請求システム、会計、契約台帳の差異も記録しました。

再計算後のMRRは旧資料より小さくなりましたが、継続率と顧客別粗利が明確になりました。また、導入支援を標準化すれば初期工数を減らせること、製造業顧客では追加拠点の拡張余地があることも分かりました。数字を大きく見せるより、定義を固定して改善施策へつなぐ方が、買い手との議論は具体的になりました。

90日前：外注コードと個人アカウントを是正

コード棚卸しでは、創業初期にフリーランスが作った共通ライブラリの契約が見つからず、代表者個人のメールで登録したドメインと分析サービスも判明しました。譲渡企業は支払記録、メール、成果物、関係者を調べ、弁護士へ相談しました。必要な確認書・契約の対応は、事実に沿って当事者と進めました。

アカウントは法人メールへ変更し、複数管理者、多要素認証、復旧手順、退職時停止を整えました。パスワードを表計算へ書き出すのではなく、管理方法とクロージング時のローテーション手順を作りました。すべての技術負債を解消するのではなく、権利と運営継続に直接影響する事項を先に処理しました。

60日前：代表者の仕事を五人へ分ける

代表者の予定表を四週間分析すると、週の約半分が大口営業と見積、残りが採用、障害判断、金融機関、地域団体でした。「後任社長一人」を探すのではなく、営業責任者、開発責任者、管理責任者、買い手の採用部門、譲渡企業代表者の移行期間へ役割を分けました。

最大顧客の障害判断は、過去事例と連絡基準を文書化し、開発責任者が代表者同席で二回対応しました。地域団体は、譲渡成立後に代表者から買い手責任者を紹介する計画にしました。属人性をゼロにしたのではなく、誰へ、どの証拠をもって移すかを決めたことが重要です。

30日前からDD：不利な情報を論点表で管理

DDでは、赤字保守、外注権利、過去の軽微な情報事故、未検収案件、退職意向のある社員について質問が出ました。譲渡企業は一件ごとに、事実、金額・顧客・期間への影響、原因、実施済み対応、残る対応、証拠、最終契約での扱いを一枚にしました。

過去の情報事故については、当時の記録が一部不足していたため、不明な点を「問題なし」とせず、確認できた範囲を明示しました。買い手は追加の権限監査と教育を100日計画へ入れました。未解決論点をゼロと装わず、責任と期限を設定したことで交渉が前へ進みました。

Day1〜90：地域対応を残し、共通機能を統合

Day1は雇用、顧客窓口、障害連絡、給与・経費を維持しました。30日までに上位顧客を共同訪問し、買い手の全国営業網と地域サポートをどう組み合わせるか説明しました。90日までに経理と採用媒体を統合しましたが、地域顧客の一次窓口と現地訪問体制は残しました。

このケースの教訓は、見つかった問題の数で会社の価値が決まるのではなく、重要性を判断し、事実と対策を一貫して説明できるかが重要ということです。譲渡企業の準備は、買い手に安心を与えるだけでなく、譲渡後に社員が混乱する時間を減らします。

23. データルームの具体的な資料一覧と更新ルール

「必要資料一覧をください」と言われてから集めると、提出速度を優先して誤送信や版違いが起きます。次の一覧を自社向けに調整し、資料がない場合は空白にせず「未作成」「該当なし」「確認中」を区別します。

会社・株式・ガバナンス

• 定款、履歴事項、株主名簿、株式移動資料、株主総会・取締役会議事録
• 組織図、職務権限、印章・銀行・契約承認のルール
• 関連会社、役員・株主との取引、個人所有の事業資産
• 事業計画、予算実績、重要会議の意思決定記録

議事録の欠損が見つかっても、後から事実と異なる文書を作りません。会社法その他の取扱いを専門家へ確認し、現存資料と対応方針を記録します。

財務・税務・資金

• 決算書、申告書、勘定科目内訳、元帳、月次試算表
• 売掛・買掛年齢表、借入、保証、担保、リース、保険
• 固定資産、ソフトウェア資産、研究開発、補助金
• 正常収益調整表、事業別損益、資金繰り、運転資金

会計データのエクスポートは、年度、税込・税抜、消費税処理、部門、補助科目を明示します。表計算での手修正値は、元帳へ戻れるよう調整列を分けます。

売上・顧客・案件

• 顧客別月次売上・粗利、上位顧客、顧客集中、解約・失注
• 基本契約、個別契約、発注、検収、請求、入金
• 受注残、商談パイプライン、未検収、クレーム、保証対応
• SaaS・アプリKPI、定義書、コホート、価格プラン、値引き

商談パイプラインは、担当者の感覚的な確度だけでなく、次回行動、決裁者、予算、競合、予定日を示します。買い手が将来売上として扱うかは別途判断するため、受注済みと混ぜません。

人事・労務・外部人材

• 匿名人員表、雇用契約、就業規則、給与・賞与、勤怠、有休
• 採用経路、応募・採用・退職、評価・等級、教育、資格
• 休職、労災、紛争、懲戒など重要事項の必要範囲の資料
• 業務委託・フリーランス・派遣・再委託の契約と実態

個人別情報は、目的と段階に応じてマスキングします。住所、家族、口座、健康情報など、検討に不要な情報を一括で渡さないよう、提出前レビューを設けます。

製品・技術・運用

• サービス構成図、データフロー、ロードマップ、障害・変更履歴
• リポジトリ一覧、開発フロー、テスト、リリース、コードレビュー
• クラウド・ストア・ドメイン・外部サービスの契約と権限台帳
• 監視、バックアップ、復旧、SLA、サポート、技術負債
• OSS・商用ソフトのライセンス、脆弱性管理、端末・資産台帳

技術資料は「最新」「本番と一致」「責任者確認済み」を区別します。構成図の更新日が古い場合は、古いまま最新版と呼ばず、差分と更新予定を示します。

法務・知財・情報管理

• 顧客・仕入・提携・賃貸・借入・保険等の重要契約
• 特許、商標、著作物、ドメイン、職務発明、権利帰属
• 個人情報保護、秘密情報、委託先管理、情報セキュリティ規程
• 訴訟、請求、行政対応、重大クレーム、インシデント

契約書のファイル名だけで管理せず、契約当事者、締結日、期間、更新、終了、関連個別契約をメタデータとして持ちます。紙原本と電子版の所在、押印・電子署名の状態も記録します。

更新ルールと提出前のダブルチェック

資料には担当者と更新頻度を決めます。月次試算表とKPIは毎月、契約台帳は締結・更新時、人員表は入退社・条件変更時、権限台帳は異動・退職・新規サービス時に更新します。DD期間だけ更新するのではなく、クロージングまで差分を管理します。

外部提出前は、作成者以外が、対象会社、期間、顧客・個人情報、パスワード・秘密情報、数式、版、開示レベルを確認します。リンク共有は有効期限、アクセス者、ダウンロード可否を設定し、誤送信時の停止方法を決めます。提出記録には日時、相手、資料番号、版を残します。

24. 売却を延期・中止する判断も準備の成果である

準備を進めた結果、今は売らない方がよいと判断することもあります。重大な契約・知財問題が未解決である、資金繰りが交渉期間に耐えられない、経営者が残れないのに後任がいない、主要顧客の更新直前である、製品障害の復旧中である、といった状況です。売却を急ぐほど条件が悪化する場合は、是正と事業継続を優先します。

一方、業績が完璧になるまで待てばよいとも限りません。経営者の健康、資金、採用、技術の陳腐化、市場競争で選択肢が減ることがあります。延期判断では、解決すべき論点、責任者、必要期間、資金、再開条件を決めます。「またいつか」と保留せず、三か月ごとに株主と見直します。

売却を中止しても、契約台帳、案件別採算、権限整備、キーパーソン育成、顧客引き継ぎは会社の耐久力を高めます。買い手候補から受けた質問を経営課題へ戻し、次回の採用、価格改定、製品投資、金融機関説明に使ってください。M&A準備の価値は成約だけで測りません。

25. 売却準備中も本業と機密を守る社内運営

準備が長引くほど、経営者と管理部門の負荷、情報漏えい、通常業績の低下が起こりやすくなります。売却専用の大人数チームを作るのではなく、知る必要がある人だけで小さな事務局を置き、通常業務と準備業務の時間を分けます。

コードネームと連絡経路

案件名に会社名や「売却」と書かず、社内で決めたコードネームを使います。メール、チャット、共有フォルダの参加者を限定し、個人端末や私用クラウドへ保存しません。印刷物、会議室予約、画面共有、通知プレビューから漏れることも想定します。

候補先や支援者から社員へ直接連絡しないルールを定め、すべての質問を窓口へ集約します。顧客や再委託先への事実確認が必要なときも、相手へM&Aを推測させる質問を独断で行いません。確認目的、説明、担当を事前に決めます。

通常業績を先に見る週次会議

毎週の準備会議は、最初に売上、受注、解約、案件遅延、障害、採用・退職を確認します。資料提出が進んでも本業が崩れれば、企業価値と社員・顧客の信頼を損ねます。DD質問には緊急度を付け、回答期限が通常業務へ与える影響を買い手側とも調整します。

経営者だけがすべて回答すると、承認待ちが増えます。財務、契約、人事、技術ごとに事実確認者を決め、最終承認と法的判断だけを経営者・専門家へ上げます。分からない質問は急いで推測せず、調査方法と回答予定日を返します。

版管理と誤送信対策

ファイル名には資料番号、基準日、版を入れ、外部提出版と社内原本を分けます。顧客名、個人情報、パスワード、数式、非表示列、コメント、ファイル属性を提出前に別担当者が確認します。表計算や文書では、画面上で隠した列や変更履歴が相手に見える可能性も考慮します。

誤送信や不適切なアクセスが起きた場合に、共有停止、ログ確認、関係者連絡、影響評価を誰が行うかを決めます。「秘密保持契約があるから安全」ではなく、技術的・運用的な管理を重ねます。

社内の不安を拡大させない

通常と違う会議や資料依頼が続けば、社員が変化を感じることがあります。虚偽の説明をせず、答えられないことは「経営上の検討事項で現時点では共有できない」とし、通常の品質・事業継続改善として必要な作業を明確にします。

正式発表までは噂への対応窓口を決め、発表後は経営者と買い手が同じ事実を伝えます。秘密管理の目的は社員を軽視することではなく、未確定な情報で長期間不安にさせないことです。説明できる段階になったら、雇用、役割、勤務地、顧客対応、未定事項を誠実に共有します。

FAQ：アプリ開発会社の売却準備でよくある質問

Q1. 赤字の期があっても相談できますか

相談できます。赤字であることだけで可能性は決まりません。赤字が先行開発投資なのか、不採算案件や解約による構造的なものか、現預金と資金繰りはどうか、価値ある顧客・人材・技術が残るかを分けます。無理に黒字化を装わず、原因と改善策を資料化してください。

Q2. 売却を社員へいつ伝えるべきですか

一律の正解はありません。DD協力が必要な人、漏えいリスク、成立確度、雇用条件、買い手との発表計画を踏まえて決めます。通常の事業継続策としてできる複数担当化や手順化は、売却を伝える前から進められます。

Q3. 顧客名はいつ開示しますか

初期は匿名の業種・規模・構成で説明し、秘密保持後も必要性を見て段階的に開示します。上位顧客の実名や契約原本は、候補先と目的を絞ってから扱うのが基本です。顧客が少ない地域では匿名情報でも特定され得るため、組合せに注意します。

Q4. ソースコードはDDで全部渡す必要がありますか

必要性と段階に応じて設計します。技術概要、品質指標、リポジトリ構成から始め、限定環境での閲覧などを検討します。秘密鍵や本番認証情報は渡しません。競合候補への開示は特に範囲、アクセス者、複製、ログを管理します。

Q5. 自社アプリのストアアカウントはそのまま譲渡できますか

取引形態、アカウント種別、プラットフォームの現行ルール、関連契約によって対応が異なります。個人名義か法人名義か、アプリ内課金、税・入金、証明書、関連サービスを含めて公式手続を確認し、専門家と移管計画を作ってください。

Q6. 外注先との契約書がない案件はどうしますか

まず対象、成果物、支払、やり取り、権利、秘密情報、現在の関係を事実として集めます。過去日付の書類を作るのではなく、専門家へ相談して確認書や今後の契約整備など適切な対応を検討します。買い手へは未整備の事実と対応状況を開示します。

Q7. 受注残はどこまで売上見込みに入れられますか

契約締結、発注書、口頭内示、提案中を分け、売上化時期、必要工数、粗利、検収条件を示します。すべてを同じ確度で合算しません。契約済みでも解約・変更条件や顧客側前提があるため、原契約に基づき説明します。

Q8. 経営者が退任すると売却できませんか

退任自体で決まるわけではありません。ただし、営業、採用、見積、障害、技術、地域関係のどれを経営者が担うかを可視化し、後任と移管期間を示す必要があります。残留可能期間を早めに伝え、現実的な引き継ぎ計画を作ります。

Q9. 買い手候補は同業と異業種のどちらがよいですか

同業は顧客・技術を理解しやすく、異業種は新しい販売網や資本を提供できる可能性があります。一方で、同業には情報開示・重複整理、異業種には運営理解・統合能力の課題があります。価格、雇用、顧客、実行力を同じ評価表で比べます。

Q10. 最低限、何年分の数字が必要ですか

案件や買い手によりますが、直近複数期の決算・税務資料と当期月次、事業別・顧客別推移を求められることが一般的です。古い期間を無理に精緻化するより、取得可能範囲と欠損理由を示し、直近から継続更新できる仕組みを作ります。

Q11. M&A準備中に採用や開発投資を止めるべきですか

通常事業に必要な合理的投資を機械的に止めるべきではありません。ただし、大型採用、長期契約、大規模刷新など将来負担を変える判断は、計画と進捗を整理し、交渉段階に応じて買い手と協議します。本業低下を避けることが最優先です。

Q12. セキュリティ事故が過去にあると成立しませんか

事故の存在だけで一律に決まりません。影響範囲、報告、顧客対応、原因、再発防止、現時点の残存リスクを説明します。隠して後から見つかる方が重大です。個別の法的対応は専門家と確認してください。

Q13. 事業譲渡と株式譲渡のどちらがよいですか

譲渡範囲、契約承継、許認可、税務、債権債務、社員、アカウントなどの扱いが異なり、会社ごとに適否が変わります。希望する範囲と引き継ぎ対象を先に整理し、法務・税務の専門家と比較します。

Q14. 売却価格を上げるため、直前にコストを削るべきですか

不要費の見直しは有効ですが、保守人員、セキュリティ、採用、品質を削って短期利益だけを作ると、継続性を損ねます。正常収益では、将来必要な費用も見ます。削減理由と事業影響を説明できる施策に限定してください。

Q15. アプリ開発M&A総合センターへの相談段階で何を用意すればよいですか

完璧なデータルームは不要です。直近の決算資料、事業概要、社員数、主な顧客構成、サービス・収益モデル、売却を考える理由、希望時期があれば初期整理を始められます。不足資料を含め、180日ロードマップのどこから着手するかを一緒に確認します。

まとめ：資料を作るのではなく、引き継げる会社を作る

アプリ開発会社の売却準備では、売上の説明、契約の整備、知財の権利、コードとアカウント、人材、顧客、地域の信頼を一つの引き継ぎ計画へ結びます。180日前には目的と条件、150日前には事業と契約、120日前には財務と採算、90日前にはデータルームと技術、60日前には人材・顧客、30日前には段階開示を整えます。基本合意とDDでは前提を検証し、最終契約後はDay1、30、90で事業継続と暗黙知移管を実行します。

アプリ開発M&A総合センターは、譲渡企業の着手金・中間金・成功報酬を含めて手数料0円です。「まだ売ると決めていない」「何がリスクかだけ知りたい」という段階でも、準備の順番を整理できます。社員、顧客、サービスの将来を守るために、最初の一歩として現状の棚卸しをご相談ください。

参考資料

• 中小企業庁「中小M&Aガイドライン（第3版）」
• Apple「App Store Connect Analytics：Metric definitions」
• Google Play Console ヘルプ「アプリの統計情報を見る」
• Stripe Docs「Billing analytics」
• 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
• 株式会社ストライク「安心の報酬・料金体系」

免責事項

本記事は、アプリ開発会社・受託開発会社のM&A準備に関する一般的な情報提供を目的としたもので、法務、税務、会計、労務、情報セキュリティその他の個別助言ではありません。取引形態、契約、知財、個人情報、税務、経営者保証、社員・顧客対応は各社の事情と時点により異なります。実行前に、弁護士、税理士、公認会計士、社会保険労務士その他の適切な専門家へご相談ください。