Windows 7 での ClearType の技術的な変更点

Bill Gates が持っている数多くの情熱のうちの 1 つは読むことであり、PC 上で読むことを快適なエクスペリエンスにするという彼の望みは、長年にわたり続けられてきた取り組みです。1998 年の COMDEX で、Bill Gates は ClearType を発表しました (こんなにも昔のことだったなんて、信じられません)。発表時、LCD モニターを持っていた人はごくわずかで、15 インチの 1024×768 モニターが数千ドルもしました (今だと 100 ドルもしないようなもの)。スムージングやアンチエイリアシングという概念はずいぶん前から存在しており、タイポグラフィ (文字体裁) やアニメーション、ゲームの世界では一般的なものです。ClearType は LCD パネルの特性を基盤として、これを新たなレベルに引き上げました。ClearTypeはその後 Windows XPに搭載され、Vista と Windows 7 にも引き続き入っています。リリースごとに、基礎となるテクノロジー、それをサポートするフォント、および開発者が利用できる API が変更されてきました。ユーザーの中には、ClearType で表示した画面をそれほど良いと思わず、この機能を無効にしたいと考える人々もいることが長年の間に判明しています。私たちはこれを認識しており、適切なコントロールを提供できるようにしたいと考えています。ClearType は Windows プラットフォームの一部でもあり、アプリケーションの開発者が呼び出してコントロールできる API を提供しています。ClearType は「視覚的な好み」であるという従来からの見方があり、この投稿でも好みと言える一面があることを紹介したいと思います。しかし、アプリケーションによって使用される API であるという一面、つまり、アプリケーションが必要に応じてフォント、色、その他の属性を選択できるのと同じである、ということについても説明したいと思います。この投稿では、歴史や背景を交えながら Windows 7 での実装の詳細に踏み込んで説明します。Greg Hitchcock は ClearType の開発リーダーで、開発当初から担当しています。 また、Windows 7エンジニアリング チームで在職期間が最も長いメンバーのうちの 1 人です。彼より…


Windows 7 グラフィックス パフォーマンスのエンジニアリング

Windows 7 グラフィックス パフォーマンスのエンジニアリング 最高の CAD やゲーム グラフィックスなどデスクトップ グラフィックスのパフォーマンスは、Windows 開発の中でかなり多くのテストと調査が実施される分野の1つです。Windows をサポートする幅広いハードウェアとさまざまな利用シナリオは、基本的なフレーム レートからマルチ モニターでの最高のフレーム レートまで、さまざまな目標を持つエコシステムに役立ちます。Windows 7 の設計では、グラフィックスの最先端の要素を向上させる努力を続けると同時に、「実世界」のグラフィックスのパフォーマンスを向上させることを目指しました。当社のパートナーがドライバーを介してプラットフォームとなるハードウェアとソフトウェアの組み合わせを向上させるようとしています (注: Windows Vista ドライバーは、Windows Vista で機能したように機能し続けますが、Windows 7 用にドライバーを更新することにパートナーとともに取り組んでいます。これらのドライバーは、ユーザーの多くが Windows Update 経由でダウンロードしてテストしてきました)。この投稿では、広範な設計とパフォーマンスを測定するさまざまな方法について見ていきます。そして最終的に、異なるハードウェア上でさまざまなシナリオにより Windows 7 を比較テストしているみなさんに検討の余地を残しながら、Windows 7 の設計で実施した内容について報告します。この投稿は、デスクトップ グラフィックス機能チームのプログラム マネージャー、Ameet Chitreによって書かれました。–Steven 新しい PCの購入を考えるとき、「より高速なグラフィックス」や「卓越したパフォーマンス」は常に重要なアピール ポイントとなります。写真を編集し、電子メールを実行し、高解像度ビデオを見て、最新の 3D ゲームをプレイする、これらすべてのタスクをシームレスに簡単で頻繁に行き来できる、そんなより高速なシステムをユーザーは期待しています。そのようなユーザーの多くは、グラフィクス ベンチマークを実行するマニア的なコミュニティ ブログやさまざまなレビュー サイトを参照し、新しいハードウェアまたはソフトウェアのグラフィクスの実行速度を評価して結果を報告しています。従来、グラフィクス パフォーマンスは、3Dゲームを通して測定および分析されましたが、Windows の UI を使い、ウィンドウを移動または最大化する、Word または IE などでスクロールする場合など「デスクトップ シナリオ」と呼んでいるものにも影響を与えます。これらのデスクトップ シナリオのパフォーマンス要件は、3D ゲームとはまったく異なります。実際、これが、Windows Vista エクスペリエンス…


