Buy-and-BuildのAdd-on統合実務｜反復型PMIで価値を壊さないプレイブック

Buy-and-Build戦略では、Platform企業を起点にAdd-on（追加買収）を繰り返し積み上げていきます。1件のAdd-onを買って統合するだけなら、統合の型は単発買収のPMIと変わりません。難しくなるのは、2件目・3件目・4件目のAdd-onが、前の案件の統合が終わり切らないうちに入ってくるときです。統合チームは常に複数の案件を同時に抱え、プレイブックは使い回されるほど摩耗し、シナジートラッカーは1本ではなく複数本の実現カーブを同時に追いかける必要が出てきます。本記事は、この「反復して統合し続けること」に固有の実務に完全に特化します。単発買収のPMIの型（Day1／100日／1年の時間軸、IMOの組み方、失敗5パターン）はPMIと100日プランで、Add-on買収のLBOモデルへの組み込み（S&U・Pro Forma EBITDA・シナジーのランレート×実現率）はAdd-on買収をLBOモデルに追加する方法で扱っているため、本記事では再説明せず必要な箇所からリンクします。

結論：反復統合の勝負は「標準化」と「キャパシティ」で決まる

結論を先に3点で示します。第一に、Buy-and-Buildの統合力は、1件あたりの統合の巧拙よりも、プレイブックをどれだけ使い回せるかで決まります。毎回ゼロから100日プランを作り直していては、Add-onの買収スピードに統合が追いつきません。第二に、複数Add-onを同時並行で統合しようとすると、ボトルネックになるのはほぼ例外なく専任統合チームの人月キャパシティです。買収のタイミングは市場やソーシングの都合で決まりますが、統合できる案件数は自社の体制でしか決まらないという非対称性が、反復統合の設計の出発点になります。第三に、シナジートラッカーは1件のAdd-onのランプカーブを追う道具ではなく、複数のランプカーブが重なり合うポートフォリオを追う道具として運用する必要があります。買収と統合が途切れなく続く限り、トラッカーが「今どの案件がどの段階にあるか」を一覧できていないと、Platform全体の実現シナジーが見えなくなります。

Bain & Companyの分析では、Add-on買収のうち約3割が同一Platformにとって4件目以降の買収であり（2003年時点では21%）、1割のケースでは10件目以降の連続買収だとされています。同分析は、買収のスピードを上げるほど、IT基盤や統合チームといった「ボトルネックの早期特定と解消」が成否を分けると指摘しています（出典は本記事末尾）。この構造をどうモデル化し、どう回すかが以下の各節のテーマです。

なぜBuy-and-Buildの統合は単発PMIと別物なのか

単発買収のPMIでは、Day1に向けた準備、100日プランの実行、1年での定着という一直線の時間軸を1回だけ回します。ma-007で扱っている枠組みがそのまま当てはまります。ところがBuy-and-Buildでは、この一直線の時間軸がAdd-onの数だけ並走します。1件目の統合が100日プランの終盤に差し掛かった頃に2件目がクロージングし、2件目のDay1準備が走っている最中に3件目のLOIが決まる、という重なりが常態化します。

この重なりが生む固有の課題は大きく3つに整理できます。第一に、資源の奪い合いです。財務・IT・人事といった機能別ワークストリームの担当者は、Platform全体で有限であり、複数の統合案件に同時に貼り付けることはできません。第二に、プレイブックの摩耗と硬直化です。過去案件で作ったチェックリストをそのまま流用し続けると、対象会社の実情との乖離に気づかないまま形骸化が進みます。第三に、シナジーの帰属の曖昧化です。複数のAdd-onが同じ調達カテゴリや同じ営業チャネルを共有し始めると、「どの施策の効果か」が切り分けにくくなり、実現額の二重計上や過大計上のリスクが生まれます。ロールアップ戦略全体における倍率裁定の考え方はロールアップ戦略｜小さく買って大きく売る「倍率の裁定」の算数で扱っており、本記事はその実行面、つまり「買い続けながら統合し続ける」オペレーションの設計に軸足を置きます。

プレイブックの標準化：何を固定し、何を毎回変えるか

