【Part 2】大手ソフトウェア企業が陥るM&A後の落とし穴とは？

※「【Part 1 - ①】大手ソフトウェア企業によるM&Aが失敗しがちな理由とは？」の続き

前章では、本稿Part 1では、大手ソフトウェア企業によるM&Aが失敗しがちな理由に関して詳しく解説しております。

本稿の内容への理解をより深めるために、是非、インベストリンゴのプラットフォーム上にて、前章も併せてご覧ください。

M&A後の落とし穴

計画と実行

Part 1で触れた課題を踏まえると、多くのソフトウェアM&Aが不十分な計画や実行ミスに悩まされるのは不思議ではありません。多くの場合、こうした取引はコンサルタントや売り手側のアナリストが作り上げたトップダウンのストーリーに基づいて進められます。彼らの巧みな物語が、現場の具体的な課題や実態を軽視させてしまうことが少なくありません。その結果、高い期待値と現場での現実が乖離し、買収後に経営を引き継ぐ側が対象企業の業務や技術を十分に理解できないまま、シナジー効果がほとんど得られない、あるいはむしろマイナスになることもあります。

典型的な例として挙げられるのが、2011年にヒューレット・パッカードが110億ドルで行ったAutonomyの買収です。ハードウェア中心の企業であるヒューレット・パッカードは、Autonomyが提供するAIベースの自動化の可能性に魅了されました。ただし、当時のAI技術は、現在のChatGPTのような高度な技術と比べると遥かに未発達なものでした。同社はAutonomyの実際の製品を十分に精査することなく、物語に引き込まれる形で買収を進めました。しかし買収後、Autonomyの製品が期待に応えないことが判明し、結果として善意（のれん）の全額を償却する事態に陥りました。その後、Autonomy創業者に対する企業詐欺の訴訟をめぐる長期的な法廷闘争へと発展しました。

もう一つの教訓となる事例が、2010年にインテル（INTC）が76.8億ドルでMcAfeeを買収したケースです。インテルは、エンドポイントセキュリティを自社のチップ技術に直接統合することを目指しましたが、このビジョンは実現しませんでした。インテルの管理下で、McAfeeは革新性を失い、その元CTOは新たにクラウドストライク（CRWD）を設立しました。クラウドストライクは現在、エンドポイントセキュリティ分野のトップ企業となっています。一方で、McAfeeは停滞し、一桁台の低成長率と弱い収益性にとどまりました。この結果は、買収当初のインテルのビジョンとは大きくかけ離れたものでした。

同様に、イーベイ （EBAY）は2005年に26億ドルでSkypeを買収し、リアルタイムコミュニケーションを自社のeコマースプラットフォームに統合することを目指しました。しかし、統合は計画通りには進まず、Skypeはビデオ会議の需要が高まる中でそのチャンスを活かせませんでした。一方で、シスコシステムズ（CSCO）のWebexや後に登場したズーム・コミュニケーションズ（ZM）といった競合他社が市場をリードし、Skypeはイーベイ のポートフォリオの中で期待を満たせない存在となりました。

これらの事例は、M&A戦略を現実的な運用計画と一致させることの重要性、そして買収後の経営陣が買収対象企業の能力や市場でのポジションを深く理解する必要性を浮き彫りにしています。しっかりとした実行計画がなければ、どれほど魅力的なM&Aストーリーであっても、すぐに崩れてしまう可能性があります。

ガバナンスと企業文化

ソフトウェア企業にとって最大の資産はその「人材」です。この人材を維持するためには、強固なガバナンスと健全な企業文化が欠かせません。しかし、買収する側は、買収対象企業の成功を支えてきた士気や文化、ガバナンス体制を維持することに苦労することが多いのが現実です。主な課題として以下が挙げられます：

文化的な抵抗が変革を妨げる

買収側と買収対象の両社の開発者たちは、それぞれの特定のワークフローに慣れ親しんでいることが多いです。特に成熟した買収側の企業では、一部の開発者が既存のやり方に固執し、ストレスの少ない環境や変化の少ない状況を好む傾向があります。そのため、M&Aによる変化に直面すると抵抗が生じ、シナジーの実現が遅れたり、最悪の場合は妨げられることがあります。しかし、買収側の企業が頻繁にM&Aを行ってきた実績がある場合、開発者たちが定期的な変化に適応している可能性が高く、これが統合のスピードを上げる大きな利点となることもあります。

買収対象企業の優秀な人材が旧来の慣習に抑圧感を抱く可能性

