フィードバックと Windows 7 のエンジニアリング

皆様からいただく電子メールやフィードバックはほぼすべて、変化させるべきこと、もっと行うべきこと、もっと減らすべきことに関するものです。このブログでこれまで話題にしたように、それら各々について積極的な方法で行動をとることは、言うは易く行うは難しです。すべてのコメント、ブログの投稿、ニュース記事、MS Connect レポート、「フィードバックの送信」の項目、そしてもちろんすべてのデータおよび遠隔測定を、私たちは注意深く観察しています。この投稿ではまず、フィードバック プロセスの概要とともに製品に対して行われる変更についてディスカッションします。その後、特定の変更について簡単に説明し、数週間にわたる Release Candidate (RC) での変更についての話題に戻ります。すでに IE ブログ では、Windows 7 の IE 8 を更新することについて解説し、また一般的なフィードバック プロセスについても触れました。

Windows 7に関するフィードバックはもちろん、コードを作成するより前に開始します。また、コードを実行する頃までには、Microsoft 外部の何千人もの人々が意見を提供し、Windows 7 の機能セットおよび設計に影響を与えました。少数のユーザーからの意見でさえ、しばしばさまざまな選択肢 (多くの場合一致した、しかし同じくらい多くの場合対立した) を表す場合があります。Windows 7の機能開発にあたって、PC メーカー、企業ユーザー、および小規模ビジネス、教育、熱狂的な愛好家、製品レビュー担当者および業界の「ソート リーダー」 などに及ぶあらゆる種類のユーザーと緊密に関わります。この幅広いさまざまな意見に基づいて、リリースの全体的な「青写真」を形作ります。設計プロトタイプあるいはコードを実行する際、ユーザビリティ試験、概念テスト、ベンチマーク調査およびこの青写真の実装を検証するその他の技法などのツールの使用により、より対象を絞った、具体的なフィードバックを使用します。このレベルのフィードバックでの目標は、たとえすべてのユーザーと一対一で対話できないとしても、幅広い分野の Windows ユーザーの全体像を捉えることです。この投稿は、このプロセス全体 (ツールおよびテクニック、およびフィードバックの範囲) についての知識を提供するものになることと思います。

Windows 7 Beta の最初の数週間で、私たちは100万人以上のユーザーの方々にWindows 7をインストールして使用していただきました。これはベータ テストとしては驚異的な数字であり、多くの人々にとっては楽しい経験をしていただいたと考えております。私たちにとっては膨大な作業になりましたが、しかし Windows 7の品質を上げるために重要な作業を意味しました。ベータ版を使用していただく際には、ユーザーはカスタマー エクスペリエンス向上プログラム (匿名のフィードバックおよび遠隔測定。RTM リリースでは任意でのオプトイン) に自動的に登録させていただいています。ベータ テスターとしてWindows 7を使用するだけで、製品の向上を自動的に支援していただけることになります。システマティックに分析できるフィードバックデータを、ユーザーの皆様のお手を煩わせることなしに、自動的にレポートしていただいている、というわけです。以下にそのフィードバックの量がどれくらいのものなのかを示します。

• 1 月のピークの週に、私たちは丸 1 週間の間 15 秒ごとに 1 つの「フィードバックの送信」レポートを受け取っており、また現在までに合計 50 万通以上のレポートを受け取りました。これは平均するとすべての開発者がそれぞれ 500 以上のレポートに目を通したことになります。Windows 7 Betaをリリースしてわずか 6 週間しか経っていませんが、多くのユーザーにとって Windows 7 は既に旧友のようになっています。
• 現在まで、Windows 7 Betaの広範な使用により、私たちは数百通もの Connect (MSDN/Technet 参加のベータ版ユーザー) バグ レポートを受け取っています。また、これらの報告されたバグに対して、以前のどの Windows 開発サイクルよりも高い割合で、修正プログラムの作成がすでにプランされています。
• 現在まで、クラッシュまたはハングを引き起こした Windows コード (サード パーティー ドライバーまたはアプリケーション中ではなく) 中のほぼ 2,000 のバグに対して修正プログラムを開発作業中です。多くのベータ版ユーザーは Windows 7 の品質に非常に満足しているとおっしゃっていますが、広範囲にわたる大規模な使用によって経験された問題点を確実に修正することにより、品質をさらに向上させることに努めています。
• これまでに、1,000 万以上のデバイス インストールを記録しており、これらの 75% 以上で、Windows 7 に含まれるドライバー (ダウンロード不要) を使用することができました。残りのデバイスは、ほぼすべて Windows Update およびメーカーのWeb サイトへのダイレクト リンクからドライバーをダウンロードすることにより機能しました。280 万種類以上のプラグ アンド プレイのデバイスIDがWindows 7 上で使われていることを記録しました。
• 個人的なメモをもとにすれば、このブログを 8 月に開始して以来、私は世界中の人々から約 2,000 通の電子メール メッセージを受け取り回答しました。私はこのディスカッションの機会に本当に感謝していますし、すべてのメールに遅れずについていくために最善を尽くしています。

