マイクロソフトのEngineering Windows 7 ブログ : Planning

次のエンジニアリングマイルストーンについて

e7blog — Fri, 20 Feb 2009 13:25:26 GMT

この投稿は Windows チーム全体を代表して、Windows 7 Beta をインストールし使用してくださっていることに対する特別の感謝で始めたいと思います。遠隔測定によると Windows 7 は何百万もインストールされているようですが、これは実にすばらしいことです。そして、[フィードバックの送信] ボタンをクリックしてくださった方から、詳細なバグ報告と当然ながらたくさんの提案を受け取っています。開発サイクルにおいて、このような広いカバレージとみなさんの取り組み無くしては、Windows 7 をBeta から最終製品へ持っていくことはできません。このようにすばらしい反応が返ってきていますし、みなさんの中にはどのように Windows 7 Beta を自分のマシンにインストールしたかや、とても快適に使用できていることなどについてブログに書いていらっしゃる方もたくさんいます。最もよく聞かれる質問は「ベータ版が 8 月に期限切れになったらどうすればよいでしょうか? 古い (原文ママ) OS には戻りたくないんですが。」というものです。ベータ版のリリースは補足物ですが、私たちは親切な反応に感謝しています。

この投稿は、現在私たちのいる地点であるベータ版から RTM (= Release To Manufacturing、正式版) までの道のりについて、PDC でお話したトピックを基に議論を進めたいと思います。この投稿は出荷日、計画の変更、これまでに説明したプロセスの変更などのお知らせではなく、どちらかというと RTM や一般に提供されるようになるまでの道のりについて、追加の詳細や前向きな見方を提供するものです。この動機は、Windows 7 に対するハイレベルな興味に加え、Windows をリリースするということはマイクロソフトが「単独」で行うことではなく、PC エコシステム全体の一部として行うことだと思っているところにあります。もちろん、私たちは自分の役割を果たすことに重大な責任があり、重く受け止めています。Windows リリースの最終ステージは、エコシステム全体にわたるパートナーシップであり、バラエティ豊かな PC、ソフトウェア、周辺機器が一緒に動作して完全で満足できる Windows 7 のエクスペリエンスをユーザーのみなさんへもたらすようにすることです。

Windows 7 の開発の次のマイルストーンは「RC」 (= Release Candidate、リリース候補版) です。歴史的に RC は「もうすぐ完成するのでテストを始めてください。特に、すべての機能は入っていますので。」というサインでした。以前に申し上げたように、Windows 7 では少し違ったアプローチをとることにしました。それは正直に実情を公開することで、現在みなさんと一緒に体験していることです。PDC で配布したプリベータ版では大体の API は完成したと申し上げました。まだ含まれていない部分についても、 API やエクスペリエンスの詳細について PDC のセッションで説明しました。同時に、2009 年初めのベータ版は API と機能の両方が完成したものであり、広く提供するもので、唯一のベータテストであろうことをお知らせしました。WinHEC でもこのことについてハードウェアパートナーにお伝えしました。また、PC メーカー、ソフトウェアベンダー、ハードウェアメーカーといった多くのエコシステムパートナーに対し、これまでどおり定期的に中間ビルドを提供していくつもりであることをお伝えしました。これが現在の私たちの立場です。機能が完成したベータ版をリリースし、世界中で広く利用できるようにしました (もっと多くの言語版に対する要望があったことは知っていますが)。開発チームとして、私たちはみなさんの多くがやっていることを行っています。つまり、自宅や会社のたくさんの PC でいつもベータ版を使用し (個人的には 9 台以上のマシンで使用しています)、マイクロソフト社内でも何千もの個人用マシンとラボのマシンで実行しています。

ベータ版を実行している人は積極的にベータ版の修正に貢献していただいていることになります。私たちは、遠隔測定のパフォーマンス、アプリケーションの互換性データ、使用状況の情報、他の分野でのデバイス要件の詳細などを受け取っています。これらのデータはとても体系的で実用的です。私たちはパートナーと非常に強い関係を築いており、すばらしいエクスペリエンスを提供するためにすぐれたツールを使用しています。ハードウェアおよびソフトウェアメーカーが Windows 7 用に改良されたアップデート版のドライバーやソフトウェアを試しているのをご覧になったかもしれません。たとえば、アンチウィルスソフトのメーカーの多くはすでに互換パックまたはアップデート版をリリースしており、インストール時に自動的に適用されます。お気づきかもしれませんが、多くの GPU のチップセットは自動認識され、Windows 7 はアップデートされた WDDM 1.1 対応ドライバーをダウンロードしてきます。Windows Vista 用のドライバーでも動きますが、新しい 1.1 ドライバーは改良されたパフォーマンスを提供し、メモリのフットプリントも削減されます。これは、1GB しかメモリを搭載していないマシンでは大きな違いです。また、デバイスを挿入して最新のアップデート版のドライバーを入手されたかもしれません。私もLogitech の QuickCam でそれが自動実行されたことを確認しました。他の例として、ベータ版をインストールしたら、Skype ソフトウェアを現在テスト中のアップデート版にするよう要求された方がいらっしゃるかもしれません。古いバージョンをインストールしようとすると、エラーメッセージが出て、続いて問題と解決方法が書かれたユーザーインターフェースが表示され、ベータのサイトへリダイレクトされます。この種のエラーハンドリングは、よく知られるにつれ、またエコシステムが新たなサポートを築くにつれ、リアルタイムで展開されていきます。これは、エコシステム全体にわたるパートナーシップがあるからこそ、ベータ期間であってもこのような取り組みが実現するのです。

もちろん、設計の目標は、現在Windows Vista で動いていて、メーカーがまだサポートしているデバイスとソフトウェアは、Windows 7 でも同じソフトウェアで動くことであることです。これまでお話したように、さまざまな理由により、Windows のバージョンを限定したソフトウェアおよびデバイスがありますが、Windows 7 ですぐれたソリューションを提供できるように一緒に取り組み続けています。人々に対し、ありとあらゆる選択肢を提供して Windows プラットフォームの情報を開示することにより、これらのすべてが壮大な取り組みになります。私たちは改善し続けていくと同時に、エコシステム全体の健全性と多様性にとって非常に重要である選択と差別化のチャンスを提供し続けていくようにします。パートナーと一緒に行っているデータと取り組みは、RC の段階へ到達するために現在進行している大変重要な仕事です。

また、ベータ期間中に収集したすべての品質測定も注意深く見ています。クラッシュ、ハング、アプリケーションの互換性の問題、主要なシナリオにおける現実のパフォーマンスなどについて調査しています。ベータから RC への道のりにおいて、ほとんどの力を品質とパフォーマンスにフォーカスして注いでいます。お客様が実際に使用して体験したバグも、広範囲にわたる一連のテストや自動化テストで見つかったバグも、修正したいと考えています。この仕事の中核は、人々が実際に遭遇したバグを修正することであり、どのバグを修正するか順番や優先度を考えながら収集したデータに注力しています。Internet Explorer が RC へ移行した際、この取り組みがうまく作用しました。詳しくは IE Blog をお読みください。

