iPaaS M&A 事例｜Yoom事業譲渡に学ぶSaaSカーブアウトの実務

iPaaS M&A 事例として見るYoom事業譲渡の全体像

事実：Yoom株式会社は2022年6月23日に設立され、2022年7月29日付でTimeTechnologiesからYoom事業を譲り受けました。Yoom側の発表によると、TimeTechnologiesは2021年8月にYoomのサービスを開始しており、新会社は事業譲受と合わせて株主割当増資による8.4億円の資金調達を公表しました。新会社の代表取締役には波戸﨑駿氏、取締役には石井淳史氏と秀島恵理子氏が就任しています。

事実：一方、ブレインパッドは2022年6月28日の取締役会でTimeTechnologiesの全株式取得を決め、同日に株式譲渡契約を締結しました。株式取得が完了したのは2022年7月29日です。完了時の開示で、TimeTechnologiesの事業内容は「LINE特化型マーケティングオートメーション『Ligla』の開発と提供」とされました。Yoomを含む二事業の会社をそのまま取得したのではなく、Yoom事業が新会社へ移った後のTimeTechnologiesを取得した形です。

分析：公開資料に「カーブアウト」という言葉は使われていません。しかし、一社にあった二つの事業のうちYoomをNewCoへ切り出し、残った会社の全株式を戦略的買い手へ譲渡しているため、実務的にはプレクロージング・カーブアウトと説明するのが分かりやすいでしょう。買い手が必要とするLiglaと、創業チームが継続して育てるYoomを別々の器へ分けた取引と読めます。

未開示：Yoom事業の譲渡価額、譲渡対象資産・負債の一覧、移籍した従業員数、顧客契約の承継方法、APIパートナーの承認、データ移行方法、移行サービス契約の有無は公表されていません。また、Yoom株式会社の役員は分かりますが、設立時および増資後の株主構成や持株比率は確認できません。旧TimeTechnologiesの株主と新会社の役員が同じ顔ぶれであっても、役員であることをもって新会社の株主と断定することはできません。

ここで重要なのは、「Yoomをブレインパッドが買収した」と短縮しないことです。ブレインパッドが取得したのはTimeTechnologiesの全株式であり、TimeTechnologiesはそれに先立ってYoomを新会社へ譲渡したと発表しています。検索見出しだけを追うと一連の動きが一件の買収に見えますが、法的主体と資産の移動を分けると、二段階の設計だったことが見えてきます。

NewCo設立からクロージングまでを時系列で検証する

事業譲渡と株式譲渡が近接している取引では、発表日、契約締結日、効力発生日、代金決済日を区別しなければなりません。本件も、TimeTechnologiesの6月28日付発表本文に「譲渡しました」という表現がある一方、買い手の適時開示は6月28日を契約締結日、7月29日を実行日としています。上場会社による日程開示を軸に整理すると、次の順序になります。

2021年8月から2022年1月：Yoomのベータ版と正式版

事実：Yoomは2021年8月にベータ版を開始し、利用者の意見を基に機能改善を進めた後、2022年1月17日に正式版を公開しました。正式版では、自社業務に合わせたデータベースを作る機能と、無料で利用できるフリープランが追加されています。ワークフローをボットが進行する「フローボット」と、複数の情報源を集約するデータベースを組み合わせる設計でした。

正式版の公表資料には、契約書の作成・承認・送付、新入社員の登録後に行う雇用契約書送付やアカウント発行、請求書の生成・送付・保存といった利用例が掲載されています。これは、Yoomが単なるAPI接続ツールではなく、人による承認や文書生成まで含む業務フローを対象にしていたことを示します。

2022年6月23日：Yoom株式会社を設立

事実：Yoom株式会社の設立日は2022年6月23日です。ブレインパッドの取締役会決議と株式譲渡契約締結の5日前に受け皿会社が存在していました。会社設立時点でどこまで交渉が進んでいたかは公表されていませんが、事業譲渡先となる法人をクロージング前に用意していたことは確認できます。

分析：カーブアウトでは、資産を移す先の法人がなければ、顧客契約、従業員、銀行口座、クラウド契約、請求主体を切り替えられません。設立から事業譲受まで約1か月しかないため、実務上は設立登記だけでなく、口座、会計、労務、規程、契約書、システム権限等の準備も並行した可能性があります。ただし、具体的な準備内容は公開されていません。

2022年6月28日：株式譲渡契約を締結

事実：ブレインパッドは2022年6月28日開催の取締役会で、TimeTechnologiesの全株式を取得して連結子会社化することを決議し、同日付で株式譲渡契約を締結しました。取得予定株式は1,153株、取得後の議決権所有割合は100％です。適時開示は株式譲渡実行日を7月29日予定としていました。

TimeTechnologiesも同日、全株式の譲渡契約締結を発表しました。同社は当時、LINE特化型マーケティングオートメーションのAutoLineと、業務自動化プラットフォームYoomを開発・運営していると説明しています。ただし、ブレインパッドの買収理由はAutoLineから改称予定のLiglaに集中し、Yoomを自社製品群へ取り込む説明はありません。

2022年7月29日：二つの移動が完了

事実：Yoom側の発表によると、Yoom株式会社は7月29日付でTimeTechnologiesからYoom事業を譲り受けました。TimeTechnologiesは同日の発表で、ブレインパッドへの全株式譲渡に「先立ち」、自社が開発・運営するYoomをYoom株式会社へ譲渡したと説明しています。

事実：ブレインパッドは同日、TimeTechnologies全株式の取得完了を発表しました。完了時点のTimeTechnologiesの事業内容はLiglaの開発・提供です。代表取締役CEOにはブレインパッド取締役の関口朋宏氏、取締役COOにはブレインパッド側でLigla推進を担う柴田剛氏が就任し、波戸﨑氏はYoom株式会社代表取締役社長とTimeTechnologies取締役を兼任しました。

未開示：同じ7月29日の中で、Yoom事業譲渡の効力発生、TimeTechnologies株式の受渡し、役員変更、所在地変更がどの時刻・条件で行われたかは分かりません。TimeTechnologiesが「これに先立ち」と表現しているため、Yoomを外へ出してから株式取得を完了した順序と読むのが自然ですが、契約上のクロージング手順書までは公開されていません。

2022年8月2日：事業譲受と8.4億円調達を発表

事実：Yoom株式会社は8月2日、新会社設立、Yoom事業譲受、株主割当増資による8.4億円調達をまとめて発表しました。資金の多くをプロダクト開発へ投じ、積極採用、開発チーム強化、活用用途の拡大、UX向上、SaaS連携、販売パートナー連携を進める方針です。

この発表がMARRのM&A速報にも掲載され、本件がM&A事例として広く認識される起点になりました。ただしMARRの記事はYoomの発表への導線が中心で、譲渡価額や契約範囲を追加開示しているわけではありません。取引条件を記述するときは、Yoom、TimeTechnologies、ブレインパッドの一次情報を優先すべきです。

当事会社と二つのSaaSを理解する

TimeTechnologies：一社で二つの成長テーマを運営

事実：TimeTechnologiesは2019年1月23日に設立されました。2022年6月28日時点の資本金は17,077千円で、株主は波戸﨑駿氏43.4％、石井淳史氏41.6％、秀島恵理子氏15.0％と開示されています。当時の事業内容はビジネスオートメーションSaaSの開発と運営で、AutoLineとYoomという二つの製品を持っていました。

AutoLineはLINEを利用したマーケティングオートメーションで、取引後にLiglaへ改称されました。企業の見込客・顧客とのコミュニケーションをLINE上で自動化・最適化するBtoCマーケティング寄りの製品です。これに対しYoomは、複数の業務SaaSをつなぎ、セールス、人事、労務、経理等の反復業務を自動化する部門横断型のプラットフォームでした。

分析：二つとも「自動化」を掲げるSaaSですが、顧客課題と成長エンジンは異なります。LiglaはLINEという大規模チャネル、広告代理店との関係、BtoC企業のマーケティング需要が重要です。Yoomはコネクタ数、業務テンプレート、ノーコードUX、外部APIへの追随、幅広い企業部門への浸透が重要です。同じ開発会社で育てられていても、最適な買い手、販売組織、KPI、投資期間が同じとは限りません。

Yoom株式会社：創業チームが事業を継続するNewCo

事実：Yoom株式会社の設立発表時の代表取締役は波戸﨑氏、取締役は石井氏と秀島氏です。この3名は、ブレインパッドの適時開示に記載された取引前のTimeTechnologies株主3名と同じです。会社所在地も設立発表時点ではTimeTechnologiesの取引前所在地と同じWeWork KANDA SQUAREでした。

