アイキャッチ画像

.Net 技術を巡るマイクロソフトの戦略を考える

  • このエントリーをはてなブックマークに追加

by [2014年12月15日]

Windows 8.1 Pro デスクトップ
現行最新の「.NET Framework」動作環境。

マイクロソフトの現在の主力製品が何なのかについてはいささか議論が分かれるところですが、同社で最も知名度が高い製品が「Microsoft Windows」ファミリーであることには恐らく異論はないものと思います。

そのWindowsは基本的にはx86系と一般に呼ばれるインテルが開発したCPUアーキテクチャのための命令セットでプログラムがコーディングされ、実際にもWindows RTと呼ばれるARM系プロセッサ用のバージョンを別にすれば、そのほとんどがx86系CPUを搭載するマシン上で動作しています。

もっとも、Windowsに「モダン」なOSとしての機能をもたらしたWindows NTではx86とは異なるRISCアーキテクチャに基づくプロセッサにも対応していましたし、マイクロソフトにとって2世代目の家庭用ゲーム機であるXBOX 360ではOSとしてWindowsのカスタマイズ版が提供されていましたが、この機種に搭載されているCPUはやはりRISCアーキテクチャによるIBMのPowerプロセッサが採用されています。

また、モバイル機や組み込み用途に目を向けると、Windows CEにせよWindows Phoneにせよ、その搭載マシンのほとんどにARMやMIPSといったRISCプロセッサが採用されており、x86系プロセッサの出る幕はほとんどありません。

Microsoft Surface 2
数少ないWindows RT搭載の一つ。

そんな状況であるのにメインストリームのパソコン向けWindowsがx86系を墨守しているのは、ひとえに既存ソフトウェア資産を抱えるユーザーが動作互換の必要からそれを望んできたからです。

実際、ARM系プロセッサに対応するWindows RTは鳴り物入りで登場したものの、恐らくは消費者や市場が最も望んでいたであろうx86版Windows用デスクトップアプリケーションがサポートされず、それどころかデスクトップ機能そのものが削除されていたこともあって気がつくと市場にほとんど搭載製品がないという悲惨な状況となりました。

アプリケーションをアーキテクチャ非依存にする

しかしこの状況は、こう解釈することも可能です。

すなわち「アプリケーションをCPUアーキテクチャ非依存にしてしまえば、パソコンに(性能以外の理由で)x86系プロセッサを採用する必然性はなくなる」と。

過去のアプリケーションソフトを全てCPUアーキテクチャ非依存にするのは困難ですが、これから作られるアプリケーションソフトをアーキテクチャ非依存とするのはそれほど困難ではありません。であるならば、現行のOS上でそうしたアーキテクチャ非依存のアプリが動作する環境を用意してやればよい、ということになります。

ここまでの話で、Javaの仮想マシン(JVM)の仕組みを思い起こした方もおられることでしょう。

JVMはまさに特定のアーキテクチャではなく抽象化されたアーキテクチャによる仮想マシンを用意し、その仮想マシン上でコードを解釈し、実際のOS上のサービスに変換して実行する仕組みとなっています。

そのため、これを使えれば現在のAndroidがそうであるように、アプリケーションソフトのCPUアーキテクチャ非依存化は可能です。

しかし、マイクロソフトはこのJavaをそのままアプリケーションソフトのCPU非依存化のために採用することが出来ませんでした。

というのも、同社はJavaの開発元であったサン・マイクロシステムズから、マイクロソフトが自社のソフトウェアで独自に開発・実装していたJVMについて訴訟を起こされていたからです。

独自JVMを製品に搭載できなくなったマイクロソフト

この訴訟はマイクロソフトがInternet Explorer(IE) 4.0に独自のJVMを組み込む際に、当時Windows用ブラウザとしてトップシェアを占有していたIEの普及率を背景に勝手な独自拡張を行い、サン側からの純正JVMと100パーセント完全互換のJVMを搭載するようにとの要請を無視したことが原因で起きたものです。

これについては、2001年6月に連邦高等裁判所がマイクロソフトの行為を独占的地位の不当乱用と認める有罪判決を下し、そのためマイクロソフトは独自拡張したJVMのWindowsへのバンドルを停止せざるを得なくなりました。

