地域のアプリ開発会社がM&A前に整理すべき「保守契約」と「属人化」の論点

地域の開発会社は、売上よりも「引き継げるか」を見られる

地域密着で長く事業を続けてきたアプリ開発会社には、数字に表れにくい価値があります。たとえば、製造業の現場に合わせた業務アプリ、医療介護の予約・記録システム、物流会社の配車や在庫管理、自治体や学校向けの連絡アプリなどは、単なるプログラムではなく、地域顧客の運用を理解したうえで成り立っています。買い手が見たいのは、その理解が会社として引き継げる状態になっているかです。

売上が安定していても、問い合わせ先が社長の携帯だけだったり、古い管理画面の仕様を一人の担当者しか知らなかったり、顧客ごとの例外処理がメモ化されていなかったりすると、買い手は譲受後の運用リスクを大きく見積もります。逆に、月額保守、改修履歴、障害対応、顧客別の窓口、外注先との関係が整理されていれば、規模が小さくても「引き継ぎやすい事業」として評価されやすくなります。

地域のM&Aでは、買い手候補も同業の地場SIer、隣県の開発会社、首都圏のDX支援会社、既存顧客に近い事業会社など幅があります。どの候補に見せる場合でも、最初に問われるのは「顧客に迷惑をかけずに引き継げるか」「保守対応を止めずに運用できるか」「代表者が抜けた後も仕様を理解できるか」です。売却価格を考える前に、この3点を説明できる資料を用意することが重要です。

• 月額保守とスポット改修の売上を分ける
• 顧客別の問い合わせ窓口と対応頻度を整理する
• 障害対応、夜間対応、月末処理など運用負荷を見える化する
• 代表者や古参エンジニアに集中している仕様理解を書き出す

保守契約は「金額」だけでなく「負荷」とセットで見る

買い手は保守契約を安定収益として見ますが、同時に運用負荷も確認します。月額5万円の保守が10社ある場合でも、ほとんど問い合わせがない保守なのか、毎週のように電話が入り、担当者が個別対応している保守なのかで評価は変わります。クラウド費用や外部API利用料を譲渡企業側が立て替えている場合、粗利の見え方も変わるため、売上だけを見せても判断が難しくなります。

特に地域の開発会社では、契約書上は保守と書かれていても、実際には軽微な追加開発、Excel出力の修正、月次処理の立ち会い、顧客担当者の操作サポートまで含んでいることがあります。買い手にとっては、その範囲が曖昧なほど譲受後の想定工数が読みにくくなります。譲渡前には、契約書の内容と実際の対応範囲を並べて整理し、必要に応じて顧客との運用ルールも確認しておくべきです。

保守契約の棚卸しでは、顧客名を最初から開示する必要はありません。初期段階では、業種、地域、保守月額、対応頻度、システム種別、担当者、外注先利用の有無を匿名化して一覧化すれば十分です。秘密保持契約を結ぶ前に顧客名を出すと、地域内で噂になりやすい案件ではリスクが高くなります。ノンネームの段階で負荷感を伝え、関心のある候補先にだけ段階的に開示するのが現実的です。

• 保守月額、粗利、クラウド費、外部API費を分ける
• 問い合わせ件数、障害件数、改修依頼の頻度を記録する
• 契約書にない実務対応を洗い出す
• 顧客名を伏せた保守一覧を初期資料として作る

属人化はマイナスではなく、引き継ぎ設計の材料になる

小規模な開発会社で属人化があるのは珍しいことではありません。むしろ、代表者や古参エンジニアが顧客の業務を深く理解しているからこそ、長く保守契約が続いているケースもあります。問題は属人化そのものではなく、買い手がその知識を引き継ぐ道筋を想像できないことです。譲渡企業側が先に属人化の内容を言語化しておけば、買い手は残留期間や引き継ぎ方法を条件に落とし込みやすくなります。

たとえば、製造業の受発注システムであれば、締め処理、在庫調整、取引先ごとの例外、古い端末でしか動かない機能などが論点になります。医療介護のシステムであれば、個人情報の取扱い、現場スタッフの操作慣れ、監査対応、帳票出力のタイミングなどが重要です。こうした情報は決算書には出ませんが、買い手にとっては運用継続の可否を判断する大切な材料です。

属人化を整理する際は、完璧なドキュメントを最初から作る必要はありません。まずは、誰に聞けば分かるのか、どの顧客で例外処理が多いのか、どの処理が手作業なのか、どのバッチや管理画面が古いのかを箇条書きにします。そのうえで、譲渡後3か月、6か月、12か月のどの期間で引き継ぐかを設計すれば、買い手との交渉でも現実的な説明ができます。