分析：この人的連続性は、プロダクトの構想、技術、顧客理解、経営判断を新会社へつなぐ意図を示唆します。第三者が事業だけを買って経営陣を入れ替える取引とは異なり、創業チームがYoomを継続して育てる形です。その一方で、役員名が同じだからといって新会社の株主比率まで同じとは限りません。株主割当増資の引受主体も公開されていないため、「旧株主が売却代金をそのまま再出資した」と断定することもできません。

ブレインパッド：Liglaとの戦略適合を明確にした買い手

事実：ブレインパッドは、顧客データを統合・分析しパーソナライズを行うRtoaster、メール向けのProbance、SNS分析のBrandwatch等を扱っていました。TimeTechnologies取得の目的として、LINEへの対応拡大、Web・アプリ・メール・LINEを横断する統合施策、顧客の認知・獲得からリテンションまでのカバー、両社顧客基盤の融合を挙げています。

ブレインパッドは、Liglaが年間2.2億通のLINEメッセージを配信し、エンタープライズ向けLINE特化型マーケティングオートメーションでトップクラスのシェアを持つと説明しました。これらは会社側の公表値・評価ですが、買い手の投資仮説が「LINE」「マーケティング」「顧客データ」「既存製品との統合」にあったことは明瞭です。

開示財務は会社全体であり、Yoom単体ではない

事実：ブレインパッドの適時開示には、TimeTechnologiesの過去3期の財務が掲載されています。2019年12月期の売上高は29,338千円、2020年12月期は200,682千円、2021年12月期は332,647千円です。3期とも経常利益と当期純利益を計上し、2021年12月期の経常利益は55,785千円、当期純利益は38,991千円でした。

注意：この財務はTimeTechnologies全体の数字であり、LiglaとYoomの事業別内訳はありません。Yoomは2021年8月にベータ版を開始したため、2021年数値へ一定の寄与が含まれる可能性はありますが、金額は分かりません。会社全体の売上高をYoom単体の売上高として扱ったり、株式取得価額を会社全体の過去売上で割ってYoomの評価倍率としたりすることは不適切です。

10.5億円、8.4億円、非公表の譲渡価額を混同しない

本件を記事化するときに最も起こりやすい誤りは、近い時期に出た三つの金額概念を一つにしてしまうことです。M&Aでは、株式価値、企業価値、事業譲渡対価、調達額、資本金、アドバイザリー費用はそれぞれ別のものです。見出しの分かりやすさを優先しても、対象を省略してはいけません。

10億5,000万円はTimeTechnologies全株式の取得額等

事実：ブレインパッドの開示によると、TimeTechnologiesの普通株式取得価額は10億4,700万円、アドバイザリー費用等の概算は300万円、合計は10億5,000万円です。取得株式数は1,153株、取得後の議決権所有割合は100％でした。

この数字は、ブレインパッドがTimeTechnologiesの株式を取得する取引の数字です。7月29日の完了時点でTimeTechnologiesの事業内容はLiglaの開発・提供とされています。したがって「Yoomが10.5億円で売却された」という説明は、取引主体と対象範囲の両方を取り違えています。

8.4億円はYoom株式会社の株主割当増資

事実：Yoom株式会社は事業譲受の発表と合わせ、株主割当増資によって8.4億円を調達したと公表しました。調達資金を用いてプロダクト開発を加速し、採用、開発チーム、用途、UX、SaaS連携、販売パートナー連携を強化する方針です。

資金調達額は、投資家または株主から会社へ入る成長資金です。事業の売り手へ支払う譲渡対価とは概念が違います。増資額が企業価値と一致するとも限りません。発行価額、発行株式数、増資前後の持株比率が分からなければ、プレマネー・ポストマネーの評価額も算出できません。

Yoom事業の譲渡価額は公開資料で確認できない

未開示：Yoom、TimeTechnologies、ブレインパッドの確認できた公表資料には、Yoom事業の譲渡価額がありません。現金で支払ったのか、債権債務と調整したのか、別の契約と一体だったのかも不明です。無償譲渡だったと決めつける根拠も、有償だったと推計する根拠もありません。

分析：10.47億円と8.4億円が近い時期に並ぶため、旧株主が受け取った株式売却代金を新会社へ再投資したように見えるかもしれません。しかし、株式譲渡代金の受領者、税金、増資の払込主体、払込時期、資金経路をつなぐ開示はありません。「資本の再配置を想起させる構造」と分析することはできますが、「売却代金を原資に8.4億円を出資した」と事実のように書くべきではありません。

価格を非公表と書くことは、記事の弱点ではありません。むしろ、分からない数字を分からないまま扱い、異なる対象の金額を峻別することがM&Aメディアの信頼性を作ります。後述するように、Yoom事例から学べる最大の価値は、倍率の推測ではなく、事業境界と資本政策を同時に組み替えた点にあります。

なぜYoomを切り出し、Liglaを残した会社を売却したのか

当事者は、Yoomを切り出した交渉経緯や契約条件を詳しく説明していません。そのため、「公表された目的」と「そこから導く分析」を分ける必要があります。ここではまず買い手と各事業が明言した内容を確認し、その後に合理的な仮説を示します。

公表された事実：ブレインパッドの狙いはLiglaとのシナジー

事実：ブレインパッドは、TimeTechnologiesの子会社化によってLiglaを自社の製品群に加えると説明しました。目的は、国内で重要なマーケティングチャネルであるLINEへの対応、Rtoasterを中心とした製品ラインの拡張、顧客の認知・獲得からリテンションまでのカバー、両社顧客基盤の融合です。

TimeTechnologies側も、ブレインパッドのRtoaster等と連携することで、メールやアプリを含むチャネル横断のコミュニケーションを可能にし、ブレインパッドのデータ活用技術でユーザーごとの情報提供を高度化すると説明しました。また、単独では難しかった機能追加や顧客要望への対応をグループ参画で実現できると述べています。

一方、Yoom株式会社は、調達資金を開発と採用に振り向け、SaaS連携と販売パートナー連携を強化する方針を示しました。Liglaはブレインパッドとの製品・顧客統合を、Yoomは独立会社としてのプロダクト投資を、それぞれ成長戦略の中心に置いています。

分析1：一つの会社にあった異なる投資仮説を分離した

分析：LiglaとYoomは、どちらも自動化を扱いますが、価値の源泉が違います。LiglaではLINE上の顧客接点、マーケティングデータ、広告代理店、BtoC大企業への販売が重要です。Yoomでは多数のSaaSコネクタ、ノーコードUX、部門横断テンプレート、実行基盤、幅広い中小企業への普及が重要です。

ブレインパッドは既存のマーケティング製品、データ統合技術、エンタープライズ顧客を持っていたため、Liglaの成長仮説と結び付きやすい買い手でした。Yoomを同じ会社に残すと、買い手は異なる顧客、異なる競争環境、異なるロードマップも同時に引き受けることになります。Yoomを事前に分けることで、投資委員会、評価、統合責任、製品戦略をLiglaへ集中させやすくなったと考えられます。

分析2：買い手の選好と創業チームの継続意思を両立した

分析：旧TimeTechnologiesの株主3名とYoom株式会社の役員3名が同じであることから、創業チームがYoomの運営を継続する人的な設計が見えます。一方、TimeTechnologiesにはブレインパッド側の経営陣が入り、Liglaの統合を進める体制になりました。一つのチームに二つの戦略を背負わせるのではなく、経営責任を分けた構造です。

創業者にとってM&Aは、必ずしも会社も事業もすべて手放す「完全退出」だけではありません。複数事業のうち、買い手とのシナジーが強い事業を売り、別事業はNewCoで継続する選択もあります。もっとも、これは創業者の希望だけで成立するものではなく、株主、買い手、従業員、顧客、契約相手の合意と、分離可能なシステム・財務が必要です。

分析3：買収対象を明確にしてPMIの複雑性を下げた

分析：複数製品を持つ会社を株式取得すると、法人単位ではすべての資産・負債・契約・従業員を引き継ぎます。買い手が一製品だけに関心を持つ場合、買収後に不要事業を売却するより、クロージング前に対象外事業を切り出す方が、買収後の組織設計を単純にできることがあります。

本件では、完了時のTimeTechnologiesがLigla専業として開示されました。買い手は、Rtoasterとの連携、顧客基盤の融合、開発体制の活用といったPMI目標をLiglaに合わせられます。Yoom側も、ブレインパッドの全社方針に合わせるのではなく、独立した資金とロードマップを持てます。二つの事業に異なる「正しい所有者」を割り当てたと表現できます。

分析4：新会社に成長資金を用意した

分析：事業を切り出しても、資金がなければ新会社は運営できません。給与、社会保険、クラウド費、API利用料、オフィス、採用、開発、顧客サポート、税金を独立して支払う必要があります。Yoom株式会社が8.4億円の調達と具体的な投資方針を同時に示したことは、カーブアウトを単なる資産移動ではなく、次の成長ステージを支える資本設計として扱ったことを示唆します。

