マイクロソフト プロダクト ディベロップメント リミテッドは，日本におけるマイクロソフトの開発部門にあたる会社である。同社のウィンドウズ開発統括部長である加治佐氏は，Windows開発の責任者，いわば日本で最もWindowsの中身を知る人物と言える。同氏にWindows Server 2003では，どのような「作り直し」が行われたのかを聞いた。
━━Windows Server 2003は，ちょっと見た目には分かりませんが，全面的な改良が施されていると思います。改良に関して，開発側で重視したところはありますか。 ［加治佐俊一氏］ Windows Server 2003の開発では，Windows 2000の時に重視した「機能を包括した形での開発」に加えて，ユーザーからのフィードバックを重視しました。 Windows 2000ではActive Directory，PKI（Public Key Infrastructure：公開鍵基盤）のサポート，クラスタリングの大幅な改良，マルチユーザーをサポートしたターミナル・サービス，といった大幅な拡張，新機能がありました。これらはただ追加すればよいというわけではなく，既存の機能にもかかわっています。既存の機能を含めてシームレスに，間違いがないように開発を進める必要がありました。 例えば，プリンタの場合，それまではスプーラのプリント・ジョブをスムーズに流して，早く印刷することだけを考えていればよかった。それがクラスタリングが入ることで，フェイル・オーバーしなければならない。あるいはディレクトリをみた場合，プリンタがどこにあるかロケートできなければならない。いろんなことが関わってきたため，包括的な形での開発になったわけです。 これに加えて，Windows Server 2003では，ユーザーからのフィードバックを重視しています。従来からのフィードバックのシステムであるテクニカル・ベータと早期導入プログラムであるJDP（Joint Development Program）を実施し，フィードバックはきちんと取り入れました。日本ではジェイアール東日本情報システムとJDPを行いました。実際に彼らと検証し，間違いのないものに仕上げられたことが，大きな成果となっています。 また，フィードバックを積極的に取り入れるという点では，Windows XPで搭載されたWindows Error Reportingが成果を出しています。XPはデスクトップOSですが，Windows Server 2003は同じカーネルを使っているため，XPで起こる問題は2003でも起こり得ます。 クライアントからフィードバックがあった場合，それを整理して理解し，開発者に伝えて直してもらう，あるいは開発のヒントにしてもらうことが大切です。Windows Error Reportingは，エラーが起きるとその情報をマイクロソフトのデータ・センターに送ります。カーネルがクラッシュした場合には，ダンプ・ファイルも一緒に送ります。データ・センターではそうしたエラー・リポートを自動解析し，問題を起こしたコンポーネントを担当していた開発者に伝えます。もちろん当社だけですべての問題を解決できるわけではありません。サード・パーティが開発した部分で問題が起きた場合には，パートナに何が起こっているのか，どれくらいの頻度で起こっているかをきちんと伝えます。パートナでもエラー・リポートを開発に反映していきます。 また，パッチやホットフィックスがユーザーに届かなければ意味がありません。そのためWindows Update，Auto Update，企業を対象としたものとしてはSUS（Software Update Service）やSMS（Systems Management Server）など，できるだけ自動的に配布できる仕組みができました。 クライアントからのリポートを開発者に伝え，修正，改良する。できたものは自動的に配布する。開発者を含めたこうした仕組みができあがったことは大きいと思います。 今回の場合はWindows XPからのフィードバックがWindows Server 2003に反映されたわけです。同じソース・ツリーの中で開発を続けるため，逆に今後サーバーからのフィードバックがクライアントOSに反映されることもあります。さらにはEmbedded，Windows CE，Pocket PCからスマートフォンにまで，フィードバックを相互に反映できる仕組みになっています。
━━ユーザーからはパフォーマンスが高くなったという評価を受けています。どのような作り直しが行われたのでしょうか。 ［加治佐］ カーネルの変更，チューニングという点ではWindows XPを開発した際，Windows 2000からかなりの変更が行われ，パフォーマンスが高くなりました。Windows Server 2003はこれを引き継いでいます。 XPが出てから1年半の間，サーバーとしてのパフォーマンス・テストを行い，カーネルだけでなくIIS（Internet Information Services） 6.0などシステム全体のチューニングを行ってきました。そうした結果として今回のパフォーマンス・アップが実現したわけです。 チューニングの具体的な内容として，リライアビリティを高めるためにプロセスを分けました。ただそれだけだとパフォーマンスを高めるには限界があります。互換性を維持した上でパフォーマンスを上げるため，できるだけ共通に動く部分に関してはユーザー・モードからカーネル・モードへ移しました。以前NTの際，ユーザーGDI（Graphics Device Interface）というモジュールがカーネル・モードにきましたが，それと似たようなアプローチです。カーネル・モードに移すということは，何か起こったらシステム・クラッシュにつながる可能性があるわけですから，バッファ・オーバーランなどをきちんと調べたうえで作ったわけです。 ━━IISもかなりパフォーマンスが高くなっています。作り直しを行ったのですか。 ［加治佐］ IIS 6.0は開発初期には，全面的に書き換えるという意気込みで当たりました。もちろん，すべて書き換えることはできなかったのですが，パフォーマンス，信頼性，スケーラビリティなどがバランスよく向上したと思います。ただそのように向上させるにはアーキテクチャを見直すしかなかった。 Apacheへの対抗意識もありました。Apacheのパフォーマンスが上がっていることも分かっていますし，やはりApacheの先を行くには何をすべきかを考えると，自然と方向は決まります。 ━━セキュリティに対して，開発側ではどのような取り組みを行いましたか。 ［加治佐］ セキュリティに対する取り組みという点では，Code RedとNimdaはよい勉強になりました。Code RedとNimdaが社会問題になりIISは批判されましたが，既にあの時点でパッチは提供していました。しかし，実際にはそれが行き渡っていなかった。このことから，セキュリティに対する姿勢を変えることになりました。 あれ以前の問題への対処方法は，発見された問題に対していかに迅速に修正モジュールをつくり，それを提供するか，情報をきちんと伝えていくか，というレスポンス重視ではありましたが，いわば受身の態度でしかなかった。もちろんその時点でも，開発では専門にシステム全体のコードをレビューする「セキュリティ対策SWATチーム」という専門部署があり，それである程度は大丈夫だと考えていました。そうした体制で出荷されたのがWindows 2000でした。 しかし，Code RedとNimdaによって，セキュリティ対策とはそんな甘いものではないと痛感し，レスポンスだけではなく，問題を未然に防ぐことにもより積極的になりました。セキュリティへの姿勢を数カ月かけて見直し，セキュリティの専門チームだけでなく開発者全員がセキュリティを意識する，そうした教育を時間かけて行いました。 Windows Server 2003では問題がありそうなところをすべてチェックし，そのモジュール担当の開発者に直させる。具体的に何をしなければならないのか，指示を出す。普通の開発のペースで，セキュリティに知識がある人間が直すようにしました。 また，システムだけでなく，一つひとつのコンポーネント，すべてのモジュールに対し想定外の危険はないかチェックしました。例えば，私たちはサード・パーティと協力してプリンタ・ドライバを開発していますが，サード・パーティも交えてドライバのコード・レビューを行っています。
日本独自のセキュリティ対策も行っています。今までは，日本で何か問題が起きたとしても，英語で報告しなければならず，敷居が高かった。また，MSのサイトを見ても，かなり専門的な知識がないと，分かりにくいという声もありました。 そこで，日本独自で専門のサポート・チームを作って，日常レベルの声を聞くことができる体制をつくりました。例えばセキュリティ・パッチが出た場合，どのようなものか，絵入りで分かりやすく説明するサイトができています。こうしたものは，まだ米国でもできていません。セキュリティに関してだれにでも知ってもらうという意味で，大きな一歩だと思います。 |
