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

個性について少し、、、

e7blog — Mon, 25 May 2009 02:51:45 GMT

こんにちは! データによると、MSDN・TechNet・Connect ユーザーの多くは、Windows 7 の RC (製品候補版) を使うことで忙しくされているようです。ありがとうございます!!! そしてもちろん、多くの人はRC をダウンロードして使うことを楽しまれています。私たちはダウンロードの規模を拡大し、皆さんの参加と RC の評価データをみることを楽しみにしています。ユーザー自身が Windows 7 を「コントロールできる」ようにすることについてお話しましたが、自分の PC に対してコントロールする方法のひとつが、使う楽しみを独自なものにすることです。RC では Windows 7 の新しい個人設定の「要素」にお目にかかれるでしょう。この投稿は、製品デザイン チームの Denise Trabona と Samuel Moreau が、彼らの仕事の舞台裏について書いたものです。画像の下のリンクをクリックしていください。才能あふれるアーティストたちによるたくさん作品をご覧いただけます。なお、この投稿にあるのは単なるサムネイルです。フルスクリーンの画像は RC でお楽しみください。 --Steven

追伸: ただのお知らせですが、プリベータ版やベータ版でも行ったように、Windows Update とシステムにパッチがあたって更新されるかのテストを行う予定です。新しいドライバーと共に、システムに対するその他の更新も目にされるかもしれません。

Windows 7 のエンジニアリングで最もエキサイティングなことのひとつは、全プロダクトサイクルにわたって成されるさまざまな種類の仕事です。このブログでもいろいろなトピックがあるように、製品のあらゆるレベルにおいて私たちが一生懸命取り組んでいることがお分かりかと思います。みなさんは Windows 7 での新しい個人設定の裏話に興味があるのではないかと思い、今回の投稿となりました。

お気づきの方もいらっしゃるでしょうが、RC ビルドで、個人の使い勝手をより柔軟にカスタマイズできるようにする新しい個人設定のコンテンツ (壁紙、グラスの色、サウンド設定) のいくつかをお見せします。Windows ユーザーはデスクトップの背景を変更することにより自分自身を表現することが好きですが、Windows 7 にはすぐに自分のエクスペリエンスをカスタマイズできるようなコンテンツが最初から含まれています。

1000の言葉に値するひとつの絵

個人設定の機能を開発する上で、ユーザーが自分のスタイルを表現するためのすばらしいコンテンツが必要だと感じていました。デスクトップの背景は非常に活気に満ちた面なので、独創的な人々がこの機能でどうするか表現したような高品質のコンテンツを提供することに重点を置きたいと思っていました。みなさんがフィードバックボタンを使ってスクリーンショットを送ってこられるとき、設定されている壁紙の豊かな多様性と個性にいつも刺激を受けています。

どのように Windows 7 の個人設定に取りかかろうかと考えていたとき、これまでの伝統に敬意を表すのもひとつの方法だと思い当たりました。過去にも写真は Windows の大きな特色でした。いくつかの写真は大変美しく、ずっと維持していきたい誇り高い伝統になっていました。また、新しい領域に足を踏み入れ、視覚的なパレットを広げたいとも思っていました。写真の分野では、伝統的にテーマを風景写真に絞ってきましたが、建築物や自然の新しいテーマを追加しました。多くの画像は、画像をストックしているパートナーによるものですが、才能ある地元の写真家 Will Austin と一緒に仕事ができたのは幸運でした。Will は多くの題材を、特に建築物に力を入れて、世界中で写真を撮影してきました。Will の写真には、私たちが誇りを持って本拠地と呼ぶシアトルエリアのローカル色が少し入っています。

インスピレーションと喜びのハードルを上げる

対象となる写真ですが、人々の想像力にひらめきと喜びを与えて活性化させるような画像を追加のするよう、取り上げる範囲を広げる努力をしました。ユニークで、タイムリーで、独特な観点を持つような新しいコンテンツにまで幅を広げたかったのです。目標は、不朽のすばらしい写真と、エネルギーにあふれたモダンで新鮮なイラストとの、バランスが取れたコンテンツです。それに加え、さまざまな好み、性別、年齢の人に気に入ってもらえるような、色調もおとなしいものから派手なものまで、構成も大きなものから小さく緻密なものまで、数多くの豊かなイラストを実現することも重要でした。

ご近所の Zune チームからヒントを得て、Windows 7 でほかにない芸術作品をみなさんのために創造するため、72 and Sunny という代理店と一緒に世界中のイラストを探しました。大量のサンプルを見ていく中で、スタイルが多様性をカバーするようにとても変化に富んでおり、かつ、私たちが達成しようとしている全体的なトーンに当てはまるような共通のテーマを維持しているようなアーティストのグループを探し求めました。そして、それからが楽しいのですが、シンプルな指針となる言葉 (光輝く、エネルギッシュな、活気づける、楽観的な、など) だけを頼りに、アーティストはオリジナル作品のコンセプトスケッチを描くために、何も描かれていないキャンバスを持って出かけて行きました。

繰り返して磨きをかける

アーティストの最初のスケッチとコンセプト作品を初めてレビューしたときのことを今でも覚えています。そしてその時から、これらの画像はとても楽しくなることがわかっていました。次のステップは、一定の目標が達成できていることを確認し、細かいところを調整するために、何度か行ったり来たりすることでした。たとえば、私たちにとって重要なのは、新しいタスクバーのもとで画像がどう見えて視覚的なインパクトとして適正なバランスを保っているかということと、ユーザーがデスクトップ上で重要なファイルを探すときに気が散って邪魔にならないか、という 2 点でした。適正なバランスを見つけるのは大変ですが、幸運にも、驚くほど才能豊かなアーティストと、このプロジェクトで一緒に働く 72 and Sunny の仲間に恵まれました。

世界中の人々のための Windows

最後に、さまざまなバックグラウンドやスタイルを持つイラストレーターを探し出し、世界中の人々を代表して世界中の人々の心に訴えることにより、全世界の Windows ユーザーを認めたいと思いました。

そこで、驚くほど才能豊かなアーティストと、Windows 7 の個人設定に貢献してくれる彼らの作品を敬意を持って紹介いたします。

近藤有稿

日本出身、イギリス、ロンドン在住

Katharina Leuzinger

スイスのチューリッヒでスイス人と日本人の両親の間に生まれる。イギリス、ロンドン在住

Osmand Nosse

アイルランド、ウィックロウ

Klaus Haapaniemi

フィンランド出身、イギリス、ロンドンをベースに活動

Red Nose Studios の Chris Sickles

アメリカ、インディアナ州

Punga

アルゼンチン、ブエノスアイレス

Pomme Chan

バンコクで生まれ、教育を受ける。イギリス、ロンドン在住

Kustaa Saksi

オランダ、アムステルダム

Nanosphere の Paul Hwang と Benjamin Lee

カリフォルニア州、ロサンジェルス

Adhemas Batista

ブラジル、サンパウロ出身、カリフォルニア州、ロサンジェルス在住

Kai and Sunny

イギリス、ロンドン

Nan Na Hvass

アフリカのスワジランドでデンマーク人の父と中国人の母の間に生まれる。デンマークコペンハーゲン在住

この投稿により、Windows 7 コンテンツを準備してきたその舞台裏を提供できたとしたら幸いです。また、Windows 7 のこの要素に対して私たちの目標を達成できたと、みなさんから言っていただければ、最高です。

-Denise Trabona、Samuel Moreau

Windows 7 のブートアニメーションのエンジニアリング

e7blog — Thu, 12 Mar 2009 10:52:25 GMT

このブログや Windows 7 についてお話する機会を通じて、このブログの話題に関してとても興味を持っていただいていることをひしひしと感じています。私たちはまず、ブート/スタートアップのシーケンス、およびそれが迅速に行われることがどんなに重要かということを知りました。同時に、休止状態からマシンをレジュームする際やマシンの電源を入れる際に HDD のライトがチカチカしているのを眺めているのは、本当に退屈であることも理解しています。PCを起動したときの最初の体験を向上させるため、ブート シーケンスの改善に着手します—いうなれば、にぎやかにします。とても簡単なことのように思えるかもしれませんが、問題解決のため調査したところ、エンジニアリング的にかなり大変なことだということが判明しました。私たちの目標は、システムのブート パフォーマンスに影響を及ぼすことなく、楽しくすることです。このエンジニアリングについて説明し、ブート シーケンスについて解説するために、コア ユーザー エクスペリエンス チームのプログラム マネージャーである Karen Wong がこの投稿を執筆しました。 --Steven

デザイン

私たちは「パーソナリティ (個性)」という言葉を、人と感情的につながっているソフトウェアの特徴の一部を言及するために使用しています。「light (光)」と「energy (エネルギー)」は Windows 7 のパーソナリティを表現するために使っている言葉です。Windows 7 を設計する上で、この Windows 7 のパーソナリティの要素を目立たせるため、Vista の起動時の映像でやったこと以上のことをやり遂げなければならないことが明らかになりました。

デザインの観点からいうと、機能の視覚的表現はパフォーマンスと品質に対するユーザーの感じ方において重要な役割を果たしています。私たちの目的は、Windows を美しく起動させることであり、Windows 7 のパーソナリティである “light” と “energy” から呼び起こされたものです。そして、自然界でこれらがそのものの形を浮き彫りにする様式が私たちのデザインパレットとなりました。たとえば、「bioluminescence (生物発光)」、「organic (有機的な)」、「humble beauty (控えめな美しさ)」、「atmosphere (雰囲気)」などが、私たちの行ったブレインストーミングで頻繁に出てきた言葉でした。これらは多少陳腐に聞こえるかもしれませんが、Windows 7 の全体的な目標のすべてなのです。

20 以上のブートシーケンスのデザインが作成およびレビューされ、テストされました。デザインは色の彩度や明るさ、動きの複雑さ、照明効果などによって変わってきます。以下は、設計中に描かれたスケッチです:

Windows 7 の最終的なデザインは、四方向からエネルギーが接近してひとつになり、窓に投影される光を形成するというものです (もちろん、Windows ロゴが窓と似ているのは偶然ではありません!)。かすかな鼓動はその後の進展を表していますが、これは Windows 7 のパーソナリティの生き生きとしたさまを強調するデザインです。

デザインの観点からいうと、この新しいブートシーケンスはデザイン目標のすべてを満たしており、世界へ発信することにワクワクしていました。しかし、起動は単に表現がよければよいというものではありません。エンジニアリングの観点から、克服すべき明らかな難題があったのです – それは、「デスクトップまでの時間」は今でもユーザーにとって最も重要なことだということです。視覚的な美しさは、デスクトップへより速く到達することには勝りません。そして、多くの人はいわゆる「目の保養」と呼ばれる機能に対して批判的であり、ブートシーケンスがそのような機能になるのは絶対に避けねばならないことでした。

パフォーマンスに妥協なし

もしすべてを Vista と同じにしてブートアニメーションを新しい Windows 7 用にただ更新するだけであれば、私たちが目指す新しいレベルのパフォーマンスや品質を達成することはできません。実際、Windows 7 で新しいブートアニメーションを実現するには、膨大なコードの変更が必要でした。

Vista では、ブートローダーは 640x480 の低解像度スクリーンを使用し、緑色の進行状況バーに必要なファイルサイズも大変小さくて済みました。その上、Vista のブートスクリーンは色濃度も低く、16 bpp (bit per pixel) しかありませんでした。Windows 7 では、新しいブートアニメーションで豊かな色彩を実現するために 32 bpp に増やしました。Vista での起動時の進行状況インジケーターの更新は CPU 経由で実現しましたが、I/O 時間の影響を受けやすいので、ときどきアニメーションに不具合が生じます。低解像度のスクリーンで色濃度も限定され、さらには不具合の影響も受けやすい – Windows 7 で何か手の込んだものを構築するには、大変な仕事が待ち構えていたのでした。

まず、ブートアニメーションを表示するのに、Windows 7 のブートローダーではこれまでとは違うメカニズムを使用することから手がけました。ファームウェア (BIOS または UEFI) からフレームバッファーへポインターを設定し、高解像度の画像 (1024 x 768) を表示します。カーネルと起動に必要なデバイスドライバーがメモリへ読み込まれる間に、画像をアニメーション化します。ディスプレイ用のネイティブグラフィックスドライバーはまだメモリに読み込まれて初期化されていないので、アニメーションは CPU を使用して、またグラフィックスディスプレイのフレームバッファーを更新して実行されます。さらなる最適化も行いました – パフォーマンスを迅速化するために、CPU が書き込みを併用するキャッシュを使用するようにしました。

Michael Fortin によるブートのパフォーマンスに関するブログでは、起動の初期の段階は、カーネル、デバイスドライバーのファイル、およびそのほかのシステムコンポーネントのファイルを読み込むので、I/O の制約を受けることが説明されています。そのため、起動初期において遅延が発生するのを避けるため、ブートアニメーションのサイズをスクリーンの狭い範囲に限定しました。広いサイズのアニメーションはそれだけ大きいアニメーションの画像を読み込む必要があり、その結果、ファイル I/O を増加することになります。アニメーションの画像はビットマップをリソースとして取り込んで圧縮されており、それから WIM 画像圧縮により圧縮されています。WIM 画像圧縮は全体的なファイルサイズを削減するので、その結果、読み込むのに必要な I/O を削減できます。WIM 画像圧縮はまた、ディスク上のフットプリントも削減します。スクリーンの狭い範囲にアニメーションを表示し、やや低いフレーム率を使用することにより、フレームバッファーを更新する CPU のオーバーヘッドを必要最低限のレベルに保ち、起動時間にオーバーヘッドを追加しないようにします。