インテグレーション・プレイブックとは、過去案件の知見をもとに、機能別の統合タスク・意思決定事項・スケジュールを標準化した実行手順書のことです。Buy-and-Buildにおけるプレイブックの価値は、Day1チェックリストを毎回ゼロから作らずに済むことにありますが、その裏返しとして「標準化しすぎて対象会社の実情を無視する」失敗も起きやすくなります。実務では、プレイブックを2層に分けて設計するのが有効です。

1層目は固定層です。銀行口座・給与計算・会計システムの接続、基幹契約の名義変更、就業規則の適用関係、独禁法上の統合前禁止事項（クリーンチーム体制の要否を含む）といった、対象会社の業種や規模によらず必ず発生するタスクです。ここはチェックリストのフォーマットごと使い回し、案件ごとの差分だけを更新すれば足ります。2層目は可変層です。営業組織の統合度、ブランドを残すかどうか、経営陣の残留・退任、ITシステムの片寄せ先といった論点は、Add-onの規模・地理・顧客基盤によって最適解が変わるため、プレイブックはあくまで「検討すべき論点のチェックリスト」として使い、結論は案件ごとに個別に出す設計にします。この切り分けを曖昧にしたまま可変層まで機械的に標準化すると、後述する失敗パターンの筆頭である「プレイブック形骸化」につながります。

プレイブックの改訂サイクルも反復統合特有の論点です。1件ごとに振り返りを行い、うまくいった判断・うまくいかなかった判断を固定層と可変層のどちらに反映すべきかを仕分ける、という運用を組み込むことで、案件を重ねるほどプレイブックの精度が上がっていきます。逆にこの振り返りを省略すると、同じ失敗を案件ごとに繰り返すことになります。

複数Add-onの順序設計と統合キャパシティ管理

以下は説明用の仮設例です。実在の案件・企業とは無関係で、単位は人月（1人が1ヶ月フルタイムで統合業務に投入できる工数）とします。

統合度によって必要な専任人月は変わります。目安として、完全統合（対象会社の機能をPlatformへ完全に取り込む）は6ヶ月間で18人月、連邦型（基幹管理機能のみ統合し事業運営は独立性を残す）は4ヶ月間で8人月、機能限定（財務・購買など特定機能のみ統合）は2ヶ月間で3人月を要する、という前提を置きます。

月あたりの専任人月消費
完全統合：18人月 ÷ 6ヶ月 ＝ 3.0人月／月
連邦型：8人月 ÷ 4ヶ月 ＝ 2.0人月／月
機能限定：3人月 ÷ 2ヶ月 ＝ 1.5人月／月

Platformの専任統合チームのキャパシティを9人月／四半期（3ヶ月）とします。4件のAdd-on（A1〜A4）を、ソーシングの都合でA1を1ヶ月目、A2を5ヶ月目、A3を11ヶ月目、A4を15ヶ月目に買収する計画だとします。統合度は案件の性質からA1・A3を完全統合、A2を連邦型、A4を機能限定と決めたうえで、着手タイミングを何も考えずに買収直後に置くと、四半期ごとの必要人月は次のようになります。

この設例が示す構造は単純です。買収のタイミングは動かせなくても、統合の着手タイミングと統合度は動かせます。ナイーブな計画では、A1の完全統合が終わり切る前にA2の統合を始めてしまい、Q2に4.0人月（+44%）の超過が生じます。同様にA3の完全統合の途中にA4を着手させるとQ5で1.5人月（+17%）超過します。キャパシティを考慮した計画では、A2の着手をA1の完了後（7ヶ月目）まで2ヶ月、A4の着手をA3の完了後（17ヶ月目）まで2ヶ月それぞれ遅らせるだけで、統合度を一切変えずに全四半期がキャパシティ上限内に収まります。代わりに支払う対価は、A2・A4のシナジー実現開始が2ヶ月ずつ後ろ倒しになることです。これは「統合の速度と、同時に走らせる案件数のどちらを優先するか」という明示的なトレードオフであり、投資委員会やPlatformの取締役会で共有すべき論点です。超過分をサージ要員（外部人材や他部門からの一時応援）で吸収する選択肢もありますが、その場合はコストが逆シナジー・統合コストとして積み上がる点を織り込む必要があります。

Platform管理部門の先行強化