ただし、増資の引受人、持株比率、払込日、事業譲渡対価との関係は未開示です。ここから言えるのは「独立運営と成長のための資金を公表した」ことまでです。誰がいくら再投資し、どのようなリターンを想定したかは、追加取材なしに書けません。

別の可能性を排除しない

公開資料だけでは、税務上の理由、会計上の理由、顧客契約上の制約、買い手の投資基準、創業者間の合意、競争上の判断がどの程度影響したか分かりません。Yoomを買い手が評価しなかった、Yoomが赤字だった、Yoomの成長性が高かったといった結論も出せません。良質な事例記事は、合理的な分析を示しつつ、反証可能性を残します。

iPaaSでは何が「売れる事業資産」になるのか

このiPaaS M&A 事例をSaaS売り手の実務へ翻訳すると、最初の問いは「ソースコードを譲渡できるか」ではなく、「稼働中の自動化ネットワークを別法人で継続できるか」です。iPaaSは、自社画面の内側だけで価値を提供しません。顧客が利用する会計、人事、CRM、電子契約、チャット、ストレージ等へ接続し、複数システムの間でデータと処理を動かします。

ソースコードだけでは事業は動かない

一般論：一般的なSaaSの事業譲渡でも、コード、商標、ドメイン、顧客契約、従業員、クラウド環境を確認します。iPaaSではさらに、外部SaaSごとの開発者アカウント、OAuthアプリ、APIキー、Webhook、レート制限、パートナー認定、仕様変更情報が必要です。コードをコピーできても、接続資格が旧会社に残れば、新会社のサービスは顧客データへアクセスできません。

譲渡対象台帳には、Gitリポジトリ、CI/CD、コンテナレジストリ、クラウドプロジェクト、DNS、SSL証明書、メール送信ドメイン、秘密情報保管庫、監視、ステータスページ、サポートシステム、請求基盤、ドキュメント、動画、テンプレートも含めます。会計上の固定資産に載らないアカウントや設定が、Day 1のサービス継続を左右します。

OAuthクライアントとAPI資格は「見えない許認可」

一般論：多くの連携はOAuthで顧客から権限を受けます。OAuthクライアントIDとシークレットが旧会社名義の場合、法人変更に伴ってブランド確認やセキュリティ審査をやり直すことがあります。規約がアカウント譲渡を認めなければ、新会社でアプリを再登録し、顧客へ再認可を依頼しなければならない場合もあります。

この問題は法務だけでも技術だけでも解けません。規約上譲渡できるか、トークンが技術的に継続するか、顧客への通知が必要か、再認可で利用離脱が起きないかを横断して判断します。各コネクタについて、契約主体、アプリ所有者、審査状況、要求権限、トークン保存、クォータ、障害履歴、利用顧客、関連ARR、パートナー窓口を一行ずつ管理すべきです。

iPaaSの障害は複数業務へ連鎖する

一般論：単一機能のSaaSが止まると、その機能が利用できなくなります。iPaaSが止まると、契約書作成は完了したが送付されない、請求書は発行されたが保存されない、人事システムへ社員を登録したがアカウントが発行されない、という部分成功が起こります。復旧後に単純再実行すると、二重請求、二重送信、重複レコードにつながることもあります。

買い手が見るべきなのは稼働率だけではありません。ワークフロー実行成功率、処理遅延、キュー滞留、リトライ回数、冪等性、部分失敗時の補償処理、外部API障害の隔離、レート制限時の挙動、手動復旧工数、顧客別の影響範囲を確認します。重大フローのRTOとRPO、バックアップからの復元実績、障害通知の速度も価値に直結します。

テナント分離と権限設計が信頼の土台になる

一般論：iPaaSは顧客自身のデータだけでなく、接続先SaaSにある従業員、取引先、応募者、請求、契約等のデータを扱います。一顧客の接続情報、実行ログ、データベースレコードが別顧客から見えないことは絶対条件です。テナントIDがアプリ画面だけでなく、データベース、オブジェクトストレージ、検索、ログ、バックアップにも一貫して適用されているかを検証します。

OWASP API Security Top 10 2023は、オブジェクト単位・機能単位・プロパティ単位の認可不備、認証不備、リソース消費、機微な業務フローへの無制限アクセス、SSRF、設定不備、API資産管理不足、外部APIの安全でない利用等を主要リスクとして示しています。iPaaSのDDでは、一般的なWeb診断に加え、顧客が指定するURLへの接続、外部API応答の検証、過剰なOAuthスコープ、トークンや個人データのログ出力を重点確認します。

パートナー関係と運用知識も無形資産である

一般論：連携先の仕様変更を早く把握できるパートナー窓口、共同マーケティング、マーケットプレイス掲載、技術サポートへのエスカレーション経路は、コードに表れない競争力です。APIが同じでも、障害時に相手企業と直接連携できる会社と、公開ドキュメントだけで対応する会社では、復旧時間と顧客信頼が変わります。

Yoomが事業譲受後にクラウドサインのプロダクトパートナー認定を発表し、SaaS連携と販売パートナー連携を強化すると述べたことは、この無形資産の重要性を示す材料です。ただし、取引前の各パートナー契約がどのように承継されたかは公開されていません。

SaaS売り手がカーブアウト前に整えるべき準備

Yoom事例を自社売却へ応用するとき、最初から「同じスキームにすべき」と考える必要はありません。重要なのは、自社のどの事業を誰に渡すと価値が最大化され、残る事業が自立できるかを検討することです。以下は本件で実施されたと確認できた作業ではなく、SaaS売り手に共通する一般的な準備です。

1．売却単位を法人より先に定義する

一般論：複数プロダクト企業は、法人全体、特定製品、特定顧客群、知財とチーム、販売権、地域事業のどこを売却単位にするかを決めます。買い手が欲しいのは法人名ではなく、将来キャッシュフローとシナジーを生む資産群です。どの従業員、契約、コード、データ、ブランドがその資産群に不可欠かを逆算します。

売却単位が曖昧なまま買い手探索を始めると、面談ごとに「その顧客は含むのか」「共通エンジニアは移るのか」「商標は使えるのか」という説明が変わります。買い手は分離コストを読めず、評価額へリスクディスカウントを置きます。売り手は、含むもの、含まないもの、一定期間だけ共有するものを一枚のスコープ表に落とすべきです。

2．プロダクト別のスタンドアロン損益を作る

一般論：会社全体の試算表だけでは、事業譲渡対象の収益力を示せません。月次のMRR、ARR、新規MRR、拡張MRR、縮小MRR、解約MRR、有料顧客数、平均単価、売上総利益をプロダクト別に集計します。無料顧客、PoC、社内利用、休眠アカウントを有料顧客へ混ぜないことも重要です。

費用側では、クラウド、外部API、メール送信、OCR、AI、ストレージ等の従量原価を紐付けます。開発、SRE、サポート、営業、CSが複数製品を兼務する場合は、合理的な配賦根拠を作ります。そのうえで、経理、人事、法務、セキュリティ、オフィス等を新会社が自前で持った場合の追加コストを積み上げます。現在の部門利益が黒字でも、スタンドアロン後は管理コストで赤字になることがあるためです。

3．KPIの定義と元データを揃える

一般論：「導入企業数」は広報に適した指標ですが、買い手が知りたいのは再現可能な収益です。登録企業、アクティブ企業、有料企業、休眠企業、解約企業を分け、定義書を作ります。アクティブの条件が「過去30日にログイン」「過去30日に成功実行」「月内に課金」のどれかで、数字の意味は大きく変わります。

NRRとGRRも、為替、従量課金、返金、プラン変更、休止をどう扱うかで変わります。算定式、対象期間、除外条件、タイムゾーン、月末処理、過去修正方針を文書化し、買い手が請求データから再計算できるようにします。Yoomの公表した「利用社数800社超」を有料顧客数と読み替えられないのは、まさに定義の違いがあるためです。

4．資産・契約のセパレーション台帳を作る

一般論：顧客契約、代理店契約、API契約、クラウド契約、ソースコード、ドメイン、データ、従業員、売掛金、前受金、保険、認証を一覧化し、「対象事業専用」「残存事業専用」「共通」「譲渡不可」「相手方同意が必要」と分類します。共通資産について、譲渡、複製、ライセンス、再契約、TSAのどれで解決するかを決めます。

特に見落とされやすいのが、個人名義の開発者アカウント、創業者のクレジットカードで支払うクラウド、共通メールドメイン、共通の秘密情報保管庫、退職者が管理者のリポジトリです。DDの直前に見つかると、名義変更、本人確認、再審査に時間がかかり、クロージング条件を満たせなくなることがあります。

5．知財の帰属を一筆ずつ確認する

一般論：正社員が職務で作ったコードだけでなく、業務委託、退職者、共同開発先が作ったコード、デザイン、文書、動画、テンプレートの権利帰属を確認します。旧会社の共通ライブラリを売却対象と残存事業の双方が使う場合、どちらが所有し、他方へどの範囲でライセンスするかを決めます。