もちろん他の作業もしていて、実世界の使用状況やフィードバックに基づき最終製品に磨きをかけています。私たちはユーザーエクスペリエンスに関してたくさんの詳細なフィードバックを受け取っています。例を挙げると、デフォルト設定、キーボードのショートカット、望ましいオプションなどについてです。言うまでもなく、このフィードバックを処理し、構成し、「集計」するだけでも壮大な活動であり、私たちの中にはこれだけに専念している人もいます。ピーク時には「フィードバックの送信」によるレポートを 15秒おきに受け取っていました! このブログでもお話したように、受け取った意見の内容をはかりにかけてよく考える必要があります。というのも、期待されていたことではありますが、論点のあらゆる側面からの意見があるからで、核となる設計の難問です。また、私たちが単純またはこれでよいと思っていたことが、フィードバックをいただいて実際には調整や改良が必要だとわかったこともあります。これから数週間のうちに、このような製品に対する特定の変更点についてブログでお話しする予定です。変更点はプロセスの一部およびベータから RC の間に予定していた時間の一部です。

さて、私たちは毎日問題を調査し、解決し、その解決策が製品を (パフォーマンス、動作、互換性、または信頼性の面で) 退化させる原因となっていないか確認しています。RC までの道のりは、内部的な観点からも外部的な観点からも (ベータ版の使用、およびパートナーエコシステムの準備が整うこと)、製品が周知され出荷可能な状態にすることに尽きます。

そして、RC をベータの更新版として提供していきます。ベータ版での経験からすると、大変多くの方々に強い興味を持っていただけると期待しています。

RC でも、遠隔測定に基づくフィードバックのプロセスは引き継がれます。ただし、このマイルストーンでは、RC から最終製品の間で何を変更するかについて、選択が極めて厳しくなるでしょう。それについて明確にお伝えしていく予定です。RC の趣旨は、みなさんのリリースに対する準備を確実にすることと、PC メーカーへリリースするまでの間にプリベータ版以降に行ったすべての作業を検証することです。繰り返しになりますが、コードに対する変更はとても限られたものになるでしょう。この時期は、開発チームの生産性が最低だとよく「冗談」を言っています。なぜなら、みんな製品に集中して作業していますが、ほとんどコードは書かないからです。世の中そういうものです－宇宙船は発射台に設置されており、すべての工具は万が一の場合に備えて道具箱に片付けられています。

先にも述べましたが、これはパートナーシップであり、プロジェクトのこの段階で行われる主たることは正にエコシステムの準備を整えることです。PC メーカー、ソフトウェアベンダー、ハードウェアメーカーはそれぞれ準備期間が必要です。新製品、新しい構成、ソフトウェアの更新、その他すべての付随物を準備する時間ですが、つまり、Windows 7 は全員が一緒に準備が整うまで (いわば) 登場できないのです。Web サイト、ダウンロードページ、手引書、トレーニング教材、周辺機器のパッケージなど、作成しなければいけないものを考えてみてください。これには時間がかかります。RC は公でテストする最後のコードで、エコシステムを安心させるものです。私たちの目標は、慎重で、予測可能で、信頼性があることにより、完全な PC エクスペリエンスをお客様に提供することです。

互換性リストの作成も引き続き行っています。まずロゴ製品から着手しており、どんな製品があるか知りたい方はhttp://www.microsoft.com/windows/compatibility サイトで確認するとよいでしょう。これらはすべて、ソフトウェア、ハードウェア、ドライバーを含む Windows 7 PC の完全な「イメージ」を作成する PC メーカーと協力して行っています。これは次のステップのためのリハーサルのようなものです。

その時点で、製品はリリースできる状態になるわけで、これがまさに私たちのやることです。その後でささやかなお祝いもするかもしれません!

もうひとつ、GA (= General Availability、一般供給) と呼んでいる追加の段階があります。この段階は、Windows 7 がインストールされた PC が文字どおり「流通経路を埋め尽くし」、ソフトウェアが (オンラインまたは実際の) 店頭に陳列される時です。多くの人は RTM 版をすぐにダウンロードできるようにして欲しいと思っているでしょうが、今回のリリースではより確立したパターンでいく予定です。また、GA に向けてローカライゼーションのための時間を確保でき、比較的短期間で (以前のどのリリースよりも短い時間で) まさに世界中に Windows 7 をお届けすることができます。なお、RC は十分長い期間機能し続けるようにできているので、安心して RC を使い続けていただけます。

簡単にまとめると:

プリベータ – PDC で配布され、開発者コミュニティーに Windows 7 を紹介しました。また、プラットフォームが完成し、機能を公表したリリースです。
ベータ (Beta) – 200万人に対して機能が完成した Windows 7 を使用する機会を提供したリリースです。また、品質、信頼性、互換性、および Windows 7 のエクスペリエンスを検証するために必要な遠隔測定やフィードバックシステムも提供しました。前述のように、ベータに移行するにあたり、Windows 7 ベースの製品のテスト、検証、および開発が最終段階に入るようエコシステム中のパートナーと協働しています。
RC (Release Candidate) – Windows 7 を出荷するつもりのリリースです。引き続きフィードバックや遠隔測定を受け付けますが、あがってきた問題のうち最も重大な件のみにフォーカスして対処します。製品に対して可視的なインパクトがある変更について明確に伝えていきます。このリリースは、エコシステム全体が周知された状態になり、全員が一緒に RTM に向けて準備ができていることを確認するためのものです。RC に達すると、次の段階に備えた「舞台稽古」モードになります。
RTM (Release to Manufacturing) – PC メーカーや小売店に対し、またボリュームライセンス製品として利用可能とすることになるの最終的な Windows 7 のビルドによるリリースです。
GA (General Availability) – ビジネス的なマイルストーンで、Windows 7 がインストールされた PC や Windows 7 のパッケージ製品を購入できる時を意味します。

プリベータは 2008 年 10 月 28 日で、ベータは 2009 年 1 月 7 日でした。では、RC はいつになるでしょう? RTM はどうでしょうか? 答えは近いうちに明らかになるでしょう。現在、フィードバックや遠隔測定を評価し、予測可能な形で適正なレベルの品質にするための健全なスケジュールを立てている最中です。多くの人々がより具体的な情報を知りたいと思っていることは十分に承知しています。私たちは順調に道を進んでおり、前進しています。製品を完成させるにあたり、品質重視のアプローチを採っており、あらかじめ決められた締め切り日に左右されることはありません。内部的な評価指標とマイルストーンがあり、パートナーは定期的にビルドを受け取るようになっています。ですので、RC になるときでさえ、私たちはパートナーとして一緒に到達するのです。そして、ベータをテストしてくださるみなさんと、一緒にゴールインするために協業させていただいているパートナーの皆様の評価に、かなり大きく依存しています。

