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

次のエンジニアリングマイルストーン: RTM

e7blog — Thu, 23 Jul 2009 13:43:51 GMT

本日、Windows 7 プロジェクトにおいて重要なマイルストーンを迎えました。Windows 7 チームは、先ほど Windows 7 を PC OEM や製造パートナーへリリースし始めました。皆様にお知らせできることを光栄に思います。次の大きなマイルストーンは、Windows 7 を搭載した PC や Windows 7 のパッケージが店頭に並ぶ 2009 年 10 月 22 日になります。

このブログでも何度もお話ししてきたように、PC エコシステム全体の幅広い参加なくして、このマイルストーンに到達することはできませんでした。Windows 7 は Microsoft だけでなく、あらゆる種類のパートナーの業界全体の製品です。Windows 7 の開発期間中、非常に多くの人々が関与し、 Windows 7 のエンジニアリングプロジェクトが関連するすべてのパートナーの方々にとってよりよいものとなるように、たくさんのご協力をいただきました。Windows 7 開発期間中のフィードバックや連携は計り知れないほど有益でした。これらの作業は、このブログでも数多く論じられてきたような素晴らしい効果を生み出しました。それは、いろいろな種類の PC ハードウェアや周辺機器を、とても簡単に、追加設定などすることなく使えるようにすることです。完璧なインストールや、新しく開発されたデバイスのとても簡単な接続法は、パートナーの皆様とのコラボレーションがなければ実現しませんでした。すばらしい仕事をしてくださったハードウェアパートナーのすべてのエンジニアの皆様に対して、Windows チームを代表し心からお礼申し上げます。

Windows 7 は、これまでリリースしてきたソフトウェアの中で、最も広く深くテストされた製品のひとつです。数千人の開発者が初期の段階で使用した 2008 年 10 月の Pre-Beta に始まり、Beta がそれに続き、そして 5 月の RC では何百万もの人々が製品を (しかも複数の PC で) 問題なく動かすことができました。以前もお話ししたように、さまざまなハードウェアおよびソフトウェア構成で、広範にしかも詳細に Windows 7 を使用していただいたことで、かつてないほど改善されたOS の品質を生み出し続けるようにするため、重要なツールを提供することができました (そして、今後も提供し続けます)。

Windows 7 を開発するうえで、みなさんとの対話も重要視しました。おそらく、みなさんは私たちにとってもっとも厳しい批評家であり、かつ、強力なサポーターです。私たちは、みなさんの Windows 7 に対する大きな期待や OS を開発しているチームへのいろいろな要求について理解しています。このブログは重大な項目や重要な決定を公表するのに役立ち、私たちはそれについて議論を重ねてきました。その間、一緒に取り組むことについて、また、みなさんにとって重要な具体的な項目について、本当にいろいろと学びました。さまざまな観点がある中で、適正なバランスを見出せるよう一生懸命取り組んできました。また、私たちの Windows 7 エンジニアリングのアプローチについて、透明かつ率直で誠実にお伝えしてきたつもりですが、みなさんにもそう感じていただければ幸いです。このブログでの会話は Windows 7 の開発で忘れられないものであり、オフィスの廊下やレドモンド、ひいては世界中で、みなさんから寄せられたフィードバックについて討議し対応するために、トータルで何千時間もが費やされました。(訳注：このブログの翻訳は、日本のWindows 開発チームが担当しました。翻訳にも非常に多くの時間を費やしてきましたが、私たちは翻訳が本業ではないため、わかりにくい表現があったかもしれません。お詫び申し上げます。昨年の夏、スティーブン・スノフスキーから、「多少日本語がぎこちなくても投稿の遅れがあってもよいので、Windows 7 の開発の実情を理解している実際の開発者が翻訳をしてもらいたい」という指示を受け、私たちが始めました。当初はこれほどまで多くの投稿があるとは予想しておらず、途中で挫折しそうにもなりましたが、おかげさまでどうにかここに至ることができました。この日本語版のブログによって私たちの想いもお伝えすることが、少しはできたかもしれません。また、このブログは、私たちが日本の多くのパートナーの皆様と協業を進めていくにあたり、大変有益なものとなりました。ありがとうございました。)

