皆様からいただく電子メールやフィードバックはほぼすべて、変化させるべきこと、もっと行うべきこと、もっと減らすべきことに関するものです。このブログでこれまで話題にしたように、それら各々について積極的な方法で行動をとることは、言うは易く行うは難しです。すべてのコメント、ブログの投稿、ニュース記事、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を使用するだけで、製品の向上を自動的に支援していただけることになります。システマティックに分析できるフィードバックデータを、ユーザーの皆様のお手を煩わせることなしに、自動的にレポートしていただいている、というわけです。以下にそのフィードバックの量がどれくらいのものなのかを示します。
私たちは、意思決定プロセスへの情報提供を支援する上で活用できる、さまざまなツールを持っています。Windows 7 において私たちがかなり注意を払った要素の 1 つは、決定を行う際のデータの役割です。製品開発とは最終的に無限の可能性から何を行うべきかを決定することであるため、私たちが行うことはすべて審判の判定のようなものです。しかし、このデータの役割は非常に明快であることが重要です -- データは、優れた判断の代わり、またはあるいは何とかして決定を行うための弁解とはなりませんが、最も明確に情報を提供します。これは、データが単にアンケートまたはフォーカス グループではなく、長年にわたって Windows を使用した何百万ものユーザーの「サンプリング」を含むようになった時代に特に真実です。
数年前に Office に取り組んでいたときのことをお話します。遠隔測定とインターネットの開発よりもずっと以前には、Officeにどの機能を入れるかを決定することは、戦いと表現するのがピッタリでした。戦いは会議室で始まり、基本的に 1 つ以上のグループが疲労 (精神的またはその他による) から降参するまで、議論が続きました。実質的にアドレナリン ベースの製品開発です。最後に残った人、最も耐久性のある人、または徹夜してコードを作成した人が、最終的に機能がどのようになるか、または最終的にどの機能が製品に入るかを決定しました。いわば機能設計を生存者に引き渡すようなプロセスでした。皆さんのうちの多くにとって、この種類のプロセスはきっとなじみのあるものでしょう。このアプローチの課題は多くありますが、必然的に機能は一致せず (シナリオまたはアーキテクチャの点から)、製品は統一を欠きます。そして最も重要なこととして、もし「勝利者」とターゲットとする顧客とが一致しなければ、多くの場合機能はしばしば的外れなものとなります。
1990 年代の初めに、私たちは Word をインストルメント化し、ユーザーがこのソフトウェアを実際にどのように使用しているかを調査し始めました (これはインターネットが使われる以前であったため、ボランティアのユーザーに実行してもらい、大量のフロッピーによってそのデータを収集した、特別バージョンの製品と言えました)。私たちはデータをコンパイルし、ユーザーがどの機能を使用したか、およびどの程度使用したかを知りました。私たちが学んだことの中には、考えていたよりも多くのユーザーが表を使用していたことがありますが、表とは非常に異なる目的のためにそれを使用していたのです。また、非常に長い間、スペリング辞書の最初の提案が正しい修正 (従ってオートコレクト) であったことを知りました。「新しい段落を始めずに改行だけを行うには、shift + return キーを押してください」などといった“今日のヒント”を、誰も読まないことも判明しました。このデータにより、何を修正すべきか、変更の影響、そして目標 (結果として生じる文書) を見たときに文書処理の進むべき方向性について真の決定を下すことができました。
Windows 7の開発に話を進めて、決定を下す際の情報提供を支援するデータの使用に焦点を当てます。このデータは多くの形をとり、また多くの方法で役立ちます。私は、このデータに関して疑問を持つ人が大勢いることを知っています。データは代表的なものとなるのか、ユーザーが使用すべきだが実際には使っていないものを修正するためにデータがどのように役立つのか、新しい機能を実行する上ではどうなのか、といった質問です。データは、決定を行う上での重要な要素ですが、明瞭な製品目標、意義深い顧客とのかかわり、および Windows 7 をユーザーに届けるためのエコシステム間の活動の代わりとはなりません。
「バグ」について少し話しましょう。まず、この多くの意味を付されたバグという用語について、私たちが同じ考えを持っていることを確認しておきましょう。私たちにとって、バグとは、予期していない何かをソフトウェアが実行することです。バグは、外観の問題、整合性の問題、クラッシュ、ハング、操作が成功しないこと、混乱を招くユーザー エクスペリエンス、互換性の問題、機能が失われること、またはソフトウェアが予期しない方法で動作するその他の多数の異なる現象の 1 つになり得ます。私たちにとって、バグとは主観的な用語ではなく、製品に対するフィードバックを表すデータベース エントリの単なる省略表現です。バグは、ユーザーによって、または Windows 7 に組み込まれたさまざまな形式の遠隔測定によっても報告されます。この広義の定義により、製品で経験されたすべてのことを追跡し、カタログ化すること、また一貫した方法でそうすることが可能になります。
決定に情報を提供する上で役立つデータのいくつかの例について、簡潔に検討してみましょう。
この種のフィードバックはすべて、組織的研究に基づいてデータが収集され、通常それに関連付けられた仮説を持つ、構造化されたフィードバックを表します。さらに、さまざまなバグ レポート、コメント、質問、およびブログ、ニュースグループや [フィードバックの送信] ボタンによって表された視点を表す非体系的なフィードバックもあります。後者は、系統だった方法で収集されず、あらゆる手段によって積極的に収集されているため、非体系的です。このフィードバックの 1 つの特別な形式は、Connect プログラム (テクニカル ベータ版) を介して行われるバグ レポートです。これは、このプログラムの参加者からのバグ レポート、機能の提案、およびコメントを表します。
Windows 7 Beta はこの点、前述したように、全体的なボリュームという意味で新たなレベルのフィードバックを頂くことができました。もしさかのぼって開発チームの規模と彼らがレポートを読むためにかかる時間を考えてみるなら、それらに回答することはおろか、問題点をただ消化する (分類し、理解し、フラグ付けする) だけで膨大な仕事となることが想像できるでしょう (開発者 1 人当たり 1 週間に約 40 の「フィードバックの送信」レポート。ご想像のとおり、それらがチーム間で平等に分配されることはありませんが)。
サイクル内のこの段階ですべてのフィードバックをどのように組み込むかという課題は非常に大きなものです。これは、Microsoft の私たちにとって感情的なことであり、またかなりのプライドと狼狽の原因でもあります。私たちはしばしば、「何が起こるとしても、必ず誰かはそうなるだろうと言った」と言います。この言葉の意味は、どのような問題点であっても、その解決法に関してすべての側に熱烈でかつ情報に基づく意見があり、それらはしばしば相互に対立し、それに加えて中間の意見も存在するということです。つまり、問題の大部分には、絶対的な意味での正解と間違いはなく、任意の状況のコンテキスト内での良い判断があるのみです。これは、機能がどのように動作すべきかに関する討論において、しばしば観察されます。複数のソリューションが提案され、ブログ上のコメントで討論が行われます (どのように機能すべきかについてブログ全体を費やす人さえいます)。しかし、Windows 開発チームでは、大勢のユーザーが Windows 7 の完成を期待していることを知っていますから、最終的に判定を下す必要があります。つまり、製品に手を加えるのをやめて出荷する必要があるのです。たとえ動作の変更は不可能であることがわかったとしても、私たちは常に正しい判定ができるわけではないかもしれません。
これらの決定を行うことは、プログラムマネージャー (PM) の仕事です。PM は、オフィスに閉じこもって意見を発信するようなことはせず、むしろより現実的にすべての事実、データ、意見を収集し、任意の状況に対する最良のアプローチを総合的に作り上げるよう働きます。プログラムマネージャーの役割は、ベータ テスター、開発、テスト、売り上げ、マーケティング、設計、カスタマー サポート、その他のチーム、ソフトウェア メーカー、ハードウェア メーカーなどを含むすべての意見が確実に聞かれるようにすることです。彼らの役割は、これらの意見を体系的に合成し表現することです。
任意の選択肢を理解する上で考慮すべき多くの要因があります。
これらは、製品変更を検討する際に考慮すべき要素のいくつかにすぎません。お分かりのように、これらは軽視できるものではなく、どの変更にも多くのことが関連します。私たちは、すべての意見を検討し、収集できるすべてのデータを考慮します。ある意味では、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