これまでの説明でお分かりいただけるとうれしいのですが、Windows を出荷するということはまさに業界全体にわたるパートナーシップを具現化することです。最初の投稿でお話したように、私たちは今までの Windowsリリースのうち一番良いものをお届けすることをお約束しています。それが私たちの目標です。ご一緒に、そしてもう少しの辛抱で、その目標を達成します。

私たちは Windows 7 への反応に謙虚であり続け、皆様のニーズ、そして業界全体のニーズを満たし続けるような製品を提供できるよう、懸命に取り組んでいきます。

--Steven、Windows 7 チームを代表して

“エコシステム”

e7blog — Mon, 20 Oct 2008 14:13:00 GMT

このブログに対し電子メールとコメントで多くのフィードバックをいただいています。いただいた一つ一つのご意見には複数の側面あるいは立場があります。一貫して見られるのは、ユーザーの皆様ご自身にとって、ベストのものを選択して欲しいというご要望です。選択の幅はWindowsをどのように構築するかに関して極めて重要なので、私は選択の幅 (あらゆる形の選択肢) の問題について理解したいと常々考えています。選択の幅について取り上げるのは、Windowsがエコシステムの一部だからです。多くのユーザーがコンピューターのタイプ、オペレーティングシステムの構成、およびアプリケーションやサービスの作成、提供、使用などに関して多くの選択をすでに行っていらっしゃいます。また、Windowsはこのエコシステム内の大きなコンポーネントになりつつあり、Windowsだけでは選択の幅の問題を解決できないのです。私たちが Windows 7で行おうと努めているのは、Windows 7の構築においてこのエコシステムの各側面において優れた仕事を成し遂げることです。

エコシステムと選択の幅とは密接な関係があります。私たちは、Windowsを構築するときに、Windowsを取り巻くエコシステム内の多くの重要な代表的なグループのことを念頭に置いています。それらは、

l PCメーカー

l ハードウェアコンポーネントメーカー

l ソフトウェア開発者

l 先駆的ユーザー

です。上記のグループは、PC エクスペリエンスの提供、多くユーザーがPCを手にして特別仕立ての差別化されたエクスペリエンスを準備できる環境の形成、また、企業が独自の差別化された製品やサービス (および消費者への選択肢) の提供により利益を得る環境の形成に関して、おのおの主要な役割を担っていらっしゃいます。そして私たちの Windows 7での目標は、各グループがWindowsで得られるチャンスを最大限に利用できるように、計画をより明らかにし、より力強くそれを推進することです。

PCメーカー (OEM) は、様々なエコシステムの側面を統合する重要なポイントです。彼らは、ハードウェアコンポーネントを購入して統合し、ソフトウェアアプリケーションをプレインストール（バンドル）します。また、PCの販売などにおいて販売業者と協力します。PCメーカーが PCと工業デザインで提供する選択肢を、私たちは個人としてもとても重要視しています。最近、より低コスﾄのラップトップや極めて薄いラップトップが大々的に売り出されているのを目にします。それぞれに独自の機能と利点とが組み合わされています。時として膨大な消費者向けの選択肢は、他に見られないほど豊富です。Windows 7では、優れたエクスペリエンスを顧客に提供する方法について共有していくために、開発プロジェクトの当初からOEMと非常に緊密に協力し合っています。一緒になって差別化されたPC エクスペリエンスの提供方法を共有し、プレインストールされたソフトウェアについてのユーザーからのフィードバックを共有し、さらに、新しい PC上でのブートやシャットダウンなどのエンドツーエンドのパフォーマンスに関する主なメトリック測定においても共同で取り組んでいます。

ハードウェア コンポーネントには、CPU、I/O の「コア」周辺機器、さらにアドオンコンポーネントまですべて含まれます。ハードウェアメーカー (IHV) の優れた仕事により、 Windowsよってサポートされるハードウェアデバイスの選択の幅は膨大なものです。Windows 95とプラグアンドプレイの導入以来、新しいデバイスを単に接続するだけで機能するというこのエクスペリエンスは、さらなる向上を求めて引き続き研究されています。そのエクスペリエンスにより、Windowsのリリースとは関係なくOS拡張機能を体験できます。この領域については、機能するのが保障された少数のデバイスだけをサポートすべきだと言う人たちもいます。しかし、選択の幅の広さと機能向上し続けるハードウェアの存在は、Windowsの固有のリリースとはしばしば無関係に、ハードウェアメーカーが、Windowsでの差別化されたエクスペリエンスとを供給する能力によってもたらされるのです。デバイスドライバーモデルは、これを実現する為にMicrosoftが提供したWindowsのコアテクノロジーです。Windows 7では、ドライバーモデル安定化の促進に取り組み、Windows Vistaでの成果がWindows 7にシームレスに適用されるよう推進しています。ドライバーは、ハードウェアメーカーが、差別化されたエクスペリエンスを表現する場所です。したがって、選択の幅と機会の多さは非常に重要です。私たちの大部分は、Windows 7の「クリーンインストール」が“当然”機能し、必要な場合にはWindows Updateからのドライバーをシームレスに取得するというエクスペリエンスを望んでいます。これは今、現代のPCの大半上で“当然”機能すると表現されますが、数年前と比べたら驚きの機能なのです。私たちは、PCメーカーと同様にハードウェア・メーカーとも長い時間協力し合っています。WinHECでは、Windows 7でのデバイスやハードウェアエコシステム関連での進歩をお見せする機会を用意しています。

ソフトウェア開発者は、Windowsのためのソフトウェアを作成します。ハードウェアエコシステムと同様に、ソフトウェアエコシステムでもWindows プラットフォーム向けに開発する多くの人々が存在します。Microsoftのルーツはプログラミング言語の提供にありますので、ソフトウェア開発者はMicrosoftの中では特別の位置にいます。Windowsの各リリースでは、開発者が使用して開発したいソフトウェアを開発するための、新しいAPIおよびシステムサービスが提供されます。Windows 7を開発する際に直面する2つの主な挑戦があります。まず、Windows Vista上で動作するプログラムを、引き続き確実に Windows 7上で動作させるということです。それはプロジェクトのスタート当初からの私たちの公約です。皆さんもご存知のように、これは新しいオペレーティングシステムを提供する場合、おそらく最も重要な点です。時には万全を尽くせない場合もあるので、各リリースの際、リリース前にどうしたらより多くのソフトウェアのテストや確認できるかを考えます。ベータテストは確かに助けになりますが、それですべて品質検証ができるかといえばそうではありません。Windowsの各リリースで私たちが改善してきた手法であるテレメトリー（遠隔測定）が、重要となります。リリース時には互換性を持たない時もあるのですが、このテレメトリーによりリリース後に問題点を診断して対処することができます。アプリケーションエラーが生じ、インターネットに接続している場合は、更新版が利用可能というメッセージを目にしたことがあるかもしれません。もちろん、この一連の過程をもっとしっかりする必要があることを理解しています。Windows 向けの開発者がこのような状況に陥らないように活用できるツールや手法を改善する必要があります。ユーザーがソフトメーカーとMicrosoft間でたらい回しにされるのは最良のソリューションではありません。