• 代表者が把握している顧客別の仕様を一覧化する
• 古参エンジニアしか触れない処理を特定する
• 引き継ぎ期間と残留条件をあらかじめ想定する
• 属人化を隠さず、買い手の不安を下げる説明に変える

ソースコード、クラウド、ストア権限は早めに棚卸しする

アプリ開発会社のM&Aでは、財務資料と同じくらい権限移管が重要です。Gitのリポジトリ、AWSやGCP、Firebase、Apple Developer、Google Play、ドメイン、SSL、決済アカウント、外部API、メール配信サービスなど、事業を動かすためのアカウントが誰の名義になっているかを確認する必要があります。個人名義や外注先名義のままになっている場合、譲渡実行前に移管方法を検討しなければなりません。

買い手は、コードを受け取れるかだけではなく、運用できる状態で受け取れるかを見ています。リポジトリに最新コードが残っているか、デプロイ手順が分かるか、本番環境と検証環境が分かれているか、障害時の連絡先があるか、ストア審査の担当者が誰か、といった実務情報が欠けていると、譲受後のリスクが大きくなります。

地域の受託開発会社では、顧客ごとにクラウド環境が異なることも多く、同じ会社の中に古いオンプレミス、レンタルサーバー、AWS、Firebase、kintone連携などが混在している場合があります。すべてを整備してから売却相談を始める必要はありませんが、どこに何があるかだけでも整理しておくと、買い手との会話が進みやすくなります。

• リポジトリ、ブランチ、デプロイ手順を確認する
• クラウド、ストア、ドメイン、決済の名義を確認する
• 外注先や個人アカウントに残っている権限を洗い出す
• 本番環境、検証環境、障害対応手順を分けて整理する

地域内で噂にならないための相談順序

地域のM&Aでは、情報管理の重要性が非常に高くなります。地銀、税理士、商工会、同業者、既存取引先、協力会社が近い距離にいるため、相談先や打診先を誤ると「あの会社が売りに出ているらしい」という話が広がりやすくなります。アプリ名、顧客名、従業員名、リポジトリ名を出す前に、どこまで抽象化して説明できるかを考える必要があります。

初期相談では、社名を出さずに、地域、業種、売上構成、保守契約の有無、代表者の希望、従業員の継続意向だけでも十分です。買い手候補へ打診する段階でも、最初はノンネーム資料で関心を確認し、秘密保持契約を結んだ後に詳細情報を開示します。既存顧客に近い候補先や競合先にいきなり話を出すのは避け、開示範囲と順序を設計することが大切です。

特に、従業員や顧客への伝わり方は事前に決めておくべきです。譲渡が決まる前に従業員へ不安が広がると、開発体制や保守体制そのものが崩れるおそれがあります。顧客に対しても、譲渡後の保守窓口、担当者、契約継続の説明が必要になるため、買い手候補の選定段階から「顧客を守れる相手か」を見ておく必要があります。

• 初期相談では社名やアプリ名を伏せる
• ノンネーム資料で候補先の関心を確認する
• 競合、既存取引先、紹介者との関係を先に整理する
• 従業員と顧客への説明時期を条件設計に含める

相談前に用意しておきたい資料

M&Aの相談前に、すべての資料を完璧にそろえる必要はありません。ただし、保守契約と属人化の状況を大まかに整理しておくと、初回相談の質は大きく上がります。まずは、直近3期の売上と粗利、売上内訳、主要顧客の業種、保守契約の月額、追加開発の頻度、開発体制、外注先、権限一覧を簡単にまとめるところから始めるとよいでしょう。

資料作成で大切なのは、買い手が知りたい順番に並べることです。譲渡企業は技術力や顧客との関係を説明したくなりますが、買い手はまず安定収益、運用負荷、引き継ぎ可能性、情報管理、権利関係を見ます。ノンネーム段階では抽象化した資料で足り、NDA後に顧客名やリポジトリ、契約書、コード、障害履歴を段階的に開示する設計が現実的です。

売却を決めていない段階でも、こうした棚卸しは会社の現状把握に役立ちます。保守が利益を生んでいるのか、代表者依存がどこにあるのか、顧客ごとの採算がどうなっているのかを見れば、売却だけでなく承継、採用、外注、値上げ、契約見直しの判断にも使えます。M&Aの準備は、会社を売るためだけでなく、事業を止めずに次へ渡すための整理でもあります。