Windows 7 でのタイポグラフィーとテキスト・レンダリングの進歩

PCで画像とビデオを観ることは非常に普及していますが、私たちの多数は大部分の時間をテキストを見て対話することに費やしています。私たちはテキスト表示品質向上のためのテクノロジーを追求していきます。この領域では引き続き、ディスプレイ、グラフィックス カード、そして開発者が利用できる API レベルで、向上したテクノロジーを活用することができます。Windows 7 では、GDI でのテキストとフォントのサポートを、互換性とアプリケーションのサポートの基礎として引き続き提供します。現代の DirectX グラフィックス インフラストラクチャの基礎に基づいて、Windows 7は Direct Write を使用して開発者が利用できるテキスト出力を拡張します。これは新しい API サブシステムで、Microsoft やソフトウェア開発者のアプリケーション、および Windows 自体でも、より長期にわたり広く採用されることでしょう。この投稿では、Clear Typeとフォントの向上点に (両方ともGDI ベースのテキスト API の向上点の部分として利用可能)関しても取り上げます。この取り組みは PDC (投稿の下記を参照のこと) で紹介されました。この投稿は Walachia Chaoweeraprasit (私たちのグラフィックス フィーチャー チームの開発リーダー) によるものです。 –Steven Windows 7 の大きな目標の 1 つは、より優れたグラフィックス、より高い忠実度を備えたグラフィックスを用意することでもあります。この目標に向かい、私のチームは、Windows で最も基本的なグラフィックの要素のうちの1つ、つまりテキストを向上させる方法を研究しています。テキストは常に目の前にありますが、気にならないほど自然な存在であって欲しいと思います。 よいテキストの必要性 ユーザーは PC の使用において約 80% を読み書きに費やします。コンピューターは実質的にユーザーにテキストで対応するため、これは驚くべきことではありません。コンピューターが人間の脳へ直接考えを伝えられるようなテクノロジーを持つまでは、テキストが引き続きコンピューター画面から情報を受け取る方法です。 研究によると、よいテキストはより高い生産性につながります。私たちは人間として、実質的に単語をキャプチャーし、それらの間を信じられないほど滑らかに、そして迅速に移行することが得意です。それが、読み取りのベースとなっています。私たちはその能力に非常に長けており、テキストがそのプロセス用に最適化されていれば、それらは信じられない速度で、しかも無意識に行うことができます。なぜ多くの人が本を短時間でさっと読むことができるか、またコンピューター画面をしばらく凝視した後すぐに疲労してしまう人がいることを、これによって説明できると思います。しかし、読み取りプロセスを妨げるようなあらゆる視覚的な関連要因が、実際に私たちの読み取り速度を遅くします。したがって、よいテキストとは可能なかぎり注意をそらす要因が少なく、ユーザーの読み取りプロセスをサポートするために調整されたテキストです。 各文字、単語、行および段落を囲む白地の均等さは、読み取りのペースを保つために非常に重要な役割をはたします。一方、黒い要素は、私たちの注意を集中させます。長すぎる行、詰まった単語、不均等な段落、およびこのような条件は、読んでいるメッセージからますますユーザーの注意をそらし、それを伝える単なるメディアにどんどん注意を向けさせます。テキスト アートとは実質的に、テキスト自体は目の前から消え、その結果、それが伝える考えがあなたの頭の中で再生させることです。適切なテキストを準備する方法に関する研究は、タイポグラフィーとして知られています。また、タイポグラファーが言うように、よいタイポグラフィーは“見ることができない”のです。よくないものだけが見えます。プラットフォームとしての Windows の役割は、優れたテキストのプレゼンテーションの提供、およびソフトウェア開発者向けに、開発しているソフトウェアのコンテキストで可能な最良のプレゼンテーションを作成するための優れたツールを提供することです。 現在の技法の向上 ユーザーは習慣によって行動する傾向があり、しばしば時間とともに、これらの習慣は優先的な方法になります。その行動がありきたりであるほど、私たちはより容易にその習慣にとらわれてしまい、それを変えるのがより困難になります。スクリーンのテキストに関していうと、ユーザーは一日中同じ画面を見ています。それが一夜にして完全に変化すると、たとえそれがよい方向への変化であっても、即座に厄介なことになるかもしれません。そうなると、ユーザーがそれほど使い慣れたものを、私たちはどのように向上させられるでしょうか。私たちは確実に、そこにあるものをサポートし、また既存のメソッドをサポートしながらそれを向上させたいと思います。しかし、向上点を理解する前に、最初に現在の実装、およびこの数年にわたって存在している課題をより詳細に見ていきましょう。 現在の実装はデバイス ピクセルに基づいたテキスト…


