「Oracleの敵対買収の行く末」

　先日、ソフトバンクによるVodafone日本法人の買収が報道されたが、日本でも近年、企業買収とりわけ敵対的買収やそれに関わる金融テクニック用語もよく耳にするようになってきた。

　企業向け統合ソフトウェアパッケージの業界では、Oracle社によるPeopleSoft社の買収劇がメディアを賑わしたことが記憶に新しいが、このOracle社、この約2年間で実に20社以上のソフトウェア会社の買収を行ってきている。

　特にPeopleSoftやその後買収したSiebelについては、ERP/CRM分野で高いシェアを誇る企業向けソフトウェアパッケージベンダであり、Oracle社の買収も「敵対的」買収としての色がより濃いものであった。同社は以前からこの分野に「E-Business Suite」という名のソフトウェア製品群を投入していたが、ライセンス販売高や顧客シェアにおいて劣勢と言わざるを得ない状況にあった。

　コンサルタントという立場ではあるが、企業のシステム開発の現場近くに身を置く立場として、このOracleによる買収・合併の行く末は非常に気にかかる。

　冒頭述べたOracle社による企業向けソフトウェアベンダ買収の目的は主に、「短期的な財務指標の改善」と「カスタマーベースの取得」が中心であるように見える。この2点については、「１＋１＝２」となる世界であり、買収先企業の顧客は自動的に自社の顧客となり、売上げも自社に連結される。そして勿論、有力な競合企業の排除による市場影響力も相対的に増大することになろう。 　一方で、同社のWebサイトや報道発表では「複数製品による機能補完」や「より広範囲な統合アプリケーションの提供」をその目的として提示しているが、実現には多くの困難が待ち受けているだろう。 　そもそも企業向けのソフトウェアパッケージとは何か。

　さまざまな定義があると思うが、一般的には、企業の業務プロセスを自動化・効率化するために作成された汎用的なアプリケーションソフトウェアのことであり、購入して最低限の設定を行えば、短期間でユーザが利用開始できる。
また、設定に留まらず、導入企業毎にカスタマイズにより独自仕様を追加して機能を拡張するためのツールや環境を具備しているものも多い。

　現在、ERP（財務会計や人事などの基幹業務）やSCM（サプライチェーン管理）、CRM（顧客関係管理）などのさまざまな業務分野に特化したパッケージソフトウェアが販売されており、あらゆる業務分野への対応をうたった「統合スウィートパッケージ」と呼ばれる製品も開発されている。SAP R/3やOracleのEBS、PeopleSoftなどは企業向け統合スウィートパッケージを提供する大手のベンダであると言える。

　これらソフトウェアパッケージだが、実際のモノとしては、次のような構成要素から成り立っている。

　(1)アーキテクチャ（アプリケーション実行・開発環境およびその設計思想）
　(2)データモデル（データベーススキーマ）
　(3)ビジネスプロセス定義とアプリケーション（GUI、ビジネスロジック）

　(1)はシステムの稼動基盤であり、性能・処理効率や拡張性などを考慮したハードウェア・ソフトウェアの構成またはそれに係る設計思想を指す。
　(2)はアプリケーションが登録・更新・照会を行うデータの具体的な格納の仕方・構造のことであり、RDBMS（リレーショナル・データベース管理システム）上に実装されるデータモデルとほぼ同義である。業務プロセスの特性を踏まえたデータ構造や、効率的なデータ格納方法などが考慮・定義される。
　(3)が最もユーザに馴染みやすい部分で、想定する業務プロセスの定義と、その実行のための具体的な画面と、その操作に伴って実行される各種ビジネス処理である。

　これらの3点があらかじめ定義・実現され、すぐに使えるように製品化されたものが企業向けソフトウェアパッケージであると言える。

　少々説明が長くなったが、このようなソフトウェアパッケージを製造するベンダ間で買収があった場合、製品はどうなるのか？「お互いのいい所を補完しあってより良いものに」と言うのは簡単だが、異なる製品同士の統合は非常に困難である。

　まずはアーキテクチャの観点。前述したパッケージの構成要素のうち、アーキテクチャ統合は、非常に困難を極めるケースが多い。そもそも2階層のC/S構造の製品と多階層Webアプリの統合などは限りなく無理が生じるであろうし、ソフトウェア構成が似通っていたとしても、機能や処理の分散・配置に関するポリシーが異なる場合、統合はやはり容易ではないだろう。

　次にデータモデル。データモデルの流用については、ある程度実現が可能かも知れないが、製品として販売されているPKGの場合は、アプリケーションの実装に即して物理構造が最適化されているケースが多く、そのままの流用は困難。論理設計レベルでの適用でどの程度のメリットが出るのかは要検討だ。
　また、製品同士で業務カバレージが重複するケースも多く、その場合はデータの保持についても重複が発生することになる。顧客や自社組織といったマスタデータの構造しかり、受発注などのトランザクションデータの構造しかり。ベースにあるデータとその関連の前提が異なる場合、モデル統合というよりは重複保持を前提とした連携・同期といったサブシステム間I/Fの実装へ寄ってしまうことも多いだろう。