OSSについてはライセンス一覧とSBOMを整え、コピーレフト義務、著作権表示、ソース提供義務、商用制限、既知脆弱性を確認します。外部SDK、フォント、画像、データセット、生成AIモデルの規約も対象です。知財DDは特許や商標の登録確認だけではなく、サービスを合法的に継続・改変・再販売できる権利の連鎖を確認する作業です。

6．セキュリティを説明ではなく証跡で示す

一般論：「安全に運用しています」という回答だけでは評価されません。IAM一覧、MFA適用、退職者権限削除、脆弱性診断、ペネトレーションテスト、インシデント台帳、バックアップ復元試験、ログ保管、暗号化、鍵管理、サブプロセッサ、BCP、RTO・RPOの証拠を用意します。

Cloud Security AllianceのCloud Controls MatrixとCAIQは、クラウドサービスの管理策を体系的に確認する質問設計の参考になります。認証を取得している場合も、認証名だけでなく、対象法人、対象サービス、適用範囲、取得日、直近審査、除外範囲を開示します。

7．人材移籍と説明計画を作る

一般論：SaaSの価値は人に集中します。アーキテクチャ、例外処理、顧客固有設定、APIの癖、障害復旧を知るエンジニアが移らなければ、コードがあっても運営できません。誰が対象事業に不可欠か、本人は移籍に同意するか、新会社の給与・等級・福利厚生・ストックオプションをどうするかを早期に検討します。

顧客、パートナー、従業員への説明は、秘密保持と事業継続の両方を満たす必要があります。早過ぎる発表は情報漏えいや離反を招き、遅過ぎる発表は信頼を損ないます。契約上必要な通知期限、問い合わせ窓口、請求主体、利用規約、プライバシーポリシーの切替日を統一し、想定問答を用意します。

8．NewCoの運転資金を事業譲渡対価と別に考える

一般論：売上が継続しても、入金サイトと費用支払のずれで資金が不足します。年額前払いの代金を旧会社が受け取っているのに、新会社が一年間サービスを提供するなら、前受収益と履行義務をどう移すかが問題になります。返金、SLAクレジット、未払賞与、クラウド最低利用料も含め、Day 1から12か月の資金繰りを作ります。

Yoom株式会社が事業譲受と同じ発表で8.4億円の資金調達と使途を示したことは、売却対価と残存・新設事業の成長資金を分けて設計する重要性を説明する好例です。ただし、本件の具体的な資金繰りや対価配分は未開示であり、一般論として扱う必要があります。

iPaaS M&A 事例から作る買い手DDチェックリスト

買い手は、売上成長率や導入社数だけでなく、買収後も同じ品質で収益を継続できるかを検証します。iPaaSでは、ビジネス、財務、技術、セキュリティ、法務、人事が強く結び付きます。例えばAPI規約違反は法務リスクであると同時に、主要コネクタ停止による解約とARR毀損につながるビジネスリスクです。

ビジネスDD：顧客数ではなく利用の深さを見る

一般論：登録企業数、有料企業数、アクティブ企業数を分けます。コホート別に、有料転換、ロゴチャーン、GRR、NRR、拡張、縮小を追います。iPaaSでは一社当たりのワークフロー数、接続SaaS数、月間成功実行数、利用部門数も重要です。利用が一つの簡単な通知だけに留まる顧客と、請求・契約・採用を横断する顧客では、解約しにくさが違います。

顧客がどの業務を自動化しているかを分類し、ミッションクリティカル度を把握します。主要コネクタが使えなくなった場合のARR影響、特定パートナーや代理店への依存、大口顧客集中、個別開発比率、導入支援工数を分析します。テンプレートが新規導入を加速するのか、個別設定がサポート負荷を増やすのかも確認します。

競争分析では、機能表だけでなく、顧客が自社開発、RPA、他のiPaaS、各SaaSの標準連携を選ぶ条件を調べます。外部SaaSが同等機能を無料で組み込む可能性、生成AIによる連携作成の容易化、API有料化による原価上昇も考慮します。

財務DD：ARRとキャッシュを一致させる

一般論：ARRは契約一覧、請求、入金、会計売上と照合します。年額契約の全額入金を当月売上やMRRへ誤って計上していないか、無料期間、返金、値引き、販売代理店手数料を反映しているかを確認します。従量課金がある場合は、コミットメント、超過料金、失敗実行の課金を分けます。

粗利はSaaS企業価値の中核ですが、iPaaSでは外部API、OCR、AI、メール、SMS、ストレージ、ログ、データ転送等の原価が顧客利用量で変わります。大量実行する顧客ほど赤字になる価格体系では、利用成長が企業価値を下げることがあります。顧客別、プラン別、コネクタ別に貢献利益を再計算します。

カーブアウトでは、旧会社の試算表から対象事業の売上・費用を切り出すだけでは不十分です。新会社が単独で必要とする経理、人事、法務、監査、セキュリティ、保険、オフィス、採用、管理SaaSを加えたスタンドアロン損益を作ります。旧会社から一定期間サービス提供を受けるなら、TSA終了後のフルランレート費用も示します。

プロダクトDD：ロードマップより現行環境を確かめる

一般論：経営説明用のアーキテクチャ図が本番環境と一致するかを確認します。共有データベース、共有認証、共有ライブラリ、共通監視が残存事業と絡んでいれば、分離工数と障害リスクが増えます。リポジトリとデプロイ単位、クラウドアカウント、データストア、キュー、スケジューラ、外部接続を実環境から棚卸しします。

品質指標として、変更頻度、変更失敗率、平均復旧時間、重大障害件数、サポート問い合わせ、未解決バグ、テスト自動化、依存ライブラリの更新状況を見ます。主要エンジニアにしか分からない手動手順がないか、本番アクセスが個人アカウントに依存していないか、退職者が管理者のまま残っていないかも確認します。

iPaaS特有の検証では、トリガーから最終アクションまでの実行履歴をサンプルします。外部APIがタイムアウトした場合、途中状態をどこへ保存し、何回再試行し、最終的に誰へ通知するかを追います。再実行時に同じ契約書や請求書を二重生成しない冪等性、データ変換エラー時の隔離、手動修正後の再開機能も確認します。

API・OAuth DD：コネクタごとに権利と稼働を検証する

一般論：コネクタ一覧には、連携先、APIバージョン、契約主体、認証方式、要求権限、トークン保存、審査状態、レート制限、障害履歴、利用顧客数、関連ARR、保守担当を持たせます。単に「100製品と連携」と数えるのではなく、どの連携が収益と継続率に寄与し、どれが保守負荷だけを生んでいるかを評価します。

OAuthスコープは最小権限か、古いトークンを失効できるか、退職者が開発者コンソールへアクセスできないかを確認します。法人名義変更やドメイン変更による再審査、顧客再認可、プライバシーポリシー更新の要否を連携先へ確認します。APIの非推奨化期限と対応工数、バージョン固定、サンドボックスの有無も将来コストになります。

外部APIから受け取るデータを信頼し過ぎていないかも重要です。悪意ある文字列、巨大応答、予期しないリダイレクト、Webhookなりすましを検証し、署名確認、入力制限、タイムアウト、サーキットブレーカーを確認します。顧客が任意URLを入力できる機能は、クラウドメタデータや社内ネットワークへ接続するSSRFの経路になり得ます。

セキュリティDD：認証の有無より統制の実効性を見る

一般論：ISMSやSOC 2は有用ですが、認証取得だけで安全性を断定しません。対象法人、対象サービス、拠点、クラウド、委託先が認証範囲に含まれるか、直近監査の指摘を是正したかを確認します。YoomがISO/IEC 27001:2022を取得したのは2023年10月であり、2022年7月の取引時点へ遡って同じ統制があったと証明するものではありません。

IAM、MFA、特権アクセス、秘密情報、暗号鍵、脆弱性管理、ログ監視、セキュア開発、インシデント対応、バックアップ、BCP、サブプロセッサ、データ削除を検証します。ペネトレーションテストは報告書の表紙だけでなく、対象範囲、重大指摘、再テスト、未解決例外を確認します。過去インシデントは件数だけでなく、検知時間、封じ込め、顧客通知、根本原因、再発防止を追います。

法務DD：契約上の地位とデータを分けて考える

一般論：顧客利用規約、個別契約、DPA、SLA、代理店契約、API規約、クラウド契約、決済契約を確認します。事業譲渡に伴う契約上の地位の移転に同意が必要か、変更通知で足りるか、譲渡禁止やChange of Control条項があるかを一覧化します。大口顧客一社の同意が取れないだけで、移転対象ARRが大きく変わる可能性があります。

