アイデアの発想から機能の実現へ: 設計の観点から
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