買収対象企業の開発者たちは、強い職業倫理を持ち、共通のビジョンに向かって働いていることが多いです。しかし、旧来の慣習や緩慢なイノベーションサイクルに適応を強いられると、フラストレーションを感じる場合があります。このような緊張状態は、対象企業のソフトウェア成功に不可欠だった優秀な開発者の離脱を招くリスクがあり、M&Aの長期的な成果を危うくする可能性があります。

ビジョンの対立と統合の課題

買収が失敗に終わる要因の一つに、買収側の経営陣が対象企業の技術を変革的な力と捉え、既存のITチームの確立された慣習を軽視するケースがあります。2013年のIBM（IBM）によるSoftLayer Technologiesの買収はその好例です。IBMはSoftLayerの高度なインフラを統合し、自社のクラウドサービスを強化することを目指しました。しかし、SoftLayerを競争の激しいクラウドコンピューティング市場でリーダーとして位置付けるのではなく、IBMはSoftLayerのインフラを自社のコンサルティングやエンタープライズサービスを支えるために活用することを優先しました。この内向きな戦略により、SoftLayerが広範なクラウドコンピューティング市場で地位を確立し拡大するためのリソースと注力が不足する結果となりました。

戦略的優先順位の不一致により、IBMのITチーム内で軋轢が生じ、新たな技術やビジョンへの適応に苦戦しました。時間が経つにつれて、SoftLayerの外部市場シェアを拡大するための一貫した努力が欠如したことで、競争力が徐々に低下しました。こうした戦略の方向性に不満を抱いた創業者たちは最終的に離脱し、ランス・クロスビー氏は新たにStackPathを設立しました。この事例は、戦略ビジョンの整合性を欠き、外部成長に必要なリソースを十分に割り当てないことが、どれほど有望な買収であってもその成功を妨げる可能性があるかを示しています。

旧態依然としたガバナンス構造がイノベーションを阻害する

買収側の企業は往々にして過剰な中間管理職や硬直的な報告体制を伴う官僚的な構造を持ち込み、結果よりもプロセスを重視する傾向があります。このような環境では、政治的な駆け引きや細部にまで干渉する管理が横行し、エンジニアリングやイノベーションよりも手続きが優先されます。その結果、ガバナンスの問題が人材の定着率を低下させることがよくあります。優秀な人材は窮屈さを感じて退職し、一方で、活力に欠ける社員は会社を「定年前の安定した避難所」と見なし、残り続けるという状況が生じます。

ソフトウェア統合の複雑性

例えば、買収側の企業が500万行のC++コードで動作するソフトウェアを持ち、買収対象の企業が50万行のJavaコードを持っているとします。この2つのコードベースを統合する課題は非常に大きなものです。JavaベースのソフトウェアスタックをC++環境に組み込もうとすると、膨大な複雑性と技術的負債が発生し、将来的なイノベーションや機能開発が一層困難になります。

統合の課題と技術的負債

異なるソフトウェアスタックを統合することは、単に複雑性を増加させるだけでなく、技術的負債を何倍にも膨らませます。新しいコードを1行追加するごとに増えるのは線形的な複雑性ではなく、指数的な相互依存性です。例えば、1,000行のコードベースに10行のコードを追加すると、複雑性が単純に1%増えるわけではなく、新たなコードが既存の構造と予期せぬ形で相互作用するため、その影響ははるかに大きくなります。M&Aにおいては、異なるコードベースやプログラミング言語、開発手法が衝突し、この相互依存性が複雑性をさらに増幅させ、イノベーションや適応をますます困難にします。

通常、完全な統合はほぼ不可能です。その結果、最終的には一部の機能だけが統合され、残りは時間とともに廃止されることが多く、大きな価値の損失につながります。あるいは、買収側がコードベースを分離したまま維持することを選ぶ場合もありますが、その場合、単一のコードベースを管理するよりも遥かに多くの労力が必要になります。

レガシーシステムとイノベーションの需要のバランス

優れたソフトウェア（Best-of-Breed: BoB）を持つ多くの企業は、そのコードベースが時代遅れであることや、柔軟性に欠けた固定的な手法で作られているため、やがてレガシーシステム化してしまいます。オンプレミスのソフトウェアからSaaSへの移行を目指す企業は、膨大なプレッシャーに直面します。技術スタックをゼロから再設計するための膨大な時間と労力、投資家の焦り、そして変革にかかるコストがその一例です。

