OracleによるSun買収ですが、ソフトウェアの領域についてはそれほど心配していません（MySQLはどうなるの等の話はありますが）。ソフトウェア企業の買収についてはOracleは相当の実績があります。問題は、Oracleにとって基本的に初体験となるハードウェア事業、特にSPARC/Solarisサーバのビジネスです。

繰り返しになりますが、ベンダーが今までビジネスを行なっていたレイヤーを越えて別のレイヤーに進出する場合には、それによる市場拡大のメリットと、今までのパートナーとの競合増大によるデメリットのトレードオフを十分に考えることが必要です。

この点をふまえて、Oracleが取り得る選択肢について考えてみます。

１．SPARC/Solarisサーバを強力に推進し、Oracleソフトウェアとの統合ソリューションを追求する

なんだかんだ言ってSolarisは現時点で最もスケーラブルなUnix OSと言って良いでしょう。Oracleのソフトウェアと統合することで、テクノロジー的にきわめては強力なソリューションが実現できることは充分に予測できます。

しかし、今日のIT市場で成功するための最重要要因はテクノロジーの優秀性ではありません。市場のエコシステムです。

SPARC/Solarisとの統合性を強化することで、今までのOracleのハードウェア・パートナーであるHP、IBM、Dell等々との利害相反が生まれてきます。現時点でのサンのサーバ市場におけるシェアはおよそ10%です。10%の市場機会を追求するために、残りの90%の市場機会に悪影響を与えるのは不適切な戦略だと思います。

仮にOracleがソフトウェア市場で圧倒的な地位を占めており他に選択肢がない状況であれば、まだ強気に出れますが、実際にはMicrosoftが多くのソフトウェア領域で後ろに迫っています。アプリケーション・パッケージの領域ではSAPもいます。まさに、「Oracleがハード事業に力を入れれば入れるほどMicrosoftが得をする」ということです。

さらに、SPARC/Solarisのラインを強化していくためには、SPARCプロセッサの性能を継続的に向上していくというきわめて困難な作業が待っています。ハードウェア分野のエンジニアリングにコアコンピタンスを有するSunですら、匙を投げかけている課題です（過去にSPARCのプロジェクトを指揮していたDavid Yen氏は退職してジュニパーに行ってしまいました。）ハードウェア分野での経験がほとんどないOracleがこの課題を解決することは困難と思われます。

結論として、この選択肢は、「事業拡大の機会」＜「既存パートナーとの競合による損失」となる可能性が高いと思います。

２．SPARC/Solarisサーバを限定的な位置づけにする

SPARC/Solarisサーバはアプライアンス的な使い方に限定して、オープンなサーバ製品は今までどおりパートナーに依存する戦略です。いわばSPARC/Solarisサーバを塩漬け戦略です。ハードウェア事業買収のメリットは小さいがデメリットも小さいと言えます。ただし、既存のSPARC/Solarisサーバのユーザーに取っては最悪の戦略と言えるでしょう。

３．統合とオープンの絶妙なバランスを取る

IBMもミドルウェア/DBMSとハードの両方を扱っており、統合ソリューションの価値とオープン性のバランスをそれなりにうまく取っています。Oracleも同様のソリューションを追究可能と言えるかもしれません。

しかし、IBMは基本的にはサービスで稼ぐ企業であるという点がポイントです。たとえば、IBMのハードやIBMのソフトとが使われていない環境でも人によるサービスで収益を上げられます。IBMにとっては、ハードやソフトの製品ビジネスは二義的です。製品指向が強いOracleがこのモデルをまねるのは厳しい気がします。

４．ハードウェア市場への進出をさらに加速する

選択肢1の問題点は、サーバ市場のシェア10%程度を押さえたくらいでは中途半端であるという点にあります。要は「中途半端にやるくらいなら全然やらない方がまし」ということです。ここで、逆転の発想でさらにハード市場への進出を加速するという大技が考えられます。OracleがIBMやHPのサーバ事業を買うことは想定しがたいですが、Dellを買う可能性はゼロではないでしょう。

５．ハードウェア事業をスピンアウトする

SPARC/Solarisの問題はOrcaleにとって規模の経済のメリットを得るにはシェアが小さすぎ、ニッチと割り切るには既存ユーザーが多すぎるという点でしょう。結局、シナジーを出せる企業に売却するのが最適と思われます。

ということで、ざっと考えてみると、既存のSun顧客、Oracle顧客、そして、Oracle自身にとっても最良の選択肢は5であると思います。ただし、大穴としての4の可能性は否定しませんが。

Oracleによる買収という形で決着が付きそうですが、Sun Microsystemsの独立企業としてのライフサイクルは終わりということでよいでしょう。盛者必衰は世の理とは言え、ピークの頃からSunをIT業界アナリストしてずっとウォッチしてきた自分としてはちょっと寂しいものがあります。