複数のAdd-onを受け入れ続けるPlatform企業では、経理・人事・IT・法務といった管理部門（バックオフィス）の体制が、統合の実質的な制約条件になります。単発買収であれば「対象会社を1社分だけ飲み込めるか」を考えればよいのに対し、Buy-and-Buildでは「今後2〜3年で何社分を飲み込む計画か」を先読みして、管理部門の体制をAdd-onの買収より先に強化しておく必要があります。

典型的な失敗は、Platformの管理部門が現状の事業規模に合わせた人員のまま、Add-onを2件、3件と受け入れてしまうパターンです。この場合、経理は決算の締めに追われて統合PJに人を割けなくなり、IT部門はシステム統合のバックログが積み上がり、結果として統合マネジメントオフィス（IMO）が実質的に機能しなくなります。先行強化の考え方は、次のAdd-onが決まってから採用を始めるのではなく、Platformの中期的な買収計画（年間何件・どの規模のAdd-onを想定するか）から逆算して、管理部門の増員・システム投資のタイミングを前倒しで計画することです。この投資は短期的にはPlatformのEBITDAを圧迫しますが、統合が滞留してシナジー実現が遅れることによる機会損失のほうが、多くの場合は大きくなります。

調達機能の強化は特に典型的です。複数のAdd-onをグループ購買でまとめることでコストシナジーを取りにいく場合、その前提として調達機能自体がAdd-onを受け入れられる体制になっている必要があります。個別施策としてのグループ購買・調達統合の実務はPE投資先のProcurement改善｜購買コスト削減をEBITDAへ変換する実務で扱っており、Buy-and-Build文脈での調達統合はその応用にあたります。

シナジートラッカーの反復運用

単発買収であれば、シナジー実現カーブは1本だけ管理すれば済みます。Buy-and-Buildでは、買収のたびに新しいカーブが立ち上がり、既存のカーブと重なり合いながら進んでいきます。シナジー実現管理の台帳様式・実現額の測定方法・AIを使った仕組み化についてはPMIのシナジー管理をAIで仕組み化で詳述しているため、本記事ではBuy-and-Build固有の論点、つまり「複数の実現カーブを同時に追いかけるとPlatform全体の数字がどう動くか」に絞って扱います。

以下は説明用の仮設例です。A1〜A4の年間ランレートシナジー目標をそれぞれ180・140・220・160百万円（目標合計700百万円）とし、買収時点をA1＝0ヶ月目、A2＝6ヶ月目、A3＝14ヶ月目、A4＝24ヶ月目とします。実現率は買収からの経過月数に応じて0%（6ヶ月未満）→25%（6ヶ月経過）→60%（12ヶ月経過）→90%（18ヶ月経過）→100%（24ヶ月経過）と段階的に上がる簡略モデルを置きます。

各時点の実現ランレートシナジー
実現額 ＝ 年間ランレート目標 × 経過月数に応じた実現率
例（30ヶ月目時点）：A1＝180×100%＝180、A2＝140×100%＝140、A3＝220×60%＝132（経過16ヶ月＝直近の到達段階12ヶ月＝60%）、A4＝160×25%＝40（経過6ヶ月＝25%）
Platform全体の実現額 ＝ 180＋140＋132＋40 ＝ 492（目標700に対し70.3%）

この図が示す運用上の要点は、Platform全体の実現額がAdd-on単体の実現率だけでは説明できないということです。30ヶ月目時点でA1・A2は目標を100%達成していますが、A3はまだ60%、A4はようやく25%です。個々の案件のダッシュボードだけを見ていると「A3・A4が遅れている」という個別の事実は分かりますが、「Platform全体として目標700に対し70.3%しか達成していない」という経営判断に必要な数字は、個別のトラッカーを合算しない限り出てきません。反復統合の現場では、案件単位のトラッカーとPlatform単位のロールアップの両方を、同じ台帳から自動的に導出できる設計にしておくことが、案件数が増えるほど効いてきます。

統合度の使い分け：完全統合・連邦型・機能限定

Add-onごとに統合度をどう選ぶかは、単発買収でも論点になりますが、Buy-and-Buildでは前述のキャパシティ制約と組み合わせて判断する必要がある点が異なります。