私たちは、意思決定プロセスへの情報提供を支援する上で活用できる、さまざまなツールを持っています。Windows 7 において私たちがかなり注意を払った要素の 1 つは、決定を行う際のデータの役割です。製品開発とは最終的に無限の可能性から何を行うべきかを決定することであるため、私たちが行うことはすべて審判の判定のようなものです。しかし、このデータの役割は非常に明快であることが重要です -- データは、優れた判断の代わり、またはあるいは何とかして決定を行うための弁解とはなりませんが、最も明確に情報を提供します。これは、データが単にアンケートまたはフォーカス グループではなく、長年にわたって Windows を使用した何百万ものユーザーの「サンプリング」を含むようになった時代に特に真実です。

数年前に Office に取り組んでいたときのことをお話します。遠隔測定とインターネットの開発よりもずっと以前には、Officeにどの機能を入れるかを決定することは、戦いと表現するのがピッタリでした。戦いは会議室で始まり、基本的に 1 つ以上のグループが疲労 (精神的またはその他による) から降参するまで、議論が続きました。実質的にアドレナリンベースの製品開発です。最後に残った人、最も耐久性のある人、または徹夜してコードを作成した人が、最終的に機能がどのようになるか、または最終的にどの機能が製品に入るかを決定しました。いわば機能設計を生存者に引き渡すようなプロセスでした。皆さんのうちの多くにとって、この種類のプロセスはきっとなじみのあるものでしょう。このアプローチの課題は多くありますが、必然的に機能は一致せず (シナリオまたはアーキテクチャの点から)、製品は統一を欠きます。そして最も重要なこととして、もし「勝利者」とターゲットとする顧客とが一致しなければ、多くの場合機能はしばしば的外れなものとなります。

1990 年代の初めに、私たちは Word をインストルメント化し、ユーザーがこのソフトウェアを実際にどのように使用しているかを調査し始めました (これはインターネットが使われる以前であったため、ボランティアのユーザーに実行してもらい、大量のフロッピーによってそのデータを収集した、特別バージョンの製品と言えました)。私たちはデータをコンパイルし、ユーザーがどの機能を使用したか、およびどの程度使用したかを知りました。私たちが学んだことの中には、考えていたよりも多くのユーザーが表を使用していたことがありますが、表とは非常に異なる目的のためにそれを使用していたのです。また、非常に長い間、スペリング辞書の最初の提案が正しい修正 (従ってオートコレクト) であったことを知りました。「新しい段落を始めずに改行だけを行うには、shift + return キーを押してください」などといった“今日のヒント”を、誰も読まないことも判明しました。このデータにより、何を修正すべきか、変更の影響、そして目標 (結果として生じる文書) を見たときに文書処理の進むべき方向性について真の決定を下すことができました。

Windows 7の開発に話を進めて、決定を下す際の情報提供を支援するデータの使用に焦点を当てます。このデータは多くの形をとり、また多くの方法で役立ちます。私は、このデータに関して疑問を持つ人が大勢いることを知っています。データは代表的なものとなるのか、ユーザーが使用すべきだが実際には使っていないものを修正するためにデータがどのように役立つのか、新しい機能を実行する上ではどうなのか、といった質問です。データは、決定を行う上での重要な要素ですが、明瞭な製品目標、意義深い顧客とのかかわり、および Windows 7 をユーザーに届けるためのエコシステム間の活動の代わりとはなりません。