データについては、Yoom自身が収集する利用者情報、顧客から委託される従業員・取引先等のデータ、外部SaaSから取得するデータ、OAuth認証情報を分けます。利用目的、保持期間、保存地域、サブプロセッサ、海外移転、漏えい通知、解約時の返却・削除を確認します。旧会社のバックアップやログへ顧客データが残る期間と削除証跡も、分離完了の条件になります。

人事DD：キーパーソンの移籍可能性を評価する

一般論：対象事業の組織図だけでなく、実際に誰が設計、リリース、障害対応、顧客折衝、APIパートナー対応をしているかを調べます。兼務者の工数を製品別に把握し、全員が移らない前提でも運営できる最低人数を算定します。移籍同意、処遇、リテンション、知識移管、競業、秘密保持を契約と100日計画へ反映します。

創業者が売却後も残る場合は、肩書だけでなく、意思決定権、予算、評価指標、在任期間、退任条件を明確にします。本件では波戸﨑氏がYoom代表とTimeTechnologies取締役を兼任しましたが、その目的、期間、稼働配分は未開示です。一般に兼任は橋渡しになる一方、情報遮断、利益相反、優先順位の衝突を管理する必要があります。

企業価値評価で「使える数字」と「使えない数字」

SaaS M&Aでは、ARR倍率が注目されがちです。しかし、倍率を掛ける前に、分子と分母の対象事業、基準日、指標定義を一致させなければなりません。Yoom事例は、公表数字が多く見えても個別事業の評価を逆算できない典型です。

TimeTechnologiesの過去売上をYoomのARRにしない

事実：2021年12月期のTimeTechnologies売上高は332,647千円です。しかし、会社はAutoLineとYoomの両方を運営しており、Yoomは同年8月にベータ版を開始したばかりです。売上の製品別内訳、月次経常収益、契約期間は開示されていません。この売上をYoomのARRと置くことはできません。

一般論：ARRは、基準月の継続課金MRRを年換算する方法、契約済み年額を集計する方法等で差が出ます。初期費用、個別開発、導入支援、従量課金、一時的な超過利用を含めるかも統一が必要です。買い手は契約書、請求書、決済、会計売上を突合し、再現可能なARRへ正規化します。

利用企業800社を有料顧客800社にしない

事実：Yoom株式会社は、2021年8月のベータ版開始から約1年で利用社数が800社を超えたと発表しました。同時にフリープランを提供していたことも公表されています。「利用社数」が有料、無料、休眠、アクティブのどれを含むかは説明されていません。

一般論：企業価値に使うなら、有料顧客数、ARPA、チャーン、NRR、粗利と組み合わせます。無料ユーザーは将来の転換可能性やネットワーク効果を持つ一方、サポートとインフラのコストも生みます。登録社数が大きくても、有料転換が低く、利用が浅く、解約が高ければ、同じ倍率は適用できません。

10.5億円を比較取引倍率に使いにくい理由

事実：10.5億円は、普通株式取得価額とアドバイザリー費用等の合計です。分母候補となる2021年会社売上は二事業を含む一方、取得完了時の会社はYoom切り出し後でLigla事業に集中しています。取引範囲と過去財務の範囲が一致しません。

そのまま取得額を2021年売上で割ると、見かけ上の倍率は計算できます。しかし、その倍率はYoomにもLiglaにも対応しない可能性があります。カーブアウト後の運転資本、現預金、債務、前受収益、共通費、事業譲渡対価、価格調整も分かりません。数字を出せることと、経済的に意味があることは別です。

SaaS事業価値を評価するときの実務フレーム

一般論：初期段階のSaaSでは、ARR倍率、DCF、類似取引、再構築コスト、戦略価値を組み合わせます。ARR倍率は成長率、NRR、GRR、粗利、CAC回収、顧客集中、契約期間、前払い、セキュリティ、技術負債で調整します。iPaaSでは、コネクタの質、API依存、ワークフロー利用深度、実行原価、パートナー関係も重要です。

戦略的買い手は、単体価値に加えてクロスセル、開発期間短縮、顧客獲得、データ、チャネル、防衛価値を評価します。ブレインパッドがLiglaについて、LINE対応、Rtoaster連携、顧客基盤の融合を具体的に説明したことは、戦略価値を言語化した例です。売り手も「市場が伸びる」だけでなく、特定買い手が何を早く実現できるかを数字と実行計画で示す必要があります。

自社の評価を検討する際は、一般的な倍率だけで結論を出さず、SaaS M&Aの解説・コラムも参照しながら、対象事業のARR品質、成長投資、分離コスト、買い手別シナジーを分けて整理するとよいでしょう。

事業譲渡で見落とせない契約、個人データ、雇用の承継

株式譲渡では株主が変わっても契約主体の法人は同じです。事業譲渡では、サービスの運営法人そのものが変わります。そのため、顧客契約、従業員、個人データ、外部サービス契約を個別に検討します。本件の具体的な承継方法は未開示なので、以下は公的資料に基づく一般論です。

個人情報保護法上の事業承継と利用目的

一般論：個人情報保護委員会の通則ガイドラインは、合併、分社化、事業譲渡等により事業が承継されることに伴い、その事業に係る個人データが提供される場合、提供先は第三者に該当しないと説明しています。一方、承継後も、提供前の利用目的の範囲内で利用しなければなりません。

また、契約締結前の交渉段階で相手会社がDDを行い、個人データを受け取る場合、利用目的、取扱方法、漏えい時の措置、交渉不成立時の措置等を定め、相手方に安全管理措置を守らせる契約が必要だとしています。データルームへ顧客名簿をそのまま置けばよいわけではありません。匿名化・マスキング、アクセス制限、閲覧ログ、ダウンロード制御、不成立時削除を設計します。

法律上の第三者提供に当たらない場面でも、顧客との利用規約、DPA、守秘義務、業界規制、海外移転規制、API提供者の規約が別途適用されます。個人情報保護法上の整理だけで、顧客契約の地位が自動的に移るとは限りません。

顧客契約とAPI契約は個別条項を確認する

一般論：顧客契約には、契約上の地位・権利義務の譲渡を相手方の事前書面同意なしに認めない条項が置かれることがあります。標準利用規約では通知で変更できても、大口顧客の個別契約では再同意が必要かもしれません。契約ごとに譲渡可否、通知期限、Change of Control、解約権、データ返却、前受金を確認します。

API・クラウド・決済等の契約も同じです。アカウントの名義変更が可能か、利用実績や割引が引き継がれるか、パートナー認定が新法人にも有効かを相手方に確認します。技術的に鍵をコピーできても、規約上許されなければ移行完了とはいえません。

従業員の真意による承諾

一般論：厚生労働省の事業譲渡等指針の案内は、事業譲渡における労働契約の承継に必要な労働者の真意による承諾を得ることを示しています。会社分割と事業譲渡では、労働契約承継の仕組みが同じではありません。

SaaSでは、移籍を希望しないキーパーソンが一人いるだけで、技術・顧客対応の移行難度が上がります。本人へ十分な情報を提供し、新会社の労働条件、評価、福利厚生、役割、将来像を説明します。合意を急がせたり、実質的に選択肢を与えなかったりすれば、取引後の定着と信頼を損ないます。

移行サービス契約と三者間責任

一般論：クロージングまでに経理、人事、クラウド、監視、サポートを完全分離できない場合、旧会社が新会社へ一定期間サービスを提供するTSAを結びます。対象業務、サービス水準、費用、担当者、データアクセス、事故責任、終了期限、延長条件、移行完了基準を定めます。

本件では、Yoom株式会社、ブレインパッド傘下のTimeTechnologies、ブレインパッドという三者が関係します。公開資料からTSAの有無は分かりませんが、一般に三者が関わるカーブアウトでは、旧会社の支援責任、買い手側の情報遮断、新会社の自立責任を曖昧にしないことが重要です。

PMIは「統合」と「分離」の二本立てで考える

PMIはPost Merger Integration、すなわち買収後の統合を指す言葉として使われます。しかし本件のようなカーブアウトでは、新会社を独立稼働させる分離マネジメントも同じくらい重要です。Yoom側はTimeTechnologiesから自立し、Ligla側はブレインパッドへ統合されます。二つの作業が同日に始まるため、責任者とKPIを分けなければなりません。

Yoom側のDay 1：顧客から見て何も止めない

一般論：最初の目標は、サービスを継続し、顧客が契約主体変更による不利益を受けないことです。本番環境、監視、オンコール、問い合わせ、請求、決済、利用規約、プライバシーポリシー、会社表示を新会社で機能させます。顧客とパートナーへの通知、必要な同意、APIアカウントの名義変更も完了させます。

アクセス権は特に重要です。旧会社の不要な本番権限を削除し、新会社の管理者へ移します。一方、TSA期間中に旧会社の技術者が支援するなら、時間制限・目的制限付きの権限と操作ログを設定します。秘密鍵、OAuthシークレット、署名鍵、クラウドルート権限をローテーションし、誰がいつアクセスできるかを明確にします。