2番目の課題は、開発者がアプリケーション用に新機能を提供するのを支援する、新しい APIを供給することです。それと同時にこれらの APIは、それを利用するために時間を費やしてもよいほど十分に価値がある必要があります。私たちはしばしば内部的に、GUIの全体的な「大きな」進歩について話し合います。それは、クリップボードであったり、アプリケーション固有のドライバーを開発する必要のない印刷できる機能であったりします。現在、ネットワークやグラフィックス機能は、アプリケーション開発で重要な役割を果たしています。Windows 7でタッチ機能に関連した新たな機能についても話しました。私たちは64 ビットが、開発者がエネルギーを費やすべき場所であるということを明確にしてきておりますし、64 ビットへの移行は進行中で、私たちはそこに集中しています。

先駆的ユーザーとは、エコシステムの重要なイネブラーです。あなたもこのブログの読者ならば、エコシステムのこのグループの一員である可能性が大いにあります。この業界で働いている私たちでさえも、この業界の“ファン”でもあるからです。Windows リリースが先駆的ユーザーにアピールする必要があるということには多くの理由があります。たとえば、私たちの多くは、家族、友人や近所の皆さんのために、構成や設定を最初に行います。私は、学校の先生や友人のために新しいワイヤレスネットワークを設定するために土曜日を費やします。皆様の多くも同じことをしていると思います。先駆的ユーザーは常にPCに対しての選択や設定の自由度を要望するグループです。プレインストールされたソフトウェアのロードに基づいてレビューを始めるのは先駆的ユーザーのサイトや雑誌です。ゲームグラフィックスのような新しいハードウェアの限界を押し挙げるのも先駆的ユーザーです。64 ビット Windowsを支持しているのは先駆的ユーザーの皆さんで、マイクロソフトをプッシュして、Windows 7向けに64 ビットの環境が準備ができていることを確認させているのも先駆的ユーザーです (私たちももちろんプッシュしています)。私は、先駆的ユーザーをこのエコシステム全体とコミュニケーションするための重要なチャネルと考え、開発の様々なフェーズに参加していて頂いています。このブログは、先駆的ユーザーと私たちがWindows7の開発にあたり、行うべき選択肢に関する複雑な事情を共有する絶好の機会です。

エコシステムには、このほかにも全体をまとめるための重要な参加者がいます。システムビルダーとVARは、PC、ソフトウェア、およびサービスを世界中の企業に提供します。いただいた電子メールによれば、このブログの読者の多くはエコシステムのこの部分を担っています。多くの国々では、リテールショップ（販売業者）は、個人ユーザーのためのインターフェースになっています。IT プロフェッショナルは、大企業ユーザーのために、多数のPCに対するカスタマイズおよび管理を要求します。そのニーズは組織ごとに独自であり、非常に厳しいものです。

エコシステムは最良のアプローチではなく、Windowsの「表面積」を狭くして、より少数のデバイス、より少数のPC、より少数のアプリケーション、を対象とし、過去のものとの互換性を持たせないようにすれば、ユーザーのためにはるかによいジョブを行える場合がある、と言った人もいます。私はさまざまな意見より、人々が多くの選択肢 (DPIやモニターサイズだけをとっても) を望んでいることを理解しました。エンジニアリングの視点から、より狭い「表面積」は、エンジニアリングの問題を容易 (定義により) にするという人もいるでしょう。しかし、実際には、そのような方法は、ユーザーの方々が利用できる選択肢を根本的にどんどん狭めてしまいます。実際には、エンジニアリングとは、いかに制約を適所に設定するかということで、それらの制約という名のデバイスやアプリケーションの選択肢の幅、Windowsの「歴史」こそが資産でもあるのです。PCのためのエコシステムは、多くのユーザーが多くのアイデアを早い時期に試す場所で、初期にはいささか常軌を逸しているように見えても、後になればメインストリームになるようなアイデアを検討する場所でもあります。 Windows 7では、Windows Vista用に皆様が行った仕事を基礎に置きつつ、エコシステムに向けての新たな準備に取り組んでいます。

エコシステムは、関連するグループとの関係の深さおよびその幅がたいへん重要です。このブログでの対話の目的を達成するには、エコシステムについてこの時点で強調するのは価値があることだと思いました。エコシステムの各グループのニーズをバランスするには常にエンジニアリングの影響があります。完全に1つの見方で最適化するのは、短期的には最善に見えることもありますが、時間の経過を考慮すると、それは極めて危険なやり方です。差別化に対応する安定したプラットフォームの利点は、多くの人に利益をもたらすからです。

Windows 7では、PCエコシステムの一員として、より優れた仕事をすることを第一としました。

以上の私たちの考えは、皆さんのエコシステムについての思いと比べてどうでしょうか。優れたPC エクスペリエンスをもたらしている人々のことを、もっとよく説明できればと、いつも考えています。

--Steven

Windows 7 開発プロジェクトの構成

e7blog — Thu, 11 Sep 2008 10:00:46 GMT

こんにちは Jon DeVaanです。

すでにStevenは、私たちが仕事をする上でとても重要な要素であること、すなわち、いかに私たちがエンジニアリング“チーム”を構成しているかについて書きました。もう一つの重要な要素はいかに私たちがエンジニアリング“プロジェクト”そのものを構成しているかです。

まずは、いくつかのお断りからはじめます。ひとつ目としては、Stevenは私より10倍ほど早く読み書きを行います。ですので、二人の文書を比較した場合、それぐらいの差があってもびっくりしないでください。（でも、安心してください、ここだけの話、私の方がよく考えるほうです。(笑) それとも、ただ嫉妬しているだけかもしれません。）二つ目としては、私たちは“どのようにしてWindowsを開発しているか”というトピックを共有していきたいと思っています、なぜならば、そうすることによりPDCとWinHECが近づいてきて詳細な機能の議論を始める時に共通の文脈を保てるからです。私たちはLonghorn/Vistaの教訓を生かしていかにWindows 7を開発しているかを議論していきたいと思っています。これらすべての事実がWindows7での判断に関係してきます。

それでは、本題を始めたいと思います。

Stevenが以前、Microsoft Secretsという本を紹介したかと思いますが、これは素晴らしい分析結果だと考えており、私はこれをMicrosoftのエンジニアリングシステム Version2と呼んでいます。（Version 1は、索引カードと“フロッピーを使ったネットワーク”が絡んでいて、あまりみなさんが興味ある内容ではないと思います。）Version 2は誰もが思った以上の長い間Microsoftにとって有益でした、しかし、Windows XPより得た教訓やLonghorn/Vistaの時代から顕著になった本質的に違うセキュリティ環境より、製品を開発するアプローチを考える上で世代交代の時期を迎えていたのは明確でした。