RTM のマイルストーンに到達はしましたが、本当に「完了」するソフトウェアプロジェクトはありません。私たちは実世界で Windows 7 がどのように使われていくかについて引き続きモニターし、対応していきます。Beta や RC のプロセスを私たちのサービスをテストするためにも使いましたが、この製品の重要な側面に対してすばらしい仕事をしようと固い決意で望んでいます。ハードウェアパートナーはこれからも新しいデバイスを提供し、既存のデバイスに対するサポートを向上し続けるでしょう。PC メーカーからは Windows 7 の新しい API や機能用に設計された PC がたくさん店頭にお目見えすることでしょう。ソフトウェア開発者もたくさんの新しいソフトウェアを出してくることでしょう。今後の展開にとてもワクワクしています。

Windows のように大規模なソフトウェアプロジェクトはまれで、私たちのチームはそのことに誇りを持っています。そして、これまで何度も申し上げてきたように、重大な責任に対し常に謙虚であり続けたいと考えています。私たちは、最高のエンジニアになるために、そして世界中のさまざまなお客様に最高の OS を提供するために、製品をどのように開発していくかについて、これからも学習し改善をし続けていきます。エンジニアであることは学習するこということであり、その学習は製品を設計し生み出す経験によってもたらされます。そして私たちは、エコシステムのみなさんと一緒に、共に学習し、共に素晴らしい製品を作り上げてきました。

Windows 7 をいつどうやって入手できるか、たくさんのご質問があるかと思います。そして Windows 7 の機能を実際に使用していかれるとともに、さらに質問が出てくるでしょう。本日の Windows Team Blog にはたくさんの最新情報と重要な詳細情報が掲載されているので、それらがみなさんの質問の回答になれば幸いです。これからWindows 7 がどのように展開していくか、どんなハードウェアやソフトウェアが出てくるか、私たちのブログを引き続きご覧ください。

RTM に至る最後の数分は、サインオフというプロセスが行われました。これは、Windows に貢献したすべてのチームが、製品をリリースするために必要な仕事を成功裏に完了したことを正式に誓約するものです。私たちは「シップルーム (Windowsの品質を常時モニターする毎日の定例会議が行われる会議室。リリースを最終決定する。)」に (Windows 7 としては) 最後にもう一度集まり、各チームからの代表者が (文字通り) サインをして自分のチームが RTM の準備ができていることを表明しました。ここで、その瞬間をみなさんと分かち合いたいと思います。

Windows 7 のエンジニアリングチームを代表して、すべてのエコシステムパートナーの方々、そしてWindows 7の開発にご協力いただいたすべての方々に対し、心より感謝申し上げます。そして、今後とも Windows 7 をよろしくお願いいたします。ありがとうございました。

次は 2009 年 10 月 22 日です!

--Windows 7 チーム

PDCが終わって・・・次は、WinHEC

e7blog — Fri, 07 Nov 2008 10:03:41 GMT

今週は Windows 7 チームにとって特別な 1 週間でした。私たちは、今週の PDC での Windows 7 の皆さまからの反応に対してとても感謝しています。ありがとうございます！

私たちチームのメンバーは全員、Windows 7 の Pre-Beta を触っていただいた結果のニュースやブログの記事を注目していました。反応はすばらしく、私たちはこのリリースに対する皆様の興奮や熱意に恐縮しています。これから Beta や RTM への道のりに対して、私たちにはまだたくさんの仕事が残っておりますが、この反響を受けて更なるやる気がおきてきます。（もちろんもうすでにかなりやる気がありましたが。）

来週は私たちが今まで話をしてきたエコシステム内のハードウェアパートナー様向けのカンファレンスがあります。WinHEC （Windows Hardware Engineering Conference）と呼ばれるイベントで、そこでも多くのセッションやキーノートを行います。“ファンダメンタル”の詳細についての話題をJon DeVaanがリードして行いますし、Windows 7 にかかわっているたくさんのパートナー様との成果をお話できると思います。WinHEC では Windows Server 2008 R2（Windows 7 のカーネルを使ったサーバー）についてもお話ししていきます。また、これらのセッションの内容はオンラインで提供いたします。

これらのショーがありますので、このブログは一時中断いたします。なぜなら、プレゼンテーションをする人たちがこのブログの執筆者でもあるからです。（私も含めて）
次の表は PDC にてのWindows 7 関係のすべてのセッションです。この情報を是非お読みください。これらはとても詳細な情報になっています。たとえばこれらの記事に対するフィードバックについてコメントをいただくことによって、今後さらに詳細な情報をこのブログでご提供させていただくというアイデアはどうでしょうか？今後のポストでどんなことを扱うべきか、参考材料としてとても有益な情報になります。

