Visual Studio .NETベータ2日本語版が公開され、いよいよMicrosoft .NETに向けたプログラマの動きも本格化しそうだ。今回は、Microsoftが1997年に.NETの開発プロジェクトを発足して以来、当初から開発の第一線に身を置いてきたというDavid Treadwell氏に、.NETの過去・現在・未来について語っていただいた。（聞き手：Insider.NET編集長 遠藤孝信） ―― まず始めに、あなたのこれまでの経歴や現在の立場、課題と目標などについてお話しください。 私は1989年に米Microsoftに入社し、Windows NTグループの開発者の一員となりました。当時Windows NTの開発はまだ始まったばかりで、グループのメンバは13人程度だったと記憶しています。ご存じのとおり、Windows NTはWindows 2000へと進化し、現在の開発チームは5000人を超える規模になっています。 Windows NT開発グループの中で、最初の3年間はファイル・サーバ関連の開発に従事し、その後はWindows Socketインターフェイスの設計と、Windows SocketのWindows NTへの実装を担当し、IIS（Internet Information Server）の開発チームを経て、1997年から.NET Frameworkの開発チームに参加しました。 現在の私のミッションは、.NET Frameworkにおいて開発者の方々がさまざまなレベルで直面する問題を解決し、.NET Frameworkを普及させることです。 ―― Microsoftは、SOAP／XMLをベースとするXML Webサービスを核とした新しい情報環境に大きく舵取りされるわけですが、この背景には何があったのでしょうか？ 最大の理由は、IT業界において、ハイレベルな相互運用性を備えたプログラマブルなWebが求められていたということです。分散型コンピューティングの重要性自体は、ずいぶん以前から議論されており、Microsoftも含めてさまざまな人々が実装を進めました。しかしRPC（Remote Procedure Call）にしろ、DCOM（Distributed Component Object Model）にしろ、CORBAにしろ、異なるプラットフォーム間での分散処理はなかなかうまく機能しませんでした。
そこで着目したのがXMLです。ご承知のとおりXMLは、自己拡張可能なマークアップ言語であり、文書構造を作り手が自由に決定できるという高い柔軟性を備えています。その仕様はW3Cによって決定され、完全にオープンです。このオープンな仕様を応用して、分散型コンピューティングを推進すれば、異機種間接続という従来の問題をクリアしながら、柔軟性の高い、インターネット上のプログラミングにより適したものになるだろうと考えました。 この発想を土台として考案された分散型コンピューティング仕様がXML Webサービスであり、それをプラットフォームに実装したソフトウェア環境が.NET Frameworkなのです。 少し前から、インターネットやWebの技術を応用したWebソリューションが注目を浴びてきました。これは、サーバ側で基本的にすべての処理を行い、クラアイント側はWebブラウザさえあれば利用できるという情報システムです。つまりこのシステムでは、Webブラウジングのインターフェイス、すなわちHTTP／HTMLがオープン・スタンダードとして機能しています。こうしたWebソリューションが隆盛を極めたということからも明らかですし、私たちの市場調査でも明確になったのですが、顧客にとってオープン・スタンダードであることは極めて重要なポイントとなっています。 しかし現行のWebソリューションの問題点は、サーバ側にばかり大きな負荷がかかることです。ご承知のとおり、サーバばかりでなく、クライアントPCの性能も急ピッチで向上しています。残念ながら現行のWebソリューションでは、こうしたクライアント側のパワーを活かすことができません。この点XML Webサービスを利用すると、サーバ側で多くの処理を行う現行のWebソリューションを構築することはもちろん、必要に応じてクライアント側の処理能力を活用できるようになります。これにより、さらに柔軟なシステム開発が可能になるでしょう。 ―― 今お話しされている現行のWebソリューションとは、サーバサイドJavaを指しているものと思います。将来はともかく、少なくとも現在は、サーバサイドJavaは大きな脅威であるということですね？ 確かに、Javaは非常に成功した環境だということは認めなければなりません。残念ながら、これまでのMicrosoftには、サーバ側のソリューションとして、現行のJavaに匹敵するような回答は用意できていませんでした。これに対し私たちが導き出した答えが、XML Webサービスであり、.NET Frameworkなのです。 ―― サーバサイドJavaは、すでに多くのシステムで採用され、実績という点では一歩も二歩もリードしています。またJavaの開発元であるSunも、Webサービスのサポートを表明しています。これに対し、後発の.NETはどうやって対抗するのでしょうか？ 優位性はどこにあるのでしょうか？ 最大の優位性は、洗練された開発環境が提供される点でしょう。.NETの開発環境であるVisual Studio .NETを使えば、XML Webサービス自体にせよ、それを使うアプリケーションにせよ、XML Webサービス関連のソフトウェアを極めて簡単に開発できます。これは、開発ツールと.NET Frameworkとを高度に統合することで可能になりました。例えばXML Webサービスを公開したければ、ソースコードの当該部分を［WebMethod］というキーワードで囲むだけです。
私たちが調査したところ、日本でも米国でも、Javaの開発環境としてはJDKが主流であることが分かりました。互いに独立性の高いテキスト・エディタやコンパイラ、デバッガなどを、プログラマが組み合わせて使うという、伝統的なプログラミング・スタイルが今も主流だということです。IBMのVisual Ageなどの統合開発環境も利用可能ですが、JDKほどポピュラーな存在と呼べるものはないようです。 これに対し、.NETには、VS .NETという優れた開発環境があります。後発ではありますが、この点では十分な優位性があると確信しています。 ―― .NET Frameworkの開発体制について教えてください。 アーキテクトやプログラマ、テスターなど、.NET Framework開発のコア・チームは500人程度でしょうか。これ以外にも、.NET Frameworkの基礎となるパーツを提供するチームや、.NET Frameworkを開発するためのツールを開発するチームもありました。こうした人たちも含め、Microsoftの中で、何らかの形で.NET Framework開発に携わった人を数えれば数千人規模にのぼるでしょう。Microsoftには大規模なプロジェクトが多数ありますが、その中でも飛び抜けて規模の大きなプロジェクトだと言えます。コード・サイズを正確に数えたことはありませんが、全体では数百万行単位のコードになると思います。 ―― .NET Frameworkの開発言語は何でしょうか？ C#は使われているのでしょうか？ CLRなど、大部分はC言語またはC++言語で記述されています。そして.NET Frameworkにおける高レベルの部分は、C#言語を使ってコーディングされています。 ―― .NET Frameworkのベータ1からベータ2へのバージョンアップでは、クラスライブラリが大幅に変更され、ベータ1をベースとして作成したプログラムがそのままでは動きませんでした。今回のTech・Edでは、.NET Frameworkベータ2日本語版が参加者に広く配布され、いよいよ本格的な.NETプログラミングを志すプログラマも多いと思います。この際プログラマにとっては、ベータ2から最終版に向けて、さらに大幅な変更がなされるかが気がかりなところです。Microsoftの中では、いまなお最終版に向けた開発作業が進んでいると思いますが、この点はいかがでしょうか？ 当たり前のことですが、最終版をリリースしたら、それ以降は大幅な変更はできませんし、するべきではありません。ですからベータ期間中に可能なかぎり精度を向上させる必要があります。ご指摘のとおり、ベータ1からベータ2では、大幅な変更を行いました。ベータ2から、現在開発中の最終版にかけてもいくつか修正が加えられます。ただし、それはベータ1からベータ2のときのような大規模なものではありませんし、修正点もわずかなものですむ予定です。結論から言って、ベータ2をベースとして作成されたプログラムのほとんどはそのまま最終版でも動作するか、修正が必要だとしてもわずかだと思います。
―― 日本では、Visual Studio .NETの最終版の出荷予定が、当初は年内だったものが、2002年第一四半期に延期されました。米国ではどうなるのでしょうか？ 米国では、.NET FrameworkおよびVisual Studio .NETとも、予定どおり年内に出荷する方向で作業を進めています。 ―― Windows XPの発売が米国では10月より、日本国内でも11月より開始される予定です。しかしこのWindows XPには、.NET Frameworkは標準では組み込まれていません。これに対し、2002年に出荷が予定されているサーバ向けのWindows .NET Serverでは、当初から.NET Frameworkが組み込まれるとのことです。Blackcomb（ブラッコム：開発コード名）などの将来のOSと、.NET Frameworkのリリース・スケジュールについて、もう一度整理してもらえますでしょうか？ ご質問のとおり、この秋に出荷されるWindows XPには、.NET Frameworkは標準実装されません。ただしこれは単に、Windows XPの方が.NET Frameworkよりも早く完成したというだけのことです。Windows XPに.NET Frameworkを組み込めば、まったく問題なく機能します。またWindows .NET Server製品については、標準で.NET Frameworkが実装されます。 将来のクライアントOSでは、.NET FrameworkをOSのアドオンとして組み込むのではなく、.NET FrameworkがOSレベルで完全に統合されます。Windows XP以降に発表されるWindows OSに関しては、すべて.NET Frameworkが標準で実装されると考えていただいて結構です。 ―― キーノート・スピーチのプレゼンテーションでは、携帯電話やPDAなど、PCだけでなく、さまざまな環境からXML Webサービスを使用可能にするとの説明がありました。この中で、Mobile Internet Toolkitであるとか、.NET Compact Frameworkという名前が出てきました。特に前者のMobile Internet Toolkitについては、9月14日に日本語版の提供開始が予定されています。.NETの非デバイス依存性と、これらソフトウェア・サポートの関係について教えてください。 まずMobile Internet Toolkitは、ASP .NETを使用して、携帯電話などからアクセス可能なWebソリューション開発をサポートするためのツールキットです。発表したキットのベータ版では、日本の携帯電話で広く普及しているNTTドコモのiモードに対応しています。またJPhoneのJ-Sky、KDDI・au・ツーカー・グループのEZwebへの対応は製品版で行います。この分野では、日本は重要な市場だと認識しており、いち早く対応を決定しました。 一方の.NET Compact Frameworkは、PC以外の小型デバイス、具体的にはPDAや携帯電話上で動作する.NET Framework対応アプリケーションを開発可能にするものです。まだお話しできる段階ではありませんが、主要なPDAベンダ、携帯電話ベンダと共同開発中です。 ―― XML Webサービスは、W3Cで標準化が進められているオープンなテクノロジで、Microsoftを始め、IBMやSun、Borland、Oracleなど、各社がそれぞれサポートを表明しています。現時点でも、BorlandのDelphiやApache、SOAP::Liteなどの開発環境を利用してXML Webサービスを開発可能です。すでに米国では、こういった環境を使用して開発されたXML Webサービスが公開されつつあります。しかし残念ながら、異なる開発環境を使って開発されたXML Webサービス・プログラム（サーバ側、クライアント側）相互の互換性はあまり高くないようです。例えば試しにVisual Studio .NETから、Delphiで開発されたWebサービスを組み込み、呼び出そうとしましたがうまく参照できませんでした。Webサービスが語られるとき、必ず「特定のプラットフォームに依存しないソフトウェア・ソリューション」という点が強調されますが、現実にはまったくの夢物語になっていませんか？ まず最初に、Microsoftばかりでなく、さまざまなベンダがXML Webサービスをサポートするのはたいへん喜ばしいことです。複数のベンダが、互いに優れた環境を提供しようと努力すれば、Webサービス環境全体のレベルが向上し、普及に拍車がかかるようになるでしょう。 しかしXML Webサービスに限らず、複数のベンダ間で、新しい標準の相互運用性を達成するのは簡単なことではありません。例えば、TCP/IPが普及した過程を思い出してください。コンピュータ・ネットワークを支えるプロトコルとして、不動の地位を獲得したTCP/IPですが、黎明期の1990年代始めは、異なるベンダの製品間で正しく通信できないなどの問題が多発していました。すでに述べたとおり、この当時私は、TCP/IPプロトコル・スタックの開発を担当しており、TCP/IPの相互運用性に関する最前線にいました。 TCP/IPが時間をかけて互換性問題を克服し、現在の地位を獲得したように、XML Webサービスも、多少の時間はかかるかもしれませんが、必ず標準テクノロジとして普及するものと確信しています。 ―― '90年代始めから現在ということは、TCP/IPの標準化には10年の歳月がかかったことになりますが、XML Webサービスの本格的な相互運用性の実現についても、それと同じくらいの時間がかかるということでしょうか？ よい質問ですね（笑）。TCP/IPの場合、厳密には、'94〜'95年ころには互換性問題はほとんど解決されていましたから、10年はかかっていないと思います。 XML Webサービスの開発と実装では、相互運用性を非常に重視して作業を進めています。TCP/IPのときもそうだったのですが、XML Webサービスの相互運用性に関するイベントなどを各社で共同開催し、相互接続実験やプロトコルの標準化に関するディスカッションなどを積極的に行っています。誰もが当たり前として使える「標準」をうち立てるのは簡単なことではありませんが、こうした努力により、向こう1年程度でXML Webサービスの相互運用性は大きく前進すると考えています。
―― 先ごろ、IISのセキュリティ・ホールを突いて感染を広げるコンピュータ・ワーム、CodeRedが大きな問題となりました。このCodeRedを始め、現在のインターネットでは、システムのセキュリティ・ホールを狙い、攻撃をしかけるクラッキングが社会問題化しています。これを受けて一部には、セキュリティ・ホールを作りやすい、ネットの高機能化に異を唱える声もあるようです。XML Webサービスという次世代ネットのテクノロジを開発している立場として、これについてはどのように考えますか？ セキュリティについて、どのように取り組んでいるでしょうか？ CodeRedでは、IIS関連のモジュールにあったバッファ・オーバーフローという単純なバグが攻撃されました。またCodeRed以外で影響が大きかったウイルスやワーム、クラッキング手法を見ても、たいていはシステムの根本的なセキュリティ・メカニズムに起因する問題点ではなく、本来設計どおりなら、システムは高いセキュリティ性能を持つはずなのに、単純なバグが潜んでいたため、それが突破口にされてしまったというケースがほとんどのようです。
つまりこうした問題を回避するには、まずは単純なバグをプログラマが不用意に作り込んでしまわないようなプログラミング・スタイルの変更が必要です。この点.NET Frameworkでは、高度なメモリ管理機能などが上位プログラム向けに用意されており、プログラマは低レベルなシステム操作を行わなくてもよいようになっています。これら.NET Frameworkのサービスを使ってプログラムを開発すれば、例えばCode Redが標的にしたような単純なバグは防止できるはずです。 もちろん、.NET Frameworkにしても、CLRにしても、セキュリティは最重要課題の1つとして開発を進めました。悪意を持つクラッカーなどによる攻撃の危険を常に考えながら、設計段階からそれに対抗するためのメカニズムを組み込んでいます。
デビッド・トレッドウェル（David Treadwell）
|
|||||||||||||||||||||
- 第2回 簡潔なコーディングのために （2017/7/26）
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21）
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために （2017/7/19）
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator （2017/7/18）
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
