次の方法で共有

Windows 7 チーム

  • [アーティクル]

私にコメントやメールをくださった皆さん、ありがとうございます。こういった形のコミュニケーションを開始できたことを大変ありがたいと思っています。このブログは私たちの職場でも大きな話題となっています。まずは Windows 開発チームの紹介を始めるのがよいでしょう。このポストではこのブログで述べられるチームの概要をお話したいと思います。

本題に進む前に、このブログに期待されていることについてもう少しお話しましょう。一番目は、私が受け取ったコメントとメールに関してです。私は非常に多くのコメント、メールを受け取りました。(週末の大部分はそれらを読むのに費やしました。) それらの中には明らかに幾つかのテーマがありました。まずはそれらの反応が非常に温かい雰囲気であったことに対し、我々は深く感謝しています。最も多くあったリクエストは、Windows のパフォーマンス、あるいは「Windows の更なる高速化」についてでした。このトピックには実に多くの関連事項がありますので、私たちは次の数ヶ月間それについてたくさんお話したいと思います。特定の要求も多くありました。ある方々が「xxx を取り除いてください (しないでください)」と言われる一方で、他の方々は「xxx を残すのは (そのままにしておくのは) 本当に重要です」と言われるように、問題に様々な側面があることを表してくれました。私にとってこのブログが重要である理由は、どんな問題に対しても複数の視点があることを気づかせていただけるからです。たとえば「パフォーマンス」のように二元 (速いか遅いか) しかないようなものについてさえ、多くの微妙な要素があることが分かります。例えば、ある人は起動時のパフォーマンスを向上するためにはアイドル時間ができるようになるまで何も開始しないことだと提案される一方で、他の人は遅延ローディングの手法によってさらに遅くなってしまうと感じていらっしゃいます。さらに他の人は、最適なアプローチはスタートアップマネージャーを提供しユーザーが何を開始するか決められるようにすべきだとおっしゃいます。これらすべての方法にはそれぞれに議論すべきメリットがあり、このようなもっとも単純明快なリクエストであっても複雑であることを示しています。

二番目は、何人かの皆様からこのブログの記事の“信憑性”についての疑問をいただきました。これはJonと私の二人にとっては驚きでした。一部にはこれらの記事には“ゴーストライター”がいるとか、このブログそのものが何かの策略ではないかという指摘もありました。私は今まさにこの記事をWindows Live Writerで直接書いて、Publishボタンを押しています。このBlogは本物です、タイプミスや何かの間違いも含めて本物です。仲介人もいなければ記事の審査もありません。我々のチームの中からこれからこのBlogに記事を提供してもらいますが、記事に署名している人間以外が記事を書くということは絶対にありません。セキュリティと所有者を明確にするために記事には一つのユーザー名を使いますが、実際にPublishボタンを押す人が署名いたします。（もし、私がコメント欄に参加するときは私のMSDN名である、steven_sinofskyを使います。）

三番目は、このブログがどれくらいの頻度で更新されるかという点です。私たちが“定期的”に更新しますと言った場合、それは更新のスケジュールや日付が決まっているということではありません。私たちは機械的に決められたような頻度で更新することはしません。それは一般的にブログとしては不自然なことだと思います。私たちは、皆さんがよくご存じの IEBlogのような形にしたいと思っています。また、私の社内向けブログに対し、（本当にそうかどうかはわかりませんが）あまり価値がないと言ってきた人は今までおりません。J

ブログの最初の紹介で書きましたように、まずはWindows 7 の開発 （“どのように”開発しているのか) についてお話するのが良いと思います。次に、製品自体（“なぜ”、“何を”開発しているのか）について書く前に、開発を行うエンジニアについてお話しましょう。

それでは、チームの紹介から始めます。

Windows チームは１つのまとまったグループと考えられがちです。そのWindows チームを代表する者がいて、コンファレンスで話したり、本や記事を書いて皆さんによく知られている場合もあるでしょう。その代表者もブログを持っているかもしれません。マイクロソフト社内では、Windowsは、全社的な製品であり、すべての製品グループが何らかのかたちで関わっています。その中で、Windows チーム“本体”のマネージメントをJonと私が一緒に担当しています。Jon はCore Operating System チームを統括しています。Core Operating System とは、主に、カーネル、デバイス インフラストラクチャー、ネットワーク、エンジニアリング ツールおよびシステム (クライアントとサーバーの両方) を指しています。一方、私は Windows クライアント エクスペリエンスのチームを統括しています。このチームでは、主に、シェルやデスクトップ、グラフィック、メディア サポートの開発を行っています。その他には、Windows 製品の主要な機能である Windows Media Center があります。これは、IPTV、エクステンダーなど、マイクロソフトの他の TV 関連技術とともに管理されている重要な機能です。

