Vistaで実際に起こったこと：インサイダー回顧

従来、Windows開発チームは、Windowsの新しいバージョンのリリースでポスター（この場合はDVDイメージ）に署名します。 リリースパーティが終了するまでに、数百または数千の署名があります。

「経験は、必要なときにのみ得られるものです。」-スティーブン・ライト

Terry Crowleyの有益なブログ（ 「Vistaで実際に何が起こったのか」 ）が気に入りました。 TerryはOfficeグループで働き、Windows Vistaを取り巻く複雑な陰謀と関連するが放棄されたLonghornプロジェクトを外部の観察者の観点から説明する素晴らしい仕事をしました。



彼はプロジェクトを悩ませた問題の多くを正しく指摘しました、そして私は再びそれらについて繰り返したくありません。 同じイベントをインサイダーに見てもらうのは正直だと思いました。 私はテリーと同じ雄弁または網羅的な説明は期待していませんが、何がうまくいかなかったのかを明らかにしたいと思っています。 Windows Vistaの最初のバージョンがリリースされてから10年が経過しましたが、これらの教訓は今ではかつてないほど関連性があります。



Windowsはモンスターです。 数千人の開発者、テスター、プログラムマネージャー、セキュリティ専門家、UIデザイナー、アーキテクトなど そして、これは、人事部門のスタッフ、リクルーター、マーケティング担当者、営業担当者、弁護士、そしてもちろん、これらの各分野の多くのマネージャー、ディレクター、副社長を数えていません。 このグループ全体は、パートナー（マイクロソフトの内外両方）からの何千人もの従業員に囲まれています。従業員は、機器やデバイスドライバーからプラットフォームで実行されるアプリケーションまですべてを提供しました。









Microsoftのサッカー場でのWindows開発チームの航空写真



当時、Windowsは組織上、実際にはコア、サーバー、クライアントの3つのグループに分かれていました。 Coreグループはフレームワークを提供しました：すべてのバージョンのWindowsに共通のオペレーティングシステムのすべての主要コンポーネント（カーネル自体、ストレージ、セキュリティ、ネットワークサブシステム、デバイスドライバー、インストールおよび更新モデル、Win32など）。 次に、サーバーグループはサーバー市場のテクノロジー（ターミナルサービス、クラスタリングおよびスムーズな運用、企業管理ツールなど）に焦点を当て、クライアントグループはデスクトップおよびユーザーバージョン（Webブラウザー、メディアプレーヤー、グラフィックス）に関連するテクノロジーを担当しました、シェルなど）。



もちろん、多くの再編成がありましたが、Windowsの人気が高まり、グループ自体の規模が大きくなった場合でも、基本的な構造は常に残りました。 また、文化的および組織的な観点から、コアグループはクライアントグループよりもサーバーグループに近かったと言っても過言ではありません-少なくともVista以前はそうでした。



1998年の初めにマイクロソフトに入社した時点では、WindowsはWindows NTを意味していました-アーキテクチャ、組織、および製品自体に関して。 Windows 95コードベースはほぼ放棄され、Windows NTは、ラップトップからクラスタ内のサーバーまで、Windowsの各タイプに導入されました。 2年後、Windows 95/98コードベースは最後の1つのリリース（非常に話題になったWindows MEそのもの）で復活することになっていますが、このプロジェクトは小さなグループによって実行され、大多数はNTコードベースで作業しました。 私は幸運にも、怪物の子宮で10年以上過ごしました。 私はWindows 2000の開発の最中に開始し、Windows 7が完成するまで滞在しました。



最初の7年間は、ストレージ、ファイルシステム、稼働時間/クラスタリング、ファイルレベルのネットワークプロトコル、分散ファイルシステム、および関連技術を担当するグループで過ごしました。 その後、マイクロソフトセキュリティ管理チームで1〜2年過ごしました。 これには、Windowsセキュリティテクノロジからウイルス対策製品、セキュリティマーケティング、セキュリティ更新プログラムのリリースなどの緊急対応まで、すべてが含まれていました。 ウイルスやワームがWindowsをひどくし、安全で安全なソフトウェアの開発者としてのMicrosoftの評判が大衆にひどく打ち負かされたとき、それはVistaのライフサイクルの終わりに近づきました。



過去3〜4年間、Windows 7のリリースの準備中に、Windowsでコアグループの開発全体を管理しました。 これは、「ボンネット内」で動作し、サーバーグループとクライアントグループの両方で使用されるほぼすべてのテクノロジーを所有していることを意味します。 Vistaのリリース後、Windowsチーム全体が組織のすべてのレベルで方向とトライアド（Dev、Test、PM）で編成されたため、私は2人の犯罪パートナーを抱えていました。 私は開発チームを率いましたが、テストチームと管理グループをそれぞれ率いていました。