たくさんの皆さまからベータ版の参加、入手方法について問い合わせをいただきました。それらの情報については私たちの製品マーケティング部が作成管理しているこのサイトhttp://www.microsoft.com/windows/windows-7 をご覧ください。ベータに関する情報が準備でき次第こちらで発表いたします。さらに、Windows Vista Blog にても Windows 7 に関する発表、ニュースを掲載していくようにアップデートしました。ブログの名称も Windows Blog に変更しました。

私にとってPDCにて楽しかった時間の一つに“Big Room”にて行われた公開討論の“Open Space”セッションがあります。Channel 9がこの模様を収録したので、ご覧ください。http://channel9.msdn.com/posts/Charles/Steven-Sinofsky-at-the-PDC2008-Open-Space/
Windows 7 APIや開発者向けの新機能について興味をお持ちの皆さまに対しては概要を説明した資料があります。MSDN の Windows 7 Developer Guide　です。

たくさんのメールをいただき本当にありがとうございます。私はそれらをチームと共有しており、とても感謝しています。

Presentation	URL
KYN02 Day Two #1 - Ray Ozzie, Steven Sinofsky, Scott Guthrie and David Treadwell (Windows 7 starts +17:00 minutes)	http://channel9.msdn.com/pdc2008/KYN02/
PC01 Windows 7: Web Services in Native Code	http://channel9.msdn.com/pdc2008/PC01/
PC02 Windows 7: Extending Battery Life with Energy Efficient Applications	http://channel9.msdn.com/pdc2008/PC02/
PC03 Windows 7: Developing Multi-touch Applications	http://channel9.msdn.com/pdc2008/PC03/
PC04 Windows 7: Writing Your Application to Shine on Modern Graphics Hardware	http://channel9.msdn.com/pdc2008/PC04/
PC13 Windows 7: Building Great Audio Communications Applications	http://channel9.msdn.com/pdc2008/PC13/
PC14 Windows 7 Scenic Ribbon: The next generation user experience for presenting commands in Win32 applications.	http://channel9.msdn.com/pdc2008/PC14/
PC15 Windows 7: Benefiting from Documents and Printing Convergence	http://channel9.msdn.com/pdc2008/PC15/
PC16 Windows 7: Empower users to find, visualize and organize their data with Libraries and the Explorer	http://channel9.msdn.com/pdc2008/PC16/
PC18 Windows 7: Introducing Direct2D and DirectWrite	http://channel9.msdn.com/pdc2008/PC18/
PC19 Windows 7: Designing Efficient Background Processes	http://channel9.msdn.com/pdc2008/PC19/
PC22 Windows 7: Design Principles for Windows 7	http://channel9.msdn.com/pdc2008/PC22/
PC23 Windows 7: Integrate with the Windows 7 Desktop	http://channel9.msdn.com/pdc2008/PC23/
PC24 Windows 7: Welcome to the Windows 7 Desktop	http://channel9.msdn.com/pdc2008/PC24/
PC25 Windows 7: The Sensor and Location Platform: Building Context-Aware Applications	http://channel9.msdn.com/pdc2008/PC25/
PC42 Windows 7: Deploying Your Application with Windows Installer (MSI) and ClickOnce	http://channel9.msdn.com/pdc2008/PC42/
PC43 Deep Dive: What's New with user32 and comctl32 in Win32	http://channel9.msdn.com/pdc2008/PC43/
PC44 Windows 7: Programming Sync Providers That Work Great with Windows	http://channel9.msdn.com/pdc2008/PC44/
PC50 Windows 7: Using Instrumentation and Diagnostics to Develop High Quality Software	http://channel9.msdn.com/pdc2008/PC50/
PC51 Windows 7: Best Practices for Developing for Windows Standard User	http://channel9.msdn.com/pdc2008/PC51/
PC52 Windows 7: Writing World-Ready Applications	http://channel9.msdn.com/pdc2008/PC52/
ES20 Developing Applications for More Than 64 Logical Processors in Windows Server 2008 R2	http://channel9.msdn.com/pdc2008/ES20/

それでは、またすぐこのブログでお会いしましょう！

--Steven

Engineering 7: 下からの視点

e7blog — Thu, 06 Nov 2008 16:31:43 GMT