• 売上内訳、保守月額、追加開発、粗利
• 顧客属性、業種、地域、契約継続年数
• 開発体制、外注先、担当者別の役割
• リポジトリ、クラウド、ストア、ドメイン、決済権限
• 障害履歴、問い合わせ履歴、未対応チケット

相談前に確認したい実務チェック

売却をまだ決めていない段階でも、M&Aを前提にした棚卸しは会社の現状把握に役立ちます。自社の売上がどの顧客、どの保守契約、どの追加開発、どのプロダクトから生まれているのかを分けるだけでも、買い手に説明できる価値と、社内で改善すべき課題が見えてきます。地域の開発会社では、数字だけでなく、顧客との距離感や代表者依存も重要な判断材料になります。

最初に作る資料は、社外にそのまま出せる完成版でなくても構いません。社名、アプリ名、顧客名を伏せたまま、事業モデル、売上構成、保守契約、開発体制、運用負荷、権限移管の見込み、譲渡理由、守りたい条件を書き出します。この段階で整理しておくと、匿名相談でも具体的な会話がしやすくなります。

次に、買い手が不安に感じやすい項目を先に確認します。ソースコードの所在、クラウドやストアの名義、個人アカウントの有無、外注先との契約、顧客データの取扱い、障害履歴、未対応チケット、古い管理画面、手作業の運用などです。問題があること自体より、譲渡企業が把握していないことの方が買い手にとって不安になります。

地域内で情報が広がりやすい会社ほど、相談先と候補先の管理が重要です。地銀、税理士、商工会、同業者、既存取引先のどこまで話すのかを決め、ノンネーム資料を使って関心を確認します。NDA前、NDA後、最終交渉の各段階で出す情報を分けることで、従業員や顧客への不要な不安を抑えやすくなります。

M&Aの準備は、会社を売るためだけの作業ではありません。保守契約の採算、属人化、顧客別の運用負荷、権限の散らばりを見える化することで、売却しない場合の経営改善にも使えます。将来の承継、採用、外注、値上げ、契約見直しを考えるうえでも、早めの棚卸しには意味があります。

• 直近3期と直近24か月の売上内訳を分ける
• 保守月額、追加開発、初期費用、クラウド費を区別する
• 顧客属性、業種、地域、契約継続年数を匿名化してまとめる
• 代表者や古参エンジニアに集中している仕様を洗い出す
• Git、クラウド、ストア、ドメイン、決済、外部APIの名義を確認する
• 問い合わせ履歴、障害履歴、未対応チケットを整理する
• 候補先に出したくない相手、優先したい相手を分ける

譲渡企業様の手数料は0円。初期相談からご利用いただけます

譲渡を検討している企業にとって、相談時点で費用が読めないことは大きな不安になります。アプリ開発会社やSaaS事業のM&Aでは、資料整理、候補先打診、秘密保持契約、条件調整、技術論点の確認など、検討初期から考えることが多くあります。その段階で高額な着手金や成功報酬の心配が先に立つと、まだ売却を決めていない会社ほど相談しづらくなります。

当センターでは、譲渡企業様から受領する着手金・中間金・成功報酬を0円としています。大手他社では最低成功報酬が2,500万円程度の料金体系が設定されるケースもありますが、当センターでは譲渡企業様の相談のハードルを下げ、まずは事業の整理、譲渡可能性、候補先の方向性、情報開示の順序を確認することを重視しています。

もちろん、外部専門家費用、登記、税務、法務、労務、公租公課、各種実費などは別途発生する場合があります。また、M&Aの成立、譲渡価格、候補先紹介を保証するものではありません。それでも、初期段階で費用を気にしすぎずに相談できることは、地域の開発会社や小規模SaaS事業者にとって大きな意味があります。

相談時には、完璧な資料がなくても構いません。社名やアプリ名を伏せたまま、売上規模、保守契約の有無、主要な顧客属性、開発体制、代表者の希望、守りたい条件だけでも整理できます。売却を決めていない段階でも、どのような買い手候補が考えられるか、どの情報をまだ出さない方がよいか、どこから準備すべきかを確認できます。

• 譲渡企業様の着手金は0円
• 譲渡企業様の中間金は0円
• 譲渡成立時の成功報酬も0円
• 社名・アプリ名を伏せた匿名相談が可能
• 外部専門家費用や各種実費は必要に応じて別途確認
• 売却を決めていない段階でも相談可能