大規模なチームの組織編成をしていくことはたいへんなことです。最も重要なのはチームの仕事をプランすることです。このプランニングは、Windows 7 の全体的な統一性や「一体感」の向上という我々のゴールを達成するうえで、やらなくてはならないものです。このため、我々は、ひとつの大きな組織とか、2つのチームととらえるのではなく、約 25 の異なるフィーチャー (機能) チームで構成された、ひとつの Windows 7 エンジニアリング チームであると考えています。

各フィーチャー チームは、Windows 7 の各パートを担当し、設計、プログラミング、品質、開発全体の管理などを行います。また、フィーチャー チームはそのフィーチャーのオーナーとして、他のチームのフィーチャーと調整をしていきます。こうして、管理しやすい規模のチームを作ることができます。ひとつの部屋で一緒に会議することができますし、一緒に映画に行くことだってできます。平均的なフィーチャー チームは、約 40 名のディベロッパー（プログラマー）で構成されていますが、チームの規模はまちまちです。フィーチャー チームは、どんな分野を担当しているのか、どういった人が所属しているのか、という2つの観点から説明することができます。

Windows 7 のフィーチャーチームは皆さんがよくご存じのWindowsのそれぞれの機能のように見えるかもしれません。Windowsの基盤となる機能を担当しているようなチームは、いくつものリリースにわたり、まったくそのままの状態を継続し続けている場合もありますが、一方で新しくコードを開発し新しいエリアを担当するチームもあります。いくつかのチームはサーバー(例えばVM)に関する多くの仕事をしていますし、またいくつかのチームはWindows 7とは別の大きな製品(例えばInternet Explorer)を持っています。

一般的にフィーチャーチームはアーキテクチャに係るコンポーネントと、Windows全体にまたがるシナリオの両方に責任を持ちます。「フィーチャー(機能)」という単語はある人達にとってはユーザーインターフェースの一つを意味し、ある人たちには伝統的なアーキテクチャに係るコンポーネント(例えばTCP/IP)を意味するので、常に気をつけて扱わなくてはなりません。我々のアプローチは、広さと深さをいつも考えて、シナリオとアーキテクチャの全体的なバランスをとることです。また、チームが仕事全体に対してオーナーシップを持つことができるように「ユーザーインターフェース」からその基礎となる要素技術を分離しないようにしています。(例をあげると、「Find and Organize」チームは検索のためのインデックス処理エンジンとユーザーインターフェースの両方を作成します。)Windows 7の主要なチームのいくつかを紹介します(アルファベット順)

  • Applets and Gadgets (アプレットとガジェット)
  • Assistance and Support Technologies (支援、サポート技術)
  • Core User Experience （コアユーザーエクスペリエンス）
  • Customer Engineering and Telemetry (顧客工学とテレメトリー)
  • Deployment and Component Platform (展開とコンポーネントプラットフォーム)
  • Desktop Graphics （デスクトップグラフィックス）
  • Devices and Media (デバイスとメディア)
  • Devices and Storage (デバイスとストレージ)
  • Documents and Printing (文書と印刷)
  • Engineering System and Tools (工学システムとツール)
  • File System (ファイルシステム)
  • Find and Organize (検索と整理)
  • Fundamentals (基盤)
  • Internet Explorer (IE 8 ダウンレベルも含む)
  • International (国際化)
  • Kernel & VM (カーネルとVM)
  • Media Center
  • Networking - Core (ネットワーキング - コア)
  • Networking - Enterprise (ネットワーキング - エンタープライズ)
  • Networking - Wireless (ネットワーキング - ワイヤレス)
  • Security (セキュリティ)
  • User Interface Platform (ユーザーインターフェースプラットフォーム)
  • Windows App Platform (Windowsアプリケーションプラットフォーム)

これらの名称は、このポストの目的からすると、十分直観的であると思います – この先のポストでは、チームのメンバーが取り組んでいるフィーチャー(機能)について明らかにしていきます。この一覧により、Windowsのサブシステムがどのようなものか、大きなプロジェクトをどのように意味のある単位にブレークダウンしているかが、おわかりいただけると思います。もちろん、プロジェクト全体を通じて、チームをまたがって、協力してフィーチャー(機能)を作っています。これはやり方の問題であり、設計時には、効率とパフォーマンスのため、しばしばコードを一つのレイヤーとして設計します (ボトムアップ)。エンドユーザーは層をまたがって機能を利用します。また、ITプロフェッショナルはデスクトップをトップダウンで管理したい、ということがあります。こういった分類ではあまり面白いことが見えてこないので、少し内部的すぎる見方であるかもしれません。例えば、タブレットとインキングの機能は音声認識、マルチタッチ、アクセシビリティと同じの我々のUser Interface Platform teamに属しております。すべての層の設計に関わる人間がいないとしても、すべての“入力”の機構を共通のインフラストラクチャーとして設計しなくてはならないという理由があるからです。このやり方ならば、入力を管理するAPIを設計する際に、ユーザーインタラクションのすべてのモードを一つのAPIセットによって実現することができます。