XPより学んだ教訓は、私たちの業界を取り巻くセキュリティに関する考え方の変化です。私たちがいかにこの教訓を活かしてきたかは、より安全なソフトウェアを開発するためにMicrosoftが推奨しているエンジニアリング手法についてまとめたSecurity Development Lifecycleを読むことによりわかると思います。私たちは内部でもWindowsを開発する上でこの手法を使っています。

このBlogのコメントを見ると、全体のシステムの品質と言うのは様々な、それぞれに人にとって別々の重要性を持っている事がわかります、またVistaの全体的な品質についても様々なご意見をお持ちだという事もわかります。私はOSの基礎の部分の信頼性についてたくさんの時間をかけており、実際のユーザーより（もちろん自発的にCustomer Experience Improvement program（訳注：日本語訳はカスタマエクスペリエンス向上プログラム）にご参加いただいているユーザーのみです。）収集したテレメトリー情報の分析にたくさんの時間をかけています。このテレメトリー情報がSP1の時に何をしなければいけないかの指標となりました。私はVistaでスリープ/レジュームが良くなっているという皆様のコメントを読んでうれしく思っています。また、私はこのテレメトリー情報を利用し続けてVistaをもっとも信頼性の高いWindowsのバージョンにする事に努力し続けられる事（実際、私たちはその作業を行っているのです）に興奮しております。Vistaのセキュリティの脆弱性はXPに比べて半分以下にすることに成功したことも指摘しておかなければなりません。これはWindows 7に関するブログですが、Windows Vistaが実世界でどのように稼働しているかについて、深く理解する努力をしながらWindows 7の作業を進めています。

もっとも重要な事として、皆様はメールやコメントを通じて、いかにWindowsのエンジニアリングシステムを改善できるかを指摘していただいています。パフォーマンス、信頼性、コンパチビリティ、と新しいテクノロジーへの対応へのお約束の反故等はそれらのコメントの共通テーマです。それら問題の解決への一つのアプローチは、私たちがいかにWindows 7のコードベースの開発を日々管理しているか、つまり日々のビルドの品質を強化しているかです。

これを読みながら皆様は“何を当たり前の事を！”と感じておられるかもしれませんが、しかし、私の経験では、いくらそのようにしたいと私たちが望んでも、ソフトウェアプロジェクトの規模や組織に関係なく、これはそれほど簡単でも、明瞭に解決できる問題でもないのです。

日々のビルドの品質

ソフトウェアプロジェクトにおいて、毎日の品質はとても重要です、なぜならば毎日残っている作業量の予測をつかって重要な決定をしなければならないからです。日々のビルドの品質が低いと、どれだけの作業が残っているかを知ることはとても困難になります、それは数々の悪いエンジニアリング上の決定につながっていきます。作業に携わるエンジニアの数が増える（なぜなら私たちはたくさんの事をやりたいから）と日々のビルドの品質の重要性がさらに増します、なぜなら一人のプログラマーのエラーの確率に伴い、完成させる労力も増えていきます。問題は製品にいくつバグが潜んでいるかがわからないというだけではありません。もし問題がそれだけなのであれば、少なくとも個々の結末は個々のデベロッパーに委ねられる事になります。もっとも油断のならない副作用は個々のデベロッパーが日々の更新結果を個人の作業に反映する自信がなくなった時です。このような事態がおこってしまうと、私たちの知らないバグ、互換性問題やその他私たちが容易に知りうることができない問題がたくさん発生します。なぜならば、誰も一つのマシン上にWindows 7のすべてのソースコードの変更をまとめていないからです。

この現象を図解かするためにグループのサイズの範囲内（青い線）で個々のプログラマーが100回に1回のエラーレートでどれだけのビルドブレイクがおきるかを予測する簡単な公式を用いたグラフを用意しました。1%のエラーレートというのはとても良い状況です。同時に個人のエラーレートを半分にした場合（赤い線）と、10分の1にした場合（緑の線）のビルドブレイクの確率の線を二つ同時に示します。見てとれるとおり、各エンジニアの日々の品質を向上するメカニズムを導入する事によって日々のビルドの全体の品質を向上するのに大きく貢献いたします。

Windowsの開発チームのような規模になると、毎日のビルドの品質を向上させるのはかなり難しい問題です。

私たちのWindows 7における改善点はWindowsのすべてのフィーチャーチームを横断し構築した共通自動化テストのインフラストラクチャーに注力していることです。これは、Vistaでのエンジニアリングシステムからの大きな改善です。（多くの人は気付きませんが、エンジニアリングのプロセスとチームの組織の間には避けられない関連性があります。）このインフラストラクチャーを使い、私たちはすべてのフィーチャーチームが行ったコードの改変を実際に毎日のビルドにマージする前に確認する事ができます。フィーチャーチーム内部ではこのインフラストラクチャーを日々のプログラマーが行うコードの改変の確認に使う事ができます。図よりビルドブレイクの確率が40人のプログラマーのフィーチャーチームでバランスされますので、フィーチャーチーム内部ではあまり起こらない事が見てとれるかと思います。

Windows 7 においては毎日高いレベルのビルドを作ることに成功しています。もちろん、時にはデベロッパー全員の作業を統合する過程でビルドブレイクは起こります、しかし、自動化テストがそれらを事前に検出し修正する事によりほぼ毎日高い品質のビルドを作成することに成功しています。私はこのプロジェクトの開始と同時にWindows 7をほとんど問題なく使えています。（多くの皆様も、私と同様にWindows 7を使いたいと思われているかもしれませんが、もうしばらくお待ちください！）

ご参考までに、毎日24時間サーバーとクライアントをビルドし検証している私たちのビルドラボの写真をいくつか紹介させてください。

まとめ

今回のポストは私が毎日かなりの時間を割いているトピックを駆け足で紹介しました。楽しんでいただけたでしょうか？この例で私たちがいかにWindowsの開発手法の向上を全体的な取り組みとして考えてきたかの一端をご理解いただければと思います。私たちの考えが本当に正しいかどうか、私たちの製品の品質それ自身が証明してくれると思っています。このソフトウェアエンジニアリングの重要な問題に対して、皆様の考えをお聞かせください！

Windows の製品プランニング___フィードバックの反映

e7blog — Sat, 06 Sep 2008 10:00:00 GMT

編集ノート: Windows プランニング & PC エコシステム チームを率いている Mike Angiulo を紹介したいと思います。Mike のチームは私たちのすべてのハードウェア、ソフトウェア パートナーと緊密に仕事をさせていただいています。また、新しいバージョンの Windows に対する、エンジニアリング チームのプロダクト プランニングとリサーチについて担当しています。　--Steven