High DPIについてのさらなるフォローアップ

素晴らしい!非常に面白い High DPI の議論です。Ryanの書いた summary によって議論はますます白熱してきています。ありがとうございます!–Steven いくつかの白熱した議論とともに、High DPIに対する多くのコメントが寄せられています。それらの多くは、我々が収集してきたデータと一致する、よい例になっています。私たちがデータを持たない分野に対して、これらのコメントは私たちの持つ多くの仮説を裏付けとなっています。もう一つ明らかになったのは、この機能の一部について誤解があり、またこの機能の理想、可能な事、機能そのものに対してある種の「神話」のような部分も見受けられます。この記事では主にそれら問題の要約と、誤解と思われる部分についての詳細を提供したいと思います。 以下はコメントにて裏付けられた私たちの「仮説」です。 ほとんどの人は画面解像度を、文字を大きくするため、またはただの偶然でのみ調整している 一部のコアユーザだけがhigh DPIを知っていて、使用している 一部の人は画面の広さを好み、他の人は大きなUIを好む 一部の人はDPI設定の見つけやすさに対して懸念を持っている アプリケーションの互換性は大きな問題で、一部の人はこれによってこの機能を利用しない IEでのスケーリングはもっとも大きな問題である(IE8をご覧になって多くの修正を確認してください) 多くの複雑かつ微妙な理由で、この機能を多数の人々に説明するのは困難である また、以下のような混乱もあります。 もし全てがベクターベースであったら、これらの問題は全て解決するのか? 開発者が何もしなくても、これらの問題は解決できないのか? アプリケーションによるスケーリングとIEでのズーミングはどう違うのか? DPIは調整の為に必要、それともスケーリングか? いくつかのトピックについてはコメントでお応えしていますが、これらに対しては関心が高いので、ここで詳細を述べることにしました。 ベクターグラフィックス vs. ラスターグラフィックス PCにおいて、全てのユーザー、開発者、デザイナーのあらゆるすべての問題を一気に解決する「銀の弾丸」の様な技術がいつも望まれています。それは例えば、この議題の最初記事に対するいくつかのコメントにあったように、もしOSを全てベクターグラフィックスをもとにすればこのスケーリングに関する問題は全て解決するというものです。実際にはすべてをベクターグラフィックスにした場合、いくつかの問題があります。 最初の問題は、アイコンを小さくする時には意味を分かりやすくする為に別の表現方法を用いる方が良い時があるということです。以下のアイコン群を見て下さい。この場合、デザイナーは一番小さなアイコンのデザインでは遠近法を無視したデザインを採用しています。   この理由ですが、最も小さなアイコンサイズでは、アイコンによって表現される情報は真正面から描いた方がより判りやすい、とデザイナーが感じたからです。このイラストは、この点に関するもう一つの例です: 当然これにより、デザイナーは複数バージョンにイメージデザインを制作しなくてはならず、複雑さは増します。ここでのポイントは、トレードオフが必ず発生し、かつ、そのトレードオフが必ずしも明確にはなっていない事です。 もし、一つのベクターベースのデザインを使用したとしても、デザイナーが思い描いている物を忠実に表わす為に、サイズに依存した微調整が必要である事は共通です。1ピクセルの線で描かれた 128x128サイズのベクター画像を、1/2サイズの64x64に縮小する事を想像してみてください。完璧に1/2ピクセルの線をディスプレイで再現する方法はありません!多くの場合、この点に対する方法として、描画処理は近似した線への“丸め”を行います。しかしながら、この処理を行うと、画像イメージの他の要素のレイアウトが根本的に変更されてしまいます。また、”どの線を丸め処理の対象とするか?”といった疑問もあります。デザイナーが、原版を手動調整していなければ、レンダリングエンジンがその決定を行います。そしてこれが、好ましくない描画結果の要因となります。そこで、どの要素をベクターで使用すべきかのルールを定義すべきである、とよく言われます。しかしそれは、表現可能なコンセプトについて更なる制約を加えてしまうだけです。 Windowsで私たちが使用しているTrueTypeフォントでさえも、その描画結果を可能な限り高品質にする為に、サイズ毎に手動で調整を行っています。TrueTypeのレンダリング パイプラインのほとんどは、アルゴリズムに基づいてベクターソースをスケーリングする事を基本にしていますが、TrueTypeの中には、サイズ毎の“ヒント”が手動でコーディングされています。これはデザイナーが、ある特定の稀なケースをシステムがどのように対処するかを指示する為のものです(例えば、ピクセルの境界にある線をどう対処するか、等)。この点に関するより詳細な記述はこちらをご参照ください: http://blogs.msdn.com/fontblog/archive/2005/10/26/485416.aspx ベクター画像が、必ずしもより小さなサイズになるという訳ではありません(特に小さな画像)。ほとんどのデザイナーは、描画や画像効果用に多くの複数レイヤーを構成してイメージを作り出すエディタを使用して画像を制作します。ビットマップをベースにした画像では、デザイナーはそれをソフトウェアの一部に追加する前に、予めレイヤーを“フラット化”します。昨今のほとんどのデザイナーは、レイヤーのサイズに対してほとんど気を使いません。なぜなら、フラット化のプロセスでは 基本的にはイメージの解像度に基づいた固定サイズへ変換が行われるからです。ベクター画像には、こうしたフラット化の技術はありませんので、アイコンが大きくなり過ぎない様に、デザイナーは使用するツールと、施す画像効果について慎重に考慮する必要があります。私はWindowsのビットマップのデザイナーが持っているベクター画像の元データを見せてもらいましたが、それは622kでした。もちろん、それは解像度に依存せず同じファイルサイズです。しかし、その巨大なファイルは23kのPNGのビットマップ画像にフラット化されます。 画像作成の工程でサイズの制約事項があったならば、この手動調整を施したベクターベースの画像も小さくなっていたでしょう。しかし、その制約事項はデザイナーへ対する追加の制約事項となったはずですし、その制約事項にうまく対処する方法をデザイナーが学習する必要があったでしょう。 開発者の方々のために レイアウトやグラフィックを微妙に調節したり、解像度にあわせてイメージの正確にスケールする必要のあるアプリケーションが最良の結果を出すには、アイテムのピクセル位置を正しく指定することが重要です。これは Mac でも、PC でも変わりありません(http://developer.apple.com/releasenotes/GraphicsImaging/RN-ResolutionIndependentUI/ を参照)。適切なツールやフレームワークが提供されていれば、そんな心配はいらないはずだという意見もあります。しかしこうしたツールセットやフレームワークにはそれぞれのトレードオフが存在しています。(それがWin32であっても、.netであっても、HTMLであっても。)これという特効薬はありませんが、開発者が簡単に DPI に対応したアプリケーションを作成できるよう助けることはできます。たとえば、近々重要なエコシステム系のイベントが 2 つ開催されますが、そこで High DPI について詳しくお話しする予定です。また、既存のアプリケーションから DPI対応への変換方法を開発者が習得するための素材も用意しています。1 つめのイベントはMicrosoft Professional…