また、そもそも当時のパソコンやJVMの性能ではJavaで書かれたCPU非依存のアプリで十分な性能を得るのが難しいという問題(※注1)もありました。

 ※注1:AndroidでJVMを基礎とするCPUアーキテクチャ非依存アプリが実用化出来た背景には、JITコンパイラのサポートなどJVMそのものの抜本的な改良が行われてJavaで書かれたアプリの実行速度が大幅に向上したことがあります。

「.NET」技術の誕生

こうした情勢下で、マイクロソフトは2000年頃から「.NET Framework」としてアプリケーションソフトのCPU非依存化を実現するアプリケーション開発・実行環境(※注2)の開発を開始しました。

 ※注2:「.NET Framework」は単なるJava環境の代替物というわけではなく、CPUのみならず開発言語にも依存しない中間言語コード(managed code)を採用しています。このため、C言語など他の言語で書かれたプログラムもコンパイルして中間言語コードに変換できるようになっているなど、より高度な仕組みを持っています。

この「.NET Framework」はOSのバージョンアップなどに合わせてバージョンアップを繰り返し、Windows 8やWindows 8.1のいわゆるWindowsストアアプリ(Modern アプリケーション)ではこの「.NET Framework」の技術を基礎とすることで、対応CPUアーキテクチャの異なるWindows RTとのアプリケーションプログラムの共通化を実現しました。

さらに以前の記事でもご紹介しましたが、現在3系統に分かれているWindowsをこの技術を用いて統合し単一のOSに整理統合することも予定されており、プロセッサごとに分かれているWindowsアプリケーションは、将来的にこの「.NET Framework」を基本としCPUアーキテクチャに依存しないWindowsストアアプリに統合されることになります。

サーバに潜む罠

以上のように、各ユーザーが使用するクライアントマシンで動作するWindows環境については、同じ一つのアプリをどのCPUアーキテクチャのマシンでも動作させるための準備が整いつつあります。

しかし、サーバレベルで見ると、「.NET Framework」を含む「.NET」技術は一つ大きな問題を抱えていました。

それは、Javaのサーブレットなどと同じようにサーバ側で「.NET」技術に対応したアプリを利用するには、そのサーバのOSがMicrosoft Windows Serverでなければならなかったことです。

「.NET Framework」が元来Windows固有のアプリケーション開発・実行環境である以上、これはある意味当然の話だったのですが、LinuxやBSD系UNIX互換OS、あるいはMac OS XなどをOSとしてサーバが構築されていた場合、「.NET」のサーバ側各種サービスが組み込まれていなかった/組み込めなかったため、そのサーバ上で実行させることが出来なかったのです。

Javaだと主立ったサーバ向けOSでJava Platform, Enterprise Edition(Java EE)と呼ばれるJavaサーブレットなどの動的Webページ生成技術が利用可能で特にサーバを選ばず実行可能なのですが、「.NET」だとWindows Serverが稼働しているサーバでなければサーバ上でのASP.NETサービス(※注3)などが実行できず、自由度の点で大きな難がありました。

 ※注3:Active Server Pages .NET。Webアプリケーションフレームワーク。

「.NET」技術が実質的にWindowsに依存することは、Windowsが圧倒的なシェアを占めるデスクトップパソコンやノートパソコン向けなどでは特に問題になりませんでしたが、ここ10年でWindows Serverの市場シェアが大幅に増えたとは言え、まだまだLinuxをはじめとするUNIX互換OSをOSとして稼働するサーバが多数を占める状況(※注4)では、「Windows Serverでしか動作しない」という「.NET」対応サーバアプリケーションの制約は、そうしたソフトウェアやサービスの開発や普及・一般化を阻害する深刻な問題となっていました(※注5)。

 ※注4:特に近年は低消費電力サーバの流行で、消費電力面で有利なARM系プロセッサを搭載するサーバが増えており、当然ながらそうしたサーバでは現状で実質的にx86/x64版しか提供されていないWindows Serverは動作しないため、「.NET」技術をサーバ上で利用することも出来ない、ということになります。
 ※注5:そのため「XSP」と呼ばれる、ASP.NETおよびその周辺技術をLinuxやMac OS X上で動作させるためのサーバアプリがオープンソースで開発されていたほどです。このソフトは後述する「.NET」におけるサーバーサイドアプリケーションのオープンソース化の影響を最も顕著に受けることになります。