請求の切替では、顧客が旧口座へ支払った場合の入金振替、年額前払いの履行、返金、請求書の会社名・登録番号、販売代理店の精算を設計します。プロダクトが動いても請求が止まれば、NewCoの資金繰りは悪化します。

最初の30日：分離による異常を可視化する

一般論：実行成功率、処理遅延、APIエラー、再認可率、サポート件数、解約、請求エラーを日次で監視します。法人変更で一部コネクタだけ失敗する、メールが迷惑判定される、Webhook送信元が変わり顧客側で拒否される、といった分離特有の異常を見つけます。

顧客データの件数、ハッシュ、アクセス権、保持期限を照合し、旧会社側のコピーを削除計画へ載せます。共有アカウント、共有チャネル、共通リポジトリを新会社専用へ切り替えます。移籍しなかった従業員から障害手順、顧客例外、API窓口を引き継ぎ、属人化を減らします。

100日まで：独立会社としての経営基盤を作る

一般論：スタンドアロン損益、資金繰り、月次決算、採用計画、ロードマップを一つの経営サイクルへまとめます。MRR、NRR、粗利、実行成功率、重大障害、サポート応答、開発速度を共通ダッシュボードで管理し、成長と信頼性の両方を経営会議で扱います。

コネクタを増やすだけでなく、どの連携が有料転換、継続率、利用深度へ寄与するかを測ります。保守負荷が高く利用が少ない連携は、終了や価格改定も検討します。セキュリティ質問票、脆弱性管理、インシデント対応、BCPを整え、大口顧客が求める統制へのロードマップを作ります。

TSAは便利ですが、長期化すると旧会社依存を固定します。対象業務ごとに終了条件を定め、新会社の採用、外部委託、システム導入へ移します。終了判断を「担当者が安心したら」ではなく、権限移管、復元試験、月次決算、問い合わせ対応等の客観基準で行います。

Ligla側の統合PMI：買収目的を製品と顧客へ落とす

事実：ブレインパッドは、LiglaとRtoasterの顧客データ統合・レコメンド機能を連携し、Web、アプリ、メール、LINEを横断するマーケティング施策を目指しました。また、両社の類似する顧客基盤を融合し、提供サービスの幅を広げるとしています。新役員体制もブレインパッド側の責任者を中心に組まれました。

分析：これは、製品統合、営業統合、ガバナンス統合を並行するPMIです。Yoomを対象会社から外したことで、Liglaのロードマップ、クロスセル、顧客データ連携に資源を集中しやすくなった可能性があります。もっとも、具体的な100日計画、統合KPI、実績は当時の資料だけでは確認できません。

PMIの一般的な設計については、中小企業庁の中小PMIガイドラインの案内も参考になります。同ガイドラインは、M&Aの目的と現状課題を踏まえた統合基本方針、推進体制、会議体、関係者への共有を重視しています。カーブアウトでは、この考え方を「統合する側」と「自立する側」の双方へ適用します。

Yoomの事業譲受後に確認できる成長シグナル

非上場会社の事業譲渡では、投資回収や事業別利益が継続開示されないことがあります。本件も、譲渡価額、ARR、利益、NRRは公開されていません。一方、会社発表から、製品、パートナー、利用規模、セキュリティに関する動きを時系列で確認できます。

事業譲受後1か月以内のパートナー発表

事実：Yoomは2022年8月24日、クラウドサインのプロダクトパートナーとして認定されたと発表しました。Yoom上で送付先を選び、Googleドキュメントの雛形から契約書PDFを生成し、承認後にクラウドサインで送付する流れや、締結後にファイル保存、ステータス更新、チャット通知を行う例を示しています。

分析：事業譲受後の早い時期に外部パートナーとの連携を発表できたことは、新会社が営業・広報・プロダクト運営を立ち上げていた状況証拠です。ただし、認定や連携開発が取引前から準備されていた可能性があり、事業譲渡の効果だけで実現したと断定できません。

約2か月後のデータコネクト機能

事実：2022年9月20日、Yoomは、各SaaSの情報をYoomデータベースへ自動的に集約・同期するデータコネクト機能を公開しました。初期の取得対象として、HubSpot、クラウドサイン、freee、Google Workspace、Salesforce、Stripe、BigQuery、Slack、SmartHR、GitHub、Asana等を挙げています。

同機能は、商談、契約、請求等の情報を一元化し、そのデータを使って契約書送付、入社対応、請求書発行等のフローを自動化する説明でした。これは、事業譲渡時の「データベース型iPaaS」という位置付けを具体化する製品展開です。

導入企業数とISMS認証

事実：2022年8月の会社発表では利用社数800社超でした。Yoomは2023年11月、2023年10月時点で4,500社超に導入されていると説明しています。同年10月22日にはISO/IEC 27001:2022認証を取得し、認証範囲を「SaaS型アプリケーション Yoomシリーズの運用開発業務」としました。

注意：800社と4,500社の集計定義が完全に同じか、有料顧客か、アクティブ顧客かは確認できません。そのため「顧客数が5.6倍」「売上が5.6倍」とは書けません。安全な表現は、「会社公表の利用・導入企業数は800社超から4,500社超へ増えた」です。

分析：機能追加、パートナー連携、導入企業数の増加、ISMS取得は、新会社で製品と管理体制への投資が続いたことを示します。しかし、M&Aの成功を評価するには、ARR、粗利、継続率、資本効率、従業員定着、顧客満足、障害指標も必要です。公開シグナルは肯定的でも、最終的な投資リターンを断定する材料ではありません。

このiPaaS M&A 事例からSaaS経営者が学べる8つのこと

教訓1．会社全体ではなく、最適な事業境界を売る

複数製品がある場合、すべてを一人の買い手へ渡す必要はありません。買い手の戦略に適合する事業と、創業チームが継続する事業を分けることで、双方の価値を高められる可能性があります。そのためには、財務、契約、コード、人材、データを分離できる状態が必要です。

教訓2．買い手の投資仮説から対象範囲を逆算する

ブレインパッドは、LINE、Rtoaster、顧客データ、チャネル横断、顧客基盤という具体的な取得理由を公表しました。売り手も、自社の一般的な魅力ではなく、候補買い手ごとに「何を何年早められるか」「どの顧客へ何を追加販売できるか」を示すべきです。シナジー仮説が明確になるほど、買収対象に残す人・知財・契約も明確になります。

教訓3．売却対価と残る事業の成長資金を分ける

経営者が一部事業を残すなら、M&Aでいくら受け取るかだけでは不十分です。NewCoの12～24か月の運転資金、開発投資、採用、管理体制を設計します。Yoom株式会社が8.4億円の増資と使途を示したことは、事業境界の変更と資本政策を同時に考える必要性を伝えています。

教訓4．広報KPIをDD可能なKPIへ翻訳する

導入社数、自動化時間、連携数は分かりやすい一方、買い手は有料顧客、ARR、NRR、粗利、顧客集中、利用深度を検証します。定義書と元データがなければ、成長を示す数字ほど疑われます。売却を検討する前から、会計・請求・プロダクトイベントをつなぎ、再計算可能なダッシュボードを作ることが重要です。

教訓5．API資格とパートナー関係を資産台帳へ入れる

iPaaSでは、コードより先に外部SaaSとの接続が止まることがあります。OAuthアプリ、開発者アカウント、審査、クォータ、規約、パートナー窓口を資産として扱います。譲渡不可なら再登録と顧客再認可に必要な日数をクロージング計画へ入れます。

教訓6．PMIの前にDay 1の分離を完成させる

成長施策を急いでも、請求、認証、監視、障害対応が不安定なら顧客を失います。誰が本番を守り、どの法人が請求し、どの規約が適用され、障害を誰が通知するかを初日から機能させます。カーブアウトでは「統合してシナジーを出す」前に「分離して価値を壊さない」があります。

教訓7．創業者の残り方を契約と役割で定義する

創業者が売却会社と残存会社の双方に関与する場合、橋渡し効果が期待できます。一方、時間配分、情報遮断、競業、利益相反、意思決定が曖昧だと両社が困ります。役職名だけでなく、期間、権限、KPI、退任、知識移管を定めます。

教訓8．分からないことを推測で埋めない

Yoom事業の譲渡価額、NewCoの株主構成、移籍人数、顧客同意、TSAは非公表です。非公表部分を業界慣行で埋めれば、もっともらしい物語は作れます。しかし、売り手読者が判断に使う記事だからこそ、事実、分析、一般論を分ける必要があります。これはM&A実務でも同じで、仮説はDDで検証し、未検証事項は価格・契約・PMIのリスクとして残します。

カーブアウトの最終契約で決めるリスク配分