High DPI 解像度に対するフォローアップ

このブログがもたらす大変素晴らしい点のひとつは、コメントやメールで寄せられるトピックの裏側にある詳細な情報やデータについて、さらに詳しくお話することができる点です。皆様のご質問やご意見についてより深く説明させていただけるのは、非常に喜ばしいことです。今回は、高DPI解像度、アプリケーションの互換性、さまざまなケースでの読みやすさに関する一般的な問題について寄せられたコメントのフォローアップをします。デスクトップ グラフィックス チームのプログラム マネージャーであるRyan Havesonより、グラフィックスとWindows7の関係についてさらに詳しく説明させていただきます。–Steven 私たちがWindows7のプラニングを始めた頃、ディスプレイについてのユーザー データを調べている際に、非常に興味深い (そして驚くべき) ことを発見しまた。ほぼ半数のユーザーがフル ネイティブ画面解像度を使用するためのPC設定を行っていなかったのです。下の表は、以前の記事でChristinaが取り上げたWindows Feedback Program から得られたデータを示したものです。 なぜユーザーが低解像度に設定しているのかを明確に把握する方法はありません。しかし、私たちが目にした多くのコメントは、「高解像度のディスプレイでは、デフォルトのテキストが読みづらいので、低解像度にしているのではないか」、という私たちの仮説と一致していました。もしかしたら、たまたまこのような設定になってしまった、というユーザーもいるかもしれません。例えば、ディスプレイ ドライバが合っていない、あるいは何らかの理由でアプリケーションが解像度を変更し元に戻らなかった、というケースが考えられます。どんな理由で画面解像度が低くなったにせよ、結果的にぼやけたテキストが表示されてしまいます。PCの画面で長時間このようなテキストを読むと本当に目が疲れます。LCDディスプレイの場合、テキストがぼやけてしまう主な原因は、LCDが固定ピクセルで構成されていることです。これは、非ネイティブの解像度設定では、システムが固定単位の中で断片的なピクセルを表示しなければならないことを意味します。これによってぼやけが生じるのです。ぼやけて見える別の理由は、ディスプレイがネイティブの解像度に設定されていない場合、ClearType text rendering technologyが正しく適用されない、ということです。ClearTypeテキストは、多くの (全てではありませんが) ユーザーに好まれて使用されています。興味深いのは、CRTディスプレイの場合、画面解像度の変更による忠実度の低下が、LCDディスプレイほど強調されないことです。なぜなら、CRTディスプレイは、LCDディスプレイのように固定ピクセルを持っていないからです。ただ、LCDディスプレイは、サイズやコスト面でのメリット、ラップトップPCの人気などの理由により、インストールベースでいち早く市場シェアを獲得しました。非ネイティブ画面解像度で実行するもうひとつの問題は、多くのユーザーが不注意にディスプレイを非ネイティブの縦横比に設定してしまう、ということです。これにより、画像は不明瞭になりしかもゆがんで見えてしまいます。ご想像のとおり、これではさらに目の疲労が悪化してしまいます。 文字以外に目を向けても、このようなシナリオではメディアに対する再現忠実性も同様にいちじるしく損なわれます。多くのユーザーが行っているような設定では、仮にハードウェアがその能力を持っていたとしても、それぞれ1280x720と1920x1080スクリーン解像度にあたる720pや1080pといった高精細(ハイデフ)テレビコンテンツを見ることはできません。PCのモニターは伝統的に「高精細」ディスプレイデバイスでしたが、この問題の解決なしにはこのTV業界に対して持っていたこの優位性を失ってしまう危険性があります。今日、約10%のユーザーだけが真に1080pを表示可能なPCディスプレイを持っているというのは事実ですが、ディスプレイの価格は下がり続け、インストールベースは成長を続ける見込みです。そして、ユーザーが利用したいと望む高精細のコンテンツに対する別の波が来るであろうことも確実でしょう。例として、ディスプレイが400 DPIを獲得したとき、それは紙に印刷された文字と見た目はほとんど区別がつかないでしょう。現在の170 DPI程度のeBookリーダーでもガラスの向こうの紙程度には見えます。 この例から、現実のエンドユーザーが活用できる利点を見ることができます。実はこの問題を解決することができる“High DPI”と呼ばれるWindowsの既存の基盤技術があります。High DPIはWindows 7の新機能ではありません。(初期にもあった基盤技術を超える意味で) VistaまではHigh DPIをサポートするためのOSユーザーインターフェースに対し大規模な投資はされてきませんでした。Vistaで試してみてください。デスクトップ上で右クリックして、個人設定を選び、左側の列から「フォントサイズ(DPI)の調整(J)」を選びます。Windows7に対する私たちの考えは、箱から出したばかりのPCそのままの状態でHigh DPIを利用できるのであれば、ユーザーは高精細エクスペリエンスを利用でき、スクリーン上の文字を読む際の目へのストレスをも大きく減らすことができるのではないかというものでした。ディスプレイの実際のDPIを検知する基盤技術があるので、箱から出したばかりのPCに対するデフォルトの設定の調整で望ましい結果を出すことができます。しかし、こうすることによりhigh DPI設定に対し完全に互換性のないアプリケーションに対し問題が生じる危険性を含んでいます。 問題のひとつは、GDIアプリケーションがDPIを気にしなくてはいけないということです。開発者はウィンドーフレーム、テキストサイズ、グラフィカルボタン、レイアウトをDPI設定で指定されたスケールファクタにマッチさせスケールするようにコードを書かなくてはいけません。そうしていないアプリケーションはいくつかの問題を持つでしょう。大多数は大きな問題ではありません。フォントサイズのミスマッチ、レイアウトに関する些細な問題などです。しかしアプリケーションによっては高DPI設定で走らせたときに大きな問題をおこします。 (この問題を)軽減するいくつかの対策として、例えばDPIを認識しないアプリケーションに対する自働スケーリング機能というような対策を、Windowsに施す事が出来ますが、しかしこうした軽減機能にも問題があります(このテーマに関するGreg Schechter’s blog もご参照ください)。自動スケーリングの場合、DPIを認識しないアプリケーションは、ウィンドーマネージャーによって自動的にスケーリングされます。テキストのサイズは、ユーザーの好みの設定に自動的に合わされますが、結果的に、そのアプリケーションのウィンドーで文字がぼやけるといった影響も生じるでしょう。小さなテキストを読むことができない方々に対して実用的なhigh DPI環境を実現するためには、こうしたスケーリング機能は必要な機能なのです。しかしながら、high DPIにうまくスケールされたアプリケーションだけを使用しているユーザーや、または、テキストサイズがうまく合っていないにもかかわらずその影響をさほど受けていないユーザーは、結果的に自動スケーリングによって文字がぼやける現象が引き起こされる事で、自動スケーリングがより悪い選択肢であると判断してしまうかもしれません。DPIを認識するアプリケーションであるかどうかをOSが検出する方法がないと、デフォルト設定を選択しなければなりません。そしてそれは、どのくらいの利点があるか、何を取捨選択するか、という元の疑問へと立ち返ります。長期的な解決方法は、アプリケーションが解像度に依存しなくなる事と、アプリケーションがユーザーの設定に合わせてスケールできるようにする事です。この為には、私たちのツールとドキュメントの両方のサポートが不可欠です。どうやって時間をかけてそこに行き着くか、そして、いかにその移行期間中の使い勝手を最良なものにするか、これらを見つけ出す事がプラットフォームの挑戦です。 短期的 vs 長期的な顧客満足度 長期的に考えるとhigh fidelity experienceを持たせる事が重要であるという点は、High definition TV(ハイビジョンテレビ)のモデルを見ても明らかです。唯一の問題点は、high DPIの基盤が複数のWindows OSのリリースに渡って存在しているにも関わらず、実際にこれらの環境設定でどのくらいのアプリケーションがテストされたのかを、私たちが明確に把握していない事です。(実際、DPIを認識するアプリケーションの作成方法として2001にMSDNの記事が公開されています。)つまり、この機能を有効にしたことで、より広範囲に引き起こされるであろう短期的なユーザーへの悪影響が数値化されていない事に、私たちは直面しました。私たちがまず初めに行ったことは、起こりえる障害を数値化することでした。私たちは、high DPI設定時にアプリケーションがどのように動作するかを把握する為に、私たちのアプリケーション互換性検証ラボにある1,000を超えるアプリケーションでテストを行いました。そこで私たちが確認できた結果として、これら1000アプリケーションの各問題の比率を以下に示します。 1点補足しますと、私たちが言う“バグ”とは、ソフトウェアが期待にそぐわない動作する事です ‐ つまり、クラッシュといった深刻な問題から、見た目上の問題まで、すべてが対象となります。私たちはこれらのバグを、1~4の段階でその深刻度(Sev)を分類しています。ここでSev1は、本当に深刻な問題(クラッシュ、データ損失、機能の欠落)、そしてSev4は非常に些細な現象、または、非常に発生率が低いものです。 調査の結果、多くのアプリケーションは high DPI において十分動作することがわかりました。ごく一部のアプリケーションでしか主要な機能が損なわれることはありませんでした。もちろん十分動作するアプリケーションは心配の必要がありません。ですがもし 1%…


