長きにわたりマイクロソフト（株）の社長として日本国内へのWindowsの普及に尽力してきた古川享氏は、その後米国Microsoft社の副社長に就任し、21世紀のMicrosoft社を担うリーダーの１人として、国内外におけるMicrosoft.NET戦略の陣頭指揮をとっている。その古川氏に、.NETの現在と未来について語っていただいた。 ―― まず始めに、「.NET（ドット・ネット）」という名前の由来について教えてください。 「.NET」構想は、「NGWS（Next Generation Windows Service）」として一部マスコミに取りあげられていました。Microsoft.NETの構想が正式に発表されたのは、6月22日に開催されたForum 2000だったのですが、実はNGWSが最終的に「.NET」という名前に変更されたということは、この発表会当日の朝に知らされました。この決定を聞いて、私も自分のプレゼンテーション資料を大急ぎで書き直しました（笑）。 .NET構想の発表は、本当は6月1日に予定されていたのですが、運悪くこの日には、反トラスト法の裁判に関する発表が重なってしまったのです。これと同時発表してネガティブに受け取られてはいけないだろうという判断から、.NETの発表は6月22日まで延期されました。代わりに6月1日は、社内のキー・マネージャ200〜300人を集めて、NGWS発表の予行演習と社内評価を行ったのです。この段階では、まだ「NGWS」という呼び名が使われていました。 .NETの構想自体は、1年半以上も前から社内で検討を開始し、プログラミング・モデルやXMLデータの取り扱い、次世代のネットワーク分散環境、各種デバイス間の連携方法など、さまざまな点について議論を重ねてきました。名前はNGWSにほとんど決まりかけていたのですが、最後の最後になって、原点に立ち返る必要に迫られました。「自分たちがやりたいことは、『Windows』のさらなる拡販ではない。Windowsだけに閉じた世界ではなく、インターネット上に開かれた新しいプログラミング・モデルを再構築することだ。これまでにはなかったようなデバイス連携を実現することだ。はたしてこのようなビジョンに『Windows』という名前をつけるのはふさわしいだろうか？」という声が沸き起こったからです。 こうした伏線があって、私たちのメッセージが最も伝わりやすい名前として、発表当日ギリギリになって「.NET」という名前が採用されたわけです。急なことでしたが、個人的には、この名前はたいへん気に入っています。
―― .NETは、Windowsを始めとして、特定のデバイスやOSには依存しない情報環境を構築するための構想だと言われていますが、同じような提案は、すでにSunがJava構想として発表し、実用レベルで採用が進みつつあります。Sunは自社のネットワーク戦略として「.COM（ドット・コム）」を提唱していますが、.NETはこの.COMを意識したものなのでしょうか？ 私の知るかぎりにおいて、それはありません。私の理解では、Sunの.COM戦略は、電子商取引システムに注目したビジョンだと感じられます。これに対し.NETは、企業の電子商取引ばかりでなく、ビジネス利用から個人利用に至るまで、インターネットをベースとしたソフトウェアの連携を可能にしようという構想です。少なくとも.COMに関する現時点の説明を見ただけでは、注目している領域がまったく異なっていると思います。 ―― 「新しいビジョンはけっこうだが、これ以上マイクロソフトに囲い込まれるのは御免だ」という意見もあるようですが。 そのような誤解を与えているとすれば、それは私たちの説明不足だと思います。確かに.NETは、マイクロソフトが提唱したビジョンですが、.NETに準拠したインターネット上のサービスを実現するために必要なインターフェイスであるSOAP／XMLは、いずれも標準仕様であり、マイクロソフト独自のものではありません。したがって.NET環境で通信可能なデバイスや、.NET環境で連携し合うサービスは、SOAP／XMLなどの標準インターフェイスさえ満たしていれば、必ずしもマイクロソフト製OSを搭載したシステムである必要はありません。つまり、仕様に準拠するかぎり、OSはWindowsである必要はないし、ハードウェアもPCである必要がない。デバイスとサービスという視点でみれば、.NETは完全にオープンなものです。 とはいえもちろん、.NETの思想に合致した最良のOSや開発環境として、それぞれWindows.NET（開発コード名：Whistler）やVisual Studio.NETを提供していきますし、今後も同様に.NET環境でベストと呼ばれる製品を開発していきます。
―― 米Microsoft社は先ごろ、経営難に陥った加コーレルへの資金援助を行いました。一部では、Linux環境に向けた.NET戦略の布石ではないかと報じられていますが、その真意についてお聞かせください。 米国には、Microsoft社の最新動向をいち早く報じる「Microsoft Direction」というニュースレターがあります（Microsoft Directionのホームページ）。情報の早さでは定評のあるニュースレターで、ときに私でさえ驚かされるような記事が掲載されていることがあるほどです。このMicrosoft Directionの報道によれば、今回のCorelへの投資は、Linux上で動く.NETビルディング・ブロック開発を期待してのことだとありました。 マイクロソフト自身がLinux環境上にビルディング・ブロックを開発するということは考えにくいですが、このようにLinuxのノウハウを持っている優秀な外部プログラマの手によって、.NETに対応したビルディング・ブロックが開発される可能性は十分にあると思います。ひょっとしたら、すべてのコンポーネントがネットワーク対応になる未来のOffice.NETやVisual Studio.NETは、Linuxを含めさまざまなOS上で実行できるようになるかもしれません。アプリケーションがネットワーク上のサービスとなり、それらのサービスを特定のデバイスやOSに依存することなく利用できるということは、具体的に言えばそういうことでしょう。ビル・ゲイツに「それでもかまわないのか？」と問いただしたところ、「それこそが.NETだ」と彼は答えました。 ―― .NETはインターネットを介した分散コンピューティングを可能にするとのことですが、もう少し分かりやすく、具体例を挙げて説明していただけませんか？ .NETのごく一部の側面を示すものにすぎませんが、一例として、Office.NETが目指す将来のアプリケーション環境について説明しましょう。例えば現状のアプリケーション環境では、デスクトップPCにしろ、PDAにしろ、基本的にそれぞれのデバイスがアプリケーションを実装している必要があります。元となるデータはネットワークから取り出すかもしれませんが、必要な処理はあくまで独自に、デバイスに実装されたアプリケーションで実行しなければなりません。例えばあるスプレッドシート・データを再計算して、グラフを描くとして、元となるデータはほかから持ってきたとしても、現状では、各デバイスで再計算とグラフ描画を行わなければならないわけです。 これに対し.NET環境では、デバイス同士、ソフトウェア同士が能動的に連携できるようになりますから、すべての処理を自分で行わなくても、周囲にある計算機資源を必要に応じて活用できるようになります。たとえば前出のグラフを携帯電話機に表示させたいとして、再計算やグラフ描画は携帯電話で実行しなくても、周りにある処理性能の高いPCなどがこれに代わって処理を行えます。そしてグラフが作成できたら、その結果のイメージだけを携帯電話に転送してやればよいわけです。重要なことは、こうしたソフトウェア連携を、人間が介することなく、ソフトウェアの判断でも行えるようになるということです。実際、Officeの将来バージョンでは、このようなことを可能にしたいと考えています。次バージョンとして開発が進むOffice 10ではここまでできないかもしれませんが、さらなる将来のバージョンでは、これが可能になるでしょう。 ―― ネットワークを前提としたソフトウェア連携は興味深い技術ですが、これは逆にみれば、ネットワークがなければ何もできないということにはなりませんか？ よい質問ですね。.NETを始めとして、インターネットを土台とする新しいコンピューティングは各社から提案されていますが、ネットワークが切断された状態、つまり「オフライン」の状態について積極的に触れたものはあまりないように思います。この点、.NETは、ネットワークに接続されたオンラインの状態はもとより、オフラインの状態についても同じ重みで扱っており、オフラインの状態があるということを前提として設計がなされています。これは机上の空論だけでなく、すでにWindows 2000には、このための第一歩となるオフライン機能が組み込まれています。 ―― Microsoft.NETでのプログラム開発では、従来のWindowsプラットフォームから、インターネット・ワイドなプラットフォームへとフィールドが大きく広がります。ソフトウェアの可能性が広がる一方で、プログラマが念頭に置くべきことも桁違いに増えるのではないかと思われます。これからのWeb Service開発について、プログラマの意識や開発プロセスなど、従来のWindowsアプリケーション開発と異なるのはどのような点でしょうか？ まず.NET時代のプログラマにとって大切なのは、すべてを自分で抱え込むという今までの意識を取り払うことでしょう。 これまでの情報システム開発では、事実上、ほとんどの部分を独自に開発する必要がありましたし、そうして企業内で開発されたソフトウェアは、社内で運用されるだけでした。これに対し.NET環境では、外部の優れたビルディング・ブロックを組み合わせることによって、第3の情報システムを構築できるようになります。特に企業の情報システムでは、高い実績を持つ外部のビルディング・ブロックを利用することによって、信頼性の高い情報システムを設計できるようになります。 逆に、ある情報システムを開発したら、その中から汎用性の高い部分をビルディング・ブロックとして外部化することにより、第三者にサービスを提供できるようになります。つまり、インターネットを介したソフトウェアの再利用が可能になるわけです。どのように課金するかというしくみを確立する必要がありますが、こうした課金体制が確立されれば、ビルディング・ブロックを外部に提供して、その利用に応じて収益をあげることもできるようになるでしょう。汎用性が高く、多くの情報システムで必要とされるようなビルディング・ブロックをいち早く提供した人は、大きな先行者利益を得ることになると考えられます。
―― しかしそのためには、多くの情報システムが.NET環境に移行する必要があります。たとえそれが優れた環境だとしても、長い年月を経て成熟してきた企業の情報システムを、おいそれと移行させるのは難しいのではないでしょうか？ 確かに簡単なことではありません。しかしそうした大規模な既存の情報システムを支えているソフトウェア資産や、それらを開発したプログラマの経験やノウハウといったものを、新しい.NET環境でも活かしてもらえるためのしくみを用意しています。それは.NETの多言語サポートです。マイクロソフトが提供する.NET向けソフトウェア開発環境のVisual Studio.NETでは、従来からのC/C++、Visual Basic、JScriptに加え、.NETプログラム開発に特化させた新しい言語、C#を標準サポートします。さらに.NETの多言語対応は、サードベンダにも開かれており、すでに彼らの手によって、さまざまな言語処理系の.NET対応が進められています（詳細は別稿「特集：.NET Framework入門」を参照）。 例えば富士通さんは現在、.NET対応のCOBOLを開発中です。周知のとおり、COBOLは歴史のある言語処理系ですから、ソフトウェア資産は膨大です。また、COBOLの高いスキルを持ったプログラマの方々も多数いらっしゃいます。パソコン・ユーザーから見れば、COBOLは過去の言語に見えるかもしれませんが、情報システム分野では、今でも現役で活躍している言語処理系です。しかしインターネットをベースとする分散処理という将来のコンピューティングに対応できるかといえば、現実には不可能に近いでしょう。.NETは、こうした既存のソフトウェア資産や、これまでに身に付けてきたプログラマのノウハウやスキルを、新しい次世代の情報環境でも活かせる道を切り開くのです。 みなさんが手にする給与明細書は、ひょっとするとCOBOLで記述されたプログラムで作られているかもしれません。従来どおりに、紙の明細書をプリントアウトして、それを手渡しするのではなく、これをWebアプリケーション化して、ブラウザで明細を確認できるようにしたいとしましょう。このとき、古いけれども、実績に裏打ちされたCOBOLプログラム資産をどれだけ新しい環境に持ち越せるでしょうか。これまでは、一から設計し直しになっていたケースが少なくないと思います。これに対し.NETでは、しかるべき対応は必要になるとはいえ、COBOLで開発された既存の給与計算エンジンを新しいWebアプリケーションに持ち越せるようにします。
―― クライアント・サーバ・アプリケーション開発ツールとして、これまでVisual Basicが広く使われてきました。VBのよいところは、C/C＋＋言語やJavaのように、オブジェクト指向プログラミングの予備知識がなくても簡単にプログラムを作成できることだったと思います。この点Visual Studio.NETでは、VCとC#、VBが完全に統合され、VBプログラミングにおいてもオブジェクト指向の知識が必須となってしまいました。一部のVBプログラマは不安を感じているとも聞きますが。 確かに、これまでのVBに精通しているプログラマにとって、新しいVisual Basic.NET（以下VB.NET）はたいへん大きな変化となるでしょう。しかしインターネットを舞台とした分散オブジェクト環境を指向する.NETでは、オブジェクト指向プログラミングはもはや不可避の概念です。したがって.NET対応アプリケーションを開発しようというVBプログラマの方々には、VB.NETでのプログラミングを学習をしていただくか、思い切ってC#言語への移行を検討していただく必要があるでしょう。 ただしオブジェクト指向が前提になったからといって、プログラミング自体が絶対的に難しくなったかといえば、そうとも言えないと思います。例えばこれから新たにプログラミングを学ぼうという人にとっては、新しいVB.NETのほうが整理されており、学びやすいのではないかと思います。とはいえマイクロソフトとしては、これから.NETプログラミングを始めるという人には、C#を推奨していきます。VBは実績ある言語処理系ですが、言語仕様自体はマイクロソフト独自のもので、標準化などはされていません。これに対しC#の言語仕様はECMAに提案され、標準化を進めている最中です。インターネット対応アプリケーション開発という意味では、やはり標準化されたプログラミング言語を推奨していきたいと思っています。 ―― 現在、Windows MeおよびWindows 2000の後継として開発が進められているWindows Whistlerのベータ1が一部の開発者向けに公開されていますが、このベータ1には、まだ.NET対応プログラムを実行するためのランタイム（CLR（Common Language Runtime））などが組み込まれていないようです。.NETプログラムをサポートするソフトウェア環境のロードマップはどうなるのでしょうか？ これには4つの段階があります。まず第1段階は、VS.NETなどの開発環境を使って開発された.NET対応プログラムとともに、実行用ランタイムをバンドルしてユーザーに提供する段階です。第2段階はこれに近いのですが、ランタイムをネットワークからダウンロードすることが可能になります。MFC（Microsoft Foundation Class）のランタイムやVBランタイムと同じような扱いですね。開発者向けのベータ版レベルでは、すでにこの2つの方法によってランタイムが配布されています。エンドユーザーにも提供可能な製品版にバンドルできる時期としては、VS.NETや.NET Framework SDKの最終版が登場してくる2001年夏を予定しています。 第3段階は、ランタイムはまだOSに完全には統合されないが、OSとセットで提供される段階です。現在開発を進めているWindows Whistlerは、今のところ最終的な製品名がWindows.NET Ver.1.0となる公算が高いのですが、これが第3段階になります。.NET用のランタイムはOSとともに提供されますが、OSの内部に完全に統合されるわけではありません。 そして最後の第4段階では、ランタイムがOSに完全に統合されます。これは、Whistlerの次バージョンとして開発が進められているBlackcomb（ブラッコム、開発コード名）で実現されます。 もちろん、新たに登場するOSばかりでなく、既存のWindows OS向けのランタイムも提供していきます。現時点では、Windows
NT 4.0、Windows 2000、Windows Me、Windows 98の各OSに対して、.NET対応ランタイムを提供することが決定しています。Windows
95はまだ決定は出ていませんが、対応を検討中です。 古川 享 （ふるかわ すすむ）
|
|||||||||||||||||||||||
- 第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用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
 |
|
|
|
|