起動のパフォーマンスだけでなく品質も向上させる変更も加えました。それは、グラフィックスモードの移行を減らすことでした。この移行はグラフィックスサブシステムや Windows シェルの初期化の際に起こります。Vista では、このため、ユーザーに対してログオン画面を表示するまでに (または、一人しかシステムユーザーがいない場合は、ユーザーのデスクトップを表示するまでに) 数回ディスプレイが変更し (黒く点滅し)、起動のエクスペリエンスがスムーズではありませんでした。

新しいアニメーションを可能にするためパフォーマンスと品質の向上のために起動の構造を深く掘り下げて調べたところ、ブートアニメーションの美化活動によりデスクトップまでの時間をさらに短縮するチャンスが生まれたのはうれしい驚きでした。Vista では、ユーザーがマシンの電源を入れると、ブートシーケンスは Windows フラッグまたは「パール」のアニメーションがログオンスクリーン (ユーザーが自動ログインの設定をしている場合はデスクトップ) の前に表示されていました。Vista の起動構造の制約により、このパールアニメーションは起動コードがすでに完了している場合のみ再生されます。

Vista のブートシーケンス、パールアニメーションを含む

さて、新しい起動の映像は Windows 7 のパーソナリティを反映した表現力豊かなアニメーションを表示します。パールアニメーションは時代遅れで冗長な感じがしたので削除されました。その結果、起動が完了した後にこのアニメーションを再生する時間を節約できました。

Windows 7 のブートシーケンス, パールアニメーションは削除

起動時のサウンドはどうなるのかと思われるかもしれません。Vista では、最高品質のエクスペリエンスを生み出すため、サウンドはパールアニメーションと同時でなければなりませんでした。しかし、これは一部のハードウェアに対してパフォーマンスの影響を与える恐れがありました。と言うのも、システムのサウンドスタックはパールのシーケンスを完了するために読み込まれなければならないからです。システムのサウンド再生の準備が整うまで待っている場合、デスクトップが表示されるまでに遅延が発生する可能性があります。そのため、今回サウンドは非同期的に、ログオン画面が読み込まれた後のいつかに再生されるように変更しました。テストしたほとんどのハードウェアでは、ログオン画面が表示されたタイミングです。Vista に対するユーザーからのフィードバックで、音が鳴ったので見てみたが、起動はまだ完了していなかった、というものがありました。つまりこの変更は、パフォーマンスのメリットに加え、ユーザーにマシンが使用可能な状態になったことを知らせることによりユーザーエクスペリエンスを向上させます。

起動に関するコードの最適化と Vista のパールアニメーションの削除の和により、デスクトップへ到達するまでの時間を増加させることなく、起動中に表現力豊かな高品質のアニメーションを追加することができました。

幅広いハードウェアへの対応

起動時のエクスペリエンスはユーザーのハードウェアによって大きく変わってきます。幅広ハードウェアにわたって最高のビジュアルエクスペリエンスを確実にするため、いくつかの設計意思決定をしました。しかし、システムがデスクトップを表示するまでにかかる時間は主にハードウェアに依存します。

たとえば、起動時、アニメーションが始まるまでに遅延があることに気付かれるかもしれませんが、この遅延時間はシステムのハードウェアによって異なります。即座の反応を示すよう最適化するために、Windows がシステム上のすべてのプロセッサーを開始する機会を得る前に、実際には起動画面上にテキストを表示します。それは、起動中にアニメーションが残りの I/O と非同期で実行できる場合のみ可能です (前述のように、最善のパフォーマンスと品質に必要です)。

また、起動中の Windows フラッグのサイズがスクリーンのサイズによって少し変わったことに気付かれるかもしれません。Windows 7 の技術的な制限のため、システムのオリジナルの解像度にかかわらず、起動時には常に推奨される最低解像度である 1024x768 で表示されます。今日、ほとんどのハードウェアはブートシーケンスを中央に表示するのではなく、拡大して画面いっぱいに表示するように設定されています。その結果、ブートアニメーションも 1024x768 とは異なる縦横比でスクリーン上に拡大されます。しかし、視覚的な品質が保たれるように、一般的な縦横比で一連の流れをテストしました。

起動、再起動、および休止状態からのレジューム

起動時のエクスペリエンスを向上させるためのこの大変な仕事を無駄にする訳にはいきません。ユーザーは休止状態から復帰する際にも同様のエクスペリエンスを体験できるでしょう。

カスタマイズ

みなさんの多くは、自分自身のアニメーションを使用したり、一連の流れをカスタマイズしたりできるのか知りたいと思っていることでしょう。残念ながら、それは Windows 7 でサポートしようとしていることではありません。すでに Windows 7 での非常に多くの「パーソナライズ」要素、たとえばベータで試すことのできる新しいテーマパックなどについてお話したり紹介したりしてきました。理由はとても明白で、起動時に任意の要素がメモリへ読み込まれるのを許可すると、システムのセキュリティが保証できなくなるからです。Windows を開始する初期段階では、ファイヤーウォールやウィルス駆除ソフトはまだシステムを守るために利用可能になっていないので、システムは鍵がかけられ大変注意深く監視された既知の状態で実行されなければなりません。そしてもちろん、画像サイズや内容などについて、みなさんが要件に従ってくださるであろうことは信じていますが、パフォーマンスに与える影響をかんがみて、すべてのサードパーティーがそれを行うのを保証するために必要なコードを組み込みたくないのです。Windows 7 の設計目標のひとつは、ユーザーの皆様一人ひとりを表現する十分なチャンスがあり、自分の PC が本当に自分の PC であるようにすることでした。ですので、なぜこの要素は一貫し続ける必要があるのかご理解いただけると幸いです。

舞台裏を簡単にご紹介しましたが、楽しんでいただけたでしょうか。Windows 7 では、Windows PC を開始するときのエクスペリエンスをもう少し楽しいものにしようと目指していますが、このブログや他のフォーラムでのフィードバックを見る限り、私たちは正しい方向へ進んでいると信じています。起動を高速にする取り組みに加え、システムが十分に堅牢であることも私たちの目標です。ですので、みなさんの多くはこの新しいブートアニメーションをそれほど頻繁に見ることはないでしょうが、そのような機会にはブートアニメーションは楽しく且つ高速なものとなるでしょう!

--Karen

UAC に関するアップデート情報

e7blog — Thu, 05 Mar 2009 18:18:00 GMT

こんにちは。今回は Jon DeVaan が最近頂戴した UAC に関するフィードバックについてお話したいと思います。

Windows 7 を完了させるための作業の多くは、フィードバックへの対応に集中しています。UAC のフィードバックは、エンジニアリングの意思決定プロセスのいくつかの局面があって面白いです。この局面について探索すると、この e7 ブログに興味深い内容を登録できるのではないと考えました。これは UAC について語る第 3 回目です。Windows におけるこの機能の進化について興味のある方は、過去の 2つの投稿 (投稿 1 および投稿 2) とみなさんから寄せられたコメントをお読みになるとよいでしょう。

これまでに Windows 7 ベータ版に対して寄せられた反応をうれしく思います。そして、RC (= Release Candidate、リリース候補版) に向けて、フィードバックや遠隔測定に基づいて製品にさらに磨きをかけるべく一生懸命作業中です。私たち Windows に従事している者はみな、自分たちの作業が世界中の非常に多くの人々に影響を及ぼすことを考えると謙虚になります。最近のフィードバックでは、人々がどんなに Windows に対して情熱を持っているか感じずにはいられません! 繰り返しになりますが、世界中の何億もの人にコンピュータの価値をもたらす仕事をしている驚くべきコミュニティの一部であることに対し、私たちは謙虚であり、ワクワクもしています。これまでにみなさんから寄せられた考えやコメントに対して、心より感謝申し上げます。

UAC は、「極」の立場とその中間にある立場を唱える (しかも、かなり強固に主張する) 支持者を持つ、幅広い観点を持つ機能のひとつです。今回のケースでは、一方の極を「セキュリティ」、その対極を「ユーザビリティ (使い勝手)」としたいと思います。もちろん、実際にはこの問題は 2つの極のみが存在するものではなく、間には完璧に実行可能な設計ポイントがあります。世界中のセキュリティ専門家はこの基本的な緊張の下ずっとやってきて、とても安全なように設計されたシステムが確実に存在していて、それによって恩恵を受けるであろう人々から守られています。個人的な例を挙げると、私の銀行は最近オンラインバンキングのセキュリティ管理方法を変更したのですが、とても複雑で使いにくいので、銀行を変えようと思っています。本気です!

誤解を解く

みなさんが現在の UAC の設計に対してコメントしているように (そして、そのコメントに対してもコメントしていますが)、いくつかの物事の融合と一連の誤解があることは明らかで、UAC に対するエンジニアリングの意思決定についてお話しする前に、解決しておく必要があります。エンジニアリングの意思決定は、Windows XP SP2 が先駆けとなった secure development lifecycle principles の、特に SD3+C (Secure by Design; Secure by Default; Secure in Deployment; and Communications) の「Secure by Default (デフォルト設定で安全)」を重視しながら成されました。Windows 7 はこの原理を擁護しており、いくつもの投稿でお話してきたようにすべての人が適切な PC エクスペリエンスを感じられるようにすることに焦点を当てなおしています。

まず最初に解決すべき問題は、PC に入り込んで実行し始める悪意のあるソフトウェア (マルウェア) vs. それがひとたび実行するとどうなるか、についてです。マルウェアが承諾なしに PC に入り込む方法についての報告はまだありません。これまでに頂いたすべてのフィードバックは、マルウェアがいったん PC に入り込む方法を見つけて実行しているときの UAC の動作を心配するものです。UAC に関する報告は脆弱性を招かないとするマイクロソフトの立場は、報告は明示的な承諾なしにマルウェアがマシンに入り込む方法がそもそも示されていないからです。「脆弱性ではない」という立場を、私たちが問題の他の部分を真剣に捉えていないと思っている人もいるようです。しかし、私たちはすべてのフィードバックを真剣に受け止めていることを分かってください。

セキュリティの分野において「脆弱性」という言葉は特別の意味を持っています。マイクロソフトは、Microsoft Security Response Center (secure@microsoft.com) の中に世界有数のセキュリティ機関を持っており、巨大なエコシステム全体のセキュリティに対する脅威をモニターしたり、マイクロソフト製品に関係するあらゆる脅威や脆弱性への対応を管理したりしています。世界中のセキュリティのコミュニティで一般的に受け入れられている定義によると、最近のフィードバックは脆弱性に該当しません。なぜなら、そもそも悪意のあるソフトウェアがコンピュータに到達するのを許さないからです。

Windows Vista にある防御機能は、そもそもマルウェアが PC に入り込むのを防ぐものであることを指摘しておくべきでしょう。たとえば、Internet Explorer の使用中 (他のブラウザでも似たようなセキュリティの処置があります)、.vbs ファイルや .exe ファイルをブラウズしようとすると、下記のようなプロンプトが表示されます:

Internet Explorer 8 ではまた、マルウェアの広がりを阻止するためのたくさんの新しい機能が導入されました (http://blogs.msdn.com/ie/archive/2008/08/29/trustworthy-browsing-with-ie8-summary.aspx をご覧ください)。私のお気に入りのひとつは SmartScreen® Filter で、悪意のあるサイトへ移動しようとした際に分からせようとしてくれます。他にも、マルウェアが PC に入り込むのをより困難にする、可視的および潜在的な機能があります。

IE8 の SmartScreen® の画面

さらに、最近の電子メールプログラム (Windows Live Mail など) で添付ファイルを開こうとすると、悪意のあるファイルはブロックされます:

最近のフィードバックの多くは、そもそも Windows 7 はマルウェアが PC に入り込むのを未然に防ぐ方法が Windows Vista よりすぐれていることを考慮していません。Windows 7 では、マルウェアがインストールまたは PC 内で実行される前に阻止する能力を向上させることに焦点を当て続けていました。

第二の誤解を解くべき問題は、UAC の設定によって異なる動作についてです。Windows 7 では UAC の機能について 4つの設定があります。その 4つとは、「通知しない」、「プログラムがコンピュータに対して変更を加えようとするときのみ通知する (デスクトップは暗くならない)」、「プログラムがコンピュータに対して変更を加えようとするときのみ通知する (デスクトップも暗くなる)」、および「常に通知する」です。Windows Vista では、「通知しない」および「常に通知する」と同等の、ふたつの選択肢しかありませんでした。Vista の UI では「通知しない」を選択するのは困難で、それゆえ実装の両極端を選ぶことになりました。Windows 7 では選択肢および機能に対するコントロールが増しました。いただいたフィードバックによると、このことはみなさんの多くにとって特に興味深いことのようです。

UAC に関する最近のフィードバックは、「プログラムがコンピュータに対して変更を加えようとするときのみ通知する」の設定の動作についてです。フィードバックが「常に通知する」に設定されている UAC とは関係ないことは明らかです。したがって、誰かが「UAC が壊れている」というようなことを言ったら、それはフィードバックを間違って捉えていることになります。

UAC の目的

Windows 7 において、「プログラムが… のときにのみ通知する」がどのように機能するかに関するフィードバックに注目しています。設計の選択について説明するには、まず前後関係を説明することが重要です。デフォルトの設定は、全体として UAC の改善について寄せられたフィードバックに基づき、幅広ユーザーの役に立つように選ばれました。私たちは、カスタマーエクスペリエンス向上プログラム、Windows フィードバック委員会、ユーザーアンケート、実地テスト、および社内のユーザビリティーテストに協力してくださったお客様から、UAC の承認ダイアログが増加するにつれ通知される情報のメリットが大幅に減少することを学びました。したがって、一般的なユーザーには、反射的に「[はい] を押す」のを防ぐため、主要なメッセージのみ表示するようにしなければなりません。

ひとつ重要なことは、UAC はセキュリティの砦ではないということです。UAC はより安全にする点では役立ちますが、救済してくれるものではありません。UAC はソフトウェアがインストールされる前にプロンプトを表示することで、ほとんどのケースで役に立ちます。UAC のこの部分は、設定が「プログラムが… ときのみ通知する」の場合でも有効です。UAC はまた管理者権限が必要なシステム全体に対する変更の場合にもプロンプトを表示します。これは理論上、マルウェアが実行された後に思えばそのようなソフトウェアへの効果的な対抗策に見えますが、実際の経験では効果は限られています。たとえば、巧妙なマルウェアは権限の昇格が必要となるようなオペレーションは避けるでしょう。その他にも、これまでのブログ (投稿 1 および投稿 2) でも論じてきたように、人間行動の要因もあります。

UAC はまた、ソフトウェア開発者が管理者権限を必要とせず実行できるようプログラムを改善するのを助けてくれます。マルウェアに対してシステムをセキュアにする最も効果的な方法は、標準ユーザーの権限で実行することです。多くのソフトウェアが管理者権限を必要とせずに動くようになれば、より多くの人々が標準ユーザー権限で実行するようになるでしょう。Windows 7 のマシンを設定する責任にある人 (IT 管理者や家族のヘルプデスク担当 (私もです!)) はみなさん、標準ユーザーアカウントを使用するようにマシンを管理していただきたいと思います。最近のフィードバックは、標準ユーザーとして実行してもちゃんと動作するとはっきり言っています。管理者はまた、標準ユーザーアカウントではなく管理者アカウントでマシンを管理する場合、グループポリシーで自由に UAC の設定を「常に通知する」に強制することもできます。

これまでの論議を繰り返すと、最近のフィードバックはセキュリティの脆弱性を表していないことがわかりました。なぜなら、悪意のあるソフトウェアはシステム上ですでに実行されている必要があるからです。Windows 7 と IE8 は共に、マルウェアがシステムに入り込むのを防ぐ保護機能が向上していることがわかりました。また、フィードバックは UAC の「常に通知する」の設定には当てはまらず、いったんマルウェアが実行し始めると UAC はそれを阻止するのに 100% 有効ではないことがわかりました。なぜ「プログラムが… のときにのみ通知する」という設定があって、しかもそれがデフォルトなのか、質問する人がいるかもしれません。

顧客主導型のエンジニアリング

「プログラムが… のときにのみ通知する」という設定を作成しこれをデフォルトに選択したのは、先にも述べたように、セキュリティ設計に固有の多種多様性に基づいて選択した設計です。Windows 7 を開始する前、Vista の UAC 機能はプロンプトを表示しすぎるというフィードバックをたくさんいただいていました。新しい UAC の設定は、このフィードバックに応える形で設計されたものです。最近のフィードバックは、「私は『常に通知する』に設定すると思いますが、”一般の人” ももっと安全にする必要があると思います」という内容のものが多いです。セキュリティ意識の高い人がこのように感じるのは当然でしょうし、Windows 7 にはそのような人のニーズに応えられる設定があることをうれしく思います。しかし、いわゆる ”一般の人” と呼ばれる人の望みは何でしょう? そのような人々のために、安全設計原理を尊重しつつ、どうデフォルトを決めるかは、大変興味深い問題です。

Windows 7 のベータ版のデフォルト設定を決定する際、M3 ビルドを実行するふたつの一般人のグループの行動を観察しました。半分は「プログラムが… ときのみ通知する」の設定で、残りの半分は「常に通知する」です。この人たちの結果と態度を分析し、私たちの選考の参考としました。この調査およびカスタマーエクスペリエンス向上プログラム、Windows フィードバック委員会、ユーザーアンケート、社内のユーザビリティーテストで得られたデータは、ベータ版での選考材料となり、最終的な設定選択を確認するためにベータ版でどのように遠隔測定を行うかの情報になりました。

調査の主要な測定基準は、セッション中に 2 回のプロンプトを閾値としました (セッションとは、電源を入れてから切るまで、または 1 日のいずれか短い方です)。もしセッション中に 2 回以上プロンプトを見ると、人はプロンプトにイライラしコンピュータの利用を干渉していると思います。ふたつのグループの比較から、「常に通知する」の設定のグループは、2 回以上プロンプトが表示されるセッションが 4 倍近いことがわかりました (6.7 回に 1 回 vs. 24 回に 1 回)。また、私たちはサンプル中の何人がマルウェアをマシンに入り込ませたか (Windows Defender のクリーニング状況で測定) の統計も収集しましたが、ふたつのグループ間でマルウェア侵入率の意味のある違いはありませんでした。ベータ期間中も、広範囲の調査でもこの結果が正しいかどうか確認するために、データを収集し続ける予定です。

私たちはベータテスターや個人のユーザーから寄せられた UAC に関する建設的なフィードバックを大変うれしく思います。このようなフィードバックは、この設計選択で考慮し続けているトレードオフの観点で、“一般の人” に焦点を合わせた検証の役に立っています。今後も UAC の設計選択を改善し続けるため、フィードバックや遠隔測定データをモニターしていきます。

お分かりのように、UAC の議論は奥が深いものです。Windows 7 では UAC そのものと、マルウェアが PC に到達するのを防ぐ方法について改良されています。Vista のときから寄せられているフィードバックに応え、すべてのタイプの人に対して適切な使い勝手とセキュリティを提供するよう一生懸命作業しています。私たちは着実に進展していると信じていますし、UAC の変更に対するフィードバックに注意深く耳を傾けています。Windows 7 に対する情熱およびフィードバックに対し、重ねて心よりお礼申し上げます。みなさんの一人ひとりが望むように機能を実装することはできませんが、さまざまな視点を適切に評価するため、耳を傾けつつ真剣に取り組んでいます。私たちの目標は、すべてのタイプの人に対して実用的で、使い勝手がよく、安全な Windows を作成することです。

Jon

フォローアップ: Windows 7 のアクセシビリティ

e7blog — Mon, 09 Feb 2009 14:18:28 GMT

前回のアクセシビリティに関する投稿に対してコメントをいただきましたが、そのトピックに関してユーザー インターフェース プラットフォーム チームのメンバーが考えをお話します。Brett は Windows 7 のアクセシビリティのテストを指揮するシニアテストリードです。--Steven

こんにちは。私は Windows 7 アクセシビリティチームでテストリードをしている Brett と申します。昨年の 11 月に同僚の Michael が Windows 7 に対する私たちのチームの仕事についてのブログを投稿しましたが、そのフォローアップと新しいスクリーン拡大鏡についての最新情報を提供したいと思います。ちなみに個人的なことですが、私は低視力で、私たちのチームで開発している技術が私自身の仕事を進めるために欠かせません。

この数ヶ月、毎日の仕事で Windows 7 を使用してきました。この、自社のまだベータ版にも満たない開発途上の製品を使用することを「ドッグフーディング」と呼んでいます。Windows 7 を第一の OS として使ってきましたが、新しい拡大鏡は私にとって大変役に立っています。

さて、拡大鏡についてですが、ご想像のとおり Windows にはたくさんの機能がありますが、アピールポイントは人によって異なります。このことについて、私たちは何億もの人にピザを作るようなものだと言っています。これは私のチームが担当している機能にも言えることです。Windows 7 のベータをリリースして以来、拡大鏡についてたくさんのコメントを読みました。あるものは新しいものによって本当に恩恵を受けている人から、あるものは提案、またあるものは懸案事項についてです。これらのフィードバックはどのような内容であってもありがたいもので感謝申し上げます。恩恵を受けた人の多くは基本的な拡大鏡が必要な人で、ズームインやズームアウトが簡単にできることを評価しています。私もその一人です。拡大鏡と一緒にカスタマイズした色、ハイコントラスト、またはスクリーンリーダーを使用している人にとっては、おそらく新しい拡大鏡はあまりお役に立っていないのではないかと思われます。そういう人のために、Vista の拡大鏡が引き続き動作することを確認しました。Windows 7 で私たちが行ったことについて、もう少しご説明しましょう。

実装について詳しくお話しする前に、Windows のグラフィックスシステムから始めたいと思います。この過去数年で GPU テクノロジーは大幅に向上し、Vista でついに最新ハードウェアのアクセラレーテッドグラフィックスシステムへ大きく飛躍しました。それが Aero と呼ばれているもので、GPU を活用しています。Aero という言葉は、透過性やグラデーションなど Windows ビジュアルの特定の要素を指すものとしてよく使用されています。しかし、実際にはそれ以上で、最新のグラフィックスレンダリング (技術的には DirectX API とデスクトップウィンドウマネージャー) は単に美学のためだけでなく、最新のハードウェアによって補助されたグラフィックスと強化された API を使用しているテキスト、2D、3D などすべての形のレンダリングのためにあります。しかしながら、さまざまなエコシステムが新しいテクノロジーを導入するには、おそらくいくつかの OS リリースにわたるくらいの時間がかかります。また、Windows、ソフトウェア開発者、およびハードウェアメーカーにとっても新しいテクノロジーを導入するには時間がかかり、しばらくの間は新旧いずれも進めてサポートする必要があります。たとえば、あるスクリーンリーダーは、昔の Windows グラフィックスシステム (GDI) を経由したデータをキャプチャーし、画面に表示されることのない UI モデルを構築するのはうまくできます。しかし新しいUIレンダリングをオフにする必要があります。一方、新しい拡大鏡はデスクトップウィンドウマネージャー (「Aero」) と密接に統合されており、グラフィックスの処理能力を活用し、全画面モードでマルチモニター対応のスムーズな拡大を実現します。

このことが示すように、進化させていく方法は単純ではありませんが、Windows 7 では新しい投資を行うと同時に Vista での機能や互換性が保たれるようにしました。拡大鏡はこの一例で、GPU の力を活用して幅広いユーザーに対して新しい可能性をもたらす一方で、スクリーンリーダー、ハイコントラスト、またはその他の理由により Aero をオフにしないといけない場合には、製品の既存の性能を維持します。そして、互換性をできるだけ保つことにより、今頼っているツールの多くが Windows 7 でも動くと考えています。

では、拡大鏡はすべての人にとってよくなったのでしょうか? 残念ながら、すべての人にとってはということではありませんが、確実に大勢の人にとってです。しかしそれ以上に、Windows 7 ではすべての人にとってのアクセシビリティが進歩したと率直に言うことができます。Michael も書いていましたが、私たちはいくつかの分野に対して投資を行いました。それは拡大鏡とスクリーンキーボードだけではなく、基礎をなすアクセシビリティ API に対してもかなりの作業を行いました。また、コミュニティを積極的にサポートしており、最近では NPO の NV Access に対し、彼らのオープンソースのスクリーンリーダーが Windows 7 や Internet Explorer 8 のサポートを向上できるよう助成しました。

最後まで読んでくださりありがとうございました。また、コメントもありがとうございました。

-Brett

Windows 7 のアクセシビリティ (ユーザー補助)

e7blog — Wed, 14 Jan 2009 12:40:00 GMT

この投稿は、アクセシビリティに対して重点的に取り組んでいるユーザーインターフェイスプラットフォームチームの開発長である Michael Bernstein によるものです。私たちにとってアクセシビリティという用語は、できるだけ多くの人々にとって Windows が使いやすくなるための機能や API のことを意味します。つまり、身体能力や認識能力に関係なく、誰もが Windows の機能にアクセスする力を持てるわけです。これを可能にするために、Windows には、あらかじめ組み込まれたアクセシビリティのユーティリティと API の両方が含まれています。API は特に、他社製の支援技術や、自分のソフトウェアがアクセスしやすいようにしようと考えているアプリケーション開発者によって使用されています。今回のトピックはマイクロソフトにとって大変重要であり、Windows 7 のエンジニアリングの基本理念のひとつでもあります。また、マイクロソフトには、 PC が見やすく、聞こえやすく、使いやすいことを確実にするために尽力している全社的なグループがあります。マイクロソフトのアクセシビリティに対するイニシアチブについては、http://www.microsoft.com/enable/ で詳しくご覧いただけます。 --Steven

こんにちは。私は Windows 7 のアクセシビリティと音声認識のエクスペリエンスの開発長をしています。私たちが Windows 7 におけるアクセシビリティに関してどのように考えたかについて書きたいと思います。

私たちは Windows 7 をこれまでマイクロソフトが製作してきたオペレーティングシステムの中でもっともアクセスしやすいものにしようと思いました。今回のリリースを計画するにつれて明らかになってきましたが、アクセシビリティという概念は見た目ほど単純ではありません。アクセシビリティはセキュリティのように考えたくなります。どちらも既知の不具合がある一方で、システムは安全/アクセス可能だと信じられています。しかしながら、この定義は限定的だとわかります。視覚障害を持つユーザーのニーズは、聴覚障害を持つユーザーのニーズとはまったく異なるという事実に対して、どのように対処すればよいでしょう? 全盲の人のニーズと弱視の人のニーズですら異なります。たとえば、拡大ツールは全盲の方々にとっては役に立ちませんが、弱視の方々にとっては極めて重要です。さらには、理論的にはアクセス可能でも、実質的にはイライラするような (たとえば、実行するのに 36回キーを押さないといけないシナリオなど) ケースはどうでしょうか? 明らかに、アクセシビリティは単純な「はい」「いいえ」で答えられるような質問にはなりません。どちらかというと特別なユーザビリティであり、しかもそれぞれ個別のニーズを持った特殊なユーザー群のためのユーザビリティです。

質問が複雑なので、その答えも複雑になってしまいました。私たちは、Windows 7 においてアクセシビリティを向上させるため、4つのパーツから成る方策を選びました。

I. UI オートメーションでしっかりとした基礎を築く

Windows Vista で、マイクロソフトは「UI オートメーション」というアクセシビリティ用の新しいコアコンポーネントを導入しました。UI オートメーションは、ユーザーの支援技術 (Assistive Technology = AT) がアプリケーションの UI をプログラムで駆動するのを可能にし、アクセシビリティ機能を以前のバージョンの Windows と比べてより豊かな方法で表現できるようにします。UI の要素について細かく確認でき、その上もっと豊かな方法でUI を操作できます。UI オートメーションは「コントロールパターン」という考え方も導入しました。コントロールパターンとは、UI のいずれの要素も、どのようにコントロールされるべきか決定できるというものです。たとえば、ボタンには Invoke パターンがありますが、これは押せるということを示すものです。同様にコンボボックスには、開いたり閉じたりできることを示す ExpandCollapse パターンがあります。すべてのコントロールを同じ型にはめようとするのではなく、それぞれのコントロールは違うようにしています。これらは Windows Vista から登場し、今もなお採用され続けています。

Windows 7 では、UI オートメーションシステムのパフォーマンス向上に力を注ぎ、支援技術を使ったさまざまなソフトウェアで効果的に使用されるよう UI オートメーション用の API を新しく一から作成しました。今では C++ で書かれたアプリケーションも .NET フレームワークを使って書かれたアプリケーションも、UI オートメーションを活用することができます。

私たちはまた、UI オートメーションシステムがレガシーである Microsoft Active Accessibility (MSAA) とより密接に統合されるようかなりの作業を行い、新旧テクノロジーのよいところを橋渡しするための新しい技術を開発しました。UI オートメーションのクライアントは MSAA アプリケーションからアクセシビリティ情報を読み出すことができますし、逆もまた同様ですが、これはアプリケーションがもともとどちらの API を使用していたかにかかわらず、最大限のアクセシビリティを確かなものとするためです。UI オートメーションシステムと MSAA システムはさまざまなシナリオで緊密に協力し合っているので、これら 2つの組み合わせを「Windows Automation API」と呼ぶことにしました。このアーキテクチャーは、その他のアクセシビリティに対する取り組みの基礎となるもので、このアクセシビリティの基礎が Windows 7 にも入っていることを喜ばしく思います。

II. Windows に入っているアクセシビリティのユーティリティを改良する

Windows に最初から入っているアクセシビリティのユーティリティも改良しました。マイクロソフトは、Windows が障害のある方にとってよりアクセスしやすいものとするために、数多くの AT ソフトウェア会社と密接に協力していますが、他のソフトウェアをインストールする前の初期のエクスペリエンスもアクセスしやすいものとするために、Windows には一連のユーティリティが含まれています。Windows 7 では、これらのユーティリティのうち 2つを強化することにしました。スクリーンキーボードと拡大鏡です。

スクリーンキーボードの最も顕著な変化は改良された外観や操作性ですが、ほかにも微妙な拡張があります。このユーティリティの外観は Windows XP から変わっておらず、お客様からサイズ変更ができるようにとの要望をいただいていました。私たちはこの両方についてタブレットの開発者とともに取り組み、タブレットソフトキーボードとスクリーンキーボードで共通のコードベースを共有しました。今ではどちらのキーボードも Windows 7 と調和した魅力的な外観となり、サイズ変更が可能になりました。しかしながら、キーボードは異なったままです。というのは、それぞれ異なった使い方をされるからです。タブレットのユーザーは、手書きとタイプ入力をダイナミックに切り替えたいと思うでしょう。一方、スクリーンキーボードのユーザーは、クリックするのが困難な障害がある場合、キーの上をさまよったりスキャンできるようなモードが必要でしょう。この線に沿って、障害のある方が文字をより速く入力できるようにするため、基本的な予測入力機能を追加しました。これまでにスクリーンキーボードでタイプ入力を試みたことがあるなら、予測入力がいかにテキストの入力スピードを向上させるか、そのよさをお分かりいただけるでしょう。

拡大鏡は徹底的に見直されました。Windows Vista や Windows XP での拡大鏡は、直感的なエクスペリエンスではありませんでした。たとえば、画面の一部をポイントすると、拡大された内容は、(通常、画面の上方にドッキングされた) 別のウィンドウに表示されました。つまり、ある一点をポイントしながら、別の場所を見なければなりませんでした。この問題に対して、私たちは 2つの基本的なソリューションを考えました。画面全体をズームできるようにすることと、ポインターの動きにあわせて領域を拡大して残りの部分はそのままにすることです。この「全画面モード」と「レンズモード」が、Windows 7 の拡大鏡の 2つの主要なモードとなりました。

全画面モードは、画面上にあるすべてのもののサイズを一度に大きくしたい場合に有効です。マウスやキーボードのフォーカスを画面の中央あたりで動かしても、ビューはじっとしたままです。画面の端に向かって動かすと、拡大鏡は追いかけるようにビューをスクロールします。このモードのマイナス面は、状況がわからなくなりがちなことです。このユーザビリティの問題に対処するため、画面全体に対して今見ている領域がどこなのかを表すためにズームアウトし、その後再びズームインするような、状況を示すアニメーションを追加しました。

一方、レンズモードは、ある特定のものだけをズームインしたい場合に便利です。このモードでは、レンズはマウスポインターを中心とするので、虫眼鏡を使っているような感じです。レンズは広くも狭くも幅広くサイズ調整が可能なので、文書を 1 行ずつ拡大して読みたい場合に便利です。このデザインは、好評を博している Microsoft IntelliPoint の拡大鏡に基づいていますが、これからはどのマウスでも使うことができます。

拡大鏡のウィンドウが画面上でスペースをとり過ぎる、というユーザーからのフィードバックに対しても対応しました。もっともよく使われているズームイン/ズームアウトといったコントロールを小さなツールバーに移動させました。このツールバーは、未使用時には半透明の透かしのような感じにフェードアウトします。その他のオプションは必要なときに [オプション] ダイアログで設定できます。そして最後に、ほとんどすべての機能に対してキーボードショートカットをつけました。したがって、UI を見たくなければ、使わなくてもすみます。Windows 7 では、[Win] + [+] キーを押せばいつでもズームインできます。

これらのツールは、低視力や手先の細かい作業が困難なお客様のアクセシビリティを直接向上させます。当たり前のことですが、PC を見たり情報のやり取りを行ったりするのを容易にすることは、すべての人にとってプラスになることであり、これらの 2つの例は AT ツールを幅広い層に対してアピールしました。PDC ではスクリーンキーボードと拡大鏡の両方をお見せしましたが、能力に関係なくすべての人が、これらのツールが自分のためになると思ってくださったと見てもよいと思います。

III. アクセシビリティソフトウェアの作成を容易にする

Windows の API だけで、アクセシビリティのすべてを提供できるわけではありません。Windows ベースのアプリケーションが、AT プログラムが使用するアクセシビリティのデータを正しく渡すことが不可欠です。たとえば、文字読み上げソフトはうまく音声を出せるにもかかわらず、気に入っている Web ブラウザで読み上げられないとしたら、それは何の意味があるのでしょう? 文字読み上げソフトや拡大鏡といった支援ツールは、アクセシビリティシステムの「クライアント」です。一方、Web ブラウザやワープロなどのアプリケーションは「プロバイダー」です。エクスペリエンス全体がアクセス可能なものとなるには、両方必須なのです－つまり、高品質なクライアントとしっかりしたプロバイダーの両方が、すぐれたアクセシビリティエクスペリエンスを得るために必要です。ソフトウェアエコシステムでは、数多くのプロバイダーがあります。そのため、それぞれのプロバイダーについて正しくコードが書かれているか一つ一つチェックするのは大変なことです。

この難問に対処するため、私たちのチームは「UI Accessibility Checker (略して AccChecker)」と UI Automation Verify (UIA Verify) という、アプリケーション (実際にはプロバイダー) をスキャンして一般的なアクセシビリティ問題について報告するユーティリティを開発しました。ソフトウェア開発者の方は、お客様が実際に使用する前に、AccChecker や UIA Verify を使ってプロバイダーコードの問題を検出することができます。また、品質保証エンジニアの方は、会社の仕事の品質を検証するのにこれらのユーティリティを使用できます。私たちは、AccChecker や UIA Verify をオープンソースのソフトウェアとして公開し、できる限り多くの関係者に使っていただけるようにしたことは、極めて重要だと考えています。プログラマーでない方は、直接使用することはないかもしれませんが、これらのユーティリティが遭遇していたかもしれないバグの除去に役立ったであろうことを考えると、やはり恩恵を受けていることになります。

IV. 1 日目からのアクセシビリティの計画

Windowsの機能そのものがすぐれたプロバイダーであることを確かなものとするために、ソフトウェア開発ライフサイクルのリスク評価からお知恵を拝借しました。コードを書く前に、それぞれの計画された Windows 7 の機能について、アクセシビリティの危険度を評価するのです。基本的な既成のコモンコントロールを使用している機能は通常、よりアクセシビリティに対応しています。なぜなら、Windows は既成のコンポーネントに対して内蔵されたプロバイダーを提供するからです。凝ったことやカスタム描画をするような機能は、対応させるためにいろいろな作業を行う必要があります。この計画プロセスにより、それぞれの開発チームはどの程度アクセシビリティの危険度があるか知ることができ、その結果、的確に計画を立てることができました。いったん機能が正しく評価されたら、私たちのチームは危険度によって機能表を並び替え、危険度の高い機能を担当しているチームに接触し、その機能がアクセシビリティ対応となるために必要なリソースやツールが足りているかを確認しました。また、より実践的なテストや検証が確実になされるようにもしました。その結果、Windows の機能のほとんどは、以前のバージョンに含まれていたものと比較して、よりアクセス可能となっており、総合的なユーザーエクスペリエンスが向上しています。

最後にまとめると、私たちは Windows 7 の開発において、アクセシビリティを重視しました。アクセシビリティ用のコア構造の改良や、スクリーンキーボードや拡大鏡など Windows に含まれるツールの強化で、順調な進展がありました。AccChecker および UIA Verify ツールにより、アプリケーションが既存の支援ツールや Windows Automation API をベースとした将来のツールに対して互換性があるか検証するのがずっと簡単になりました。Windows の機能やプロバイダーのアクセシビリティに対する私たちの取り組みは、社内の何百人ものエンジニアの懸命な働きのおかげで、さらに徹底して、一貫性があり、統合されたものとなりました。Windows 7 で成し遂げたことに対して私たちは誇りに思います。そして、障害のあるユーザーの方が自らの全潜在能力を発揮し、Windows でより楽しいエクスペリエンスを実現する手助けとなれば幸いです。

--Michael

アイデアの発想から機能の実現へ: 設計の観点から

e7blog — Fri, 07 Nov 2008 08:04:46 GMT

Larry は彼のポストへの反応や寄せられたコメントにとても感謝しています。ありがとうございます。2000 を超えるコメントや、同じくらい多くの電子メールを受け取れたことは、本当にありがたいことです。できるだけ多く返信しようと努力しているところです。

PDC まであと 10 日なので、Windows 7 のデモを練習する間、ブログは少し休むかもしれません。もちろんコメントのチェックは続けますし、その中で少しポストすることがあるかもしれませんが。

それでは、開発の「上流」プロセスに話を移して、私たちがどのようにしてリリースに組み込む機能を思いつき、アイデアを実際の機能にしていくのかを見てみましょう。

さまざまなエンジニアリングの課題についてポストする中で、これまで私たちはよく議論を少数の意思決定に絞り込んできました。多くの場合、それは 2 つのオプションのどちらを取るか (ある機能をオプションにするかどうか、2 つのうちどちらの方法でウィンドウ管理機能を追加するか、など) ということでした。しかし、このことは、製品定義がどこで始まり、私たちがどのようにしてアイデアを選択し、それを機能に変えるかということに対する説明にはなっていません。Windows のエンジニアリングにおけるほとんどの選択は、二者択一ではありません。無数の考慮事項、可変要素、および可能性を検討した後で、ようやくいくつかのオプションにたどりつくのです。このポストでは、アイデアが機能になるまでの過程に注目してみましょう。

これまでにフィードバックでよく見かけたスレッドは、「すべてをカスタマイズ可能にし、すべてをオプションにする」(もちろんそのままの引用したわけではありません) というものでした。もちろん、プラットフォームを提供しているということもあり、私たちは自分たちが提供している API の変更によって最大限の拡張性とカスタマイズを可能にすることを目標にしています。しかし、実際のエンジニアリングでは、パフォーマンス、複雑性、上位互換性などを考慮する必要があるために、カスタマイズと拡張性にはコストがかかります。このようなことを考慮に入れる 1 つの方法に「モード」があります。たとえば、あるリリースである機能に２つのモードがある場合 (多くの場合、新機能を有効にするか、旧機能を有効にするか)、後続リリースでその機能に変更があれば、その機能は潜在的に 4 つのモード (旧 + 旧、旧 + 新、新 + 旧、新 + 新) を持つことになり、さらに次には 8 つのモードになります。安定した一貫性のあるプラットフォームを提供する複雑さにはコストが伴うため、私たちは常にすべてを「抱えこむ」ことはできません。そのため、私たちは将来を計画しながら機能のあるべき動作について現実的な選択を行う必要があります。機能の設計は難しい選択を行うことでもあるのです。同時に、私たちは、プログラムの起動、ウィンドウ管理、ファイル操作、多様な周辺機器の使用など (Windows が実行する機能はもちろんこれだけではありません) のコアオペレーティングシステム機能で素晴らしい使い心地を提供したいとも思っています。このエクスペリエンスは、さまざまなスキルレベルと異なる用途で PC を使用する幅広い層のユーザーのニーズを満たし、かつ、ユーザーインターフェイスによるパーソナライズとコードによるカスタマイズを可能にするメカニズムを提供するものでなくてはなりません。私たちが計画するすべてのリリースは、期待どおりに動作しなかった機能の修正と新旧の諸問題に対処する新たなソリューション開発の融合であり、機能と拡張性の融合であり、既存ハードウェアのより優れたサポートと新しいハードウェアのサポートの融合であるのです。

このポストは、Windows エクスペリエンスのユーザーエクスペリエンス設計チームマネージャーである Samuel Moreau、Windows / Windows Live のユーザーエクスペリエンス設計およびリサーチ担当ディレクターである Brad Weed、そして Windows エクスペリエンスのプログラムマネジメント担当副社長である Julie Larson-Green が共同で執筆しています。私たちは、特定の機能のアイデアが書かれた多数のコメントを見て、私たちがどのように設計プロセス全般に取り組み、皆さんが言及したようなアイデアをプロセスに取り入れているのかについて、概要を説明するといいのではないかと考えました。また、PDC に参加予定の皆さんには、Sam が design principles of Windows 7 のセッションの進行役を務める予定であることをお知らせしておきます。--Steven

Windows の設計: アイデアの発想から機能の実現へ

私たちは通常、ある程度明確なアプローチで製品設計を行っていますが、このアプローチで設計が容易になったり「自動化」されたりするわけではありません。このアプローチはしばしば「設計の漏斗」と呼ばれ、この中でアイデアが概念からプロトタイプになり、実装され、さらに洗練されていきます。Chaitanya のユーザーインターフェイス: スタート、起動、および切り替え機能のポストに対するコメントとして寄せられた多様な設計アイデアを読んでいただければ、洗練された機能設計に行き着くことがいかに困難であるかをおわかりいただけると思います。これらのコメントの中には、同じように有効でありながら、相反した考え方が存在することがわかります。また、「すべてに着手しろ」と言っているに等しいコメントもあります。この設計プロセスがまさにWindows という包括的な製品の枠組みの中で問題に取り組み、アイデアを機能にすることをしていく場所なのです。

Windows を開発する際の大きな課題は、それが単一製品であるにも関わらず固有の用途が幅広く多数存在することです。ある意味では、ソフトウェアの魔法的要素の 1 つは、それが「ソフト」であるがゆえに、わずかな追加コストと「素材」の変化ですべてのユーザーにすべての機能を提供できることです (すべての機能を用意して、オプションで使用するコンポーネントを選択できるようにしてはどうかという多数のコメントが継続して寄せられているのに対して、私たちは用意されていても使用されないコンポーネントや機能があった場合を考えてコストの最小化の観点で話をしてきました)。また、同時に、任意の PC が共通の機能セットを持ち、プラットフォームに特定の動作をさせる特定の API が用意されていて、それを利用できることがアプリオリに (経験からではなく自明のこととして) わかっている状態は、開発者にとって大きなメリットになります。このメリットはもちろん個人ユーザーにも当てはまります。どの PC を使用しても使い慣れたユーザーエクスペリエンスが得られるだけでなく、その PC でそのユーザー特有の作業をしたり、特殊なデバイスを使用したり、特定のプログラムを実行したりしたければ、それもできるのです。この幅広い機能性は Windows PC の価値の重要な要素です。しかし、それは同時に設計上のかなり難しい課題も生み出します。Windows 設計に対する幅広い入力情報を知り、理解し、それに基づいて行動することは、Windows の構築の中でも最高に楽しく、かつやりがいの多い部分です。

Larry が指摘したように、設計と機能選択は組織内の彼の担当部署で行われています (ここではありません)。リリース全体のテーマが決定される過程や、機能を連携させて矛盾なくまとめ、ユーザーのニーズにエンドツーエンドで対処するためのリリースへの全体的なアプローチの確立方法については、今後別のポストの中で話し合うことにしましょう。

私たちは、Windows の全体的な操作設計を担当する製品設計者のグループ (Windows のシーケンスと視覚エフェクトのグループ) を持っています。このチームの全てのプログラムマネージャーは製品設計者と協力しながら仕様を作成します。設計者とともに UX (ユーザーエクスペリエンス) リサーチャーも存在し、前にも話題にしたように、設計のテストと検証を担当しています。重要なことは、私たちが 1 つの機能を開発するためにあらゆる範囲のスキルを適用している一方で、責任の所在とエンドツーエンドの設計が明確になるようにしているということです。1 つだけ、私たちにとって未だに明確でないことは、製品に関して「1 人の担当者」がすべてに責任を持つべきかどうかということです。このことが潜在的な問題の原因だと考える人もいれば、これほど多くのユーザーに使用される、これほど幅広い機能を持つ製品を 1 つの観点 (それが開発、テスト、設計、マーケティングのどの観点であるにしても) で代表することはできないと考える人もいます。私たちは、エンジニアがエンジニアリングに集中できるように努めています。それはつまり、全員が実装に向けて努力できるように製品を明確に定義し、その製品の定義が、Windows を世界中のユーザーに届けるために関係したあらゆる部門の目標にかなったものになるように努力しているということです。そして、最も重要なことは、Windows 7 では、「エンドツーエンド」の設計に新しい方法で取り組んでいるということです。

ここで、Windows のエンジニアリングの主要な各段階を見てみましょう。これからお話しする内容はもちろん一般論であり、それぞれの具体的な事象にあてはまることではありません。私たちが社内でいつも言っているのは、私たちは学習する組織だということです。このようなことから、完璧なプロセスや完成されたプロセスなど存在しないという考えのもと、私たちは Windows 構築の各作業を繰り返しながら、常により優れたプロセスを目指して努力しています。

このポスト全体にわたって「私たち」という表現が出てきますが、これは、実際には、協力して作業する各部門 (プログラミング、テスト、プログラムマネジメント、デザイン) の各個人を指しており、特別な組織や設計委員会があるわけではありません。

論点を選択するかアイデアを得るか

私たちは、やるべきことのどこかからアイデアを得ます。アイデアとは、たとえば、壮大 (タッチ式などの新しい入力方式をサポートするユーザーエクスペリエンス:UX の構築) であったり、無謀 (ユーザーインターフェース：UI のパラダイム全体で 3D を使用するような変更) であったり、既存の機能の改善や洗練 (マルチモニターサポート) であったりします。アイデアが不足することはありません。なぜならば創造的なアイデアを得るということ自体は全体のプロセスの中では簡単な方なのです。アイデアは、私たちも含めたエコシステムのあらゆる部分から流れ込んできます。これまでに、このブログへのコメントやフィードバックについてたくさん述べてきましたが、これももちろん入力の 1 つの形です。また、製品レビュー、企業ユーザー、カスタマーサポート、PC メーカー、ハードウェアおよびソフトウェア開発者、ブログ、ニュースグループ、MVP をはじめ、その他の多くのものがチームに対する同様の入力ストリームを持ちます。

重要なのは、Windows に取り組むことは、実際に絶え間ない入力ストリームの中に身をおくことだと思います。私たちはまず、リリースのフレームワークを作成します。それは、私たちがより簡単に、より良く、より高速にしたいと考える目標やシナリオを表すものです。そして、そのフレームワークを使用して、プログラム管理が候補となるアイデアを作り、そのアイデアが発展して機能になります。機能を十分に「成熟した」ものにするのはプログラム管理の仕事で、担当者は製品全体を対象にしてこの仕事に取り組み、設計、開発、およびテスト部門と協力して作業します (Larry も述べているとおりです)。

アイデアがどこから来るのかについて言うなら、プログラム管理の仕事は、優れたアイデアを単に思いつくだけではなく、すべての優れたアイデアを最終的に確実に選択することです。優秀なプログラムマネージャーは、どこから来たものであっても、優れたアイデアを必ずうまく取り込みます。

情報とデータの収集

何らかのアイデアが与えられたとき、私たちが最初にすることは、そのアイデアの「周囲」のデータを理解することです。アイデア自体がデータ中心の形で与えられることもあれば (カスタマーサポートの案件)、逸話的で不確かなもの (ブログ) であることもあります。

私たちは最初に、アイデアにどのようなデータがあるのかを確認します。それは、特定の仮説の作成に役立つのか、一般通念を否定または支持するのか、問題の一部がクローズアップされているだけなのかなど、実世界でそれがどのように使用されるかをベースにした確認です。重要なのは、機能は入力された情報により多くの視点を加えることから発展するということです。

当然のことですが、私たちは仮説を解釈する客観的な視点を要求されます。私たちはこのようなデータを、エンドユーザー、ユーザー、パートナーなどの複数のソースから、多様な形 (クラッシュダンプなどのオンラインによる自動的データ送信、リサーチ、ユーザビリティ調査、競合製品、ユーザーからの直接のフィードバック、製品サポートなど) で収集します。

多くの人 (私たちも含みます) が指摘しているように、遠隔測定(テレメトリー)データには限界があります。第一に、そのようなデータでは、ある人物が何をしようとしていたのかはわからず、その人が何をしたかがわかるだけです。私たちが意図に関してデータをより多く得ることができるのは、ユーザビリティ調査の観察によってです。たとえば、High DPI のところでも述べましたが、遠隔測定であることが示されても、意図は違うものでした (しかもそのような選択が与える影響の大きさも意図されたものではありませんでした)。この事実を最適に解釈するには、PC ユーザーは「PC の使用に慣れる」ことに興味があるのではなく、自分の仕事 (または自分の遊び時間) を終わらせようとしているだけだということを忘れないことです。そして、「問題」に直面した時、ユーザーに与えられた唯一のソリューションはそこにあるボタンやメニューコマンドであり、ソリューションのフルセットはそこに存在するソフトウェアです。私たちの仕事は、問題の根本を探り当て、ソリューションを拡充するか、単に問題を消し去るかのどちらかです。

ニーズが不確かな場合を考えてみましょう。データ + 意図では「既知の世界」と「既知のソリューションスペース」が示されますが、私たちの役割の 1 つは、すべての潜在的なソリューションスペースを考慮することに慣れていないユーザーがあいまいに表現したニーズや要望を先見的思考で考慮することです。ソリューションスペースは、稼働中の製品から簡単に把握できる範囲よりずっと広い可能性があり、アーキテクチャの再構築、新しいハードウェア、新しいユーザーインターフェイスの発明などを伴う場合もあります。

このことをよく示す例が、タスクバーのポストへのコメントの中にありました。このコメントには (言葉は変えてあります)、タスクバーのアイコンの順序を重視しているユーザーが、開いているすべてのプログラムを終了し、タスクバー上に表示したい順に各プログラムを再起動する場合があることが示されていました。この場合、データは、起動/終了/起動/終了/起動/起動という奇妙なシーケンスに見えるでしょう。そして、誰かがそのようなことをしている理由を私たちが知るとしたら、それはこれらのデータ以外の手段によってのみです。ほとんどの場合、何の脈絡もなく「どうしたら Windows をもっと簡単にできるでしょうか」と質問しても、あまり意味のあることではありません。このように、この 1 つの例でも役に立つことが数多くわかります。たとえば、データがいかに意図を反映しないものであること、この「リクエスト」がどのリストのトップにもならないこと、ソリューションにはいくらでも形があり得ること、その中から適切なソリューションが作成されればかなり有用な機能になること、などです。そして何より、このことは、後から考えれば解決すべきであるということがきわめて明白な「問題」の 1 つです (きっと多くの読者が間違いなく「聞いてくれればよかったのに」と言うことでしょう)。このように、どのようなデータと情報を収集しても、どのような設計について話していても、誰かが必ずそれに気づいていたり、提案をしたりしているものだという教訓も、私たちは学んでいます。

仮説の作成

次の手順は明確な仮説を立てることです。たとえば、「異なるセッション間の位置関係を記憶すると、アプリケーションの切り替え時間が短縮され、Windows を制御し Windows に習熟しているという感覚が強まるため、アイコンの再配置はユーザーにとってメリットがある」などです。

このような仮説を、どのような機会が存在するか、どのような問題が解決されるか、ソリューションがどのようなものなるか、問題がなぜ存在するのか、などに関して (科学的な方法で) 吟味します。機能の設計には、問題 (なぜ問題が存在するのか) について考え抜き、次にその問題の解決によってどのようなメリットが得られるかを提案するという側面があります。重要なことは、提案されたソリューションのコンテキストでメリットを考えるということです。“そのほうがいいような気がする、あるいは何かが壊れてしまったので新しいものはそれより良くしよう”、と単純に考えて変更を行うのは簡単なことです。しかし一方で、“なぜそれがユーザーにメリットをもたらすのか”、という視点を常に持って考え続けることこそがとても重要なことだと思っています。

仮説に関するもう 1 つの重要な要素に、その領域をとりまく一般通念の理解があります。仮説がターゲットユーザーセグメント (エンドユーザー、熱心なユーザー、PC メーカーなど) に関連する場合、このことは特に重要です。一般通念は、ある機能がなぜそのようになっているのか、何かの問題に対してどういう解決策があるのか、ということがベースになっています。一般通念が非常に強力であるためにそのことを考慮に入れて設計をする必要があったり、設計段階では十分に検討されていなかったのにもかかわらず後で考慮する必要が出てきてしまった、という例は歴史的に数多くあります。有名な例にメニューのキーボードショートカットがあります。ショートカットは「DOS」の世界では必須だと考えられましたが (すべての PC にマウスが付属しているとは限らないため)、常にマウスが存在する Mac では「不要」と考えられました。DOS 世界の一般通念では、マウスはオプションだったのです。

実験

どのような仮説にも、多くの設計の選択肢があります。私たちが多様なオプションを幅広く検討するのはこの段階です。私たちは、スケッチをしたり、シナリオやストーリーボードを書いたり、ワイヤーフレームやさまざまなレベルのプロトタイプを作成したりします。私たちはその中で、単に「ベストアンサー」を特定するのではなく、問題の核心を探り、さまざまな観点で次の手順である検証に役立つ情報を残します。

これは設計プロセスの実に面白い部分です。私たちの会社の廊下を歩けば、あらゆる種類の選択肢がポスターとなって壁に貼られているのを見たり、各種の機能プロトタイプを抱えたプログラムマネージャーやデザイナーをつかまえたりできるかもしれません (PowerPoint は、プロトタイプを短時間で作成しシナリオやクリックスルーを確認する優れた UI 設計ツールであり、Visio もこれにたいへん役立ちます)。また、デザイナーはしばしば、私たちがラボですみずみまでテストできる、非常にリアルなプロトタイプを作成したりもします。

解釈と検証

多数のオプションを目の前に次に実行する手順は、選択肢、ユーザビリティテストのデータ、および外部から (チームへ) のフィードバック、などについての解釈です。これは、たとえば「オプション A は新機能をより高いレベルまで知ってもらえるという点で優れているが、オプション B は全体的なユーザーエクスペリエンスに溶け込んでいる感じが強い」などといった議論をしていく段階です。

私たち誰もが知っていることですが、ミクロレベルでは、特定の問題に対する完璧なソリューションを発見できる場合が多々あります。しかし、マクロレベルで考える場合は、まずどのようなソリューションでも賛否の両意見を確認することが始まりです。私たちが「テスト」のわなに陥らないように慎重にならなくてはいけない理由はそこにあります。ここでいうわなとは、ある機能を使用方法のコンテキストがすべて整った状態でテストするのは不可能な場合が多く、機能は特定のシナリオセットのコンテキストの中でしかテストできないということです。ある機能が可能性のあるすべてのシナリオや使用方法とどのように関連しているかをテストしつつ、意図に関する豊富なフィードバックも得るのは不可能です。テストの設計とその結果の解釈が、リサーチャーに率いられた UX への取り組みの中で非常に重要な部分となっているのはこのためです。

このことを数字的に捉える方法として、「ローカルな最小化」と「グローバルな最小化」があります。ローカルな最小化はカーブ上の誤ったポイントで最適化を開始する場合に見られます。ソフトウェアでのわかりやすい例として、ユーザビリティの課題に直面して新しいコントロールや UI ウィジェットを開発する場合を挙げましょう。新しい UI は、求められたテーマがウィジェットの適切な操作である場合はまったく理にかなったもので、テスト結果もすこぶる良好でしょう。しかし、私たちが追い求めているのは、新しいウィジェットの導入で得られるすべての潜在的なメリットを帳消しにして別のウィジェットに潜在的なコスト (コード、品質、およびユーザビリティの) が見込まれるような場合の全体としての最適化です。オプション間の選択に関する意思決定論の役割についてはいろいろ述べられていますが、設計に関する私たちの課題は品質的な要素をどれだけ優先できるかということです。

選択

最終的に、私たちは設計を選択しなければなりませんが、その選択は、質的にも量的にもあらゆる方面のデータに基づいて行われます。

ある設計の選択肢があり、その実装方法とコストを理解していても、さらに 1 つ選択することがあります。それは、そもそもその機能を実現すべきかどうか、ということです。これまでの作業をすべて行った後で、それでも特定の機能を構築しないかもしれないというのはおかしなことのように思えます。しかし、これは映画監督がシーンを撮影した後で結局それをカットするのと同じことです。設計が期待したようにはうまく行かなかったり、常識の範囲内で実装計画を作成できなかったり、単にもっと優れたアイデアが出てきたりする場合があります。実装に至るまでにはこのようにいろいろなことがあり、これも Larry が難しい課題だと指摘した点です。

私たちが機能と設計に優先順位をつけるときには、2 つのツールの助けを借ります。第１のツールは製品計画です。この計画は、製品で達成する「必要がある」ことを、シナリオ、業務目標、スケジュールなどの観点から、高いレベルで示したものです。機能は、単にリリースの全体目標と矛盾しそうだという理由で、プロトタイプ作成やテストに至らないことがほとんどです。これらの目標がなければ、製品に「整合性」がなくなり、「たくさんの個別機能」のようになってしまうリスクが生じるため、このような目標は重要です。これらの高レベルの目標から、私たちは、リリースに関してどのようなコードを扱い、どのようなシナリオを検討するのかについて多くの情報を得ることができます。

第 2 のツールはリリースの「設計原則」です。これらの原則は、私たちの言葉使いやボキャブラリのようなものです。これらは中核となる価値を表すもので、私たちは多くの場合、設計原則を製品の擬人化によって考えます。たとえば、「Windows が人間だったら、きっとこんな感じだろう」などのようにです。これは Sam が PDC で取り上げるトピックです。

冒頭部分でも言及しましたが、すべてを 2 度実行することはできません。私たちは決断しなければならないのです。このことは、カスタマイズ、互換モードなど、ポストの全シリーズにわたって言えることかもしれません。私たちは、これらのトピックに対する皆さんの声を確かに聞き、「微調整」と「現状維持」の両方を可能にするために常に膨大な作業を行っています。しかし、同時に私たちは、このような目標と、堅牢で適切な性能を持ったプラットフォームを提供するという目標のバランスをとり、この OS をさらに向上させなければなりません。私たちの中には Office 2007 に携わった者もいますが、Office 2007 の「互換モード」を提供するかどうかの意思決定に関して、面白いケーススタディ (Harvard Business School による) があります (フルテキストの取得には料金がかかります)。これは、当時は難しい選択だったため、数人がコメントでこのことに言及しています。

実装と統合

最後に、私たちは選択したソリューションを構築し、それを洗練する作業を繰り返します。実装段階で新しい発見があるのは必然的なことで、私たちはそれに応じて調整を行います。発見は、ソリューションを Windows に統合するときにも続きます。ベータ期間は私たちがどのように機能の展開を継続し、使用方法のデータやフィードバックから学ぶのかがわかる良い例です。ベータ版 Windows では、私たちはとりわけ互換性と実世界でのパフォーマンスに関心を持ちます。それは、これらが、優れたベータ版でなければ取得できない幅広い使用方法のデータによってはじめて検証のできる、設計の 2 つの側面だからです。

私たちが受け取ったすべての形のフィードバック (レビュー、ブログ、そしてもちろん製品がどのように使用されているかに関するすべての遠隔測定など) を真剣に追跡していることを、どうか忘れないでください (私たちは、ベータ版が一部のユーザーグループだけを対象にしていることを十分認識しています)。

私たちがこのブログで行いたいと考えていることの 1 つは、IE 8 ブログですでにおわかりかもしれませんが、製品の進化をリアルタイムで話し合うことです。段々とこのようなことを行う時期に近づいています。Windows 7で私たちが行った設計上の選択について、さらに話し合えるようになることを楽しみにしています。

-- Sam、Brad および Julie

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

e7blog — Tue, 23 Sep 2008 10:00:00 GMT

このブログがもたらす大変素晴らしい点のひとつは、コメントやメールで寄せられるトピックの裏側にある詳細な情報やデータについて、さらに詳しくお話することができる点です。皆様のご質問やご意見についてより深く説明させていただけるのは、非常に喜ばしいことです。今回は、高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点補足しますと、私たちが言う“バグ”とは、ソフトウェアが期待にそぐわない動作する事です　‐　つまり、クラッシュといった深刻な問題から、見た目上の問題まで、すべてが対象となります。私たちはこれらのバグを、１～４の段階でその深刻度（Sev）を分類しています。ここでSev1は、本当に深刻な問題（クラッシュ、データ損失、機能の欠落）、そしてSev4は非常に些細な現象、または、非常に発生率が低いものです。

調査の結果、多くのアプリケーションは high DPI において十分動作することがわかりました。ごく一部のアプリケーションでしか主要な機能が損なわれることはありませんでした。もちろん十分動作するアプリケーションは心配の必要がありません。ですがもし 1％のアプリケーションで high DPI において重大な問題があるとすれば、それは重要な数字です。そのため私たちはバグを調査し、発見された問題の種類ごとに分類しています。こちらは私たちが見つけた結果です。

私たちが見つけたことで、もっとも重大な問題のひとつはユーザーインターフェースの表示が欠けてしまうということでした。これをより深く調べると、それらのケースの多くでは画面の有効解像度が極めて低い (800x600 もしくはそれ以下) 時おこるということが明らかになりました。これに基づき、私たちはユーザーがそのような低解像度に設定するケースの数を最小化できるように設定画面をデザインすることができました。私たちは問題の種類を一つ一つ調査し、可能な場合はそれぞれの緩和策をとりました。もちろん最良の緩和策は予防であるため、High DPI は PDC やWinHEC、その他の会合において私たちが開発者の皆さんに対してお話しする重要な焦点になります。

総計 vs 個々のユーザーデータ

私たちの調査のひとつに何人のユーザーが現在 (Vista/XP で) high DPI を利用しているかという事があります。データによると、非常に少ない割合のユーザーだけが現在 high DPI の機能を有効にしています。これを、エンドユーザーはこの機能に関心がない、もしくは必要性がないという明確なメッセージだと安易に捉えることもできます。また別の説明としては、利用されていない主な理由が XP と Vista の high DPI に対するシェルのサポートが非常に限られており、これらのプラットフォームに搭載された IE の各バージョンでフォントサイズが合わなかったりウェブページの比率がおかしくなったりするという大きな問題があるからだという見方もできます。また、Vista以前からこの機能を利用されているユーザーがいらっしゃるという事も理解しています。また再度、私たちはデータを解釈する必要があり、今の段階では必ずしも明白ではありません。

タイミング: この時期にこの機能は市場にとって正しいでしょうか？

幸いなことに、私たちはハードウェアとソフトウェアのどちらが先に出てくるのかといういわゆる “鶏と卵” の問題を抱えていません。ハードウェアはすでにフィールドやマーケットに出ており、したがってOSが単にそれを利用するかどうかという問題だけです。ソフトウェアの観点からすると、多くのソフトウェアアプリケーションは (IE 8 のように改善されたズーム機能をもつブラウザも含めて) DPI に対応できていますが、かなりの数のアプリケーションで high DPI でうまく動作しない可能性があるものが存在しています。別の鍵となるデータとしては、LCD パネルのディスプレイ解像度が標準のDPIでは最大に達しつつあるということがあります。このようなディスプレイで1900x1200を超える解像度にすることはテキストが小さすぎて誰も読めなくなるため、OS の high DPI サポートなしには成し得ません。さらに、既にこの解像度では2 メガピクセルの写真や高精細なビデオ (1080p) を再生することができます。フィールドに既にハードウェアが存在すること、よりよいエクスペリエンスを可能にできる将来性、そしてハードウェアが現状では OS とソフトウェアによって制約されていることを組み合わせると、この件を論じるのは正しいタイミングだといえます。

結論

お客様のデータを調査することは、ウィンドウズエクスペリエンスを改善する方法を見つけるのに役立ちます。この場合私たちが、ユーザーがディスプレイを、メディア再生のための高性能なエクスペリエンスを楽しみ、テキストを適切なサイズに描画させるために設定を簡単にする機会が存在している事が明確にわかりました。とは言うものの、私たちはいつでもウィンドウズアプリケーションのエコシステムに影響を与える可能性の高い機能に投資する場合、皆さんのソフトウェアに対する投資を無駄にしないように注意したいと考えています。また、私たちは、ソフトウェア開発企業の開発者コミュニティと早期に、密にお話し、私たちが提供するプラットフォームの価値を、ソフトウェア開発者の皆さんが彼らのお客様にシームレスに提供できるように確認作業を続けていきます。現在までのところ、マイクロソフト社内のテストや私たちが収集したデータが、私たちが何かを適切に決めるにあたって、非常に重要なデータになっています。High DPI は、エコシステム全体の協力が問題の解決に必要であるという良い例です。また、それは人々が抱えている問題がなにか、それを解決するための最善の方法は何かを判断するために、市場のお客様のデータをマイクロソフト社内のテストとともに、どのように利用できるかという可能性も示しています。

--Ryan

最近の話題を振り返って…

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

私達がこのブログを始めた時考えていたのはオープンな対話をする、ということで、Windows 7エンジニアリングに関して世界中の方々と双方向の会話を実現したいと考えていました。私達はこの短い間に起こったことについては喜ばずにはいられません。私達がどのように製品を開発しているかについての議論を開始したところ、皆さんにとって正に重要なトピックに対してのコメントと投稿でのやり取りが始まりました。数字をいくつかあげると、私は個人的に400通のメールを受け取り(いくつかには返信をさせていただきました)、約500人の異なる読者から900個の英語でのメッセージをいただきました(10個以上のコメントをしてくださる方もいます)。ページビュー＋読者と言う観点では後者の数字の約10倍の人が参加されています。

このブログの読者のうちの何人かの方からは、私達がどのように機能を選択しているのか、日々のビルドプロセス、国際化、等、Windowsをいかに開発しているのかについて、さらに詳細を教えてほしいというご要望をいただいています。一方で、たくさんの皆さんがそれらの情報については十分に持っているので、機能の詳細について知りたいという別のご要望もいただいています。そこで、このポストでは既に話題になったいくつかの機能についての詳細機能およびその機能を選択するにいたった考え方を合わせてお話したいと思います。

私たちは頂いたレスポンスをうれしく感じています。Windows 7についての機能に関して質問を投げかけ合うためのフォーラムが作られているようです。そこで、私たちが何を始めようとしているのか、Windows 7がどのように作られようとしているのか、製品を作るにあたってどのように選択を行っているのか、について出来るだけお応えする事によりそれらのご質問にお答えしたいと思います。新製品の機能を列挙した長いリストを作って、「どうぞフィードバックをお寄せください」とブログに投稿するのは簡単なことです。こういうことは過去にも行われており、そうすることは人々を喜ばせ、製品づくりに関与したという風に皆さんに感じていただくためには、確かに簡単な方法なので（実を言うと私にとっては）魅力的なのです。しかし、全員を満足させるという点ついてそのようなフォーラムを作るという手法はいくつかの問題があります。まず、この手法は「リアクティブ」、つまりそれは皆様に単なる第一印象をお知らせくださいとお願いしているだけです。共通のコンテキストを持たずしては、お互いのモチベーション、優先度等について私達は共通の理解を得ることができないでしょう。これは時期が早過ぎ、私達が効果的に「マーケティング」できず、機能についての十分なストーリーを語ることができないようなケースで顕著です。二番目に、（自由に書かれたテキストでの）逸話のようなフィードバックは、実際には行動に結びつけられるようなデータではなく、このブログのような対話や議論を反映できません。このやり方で決定を下そうとすると、決定や優先度について同意できない「半分」の人々にとってはおもしろくない結果になります。そして三番目に、フィードバックをすることはそれをした人にとってはその方向に何かのアクションがあるはずだという期待感をあおってしまう傾向があります。これらがWindows 7をどのように開発しているのかについて様々なことをお話することにした理由です。

何人かの人は機能のリストを公開してそれに対してランク付け・投票というプロセスをすべきだ、という提案をされていました。実際、皆さんご自身のウェブサイトでこのようなことをされている人もいます。ありがとうございます – それらはとても面白いサイトであり、私たちはそれらのウェブサイトを拝見しています。しかし、皆さんの同意が頂けるかと思いますが、これらのセルフセレクトグループ（志願）のフィードバックは、意図的に代表としてセレクトされたグループ（選ばれた人達）のフィードバックとは違ってきます。Saturday Night Liveの古いエピソード, “Larry the Lobster”を思い出しました。Larry をストーブから救うか電話で投票できる話です。これは非科学的な投票です。しかし、非科学的な投票だとしても、これは動物保護に基づく動物の権利の話なのか、あるいは食べ物嗜好についての話なのかさえ分かりません。特定の機能について投票するというようなことは娯楽の範囲を超えていると私は考えています。私たちは同じコンテキストの中で問題を考えているかどうかについてエネルギーを費やしていかなければいけません。私たちはこれらのカスタマーのサンプルがブロードベースのカスタマーか、特定のターゲット“セグメント”のどちらかの代表になってほしいとも思っています。

このブログを立ち上げた主な目的は、何が重要で、私たちの相対的なコンテキストとは何かといった議論に対してお互いに耳を傾け合うためのフォーラムを作る事でした。そのために、ここにあるのは対話であると考え – 決して質問に対する回答、リクエストに対するレスポンス、指摘とそれへの反論、アナウンスやコメントというものではありません。私としてはこのブログに参加されている方々のダイナミックな活力を、次にどのような記事を書くかということの参考にしています。したがってこのブログはそれぞれの明確なゴールを持つビジネスミーティングもしくは一部の人間だけ話すようなトレーニングクラスのようなわけではなく、みなさんで集まって会って話す交流の場のようなものです。

この調子で引き続き、少し前に浮かび上がったいくつかの問題点についてお話ししたほうがいいと思います。皆さんはそれらについて見解を求めておられると思います。それぞれは個別のポストに値するほどのものでありますが、ここでいくつかの新機能の要望に対して私の意見を述べたいと思います。まず、パフォーマンスもしくはWindows 全体のエクスペリエンスについてお話をしていた際に浮かび上がったトピックについて触れてみたいと思います。これは、“コメント”に対しての回答とインプットになってしまうので、指摘と指摘への反論になり得ますが、さらなる議論に進める前に、できれば一度“コンテキスト”の議論を振り返りながら、深い議論ができればと考えています。

プロファイル ベースのセットアップ

機能のアイデアとして多くの方からセットアップのときにWindowsを特定のシナリオ（用途）に合うようにできることについて提案いただきました。そのうちの一部の方はゲーム、カジュアルな用途、仕事のため、ウェブ閲覧、電子メール、“ライトウェイトの用途”などのシナリオを提案されています。それらの提案には、もし私たちがそれら特定のシナリオ用にWindowsを調整すればもっと (速度や容量的に) よいパフォーマンスを発揮できるはずであるとの含みがありますが、実際にはそれほどうまくはいかないでしょう。この機能を検討するにはいくつもの方法がありますが、スタートメニューの内容を(企業において管理者がよくやられているように) 変更したり、あるいはいくつかの基本的レベルのコンポーネント(ディスクブロックサイズや TCP/IP フレームサイズなど) のパフォーマンスのチューンアップであったり、ユーザーインターフェースに磨きをかけるレベルのもの(“eye candy”と呼ばれる) などがあります。私たちはシナリオや役割ベースのセットアップがWindows Server 2008 の非常にポピュラーな機能であると理解しています。しかしサーバー環境ではそれらの各役割は個別の(異なる設定の)ハードウェアや非常に大きなマシン上の特定のVMであったり、明確に区別できるもの( ファイルサーバー、プリントサーバー、ウェブサーバーなどの) であったりします。

ところがデスクトップ PC (もしくはラップトップ) の場合はサーバーとは違い一台のPCに対して役割が特定できません。唯一まれなケースはPCがPOS端末のように単一用途である場合です。Product Planning の Mike がブログに書いたように、実際には私たちが特定のソフトウェアのみを実行するPCを見ることは殆どなく、私たちがこれまで行なった調査では、ほぼ全てのPCで他の人が実行しないようなソフトウェアが少なくとも一つ実行されています。したがってPCを特定用途に分類するといったことはするべきではありません。現在は PC を使用している際に役割が決まっていることもありますが、OS のゴールはワークロードの変化に際して十分に調整を行なうことです。Windows Vista における一つの例として新しい low-priority I/O APIs を使って、Indexer を低プライオリティにすることが挙げられます。”これを常に無効にしている” という人がいることを私は知っていますが、実際には前もってコストをかけることで、実行中のコストはとても少なくなります。そしてこれについては、Desktop Search 4.0 (ダウンロード用にリリースされています) と Windows 7 においても大きな改善が行われています。汎用のOSはワークロードに合わせて調整するべきです。私たちもすべてが完璧ではないことは承知しており、多くの (特にゲーマーの) 皆さんがパフォーマンス改善の可能性を一つ一つ探していることも知っています。しかし私たちはコアシステムサービスの”裏をかこう”とすることによって生じる複雑さと壊れやすさが、しばしば広範囲のお客様のところで確認されているように、パフォーマンス改善を妨げることも分かっています。ほんの少しだけ都市伝説を解決する余地があるかもしれません。－たとえば皆様がこれらにより達成できた系統的な結果を共有して、私たちがコメントでそれらを検証するというアイデアはいかがでしょうか。

もうひとつの挑戦がまさにこれらの分類を定義する事です。Office 95、Office 97のために私が一生懸命行ったことがこれです。私はセットアップ・ウィザードで簡単に、皆さんがどのくらいWord、Excel、PowerPointやAccessを使用するか、そして皆さんの職業（弁護士、会計士、教師）を分類できると考えました。それを利用して、どのアプリケーションをインストールするかを選ぶだけではなく、アプリケーションのどの機能をインストールするかを決定しようとしました。私たちは一貫して、二つの問題に出くわしました。まずに、人々を分類分けするための記述や質問を作る際のユーザビリティテストの時点で問題が現れました。それは選択の範囲が与えられると人々は、それらのすべての真ん中を選んだり、どれもふさわしくないと感じてしまったりするという古典的な問題でした。(人々は通常レッテルを張られるのが好きではありません)。そして私たちが常に直面していた二つ目の問題は、複数のユーザーが同じPCを使用している場合や、利用する時と場合によって役割を変えたり利用方法を変えたりすると言った問題でした。実は私たちの企業のお客様も、同じことを経験されていたという事がわかりました。そしてそれは”すべてをインストールする”ということになり、そして製品のすべての機能をインストールする時代が始まりました。すべてをインストールした後に、トレーニングなどで利用シナリオを狭めていったのです。

最後のチャレンジは、まさにこれをユーザーにいつどのように提供するかということでした。Out of box experience(箱を開けた後の体験) - OOBEの手順は、PCの箱を開けたときや、DVDからセットアップを行ったときに通過する手順です。そしてパフォーマンスの最適化をするための場所としてOOBEを検証するということが課題になります。このステップでパフォーマンス問題を解決することは、確かに挑戦であり、同時にOut-Of-Box Experience のための“コンテキスト”に続いていきます。

Out of Box Experience - “OOBE”

OOBEは、まさにユーザーが新しいPCでWindowsを最初に経験する場所です。Windows PCに対して競合製品のレビューで多く見られたように、たいていの人が持っているゴールは、“カッターで開封してから、いかに早くWebを見ることが出来るのか”ということになっています。 Windows 7に関して私たちは、OEMパートナーと密接に作業を行い最も合理化された使いやすさを提供すべく努力しています。もちろんOEMパートナーには新しいPCのセットアップの一部として、非常に多くの柔軟性や差別化の機会を提供させていただいております。また私たちが注意しなければいけない事はこの時の“コアOS”部分がPCを使って楽しむための必要最低限なものであるかどうかです。

この目的はさらに (購入時の) PC利用・使用の目的を測定するプロファイリングやウィザードを導入するということになっていきます。しかし、これはOEMパートナーがこのようなプロファイルされた情報を基に差別化されたOOBEエクスペリエンスを提供できないという訳ではありません。これは“コアOS”のインストール時にすべてのお客様に強いるものではありません。

PCファンである多くの皆さんは、様々なパッケージマネージャーの中の一つを使いLinux PCをセットアップされた事があると思います。(おそらくインストレールの成功まで何回もやられた事でしょう) これらのインストールを見て分かるとおり (特に最近はエンドユーザー向けにフォーカスしたものになっています)、不十分なシステムを構成する回数は、 (あなたが必要としている) 完全なシステムを構成する回数を上回っています。たとえWindows Installerのような、ソフトウェア依存関係マネージャーを使用したとしても、多くの構成要素が多くの他の要素に依存しており、最終的に、この依存関係を管理し、正しくする事はとても難しい事です。結果として、多くのソフトウェアがマシン上に存在している事はお客様にとっては有益です。もちろんそれはそのシステムをインストールするのが容易であれば、ということです。インストールとはフットプリントをバランスする事、接続のアーキテクチャ、システム信頼性などと同様に製品開発の一部です。

そこで、Out of boxエクスペリエンスに対する私たちの考えは、お客様に速やかに新しいPCを使用してもらい、最も興味のないであろうという点をこれ以上複雑にしたくないということがコンテキストになります。皆さんはこんな経験がありませんか？車のディーラーに行った時、車についての説明DVDを見終わり、そして車のガイドツアーが終わるまで鍵を渡してくれない事。もし皆さんが私に似ているのであれば、「鍵をくれませんか、早く試乗させてください！」、と叫ぶでしょう。かなり多くのPC購入者が同類であり、そして私たちの世界中で実施した調査結果も同じ結果を示しています。

また、私たちは、様々な理由により実行中のシステムの調節 (パフォーマンス、footprint, 画面の広さ等) をしたいというようなエキスパートユーザーがいる事を認識しています。これは皆さまよりすでにお聞きしている項目ですが、私たちは”Windows 機能の有効化と無効化”と呼んでいます。

Windows の機能

お客様が購入されたWindowsの全機能をインストールして、もしお客様が機能の一部を取り除きたいと思った場合何ができるでしょうか？お客様は一度も使う事がない幾つかの機能を削除したいと思うかもしれません。なぜなら、そのような機能を間違って使ってしまうかもしれませんし、また、使わないと分かっているようなコードを持ち歩きたいと思わないからです。お客様はPCを（たとえばキャッシュレジスターやPOS端末）として役割定義をしているかもしれません、その場合には特定の機能が入ってない事が必要かもしれません。それには多くの理由があります。多くのリリースのWindowsでは、Windowsの一部である様々な機能をインストールまたはアンインストール出来ました。Windows Vistaでは、この機能をさらに強固なものにしました。ある機能をアンインストールしても、再度利用しようとした場合オリジナルDVDを必要とせずに復元して利用できるようにしました。また、アンインストール可能な機能をWindows Vistaでは増やしました。

Windows 7ではこのリストにさらに多くのWindows 7の機能を入れて欲しいとの要望をたくさん頂いています。これは私たちがWindows 7で真剣に検討していることであり、Internet Explorer 8.0ベータ2の “選択とコントロール” のデザインゴールと一致していると思います。

Linuxディストリビューションは、ある機能を簡単に削除できるのですが、それをすると簡単に他の機能を壊してしまうことがあります。その結果、これらの“依存関係”をお客様に伝える複雑さと最終的に全ての機能が何か他の機能に繋がっているような感覚をお客様が感じてしまわれることもあります。私たちは同じチャレンジに直面しているのです。重複した機能があるいくつかのOSのインストールではこのようなパッケージングはとても有効です。(それぞれいくつかの、ファイルブラウザ、ウェブブラウザ、オフィススイート、GUI の中から一つを選択するからです)　コアWindows OSは、若干の機能の重複がありますが、このタイプの設定はありません。むしろ、私たちはカスタマーが望む多くのコンポーネントを追加できるプラットフォームを出荷しています。

Windowsコンポーネントの削除、リプレース、またはアクセスさせないようにしたいお客様のためにいくつかのツールがあります：

既定のプログラムの設定-Set Your Default Programs -SYDP((またはプログラムのアクセスとコンピュータの既定の設定- Set Program Access and Defaults-SPAD). Vista ではこれらの機能によって既定のプログラム/ハンドラーをファイルタイプやプロトコルによって設定することができます。このツールは Windows XP SP1 で取り入れられました。 Vistaで SYDP は拡張され、私たちは全てのマイクロソフトのソフトウェアが適切に登録され、このメカニズムを使用することを期待しています。そのため、もし既定のメールプログラム、既定のGIFファイルのハンドラー、またはWebブラウザーを選択したいならば、このユーザーインターフェイスを使えます。WindowsはすべてのファイルタイプについてSYDPが管理する既定値を優先に使います。
スタートメニューのカスタマイズ及びグループポリシー. 長い間、企業の管理者はスタートメニュー（プログラムマネージャーの時代からも）をカスタマイズすることで、指定したプログラムのみを表示させる “役割ベース” のPCを作ってきました。最近ではインターネットカフェでもよくみかけます。SPAD機能はこれを更に拡張していて、インストールされた電子メールプログラム、ウェブブラウザ、メディアプレーヤー、インスタントメッセンジャーとバーチャルマシンのランタイムへのアクセスを削除するためのエンドユーザー向けのツールを提供します。
コードの削除. 時々、お客様はただコードすなわちプログラムを削除したいと思われることがあります。多くの人々がSSD等の容量の少ないディスクに収まるように多くのWindowsのコードを削除してきました。私は確かにいくつかのWindowsの最少インストールをみてきました。Windowsからコードを削除するためには、(Vistaの)“Windows 機能の有効化と無効化”ユーザーインターフェイスが使えます。現在Vista Premiumパッケージのツールには80を超す機能が存在しています。

多くの人々はこのような追加/削除できるWindowsの機能が増える事を望んでおり、このサイトでも様々な機能を追加/削除できるようにしてほしいという提案をいただきました。これはWindows プラットフォームでは複雑です。なぜなら多くの開発者がWindowsプラットフォームの様々なコンポーネントに依存し、それらのコンポーネントが存在すると仮定して開発されるからです。たとえば、Windows アドレス帳を使うMedia Player、先進的なプリント　スプーリングを使う個人向け金融パッケージ、または先進的なネットワーク機能に依存する最新のブラウザーであるかもしれません。これらはソフトウェアのエンドユーザーの視点からは見えないシステムAPIの一般的な使用例です。

タブレットPCのコンポーネントの例の用に、いくつかの例は非常にわかりやすく、私たちは今後この方向性を増やしていこうと考えております。私は非常に小さいラップトップPCを持っており、そのPCにはフルタブレット機能がついています。しかし私にとってタブレット機能のインクを利用するには最適なサイズではありませんでした。(私は12.1インチ以上のスクリーンを好みますが、このPCは10インチスクリーンでした). タブレットのコードはメモリーを消費し、もしも私がこの1GBメモリーのマシンからタブレットのコンポーネントを取り除けば、そのマシンのパフォーマンスは良くなります。これは私が今できることです。皆さんからは、フォトギャラリー、ムービーメーカー、Windows Mail, Windows Calendarなどについても同様にしてほしいというご意見をいただきました。これらは私たちがWindows 7の開発で貴重なフィードバックとなりました。

重要な点は、皆さんが取り除いた機能の大多数は、実はほとんどリソースを消費しないということです(皆さんがそれらの機能を使用しないならば)。たとえPCの目に見える機能を減らすことができたとしても、PCのパフォーマンスを良くすることはできないでしょう。一つの例として、メール（またはニュース）のアカウントを構成しなければ、Windows Mailがパフォーマンスを悪くすることはあり得ません。もちろん、SPADによってこのプログラムへのアクセス制限する事も、好きなメールプログラムへのデフォルトプロトコルハンドラーの変更も可能です。もう一つの例として、皆さんは関連付けを変更し、もしあなたが望むならば二度とフォトギャラリーを立ち上げさせなくする事も可能です。それはこれらの機能によってメモリーが使われないことを意味します。

今回はこれまでに出てきた項目の詳細と、いかに私たちがこれらの議論から学ばせていただいているか、という話の続きをしました。それぞれの項目のいくつかについては私たちと皆さんは同じ考えに近づいていることを望んでいます。

今回は記録的に長いポストになりましたが、それほど多くはないようにいたします。J

--Steven

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

e7blog — Tue, 16 Sep 2008 10:00:00 GMT

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からプログラムに参加し、登録されているたくさんのお客様を通じての調査です。お客様は、まずアンケートに回答してフィードバックするプログラムに参加するか、または自動化されたフィードバックプログラム参加する、あるいはその両方に参加するかを選択できます。そのあと２０分ほどのプロフィール調査のアンケートに回答していただきます。このアンケートの結果は、フィードバックを後で分析する時の参考にさせていただきます。私たちのプログラムにはコンピューターの知識レベルに関して広い範囲の方が参加されています。そして私たちは参加者のコンピューター知識レベルが偏らないように常に調整しています。私たちのプログラムのようなフィードバックプログラムに自発的に参加される方の多くは、通常テクノロジーに関して非常に熱心な人たちです。彼らは、消費者向け電子機器、デジタル機器、ソフトウェアの新しいバージョンなどを、製品で出た早い時期から使い始める人たちです。対照的に、PCは仕事をするための道具と考えているお客様は、フィードバックプログラムに参加することをあまり好まない傾向があります。または、私たちは、もっと女性の方にプログラムに参加していただきたいと考えています。

自動化されたフィードバックプログラムに参加されたお客様には、Windows Telemetry チームが開発した自動的にデータを収集するツールをインストールしていただきます。このプログラムのプライバシーアグリーメントには、このツールが収集するデータについて記載されています。

いくつかの例をあげます。

Windows およびインストールされ使用されているアプリケーションの使い方
コンピューター上のファイルとフォルダーの構成、およびフォルダーに入っているファイルの種類の数、例えばピクチャフォルダにある JPGファイルの数など
コンピューターにインストールされているハードウェア、デバイス、ドライバや設定などシステム固有の情報
Customer Experience Improvement program (訳注：日本語訳はカスタマエクスペリエンス向上プログラム) のデータ

集められたデータから、Windows フィーチャーチーム、プランナーやユーザーリサーチの専門家が利用するレポートを作成します。以下のチャートは、次の質問の答えを示しています - 「私たちのプログラムに参加するお客様が彼らの PCの中に保存する最も一般的なファイルタイプは何でしょうか? そしてそれらの保存先として最もポピュラーなものは何でしょうか?」

この結果は、プランニングを行う上で私たちがお客様のPCに保存されている大量のデータをいかに取り扱うかを検討するためと、私たちがテストラボで現実と同様のファイル数、ファイルサイズそしてPC上のファイルの位置などのテストシナリオを作成する際に役に立ちます。

更にこれらの収集されたデータにより、私たちはプロファイルされたパネリストに基づくレポートを作成することができます。もし、私たちが私たちのプログラムに参加する2、3の異なったプロファイル、例えば開発者によって提供されたデータに基づいた場合や、ゲームプレイヤーによって提供されたデータに基づいた場合、では上記のチャートは異なるように見えるかもしれません。またWindowsに対する理解度によっても違いが生じるでしょう。従って、自身を Windows のエキスパートであると考えているお客様も、PCは何か物事を成し遂げるためのツールであるとしてとらえ、PCに対して自分たちの時間を費やすことを快く思わないお客様も、私たちにとって大変重要です。データに基づいて、私たちは特定のプロファイルのためにある機能性を最適化することを決定するかもしれません。

一般的に、私たちは、Windowsの次のバージョンで何を改善するべきかについてよりよく理解するために、このデータを利用します。これらのサンプルによって彼らのモニターがどう設定されているか見てみましょう。まず、お客様はどんな解像度でPCを使うでしょう？以下の表はWindows Customer Experience Improvement Program（データ提供に合意したすべてのＰＣをサンプリングしたデータ）に基づく典型的な解像度とその分布をリストしています。（以下の表にはすべての解像度が含まれないので、合計が100%にならない点に注意してください）：　

（約10％のお客様はHD以上の解像度をお持ちです。）

まず気づくことは、およそ10%のユーザーがHDまたはそれ以上の解像度を利用しているということです。いただいたいくつかのコメントの中で、我々のデータは「トップ」か「パワーユーザー」を代表しているのかという質問がありました。サンプルの大きさや、業界をリードする解像度を選択しているユーザーの数を見ると、私はこれが十分にすべてのセグメントを代表しているデータであると合理的に結論づけることができると思います。

このサンプルはとても大きなデータセット（すべてのWindowsのお客様）から取られた、大きなサンプル（データ提供に合意した顧客）であり、従って、セグメント別の研究のために統計学的に有意であるということが言えます。

私たちは、大部分のプログラム参加者が、彼らのディスプレイの最高解像度よりも、表示解像度を下げていることを見出しました。Windows Customer Experience Improvement Programから来るデータと比べてみても、やはり類似した傾向が見られます：1600x1200画面解像度をもつ50%以上のユーザーが解像度を1024x768に調整しています。これは、おそらく、高解像度ディスプレイで小さいテキストを読むことを不快に感じているからでしょう。この解像度変更によるマイナスの影響としては、エディタとウェブブラウザでテキストを読むことが難しいほど、精細さが失われてしまうことです。高解像度ビデオコンテンツは、正しく再現することができません。

これは1600x1200の表示機能があるディスプレイをお持ちのユーザーだけを対象としたデータです：

（68％のユーザーが、1600x1200の表示機能を持つディスプレイで、それよりも低い解像度を使用しています。）

近い将来のブログでは、ディスプレイの品質向上のために、また、快適に文字が読めるように、Windows7において私たちがどんな対応をしたかについて、Windows Desktop Graphicチームのプログラムマネージャーによる解説をご紹介する事になるでしょう。

私たちはまた、これらのデータを頻繁に活用し、アンケートにご参加いただける方を適切に選別する為に役立てています。たとえば、あるリサーチャーが、バーチャルマシンで動作するアプリケーションのユーザーのみを対象として、オンラインアンケートを送信する事に関心を持つ事もあるでしょう。まず、“アプリケーションの使用形態”のデータを調べ、対象となるユーザーを決め、それから、リサーチャー向けに参加ユーザーのリストを作成します。また時には、ユーザー皆様の全体的な満足度とPCの環境設定情報との関連性を解析するために、私たちは自動的に収集したデータをアンケートの返信情報に結びつける事を行っています。

現時点、私たちの調査パネル参加者の50％が、Windows XPを使用し、50％が Windows Vistaを使用しています。また現在、この調査パネルは、自由にご参加いただける形体にはしておりません。もし、お客様がこのプログラムに参加される事にご興味をお持ちでしたら、こちらのメールアドレスにご連絡ください； winpanel@microsoft.com　（件名に“Notify me for enrollment”とご記入ください）。また、Windowsの知識をどの程度お持ちかといった、お客様自身の情報をほんの少しでもご提供頂けるなら、私たちはそのご協力に非常に感謝致します！お客様を参加登録待ちリストに追加し、参加枠が空きしだいご招待差し上げる様、最大限努力致します。

Windows 7のベータ版をリリースした後も、Windows 7 ベータ版をご使用になられているお客様へ対し、調査パネルへの参加のお願いと、調査パネルからのフィードバック収集を行う予定です。なお、ベータへのサインアップのご案内は、Microsoftのこれまでの方法と同様に、http://connect.microsoft.comより実施する予定です。お見逃しなく！

-- Christina Storm