あるいは: Windows 7 開発プロセスについての一プログラマーの視点

このポストは Larry Osterman によるものです。Larry は Windows チームの最も「経験豊かな」開発者の 1 人で、1980 年代半ばからマイクロソフトで活躍してきました。Windows チーム全体で、Larry より長くマイクロソフトに勤めているエンジニアは他に 3 人しかいません。私は1989 年にマイクロソフトに入社しましたが、その頃 Larry と知り合ったときのことを覚えています。Larry は "マルチメディア" (当時はマイクロソフト CD-ROM カンファレンスをホストしていました) に従事しており、私が出席した最初の社員総会で、Bill Gates から "5 年勤続" 賞を受け取った人々の内の 1 人でした (当時はそれがすごいことに思えたものです)。Windows 7 に関しては、Larry は Devices and Mediaチームの開発者です。このチームでは、オーディオ、ビデオ、Bluetooth、および Windows にデバイスを接続するためのすべての最新機能の開発を担当します。

Larry はすぐにこのポストを書き上げ、非常に多くの Windows リリースに関する経験を提供してくれました。これらの考察はみなさんと共有する価値が大いにあります。このポストは、私たちがどのようにチームとして機能しているかについて扱っており、ソフトウェア開発チームの一員である人すべてにとって大変興味深い内容となるでしょう。ここでは Vista との比較対照が行われますが、誰もが知っているとおり物事を行う完璧な方法というものは存在しませんし、一つの観点を示しているに過ぎないことをお断りしておきますが、おそらく興味を持っていただけるのではないかと思います。

と言うことで、ありがとう Larry! --Steven

発言する機会を与えていただいたことに感謝します。

ここでは、Windows 7 の「開発」に携わった私の経験を提供し、それを Windows Vista を開発した際の私の経験と比較したいと思います(このブログで皆さんがこれまで読んでこられたその他の技術記事とは対照的に)。これらの考察は「私の」個人的な経験であることに留意してください。他の人には別の経験があることでしょう。それらについてもいずれここで共有してもらいたいと思います。

Windows 7 の開発の経験は、Vista のそれとはかなり異なっています。製品開発プロセスの概要は変わっていませんが、組織的には、Windows 7 のプロセスが格段に優れています。

Windows Vista では、私は WAVE (Windows Audio Video Excellence) グループの一員でした。このグループは、成果物に最終責任を負う部長によって統率されていました。テストリーダー、開発（プログラミング）リーダー、およびプログラムマネジメントリーダーが存在し、これらのリーダーは部長に報告を行いました。ある機能の開発プロセスは、大体次のように機能していました。プログラムマネジメントリーダーは、Windows に対してどの機能が開発されるか、またどのプログラムマネージャーがどの機能に責任を持つかについて決定を行います。開発（プログラミング）リーダーは、どのプログラマーがその機能に責任を持つかを決定します。プログラムマネージャーは、プログラマーと連動して、機能的な仕様 (機能の内容と動作方法を説明したもの) を作成します。テスト担当者はプロセスのこの部分に必ずしも関わらないことに注意してください。機能に責任を持つプログラマーは設計仕様 (機能がどのように実装されるかを説明したもの) を作成します。次に、この機能に関連するテスト担当者は、機能をどのようにテストするかを説明したテスト計画を作成します。プログラムマネージャーまたはプログラマーは、それぞれの機能に対するウィルス脅威モデルを作成します。

その後プログラマーは機能のコーディングにかかり、プログラムマネージャーは機能開発が順調に進んでいることを確認し、そしてプログラマーの作業が終われば、テスト担当者がテストケースの作成を開始します。

機能がコーディングされ、ソースツリーにチェックインしたら、その機能は "winmain" ブランチに進みます。余談ですが、Windows ソースコードは “ブランチ” として組織されています。ルートは “winmain” で、最終的に Windows Vista となるコードベースです。各開発者は、"フィーチャーブランチ" と呼ばれるもので作業し、このフィーチャーブランチは変更を "集約ブランチ" にマージし、集約ブランチが winmain となります。