Windows には、私たちの顧客と市場について学ぶための様々な種類の手法があり、それらはすべて私たちが何を開発するのかを決めるために役立っています。WinHECとPDCで私たちのエンジニアがお答えするであろう個々の質問から、私たちのテレメトリーシステムにある何百万ものレコードまで、皆さんが私たちに Windows で何を開発して欲しいと思われているか、またそれがどの程度うまくいっているのかなどといった、あらゆる種類の質問のほとんどに回答するためのツールを私たちは持っています。（訳注：テレメトリーシステムとは、Customer Experience Improvement program - カスタマエクスペリエンス向上プログラム(CEIP)を経由し、世界中のユーザーの皆様のPCからインターネット経由で自動的に送っていただいた、PCの稼働状況情報のデータベースのことです。）これらの声のすべてを併せて聞き、オペレーティングシステムリリースするために、きっちりとしたプランを構築するのは、たいへん大きな挑戦です。 – それは、まるで10 億人もの親友からのピザの注文を受け付けるような気分です !

学び続ける組織を作るために、私たち自身がいつも学び続ける態度を失わないようにすべきであるという点は、言うべくもないことです。この活動は私たちの組織ではプロダクトプランニングチーム（何十人ものエンジニアで構成され、フィーチャーチームのプログラムマネージャー、開発者、そしてテスターと一緒に仕事をしているチーム）がリードします。彼らは、製品開発サイクルを通して私たちの製品のビジョンに説得力があるかどうか、そしてそのビジョンが私たちのお客様の実際の環境を元にしていて常に変化しているビジネスの現状や競業製品の状況とのバランスが取れているかどうか、を確認しています。ここ 2 年間、私たちは何十ものプロのリサーチャーを動員してサーベイを実施し、フォーカスグループからの聞き取りを行い、テレメトリー情報や製品使用状況を解析しビジョンを組み立て Windows 7 の開発へ進んできました。その作業はまだ終わっていません。私たちが独自に行っている市場調査や、このブログの皆さんのフィードバックを参照することなどで、私たちは、私たちの製品そのものと、私たちが顧客やパートナーに製品について話すための方法を洗練し続けることを考えています。ただしこれは、あらゆるご要望にお答えできるということを意味するわけではありません。プランニングにおけるもっとも困難な仕事の一つはこれらすべてのデータを、開発のための実施可能なプランに転換することです。最近は3つの厳しいトレードオフと直面しています。

最初のトレードオフについて私の頭に浮かぶのは、“テイスト・テスト・チャレンジ”です。３０年以上前にこれは有名な２つのコーラの争いで起こりました。“ニュー・コーク”を憶えていますか？それは、製品に対する顧客の最初の反応と長期間にわたる製品への顧客の満足度の違いを極端に誇張したため起こりました。私たちは、ウインドウズの開発において、常にこの問題に直面しています- つまり製品の良さをわかりやすくすることと製品がそのライフサイクルにおいてずっと高い品質を発揮できることのバランスを、どうすればとれるか？ということです。皆さんは、とにかく早く起動するものと、皆さんが何かするため役にたつものではどちらが良いですか？もちろん私たちはどちらかに極端にかたよることもありますし、その通りにしてしまったこともあります-実際私たちわずか１０年で“c:\”から“マイクロソフト・ボブ”まで達しました。製品を箱から取り出した時に新鮮で素晴らしいものであることと、製品がずっと性能を発揮できるかのバランスを取ることは、常に課題です。マイクロソフトには民族誌学者（ethnographer）がおり、時には製品の購入前から何か月も定期的に顧客を訪問して、私たちの製品のライフサイクル全体において最初の印象がどのように製品の使われ方に影響するかを調査しています。

２番目に私たちは常に、“木を見て森を見ず”ということがないように注意しています。それは、顧客全体の情報と個々の顧客の情報を適切なバランスで参考にするということです。伝統的なPCについての議論は、限られた部分的な使用方法が集まって全体的な使用方法を構成する、というようなものでした。その結果、限られた機能を持つデバイスの方が簡単であって大多数の顧客を満足させるということになってしまいます！もちろん、この結論は短期的に見ても、また長期的に見ても正しくないとわかる場合があります。長期的には、“一般的な使用方法”はタイピングと印刷からCDを聴くことや焼くことに、そしてゲームをすることからインターネット閲覧へと変わって行きましたし、徐々に発展し続けて行きます。短期的にみても、私たちは何千というPCの使われ方を調査してきました（もちろんご協力いただいたユーザーの皆様のおかげです）、そしてたくさんの一般的な使用方法が実際に一般的である一方で、私たちが調査したほとんどすべてのPCで１つまたはそれ以上の独自のアプリケーションが使われていて、それは他のPCにはないということがわかりました！この“ロングテール現象”は非常に重要です。なぜなら、もし私たちが“一般的な使用方法”のためだけに製品を設計したら、最終的には誰にも満足していただけなくなるからです。この選択と複雑さのトレードオフは、集団と個人の両方の使用方法を厳密に調査し、どちらの観点も失わなかったことから得られたものです。

3 番目はタイミングです。タイミングが全てです。私たちには、非常にダイナミックな市場 – 現在私たちが開発しているものが影響を及ぼしてしまう市場の状況です – を学んでいくために、現在実行しているプロセスがあります。最終的なゴールは、ソフトウェアとハードウェアの究極的なエクスペリエンスをお客様に提供することです。つまり、適切なタイミングに適切な製品を提供することです。私たちは、新しいカテゴリーのソフトウェアサポートのリリースをあまりに長く待っているとどういうことになるのかを学びました。 (早い段階からBluetooth ペアリング標準規格のエクスペリエンスの件に関しては、もっとうまくやれたはずだと思います。) また、ソフトウェアは出荷しても、残りのエコシステムがまだ対応できていない場合にどうなるかもわかっています。この問題は、将来提供されるテクノロジーの啓蒙、競合する規格の追跡、ユーザーシナリオの進化への注目、ソフトウェアサポートの調整、などの作業を伴います。対象が流動的と言うには十分でないかもしれませんが、これらのことは、ある Windows がリリースされた後でさえ、私たちが継続的にフィードバックを得ている理由を示しています。

これら 3 つの主要なトレードオフは、常に活発な議論を生み出します。このブログに対するこれまでのコメントを見れば一目瞭然です！もちろん、これら「明示された」ニーズに責任を持つことは、私たちのいるダイナミックでチャレンジングな市場の中では必要なことです。同時に私たちはとりわけ大きなトレードオフに決着をつけなければなりません。それは、現在必要なことと、将来必要であると思われることとのバランスをとることです。これは、「明示されていないニーズ」を定義する際の課題です。全ての技術産業は、革新するのか維持するのか、または、不連続な S 字曲線の概念を認めるのかどうか、など、それをどう呼ぶかに関わらず、このトレードオフに直面します。同じ市場から情報を得ていた 2 社の成功した自動車メーカーが、最初の商用ハマーと最初のハイブリッド車プリウスを同じ年に発売したのはなぜでしょう？1998年が混乱していたからだというわけではなく、短期的な市場のニーズと長期的な市場のニーズが明らかに一致していなかったからです。郊外のショッピングセンターの混雑した駐車場で生き残るための強化されたオフロードキャパシティーに対するニーズがある一方で、世界中の大学で予測されていた切迫した環境破壊問題がありました。両方の勢力ともはっきりとしていましたが、容易に片付けられてしまいました。私たちはこのように、バランスが必要な状況にいつも直面しています。ひとつのリリースで、下位互換性と将来への拡張性をどのように提供すればよいのでしょうか。64 ビットに向かう傾向はアプリケーションシナリオによって促進されるのでしょうか、それともお店で売られている 4GBマシンによって促進されていくのでしょうか。