「バグ」について少し話しましょう。まず、この多くの意味を付されたバグという用語について、私たちが同じ考えを持っていることを確認しておきましょう。私たちにとって、バグとは、予期していない何かをソフトウェアが実行することです。バグは、外観の問題、整合性の問題、クラッシュ、ハング、操作が成功しないこと、混乱を招くユーザー エクスペリエンス、互換性の問題、機能が失われること、またはソフトウェアが予期しない方法で動作するその他の多数の異なる現象の 1 つになり得ます。私たちにとって、バグとは主観的な用語ではなく、製品に対するフィードバックを表すデータベース エントリの単なる省略表現です。バグは、ユーザーによって、または Windows 7 に組み込まれたさまざまな形式の遠隔測定によっても報告されます。この広義の定義により、製品で経験されたすべてのことを追跡し、カタログ化すること、また一貫した方法でそうすることが可能になります。

決定に情報を提供する上で役立つデータのいくつかの例について、簡潔に検討してみましょう。

• カスタマーエクスペリエンス向上プログラム。 CEIP は、匿名、非公開、またはオプトインで Microsoft に提供される、あなたの PC 上で収集されたデータを対象とします。ベータ版では、先に述べたように、これは既定に設定されます。製品版では、もちろんこれはオプションです。ベータ版の使用期間中に、新機能の使用率、ユーザーが製品をカスタマイズする部分、使用されるコマンド、および Windows 7 が一般的に使用される方法についてのデータを検討します。これまで、Windows Vista からのこのデータの一部 (たとえば使用されるディスプレイ解像度またはコンピューター上のアカウント数など) が、Windows 7 の機能に情報を提供したことを私たちが話題にしたのをご存知でしょう。製品には、多数の測定するデータ ポイントがあります。実際、開発サイクルの重要な部分の 1 つは、ベータ期間中およびその後も使用率について情報を提供するよう、新機能が十分にインストルメント化されていることを確かめることです。
• 遠隔測定。 プログラム的には CEIP に関連していますが、ここではやや異なった視点で遠隔測定をとらえます。これについては、High DPI のサポートのディスカッションのような、パフォーマンスまたはデバイスの多様性について私たちが話題にする仕方から既に理解されているでしょう。ベータ版の期間全体にわたって、私たちは、起動時間がどのように経過するか、またはどのデバイスが正常にインストールされるか、されないかを確認できます。どのバグを修正するかについて情報を提供してくれる遠隔測定の重要な要素は、どれほど頻繁にクラッシュまたはハングが生じているかということです。私たちは、高レベルの問題を引き起こしているソフトウェア、および問題点に取り組む方法を知っている正しいチームまたはソフトウェア開発元を特定することができます。遠隔測定を使用すると、変更の利点に注目することができるようになります。何千人もの顧客の意見を代表するバグ、広く使用されるデバイス、または幅広く使用されるサード パーティーのソフトウェアを修正することは、たった数人が報告するバグ、数の少ないデバイス、またはあまり使用されないソフトウェア製品よりも、はるかに大きな影響を及ぼします。このデータにより、私たちはより正確に変更の利点を評価することができます。
• シナリオベースのテスト。 機能開発の期間中、私たちは設計およびプロトタイプ (コード、ペーパー、またはビットマップ) を選んで、ユーザーが機能/シナリオを解釈および評価する方法について、構造化されたリサーチを行うことができます。たとえば、Windows 7 計画の初期に、私たちはタスク バー拡張機能の完全に機能するプロトタイプを作成しました。このプロトタイプによって、私たちはさまざまな種類のユーザー (スキル レベル、Windows の異なるバージョンの使用経験があるかどうか、競合製品のユーザー、IT プロフェッショナル、またはエンド ユーザー) について、およびそれらのユーザーが十分定義された一連の「タスク」にどのように反応するかを調べることができます。これにより、たとえば機能に関するより詳細な研究が可能になります。すべてのテストと同様に、これらはより広範囲のコンテキストにおける優れた判断の代わりとはなりませんが、決定に情報を提供する重要な要素となります。
• ベンチマーク研究。 プリベータ版に移行した際、実世界のシナリオで実際のコードによって Windows 7 の検証を始めることができるよう、私たちは製品全体にわたって実際のコードを使用しはじめました。私たちはこの研究をベンチマークと呼んでいます。というのは、しばしば私たちは以前のバージョンの Windows の基準に比較して新製品のベンチマーク テストを行うからです。たとえば、ホームのプリンターを共有するのにかかる時間を観察し、次にその時間を HomeGroup を使用した Windows 7 テストによる完了/成功率と比較することができます。無線LANの設定を容易にするWPA を使用した場合と使用しない場合のセットアップを比較することもできます。私たちは、このようなベンチマークを多数行い、これまでに遂げた進歩と、今後ドキュメント、チュートリアル、またはその他の形式のアシスタンスを向上させる必要がある分野の両方を確実に理解するように努めます。