こうした状況下で、企業は株主を納得させるために、旧来のシステムを新たなパラダイムに適応させようとしますが、これは「四角い杭を丸い穴に無理やり押し込むようなもの」であることを分かっていながら進めるケースが多いです。それが不可能と分かった場合、関連する技術を獲得するために買収に頼ります。しかし、これによってさらなる複雑性が加わり、ソフトウェアスタックは断片化し、管理やスケールアップが一層困難になるという結果に陥ります。

「レシピ」よりも原理原則の理解を重視すること

多くのソフトウェアチームは、アプリケーションを迅速に開発し、最適化されたユーザー体験を提供するために、既存の定型的な「レシピ」に頼っています。この方法はスピードを重視する場面では効果的ですが、クラウドコンピューティングへの移行といったパラダイムシフトが起きると、こうした硬直的なレシピが障害となり、チームの柔軟な適応を妨げてしまいます。

例えるなら、パンを作るために水、小麦粉、イーストを混ぜる方法を知っているとしても、それが料理全般をできることを意味しないようなものです。同様に、特定の「レシピ」に慣れた開発者は、新たなパラダイムに適応する際に苦労することがあります。一方で、原理原則を深く理解している開発者は、こうした表面的な変化に惑わされることなく、ソフトウェアの本質を理解して柔軟に対応することができます。

このような知識は、M&Aにおいて特に重要です。ソフトウェアの根本原則を理解している開発者は、統合の複雑性に圧倒されることなく、それをソフトウェアの基本原則や適応能力の延長線上として自然に捉えることができます。しかし、残念ながら多くのテック企業はこのような深い理解を欠いているため、M&A後に技術的負債が指数的に増加し、将来の成長や適応性を阻害する結果を招いています。

別の選択肢：構築か買収か

場合によっては、買収対象のソフトウェアをリバースエンジニアリングし、一から順を追って自社で構築する方が、統合や技術的負債に関する長期的な課題を軽減できることがあります。一部のソフトウェア開発の専門家は、アプリケーションの複雑性が膨れ上がるのを防ぐために、3～5年ごとにゼロから再構築することを推奨しています。

しかし、リバースエンジニアリングには特許侵害のリスクや市場投入の遅れといった課題が伴います。また、ソフトウェア市場は急速に進化するため、新たな領域に進出したり、買収側の中核分野を超えて事業を拡大したりする際に、一からの構築を選択するのは現実的ではありません。

多くの企業にとって、生き残りや市場での relevancy（存在感）を確保する最も迅速な手段は、たとえ統合の複雑性を伴うとしても、買収を通じて解決することなのです。

M&Aにおける技術的負債の評価

買収側と買収対象の双方の技術的負債のレベルを理解することは非常に重要です。技術的負債が高い場合、顧客のオンボーディング体験が悪化し、顧客サポートコストが増加する一方、負債が低い場合はCOGS（売上原価）の削減や長期的な粗利益率の向上につながります。

技術的負債を測定するために、開発者向けにはコードの複雑性、コードの変更頻度（コードチャーン）、バグ修正にかかる時間などを評価するツールが利用可能です。また、DevOpsチームはDORAメトリクスを活用して効率性や負債レベルを評価することができます。

また、外部の利害関係者、例えば投資家にとって、技術的負債を示す指標としては、新機能リリースの頻度、イノベーションに関する業界での評価、そしてエンジニアリングチームが技術的負債の管理状況を企業のブログやYouTube動画を通じて共有する透明性の取り組みなどが挙げられます。

特にクラウドフレア（NET）は、人気のあるエンジニアリングブログを通じて技術的課題を公に共有している優れた例です。このような取り組みにより、技術者コミュニティや投資家からの信頼を築き、優れた評価を得ています。

ビジネスモデルとアーキテクチャ統合の複雑性

ソフトウェアM&Aを検討する際、買収側と買収対象の収益モデルの違いが統合に大きな影響を及ぼすことがあります。例えば、一方がライセンスベースで、もう一方がSaaSベースの場合、収益ストリームの調整が複雑になり、それが粗利益率への影響を理解することをさらに困難にします。

仮に両社がライセンスベースであっても、一方は永続ライセンス、もう一方は使用量ベースのライセンスを採用している場合や、両社がSaaSベースであっても、一方がシートライセンス（ユーザー数ベース）、もう一方が使用量ベースで運営している場合があります。これらそれぞれの収益モデルは固有の特徴を持ち、それがビジネスモデルの統合のしやすさに影響を与えます。