私たちには重要なトレードオフに対するインプットがあります。私たちは将来の動向に対する見解があります。通常これは次のバージョンの製品を始めるには十分であり、私たちの計画を最初の方向性から開発期間の終始一貫するようにお客様やパートナーとの関係を持続していますが、しかし製品を出荷できるかどうかを知るには不十分です。本当に出荷できるか確認するには、コミュニティテクニカルプレビューであろうと、技術適用プログラム（Technology Adoption Program = TAP）であろうと、もしくは昔ながらの一般向けベータであろうと、常にいくつかのエンジニアリングフィードバックの工程を必要とします。ベータテストの起源や、それどころか現在のベータという言葉の定義ですら不明瞭です。いくつかの製品は永遠にベータであるようです！私たちは、製品を皆さんにお見せし、最終的なフィードバックを得るのに最も効果の高いタイミングを見つけようとしています。もしあまりにも早くリリースすると、通常は特にパフォーマンス、セキュリティ、互換性、そしてそのほかの重要な基本機能の評価をするに十分ではありません。もしあまりにも遅くリリースされると、私たちは皆さんからのフィードバックを実際に吸い上げることができません、つまり、自動的に無視されてしまうようなフィードバックを皆さんにお願いすることになります。これこそは顧客満足度を低下させるもっとも効率的な方法だと私は思っています。ただ単に「このサイトを見て！」、というコメントがたくさんあるだけのような、ある会社のソフトウェアへの「フィードバック」サイトがあることを見たことがあります。Windows 7に対して私たちは体験するに十分でありかつ、製品を洗練させる為に十分な時間があるようなタイミングでベータをリリースします。このブログは私たちのプロセスの中で重要なものになるでしょう。なぜならば、このブログは(製品開発プロセスの中で)残された自由度、それぞれのエリアに対する重要な仮定について、皆さんにご理解いただけるようにするための、十分な説明、コンテンツ、そしてガイドラインを提供しますし、また皆さんからいただけるすべてのフィードバックについて、耳を傾け私たちから返答をするという対話を形作る事ができるからです。その結果いくつかのバグはフィックスされるでしょうし、いくつかはドライバーやアプリケーションのバグとして私たちのパートナー企業の方々が修正できるように私たちがお役に立てると考えます。いくつかのケースでは（たとえそれらが有意義であったとしても）議論をするだけで終わってしまうかもしれません。ただし、このようなケースにおいても私たちは話し続け、建設的なコメント、バグ、アイディアに対しお答えしていきます。以前にはないくらい有意義な会話が始められるでしょう。どうかコメントを引き続きお願いします。また、Customer Experience Improvement program（訳注：日本語訳はカスタマエクスペリエンス向上プログラム）にご参加ください。 WinHEC 、 PDC 、ニュースグループ、フォーラムにおいてフィードバックをいただけますように、どうぞお願いします。 – 皆様の声をお待ちしています！

Thanks,
- Mike

リリースのスケールの判断 – メジャーリリース？

e7blog — Tue, 26 Aug 2008 22:00:00 GMT

たくさんのフィードバックをいただき感謝しています。またそれらの多くがポジティブな内容であったことをありがたく思います。私はできるかぎり皆さんからいただいたメールに回答し、チームのメンバーと共にそれらのコメントについて議論してきました。詳細なことや希望、要求に関し皆様それぞれの立場での意見を共有する努力をしていただいた事にも感謝しています。私はこれらのメールを受け取ること、そしてコメントを読むことを本当にうれしく思います。まさに素晴らしいことです。いただいたコメントに一つ一つ回答できないことをお許しください。私たちがやるべきことは、今後取り上げるべきトピックスを考える上で、メールやコメントを参考にしていくことだと考えています。すべての方々からの温かい反応にチーム全体が感謝しています。多くのエネルギッシュな議論をこれからできるであろうと思っており、そのような場を開始できたことを本当に幸せに思っております。

この投稿では、私たち「Win7チーム」が内部でどの用に物事を考えるかについてのお話を続けたいと思います。範囲を少し広げ、私たちが行ったリリース (出荷) の計画に関する話し合いについて少しお話します。リリースがメジャーかマイナーということについての会話は、プランニングを開始するにあたって私が上司とした会話とそっくりです :-)

リリースの計画を開始する際、まず決定しなければならないのが、Windows 7 (クライアント) は「メジャーリリース」かどうか、ということと思われるでしょう。ここで「メジャーリリース」を「」で括ったのは、これは実際にはお客さまが決めることではないですし、ひとつしか答えがないことでもないからです。リリースがメジャーかそうでないかということは、機能そのものが要因となると同時に、機能に対するお客様の見方も要因となります。メジャーリリースと宣言されることはほめ言葉か、と尋ねられることもあるでしょう。製品を計画するエンジニアとして、私たちは前もって、そのリリースに携わる開発チームの割合とスケジュールの限界を決定します。その結果、お客様は自分自身にとってそのリリースは「メジャー」かどうかを判断することになります。もちろん、私たちはその判断についての意見も伺いたいと思います。server blog では、スケジュールについて話したり、Windows 7 クライアントおよびサーバーのリリースのスケールの意見を共有したりしています。

私たちの目標はWindows 7 を最高のリリースにすることです。

すべてのお客様には、メジャーリリースは自分のための機能があるものであり、マイナーリリースは自分のためのものが何もないもの、という見方が常にあります。そうであれば、メジャーリリースの計画はとても簡単なものになるはずです – すべての人にとってまさにぴったりの機能であることさえ確実にすればよいのです! (パフォーマンスについて取り組んでいる限り、余分な機能は、たとえ他の人が欲しいと思ったとしても、入れません。) エンジニアとして私たちは皆、そのような設計プロセスは実際には不可能だということを知っています。特に、ある二人の顧客はまったく反対の機能を望むことがよくあるためです。実際、私がこれをタイプしているときに電子メールを続けて受け取りましたが、ひとつは「誰もタッチスクリーンについて気にしていない、ナンセンスだ」というもので、もうひとつは「Win7 はもっと高度で堅牢なタッチ機能が必要だ」というものでした。あなたも、組織化されてない一方的なインプットを受け取ったとき、このような正反対のものをかなりよく見かけると思います。また、ブログのコメントでもお気付きかと思います。