Microsoftは伝統的に、他のOSで実行可能なサービスを自社のOSで提供する事には熱心ですが、自社のOS上のサービスを他のOS上に移植・展開することには割と不熱心(※注6)な会社でしたから、こうした状況に陥ってしまったのもある意味仕方ないことです。

 ※注6:一方で、そうした一種の囲い込み政策が過去のWindowsの普及を支えてきたという面があります。

しかし、サーバ上で実行するアプリケーションで「.NET」技術を利用したいユーザーにとっては、これは「靴に足を合わせろ」式の強要にしか見えなかったのは確かです。

このあたりは、マイクロソフト社内の部門ごとの意見の相違も影響していたようで、例えばOfficeなどのアプリケーションソフトを開発している部門は、かなり初期からMacintosh向けのアプリ開発を行ってきた(※注7)こともあって自社製OS以外への製品展開を特に忌避していない(※注8)のですが、Windows ServerなどのサーバOSを開発している部門は総じて自分たちの担当するWindows Serverの売り上げ減につながる自社のOS独自サービスの社外OSへの展開に消極的で、規模の大きな会社故に意思決定に手間取っていたというところでしょうか。

 ※注7:そもそもその頃にはWindowsそのものが影も形もありませんでした。
 ※注8:それどころか最近では「Microsoft Offiece 365」でのAndroid・iOSへの対応版の提供など、OSの枠を越えた展開が目立ちます。

サーバサイド「.NET」技術の開放

「.NET」技術の内、サーバサイドアプリケーションのオープンソース化およびクロスプラットホーム化を告知するMicrosoftのプレスリリース。併せてこの技術の開発環境となるVisual Stuidioについても現行製品の個人利用無償化となる「Visual Studio Community 2013」の発表などがなされています。

もっとも、さすがに利用するにはWindows Serverが必須という状況が今後の「.NET」技術、中でもサーバサイドアプリケーション開発の普及に甚大な悪影響を及ぼすことはマイクロソフト上層部も理解していたようです。

2014年11月12日、マイクロソフトは「.NET Framework」などの「.NET」技術を構成する各製品の内、サーバサイドアプリケーション、つまりサーバ側で動作する製品についてオープンソース化とクロスプラットホーム化を発表しました。

具体的には「.NET server stack」(関連する「ASP.NET」・「.NET compiler」・「.NET Core Runtime」を含む)がオープンソース化され、開発者はWindowsやMac OS X、あるいはLinux上でビルド可能となるとのことです。

つまり、主立ったサーバOS上で後腐れなく「.NET」のサーバサイドアプリケーションを実行可能な形でビルドするために必要なソースコードが提供され、提供されていないOSについてもそれらのソースコードを用いて合法的に移植を行うことが可能になるわけです。

Microsoft側としてはサーバサイドアプリケーションクロスプラットホーム化することで「.NET」技術の利用可能なサーバの台数を大幅に増やせるだけでなく、オープンソース化することでボランティアのプログラマ達によってこれらのソースコードの改良が進むことやマイクロソフト自身が移植した以外のサーバOSへの移植が行われることを期待してこのような決断に踏み切ったものと思われます。

損して得取れ

これは言い換えればこれらのサーバサイドアプリケーションを自社で囲い込んでいても利益にならず、それらをオープンソース化とクロスプラットホーム化を実施することで広範に普及させ、ボランティアによって改良や異種OSへの移植が進む状況を創り出した方が今後の利益になる、とマイクロソフト上層部が判断したことを示しています。

最近のマイクロソフトはタブレットなど向けに「Windows 8.1 with Bing」という特定の条件を満たしたタブレットなどへプリインストールする場合のOSライセンス料が無料に設定された製品を提供しており、また次世代Windowsについてはアップグレード料金が非常に低廉となる見通しが報じられるなど、これまで同社の収益に大きく貢献してきたOSを会社の収益構造から切り離すような行動が目立っている=OSではなくアプリケーションやサービスで収益を得る体制への転換を図ろうとしている状況が鮮明になってきているのですが、今回のこの発表もそうした経営戦略の一環とみられます。

クライアント側「.NET」は手放さないマイクロソフト

実際、今回の発表内容はあくまでもサーバ側技術だけのオープンソース化およびクロスプラットホーム化であり、クライアント側の「.NET」関連技術やその製品については一切そうした対応が発表されていません。

