例年秋になると，私は「開発ツール」モードに入る。日経バイトでここ数年，開発ツール増刊号を発行しているからだ。

　その絡みもあって先日，米Microsoftの次世代開発ツール「Visual Studio.NET」を取材した。Visual Studio.NETの中核となるアイデアは，異なる言語で共通して利用するクラス・ライブラリ「.NET Framework」と，中間言語方式による実行形態にあると思った。これらによって，Visual C++や新言語のC#，Visual Basicがほぼ同じ機能を備え，C++で作成したクラスをVisual Basicを使って定義し直すことなどができるようになったからだ。

　この話を聞いていて，Javaを思い出した。Javaが発表になったときに感じたのは，アプリケーション・プログラムの実行環境が論理レベルの高いレイヤに移行していくということだ。

　もともとコンピュータは，BIOSのような低レベルのサービス・プログラムを通じて現実世界とデータをやり取りしていた。それがMS-DOSやCP/Mのような単純なOSが普及したおかげで，GUIやテキスト描画エリアを直接操作するようなプログラムでなければ，違うアーキテクチャのマシンでも共通して動作するプログラムを開発できるようになった。

　しかし，パソコンのプログラムは基本的にユーザ・インタフェースを備えている。このレイヤについても仮想化したのが，Windowsである。Windows対応アプリケーション・ソフトであれば，PC-9801でもIBM PC互換機でも同じアプリケーションがほとんど動くようになった。

　次の仮想化のステップがJavaである。Windowsのような「OS」で対処できるのは，CPUアーキテクチャが同一のものだけだった。Javaはその1段上のレイヤにおける仮想化を目指した。CPUアーキテクチャの違いを仮想化して，まさに「仮想マシン」という形で実装した。「Write Once，Run Anywhere」コンセプトである。このコンセプトは必ずしも成功をもたらしたとは言い難い面はあるものの，仮想マシンというアイデア自体は有効なものだし，CPUの処理性能が向上していけば問題も自然消滅するはずなのである。

開発効率は確かに上がるだろうが・・・

　ではなぜ，Microsoft社がこのような仮想化を必要としたのか。同社からすれば，ターゲットは基本的にWindowsであればよいはず。Javaのような意味で仮想化する必要はない。事実，同社のC/C++プロダクト・マネジャも「Write Once，Run Anywhereのアイデアは，現実を無視した考えだ」と述べている。

　Microsoft社が求めるのは生産性である。完全なバイナリ・コードでは，メモリ管理が難しい。自動ガーベジ・コレクションを実現するためには，メモリの状態をモニタしておく必要がある。そのオーバヘッドを考えれば，「多少解釈に時間がかかったとしても，生産性の向上によるメリットが上回る」と同社は踏んだわけだ。さらに，すべてのプログラミング言語で記述したプログラムを同一のフレームワークで実行させるのに適した，仮想コード体系を作れば，プログラマが適切なプログラミング言語を選べるようになる。これも生産性に寄与するはずだ。

　ペナルティはもちろん性能だ。これはまさに，「速いパソコンを遅くして使う」方法なのである。プログラマの生産性と，ユーザの利便性のトレードオフということになるのだろうか。実は，ここが気になるところだ。

　開発する立場からすれば，効率よく開発できることは非常にうれしい。しかし，そのプログラムを使うユーザにとっては，性能の出ないプログラムなど受け入れられないのではないか。まさにここが，Javaがクライアントで失敗した理由ではないか，という気がしてならない。

　現在手に入るPDC Tech Previewは性能に関してチューニングしていないので，恐らくネイティブ・コードの半分以下の性能しか出ていないだろう。問題はプロダクション・レベルでどこまで性能が出るかだ。

　Microsoft社の日本法人マイクロソフトは，「80％程度の性能は十分に出る」と言っているが，さて。Javaの性能もそれくらい出る，と言われていたような気がするが・・・。