さて、さまざまな (すべてではありません) 顧客の種類 – 一般ユーザー、開発者、パートナー、IT 技術者、およびインフルエンサー－に対する多種多様のリリース規模について検討してみましょう。

一般ユーザーは通常、リリースがどの規模になるかを決定するという点で、もっともシンプルです。一般ユーザーにとって、もしアップグレード版または新しい PC を買いに出かけたいと思えば、そのリリースは一大事で、メジャーリリースと呼べるでしょう。十分に単純で、メジャーリリースは誰にとってもよいことのように見えます。その一方で、リリースはとても素晴らしく買いたいと思っても、既存の PC を使い続けたく、新しいリリースを十分に使うにはもっとたくさんのメモリ、入手困難なドライバのアップデート、特殊なハードウェアなどを必要とする、というケースも想像できます。そうすると、メジャーリリースは肯定的なイメージから少々押され気味になり、その輝きの一部を失うでしょう。もちろん、私たちは皆、人々が本当に必要とするものは、彼らが必要とするハードウェア上で動作するすべてのもので、それが (メジャーであるかどうかにかかわらず) 優れた製品であることを知っています。

開発者は違った視点でリリースを捉えます。当然ながら、開発者にとって、新しい API や彼らのソフトウェアにとって利点となるような能力がある場合、リリースはメジャーリリースとなります。これも、十分に単純です。一方、前回のリリースでたくさんの新しい API があり、やっとそれらに慣れてきたところで、実際に望むのはそれらの API を完結させてパフォーマンスを向上させること、というケースも考えられます。その場合、最初のリリースがメジャーリリースで、二番目がマイナーリリースではないかと思うでしょう。しかし、ソフトウェア製品の歴史を見ると、これらの「マイナー」リリースがメジャーリリースになることはよくあることなのです。たとえば、Windows 3.1 であったり、Office 4.2 であったり、Windows XP SP2 もそうです。それぞれのケースでは、開発者対象では「マイナー」リリースでしたが、市場的には「メジャー」リリースでした。開発者が新しい API を使用したい理由は、製品を差別化するためであったり、エネルギーを専門分野に集中させるためであって、単に新しい API を呼ぶために呼んでいるのではありません。その意味で、ソフトウェアメーカーの時間を節約できるのであれば、リリースはメジャーと言えるでしょう。なぜなら、新しい API に賭けることによって、彼らにとってメジャーな取引に集中できるからです。

パートナーとは、Windows を含むエコシステムを形成する PC、ハードウェア、インフラなどを制作する広い範囲の人々を示します。パートナーはメジャーリリースをチャンスという意味で考える傾向があり、そのため、メジャーリリースとはたくさんの変更があるものであり、つまり、新しいハードウェアやインフラを顧客に提供するチャンスをもたらしてくれるものです。その一方で、過去との非互換は、パートナーに前進を中断させて新しい Windows との互換性を保つために過去の仕事の見直し作業を必要とする場合、決して肯定的な面では見られません。もし、いくつかの理由によりパートナーがそのような作業をしないと選択したならば、リリースはエコシステムサポートの欠如からマイナーリリースと見られるでしょう。つまり、大きな変化はメジャーまたはマイナーリリースのレンズを通して見られます。

IT 技術者はしばしば、生来保守的で変化に対しても保守的な見方をするとみなされています。ビジネスに重点を置くという役割の性質上、ソフトウェア製品の評価は投資収益に即して行われます。そのため、IT 技術者にとってのメジャーリリースとは、大幅なビジネス価値をもたらすものということになるでしょう。このビジネス価値は、たとえばソフトウェアの導入や管理における大きな投資と定義することができます。一般ユーザーや開発者にとって、これらの機能は興味の対象にもならないことはもちろん、メジャーかマイナーリリースであるかにも値しません。

インフルエンサーは、私たちの作ったソフトウェアに対してアドバイス、分析、および視点を提供するビジネスに従事する人々です。これらの人々はしばしば、「変化」の基準を通してリリースを見ます。大きな変化がメジャーリリースです。大きな変化は、Windows 9x から Windows 2000 への移行で見たような「再設計」かもしれません。– これらの製品は似ていましたが、中身には大量の変更がありました。そのため、批評家やアナリストにとって、これは当然ながらメジャーリリースでした。大きな変化は、ユーザーインターフェースでの大きな変化でもありえます。なぜなら、それはたくさんの議論を促しますし、変化を表現するのは簡単だからです。けれども、このメジャーの定義は、肯定的には捉えられないこともあります。再設計は非互換の可能性を意味します。新しいユーザーインターフェースはすでに学び慣れ親しんだものからの移行を意味します。

私たちは、メジャーリリースのシンボルとして Windows の再設計について論じられているコメントを多く見てきましたし、私自身もそのような電子メールをたくさん受け取っています。また、私たちは、メジャーリリースがどのように過去のサポートを断ち切ったかについてのフィードバックもたくさん受け取ってきました。一般的には、もし私たちがそのようにすると、たくさんの他の大きな利益が付いてくるであろう – 再設計はよりよいパフォーマンスを、過去との決別はより少ないメモリ使用量をもたらす – と人々は言っていることが多いようです。これらのことについて議論するときはいつも用心しなければなりません。どうやって修正したらよいかわかっている箇所一つ一つのことと、もしかしたら新たな問題を引き起こしてしまうかもしれず結局修正できないようになってしまうかもしれない、という両方のことを、いつも比較検討しているのです。そのため、実装という点に関してメジャーリリースを定義するよりも、実装そのものがどうあれ、その利点ということに関してメジャーリリースの成功を定義する方が、より意味のあることだと考えています。この議論はこれからも継続させていただきます。たくさんお話があります。

鍵となるのは常にバランスです。もし、すべての必要な人々が変化に対応できるよう準備できるのであれば、すべての顧客に対して大きな変化を実現できるでしょう。正しいタイミングの正しい変化であれば、小さい変化でも大きなインパクトをもたらすことができます。そして、それはいずれメジャーリリースとして記録されるでしょう。

タイミングとチームの編成方法についてお話してきましたので、どんなときにWindowsの開発プロジェクトに対して“インプット”をしていけばよいか、おわかりいただけたと思います。私たちがよく耳を傾け、努力を正しく集中させれば、それぞれのタイプのお客様は製品の価値に気付いていただけると思います。そして、私たちが効率的に製品についてコミュニケーションしながら仕事をすれば、「問題」となるようなこともエコシステムのより広い意味で捉えられ、一部の人たちが大いに利益を得るときもあれば、あらゆる人がトータルで恩恵を享受するようになるかもしれません。

私たちの立場からすれば、Windows 7 クライアント OS を作り上げるために、Windowsグループのすべてのエンジニアチームとその膨大な時間をささげています。このことは、あらゆる定義において、メジャーな取り組みであることを示しています。私たちは Windows 7 を最高のリリースにするつもりです。

それぞれの種類の顧客にとってリリースがどんな規模であるか決定する際には、物の見方がすべてあることを理解していただけると幸いです。