この種のフィードバックはすべて、組織的研究に基づいてデータが収集され、通常それに関連付けられた仮説を持つ、構造化されたフィードバックを表します。さらに、さまざまなバグ レポート、コメント、質問、およびブログ、ニュースグループや [フィードバックの送信] ボタンによって表された視点を表す非体系的なフィードバックもあります。後者は、系統だった方法で収集されず、あらゆる手段によって積極的に収集されているため、非体系的です。このフィードバックの 1 つの特別な形式は、Connect プログラム (テクニカル ベータ版) を介して行われるバグ レポートです。これは、このプログラムの参加者からのバグ レポート、機能の提案、およびコメントを表します。

Windows 7 Beta はこの点、前述したように、全体的なボリュームという意味で新たなレベルのフィードバックを頂くことができました。もしさかのぼって開発チームの規模と彼らがレポートを読むためにかかる時間を考えてみるなら、それらに回答することはおろか、問題点をただ消化する (分類し、理解し、フラグ付けする) だけで膨大な仕事となることが想像できるでしょう (開発者 1 人当たり 1 週間に約 40 の「フィードバックの送信」レポート。ご想像のとおり、それらがチーム間で平等に分配されることはありませんが)。

サイクル内のこの段階ですべてのフィードバックをどのように組み込むかという課題は非常に大きなものです。これは、Microsoft の私たちにとって感情的なことであり、またかなりのプライドと狼狽の原因でもあります。私たちはしばしば、「何が起こるとしても、必ず誰かはそうなるだろうと言った」と言います。この言葉の意味は、どのような問題点であっても、その解決法に関してすべての側に熱烈でかつ情報に基づく意見があり、それらはしばしば相互に対立し、それに加えて中間の意見も存在するということです。つまり、問題の大部分には、絶対的な意味での正解と間違いはなく、任意の状況のコンテキスト内での良い判断があるのみです。これは、機能がどのように動作すべきかに関する討論において、しばしば観察されます。複数のソリューションが提案され、ブログ上のコメントで討論が行われます (どのように機能すべきかについてブログ全体を費やす人さえいます)。しかし、Windows 開発チームでは、大勢のユーザーが Windows 7 の完成を期待していることを知っていますから、最終的に判定を下す必要があります。つまり、製品に手を加えるのをやめて出荷する必要があるのです。たとえ動作の変更は不可能であることがわかったとしても、私たちは常に正しい判定ができるわけではないかもしれません。

これらの決定を行うことは、プログラムマネージャー (PM) の仕事です。PM は、オフィスに閉じこもって意見を発信するようなことはせず、むしろより現実的にすべての事実、データ、意見を収集し、任意の状況に対する最良のアプローチを総合的に作り上げるよう働きます。プログラムマネージャーの役割は、ベータ テスター、開発、テスト、売り上げ、マーケティング、設計、カスタマー サポート、その他のチーム、ソフトウェア メーカー、ハードウェア メーカーなどを含むすべての意見が確実に聞かれるようにすることです。彼らの役割は、これらの意見を体系的に合成し表現することです。

任意の選択肢を理解する上で考慮すべき多くの要因があります。

