【M&A事例解説】ispec、ギフトサービス「SmartThanks」事業をくうるに譲渡

この事例をアプリM&Aとして見る理由

本件は、会社全体の買収ではなく、ギフトサービスという特定事業の譲渡として捉えられる点が重要です。アプリ開発会社やプロダクト開発会社では、受託開発、共同開発、自社サービス、実証実験中のプロダクトが同じ会社の中に混在していることがあります。そのうち、特定のサービスだけを譲渡するケースでは、会社全体の財務だけでなく、対象事業の売上、顧客、コード、契約、運用、権限を切り出して説明する必要があります。

ギフトサービスのようなBtoBまたはBtoC寄りのアプリ事業では、ユーザー基盤、利用シーン、決済、通知、管理画面、カスタマーサポート、外部サービス連携などが論点になります。買い手は、事業を譲り受けた後に、既存ユーザーや取引先を維持しながら運用を継続できるかを確認します。単にサービス名やコンセプトが魅力的であるだけでは足りず、運営に必要な実務情報が移管できるかが重要です。

譲渡企業側にとっては、自社の主力事業に集中するために一部サービスを譲渡する選択肢があります。開発会社が複数のプロダクトを持っている場合、すべてを自社で伸ばすのではなく、より相性のよい会社に事業を引き継いでもらうことで、顧客やユーザーにとっても良い結果になることがあります。この視点は、地域のアプリ開発会社が自社サービスを整理する際にも参考になります。

• 会社全体ではなく特定サービスだけを譲渡する事業譲渡型の論点
• ユーザー、契約、コード、運用権限を対象事業単位で切り出す必要
• 譲渡企業は主力事業への集中、買い手はサービス拡張を狙える
• 譲渡後にユーザー体験を止めない引き継ぎ設計が重要

事業譲渡では、対象範囲の線引きが最初の論点になる

特定サービスの事業譲渡では、何を譲渡対象に含めるのかを明確にする必要があります。サービス名、ドメイン、アプリ、ソースコード、デザインデータ、顧客契約、利用規約、プライバシーポリシー、問い合わせ履歴、決済アカウント、広告アカウント、SNS、運用マニュアルなど、対象範囲を一つずつ確認します。

アプリ開発会社では、同じリポジトリやクラウド環境に複数サービスが入っている場合があります。譲渡対象サービスだけを切り出せるのか、共通基盤をどのように扱うのか、社内の別事業で使っているコードやデザインを含むのか、外部ライブラリの利用条件はどうなっているのかを確認しなければなりません。対象範囲が曖昧なまま交渉を進めると、契約直前に論点が増えてしまいます。

買い手側は、譲り受けるものだけでなく、譲り受けないものも知りたいと考えます。たとえば、既存顧客の一部だけを引き継ぐのか、過去のデータを移せるのか、商標やロゴは含まれるのか、問い合わせ対応の履歴は残るのか、といった点です。譲渡企業側が最初に対象範囲の一覧を作っておくことで、買い手は検討しやすくなります。

• サービス名、ドメイン、アプリ、コード、デザインデータ
• 顧客契約、利用規約、問い合わせ履歴、決済アカウント
• 共通基盤や外部ライブラリの利用条件
• 譲渡対象に含めるものと含めないものの一覧化

ギフト系サービスではユーザー体験と運用継続が価値になる

ギフトサービスのようなプロダクトでは、ユーザーがどの場面で使うのか、贈る側と受け取る側の体験がどう設計されているのか、通知や決済、配送、メッセージ、管理画面がどのように連携しているのかが重要です。買い手は、サービスの見た目だけでなく、裏側の運用が回るかを確認します。

たとえば、法人向けのギフトサービスであれば、発注者、受取者、管理者、決済担当、サポート担当が関わります。個人向けであれば、ユーザー登録、決済、ギフト選択、通知、問い合わせ、キャンセル、返金などが論点になります。どの機能が標準化され、どの部分が手作業で運用されているのかを把握することが、譲渡後の安定運用につながります。

アプリ事業の売却では、ユーザー数や売上だけでなく、ユーザー体験がどの程度仕組み化されているかも評価されます。運用担当者の手作業が多い場合でも、それを隠す必要はありません。むしろ、どの業務が手作業で、どの業務が自動化され、どこに改善余地があるかを整理しておくと、買い手は譲受後の成長施策を描きやすくなります。

• 贈る側、受け取る側、管理者の体験を分けて整理する
• 決済、通知、問い合わせ、キャンセル、返金の運用を確認する
• 手作業と自動化済みの業務を分ける
• 譲受後の改善余地を買い手に説明できる形にする

譲渡企業が準備したい開示資料

このようなサービス事業を譲渡する場合、譲渡企業は対象事業だけの資料を作る必要があります。会社全体の決算書はもちろん必要ですが、買い手が知りたいのは、対象サービスがどのように収益を生み、どのように運用され、どのような顧客やユーザーに支えられているかです。

初期段階では、社名や詳細な顧客名を伏せたノンネーム資料で、サービスカテゴリ、売上規模、利用者属性、課金形態、譲渡理由、希望条件を整理します。NDA後には、月次売上、ユーザー推移、契約書、利用規約、プライバシーポリシー、コード構成、クラウド環境、外部API、問い合わせ履歴、障害履歴、運用マニュアルを段階的に開示します。