マルチテナンシー（複数顧客の共有構造）の程度が異なるアーキテクチャの違いは、統合を一層複雑にします。例えば、買収側の企業がインフラの共有に限定したマルチテナンシーモデルを採用している一方で、買収対象企業がインフラ、ソフトウェア、データベースを顧客間で広範囲に共有するモデルを採用している場合があります。特にSaaS環境では、こうした異なるアプローチを統合することが大きな複雑性をもたらします。

さらに、顧客のニーズがこれらのマルチテナンシーの選択に影響を与えることもあります。規制の厳しい業界の大手企業では、データの分離をより厳格に求められる場合があり、完全なマルチテナントシステムの利用が困難になることがあります。そのため、両社がSaaSを採用している場合でも、マルチテナンシーのアーキテクチャの違いが統合に新たな課題を加える要因となります。

収益モデルやマルチテナンシーを超えた課題として、技術スタックのオープン性もM&Aにおいて極めて重要な要素です。買収側がクローズドソースのソフトウェアスタックを採用している場合に、オープンソースの企業を買収すると、摩擦が生じる可能性があります。例えば、何百万人もの開発者からなるコミュニティを持つオープンソース企業が、買収後にコードへのアクセスを制限し、クローズドソース化すれば、その支持を失うリスクがあります。このような変化は開発者を疎外し、無料および有料の両方の利用層を失う可能性があり、結果としてユーザーや収益に悪影響を及ぼします。

これらの動きはユニットエコノミクス（単位経済性）にも影響を与え、COGS（売上原価）や粗利益率に影響を及ぼします。特に計算リソースの需要はCOGSや粗利益率に大きな影響を与えます。例えば、ネットワークセキュリティベンダーのような高エントロピー情報を扱うソフトウェア企業は、大量のデータ「ノイズ」を管理するため、計算能力や帯域幅の需要が増大します。一方で、生産性ソフトウェアのような低エントロピー分野では、必要なリソースが少なく済むため、負担が軽減されます。

このようなユニットエコノミクスの違いは、M&Aのデューデリジェンスにおいて慎重に評価されるべき重要なポイントです。

買収側と買収対象の垂直統合の程度も重要な検討事項です。もちろん、すべてのソフトウェア企業はソフトウェア層で事業を展開していますが、中にはデータ層やインフラ層、さらにはハードウェア層まで垂直統合を進めている企業もあります（例：独自のカスタムチップを開発するなど）。こうした企業は、サードパーティを排除し、上流の層を独自に開発することで、一層の競争優位性を確立しています。

ハイパースケーラー（超大規模クラウドプロバイダー）は、ソフトウェア層からハードウェア層まで完全に垂直統合を行う企業の代表例ですが、小規模なプレーヤーも上流に進出し、サードパーティへの依存を減らし、コスト削減やサプライチェーンの制御強化を図っています。例えば、フォーティネット（FTNT）やクラウドフレア（NET）のようなネットワークやサイバーセキュリティのベンダーがその例です。

統合する企業の一方だけがソフトウェア層を超えて垂直統合を進めている場合、より大きなシナジー効果を得られる可能性があります。例えば、買収側が独自のデータ層を持つ垂直統合型企業である場合、ソフトウェア層に特化した買収対象企業を統合する方が、統合の課題が少ない傾向があります。ただし、両社がソフトウェア層に共通して存在していることが、多くの場合で統合の前提条件となります。そうでない場合、インテルとMcAfeeの例のように、重大な不整合が生じる可能性があります。インテルはソフトウェア層での経験がほとんどなく、そのためにコミュニケーションがうまくいかなかったことが一因とされています。

弊社はテクノロジー銘柄に関するレポートを毎週複数執筆しており、弊社のプロフィール上にてフォローをしていただくと、最新のレポートがリリースされる度にリアルタイムでメール経由でお知らせを受け取ることができます。

加えて、その他のアナリストも詳細な分析レポートを日々執筆しており、インベストリンゴのプラットフォーム上では「毎月約100件、年間で1000件以上」のレポートを提供しております。

弊社のテクノロジー銘柄に関する最新レポートを見逃さないために、是非、フォローしていただければと思います！

アナリスト紹介：コンヴェクィティ

📍テクノロジー担当

コンヴェクィティのその他のテクノロジー銘柄のレポートに関心がございましたら、こちらのリンクより、コンヴェクィティのプロフィールページにてご覧いただければと思います。