機能がコーディングされたら、テスト担当者はテストを実行し、プログラマーはバグを修正し、プログラムマネージャーはプログラムを管理します。製品開発が進むにつれて、バグ修正を winmain にチェックインすることは段々と難しくなっていきます (すべてのバグ修正には、その修正による副作用を発生させる可能性が存在するため、各バグ修正に関連するリスクを判定する必要があります。そしてその許容の幅はプロジェクトが進むにつれて小さくなっていきます)。このプロセスの管理を担当するチームは、「シップルーム」（出荷できるかどうか最終決断をするミーティングルーム）に集まり、どの変更を製品に加え、どの変更を省くかについて日々決定を下します。この決定に関しては激しい議論が交わされることがあります。品質に責任を負うさまざまなチームが、特定の修正に関連した利点について話し合うため、この討論は何時間にも及ぶことがしばしばありました。

全体として見ると、これはマイクロソフトで何十年もの間続けられてきたソフトウェア開発手法とそう変わりません (そして大学のソフトウェア工学のクラスで教えられたやり方とも基本的に一致しています)。

Windows 7 では、経営側は Windows の組織、とりわけ私が所属する WEX [Windows Experience] 部門のエンジニアリング構造を変更することにしました。過度に階層的である代わりに、Steven は、それぞれ特定の領域を表す 3 つの直属チームを設置しました。開発（プログラミング）、テスト、およびプログラムマネジメントです。各領域のリーダーの下に6 人ずつ責任者が存在します。これらの 2 番目のレベルのマネージャーの下には、さらに別に6 人ほどのリーダーが存在し、各リーダーに 5 ～ 15 の部下がおります。このレポート構造には賛否両論がありますが、私の意見では、今までのところ著しく成功を収めていると言えるでしょう。

もう 1 つの大きな変更は、「トリオ」の概念の導入です。「トリオ」は、各領域すなわちプログラミング、テスト、およびプログラムマネジメントの集合体を意味します。実質的に、現在すべての作業はトリオによって組織されています。グループが特定の分野に集中する必要が生じる場合、そのプロセスを管理するためにトリオが編成されます。これは、すべての 3 つの領域がそのプロセスに関わることを意味します。管理のすべてのレベルがトリオによって表されます。WEX 内の主要なグループそれぞれのトップにトリオが存在し、2 番目のレベルのリーダーのそれぞれがトリオを形成し、というようになります。私のグループ (Devices and Media) にも同様に、トップにトリオが存在します (それぞれのマネージャーのイニシャルを表す DKCW として知られています)。サウンドチーム (私の属するチーム) 内では、別のトリオ (それぞれのリーダーのイニシャルから SNN として知られる) が存在します。セキュリティ、パフォーマンス、ソフトウェア互換性を担当するトリオもあります。

Windows Vista と同様、これらの 3 つの領域のリーダーが集まって、各リリースに含める一連の機能を決定します。その後彼らは各機能を実装するための "フィーチャー (機能) チーム" を作成します。通常フィーチャーチームは、1 人または 2 人のプログラマー、1 人のプログラムマネージャー、および 1 人または 2 人のテスト担当者で構成されます。

Vista と Windows 7 での大きな違いが生じるのは次の点です。Windows 7 では、フィーチャーチームは機能全体に責任を持っています。チームが全体で設計にあたり、次にプログラムマネージャーは機能仕様を作成し、開発者が設計仕様を書き、最後にテスト担当者がテスト仕様を作成します。フィーチャーチームは共同でウィルス脅威モデルやその他のさまざまなドキュメントを作成します。上層部経営陣が継続的にフィーチャーチームに対して機能仕様に関する指示を与えてきた Windows Vista の開発とは異なり、Windows 7 では経営側は開発プロセスそのものにはあまり関わりません。フィーチャーチームがコーディングを始める準備ができている (そして 3 つの主要なドキュメントに署名を済ませている) と判断すると、フィーチャーチームは 2 番目のレベルのトリオ (私の場合は DKCW) とミーティングを行い、機能の健全性チェックを行います。2 番目のレベルのトリオは計画の実行可能性についてフィーチャーチームに詳細なフィードバックを提供する機会を得るため、プロセスのこの部分は非常に重要です。

その後、チームはようやくコーディングを開始します。おおまかに言うとそのような形になっています。チームが「準備ができた」と見なされるために、追加のレビューもあります。たとえば、セキュリティトリオのメンバーから、各機能のウィルス脅威モデルのレビューを受ける必要があります。他のトリオによってレビューされるいくつかのドキュメントも提出しなければなりません。