過去のWindowsチームは、数年後に放棄または再設計された野心的で大規模なプロジェクトを圧倒しようとすることがよくありました。 前の例は野心的なCairoプロジェクトであり、最終的には破壊されました。Windows2000に含まれる一部のパーツのみが保存されました。



私の謙虚な意見では、これまでのWindowsの最大の問題は各リリースの長さでした。 平均して、各リリースは開発の開始から完了まで3年かかりましたが、「新しい」コードの開発にかかったのはこの6〜9か月だけでした。 残りの時間は、統合、テスト、アルファおよびベータステージに費やされました-それぞれ数か月間。



一部のプロジェクトでは、主要な開発に6か月以上を要したため、並行して作成され、完了時にメインコードベースとマージされました。 これは、大きな機能が追加または変更されたため、メインブランチが常に限定されていることを意味します。 Windows 7の開発中に、継続的に健全で機能するコードベースを保証するために、より厳密な制御が確立されましたが、以前のバージョンは数か月連続で不安定で常に不健全な状態でした。



開発の混oticとした性質により、開発チームはスケジュールを立てて危険なゲームをプレイすることがよくありました。 彼らは、自分たちのコードは他のプロジェクトよりも良い状態にあり、残りのフラグメントを時間通りに「研磨」できるので、コンポーネントを半完成状態にできると確信しました。



3年のリリースサイクルは、リリースの時点で競合環境と外部エコシステムがどのように見えるかをほとんど想像していなかったことを意味しました。 機能の開発にリリースの時間がなかった場合、（開発の開始から6年後にほとんど意味をなさないため）完全に放棄されたか、さらに悪いことに、「シベリアに送信された」、つまり、ほとんどの部分が無視されたコンポーネントの開発が続けられました組織の残りの部分と失敗または無益に運命づけられた-しかし、グループまたは管理は、単に開発を放棄することを決定することができませんでした。 私は個人的にこれらのプロジェクトのいくつかを担当しました。 過去を見るときのビジョンは100％になります。



各チームがリリースで独自の計画と一連の機能の宣伝に忙しかったため、他のコンポーネント、ユーザーインターフェイス、エンドツーエンドのテスト、および更新などの不快で退屈なものとの統合を頻繁に省略し、これらの困難なものを後から残す。 言い換えると、これはいくつかのグループが開発全体のボトルネックになり、土壇場で全員がUIの作業を完了したり、更新メカニズムをテストしたりするために走りました。



それぞれの時点で、開発中のいくつかのメジャーリリースと多数のサイドプロジェクトがありました。 さまざまなグループが準備状況の異なるコードベースを担当し、最終的には「金持ちは金持ちになり、貧しい人は貧乏になる」という結果に至りました。 何らかの理由で遅れ始めたグループは、通常、遅れをとっていました。



プロジェクトが完了に近づいたとき、プログラムマネージャーは次のリリースの要件を作成し始め、「健全な」状態（リッチ）のグループは新しいコードの実装を開始しましたが、組織（貧しい）のほとんどは現在のリリースを引き続き調査しました。 特に、テストグループがリリース前にリリースされることはめったになかったため、プロジェクトの開始時には、新しいコードは徹底的にテストされていませんでした。 「不健康な」グループは常に遅れをとっており、現在のリリースの最後の仕上げを行い、ますます遅れています。 これらのグループでは、士気が最も低く、疲れ果てた開発者がしばしば働いていました。 これは、グループの新しい従業員が（退役した人の代わりに-約Per。）彼らが書いていないため理解できなかった脆弱なコードを継承することを意味します。



Vista / Longhornの開発期間のほぼ全体にわたって、ストレージとファイルシステムを担当しました。 これは、私がWinFSプロジェクトに関与していたことを意味しますが、主にWindowsチームの姉妹構造であるSQL DBMSグループの従業員が主導しました。



Bill Gatesは個人的に非常に詳細なレベルでプロジェクトに参加し、冗談で「WinFS PMプロジェクトマネージャー」と呼ばれました。 数千人年ではないにしても、数百人が、時間の経過したアイデアの開発に費やしてきました：DBMSクエリの機能と、非構造化データのストリーミングと保存のためのファイルシステム機能を組み合わせて、独自の新しいリッチアプリケーションを作成するためのプログラミングパラダイムとしてそれを開いたらどうでしょうか？



後から考えると、Googleが非構造化データの透過的かつ迅速なインデックス作成を提供することでこの問題を巧みに解決したことは明らかです。 そして、彼らはあなたのローカルドライブだけでなく、インターネット全体に対してそれをしました。 また、このシステムを活用するためにアプリケーションを書き直す必要もありません。 WinFSプロジェクトが成功したとしても、アプリケーションを書き換えて利用できるようにするには何年もかかります。



