Engineering 7: 下からの視点
あるいは : 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