• それは何を行うことを予期されているか。 最上位レベルでは、尋ねるべき最初の質問はある機能がどのように動作することを予期されているかということです。時には完全に壊れている場合もあります。このことは、たとえばクラッシュとハングに関する大量のベータ版の問題点からわかります。しかし、これらについて盛んに討論が行われることはありません。というのは、意味のある頻度で (遠隔測定に基づいた) クラッシュが起きるなら、それは修正すべきだからです。もしあなたがクラッシュを経験したなら、それはあなたにとって「絶対修正が必要」な機能であることを私たちは理解していますが、私たちはユーザー全体を対象とし、クラッシュの頻度および問題を引き起こすコードが Windows に存在するか、またはハードウェア メーカーから提供されるドライバーあるいはサード パーティー製ソフトウェアに問題が存在するかを調べます。これらすべてに検討するべき潜在的な解決経路があります。ユーザー操作に関して言えば、「予期される動作」には 2 つの要素があります。最初は全体的なシナリオ目標で、次にその機能が行うべき動作に関して異なるエクスペリエンス (見解) を持つ異なるユーザーによるフィードバックです。たとえば、HomeGroup およびパスワード/パスフレーズについて話題にしたとき、これがどのように機能すべきか (部分的にはこのフィードバックに基づいて私たちが微調整する領域) に関して多数のフィードバックがありました。私たちにはもちろん仕様とプロトタイプがありますが、開発プロセスには流動性もあるため、製品の実動前に 100% の再現性はありません (多数の決定をゼネコンが行うようにするか、または建設中に行われるように残す建築の設計図と同様)。さらに、機能は完成しており、あとはエクスペリエンスを「磨く」途上にあるという領域もベータ版には常に存在します。
• どれほどの利点があるか。 たとえばある機能が現在とは異なった仕方で動作するべきであると決定するとします。そうするなら今までの 2 倍も良くなるでしょうか。それとも 5% 程度良くなるでしょうか。誰か気付くでしょうか。これは常に討論の最大の争点の 1 つになります。もちろん、変更を主張する人は、その変更によって機能が「うまく働かない」状態になることを防ぐだろうと、または「これを変更しないならその機能は動作しない」と常に確信しています。たとえば（機能の）「発見可能性」に関連する領域でこのことがよく観察されます。人々は何かを修正する方法として何かを中心に置きたがるのです。また、「構成可能性」の多数の提案もあります。もちろんこれらは両方とも、短期間の利点を持っています。しかしどちらも、構成、レガシー ユーザー インターフェイスなどの点で今後複雑さを増大させます。多くの場合、より幅広いコンテキスト (ある機能が任意のユーザーによってどれほど頻繁に実行されるだろうか、またはどれほどの割合のユーザーがその変更を活用するだろうかなど) で利点を考慮することは重要です。社内では、「誰だってこうする!」と即座に決めつける人を見るのは珍しいことではありません。
• 変更はどれほど大きいか。 製品サイクルの初期に、私たちは、新しいコードの追加、再設計、および移動など、コードに大量の変更を加えます。私たちはもちろん行き当たりばったりにそうする訳ではありませんが、実際のところ、サイクルの初期には、大幅に変更されたコードとその後生じる関連する回帰のプロセスを処理するための時間があります。プロジェクトが進行するにつれて大きな変更を行うためのコストももちろん上がることを知っているので、機能の仕様と明確なビュー (シナリオ計画、プロトタイプなど) を作成します。大規模システムに対してサイクルの遅い段階で大きな変更を行うことは、時間がないためコストが増大するだけでなく、安全なエンジニアリングでもありません。それで、変更を検討する際には、システム全体に対する影響を理解するために、その変更がどれほど大きいものであるかも考慮する必要があります。変更は、コード数の点から大きいものとなる場合があり、多くのコードには常に危険があります。しかし多くの場合、変更は行数の問題ではなく、コードが接続される場所の数です。そのため、変更が単純な「if」ステートメントのように聞こえても、しばしばそれよりもずっと複雑になります。ここ何年にもわたって多くの人々により、変更の影響を軽減するためにコンポーネント化およびその他のシステム工学上の方法が語られてきましたし、もちろん Windows は非常に階層状のシステムです。しかし現実には、よく階層化されたシステムであっても、ある人が最下層で変更を行い、その結果として後続の上層部に動作が引き継がれることはないだろうと仮定することはあり得ません。この「防御」は、互換性、安定性、パフォーマンスおよび信頼性を維持するために開発プロセス全体にわたって私たちが一貫して保つ姿勢です。
• 利点に対して変更はどれほどコストがかかるか。 変更とは、何かが異なることを意味します。したがって、私たちが何かを変更するなら、常にユーザーがそれに対応する必要があることを意味します。多くの場合私たちが行う変更は計画的なもので、この例はユーザー インターフェイスやドライバー モデルなどに見られます。新しいものが計画的な場合、ユーザーは準備することができ、私たちは移行を支援するツールを提供できます。私たちは、変更のコストに対応する新機能に関する多くのコメントを見てきました。多くの場合、これらのコメントは利点に依存せず、変更自体に注目するものです。この種の対話は、変更それ自体は常に良いものではないことを明らかにします。多くのバグ レポートで、「これは Windows の 3つのバージョンにわたって存在しており、Windows 7 では修正しなければいけない」という意見を耳にします。Windows の多数のリリースにおいて、システム内、とりわけ API、メッセージの順序およびセマンティクス、またはインターフェイスにおける動作は理想的ではないかもしれませんが、それらを変更するなら、変更の利点を上回る複雑性、非互換性、および問題をもたらすことを私たちは学んできました。一部の人はこのような決定は「私たちを押しとどめる」ものとみなしますが、しかしそのような変更は過去の 1 日からの解放となるよりは、解放が必要となる新しい過去を創造するだけとなることでしょう。既存の動作は、それが API であってもユーザー インターフェイスであっても、私たちが持つコントラクトを定義します。また、システムの他のすべての側面と同様に、異なるユーザーにはこの「方程式」の異なる見方があることを理解しつつ、コストと利点についての汎用的な見方を持つことは、リリースの構築の不可欠な要素です。
• リリース全体のコンテキストでは、この問題点はどれほど重要か。 現実には、リリースのより広範囲の目標のコンテキストにおいて、すべての決定を下す必要があります。リリースはそれぞれ、そのリリースを定義する一連のコア シナリオおよび原則を表わしています。当然ながら、それは各リリースにおいてあるものは他のものよりも変化し、あるものはまったく変化しない可能性があることを意味します。言い換えると、システムの一部は一連の目標に向かって積極的に取り組みがなされる一方、システムの他の部分はリリースにまたがってほぼ「安定した」状態に保たれます。これはつまり、あなたが変更してほしいと望んでいるものが、Windows 7 で私たちが調整しない製品領域であるために、変更されない場合もあることを意味します。前述したように、Windows 7 については、システム パフォーマンスのさまざまな要素のチューンアップに多くの労力を費やしました。明白なシナリオ計画および測定に加えて、私たちは、さらに前進するために変更する必要のあったシステムの領域を大変重要視しました。同様に、パフォーマンス向上が変更を指示するほど顕著ではないシステム領域では、大幅な変更を行いません。私たちは、データと遠隔測定を受け取りつつ、今後もサイクル全体においてこの方針を保ちます。
• 変更はセキュリティ、信頼性、パフォーマンス、互換性、ローカライズ、ユーザー補助、プログラマビリティ、管理性、カスタマイズ性などにどのように影響するか。 その変更が Windows にもたらす「機能」のリストは大変重要です。開発チームのメンバーは、これらの機能のすべてをもたらす上でトレーニングと情報を継続的に受け取っているため、製品全体で良い仕事を行うことができます。さらに、これらの機能の多くについて、その機能を実現し、私たちが製品全体で良い仕事を行うことを確実にするためにフルタイムで働く専属チーム メンバーがいます。これらの機能すべてに対する変更要望と実際の変更のバランスをとることは、それ自体が重要な仕事であり、調査の重要な要素です。しばしば、別の機能と対立する、ある機能に非常に集中した投入を見ることがあります。たとえば、カスタマイズを提供するための変更を行うのは簡単ですが、この変更は、管理者、エンド ユーザーおよび PC メーカーにとってもカスタマイズ可能でなければなりません。そのような複雑性は、PC の使用率、導入や運用、管理のさまざまな異なるシナリオに内在するものです。この種の影響を考慮する最大の領域は、「製品にこれまでずっと存在した」動作への変更する場合です。しばらく前に行われた独断的な決定が、サブシステムの特性を維持するためにそのままにして置かれるのが良い場合もあります。古い選択肢を新しい実装で置き換えることは、人々が変わってほしいと願うもののクロックをただリセットするだけだと言うことを私たちは知っています。なぜなら、ニーズは変化し、考え方も変化し、人々も変わっていくからです。