サービス単体の譲渡では、譲渡企業会社に残る事業との境界も説明が必要です。開発チームは残るのか、一定期間サポートするのか、顧客対応は誰が引き継ぐのか、ドメインやブランドをどのように移すのか、過去データをどこまで提供できるのか。こうした条件が整理されているほど、買い手は安心して検討できます。

• 対象サービス単体の売上、ユーザー、運用資料
• NDA前のノンネーム資料とNDA後の詳細資料
• コード、クラウド、外部API、問い合わせ履歴
• 譲渡企業会社に残る事業との境界と引き継ぎ条件

買い手側の狙いを想像すると交渉が進めやすい

買い手が特定サービスを譲り受ける理由は一つではありません。既存事業との顧客基盤の重なり、プロダクトラインの拡張、開発済み機能の獲得、運用ノウハウの取得、ユーザー接点の強化、将来のSaaS化や横展開など、さまざまな狙いが考えられます。譲渡企業は、どの買い手に何を評価してもらうかを考える必要があります。

ギフトサービスであれば、EC、福利厚生、マーケティング、HR、ポイント、決済、地域産品、法人営業など、複数の隣接領域と相性があります。買い手候補を探す際は、単にIT企業だけでなく、サービスを活用できる事業会社や、既存顧客に提案できる会社も視野に入ります。

ただし、候補先を広げすぎると情報管理が難しくなります。特にサービス名や顧客名が知られると、ユーザーや取引先に影響が出る可能性があります。譲渡企業は、候補先ごとに開示範囲を分け、関心度が高い相手にだけ詳細情報を出す設計をすべきです。

• 既存顧客への追加提案を狙う買い手
• プロダクトライン拡張を狙う買い手
• 運用ノウハウやユーザー接点を求める買い手
• 候補先ごとに開示範囲と打診順を変える

アプリ開発会社への示唆

本件から、アプリ開発会社が学べるポイントは、特定サービスだけでも譲渡対象になり得るということです。自社の中に、主力ではないが顧客やユーザーがいるサービス、開発済みだが営業リソースを割けないアプリ、別会社の方が伸ばしやすいプロダクトがある場合、事業譲渡という選択肢を検討できます。

一方で、事業譲渡は対象範囲の整理が欠かせません。会社全体を譲渡する場合よりも、何を渡し、何を残すのかを細かく決める必要があります。コード、契約、顧客、データ、運用、ブランド、サポート、知的財産、外部API、アカウント権限を一つずつ確認し、買い手が引き継げる形に整えることが大切です。

地域の開発会社でも、受託開発の中から生まれたアプリ、業界特化の業務システム、保守顧客に使われている小さなSaaSが、買い手にとって価値ある資産になることがあります。売却を決めていない段階でも、サービス単位で棚卸しをしておくことで、将来の承継やM&Aの選択肢が広がります。

• 主力ではない自社サービスも譲渡対象になり得る
• 対象範囲の線引きが交渉の前提になる
• 運用・権限・契約をサービス単位で整理する
• 買い手候補ごとに評価されるポイントを変えて見せる

この事例から譲渡企業が確認したい実務チェック

この事例を自社に置き換えて考えると、最初に行うべきことは「何が事業価値なのか」を買い手の言葉で説明できる状態にすることです。サービス名や技術スタックだけではなく、どの顧客が、どの業務で、どの頻度で使い、どの担当者が保守し、どの権限を移管すれば継続運用できるのかを整理します。アプリやSaaSのM&Aでは、事業の魅力と同じくらい、譲受後に止まらないことが重視されます。

譲渡企業が準備する資料は、最初から詳細である必要はありません。初期相談では、社名、サービス名、顧客名を伏せた状態で、事業カテゴリ、売上規模、収益モデル、導入先の属性、保守体制、譲渡理由、希望条件をまとめます。買い手候補の関心が確認でき、秘密保持契約を結んだ後に、月次売上、顧客別売上、契約書、リポジトリ、クラウド構成、障害履歴、問い合わせ履歴を段階的に開示します。

特に注意したいのは、対象事業の境界です。会社全体の譲渡なのか、特定サービスだけの事業譲渡なのか、コードやブランドは含むのか、顧客契約は移るのか、従業員や外注先は引き継ぐのか、代表者が一定期間残るのかによって、買い手の見方は変わります。境界が曖昧なまま価格交渉に入ると、契約直前に論点が増え、条件調整が難しくなります。

買い手候補を探す際は、価格だけでなく、顧客を守れるか、プロダクトを伸ばせるか、保守体制を維持できるかを見ます。地域の開発会社や小規模SaaSでは、従業員、既存顧客、紹介者との関係が近いため、候補先の選び方と開示順序が重要です。最初から広く打診するのではなく、避けたい候補、優先したい候補、NDA後に詳細を見せる候補を分けて管理します。

事例記事は、個別企業の条件や評価額を推定するためではなく、自社の準備に使う視点として読むことが大切です。どのような買い手が関心を持つのか、何が譲渡対象になり得るのか、どの資料があれば検討が進むのかを自社に置き換えて考えることで、売却を決めていない段階でも、事業承継やM&Aの選択肢を広げられます。

• 対象事業の売上、粗利、継続率、解約理由を整理する
• 顧客名を伏せた導入先属性と利用シーンを作る
• リポジトリ、クラウド、ストア、ドメイン、決済の権限を確認する
• 契約書、利用規約、個人情報、外部APIの条件を確認する
• 譲渡対象に含めるもの、含めないものを一覧化する
• 従業員、外注先、代表者の引き継ぎ期間を想定する
• 候補先ごとに開示範囲と打診順を変える

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

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

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

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

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

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