Windows フィードバック プログラム

Windows Customer Engineering Feature チームのChristina Storm を紹介します。彼女はテレメトリーと呼ばれている、お客様からのデータ収集を担当しています。 以前のブログで、Steven が Windows 7 Feature チームを紹介しました。私は、Windows Customer Engineering チームでお客様からのデータ収集を担当しているプログラムマネージャーです。私たちのチームは Windows Feedback Program を担当しています。Windows Feedback Program は、開発プロセスにおいてお客様から直接フィードバックをいただくための現在いくつかあるプログラムのひとつです。 Windows Feedback Program (WFP) はWindows XP, Windows Vista のプロダクトサイクルを通して何年も行われてきました。私たちは、現在このプログラムをすべての面において Windows 7 に適用できるよう準備を始めています。このプログラムの最も重要な部分は、私たちのウェブサイト、http://wfp.microsoft.comからプログラムに参加し、登録されているたくさんのお客様を通じての調査です。お客様は、まずアンケートに回答してフィードバックするプログラムに参加するか、または自動化されたフィードバックプログラム参加する、あるいはその両方に参加するかを選択できます。そのあと20分ほどのプロフィール調査のアンケートに回答していただきます。このアンケートの結果は、フィードバックを後で分析する時の参考にさせていただきます。私たちのプログラムにはコンピューターの知識レベルに関して広い範囲の方が参加されています。そして私たちは参加者のコンピューター知識レベルが偏らないように常に調整しています。私たちのプログラムのようなフィードバックプログラムに自発的に参加される方の多くは、通常テクノロジーに関して非常に熱心な人たちです。彼らは、消費者向け電子機器、デジタル機器、ソフトウェアの新しいバージョンなどを、製品で出た早い時期から使い始める人たちです。対照的に、PCは仕事をするための道具と考えているお客様は、フィードバックプログラムに参加することをあまり好まない傾向があります。または、私たちは、もっと女性の方にプログラムに参加していただきたいと考えています。 自動化されたフィードバックプログラムに参加されたお客様には、Windows Telemetry チームが開発した自動的にデータを収集するツールをインストールしていただきます。このプログラムのプライバシーアグリーメントには、このツールが収集するデータについて記載されています。 いくつかの例をあげます。 Windows およびインストールされ使用されているアプリケーションの使い方 コンピューター上のファイルとフォルダーの構成、およびフォルダーに入っているファイルの種類の数、例えばピクチャフォルダにある JPGファイルの数など コンピューターにインストールされているハードウェア、デバイス、ドライバや設定などシステム固有の情報 Customer Experience Improvement program (訳注:日本語訳はカスタマ エクスペリエンス向上プログラム) のデータ 集められたデータから、Windows フィーチャーチーム、プランナーやユーザー リサーチの専門家が利用するレポートを作成します。以下のチャートは、次の質問の答えを示しています -…

1