DDで問題を発見しても、それだけでは取引リスクは減りません。発見事項を、譲渡対象の修正、価格、クロージング前提条件、表明保証、補償、誓約、TSA、PMIのどこへ反映するかを決める必要があります。本件の契約条項は公開されていないため、以下はSaaS事業譲渡に関する一般論です。

譲渡対象資産と除外資産を別紙で固定する

一般論：「Yoom事業一式」のような抽象的な記載だけでは、クロージング後に認識差が生じます。ソースコードのリポジトリ、ブランチ、コミット、商標、ドメイン、クラウド環境、データベース、顧客契約、パートナー契約、売掛金、前受金、機器、文書を別紙で特定します。アカウントは表示名だけでなく、契約ID、管理者、請求先、リージョン、移管手続きを記載します。

除外資産も同じ精度で定めます。旧会社の共通ブランド、全社管理データ、残存事業の顧客情報、共通ライブラリ、税務資料等を除外し、対象事業が利用を続けるものはライセンス条件を決めます。「運営に必要な一切の資産」という包括条項があっても、第三者の同意がなければ移せない契約やアカウントがあります。別紙と移管手続一覧を対応させることが重要です。

デジタル資産はクロージングまで変化します。毎日コードが更新され、新しい顧客やワークフローが増え、APIトークンが更新されるためです。基準日以降に追加された資産を自動的に対象へ含めるか、最終更新リストをクロージング時に提出するかを定めます。ソースコードは特定コミットのハッシュ、データは抽出日時と件数を証跡にすると、受渡し完了を確認しやすくなります。

引き受ける負債と旧会社に残す責任を分ける

一般論：SaaS事業には、貸借対照表に見えにくい履行義務があります。年額前払いを受けた顧客への残存サービス、無料延長、返金約束、SLAクレジット、セキュリティ事故の通知、未完了の個別開発、販売代理店への手数料、API最低利用料等です。買い手がどの義務を引き受け、売り手がどの過去責任を負うかを明記します。

例えば、クロージング前に発生した障害がクロージング後に判明した場合、顧客対応を新会社が行っても、補償費用を旧会社が負担する設計があり得ます。反対に、クロージング後の運用ミスは新会社の責任です。原因発生日、発見日、顧客請求日がずれるSaaSでは、単純に「クロージング前後」で切るだけでなく、原因と管理可能性を考えます。

前受収益の扱いは価格と運転資金に直結します。現金を旧会社が保有したまま履行義務だけ新会社へ移すと、新会社は収入なしでサービス原価を負担します。前受金相当を現金移転、価格調整、精算金のいずれで補うかを決めます。月額課金でも、締日と決済日のずれ、返金、チャージバックを処理するルールが必要です。

クロージング前提条件を「実行可能な証拠」にする

一般論：重要顧客の同意、キーパーソンの移籍同意、主要APIの再登録、商標移転、クラウドアカウント移管、重大脆弱性の是正をクロージング前提条件にすることがあります。しかし「合理的に満足する対応」とだけ書くと、完了判定が主観的になります。

顧客同意書の受領、API提供者の承認メール、新会社管理者でのログイン確認、バックアップ復元テスト結果、権利移転申請の受理証等、完了を示す書類とテストを定めます。すべての顧客同意を条件にすると一件の遅れで取引全体が止まるため、ARR基準、上位顧客基準、同意率基準を用いる設計も検討します。未同意顧客は価格留保、後日精算、対象除外等で扱います。

iPaaSでは、OAuthアプリの再審査に第三者の期間がかかり、当事者だけで完了日を制御できません。審査完了を絶対条件にするのか、旧アプリをTSAで一定期間利用するのか、顧客再認可率が基準に達した時点で切り替えるのかを決めます。技術チームを契約交渉へ参加させ、現実的な期限を設定する必要があります。

表明保証はSaaSの実態へ合わせる

一般論：一般的な権限、契約、訴訟、税務の表明保証に加え、SaaSではARRデータ、顧客契約、知財、OSS、情報セキュリティ、個人データ、サービス障害、外部APIを扱います。売り手が「すべてのシステムに脆弱性がない」と無限定に保証するのは現実的ではありません。重大性、認識、対象期間、開示済み例外を定義します。

ARRについては、金額そのものを保証するのか、契約一覧が完全・正確であることを保証するのかを分けます。有料顧客が解約しないことは将来事象であり保証できませんが、既に解約通知を受けていないこと、無償契約を有料へ含めていないこと、重要な値引き・返金を開示したことは確認できます。

知財では、譲渡対象コードを使用・譲渡する権利、重大な侵害主張を受けていないこと、重要な業務委託者との権利帰属、OSS義務の遵守を扱います。セキュリティでは、既知の重大インシデント、当局・顧客通知、合理的な統制、未解決の重大脆弱性を対象にします。APIでは、主要連携の規約違反通知、停止予告、クォータ超過、認定取消しを確認します。

補償、価格留保、エスクローをリスクへ対応させる

一般論：表明保証違反や特定リスクが顕在化した場合の補償について、上限、免責、バスケット、期間、請求手続を定めます。個人データ事故、知財侵害、税務、未払賃金等は一般表明保証と別の上限・期間を置くことがあります。どの条項を特別補償にするかは、DDで見つかった具体的なリスクと交渉力で決まります。

顧客同意やAPI再認可がクロージング後になる場合、対価の一部を留保し、移管実績に応じて支払う方法があります。これは将来業績に連動するアーンアウトとは目的が違います。価格留保は、クロージング時点で移せなかった価値の確保に使い、アーンアウトは将来の売上・ARR・利益等に使われます。両者を混ぜると、計算と責任が複雑になります。

アーンアウトを採用するなら、買い手が価格、営業投資、製品統合、費用配賦を変更できる点を考慮します。売上だけを指標にすると過度な値引きで達成でき、利益だけを指標にすると買い手の共通費配賦で未達になります。ARR、NRR、粗利、対象顧客、会計方針、運営誓約、情報権、紛争解決を細かく定義する必要があります。本件にアーンアウトがあったという公開情報はありません。

TSAは終了設計まで契約する

一般論：TSAには、旧会社が提供する経理、人事、IT、クラウド、サポート等を列挙し、サービスレベル、費用、担当者、データアクセス、再委託、事故責任を定めます。しかし最も大切なのは終了です。新会社が何を導入し、どのテストに合格したら旧会社支援を止めるかを業務ごとに決めます。

旧会社がブレインパッド等の第三者に買収される場合、TSA提供能力も買い手の管理下に入ります。株式取得契約と事業譲渡契約の当事者が異なるため、必要なら三者合意で人員・アクセス・費用を確保します。旧会社が提供すると約束しても、新しい親会社がセキュリティ上のアクセスを認めなければ実行できないためです。

データ削除と証拠保全を両立する

一般論：分離後、旧会社は対象事業の顧客データを不要に保持すべきではありません。一方、税務、訴訟、障害調査、契約上の保存義務で一定の記録を残す必要があります。何を、どの法的根拠で、どの期間、誰がアクセス可能な状態で保管するかを決めます。

本番DB、分析基盤、ログ、バックアップ、開発環境、チケット、メール、端末を対象に削除計画を作ります。バックアップは即時削除できないことがあるため、復元時に対象データを再削除する手続と最長残存期間を定めます。削除証明だけでなく、移行前後の件数、ハッシュ、サンプル照合を残し、新会社へ完全に渡ったことも証明します。

買い手に伝わる経営ストーリーの作り方

売り手の説明資料は、過去の実績を並べるだけでは十分ではありません。買い手は、なぜ今この事業を取得し、自社が所有することで何が変わり、どのリスクをどの期間で解消できるかを知りたいからです。YoomとLiglaの分離からは、「一つの会社に二つの物語を詰め込まず、所有者ごとに投資仮説を明確にする」という示唆を得られます。

顧客課題を機能一覧より先に置く

一般論：「100サービスと連携」「ノーコード」「データベース機能」という特徴だけでは、買い手は将来収益を判断できません。誰が、どの頻度で、どの業務を、どれだけの時間・費用・エラーを削減するために使うかを示します。経理の請求、法務の契約、人事の入社、営業の案件更新では、予算責任者、導入理由、解約要因が異なります。

顧客インタビュー、利用イベント、サポート履歴から、導入前の業務、初回価値到達までの日数、定着するワークフロー、他部門展開の順序をまとめます。製品利用の深さがNRRや解約率へどう影響するかを示せれば、単なる登録社数より説得力があります。顧客名を開示できない段階では、匿名化したコホートや業種別集計を使います。

買い手別にシナジーを作り替える

一般論：同じSaaSでも、戦略的買い手、PEファンド、同業、販売会社、海外企業では価値が違います。戦略的買い手には既存顧客へのクロスセル、製品統合、データ・チャネル補完を示します。PEには、独立した経営体制、価格改定、営業生産性、追加買収による拡大余地を示します。同業にはコネクタ重複、顧客移行、インフラ統合による相乗効果とカニバリゼーションを示します。