Longhornがキャンセルされ、Vistaがその残り火から急いで組み立てられたとき、WinFSはすでにOSリリースから除外されていました。 SQLグループは、別のプロジェクトとして数年間作業を続けました。 この時点で、Windowsには組み込みのインデックスエンジンと統合された検索があり、アプリケーションを変更することなく純粋にサイドに実装されていました。 そのため、WinFSの必要性はさらにあいまいになりましたが、プロジェクトは以前と同様に継続されました。



Longhornのセキュリティに関連する大規模なアーキテクチャの変更は、Longhornの「再起動」後もWindows Vistaプロジェクトの一部として継続されました。 急速に拡大するインターネットの世界でセキュリティについて多くのことを学び、この知識をOSのアーキテクチャレベルで適用して、すべてのユーザーの全体的なセキュリティを改善したいと考えました。



選択の余地はありませんでした。 Windows XPは、私たち自身の成功の犠牲者であることを示しました。 利便性のために設計されたこのシステムは、インターネット時代の現実に直面して、明らかにセキュリティ要件を満たしていませんでした。 これらのセキュリティ問題を解決するには、並行プロジェクトが必要でした。 Windows XP Service Pack 2（その名前にもかかわらず）は、Longhornから何千ものリソースを吸い込んだ巨大な事業でした。



次の主要なOSリリースでは、セキュリティ要件を確実に後退させることはできませんでした。 したがって、VistaはMicrosoftがこれまでにリリースした他のどのOSよりもはるかに安全になりましたが、このプロセスは、エコシステムにとって前例のないレベルでアプリケーションとデバイスドライバーの互換性を破ることに成功しました。 ユーザーは、Vistaが復活したAppleと競争するために急いでリリースしているため、アプリケーションが機能しなかったためにそれを嫌い、パートナーはドライバーとアプリケーションを更新および認証する十分な時間がないように思われたため、それを嫌いました。



多くの点で、これらのセキュリティの変更には、アーキテクチャを大幅に変更するためにサードパーティのアプリケーションが必要でした。 また、ほとんどのエコシステムベンダーは、レガシープログラムの変更にあまり投資する準備ができていませんでした。 それらのいくつかは、機能を実装し、通常のAPIをバイパスし、システムで混乱を引き起こすことが多いマルチプロセッサロックのために、データ構造やカーネル内の命令を変更するために型破りなアプローチを使用しました。 ある段階で、Windowsのすべての「ブルースクリーン」の約70％は、これらのサードパーティドライバーと、その機能を実装するために通常のAPIを使用することに抵抗があるためです。 特に多くの場合、このアプローチはアンチウイルス開発者によって使用されました。



マイクロソフトのセキュリティ責任者として、私は個人的にアンチウイルスメーカーに、カーネル命令とメモリ内のデータ構造を「パッチ」できないようにする理由、これがセキュリティリスクをもたらす理由、そして今後通常のAPIを使用する理由を個人的に説明しました。ハッカーがユーザーシステムを攻撃するために使用するまさにその方法である、Windowsカーネルへの深いフックを備えた従来のプログラムをサポートしなくなります。 アンチウイルスのメーカーである「友人」は振り返って訴え、彼らの生計を奪い、独占的地位を濫用したと非難しました！ そのような友人と、誰が敵を必要としますか？ 彼らは、一般的なユーザーのセキュリティを低下させることを意味する場合でも、古いソリューションが引き続き機能することを望んでいました。まさに、このセキュリティを改善する必要がありました。



長年にわたり、コンピューター業界には非常に多くの劇的な変化がありました。インターネットの出現、携帯電話の普及、クラウドコンピューティングの出現、広告に基づく新しいビジネスモデルの作成、ソーシャルメディアのバイラル成長、ムーアの法則の容赦ない行列、フリーソフトウェアの人気です。 これらは、あらゆる側面からWindowsを攻撃した要因の一部にすぎません。



その答えは、大成功を収めたプラットフォームにとっては非常に論理的でした。頑固にコースを継続し、既存のシステム、つまり革新者のジレンマを次第に改善します。 コードを追加すればするほど、システムが複雑になり、スタッフが増え、エコシステムが大きくなり、競合他社からの成長したバックログを補うことが難しくなりました。



競争の圧力が十分ではないかのように、かつて、当社のエンジニアとプログラムマネージャーの軍隊全員が、数時間、数日、数週間、数ヶ月を法務省の代表者や企業弁護士と話し合い、政府の反トラスト規制に準拠するために以前のリリースからの既存のAPIを文書化しました。



厳しい現実は、ライフサイクルのその時点で、Windowsのメインリリースをリリースするのに約3年かかり、急速に変化する市場には長すぎたということです。 WinFS、セキュリティ、およびマネージコードは、Longhornのアジェンダにあった大規模なプロジェクトのほんの一部です。 そして、何百もの小さな賭けがありました。