これらは、製品変更を検討する際に考慮すべき要素のいくつかにすぎません。お分かりのように、これらは軽視できるものではなく、どの変更にも多くのことが関連します。私たちは、すべての意見を検討し、収集できるすべてのデータを考慮します。ある意味では、Windows 7 をリリースするために私たちが行わなければならない決定について考えすぎることを止める方が簡単です。なぜならあるものに依存する 10 億人のユーザーの一人ひとりについて心配し始めるかもしれず、それは非常に厄介になるからです。それで、私たちはデータを使用して、自分自身を客観的に保ち、意志決定プロセスに常に情報を提供し、それを反復可能にします。私たちは、常に自分たちの持つ責務によって謙虚にさせられます。

この投稿を書いている間、私は「山のような問題があるにもかかわらず、Microsoft はこの問題を避けようとしている」というはっきりした宣言とともに、お決まりの「Microsoft は絶対にフィードバックに耳を傾けない」というコメントの付いた「バグ レポート」電子メールを受け取りました。このような電子メールを受け取るのはつらいことです。開始する前から面目丸つぶれです。送信者は、このレポートが Microsoft の無力さ、または重要なフィードバックを取り入れ、開発時に修正が絶対必要なバグを修正する願いの欠如を象徴的に表すとお考えになられたのでしょう。Microsoft も、適切な製品を出荷することに注力しています。人々が探し求める唯一の答えが修正であり、それ以下であれば問題か、あるいは、私たちの怠慢のさらなる証拠と見なされるため、私はお手上げのように感じます。たまたま今は1 つの問題点をお持ちの1 人のユーザーの方とメールでお話できていますが、現実的にはベータ版を使用しているユーザーは数百万人いらっしゃいます。もしその一人ひとりに、あるいは 10 人のうち 1 人だけにでも、特別な変更、バグ修正、または絶対必要な作業項目を実施するとして、そのリストに目を通すだけで、、、文字どおり数年間がかかるでしょう。また、数に目を向けて、1 つの製品サイクルでの優に 100 万件の新しい「作業項目」が提出されることを考えると、もし私たちがそのうちの 10 万件を実行したとしても、10 万人のユーザーは自分たちの意見が聞いてもらえたと感じますが、残りの 90 万人のユーザーは耳を傾けてもらえないと感じることになります。おそらくこのことも状況を難しくしています。