シナジーは売上だけでなく、実現コストと時期を含めます。既存顧客1,000社へ販売できるとしても、製品統合に18か月、セキュリティ審査に6か月、営業教育に3か月かかるなら、初年度の効果は限定的です。誰が責任を持ち、どのKPIで進捗を測るかまで示すと、買い手の社内稟議で使える資料になります。

「残す事業」も買い手の安心材料にする

一般論：一部事業をNewCoへ切り出すと、買い手は価値ある資産まで外へ出されるのではないか、競合が生まれるのではないかと警戒します。残す事業と売る事業の顧客、機能、データ、人材、ブランドを明確に分け、競業、顧客勧誘、共通コード、将来開発の境界を説明します。

YoomとLiglaは対象課題が異なるものの、いずれも自動化とデータを扱います。このような場合、将来どの機能が競合するか、共有顧客へどちらが提案するか、旧会社のノウハウをどこまで使えるかが論点になります。本件の具体的な競業・ライセンス条項は未開示ですが、一般のカーブアウトでは買い手とNewCo双方の成長を不当に妨げない境界設計が必要です。

リスクを隠すのではなく、管理可能にして示す

一般論：技術的負債、顧客集中、主要人物依存、API規約変更、セキュリティ指摘を完全になくしてから売却することは難しいでしょう。重要なのは、リスクを把握し、影響、発生可能性、対応責任、期限、費用を示すことです。買い手が最も嫌うのは問題の存在より、DD後半で初めて発覚し、売り手の説明を信頼できなくなることです。

リスク一覧には、事象、根拠、影響する顧客・ARR、暫定対応、恒久対応、責任者、期限、残余リスクを記載します。すでに修正した事項も、発見から是正、再テストまでの証跡を示します。この透明性が、表明保証の範囲を限定し、価格留保を小さくし、PMI計画を現実的にします。

非公表事項は取材とデータで埋め、推測で埋めない

事例を自社の意思決定へ使う際も、公開情報の限界を認識します。本件から、Yoomの譲渡価格やNewCoの資本政策の詳細は分かりません。分からない数字を類似会社の倍率で埋めても、取引範囲、成長率、粗利、権利関係が異なれば意味がありません。

自社取引では、非公表で済ませるのではなく、秘密保持契約下で買い手へ必要なデータを提供します。外部記事では書けない契約・顧客・技術情報こそ、買い手の価格と契約判断に必要です。公表ストーリーは簡潔でも、データルームと経営者説明は精密でなければなりません。

自社のSaaS売却に向けた180日アクションプラン

以下は、複数プロダクトの一部売却またはカーブアウトを検討する経営者向けの一般的な進め方です。会社規模、株主、契約、規制、資金繰りで期間は変わります。180日で必ず売却できるという意味ではなく、買い手と対話できる状態を作るための準備順序です。

最初の30日で行うこと

経営者はまず、売却理由を「資金が欲しい」「成長したい」から一段深くします。どの事業へ誰の資本・顧客・技術が必要か、残る事業をなぜ自分たちが運営するかを言語化します。株主間で、全社売却、一部売却、資本提携、資金調達の優先順位を確認します。

同時に、プロダクト別の月次損益、ARRブリッジ、有料顧客コホート、組織、契約、システムを棚卸しします。この段階で数字が出なければ、売却活動を急ぐより、データ取得と会計整理を優先します。買い手候補へ一度出した矛盾した数字は、後から直しても信頼を戻しにくいためです。

60～120日で分離可能性を高める

共有コード、共通クラウド、兼務者、共通契約を特定し、解決方針を決めます。顧客契約の譲渡同意が必要なら、どの時点で誰が接触するかを設計します。API提供者に法人変更手続きを確認し、審査や再認可の期間を見積もります。知財帰属、OSS、セキュリティ指摘を是正し、買い手が追試できる証跡を揃えます。

この時期に、買い手候補別のシナジー仮説を作ります。顧客クロスセルだけでなく、製品統合に必要な開発、データ利用の法的条件、営業組織の適合、ブランド変更の影響を含めます。シナジーを実現するコストと期間も示すことで、単なる希望ではなく投資判断になります。

最終契約からDay 1まで

価格だけでなく、譲渡対象、除外資産、前受収益、売掛金、従業員、顧客同意、表明保証、補償、TSA、データ削除、クロージング前提条件を整合させます。技術チームは切替リハーサルを行い、失敗時のロールバック、障害連絡、顧客通知を準備します。

取引公表文も重要です。誰が何を取得し、何を残し、価格の対象が何かを明確にします。Yoom事例のように複数の数字がある場合は、増資とM&A対価を別項目で説明します。顧客には、サービスURL、ログイン、データ、サポート、請求、契約条件の何が変わり、何が変わらないかを具体的に伝えます。

SaaSの売却や一部事業のカーブアウトを検討している場合、SaaS M&A Centerで情報を確認し、自社の事業境界、ARR、契約、技術分離の現状を整理することから始めてください。一般的な企業売却の資料だけでは見落としやすい、API、データ、クラウド原価、プロダクト人材まで含めて準備することが重要です。

Yoom事業譲渡とSaaSカーブアウトのよくある質問

出典・参考資料

取引事実は、可能な限り当事会社と上場会社の一次情報を優先しました。リンク先の情報は公表時点のものであり、その後更新・移転される場合があります。

1. Yoom株式会社「Yoom株式会社設立のお知らせ。データベース型iPaaS『Yoom』8.4億円を調達」（2022年8月2日）
2. 上記Yoom発表のPR TIMES掲載ページ（2022年8月2日）
3. ブレインパッド「株式会社TimeTechnologiesの株式の取得（子会社化）に関するお知らせ」（2022年6月28日）
4. ブレインパッド「TimeTechnologiesの株式を取得、LINEに特化したMAツールをプロダクトラインナップに追加」（2022年6月28日）
5. TimeTechnologies「株式会社ブレインパッドへ全株式の譲渡契約を締結」（2022年6月28日）
6. TimeTechnologies「株式譲渡に伴う新役員体制を発表」（2022年7月29日）
7. ブレインパッド「TimeTechnologiesの株式取得（子会社化）を完了」（2022年7月29日）
8. TimeTechnologies「業務自動化プラットフォーム『Yoom』が正式版をリリース」（2022年1月17日）
9. Yoom「クラウドサインとプロダクトパートナーとして連携」（2022年8月24日）
10. Yoom「データコネクト機能」（2022年9月21日）
11. Yoom「ISO/IEC 27001:2022認証を取得」（2023年11月15日）
12. MARR entry 38588「Yooｍ、新会社を設立しTimeTechnologiesからデータベース型iPaaS『ユーム』事業を譲り受け」（2022年8月2日）
13. 中小企業庁「中小M&Aガイドライン」
14. 特許庁「スタートアップ向け情報」（知財デューデリジェンス関連資料を含む）

まとめ：売却とは、事業の「最適な所有者」を設計すること

Yoom事例の核心は、10.5億円や8.4億円という目を引く数字ではありません。TimeTechnologiesにあった二つのSaaSを、Liglaはブレインパッドとの統合へ、Yoomは創業チームが率いる新会社での成長へと分けた点にあります。買い手の戦略適合、創業チームの継続、NewCoの資本政策を一つの時間軸で組み合わせた構造です。

一方、公開資料だけでは、Yoom事業の譲渡価額、契約範囲、従業員移籍、顧客同意、データ移行、TSA、新会社の株主構成は分かりません。これらを事実のように補わないことが重要です。確認できる事実から構造を描き、推論には推論と明示し、一般論は読者が自社で使える実務へ展開する。それがM&A事例を正しく読む方法です。

SaaS経営者にとって、売却準備は買い手を探すところから始まりません。プロダクト別損益、ARRの定義、顧客契約、知財、API資格、データ、キーパーソン、スタンドアロン費用を整え、自社のどこまでが一つの事業として自立できるかを明らかにすることから始まります。iPaaSなら、外部SaaSとの接続を継続する権利と能力まで事業資産として扱う必要があります。

免責事項

本記事は、公開情報を基にした一般的な情報提供を目的としており、特定の取引に関する法務、税務、会計、投資、情報セキュリティ上の助言ではありません。事業譲渡、株式譲渡、個人データ移行、労働契約承継、企業価値評価の判断は、個別事情と最新の法令・契約を踏まえ、弁護士、公認会計士、税理士、社会保険労務士、セキュリティ専門家等へご相談ください。

当事会社が公表していないYoom事業の譲渡価額、Yoom株式会社の株主構成、従業員移籍人数、契約・データ移行の詳細について、本記事は推測を事実として記載していません。企業の公表値である利用・導入企業数やサービス実績についても、第三者監査済みの財務指標とは区別して掲載しています。