アプリ業界M&Aの実務コラム
アプリ開発・SaaS・受託開発会社の経営者が、売却準備と承継後の事業継続を具体的に進めるための実務情報です。
「うちの会社は売上の何倍ですか」「SaaSならARRの何倍ですか」「エンジニア一人当たりで値段が決まりますか」。アプリ開発会社のM&A相談で、経営者が最初に知りたいのは価格の目安です。しかし、倍率だけを先に置くと、自社の価値を誤って理解する危険があります。同じ売上でも、来年も続く契約か、経営者が抜けても再現できるか、粗利が残るか、知財を承継できるか、顧客と人材が集中していないかによって、買い手の判断は大きく変わるためです。
企業価値評価は、単一のKPIを価格へ変換する作業ではありません。過去実績を正しく把握し、将来キャッシュフローの前提を検討し、類似する取引や会社を参照し、保有資産・負債を確認し、取引条件とリスク分担を交渉する総合判断です。譲渡企業ができる最善の準備は、都合のよい倍率を探すことではなく、事業の継続性、再現性、成長余地を原資料で説明できる状態を作ることです。
この記事の対象読者
- 自社アプリやSaaSを運営し、MRRやユーザー数を企業価値へどう結びつけるか知りたい経営者
- 受託開発、SES、保守運用を併営し、部門ごとの稼ぐ力を整理したい経営者
- M&A仲介会社や買い手から提示された評価の前提を、自分でも検証したい株主
- 売却を半年ほど先に想定し、減額要因を先回りして改善したい経営者
- 地域顧客との信頼、社員の技術、開発資産など、決算書に出ない価値を説明したい経営者
この記事で分かること
- 企業価値、事業価値、株式価値、譲渡対価を混同しない考え方
- SaaS、自社アプリ、受託開発、SES、保守運用で重視されるKPIの違い
- 正常収益、継続性、再現性、顧客集中、粗利を検証する方法
- MRR、ARR、GRR、NRR、ロゴチャーン、売上チャーン、コホートの定義
- 品質、セキュリティ、コード、アカウント、知財、人材が評価へ影響する理由
- 買い手が価格調整や条件変更を検討しやすい減額要因
- 90日・180日で評価の不確実性を減らす改善ロードマップ
結論サマリー
アプリ・SaaS・受託開発会社の価値は、「いくら売ったか」だけでなく、「その売上と粗利が、経営者交代後も、必要な権利と人員が確保され、同じ品質で継続できるか」で見られます。SaaSではMRR・ARRの定義、GRR・NRR、チャーン、コホート、粗利、自社アプリでは利用継続、課金・広告、ストア依存、運用体制、受託では案件別採算、受注残、未検収、変更管理、SESでは稼働、単価、待機、採用・退職、保守では更新、実工数、SLA、障害対応が中心です。
KPIの数値が良くても、定義が途中で変わる、会計とつながらない、顧客一社やキーパーソン一人へ依存する、知財の権利チェーンが切れる、クラウドやストアが個人名義、重大な技術負債が見えない場合、買い手は価格だけでなく支払方法、補償、経営者残留などの条件でリスクを調整します。逆に、弱点を早期に測定し、原因、影響、改善責任者、期限を示せれば、不確実性を減らせます。
1. 「会社の値段」を四つの言葉に分ける
企業価値・事業価値
実務では用語の使い方が案件や評価書により異なることがありますが、一般に、事業が将来生み出す価値を、資金調達構造を含めて捉える概念として企業価値や事業価値が使われます。重要なのは用語の違いを論じることではなく、提示額に現預金、借入、有利子負債類似項目、運転資金、非事業資産がどう反映されているかを数式と例で確認することです。
株式価値
株式価値は株主に帰属する価値を示す考え方です。事業価値から負債等を調整し、余剰現預金等を加える説明がされることがあります。ただし、どの勘定を負債類似と見るか、必要運転資金はいくらか、前受金や未払賞与をどう扱うかは案件で異なります。譲渡企業はラベルではなく、直近貸借対照表を使った計算表を求めます。
譲渡対価と手取り
最終契約に記載される譲渡対価が、クロージング日に全額支払われるとは限りません。分割払い、エスクロー、将来業績に連動するアーンアウト、価格調整、役員退職慰労金などが組み合わさる場合があります。さらに税金、専門家費用、借入・役員貸借の整理が手取りへ影響します。見出しの価格だけでなく、確定額、条件付額、支払日、課税・費用を専門家と確認します。
価格と条件は一体である
買い手がリスクを感じたとき、必ず価格を下げるとは限りません。経営者の残留期間、主要顧客の更新を前提条件にする、表明保証と補償を厚くする、一部を条件付支払にするなど、条件で調整することがあります。譲渡企業は「高い・安い」だけでなく、自分が制御できる条件か、期間が長すぎないか、責任上限は何かを評価します。
2. 企業価値評価の三つの視点
中小企業庁の中小M&Aガイドライン第3版は、中小M&Aの流れや支援の留意点とともに、企業価値・事業価値評価について複数の考え方があることを示しています。実際の評価では、一つの方法だけで機械的に決まるのではなく、会社、事業、取引目的、入手情報に応じて検討されます。
インカム・アプローチ
将来の利益やキャッシュフローを予測し、時間とリスクを反映して現在価値を考える方法です。SaaSの成長投資、受託の受注残、保守更新、採用計画など、将来の事業像を反映しやすい一方、成長率、粗利、解約、人員、投資、割引に関する前提で結果が変わります。
譲渡企業は楽観計画だけでなく、基準・上振れ・下振れを用意します。各ケースで、顧客数、単価、解約、採用、クラウド費、開発投資、営業期間を明示します。将来予測の価値は数字の大きさではなく、過去実績と営業・人員能力から再現できることです。
マーケット・アプローチ
類似する上場会社やM&A取引を参照して価値を考える方法です。ただし、公開会社と地域の未上場会社では規模、資金調達、流動性、成長率、顧客分散、経営体制が違います。取引事例も、対象事業、時期、支払条件、シナジー、非公開条件が異なります。表面的な倍率だけを自社へ当てはめません。
「SaaSだからこの倍率」「受託だからこの倍率」という断定を避け、参照先と自社の差を説明します。継続率、粗利、成長、顧客集中、経営者依存、コード・知財、社員残留、取引規模を比較します。
コスト・アプローチ
貸借対照表上の純資産を基礎に、資産・負債の実態を調整して考える方法です。現預金、売掛金、固定資産、借入が重要な会社では理解しやすい一方、ブランド、顧客関係、社員、ソフトウェア、将来収益力を十分に表さないことがあります。逆に、自社開発費を多くかけたから同額以上の価値があるとも限りません。過去コストと、買い手が今後得る便益は別です。
複数視点を突き合わせる
評価の幅が出たら、中央値を自動的に選ぶのではなく、差の理由を読みます。将来計画が強いが実績が短い、資産は少ないが継続収入がある、類似会社より顧客集中が高いなどです。この差の説明こそ、譲渡企業が改善できる論点です。
3. 買い手が最初に見る四つの軸
継続性
売上や粗利が来月、来年も続く可能性です。契約期間、自動更新、解約履歴、顧客満足、製品利用、受注残、保守更新を確認します。「過去三年続いた」ことは証拠の一つですが、顧客の経営状況、競合、システム刷新、価格改定など将来要因も見ます。
再現性
新規顧客獲得、提案、開発、運用を、経営者や特定社員が抜けても繰り返せるかです。営業パイプライン、提案から受注までの期間、採用経路、見積精度、開発標準、サポート手順、顧客紹介の仕組みを確認します。一度の大型案件は価値がないのではなく、次の案件へつながる能力を説明する必要があります。
収益性
売上から直接費を引いた粗利、さらに維持・成長に必要な人件費、販促、開発、管理を考えます。売上総利益率が高く見えても、経営者が無給でサポートし、開発投資を止め、クラウド更新費を計上していなければ持続しません。会計利益と正常収益をつなぎます。
移転可能性
契約、知財、アカウント、人材、データ、顧客関係が取引後も使えるかです。コードがあっても権利がない、ストアアカウントが個人名義、最大顧客契約に重要な承諾事項がある、開発者が退職予定なら、収益力の移転に不確実性が生じます。
4. 正常収益：過去利益を将来の稼ぐ力へ読み替える
会計利益をそのまま使わない理由
未上場の開発会社では、役員報酬、関連当事者取引、個人的経費、一過性の補助金、事故対応、大型採用、開発投資の時期により利益が変動します。また、経営者が営業、採用、技術、障害対応を無償または低い報酬で担う場合、退任後には代替コストが必要です。
正常収益の検討では、過去損益を「買い手に有利な数字へ直す」のではなく、継続的に必要な収益と費用へ整理します。譲渡企業に有利な足し戻しだけでなく、将来必要な人件費、セキュリティ、保守、クラウド、老朽化対応を減算方向にも検討します。
調整項目の分類
一過性項目には、事務所移転、単発訴訟、特別な補助金、資産売却などが考えられます。一度限りか、別の一過性費用が毎年起きていないかを見ます。
株主・経営者関連には、役員報酬、社宅、車両、保険、関連当事者への賃料・外注、役員貸付・借入があります。私的か事業必要かを証憑で分け、代替費用も置きます。
過少・先送り費用には、未払残業の可能性、必要な採用、保守停止、脆弱性対応、テスト不足、古い端末更新などがあります。今期に支払っていないだけで将来不要とは限りません。
成長投資には、新製品開発、広告、営業採用、海外展開などがあります。どこまで既存事業維持に必要で、どこから任意の成長投資かを分けます。研究開発費をすべて足し戻すと、製品競争力の維持費まで無視することになります。
正常収益ブリッジの作り方
会計上の営業利益等から始め、各調整項目の金額、期間、根拠資料、継続性、買い手による代替可否を一行ずつ示します。関連当事者賃料を足し戻すなら、譲渡後の事務所費を減算します。経営者報酬を調整するなら、経営者の業務一覧と後任コストを示します。
数字を一つに決め切れない項目は、低・基準・高の範囲を置きます。買い手のシナジーで削減できる本社費用は、会社単独の正常収益と分けます。譲渡企業の価値と、特定買い手だから実現する価値を混ぜないことが交渉の透明性につながります。
正常収益チェックリスト
- 調整前の数字が決算・月次試算表に一致する
- 各調整に請求書、契約、給与、元帳などの根拠がある
- 有利な足し戻しだけでなく将来必要費を反映した
- 経営者の業務と代替人材コストを見積もった
- 成長投資と維持投資を分けた
- 買い手固有シナジーを単独収益と混ぜていない
- 全期間で同じ方針を適用した
5. KPIは数字より先に定義を固定する
KPI定義書の必須項目
KPI名、事業上の目的、算式、分子、分母、対象顧客、対象期間、税、返金、無料期間、値引き、一時金、通貨、データソース、更新頻度、責任者を一枚にします。名称が同じでも企業ごとに計算が違うためです。
たとえば「アクティブユーザー」は、アプリを開いた人、特定機能を使った人、ログインした契約社、課金中の人で意味が違います。「解約」も、申請日、契約終了日、MRRがゼロになった月、支払失敗で停止した日が候補です。買い手が再計算できるよう、元イベントから集計までを説明します。
会計、請求、プロダクト分析を三点照合する
SaaS売上は会計、請求システム、プロダクト分析で別の時点を示します。会計は収益認識、請求は契約と入金、分析は利用を捉えます。三つを無理に同じ数字にせず、顧客ID、契約ID、期間でつなぎ、差異を説明します。
年額一括請求、無料期間、返金、未収、従量課金、為替、ストア入金は特に差が出ます。KPI表から会計売上へブリッジを作り、未照合差異は金額と原因を記録します。
定義変更を隠さない
事業の成長に伴いKPI定義を改善することはあります。変更日は、旧定義、新定義、変更理由、影響、過去遡及の有無を記録します。可能なら比較期間を同じ定義で再計算し、旧資料との差異を示します。過去の見せ方が悪かったことより、面談ごとに数字が変わることの方が信頼を損ねます。
6. SaaSで見るKPI：MRR・ARR・GRR・NRRをつなぐ
MRRとARR
MRRは月次経常収益、ARRは年次経常収益を把握する代表的な指標です。しかし、ARRをMRRの単純な年換算とするか、年額契約をどう月割りするか、一時金や従量課金を含めるかは定義が必要です。StripeのBilling analytics資料など、利用している決済・請求基盤の定義も参照し、自社の算式と差異を明記します。
MRRブリッジは、期首MRRに、新規、再開、増額を加え、減額、解約を引いて期末MRRへつなぎます。価格改定や通貨換算の影響は別列にすると、営業・継続の実態が見えます。顧客数が増えても、低単価化や解約でMRRが伸びないことがあります。
GRRとNRR
GRRは、期首の既存顧客から、解約と減額による減少を考慮してどれだけ売上が残ったかを見る考え方です。NRRは既存顧客の増額も加味します。一般的な形では、期首既存MRRから解約・減額を引いたものを期首既存MRRで割るのがGRR、さらに増額を加えるのがNRRです。ただし、再開、従量課金、為替、買収顧客、プラン移行をどう扱うかを定義します。
NRRが高くても、新規顧客が定着しない、大口一社の増額だけに依存する場合があります。GRR、NRR、ロゴ数、上位顧客、コホートを合わせて読みます。
ロゴチャーンと売上チャーン
ロゴチャーンは顧客数の減少、売上チャーンは金額の減少を捉えます。小口顧客十社の解約と、大口一社の解約では、ロゴと売上に逆の印象が出ます。月次率をそのまま年率へ換算すると解釈を誤ることがあるため、算式と観測期間を明示します。
解約理由は、価格、機能不足、導入失敗、利用低下、顧客事情、競合、支払失敗、統廃合へ分類し、自由記述も残します。「顧客都合」でまとめると改善点が見えません。解約申請前の利用低下やサポート履歴とつなぐと、予兆を検証できます。
コホート分析
顧客を獲得月、プラン、業種、チャネル、規模などで群に分け、経過月ごとの継続、売上、利用を見ます。全体平均が改善していても、古い優良顧客が支え、新規コホートの定着が悪化していることがあります。逆に、最近のオンボーディング改善が定着に表れていれば、将来計画の根拠になります。
コホート表は色の見栄えより、母数と定義が重要です。顧客数が少ない場合、一社の動きで率が大きく変わるため、件数と金額を併記します。途中で顧客のIDを統合・分割した履歴も残します。
SaaS粗利とユニットエコノミクス
売上から、クラウド、決済、外部API、顧客サポート、導入作業など直接的なサービス提供費を引いて粗利を見ます。何を原価に含めるかを固定し、社員人件費の配賦も説明します。顧客が増えるほどサポート・個別開発が比例して増えるなら、ソフトウェアらしい拡張性は限定されます。
顧客獲得費や顧客生涯価値を使う場合、営業・広告・人件費の範囲、回収期間、粗利、解約の前提を明示します。短い実績から長期価値を断定せず、チャネル別・コホート別に見ます。代理店経由は獲得費が低く見えても、手数料や顧客関係の所在を考慮します。
7. 自社アプリで見るKPI：ダウンロードより継続と収益構造
プラットフォーム指標の定義を確認する
AppleのApp Store Connect Analyticsの指標定義とGoogleのPlay Console統計情報では、インストール、端末、ユーザー、セッション、売上など複数の指標が提供されています。指標にはオプトイン、期間、端末、集計条件などの前提があるため、画面の数字を社内の「ユーザー数」と同一視しません。
買い手へは、指標名、取得元、期間、フィルター、タイムゾーン、欠損、社内集計との差を示します。スクリーンショットだけでなく、エクスポート可能な元データと更新手順を用意します。
獲得・活性化・継続・収益を分ける
獲得ではストア表示、流入、インストール、顧客獲得費を見ます。活性化では、単なる起動ではなく、事業価値につながる初回行動を定義します。継続では翌日・一定日後・月次など自社に合う期間を選び、コホートで比較します。収益では課金者、購入、サブスクリプション、広告、返金、ストア手数料、決済失敗を分けます。
ゲーム、業務アプリ、地域情報、医療支援では利用頻度が違います。毎日使わない業務アプリを日次アクティブ率だけで低評価にせず、契約目的に沿った利用、業務完了、更新を見ます。逆に、無料利用が多くても課金・広告・送客へつながらなければ、買い手は収益化の仮説を検証します。
ストア・広告・外部プラットフォーム依存
売上が一つのストア、広告ネットワーク、SNS流入、検索順位へ集中している場合、規約、手数料、アルゴリズム、アカウント停止の影響があります。過去の審査差し戻し、警告、削除、広告制限、返金を一覧化し、対応記録を残します。
アプリ内課金、外部決済、広告、アフィリエイトなど収益源ごとに、契約当事者、入金、税、顧客データ、移管可否を確認します。個人名義のデベロッパーアカウント、証明書、署名鍵、ドメインは、譲渡前から公式手続と事業継続策を検討します。
開発ロードマップとストア評価
レビュー平均だけでなく、件数、時期、バージョン、主要不満、返信、改善を見ます。障害後の低評価と、構造的な使いにくさを分けます。ロードマップは要望数だけで決めず、継続・収益・品質への影響、工数、依存、担当を示します。
更新頻度が高ければ価値が高いわけではありません。リリースの予測可能性、変更失敗、ロールバック、審査対応、重大不具合、サポート終了OSへの方針を説明できることが重要です。
8. 受託開発で見るKPI：案件別粗利と受注の質
案件別採算
受託開発では、全社粗利より案件別の契約額、追加発注、外注費、実工数、標準人件費、進捗、検収、残作業を確認します。工数を記録していない場合、黒字案件が優秀なのか、経営者や社員の無償残業で成立したのか分かりません。
案件完了時の粗利だけでなく、着手時見積、月次予測、完了見込みの変化を見ます。見積と実績の差が小さい会社は、価格設定とプロジェクト管理の再現性を示しやすくなります。赤字案件は原因を要件追加、見積不足、品質、外注、顧客遅延、技術難度、管理不在へ分けます。
受注残
受注残は将来売上の参考になりますが、契約締結済み、発注書受領、口頭内示、提案中を混ぜません。売上化時期、必要工数、予想粗利、検収、解約・変更、顧客側の準備を記載します。大きな受注残でも、採用できなければ消化できず、外注費高騰で粗利が残らないことがあります。
買い手は、受注残の金額とともに、引き継ぎ可能なチーム、顧客関係、契約上の地位、プロジェクトリスクを見ます。譲渡企業経営者が退任すると要件合意できない案件は、受注残の質が低下します。
未検収・未請求・仕掛
未検収には、正常な顧客テスト中、修正残、仕様争い、顧客都合の延期など異なる状態があります。請求可能日、残工数、損失見込み、顧客確認を整理します。売上計上の妥当性は会計方針と契約に基づき専門家と確認します。
未請求売上や仕掛を増やして利益を見せるのではなく、原契約、進捗、検収、請求、入金へつなぎます。長期滞留は案件別に理由を説明します。
顧客集中と営業再現性
上位顧客の売上比率だけでなく、粗利、更新・受注頻度、意思決定者、競合、担当者、失注影響を見ます。最大顧客が全売上の大半を占めても、長期契約と高い切替コストがあれば一面では安定しますが、一度の失注影響は大きくなります。リスクを隠さず、複数部署への関係拡大、契約期間、次回案件、他顧客開拓を示します。
営業再現性は、リード源、提案数、受注、期間、単価、粗利、失注理由で確認します。代表者の地域人脈だけなら、その人脈を誰へどう移すかが論点です。紹介者の個人情報を一覧で開示するのではなく、紹介経路と実績を整理します。
変更管理と品質
受託の利益は、契約後の変更管理で大きく変わります。要望、影響見積、顧客承認、追加費用、納期変更をチケットや変更票で追います。追加要望を「サービス」として無償対応し続ける会社は、顧客満足が高く見えても利益の再現性が低くなります。
欠陥件数だけでなく、重大度、流出工程、再作業工数、顧客影響、原因、再発防止を見ます。テストが多いことより、リスクに応じたレビューと自動化、リリース判定、障害学習が機能しているかが重要です。
9. SES・常駐支援で見るKPI：人員数より人材経済性
稼働率と待機
稼働率は、分母を在籍者、稼働可能者、営業対象者のどれにするかで変わります。入社直後の研修、育休、管理職、受託兼務をどう扱うかを定義します。月末一日時点ではなく、月中の入退場と部分稼働も反映します。
待機は日数、給与、採用経路、理由、次回入場までの期間を見ます。待機ゼロを優先して低単価案件へ固定すると、長期粗利とキャリアが悪化することがあります。待機を営業力、育成、案件ポートフォリオと一緒に評価します。
人材別・契約別粗利
契約単価から給与だけを引くのではなく、社会保険、賞与、採用、教育、交通、管理、待機をどこまで含めるかを決めます。個人別情報は初期に匿名化し、職種、経験、資格、単価、契約更新、粗利、顧客、上位会社、退職懸念を一覧化します。
高粗利社員が一人に集中している場合、その退職は売上と採用コストに影響します。評価は人を資産のように所有する発想ではなく、社員が残りたい仕事・処遇・成長機会と、顧客契約が続く条件を検討することです。
商流、再委託、契約実態
エンド顧客までの商流、契約当事者、再委託承諾、単価、更新、指揮命令の実態を確認します。契約書の名称だけで適法性を断定せず、労務・法務の専門家と運用を点検します。多重商流は一律に悪いのではありませんが、単価交渉、顧客関係、情報伝達、契約継続の制約があります。
採用と退職の再現性
応募、面接、内定、入社、定着を職種・経路別に追います。採用人数だけでなく、採用費、採用期間、入社後単価、育成、早期退職を見ます。代表者の知人採用が中心なら、買い手の採用力で拡大できる可能性と、文化が変わるリスクの両方を検討します。
10. 保守運用で見るKPI：更新率より提供義務と粗利
契約継続の質
保守契約は、自動更新、解約通知、価格改定、SLA、対応時間、障害、セキュリティ、再委託、顧客環境の変更を確認します。更新実績が長くても、価格が据え置かれ、提供範囲だけ広がっていれば将来粗利は下がります。
顧客別に月額売上、クラウド・ライセンス、担当工数、夜間休日、訪問、障害、問合せを集計します。小口顧客は一社当たり利益が小さくても標準化されていれば安定し、大口顧客は個別対応が多いと粗利が低いことがあります。
SLAと障害対応能力
契約上の応答・復旧条件と実績を照合します。達成率だけでなく、重大障害、平均復旧に関する指標、再発、顧客影響、補償、当番負荷を見ます。件数が少ないことが安全を意味するとは限らず、検知・記録されているかが重要です。
手順書、監視、バックアップ、復旧試験、エスカレーション、顧客連絡を確認します。一人のベテランがすべて判断する場合、契約は継続しても提供能力が移転しません。
価格改定余地
値上げ余地を事業計画へ入れる場合、顧客価値、競合、契約、過去改定、説明、解約感応度を示します。「市場価格より安いから一律値上げ」では根拠が弱くなります。対応範囲の標準化、上位プラン、時間外オプション、クラウド実費の扱いを顧客別に検討します。
11. 顧客集中を一つの比率で判断しない
売上・粗利・契約・人材の四面を見る
顧客集中は、上位顧客売上比率、粗利比率、契約期間、担当人材で見ます。売上比率が高くても、長期更新と複数部署展開がある場合と、代表者一人の口約束で単発受注している場合は違います。逆に売上が分散していても、販売代理店一社が顧客接点を握る場合、実質的な集中があります。
グループ企業を別顧客として数えるか、同一意思決定主体としてまとめるかを明示します。自治体関連も、部署・年度が違っても同一予算・調達要因へ依存する場合があります。
最大顧客喪失の感応度
最大顧客が失われた場合の売上、粗利、固定費、余剰人員、外注、運転資金を試算します。社員を直ちに削減する前提ではなく、他案件へ移せるか、何か月必要かを見ます。買い手がクロスセルで依存を下げられるという仮説も、対象顧客と営業期間へ落とします。
分散のために低品質顧客を増やさない
顧客集中を下げる目的で、低粗利・高サポートの顧客を急増させると価値は改善しません。理想顧客像、獲得費、粗利、継続、導入負荷を見て分散します。既存最大顧客との関係強化と、新規顧客の再現性を両立させます。
12. 品質とセキュリティは「コスト」ではなく継続条件
品質指標を事業影響へつなぐ
不具合件数、テストカバレッジ、デプロイ頻度など単一指標で品質を断定しません。重大度、顧客影響、検知工程、再作業、復旧、再発、サポート工数を見ます。自動テストが多くても本番障害を防げない場合、重要経路を覆っているかを確認します。
買い手が知りたいのは、問題が起きない会社ではなく、問題を検知し、影響を限定し、復旧し、学習できる会社かです。障害記録がゼロなら、実際に事故がないのか、記録文化がないのかを区別します。
情報セキュリティの証拠
規程の有無だけでなく、資産台帳、権限棚卸し、端末管理、多要素認証、ログ、バックアップ、復旧試験、脆弱性対応、委託先管理、教育、事故対応の記録を確認します。認証を取得している場合も、対象範囲、更新、例外を示します。認証がない会社でも、実効的な運用を証拠で示せます。
過去事故は発生日、検知、影響、報告、顧客対応、原因、再発防止、完了確認を時系列にします。法的な報告義務等は、個人情報保護委員会のガイドライン（通則編）その他の関係資料と専門家の助言を踏まえて個別に確認します。
セキュリティ負債の優先順位
本番の公開設定、退職者権限、秘密鍵の露出、復旧不能なバックアップ、サポート終了基盤など、事業停止や情報事故に直結する事項を優先します。全システムを最新へする計画ではなく、資産、脅威、影響、代替策、担当、期限を持つリスク台帳を作ります。
13. コード・アカウント・知財：使えることと所有できることは別
権利チェーン
プロダクトごとに、企画、社員開発、業務委託、顧客委託、既存ライブラリ、OSS、商用部品、デザイン、素材、商標、ドメインを整理します。支払った、社内で使っている、リポジトリを持っているという事実だけで、権利帰属や移転可能性を断定しません。雇用・委託・顧客契約を専門家が確認できるよう結びます。
受託成果物の再利用は重要です。顧客固有コードを共通部品へ混ぜた、逆に自社既存部品まで顧客へ譲渡したように読める場合、買い手は利用継続を懸念します。コードの由来をモジュール単位で完全に追えない場合も、重要箇所から調査範囲と不明点を示します。
OSSと商用ライセンス
コンポーネント、バージョン、ライセンス、利用箇所、配布形態、改変、通知、脆弱性を一覧化します。自動スキャン結果は出発点で、誤検知や利用実態を確認します。買い手の利用形態が変わると条件の検討も変わり得るため、専門家と確認します。
商用ライセンスは、ユーザー数、環境、本番・開発、顧客への提供、契約当事者、チェンジ・オブ・コントロール、譲渡、更新費を確認します。無料プランの業務利用が条件に合うかも点検します。
アカウントと秘密情報
クラウド、Git、CI/CD、ストア、ドメイン、DNS、決済、広告、分析、通知、監視、サポートについて、名義、管理者、請求、復旧、多要素認証、移管方法を台帳化します。代表者や退職者の個人メールへ依存する場合、価値あるサービスを買い手が制御できません。
パスワードやAPIキーをデータルームに並べず、承継手順を示します。クロージング時に管理者変更、秘密情報ローテーション、権限確認、操作ログ保存を実行します。
技術負債
技術負債は、古い言語やフレームワークだけでなく、テスト不足、手動リリース、顧客別分岐、文書欠如、監視不足、データ移行困難、特定社員しか触れない領域を含みます。対象、事象、事業影響、発生条件、暫定対応、恒久対応、概算工数、優先順位を記録します。
リファクタリング工数をすべて価格から引くという単純な関係ではありません。買い手が製品統合を予定するなら改修不要なことも、逆に長期運用するなら投資が必要なこともあります。負債を隠さず、経営選択として説明できる状態にします。
14. 人材価値：人数ではなく組織能力を見る
キーパーソン依存
肩書ではなく、止まる業務からキーパーソンを特定します。営業、見積、設計、リリース、障害、採用、自治体手続、医療・製造の現場知識などです。一人が複数の重要業務を持つ場合、その人の退職影響は売上、品質、採用、顧客へ連鎖します。
対策は一時金だけではありません。複数担当、手順、権限分散、後任育成、キャリア、買い手での役割を設計します。社員を所有物のように扱わず、本人が残る合理的な環境を作ります。
開発生産性を単純な行数で測らない
コード行数、コミット数、チケット数は仕事の一側面にすぎず、これらを個人評価や企業価値に直結させるのは適切ではありません。買い手は、計画予測、レビュー、テスト、障害、顧客価値、知識共有、採用・育成がチームとして機能するかを見ます。
プロジェクトのリードタイム、変更失敗、再作業、見積差異を使う場合も、プロダクトと受託、保守では意味が違います。数値で競わせるより、ボトルネック改善へ使っているかを説明します。
採用・育成・退職
職種別に応募、面接、内定、入社、立上がり、定着、退職理由を追います。採用単価が安くても、早期退職や長い待機があれば経済性は悪化します。育成では、研修受講数より、単独担当までの期間、レビュー品質、顧客対応力を見ます。
退職率は母数が小さいと一人で大きく動きます。率と人数、職種、勤続、理由を併記します。売却検討中の退職を隠すと、DDやクロージング条件で問題になります。本人のプライバシーへ配慮しつつ、重要影響を適切に開示します。
経営者の代替コスト
代表者の週を、営業、採用、技術、管理、顧客、地域活動へ分けます。後任一人の給与を置くのではなく、買い手側で吸収できる業務、社内昇格、外部採用、譲渡企業の移行期間へ分けます。代替計画が具体的なら、経営者依存を「残留年数」だけで評価せずに済みます。
15. 地域顧客の暗黙知と関係資産
自治体
自治体向けでは、入札参加、予算年度、仕様、再委託、情報セキュリティ、検収、実績報告、担当変更を整理します。過去実績は強みですが、担当者個人との関係だけでなく、調達の再現性、現場理解、必要資格、書類手順を示します。
医療・介護
医療・介護では、データの機微性、現場停止の影響、端末、問合せ、バックアップ、委託先管理を確認します。院長だけでなく、事務、情報担当、現場リーダーとの関係を記録し、診療・介護を止めない運用知識を手順化します。
製造業
製造業向けでは、工場停止、古い設備、ネットワーク、保全時間、現地対応、設備ベンダーとの役割が価値を左右します。中央集約できる仕事と、地域拠点・現場訪問が必要な仕事を分けます。顧客固有の品番や工程を知る担当者の代替育成も示します。
関係資産を過大評価しない
長年の信頼は重要ですが、経営者が退任しても自動継続するとは限りません。接点、紹介、更新、未解決課題、新責任者の紹介計画を示します。顧客名簿そのものではなく、顧客価値を守る運営能力として説明します。
16. 成長余地：市場規模ではなく実行経路を示す
既存顧客の拡張
クロスセル、上位プラン、追加拠点、追加ID、保守拡張の対象顧客を具体化します。全顧客が対象とせず、利用、契約、予算、決裁者、課題から候補を絞ります。過去の増額実績があれば、期間、提案、成約、粗利を示します。
新規顧客
市場全体の規模だけでなく、理想顧客、リード源、商談化、受注、導入期間、営業人員、獲得費を示します。買い手の販売網との相乗効果は、買い手の顧客のうち何社が対象となるか、誰が提案するか、製品の適合性と導入能力があるかを検証します。
価格と商品設計
値上げは成長施策ですが、解約、競合、契約、サポート範囲を伴います。プラン別粗利、利用、支払意思、過去値上げ、顧客反応を示します。安価な顧客を一律に切るのではなく、標準化、セルフサポート、最低料金、オプションを検討します。
買い手シナジーと単独計画を分ける
単独でも実行できる改善と、買い手のブランド、資本、顧客、採用、インフラがあって初めて可能な施策を分けます。シナジー価値の配分は交渉事項ですが、譲渡企業が具体的な仮説を持つことで、相性の良い買い手を選びやすくなります。
17. 買い手が減額・条件調整を検討しやすい要因
数字の不一致
会計、請求、KPI、顧客台帳の売上がつながらず、質問のたびに数字が変わる状態です。差異自体より、原因不明と更新不能が問題です。元データ、定義、ブリッジ、版管理を整えます。
継続性の誤認
一時金をMRRへ含める、口頭内示を受注残へ含める、期限付き契約を永続収入として扱うなどです。売上を経常、一時、契約済み、見込みへ分け、解約・更新条件を示します。
顧客・人材集中
最大顧客、代理店、一人の開発者、代表者に利益や権限が集中している状態です。短期に分散できなくても、影響、契約、複数担当、移管、残留、代替期間を示します。
低粗利・赤字案件の不可視化
全社黒字でも案件別工数がなく、損失案件と残作業を把握できない状態です。過去推計の精度を明示し、今日から記録、月次予測、変更管理を始めます。
未検収・長期売掛・返金
売上の実在性、期間帰属、回収、顧客満足に懸念が生じます。案件別に契約、納品、検収、請求、入金、残作業、紛争兆候を整理します。
契約と実態の不一致
再委託禁止なのに外注、成果物の権利が不明、請負と実態のずれ、必要承諾未取得などです。隠さず専門家へ相談し、是正、承諾、開示、条件対応へ分けます。
知財・アカウントの移転不能
外注コードの権利が不明、ストアやドメインが個人名義、OSS条件が未確認、退職者だけが管理者といった状態です。権利チェーンと権限台帳を作り、公式手続を確認します。
技術負債・セキュリティ
サポート終了、バックアップ未検証、秘密情報露出、重大事故の未対応、手動リリース、単一障害点などです。全部を刷新せず、事業影響と優先順位、暫定・恒久対応を示します。
予算の根拠不足
市場規模だけで急成長を置き、営業人員、採用、導入能力、解約、投資を反映していない状態です。売上を顧客数、単価、継続、獲得経路へ分解し、基準・上下ケースを作ります。
DD中の本業悪化
経営者が資料対応へ集中し、商談、更新、品質、採用が落ちると、直近実績が悪化します。資料責任者、Q&A承認、週次時間枠を決め、通常業績を最初に確認します。
不利事実の後出し
質問に直接関係しないと思って伏せた事実が、後から重大論点になることがあります。開示要否は自己判断だけでなく専門家と確認し、事実、影響、対応を論点表にします。
18. 評価を支えるエビデンス・パック
財務パック
決算・税務、月次試算表、事業別損益、顧客別売上・粗利、正常収益、資金繰り、運転資金、売掛・買掛、借入を一つの索引でつなぎます。すべての表は決算書合計へ戻れるようにします。
商業パック
顧客・契約台帳、更新・解約、受注残、パイプライン、価格、競合、顧客面談、満足・クレームを含めます。実名版と匿名版を分け、開示段階を設定します。
KPIパック
定義書、元データ、計算式、月次推移、コホート、会計ブリッジ、変更履歴をそろえます。ダッシュボード画像だけでは再計算できないため、集計プロセスを示します。
技術・知財パック
構成図、ロードマップ、障害、品質、権限、リポジトリ、OSS、ライセンス、権利帰属、技術負債、セキュリティを含めます。秘密鍵・パスワードは除き、承継手順を別にします。
人材・組織パック
匿名人員表、組織、職務、給与等の必要情報、採用、退職、稼働、キーパーソン、代替育成、経営者業務を整理します。個人情報は段階に応じて最小化します。
19. 簡易ケーススタディ1：成長中SaaSの数字を組み替える
以下は理解のための架空例で、特定企業の評価や価格を示すものではありません。ある業務SaaSは売上が伸び、「ARRが大きい」ことを強みとしていました。しかし集計には初期導入、個別開発、年額契約の一括計上が混在し、買い手は経常部分を再計算できませんでした。
譲渡企業は顧客・契約IDを統一し、月初MRR、新規、増額、減額、解約、月末MRRを作成しました。初期導入と個別開発を分け、GRR、NRR、ロゴ・売上チャーンを同一定義で再計算しました。さらに獲得月別コホートで、新しい顧客ほど導入後の利用が改善していることを示しました。
一方、最大顧客の大幅増額がNRRを押し上げていること、サポート工数を原価へ十分に配賦していないことも判明しました。譲渡企業は有利な指標だけを提示せず、最大顧客を除く感応度、顧客別粗利、標準オンボーディング計画を示しました。
このケースで改善したのは、倍率ではなく判断可能性です。買い手は経常収益、集中、粗利、改善余地を分け、将来計画の前提を置けるようになりました。
20. 簡易ケーススタディ2：受託会社の受注残を精査する
架空の受託会社は、翌期売上に相当する大きな受注残を説明していました。しかし、内訳には契約済み、発注書待ち、口頭内示、提案中が混在し、工数と外注費も入っていませんでした。過去の大型案件では要件追加を無償対応し、粗利が低下していました。
譲渡企業は確度を四段階に分け、契約済み分には売上予定月、残工数、担当、外注、検収、顧客側前提を付けました。未検収案件は、テスト中、修正残、仕様協議へ分けました。過去案件では見積と実績の差を原因別に分析し、変更票と週次原価予測を導入しました。
集計後、受注残の見かけの金額は減りましたが、消化可能な粗利と必要人員が明確になりました。買い手は不足人員を自社から補える案件と、顧客承認が必要な案件を分けました。譲渡企業は弱い見込みを外すことで、確度の高い部分を説明しやすくなりました。
21. 簡易ケーススタディ3：SES・保守の人材依存を解く
架空の地域IT会社は、SESの高稼働と保守の継続契約を強みとしていました。しかし、高粗利案件の多くを二人のベテランが担当し、最大顧客の工場システムは一人しか復旧できませんでした。人員数は十分でも、能力と顧客関係が集中していたのです。
譲渡企業は匿名人材表を作り、職種、単価、粗利、契約更新、担当顧客、権限、代替期間を整理しました。工場保守では障害事例、連絡、復旧、設備ベンダーを文書化し、二人目が訓練に参加しました。社員面談では、買い手での役割、地域勤務、技術キャリアを具体化しました。
依存は半年で完全には解消しませんでしたが、影響範囲、残留意向、育成進捗、買い手の補完人材が見えるようになりました。買い手は「二人が辞めたら全売上が失われる」という不確実な最悪想定ではなく、案件別の移行計画を検討できました。
22. 90日改善プラン：定義と証拠を整える
1〜30日：測る対象を固定
最初の30日は、価格を上げる施策より、数字を確定します。収益モデル別損益、顧客・契約台帳、案件別採算、KPI定義、権限・知財台帳を作ります。会計、請求、プロダクト分析の差異を洗い出し、未解明額を記録します。
経営者業務を一週間単位で記録し、キーパーソン、最大顧客、赤字案件、未検収、長期売掛、退職者権限を優先します。重大な法務・税務・労務・セキュリティ論点があれば、自己判断で直さず専門家へ相談します。
31〜60日：弱点へ担当と期限を置く
KPIを同一定義で過去へ再計算し、月次更新手順を作ります。赤字案件は残作業と損失見込み、受注残は確度と粗利、SaaSはコホート、SESは待機・退職、保守は実工数を集計します。
個人名義アカウント、単独管理者、外注契約、OSS、バックアップ、重大技術負債を優先し、暫定対応と恒久対応を分けます。社員へ売却を伝えずにできる複数担当化と手順化を開始します。
61〜90日：買い手の検証を模擬する
第三者が、KPI表から元データと会計へ辿れるかを確認します。最大顧客喪失、キーパーソン退職、解約増、採用遅れの感応度を試算します。企業概要書の強みとリスクが原資料に一致するかをレビューします。
仮想DDとして、質問、回答、根拠、開示レベル、期限をQ&A台帳で回します。未完成資料を隠さず、完成条件と担当を示します。90日で業績を劇的に作るのではなく、不確実性を減らすことが目標です。
23. 180日改善プラン：再現性を実績で示す
91〜120日：採算と継続性を改善
受託では見積レビュー、変更管理、週次原価予測を実案件で運用します。SaaSではオンボーディング、解約予兆、顧客別粗利を改善します。SESでは採用チャネルと待機、保守では料金・範囲・複数担当を見直します。
改善施策には開始前の基準値、責任者、目標、顧客影響、判定日を置きます。短期値上げやコスト削減で一時利益だけを作らず、継続と品質を同時に測ります。
121〜150日：組織と権利の移転可能性を高める
キーパーソン業務を二人目へ移し、休暇や模擬障害で代行できるか確認します。代表者の見積・営業・採用・障害判断を役割別に移管します。顧客カルテ、地域関係、再委託先を後任と共有します。
コード・知財・アカウントは、専門家確認と公式手続に基づいて未解決を減らします。すべて解決できなくても、取引前に行うこと、クロージング条件、Day1以降の対応へ分けます。
151〜180日：改善結果と将来計画を接続
半年間の月次KPI、案件粗利、更新、障害、採用、権限改善をまとめます。計画未達も理由と学びを示します。事業計画は、改善実績から新規、増額、解約、採用、投資の前提を更新します。
候補買い手ごとに、販売、採用、技術、地域、管理のシナジー仮説を作り、単独計画と分けます。譲渡企業の希望価格を先に証明するのではなく、相手がどの能力を評価し、どのリスクを解消できるかを対話します。
24. 経営会議で毎月確認する評価ダッシュボード
全社共通
- 売上、粗利、正常収益の前年差・計画差
- 上位顧客売上・粗利、更新、解約・失注
- 受注残、商談、未検収、長期売掛
- 採用、入社、退職、キーパーソン、稼働
- 重大障害、セキュリティ、クレーム、改善
モデル別
- SaaS：MRRブリッジ、GRR、NRR、ロゴ・売上チャーン、コホート、粗利
- 自社アプリ：獲得、活性化、継続、課金・広告、返金、ストア状況
- 受託：案件別見積・予測・実績、変更、検収、再作業
- SES：稼働、待機、単価、人材別粗利、更新、採用・退職
- 保守：更新、実工数、SLA、障害、夜間休日、顧客別粗利
数値の隣には、定義変更、データ欠損、主要変動理由、次の行動を記載します。ダッシュボードの目的は見栄えではなく、経営判断と買い手説明を同じ事実にそろえることです。
25. 複合型IT会社は「足し算」と「共通基盤」を両方見る
多くの地域IT会社は、受託、SES、保守、自社アプリを同じ社員と顧客基盤で運営しています。部門別に価値を考えると理解しやすくなりますが、各部門を別会社のように評価して単純に足すと、売上、人材、共通費、顧客関係、コードを二重に数える危険があります。
まず経済実態を分ける
売上、直接費、担当人員、顧客、契約、利用資産をモデル別に分類します。一人が受託とSaaSに半分ずつ関わる場合は配賦ルールを置き、厳密に測れない期間は推計根拠を記載します。共通費は、人数、工数、売上など合理的な基準で配賦し、全社合計へ一致させます。
自社SaaSが赤字でも、受託社員が開発費を別部門で負担していれば、SaaS単体損益はさらに悪い可能性があります。反対に、SaaSが受託の新規顧客を生み、受託がSaaSの導入収益を生むなら、部門間送客の価値があります。リード、受注、粗利の経路を記録します。
分離可能性を確認する
事業ごとに売却する選択肢を考える場合、社員、顧客契約、コード、クラウド、商標、データ、オフィス、管理機能を分けられるかを確認します。共通認証、共通データベース、同じデベロッパーアカウント、兼務社員があると、技術的・契約的な分離コストが生じます。
分離に必要な期間、追加契約、データ移行、人員、顧客同意を見積もらず、「SaaS部分だけなら高い倍率」という発想で進めると、実行段階で止まります。会社全体、複数事業、一事業の三案を、対価だけでなく実行可能性と残る会社の運営で比較します。
共通基盤の価値を示す
共通の顧客サポート、採用、品質基準、地域営業、デザインシステム、認証、データ分析が各事業の粗利と成長を支える場合、それ自体が組織能力です。担当者、コスト、利用部門、代替可能性を説明します。
ただし、「共通だから効率的」と言うだけでは不十分です。部門別に分けた後、共通基盤を維持した場合と分けた場合の費用、サービス品質、開発速度を比較します。買い手が自社基盤へ統合できる領域と、対象会社固有で残すべき領域が見えてきます。
二重計上を防ぐ確認
- SaaSの初期導入売上を受託売上にも含めていないか
- 兼務社員の人件費を両部門で全額負担していないか、逆にどこにも負担していないか
- 共通コードを複数事業の独立資産として重複評価していないか
- 顧客一社をSaaS顧客と受託顧客として分け、集中を低く見せていないか
- 買い手の本社費削減を各部門の正常収益へ重複して足していないか
- 前受金と将来売上、受注残と事業計画を二重に数えていないか
26. 買い手の類型で「価値の使い方」が変わる
同じ会社でも、買い手が何を持ち、何を不足しているかによって評価する能力が変わります。譲渡企業は候補先ごとに数字を作り替えるのではなく、同じ事実を基礎に、どの能力が組み合わさるかを検討します。
同業の開発会社
同業は、エンジニア、顧客、受注、開発プロセスを理解しやすく、稼働平準化、共同提案、採用、外注内製化の可能性があります。一方、顧客・技術が重複し、統合後の人員配置やブランド整理が論点になります。競合へ顧客名、単価、コードを開示するリスクもあるため、候補選定と段階開示を厳格にします。
確認したいのは、過去買収した開発組織がどう運営されているか、現場責任者は誰か、評価・技術選択・地域勤務をどう扱うかです。「エンジニアが欲しい」だけなら、社員のキャリアと顧客事業をどう守るかを具体的に質問します。
垂直業界の事業会社
医療、製造、物流、建設、小売などの事業会社は、対象会社のアプリ・開発力を自社DXや業界向けサービスへ活用できる可能性があります。現場知識と顧客接点が大きな価値になる一方、受託顧客が買い手の競合である場合、契約継続と情報遮断が問題になります。
対象会社の開発チームが買い手社内の要望対応だけに固定され、外販事業が縮小しないかも確認します。譲渡企業が顧客と社員の成長を重視するなら、外販継続、製品ロードマップ、意思決定、データ分離を交渉します。
大手IT・プラットフォーム企業
販売網、ブランド、セキュリティ、採用、クラウド調達で補完が期待できます。反面、審査・承認・品質基準が増え、地域企業の迅速な対応が失われる可能性があります。統合対象システム、必要認証、リリース承認、顧客契約の標準化にかかる時間と費用を見ます。
譲渡企業のSaaSを買い手の顧客へ販売できるという仮説は魅力的ですが、顧客担当者のインセンティブ、商材競合、提案教育、導入支援、価格を確認しなければ実現しません。
投資会社・ファンド
資本、経営人材、追加買収、管理高度化を提供できる可能性があります。投資期間、成長計画、追加買収、経営者の再出資・残留、将来の売却方針を確認します。短期のコスト削減だけでなく、製品・人材・営業へどの投資を行うかを具体化します。
条件付支払や経営者の役割が複雑になる場合、価格と将来責任を一体で評価します。財務投資家だからITを理解しないと決めつけず、担当チームと外部専門家、過去投資先の運営を確認します。
地域企業・事業承継型の買い手
地域雇用、既存顧客、拠点、信用を重視し、長期運営と相性がよいことがあります。一方、技術投資や採用の規模が十分か、経営者交代後の開発判断を誰が担うかを確認します。地域金融機関や商工団体との関係は、買い手責任者の継続参加があって初めて移ります。
候補先比較では、提示価格、資金確度、事業理解、社員・顧客方針、統合責任者、技術投資、地域方針、経営者残留、契約条件を同じ表で評価します。
27. 感応度分析で「何が価値を動かすか」を共有する
一つの事業計画だけを提示すると、買い手は譲渡企業の楽観性を割り引き、譲渡企業は買い手が保守的すぎると感じます。感応度分析は、価格を機械計算するためではなく、どの前提が将来収益を大きく動かすかを共有する道具です。
SaaS・アプリの感応度
新規顧客数、単価、GRR・NRR、獲得費、導入工数、クラウド原価、開発・サポート人員を動かします。解約だけを悪化させるのではなく、解約増でサポート工数や返金がどう変わるかも見ます。大口顧客一社の増減を分け、全顧客平均へ埋めません。
自社アプリでは、ストア流入、継続、課金率、広告単価、手数料、外部プラットフォーム変更、サーバー負荷を検討します。広告単価やストア順位は自社で制御しにくいため、基準ケースへ過度な改善を置きません。
受託・SES・保守の感応度
受託では受注、単価、工数超過、外注単価、検収遅延、採用を動かします。受注が増えても稼働能力を超えれば、外注増と品質低下で粗利が下がることがあります。SESでは稼働、待機、単価、退職、採用期間、商流、保守では更新、価格改定、対応工数、障害を見ます。
三つのケース
基準ケースは、直近実績と確度の高い施策から作ります。上振れケースは、買い手シナジーや新製品が一定条件で実現した場合を示します。下振れケースは、主要顧客解約、採用遅れ、リリース遅延など現実的リスクを置きます。
各ケースには、発生確率を無理に一つ置くより、先行指標と対応を記載します。たとえば利用低下、商談停滞、退職意向、障害増が見えたら、どの計画へ切り替え、誰が何をするかを決めます。
感応度表で避けること
- すべての良い前提を同時に上振れへ置く
- 売上だけを変え、人件費・原価・運転資金を固定する
- 顧客数が増えても導入・サポート能力を増やさない
- 最大顧客喪失時に社員を即時ゼロコストで削減する
- 買い手シナジーを基準ケースへ確定事項として入れる
- 過去の計画未達を無視して同じ成長率を置く
28. DD質問への回答品質が評価の不確実性を左右する
DDでは、回答が速いことだけでなく、質問へ正面から答え、根拠と基準日があり、他資料と整合することが重要です。回答が遅くても論点が難しい場合は理解されますが、数字が毎回変わる、担当者ごとに事実が違う、重要資料が最後に出ると、買い手は未知のリスクを広く見積もります。
Q&A台帳の項目
質問番号、分野、質問文、意図、一次回答、最終回答、根拠資料、基準日、担当者、承認者、機密区分、提出日、追加質問、契約開示への反映を持たせます。「該当なし」は、誰がどの範囲を確認したかを残します。
良い回答の型
最初に結論を一文で書き、次に対象期間・範囲、事実、金額や件数、原因、対応、残存リスク、根拠資料を示します。たとえば「重大障害はありません」だけでなく、重大度定義、確認期間、障害台帳、軽微事故の有無、監視・記録の範囲を説明します。
不明な場合は「確認中」とし、確認方法と回答期限を示します。推計値なら推計と明示し、元資料、仮定、限界を書きます。法的評価を経営者が断定せず、事実を整理して専門家見解へつなぎます。
悪い回答の例と修正
「契約上の問題はありません」は、全契約を誰が確認したか不明です。「重要顧客契約30件を契約台帳の項目で確認し、再委託承諾が未確認の2件を専門家と対応中」のように、範囲と例外を示します。
「エンジニアは全員残ります」は、本人の意思と将来を断定しています。「匿名面談の対象、現時点の意向、懸念、買い手説明後の再確認予定、キーパーソンの代替計画」を示します。
「コード品質は高い」は、判断基準がありません。「レビュー手順、テスト、重大障害、変更失敗、既知技術負債、改善履歴」を提示します。
開示後の変更管理
DD期間中も新規契約、退職、障害、業績が発生します。基準日以降の重要変化を差分報告し、古い資料を黙って上書きしません。版番号、更新履歴、提出先を管理し、最終契約の表明保証・開示資料へ必要事実が反映されるよう専門家と確認します。
29. 評価を上げようとして逆効果になる施策
短期利益のために品質・保守を削る
テスト、監視、セキュリティ、サポート、採用を止めれば一時的に利益は増えます。しかし、障害、解約、社員疲弊、技術負債として戻ります。正常収益では将来必要費を考えるため、単なる先送りは価値改善になりません。
低価格の長期契約を大量に結ぶ
継続売上を増やすために、解約しにくい低価格契約を結ぶと、将来の原価と機会損失を固定します。契約期間だけでなく、顧客価値、粗利、価格改定、提供能力を見ます。
無理な受注で受注残を膨らませる
売却前の大型受注が、必要人員、外注、納期、検収を伴わない場合、買い手には将来利益より履行負担に見えます。見積レビューと消化計画を通し、赤字リスクを受注残に含めます。
KPIの対象を恣意的に狭める
解約の多い顧客群を除く、無料期間を有料顧客へ含める、直近好調月だけを年換算するなどは、DDで再計算されます。全体値と、合理的に区分したセグメント値を併記し、除外理由を示します。
売却直前に大規模リファクタリングする
既知負債を解消しようと全面刷新すると、納期、障害、開発費が不安定になります。重大リスクを優先し、戦略的刷新は買い手の製品計画と調整します。
社員へ曖昧な残留保証をする
買い手と合意していない給与、役割、勤務地を約束すると、成立後に信頼を失います。確定、方針、未定を分け、質問への回答期限を示します。リテンションは金銭だけでなく、仕事とキャリアを含めます。
リスクを資料から削除する
見せないことで初期評価が高く見えても、後から発見されれば価格、補償、取引継続に大きく影響します。事実、影響、原因、対策、残存リスクを早期に整理し、適切な段階で開示します。
30. 譲渡企業手数料0円と評価の透明性
アプリ開発M&A総合センターは、譲渡企業から着手金・中間金・成功報酬を含めて手数料をいただかない、譲渡企業手数料0円の仕組みです。相談、候補検討、成立の各段階で、譲渡企業側の仲介手数料を理由に手取りが減ることはありません。
M&A支援会社の手数料は、算定基礎、料率、最低額、提供業務、相手方からの報酬などが異なります。総額だけでなく契約内容を確認してください。大手仲介会社が公開する料金説明には、譲渡金額を基準とした階層の例として「譲渡金額5億円×5％＝2,500万円」となる計算が示されています。ただし、実際の成功報酬は契約と算定方式で異なり、アプリ開発M&A総合センターとの単純比較ではありません。出典はストライクの公式料金ページです。
手数料0円でも、企業価値を過大に断定することはしません。評価の前提、KPI定義、正常収益、契約・技術・人材の論点を整理し、買い手が検証できる材料を増やします。売却を決める前に、自社の強みと不確実性を把握する相談にも対応します。
31. 初回面談前のセルフスコアカード
次の質問は価格を採点するものではありません。「はい」が多いほど必ず高く売れるわけでも、「いいえ」があれば売却できないわけでもありません。買い手が追加検証しそうな領域と、改善の順番を見つけるために使います。回答は、はい・一部・いいえ・不明の四段階とし、根拠資料と担当者を横に記載してください。
収益の質
- 直近の売上と粗利を、SaaS、自社アプリ、受託、SES、保守へ分けられるか。
- 顧客別売上・粗利の合計が決算・月次試算表へ一致するか。
- 経常、一時、受注済み、見込みを区別しているか。
- 正常収益の調整に、加算だけでなく将来必要費を含めたか。
- 最大顧客を失った場合の粗利と人員影響を試算したか。
「不明」が多ければ、成長施策より先に会計、請求、顧客、工数をつなぎます。精密さより、同じルールで毎月更新できることを優先します。
KPIの信頼性
- MRR、ARR、GRR、NRR、チャーンなど使う指標に定義書があるか。
- ダッシュボードから元データと顧客・契約IDへ辿れるか。
- 会計売上とKPIの差異を説明できるか。
- 定義変更の日時、理由、影響を記録しているか。
- 全体平均に加え、顧客獲得月や事業区分別の動きを見ているか。
数値が良くても根拠が弱ければ、買い手は再計算に時間を使います。短期の率改善より、監査証跡を整える方が90日では効果的です。
顧客と契約
- 全顧客の契約原本、期間、更新、解約、知財、再委託を台帳化したか。
- 口頭合意、期限切れ、未締結、実運用との不一致を識別したか。
- 上位顧客に、代表者以外の接点が複数あるか。
- 解約・失注・クレームを理由別に記録しているか。
- 顧客名を段階的に開示する基準を決めたか。
契約の強さと関係の強さは別です。長期契約があっても提供品質が悪ければ更新は危うく、口頭関係が強くても経営者退任後の移管には不確実性があります。両方を確認します。
技術・知財・セキュリティ
- 重要コードの作成者、契約、権利、OSSを辿れるか。
- クラウド、ストア、Git、ドメインに複数の適切な管理者がいるか。
- 退職者権限、個人名義、秘密情報の所在を把握したか。
- バックアップから実際に復旧した記録があるか。
- 重大な技術負債を、影響、暫定策、恒久策、工数で説明できるか。
ここで「いいえ」がある場合は、見栄えのよい新機能より、サービス停止・情報事故・移管不能へ直結する項目を先にします。法的評価や事故対応は専門家へ相談します。
人材と組織
- 経営者の週間業務と代替方法を説明できるか。
- 止まる業務ごとにキーパーソンと二人目がいるか。
- 採用、立上がり、退職を職種・経路別に把握しているか。
- 社員へ説明する時期、メッセージ、未定事項の扱いを計画したか。
- 買い手での役割、勤務地、技術キャリアを検討する材料があるか。
人材に関するスコアは社員の優劣ではなく、会社が能力を共有・育成・維持できるかを測ります。退職意向を責めず、働き続ける合理性と代替計画を整えます。
将来計画
- 基準、上振れ、下振れの三ケースがあるか。
- 売上を顧客数、単価、継続、獲得経路へ分解したか。
- 売上増に必要な採用、導入、サポート、運転資金を反映したか。
- 単独で可能な施策と買い手シナジーを分けたか。
- 過去計画との差異と学びを次の前提へ反映したか。
計画は約束ではなく、意思決定の地図です。未達リスクと切替条件が書かれている方が、単線の強気計画より経営能力を伝えます。
取引準備
- 価格以外の必須・重要・希望条件を分けたか。
- 提示額から株式価値、支払、手取りへ至る調整を理解しているか。
- 仲介・FA契約の手数料、専任、直接交渉、テール、解約を確認したか。
- DDのQ&A台帳、開示レベル、承認者を決めたか。
- Day1・30・90の事業継続計画を用意したか。
セルフスコアは一度で終わらせず、90日後と180日後に同じ質問で見直します。回答が「いいえ」から「はい」に変わった項目数だけでなく、未把握だったリスクを特定し、担当者と期限を設定できたかでも進捗を評価します。
32. 評価説明を受けたときに読むべき十の前提
評価資料に大きな金額が書かれていても、その数字が最終対価や手取りとは限りません。譲渡企業は結論ページから読むのではなく、前提、計算、取引条件を順に確認します。理解できない用語はそのまま署名せず、具体的な貸借対照表と計算例で説明を求めます。
1. 評価対象
会社全体、特定事業、株式の全部・一部のどれを対象にしているかを確認します。子会社、非事業資産、代表者所有の商標・不動産、共通コードが含まれるかで範囲が変わります。
2. 基準日
評価がいつの財務とKPIに基づくかを確認します。決算から時間が経っていれば、直近月次、受注、解約、借入、現預金、社員変動を更新します。好材料だけでなく悪化も同じ基準で反映します。
3. 正常収益
どの利益から始め、何を加算・減算したかを一行ずつ確認します。役員報酬や一過性費用を足し戻す一方、後任人件費、開発維持、セキュリティ、採用を含めているかを見ます。
4. 将来計画
顧客数、単価、解約、粗利、採用、投資、運転資金の前提を確認します。過去実績や受注残とつながらない急成長、買い手シナジーを確定扱いした計画は、基準ケースと分けます。
5. 参照会社・取引
類似先を使う場合、事業モデル、規模、成長、顧客集中、地域、時期、上場・未上場の差を確認します。倍率だけでなく、なぜ比較可能と判断したか、どの差を調整したかを聞きます。
6. 現預金・借入・負債類似項目
企業価値等から株式価値等へ橋渡しする計算で、現預金、借入、リース、未払賞与、税、役員貸借、前受金などをどう扱うかを確認します。同じ項目を利益と貸借対照表で二重調整していないかも見ます。
7. 運転資金
必要運転資金の基準額、対象科目、季節性、算定期間を確認します。自治体の年度末、受託の検収、SaaSの年額前受、賞与・税の支払で月により大きく変わる会社は、単月だけを正常水準にしません。
8. 取引条件
全額現金、分割、アーンアウト、エスクロー、価格調整の内訳を確認します。条件付部分は、指標定義、判定期間、経営権、必要投資、情報閲覧、紛争時の手続まで見ます。
9. 表明保証・補償
対価が高くても、譲渡企業の将来責任が広く長ければ実質的な条件は重くなります。知識限定、重要性、期間、上限、免責、開示済み事項を専門家と確認します。
10. 手取りと確実性
税、専門家費用、借入・保証、役員貸借、条件付支払、支払日を含め、株主がいつ何を受け取るかを整理します。最高提示額だけでなく、資金確度、社内決裁、前提条件、破談可能性、社員・顧客方針を比較します。
この十項目を一枚の「評価前提メモ」にまとめ、提案が更新されるたびに差分を記録します。数字が上がった場合も、条件付部分や責任が増えていないかを確認します。譲渡企業が評価手法を専門家と同じ深さで計算する必要はありませんが、何が事実で、何が仮定で、何が交渉条件かは区別できるようにします。
最後に、評価額には幅があり、交渉中も最新実績や発見事項で変わり得ることを株主間で共有します。一人だけが見出し金額を確定価格だと受け止めると、後の条件調整で対立が生じます。主要株主、経営者、専門家が同じ前提表を見て、希望、許容範囲、見送る条件を事前に確認してください。
FAQ：アプリ・SaaS・受託開発会社の企業価値
Q1. 売上の何倍で売れるか、すぐ分かりますか
売上だけでは判断できません。収益モデル、粗利、成長、継続、顧客集中、人材、知財、取引条件が異なるためです。参考倍率を使う場合も、比較対象との差を検討し、インカム・マーケット・コストの複数視点と実際の買い手提案を確認します。
Q2. SaaSならARRが大きいほど高く評価されますか
ARRは重要な情報ですが、定義、成長、GRR・NRR、チャーン、粗利、顧客集中、コホート、開発・運用体制を合わせて見ます。一時金を含めたり、年額入金を一月へ集中させたりせず、経常部分を再計算できるようにします。
Q3. 赤字SaaSでも価値はありますか
赤字だけで一律に決まりません。成長投資による赤字か、顧客獲得や継続、粗利に構造問題があるか、資金と人員がどれだけ必要かを見ます。成長停止で黒字化した数字より、投資と回収の前提を透明に示す方が判断しやすくなります。
Q4. ダウンロード数が多いアプリは高く売れますか
ダウンロードは認知・獲得の一指標です。継続利用、活性化、課金・広告、返金、獲得費、ストア依存、運用費、アカウント・データの承継を確認します。累計ダウンロードが多くても、現在利用と収益が低い場合は分けて説明します。
Q5. MRRと会計売上が一致しないと問題ですか
必ずしも同額にはなりません。MRRは経常収益の管理指標、会計売上は会計方針に基づく数値、請求は契約・入金を表します。年額契約、一時金、従量、返金などの差異をブリッジで説明できることが重要です。
Q6. NRRが100％を超えていれば安全ですか
一つの指標だけで安全とは言えません。大口一社の増額が全体を押し上げ、新規コホートの解約が悪化している場合があります。GRR、ロゴチャーン、顧客集中、コホート、粗利を合わせ、算式を固定します。
Q7. 受注残は全額、企業価値に加算されますか
単純に全額加算されるものではありません。契約確度、売上化時期、残工数、外注、予想粗利、検収、解約・変更、引き継ぎ能力を確認します。すでに会計や将来計画へ反映されている価値を二重に数えないことも重要です。
Q8. エンジニアの人数が多いほど価値は高いですか
人数だけでは決まりません。スキル、役割、顧客、粗利、稼働、採用・退職、チーム開発、残留意向、経営者依存を見ます。社員が買収後に働き続けたい環境と、能力を再現できる組織が重要です。
Q9. 顧客一社への依存が高いと売却できませんか
依存があるから直ちに不可能ではありません。契約期間、更新実績、粗利、顧客関係、切替コスト、担当者、喪失時影響を示します。買い手が関係を維持できる引き継ぎと、他顧客の開拓計画を用意します。
Q10. 技術負債は全部直してから売るべきですか
全部を直す必要はありません。重大なセキュリティ、サービス停止、移管不能に直結する事項を優先します。大規模刷新は買い手戦略と重複することがあるため、影響、暫定対応、恒久対応、工数を示して協議します。
Q11. OSSを使っていると評価が下がりますか
OSS利用自体で一律に下がるものではありません。コンポーネント、ライセンス、利用・配布形態、通知、改変、脆弱性を把握し、条件へ対応できることが重要です。個別の法的判断は専門家へ確認します。
Q12. 買い手のシナジーは売却価格へ必ず反映されますか
シナジーの実現可能性と価値配分は交渉によります。譲渡企業は、対象顧客、販売経路、採用、技術統合、必要期間を具体化し、単独計画と分けます。「買い手なら売上が倍」といった根拠のない期待は避けます。
Q13. 正常収益で役員報酬は全額足し戻せますか
一律にはできません。経営者が退任するなら代替人材・機能が必要です。実際の業務、適正な代替費用、買い手側で吸収できる範囲を検討し、専門家と調整します。
Q14. 売却前に値上げすると評価は上がりますか
値上げ後の継続、粗利、解約、顧客反応まで確認されます。契約と価値に合う改定は有効ですが、短期売上だけを作る急な改定は顧客関係を損ねます。対象、説明、移行、感応度を設計します。
Q15. KPIの過去データが欠けています。売却できませんか
欠損だけで決まるわけではありません。取得可能期間、欠損理由、推計方法と限界を示し、今日から同一定義で記録します。請求、会計、ストア、ログから復元する場合も、推計と実測を分けます。
Q16. 地域の紹介ネットワークはどう評価されますか
紹介者の人数ではなく、案件発生、受注、粗利、継続、経営者交代後の移管を見ます。金融機関、商工団体、大学、元請との関係を、個人情報へ配慮しながら経路と実績で説明します。
Q17. 買い手から低い価格を提示されたらどう確認しますか
価格の算定方法、正常収益、現預金・借入、運転資金、リスク調整、支払条件を項目別に求めます。感情的に倍率だけを争わず、事実誤認、定義差、買い手固有リスク、条件付支払を分けます。
Q18. 譲渡企業手数料0円だと、評価や支援が簡素になりませんか
アプリ開発M&A総合センターでは、譲渡企業の着手金・中間金・成功報酬を含めて0円です。費用の有無と、評価の透明性や準備の質は別の論点です。KPI、財務、契約、技術、人材の根拠を整え、買い手が検証できる状態を重視します。
まとめ：高い倍率を探すより、評価の不確実性を減らす
アプリ、SaaS、受託開発、SES、保守運用の企業価値は、単一倍率で決まりません。正常収益、継続性、再現性、収益性、移転可能性を、収益モデルに合ったKPIと原資料で検証します。SaaSならMRR・ARR、GRR・NRR、チャーン、コホート、自社アプリなら継続、課金・広告、ストア、受託なら案件別採算、受注残、未検収、SESなら稼働・待機・採用、保守なら更新・実工数・SLAが中心です。
数字が良くても、定義不一致、顧客・人材集中、知財不明、個人アカウント、技術負債、セキュリティ、経営者依存があれば条件調整の要因になります。弱点を隠すのではなく、影響、原因、担当、期限を示すことで、買い手が具体的に検討できます。
アプリ開発M&A総合センターは、譲渡企業から着手金・中間金・成功報酬を含めて手数料0円です。まだ売却を決めていない段階でも、自社KPIの定義、正常収益、減額要因、90日・180日の改善順序を一緒に整理できます。数字を大きく見せる相談ではなく、社員、顧客、技術の価値を正しく伝える準備からご相談ください。
参考資料
- 中小企業庁「中小M&Aガイドライン（第3版）」
- Apple「App Store Connect Analytics：Metric definitions」
- Google Play Console ヘルプ「アプリの統計情報を見る」
- Stripe Docs「Billing analytics」
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」
- 株式会社ストライク「安心の報酬・料金体系」
免責事項
本記事は、アプリ・SaaS・受託開発会社のM&A、企業価値評価、KPI整備に関する一般的な情報提供を目的とするもので、法務、税務、会計、労務、情報セキュリティ、企業価値評価その他の個別助言ではありません。評価方法、契約条件、指標定義、個人情報、知財、税務上の取扱いは会社と取引ごとに異なります。実行前に、弁護士、税理士、公認会計士、社会保険労務士その他の適切な専門家へご相談ください。
コメント