　最後にアプリケーション部分。この部分については、上記2点の統合ができない場合、そのまま使うことはまず不可能。特にGUI部分については製品の独自色が出やすい（画面構成や遷移のクセなど）ため、異なるアプリケーションのつぎはぎはオペレーションの複雑化や不整合を生みやすい。せいぜい業務レベルでの機能・処理をどちらか一方に実装しなおすといった流用がいいところだろう。

　このように考えてくると、買収によって製品そのものがより良い統合された１つの製品に生まれ変わるということはほとんど期待できないのではないか、という思いが強くなる。まして、1社や2社でなく数十社の製品を統合するとなると尚更だ。買収された企業のソフトウェアを利用しているユーザにとっては我慢ならない話だろう。

　このような現実を受け、買収攻勢を続けるOracleが選択したのは、製品の再構成としての統合ではなかった。 「プロジェクト・フュージョン」と銘打ち発表された同社の製品統合のロードマップは、アーキテクチャ統合やデータベース統合をあきらめ、EAI/BPM領域に位置づけられるミドルウェアを利用し、相互接続性を担保していこうというソリューションだった。見方によっては「間に合わせ」的で根本から目をそらせたアプローチと言えない事もない。

　顧客の立場からすれば、同じ会社の製品をつなぐためにEAI/BPM製品が必要というのはどう考えてもばかばかしい話だ。

　そもそも最終消費者が「サービス」に対価を払う銀行や小売の合併と違い、ソフトウェア企業の場合はソフトウェアという「製品そのもの」に金を払っている感覚が強い。パッケージソフトの良いところは、必要なものから早期に導入でき、後から徐々に業務領域を拡張していけるところだったのに、買収の結果、その道が断たれたり、明らかに「合わない」製品にゴテゴテとアダプタをつけて購入しなければならないとなれば、容易には納得できないだろう。

　とはいえ、既に述べたように真っ向から製品に立ち向かい１つの統合製品をつくるにはあまりにも多くの企業を買収してしまっているのも事実。獲得した顧客ベースをつなぎ止め、同時にビジネスを継続していくための唯一現実的な方法がプロジェクト・フュージョンだったのかも知れない。 　折りしも「SOA」なんて言葉が流行っており、既存資産の有効活用とか、サービスを媒介にしたシステムの有機的な疎結合なんてこともまことしやかに語られている。しばらくはこれで良い、もしくは中継ぎ手段としてはこれで良いのかも知れない。

　ただし、システムの一般的な寿命を5年～10年とした時、10年後、15年後に同社のエンタープライズアプリケーションの姿が、買収してバラバラに作ったものの寄せ集めの域を出なかったとしたら、顧客はきっと離れていくだろう。

　かつてERPベンダだったPeopleSoft社がCRMで高い導入実績を誇ったVantive社を買収した際にも同じようなことが懸念された。しかし同社は、自社の既存製品のアーキテクチャ更改の際、VantiveのCRMアプリケーションを完全に新アーキテクチャ上に載せかえてみせた。継承されたのは、設計仕様とも言うべき「機能性」のみといっても良い。

　長期的な視野から真に統合されたエンタープライズパッケージを目指すのであれば、自社のコア製品（E-Business Suite）と買収した各製品について、真剣に、詳細な分析を行って欲しい。そしてあらゆる角度から再評価を行い、優れているところ、劣っているところをスコアリングする。それに基づいて、存続するアーキテクチャを選定、もしくは新しいアーキテクチャを検討する。
　また各アプリケーション機能やデータモデルについては注意深く統合を行い、効率が悪い部分については思い切って設計仕様のみを受け継いで実装はスクラッチで行うことも検討する。

　このようなアプローチによって、全プロダクトを一貫性のある作りにして真の意味での「統合アプリケーションスウィート」を作るためのロードマップをユーザに公開すべきではないだろうか。場合によっては、旧Apps、EBSのアーキテクチャを捨てて買収した中の1社のアーキテクチャに合わせるとか、そんな大胆な選択も有効かも知れない。
　それができないというのならば、結局はマネーゲーム、顧客に対して高い価値を提供し続けていた企業を、自らの存続や利益拡大のために潰し、結果として最終消費者にそのつけを払わせたと言われても仕方がないのではなかろうか。

　キャッシュに物を言わせて企業向けソフトウェアパッケージ市場の再編を無理やり加速させたOracleは、その責任を重く受け止めて、最も広いカバレージを持った最も良い製品を提供してもらいたいものだ。