数千人の従業員と文字通り数十億のユーザーからなる組織がある場合、絶対にすべてを想定する必要があります。 タブレットとスマートフォンで起動するはずの同じOSリリースは、ラップトップ、データセンターのサーバー、ネットワーク接続ストレージなどの組み込みデバイス、「Powered by Windows」ボックスで動作するはずです-ハイパーバイザーの上で動作することは言うまでもありません（ HyperV）クラウド。 これらの要件により、すべての市場セグメントで同時に進歩を達成しようとしたため、チームは反対方向に引っ張られました。











LonghornとVistaを別々に表示することはできません。 それらは、Windows 2000とXP、Windows Server 2008とWindows 7の前後のバージョンと、レトロスペクティブにおける業界の幅広いコンテキストを完全に理解した場合にのみ意味があります。



Windowsは、それ自体が成功した犠牲者です。 彼女はあまりにも多くの市場を征服することに成功し、これらの各セグメントのビジネスは現在、オペレーティングシステムの設計に何らかの影響を及ぼし、異なる方向に引っ張っていました。



90年代に非常に成功したアーキテクチャは、組織がそれに追いつけようとする間に周囲の環境があまりにも急速に変化していたため、10年後に単純に消滅しました。 明確にするために、これらすべての傾向を確認し、それらに順応するように努力しましたが、隠allowを混ぜることを許可した場合、3年間の放出の妊娠の2年目にある場合、エアライナーを反対方向に向けることは困難です。



要するに、3、4年前にこのOSリリースを計画していたときに知っていたことが、製品がついにリリースされたとき、途方もなく時代遅れになり、時には明らかに間違っていました。 最善の方法は、新しいクラウドサービスを徐々に簡素化されたデバイスに段階的かつ簡単に提供することでした。 代わりに、モノリシッククライアントシステムに機能を追加し続けました。各リリースの前に何ヶ月もテストする必要があったため、スピードアップが必要な場合は速度が落ちました。 そしてもちろん、古いバージョンのWindowsのアプリケーションとの互換性に必要な古い機能を削除することについては気にしませんでした。



数十億のユーザー、数百万の企業、数千のパートナー、数百のユースケース、数十のフォームファクターで同じOSを10年以上サポートすると想像してみてください。



振り返ってみると、Linuxはこの点でより成功していることが証明されています。 ソリューションの疑いのない部分は、オープンソースコミュニティとそのような開発へのアプローチでした。 モジュールおよびプラグインのUnix / Linuxアーキテクチャも、この点で重要なアーキテクチャの改善です。



遅かれ早かれ、どの組織も組織図を製品として提供し始めますが、Windowsも例外ではありません。 オープンソースにはそのような問題はありません。









「戦争室」ウィンドウ、後に「橋」（船室）に改名



必要に応じて、これに内部組織のダイナミクスと個性を追加します。 私たちはそれぞれ独自のお気に入りの機能を備えており、独自のエコシステムのパートナーは、プラットフォームでの認定を取得し、特定のシナリオにAPIを追加するための新しい標準をサポートするように私たちを押しました。 誰もが私たちの技術、私たちのアイデアが勝つことを証明したいという野望と欲求を持っていました... Windowsの次のリリースにそれを含めて、何百万人ものユーザーに即座にそれを届けるならば。 私たちは、戦争室での毎日の会議で戦いを繰り広げるのに十分に強いと信じていました。 それぞれには、影響力の範囲を拡大し、拡大しようとするマネージャーがいました。このマネージャーは、このパスに沿った中間ステップとして従業員の数を増やしました。



開発チームとテストチームはしばしば衝突しました。 前者はコード検証の完了を主張しましたが、後者は、クライアント環境に実際には似ていない、ますます複雑で難解なテストケースを見つけることで報われました。 控えめに言っても、内部ダイナミクスは複雑でした。これでは不十分であるかのように、少なくとも年に一度、会社は大規模な再編成を受け、新しい組織のダイナミクスに対処していました。



ところで、これのどれも謝罪や言い訳として受け入れられるべきではありません。これはそれについてではありません。



間違いを犯していませんか？はい、豊富です。



特に間違った決定をしたことがありますか？いいえ、1つだけ覚えていません。



それは信じられないほど巨大なエコシステムを備えた信じられないほど複雑な製品でしたか（当時は世界最大）。はい、ありました。



もっと良くできますか？はい、他の方法。



今日、他の決定を下しますか？はい過去を見るときのビジョンは100％になります。それから、私たちは今知っていることを知りませんでした。



失望したり後悔したりして振り返るべきでしょうか？いいえ、学んだ教訓を学びたいです。私たちは誰もその後のプロジェクトで同じ間違いを犯したことはないと確信しています。その経験から教訓を得ました。つまり、次回はまったく異なる間違いを犯すことになるということです。誤ることは人間です。