ここで、Sunの企業戦略のどこがいけなかったのかをダメ出し分析してみたいと思います。なぜ、Sunは今のような状態になってしまったのでしょうか？なぜ、自らをreinventできなかったのでしょうか？「後付けでなら何とでも言える」、「外部者にはわからない内部事情があるんだよ」等々の批判は覚悟の上で、反面教師としてのSunを分析してみましょう。

１．業績がピークの時に適切なイノベーションを行なわなかった

Sunが企業として大きな成功を収めることができた最大の要因はドットコムバブル初期の1997年にハイエンド・サーバのEnterprise 10000 （Starfire）を投入できたことにあります。

Starfireは当時のUnixサーバとしては圧倒的なオンライントランザクション処理（OLTP）性能を発揮していました。OLTPで高性能を実現するためには、CPU本体の性能もさることながら、CPU-メモリ-I/Oをつなぐインターコネクトの帯域幅が大きいことが重要です（ちなみに、CPU能力としては比較的非力なメインフレームが現実世界のOLTPではきわめて高い能力を発揮できる理由のひとつがこれです。）Sunは、Cray ReseachのBusiness Systems DivisionのテクノロジーをSGIから買収することで強力なイノベーションを達成できました（Sunの某マネージメントによれば、ITの歴史で二番目に成功したテクノロジー買収だそうです、ちなみに最大の成功はMicrosoftがSeatle Computing ProductsからMS-DOSを買ったケースだそうです。）当時のIBMやHPのハイエンドサーバはCPU能力での格差はそれほどなかったのですがこのインターコネクトでSunに大きな差を付けられていました。

しかし、Sunはこの成功の後で大きなイノベーションを提供できませんでした。確かに組織の規模や製造組織の拡大は行なったのですが、質的なイノベーションが十分に行なわれていなかったことように思えます。どれほど画期的なイノベーションであってもせいぜい2年で他社に追いつかれてしまうのが、今日のハイテク業界の現実です。実際、HPやIBMが本気になった段階で、Sunのハイエンド・サーバの優位性はなくなったとは言わないまでもかなり減少してしまいました。

先頭に立ったときこそがさらに加速を強めるタイミングです。これがイノべーションの法則です。

さらに言うと、Starfireの品質上の問題を充分に解決できなかったのも痛かったと思われます。どんなマシンにもトラブルはありますが、Sunのトラブル対応はエンタープライズ・ベンダーのものとしてはふさわしくなかったとの意見が聞かれていました（あくまでも当時の話です）。

２．M&Aが下手だった

上記にも関係しますが、IT企業がイノベーションを継続していくためにはM&Aは必須です。しかし、Sunは決してM&Aが得意とは言えないと思います。もちろん、上記のとおりStarfireは大成功だったのですが、それ以外の買収はほとんど成功していません。最も悲惨だったのはCobalt Systemでしょう。MｙSQLも微妙（そもそも、OSSの買収に意味があるかという問題もありますが）。StorageTekの買収もうまく行ったとは言えません。StorageTekの買収メリットについてSunの某マネージメントに聞いたことがありますが、「StorageTek社の顧客に容易にアクセスできるようになった」との答が返ってきました。それが最大のメリットであると言うのならば、会社を丸ごと買収しなくても、優秀な営業を引き抜けばよかった話です。

Sunは一見オープンな思想を持った企業のように見えますが、実はNIH（Not Invented Here; 自社由来でないテクノロジーを軽視する傾向）が強い企業であったと思います。ドル箱のプリンタ事業の基本テクノロジーをキャノンに依存しているHPとは対照的です。

３．キャッシュカウの事業を欠いていた

まだSunが調子が良かった頃のアナリストイベントでスコット・マクニーリは、他社の事業の利益ブレークダウン（推定）のグラフを見せながら、「HPはプリンタ・インクカートリッジ企業である。IBMはメインフレーム保守サービスの企業である。これに対して、Sunはコンピューター製造企業である。」などとの主張を行なっていました。まあ、確かにそうなんですが、これは別の言い方をするとSunにキャッシュカウ事業（成長性はなくても確実に利益を生み出してくれるビジネス）がなかったということを表わしています。つまり、Sunは常に新しいマシンを売り続けないと成長を維持できないという財務的にはあまり魅力的でないビジネスモデルの企業であったわけです。後に、この問題を解決するために、Java Enterprise Systemをサブスクリプション制料金で提供するという戦略も追求しましたが、”too late, too little”であったと思われます。

４．競合のメッセージングを誤った

スコット・マクニーリは初期にはMicrosofｔを、そして、比較的最近ではIBMを徹底的にけなしてたのは有名です。こういうやり方はわかりやすいですし、プレスも記事にしやすいのでしょうが、行き過ぎると「顧客のためのソリューションではなくMicrosoft対抗のためのソリューション」ばかりを追求する結果になりかねません。

もうひとつ、Linuxが企業ITの世界で勢いをつけつつあった時の戦略も問題だったと思います。その時点で、Solarisをオープン化して徹底的に対抗するか（OpenSolarisのタイミングは2年遅かったと思います）、あるいは、Linuxを全面的に採用してハードと上位ソフトで差別化する戦略に出るべきだったでしょう。