ある機能は、それが完成するまで winmain ブランチにチェックインすることは許可されません。ここで言う完成とは、本当に完成を意味しています。機能は、winmain に到達する前に出荷可能な状態である必要があります。ユーザーインターフェース（表示されるメッセージなど）は確定していること、機能は完全に動作すること、といった具合です。また、フィーチャーチームが別の Windows 7 の機能に依存している場合、その 2 つの機能を担当する 2 つのフィーチャーチームが、サービスレベルアグリーメント(SLA)に署名し、各チームが相互依存関係について理解していることを確認する必要があります。この SLA は特に重要です。というのは、これによりチームがお互いの依存チームについて知っていることが保証されるからです。そうするなら、設計を変更したり、ある機能の一部をWindowsから削除しなければならなくなった場合でも、その機能に依存する他のチームが驚かされることはありません (もちろん、失望はするかもしれません。しかし驚くような状況にはなりません)。また、コンポーネント間の統合を強力にするのにも役立ちます。なぜなら、あるチームが別のチームについて知っているので、両方のチームがより密接に提携できるようになるからです。

Vista の開発時を振り返ると、機能開発が複数のマイルストーンにまたがってしまうことがときどきありました。機能は完全には機能しないツリーの中にチェックインされていました。Windows 7 では、フィーチャーチームは機能的に完成した一貫した機能を作成するよう強制されました。私たちは、各マイルストーンがその製品における最後のマイルストーンであると仮定して働き、それ以降に仕事を行うようスケジュールしないようにと告げられました。それは、機能の実装を先延ばしにするのではなく、マイルストーン内に着実に行われるようにチームが集中することを意味しました。

基本的には、Windows 7 の開発プロセスは3 か月ごとのマイルストーンに渡ってスケジュールされました。各マイルストーンには 6 週間の開発期間と 6 週間の統合期間が与えられました。この統合期間とは、実質的に機能を微調整し、相互運用性の問題のほとんどがなくなったことを確認するための時間です。

さあ、これで背景知識は十分でしょう (Windows 7 についてのポストの半分以上が実際には Windows Vista の話であるというのは良くありません。しかし前提をはっきりさせておくことが必要でした)。最初に述べたように、このポストは Windows 7 における一開発者としての私の経験を述べたものです。Windows 7 では、私は 3 つの別のフィーチャーチームで働きました。最初のチームは 2 つの機能を提供し、2 番目のチームは 8 つの異なる機能 (すべて比較的マイナーな機能) を提供し、3 番目のチームは 3 つのメジャー機能と 2、3 のマイナーな機能を提供しました。また、私は WEX Devices and Media セキュリティチーム (これが私の脅威モデリングに関する一連のポストが生まれた所です。私は脅威モデリングに関して D&M のメンバーと共に働いていたときにこれらのポストを書きました) のプログラマーとしても働きました。また、Windows 7 の開発企画の開始時には、ユーザーシナリオを担当するトリオの中、プログラマーとして働きました。そのときはサウンドチームが定義したシナリオが、一貫していてかつ簡単に使えることを確認することに責任を持っていました。

加えて、テストチームが計画プロセスの非常に早い段階で加わり、価値のあるアドバイスを提供してくれたため、私たちはコード上で完成しているだけでなく、テストの点でも完成した機能をマイルストーンの終わりまでに確実に開発することができました (Vista の開発時には、いつもそういうわけにはいきませんでした)。そしてそれは私たちが開発した機能が実際にテスト可能であることも確認しました (これは馬鹿げたことに聞こえるかもしれないとわかっています。しかしある機能をテストすることがどれだけ難しいかを知ればおそらく驚かれると思います)。具体的な例として、私たちは計画プロセス中に、M2 (マイルストーン 2) において取り組んでいた機能の 1 つが、そのマイルストーン中には完成できないことに気付きました。それで、マイルストーンが完了する前に、その機能を削除しました (より正確に言うと、システムを変更して新しいコードがその製品の一部とならないようにしました)。次のマイルストーン中に、テストチームがテストケースの作成を完了した後に、私たちはその機能を再び有効にしました。しかし、私たちは設計哲学には忠実でした。マイルストーンの終了時点で、"メイン" ブランチにチェックインされたものすべては、完成していました。それらはコードおよびテストの両面で完成しており、M3 なしで Windows 7 を出荷しなければいけないとしても、未完了のテスト作業は残っていませんでした。これは Vista からの大幅な変更です。Vista では、コードが完成したらそのコードにただチェックインし、テストチームにその後の処理を任せていたのみでした。テストチームを初期の段階からプランニングプロセスに統合することにより、テスト組織をそのような困難な状態に陥らせないことを保証できるようになりました。結果的に、開発プロセス全体が手に負えない状態に陥ることを防いでくれるものとなりました。それぞれの機能は、複数のマイルストーンにまたがって開発可能であり、実際にそのようになることに留意してください。実際、サウンドチームの機能の 1 つは、3 つのマイルストーンにまたがって提供されるようスケジュールされていました。その機能に関連するフィーチャーチームは、Windows 7 の開発の完了時にはいつでも価値あるものを提供できるよう、作業を注意深くスケジュールしました。