つまり、マイクロソフトはこのWindowsストアアプリの根幹を支える技術であるクライアント側の「.NET」技術については「金になる」と考えていて、ソースコードを開示しないプロプライエタリなソフトとして自社でコントロールすることを望んでいるということです。

冷静に考えてみれば、クライアント側の「.NET」関連技術をオープンソース化してクロスプラットホーム化してしまうと、少なくともWindowsストアアプリについてはWindowsストアでの流通を前提としなければ全くWindowsをOSとする必要がなくなってしまうということで、極論すればAndroid端末やiOS端末上で野良Windowsストアアプリがそのまま動作するようになってしまう可能性、あるいは危険性がある(※注9)わけですから、OS開発や「.NET」技術そのものの開発についてマイクロソフトが全くコントロールできなくなる恐れがあります。

 ※注9:現在、「Unity」で用いられているフレームワークの「mono」は「.NET Framework」互換の環境を実現していて、これを利用することでiOS向けに(「.NET」の開発言語の一つである)C#などによるアプリケーション開発が行えるようになっていますが、これはApple側の審査の制約もあってiOSにインストールするランタイムにJITコンパイラを含む仮想マシンを搭載せず、アプリを「.NET」標準の中間言語コードの形ではなくiOSのネイティブコードとしてコンパイルするという回避策を講じています。つまり開発環境は流用でき。一部のランタイムも流用できるものの実際に得られるバイナリコードには互換性がないわけです。このため開発環境として「.NET Framework」の環境が利用されていても、そのアプリはWindowsストアアプリとしてそのまま提供することも出来ない構成となっています。

このあたりはGoogleがGoogle Playストアをプロプライエタリなアプリの下で機能するように構築しているのと恐らく同じ理由で、Googleもマイクロソフトも(そしてiTunesストアを擁するAppleも)、アプリのストア(およびその仕組み)こそが「事業収益を確保する上で決して手放してはいけない本丸」、最近割とはやった言い回しを使えば「核心的利益」だと認識しているわけです。

マイクロソフトのサービス事業者化が進む

最近の「Microsoft Office」製品の売り切り形のパッケージ版から期間ごとに使用料を支払うサブスクリプション版である「Microsoft Office 365」への移行が顕著に表すように、マイクロソフトはソフトウェア製品のライセンスを販売することよりも、ソフトウェア利用環境を含めた「サービス」を提供することに事業の軸足を急速に移しつつあります。

さすがに、家庭用ゲーム機であるXBOX Oneでのそうした方向性への急転換は勇み足が過ぎた感があった(※注10)のですが、パソコンなどの商用アプリケーションソフトは概ね収益構造のサブスクリプションモデルへの移行を指向するようになってきており、近年のマイクロソフトのこうした一連の動きはそれに追従しているだけだ、とみることもできるでしょう。

 ※注10:実際、中古製品の扱いなどを含めてそうした方向転換を製品発表時に公表したところ大ブーイングになり、同様に製品発表時に中古製品の扱いについてただ「従来通り」と発表したライバル機であるPlayStation 4が大喝采を受ける、という状況になって大慌てでXBOX Oneも方針転換を発表するという一幕がありました。

このあたりの話はアプリケーションや各種サービスのクラウド化が始まった頃から指摘され議論もされてきたことですが、現在の情勢を見る限りこの流れの向きは当分変わりそうにありません。

むしろ、先にも触れたようにマイクロソフトは会社規模が巨大故に意思決定でやや出遅れている面があって、今回の決定もようやく重い腰を上げたか、という印象があります。

もっとも、一度これと見定めて方向性を決めると、凄まじい勢いで開発に邁進して成功を収めてしまうのがマイクロソフトという会社の怖いところです。

今回の決定が例えば同じ「.NET」技術を使用している製品の中でも特に不振を極めているWindows Phoneの劣勢挽回にどの程度影響があるのかは定かではありませんが、少なくともWindows全体の将来に重要な意味を持つ布石であることは間違いありません。

今後もこうしたMicrosoftの「.NET」技術を巡る動きには特に注目が必要でしょう。

▼参考リンク
Microsoft takes .NET open source and cross-platform, adds new development capabilities with Visual Studio 2015, .NET 2015 and Visual Studio Online | News Center
ホーム – Microsoft .NET
The Microsoft Antitrust Case – NYU Stern School of Business

コメントは受け付けていません。

PageTopへ