フィーチャーチームのもう一つの特徴はその構成です。フィーチャーチームは核となる3つのエンジニアリングの職種である、software development engineers（sdeまたはdevまたはデベロッパー）、software development engineers in test (sdet または test。すみません、まだ外部向けにtestの職務内容を書いていませんでした)、program mangers(pm) により構成されます。これら3つのエンジニアリングの職種の存在がMicrosoftの一つのユニークな点で、この事実は何人かのリサーチャーの目にも止まっています。私の古いブログではdevとpmについて解説していますのでそこへのリンクをはっておきます。（SDETについても同じような事を書かなければいけません！）

これらの職種についてのもっとも短い説明は、devはアーキテクチャとコードに対して責任を持ち、pmはフィーチャーと仕様書に責任を持ち、testは検証および顧客の使い勝手を最終的に判断します。品質とパフォーマンスに関しては全員がそれぞれの立場で責任を持ちます。すべてのフィーチャーに対して、dev, test, pm のそれぞれがひとつのチーム（文字の上でも概念の上でも）として仕事を進めていく。Windows 7の開発を確実に、かつバランスよく取り組むために、これが非常に重要な“パワーのバランス”です。組織的に、dev はdev のために働く、sdet はsdet のために働く、そしてpm はpm のために働く。つまり我々は“エンジニアリングファクション”で編制されているのです。これには二つの利点があります。それは、それぞれの開発領域と専門職種にフォーカスできること。そして、サイロのように分断されているのではなく組織全体の製品開発が可能になること、です。

これら３つの職種はいつも１セットで考えられます。なぜならば、フィーチャーを開発するためには、n 人のデベロッパー、n 人のテスター、n/2 人のプログラムマネージャがともに作業をするからです。この比率は非常に安定しています。Windows 7 プロジェクト全体を通してひとつのフィーチャーチームに平均40人のデベロッパー(dev)が所属しています。

さらに、開発グループ全体のために仕事をするチームがあります：

· コンテンツの開発（ Content Development ） – オンラインアシスタント、Webサイト、SDKドキュメント、およびデプロイメントドキュメントを開発するライター、編集者です。

· 製品企画（ Product Planning ） – カスタマーリサーチ、リサーチの結果をもとにフィーチャーの選定に対して提案を行う。製品企画チームは製品デザイン、リリースに向けてパートナーとの協業も調整していきます。

· 製品設計（ Product Design ） – インタラクションモデル、グラフィカルランゲージ、及びWindows 7 のサポート言語をすべて設計します。

· リサーチ及びユーザビリティ（ Research and Usability ） – 既存の製品と新しい機能をどのようにユーザーが取り扱うかを調査する、フィールドスタディ、ラボスタディを行います。

ある人は、Windowsチームは大きくなりすぎて開発をしていく上で様々な問題が出てくるようになってしまった、と言います。一方で、Windows はもっと変わるべきだとか、もっとたくさんの機能がほしい、という非常に多くの要望があることも、いただいたコメントから伝わってきます。Windows を開発するにはそれなりの規模のチームが必要になります。それは大きなプロジェクトです。私たちの仕事はWindowsチームを適正な大きさに保つことだととらえています。－ 決まり文句ですが、私が言いたいことは、Windowsチームは大きすぎず、小さすぎないようにあるべきだということです。大きな成果物を作るには大きなチームが必要です。しかし意味のある成果を出すためには効果的にチームを管理しなければなりません。映画のアマデウスの中の、あるシーンを思い出します。皇帝が、フィガロの結婚は“多くの音符がありすぎる”と言います。それに対して、モーツァルトが応えました。“確かに多くの音があります。しかし、陛下、それは多すぎず、少なすぎず、すべて必要な音なのです。”皇帝からのもう少し音の数を少なくせよとの提案に際して、モーツァルトはただ言いました。“どの程度少なく、と、お望みでしょうか？”当然のことながら、Windowsチームは、機能やシナリオに対する開発要望に応じて構成されています。そこで課題になるのは、目的を達成するために、そしてチームの可能性を最大限に活かすために、正しいチームを正しい形で持つということです。－ 多すぎず、少なすぎず。

毎回のポストは４ページを超えないようにとお約束しました。そろそろ紙面が尽きたようです。いただいておりますコメントは素晴らしいもので、今後のこのブログの内容を考えていく上で役立つと思います。今回の話がさらに新しい話題のきっかけとなればと思っています。

--Steven