マイクロソフト(株) : 奥津 和真氏
Windows 2000チーム徹底インタビュー (その6) Internet Explorerのゴールは表示された、すべてのものにアクセスできるようにすることです～Internet Explorer 5.5～
2000年12月13日 01時05分更新
また、HTMLのレンダリングエンジンとして考えた場合に、処理能力としての限界があるのではないかと思うのですが。コンポーネント間の連携にしても、データ処理やサーバ側へ送るといった処理を考えても、限界があるのではないかと考えていました。ですから、Outlook 2000などを使って「デジタルダッシュボード」といったコンセプトを打ち出した。同様の処理を、Internet Explorer上で実現することは可能にしてもです。もちろんこれは、今後Internet Explorerがなくなってしまうといった意味ではないのですが。
また、後半の質問にも誤解があると思います。Out look 2000の「デジタルダッシュボード」を考えた場合、同じ機能をInternet Explorerに実装すること自体は、我々からするとさほどたいへんな作業ではないのです。Internet Explorerしても、それがよいか悪いかという問題は別にして、たとえばActiveXコントロール、つまりCOMコンポーネントを使えば、要は何でもできるわけです。特にHTMLにこだわらなければ。だから、限界というわけではないのです。
しかし現実問題として、企業での利用を考えた場合に、Internet Explorer上で同じような機能を実現しようとすると、できるできないは別として、開発工数がかかるという問題が発生します。それに対してOutlook 2000には、予定表などといったさまざまな機能を、すでに持っています。同じ機能を用意するにしても、高いところから始められるということがポイントなわけです。こういった理由で、今の「デジタルダッシュボード」はOutlook 2000上で実現されているわけです。
Outlook 2000をベースとして利用するほうが現実的だという考え方です。
ある程度工数が増えるのを前提とするのであれば、Internet Explorer上でも、今の「デジタルダッシュボード」程度でしたら、別に問題なく作ることができるでしょう。ただし、開発の面からすると影響がある。ネイティブなプログラミング言語で開発するのと、Internet Explorer上で、あえてHTML／DHTMLだけで開発するのとでは、どうしても変わってきてしまう。そういった意味では、Internet Explorerにもまだまだ改善の余地が残されています。ですから、今回の「5.5」のような裏方の機能拡張が進んでいると考えていただいたほうがよいでしょう。
難しいのは、どういうシステム構成に対して、たとえばWindow DNA 2000にしても、どこまでXMLを使うかということです。マイクロソフトが提示するフレームワークでは、XMLを多用するといった理想的なものはあるにしても、現実を考えた場合、システムすべてが100％フレームワークの理想どおりにはい かないのは周知の事実です。いろいろなケースに対 応して、あらゆる選択肢が取れるように、すべての環境をそろえていこうというのがマイクロソフトの基本的な姿勢です。ですから先ほどの例のように、Internet Explorer上で、ActiveXコントロールを使ってUIを作るシステムも考えられまし、従来どおりのWin32のクライアントを使う場合もある。また、Win32のクライアントを使った場合でも、サーバとはHTTPでやり取りする、さらに外部とはインターネットを利用して、複数のサイトと同時にやり取りする場合も考えられます。社内では、従来のようなバイナリプロトコルを使う場合も考えられる。パフォーマンスは、HTTPでXMLのテキストベースで行なった場合には、どうしても悪くなるけれど、悪くなるのが問題かというと、それは使うシステムの性質によって、問題になるレベルの話か、そうでないのかは大きく違ってきます。
たとえば、よく持ち出される議論ですが、XMLに変えたら、今まで0.1秒で済んでいたものが、0.2秒あるいは0.5秒に遅くなったという例が挙げられます。数値だけ見るとパフォーマンスが悪くなったのは確かです。しかし、これをどこに適用するかが問題なわけです。たとえば、ある部分では10秒かかったとしても、別に問題にはならないシステムというのもある。そうであれば、XMLのメリットの方が大きいと判断した場合には、XMLを使えばいい。そうでなければ今までのようにバイナリプロトコルを使えばいい。しかし、さまざまな選択肢を用意し、どれでも取れるようにしていこうと考えると、必然的に個々の持つ機能が多くなってきます。 「Internet Explorer 5.5」を例にすると、これだけの機能が搭載されていて、一見するとHTMLを表示するだけのように思える。しかし、当然のことながらXMLパーサーも使えるし、ほかのプログラムにしても、ウィンドウの中で表示する場合、Internet ExplorerのHTMLレンダリングエンジンを再利用している場合が多い。先ほど「デジタルダッシュボード」という例がありましたが、実際はOutlook 2000での表示は、Outlook 2000という枠の中で動いてますが、Internet Explorerのコンポーネントを使って行なっているわけです。ですから、たとえばOutlook 2000を使っていても、Internet Explorerを「5.01」から「5.5」にバージョンアップした時点で、内部で動いているエンジンは「5.5」のエンジンに変更される。すると個々の表現力というのは、やはり増していく。XMLパーサーにしても同じように強化されていく。こういったコンポーネントを置き換えて機能をアップすることができるのは、やはりすべてが「COM」から来ている利点であると言えるでしょう。「COM」をベースにして、どんな既存のシステムとでも連携できるシステムが迅速に構築できるというのが、マイクロソフトの理想とするところです。あらゆるケースにマッチするものを用意しておかないと、要求に合わせることができずに、現実的には採用していただけませんから、非常に柔軟性を持ったフレームワークを用意しているわけです。
古いシステムを、現在でもそのまま使い続けているお客様がいらっしゃる場合もあります。しかし、今のテクノロジーやインフラの流れからすると、必然的に外の会社とのやり取りが発生してくる。たとえば、社内の部門内や部門間のやり取りに支障はないにしても、そこの会社のサーバから外の会社との接続は、やはりXMLベースの、たとえばBizTalkのスキーマに沿ったものに変わっていくと思います。そうなった場合、わざわざ変換をかけて従来のシステムを使い続けているほうが効率が悪くなる場合もあるわけです。当然システムにしても、バイナリのプロトコルに対応したものは独自性が強くなります。XMLで作れば、パーサーは共通のものが使えますから、そこから先を考えればいいことになる。何よりも、バイナリのプロトコルというのは、まず繋ぐだけでコストがかかる。たとえば、繋ぐためだけのミドルウェアが、何百万円したりするわけですから。企業のシステムを構築する上で、ここを簡単に繋ぐことができれば、ほかの部分にお金がかけられるわけです。また、バイナリプロトコルの場合には、システムの変更が柔軟に行なえない上に、変更に時間とお金がかかります。こういったことからも考えられるように、やはり、XMLの流れというのはあると思います。
なぜオープンな場所に漕ぎ出すことを意味するかと言うと、サーバに「Windows NT Server」を使いXMLベースで構築していたシステムが、仮に、ほかのプラットフォーム、たとえば、UNIXやメインフレームに変えるといった場合、現在のシステムと比べると自由に変更可能なわけです。現在のように、たとえばバイナリプロトコルを使って、それに対応するソフトウェアやミドルウェアがないと連携が難しいといったことはなくなるわけです。
最近よく海外のニュースソースで、「Microsoftは、今までのような囲い込みの戦略から脱して、XMLを推していくというのは、結果的にシステム間の結合を弱めるのではないか。果たしてMicrosoftは、これからどのような計画を推し進めていくのだろうか」と言われています。もちろん、データベースがメインフレームであっても、繋ぐ手段を用意して、すべてが繋がるようにします。ただし、願わくばWindowsプラットフォームで統一することによって、より開発が楽になり、より管理が便利になるという部分を訴求していくのが、これからのマイクロソフトの路線とも言えます。かつ同じプラットフォームであるから、個々のプラットフォームについて詳しい人間を専属で用意する必要がない。Windowsに詳しい人間を配置すればいいわけです。我々の戦略も、こういった形に変わってきているわけです。
もう1つは、構造化されたデータを扱えるということです。しかし、これには問題点もあります。これをリレーショナルデータベースのデータに割り当てるのは、マッピングが非常に面倒で難しい場合がある。ですから、既存のリレーショナルデータベースを使うと実装に手間がかかってしまう。つまり実装に手間がかかるということは、それだけ品質が悪くなる可能性の高くなることを意味します。この対応策としては、マイクロソフトはSQL Serverの次期バージョン「Shiloh」で、XMLの機能を大幅に強化します。機能強化のためには、当然XMLパーサーの機能も強化／追加しなければならない。ですから、SQL ServerのチームとXMLパーサーのチームは一緒に仕事をしているわけです。将来も、XMLパーサーのチームとSQL Serverのチームが一緒に開発を進めていくのかというと、ほかのサーバ製品の開発チームと一緒に行なうかもしれません。XMLパーサーがデータアクセスの部分で、非常に重要なテクノロジーを持っているのは確かですから。
我々が、Internet Explorerに載せているDHTML／HTMLのレンダリングエンジンの最終的な目標は、「すべてのものにアクセスできるようにする」ということなんです。「ブラウザで表示されている要素に対して、スクリプトでアクセスできる、すべての要素を編集可能にする」というのがゴールなのです。確かにまだ機能的に不足している部分というのはあります。特に日本のお客様はシステムを発注する際に、UIの細部にこだわる傾向が強い。そういった意味で無理があるのは確かですが、HTMLベースのUIを作るのに開発者が慣れてない部分もある。要するに、今までと同じ方法では作れないわけですから。たとえばVisualBasicのフォームと較べても、確かに不便なカ所はたくさんありますが、我々は基本的に同じになるように、その差を解消していくように努力していきます。
「分業」という考え方は、米国の方が進んでいますから、機能に対する要望が日本とは多少違うのは確かです。結果的には、分業を進めるという意味も含まれてはいるのですが、それよりもコンポーネントを完全に分離することが、プログラミングモデルを考えた場合、非常に大切なことなのです。一般の開発言語では、分離できて当たり前のことであるにもかかわらず、今までできていなかったということです。ですから基本的にはチューンナップではあるけれども、足りない部分から少しずつ直していこうというわけです。
しかし、互換性を失うというのは非常にまずい話ですから、それを保ちながら行なっている。昔の互換性というのは、ある意味で大きな壁にぶつかった時には、切り捨てざるを得ないこともありますが、それでも確保していこうと努力している。たとえば実際には、今あるHTML 4.0の仕様と以前の仕様も入っている。今までの流れがすべて積み重なっていますから、それを一気に変えるというのは、これから先は難しいだろうなというのが私の感想です。エンジン自体は、しばらくはこの調子で進むでしょう。インターフェイスが変更されれば、エンドユーザーにとっては、インパクトは大きいのでしょうが、開発の上では、必ずしも最優先されるほど重要な要素というわけではないんですよ。
「デジタルダッシュボード」
Internet Explorerはコンテナというイメージがあったが、当然コンテナとして吸収できる情報に制限がある。IIS上にあるWebコンテンツに限られてしまうという傾向にある。しかし、「デジタルダッシュボード」では、Outlookをフロントエンドとして、そこに「ナゲット」という形でさまざまなコンポーネントを貼り付けることが可能となる。「ナゲット」自体は、Webコンテンツだけではなく、サーバ側にあるさまざまなデータでも構わない。たとえば、Exchangeのメッセージでも構わないし、SQLの中に入っているキューブを取り出してきて、それをピボットテーブルという形で表示させることができる。サーバ側に、ExchangeやSQLといった、Officeとのかなり強い連携を持った環境がある場合には、非常に使いやすいだろう。こういった意味では、Internet ExpplorerよりもOutlookの方が充実してくると考えられる。OutlookでもVBAが採用された理由の1つにもなっている。外部アプリケーションと連携させたい場合などを考えても、今までのようにVBSよりもVBAを使ったほうがより効率的であると考えられたからである。