私がこれまで働いてきたフィーチャーチームは、それぞれフォーカスしているものが大幅に異なっています。ある時はコアオーディオインフラストラクチャに焦点を当てていましたし、別の時は UX (ユーザーエクスペリエンス＝使い勝手) の変更にほぼ完全に集中しており、またある時はより全体的なレベルのコンポーネントと関連していました。マイルストーンがそれぞれ異なったため、私はそれぞれ劇的に異なるシステムの一連の部分の開発に関わることができました。これは、それまでには経験したことのない貴重な体験でした。

Windows 7 では、リリースするための品質基準を満たせない機能を削るという難しい決定を下さなければいけない場合、それを担当しているチームに対してマネジメント上層部が非常に協力的でした。また、プランニングから長い道のりを経て、結局はその機能に関連した作業があまりにも多くて予定された時間内に完了できないだろうということが判明したメジャー機能も確かに存在しました。Vista では、機能を削るようにマネジメント上層部を説得することは困難でした。しかしWindows 7 では、フィーチャーチームが難しい決定をしなければならないとき、マネジメントはそういったチームを支援しました。マネジメントがフィーチャーチームにいつも言って聞かせたメッセージの 1 つは、"削減は出荷につながる" ということで、それは真実でした。ある機能の実装が遅れているなら、その機能によってシステム全体の出荷の可能性を危険にさらすよりは、その特定の機能を提供「しない」ことに決定する方がずっと良いのです。通常の Windows リリースには数千もの機能があり、その内 1 つか 2 つの機能が準備できていないためにシステム全体の遅れにつながるとしたら、本当に残念なことになってしまいます。

Windows 7 の開発プロセスはこれまでになく透過的でした。組織の下層にいたとしても、どのように決定が行われているかをよく理解できるのです。そしてこの高度な透過性は、部下を持たない一スタッフとして、私自身もスケジュール作成に関してより良い決定に貢献できることを意味します。この透過性は実際のところ、さまざまなフィーチャーチームにそれぞれ独自の決定をさせようというマネジメント側が決定したことの直接の副産物です。フィーチャーチームをプランニングプロセスのより深い部分に加わらせることにより、チームは通常より良い決定を下せるようになります。

もちろんこの透過性は双方向に働きます。チームがプランニングプロセス内で生じていることを知ることができるようになっただけでなく、マネジメント側が開発チーム全体にわたって標準化されたレポートのメカニズムを導入したため、階層内の各レベルのリーダーは、今だかつてないレベルまで、プランに対する進捗状況を追跡できるようになりました。一開発者としての視点からすると、これを実現するためのオーバーヘッドはそれほど煩わしいものではありませんでした。基本的に週 1 回、各作業項目について、計画に対する進捗状況を更新するよう求められました。その状況が次に一連のスプレッドシートと社内ネットワーク上のウェブサイトページにまとめられ、それによって各マネージャーはすべてのチームの計画に対する進捗状況を追跡できるようになりました。これにより、マネジメント側はどのチームが問題を抱えているかを容易にまた素早く識別し、予定通りに事を進めるために適切なアクションをとる (デザインを簡略化したり、より多くのプログラマーを割り当てたりする) ことができるようになりました。

概して、Windows 7 を開発することはとても楽しく満足感のある体験でした。私たちはいくつか本当に価値のある機能を開発できたと思っていますし、そのすべてのプロセスに渡ってシステムをとても安定した状態に保つことができたと考えています。

--Larry Osterman

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

次のエンジニアリング マイルストーン: RTM

PDCが終わって・・・次は、WinHEC

Engineering 7: 下からの視点

次のエンジニアリングマイルストーン: RTM