Buy-and-Build特有の判断軸は、対象会社の性質だけでなく「そのとき統合チームが空いているか」を統合度の選択に織り込むことです。表1の設例でA4を機能限定としたのは、A4自体の性質だけでなく、A3の完全統合と時期が重なりキャパシティが逼迫していたことも理由になります。連邦型で入れたAdd-onを、統合チームに余裕ができた後の四半期で完全統合へ引き上げる「段階的統合」も実務ではよく使われます。逆に、経営陣・従業員の反発が強くカルチャー統合の摩擦が大きいと判明した案件を、当初の完全統合方針から連邦型へ計画変更するケースもあります。統合度は買収時点で1回だけ決めて固定するものではなく、統合キャパシティの状況とAdd-onごとの実情を見ながら、四半期単位で見直す運用が反復統合には向いています。

反復統合特有の失敗パターン

単発買収のPMIの失敗パターン（計画の遅さ・人材流出・システム統合の遅延等）はma-007で扱っているため、ここでは複数Add-onを繰り返すことで初めて顕在化するパターンに絞ります。

日本実務での論点

日本のBuy-and-Build案件で反復統合を計画する際、モデルやオペレーションの設計そのものに加えて、いくつか一般的な留意点があります。いずれも制度の概要紹介にとどめ、個別案件の判断は専門家の検討を前提とします。

まず、Add-onを連続して買収していく場合、各案件は個別に企業結合の届出基準（会社法上の手続に加え、独占禁止法上は売上高等の基準額を超える場合の事前届出）の対象になるかを確認する必要があります。公正取引委員会の「企業結合審査に関する独占禁止法の運用指針」では、水平型・垂直型・混合型の類型ごとに競争制限効果を審査する枠組みが示されており、審査では需要者にとっての代替性という観点から一定の取引分野が画定されます（出典は本記事末尾）。1件ごとの買収規模が小さく単体では届出基準に満たなくても、同一の取引分野でAdd-onを繰り返すことでPlatformのシェアが積み上がっていく点は、案件を重ねるほど後続の審査で意識される可能性がある一般的な留意点です。競合他社を対象とするAdd-onのDD段階では、価格・顧客情報等の機微情報を限定された担当者のみが扱うクリーンチーム体制を、単発買収以上に日常的な運用として組み込んでおくことが実務上有効です。

また、複数のAdd-onを抱えるグループでは、労務・給与規程の統一やグループ経理方針の統一といった管理部門タスクが、単発買収より頻度高く発生します。就業規則の不利益変更に該当しうる制度変更や、労働契約承継法が適用される会社分割スキームを用いる場合の手続については、案件ごとに個別に確認が必要な領域であり、モデル上は「管理部門統合コストの一定割合を人事・労務対応の予備費として織り込む」という保守的な前提を置くのが実務的です。

よくある質問（FAQ）

まとめ

Buy-and-BuildのAdd-on統合は、単発買収のPMIを繰り返し実行するだけでは成立しません。プレイブックを固定層と可変層に分けて使い回しつつ改訂し続けること、統合チームの人月キャパシティを四半期単位で管理して着手タイミングと統合度を調整すること、管理部門をAdd-onの買収より先に強化しておくこと、そしてシナジートラッカーを案件単位とPlatform単位の両方でロールアップして運用することが、反復統合に固有の実務です。

本記事の設例では、同じ47.0人月の統合需要でも、着手タイミングと統合度の組み合わせ次第でキャパシティ超過を解消できることを示しました。同様に、4件のAdd-onの実現シナジーが積み上がっていく過程では、個々の案件の実現率だけを見ていてはPlatform全体の進捗が見えないことも確認しました。いずれも、統合を「1回きりのプロジェクト」ではなく「継続するオペレーション」として設計し直すことが出発点になります。

個別の統合技術（Day1準備・100日プランの型）とモデル実装（S&U・シナジーのランレート）は、それぞれma-007・pe-032という確立した土台があります。本記事の枠組みは、その土台を前提に「何件も繰り返す」という条件を加えたときに何が変わるかを整理したものです。

出典・参考（2026年8月確認）

• Bain & Company「Private Equity Buy-and-Build: How to Get It Right」 bain.com
• 公正取引委員会「企業結合審査に関する独占禁止法の運用指針」 jftc.go.jp

※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。設例は理解のための仮設例です。