この投稿では、私たちが受け取るフィードバックについて検討するいくつかの方法と、Windows 7 の開発時にどのようにフィードバックを評価するかについて考えてきました。エンド ユーザー、開発者、IT プロフェッショナル、ハードウェア メーカー、PC メーカー、シリコン パートナー、ソフトウェア メーカー、PC マニア、システム管理者など、これほど大勢の人々のニーズ (および要望) のバランスをとることほど複雑な領域はありません。私たちが自分たちのアプローチを、「ユーザー」の複数の代表的なグループのために計画的に選択されたデータと調査によって増強する主な理由は、それが「多数の専制」または「群衆による支配」を避けるために重要であるからです。ある意味では、私たちがアドレナリン ベースの開発から学んだ教訓は、データの使用において系統的、代表的、そしてできる限り科学的であることでした。

フィードバックに対して責任を持って対応し、プロセスのすべてのフェーズで Windows の開発を管理することは、私たちが非常に真剣に取り組んでいる仕事です。組織としてどうしたら学習し続けていけるか、どうしたらより良い仕事を行い成果を向上させることができるか、そして Windows をさらに改善する方法をどのように学び続けるべきか、ということについて私たちは社内で大いに語り合ってきました。製品開発に携わる人なら誰もが考えていらっしゃるように、私たちもこれからずっと難しい選択をし続けなければならないことを理解しています。そして、使える限りすべての手段を使って、最良の Windows 7 を構築すること。それが私たちのコミットメントです。

--Steven