私は通常、コードの作成またはプロジェクトの管理のいずれかで、直接関与していたことについて食べます。 この記事では、Windows Vistaの大失敗（コード名Longhorn）の根本原因についての私の見解について書くために、別のアプローチを取りました。 これは10年以上前に発生しましたが、モバイルデバイスへの移行の重要な時期でした。これらのイベントは、マイクロソフト内で長期的な結果を引き起こしました。 特にモバイルプラットフォームへの移行に関連して、Microsoftの問題を説明しようとする多くの試みは説得力がなく、何が起こったのかについての私の理解と一致しないことがわかりました。 Vanity Fairの記事「Microsoftの失われた10年」は、官僚的な腐敗と手に負えない闘争（「人生は絶えず残酷になっている」）や、競合するスタックレーティングシステムの悪影響による文化的な腐敗について説明しています。 The Atlanticのその後の記事では、状況を古典的な「革新者のジレンマ」として説明しています。
私は、状況は異なって述べることができると思います-プロジェクトについての特定の事実と主要な関係者の真の動機へのより良い拘束力で。 これは、別の物語を書く試みではありません-それらの間違いがなされなかった場合、私は何が起こるかわかりません。 しかし、彼らは間違いなくマイクロソフトがコンピューター業界のこの転換点を通過するのを助けませんでした。
これはジャーナリスティックな調査ではありません-イベントの主要参加者との大規模な一連のインタビューを実施しませんでした。 ここに私がその時に見たものと私が後で見つけたものに基づく私の個人的な意見があります。 私は当時Office部門で働いていましたが、Windows部門の多くの同僚と緊密に連携する必要があったため、そこで行われたプロセスをよく知っています。
記事のサイズが大きいことをおIびします。 概要は次のとおりです。
- マイクロソフトは、主要なハードウェアの傾向を誤って判断しました。 特に、2003年の急激な転換は、PCの他の主要な要素に対応する改善を伴うシングルスレッドプロセッサの周波数を急速に増加させる傾向でした。 Vistaは、存在しないハードウェア向けに計画および構築されました。 これはデスクトップにとっては悪く、ラップトップにとってはさらに悪く、モバイルデバイスにとってはひどいものでした。
- C＃とマネージコードへの賭けは十分に根拠がなく、実装も不十分でした。 この特定の失敗の責任は、ビル・ゲイツと、普遍的なアプリケーションインフラストラクチャを備えた普遍的なリポジトリから聖杯を作成する彼の実りのない試みに直接起因する可能性があります。 この失敗は特に長期的な結果をもたらしました。
- Windows部門のプロジェクト管理は、終わらないプロジェクトを含め、その歴史を通じて壊滅的なレベルにとどまっています。 Vistaは災害であることが判明しましたが、それは複雑なプロジェクトを実行するための重要なミッションにおける一連のほぼ壊滅的なシナリオの頂点に過ぎませんでした。
これはこの物語にとって非常に重要なので、業界の構造と価値の創造についての小さな例から始めたいと思います。
デバイスは、ハードウェア、オペレーティングシステム（OS）、およびアプリケーションで構成されます。 最も基本的なレベルでは、OSはハードウェアリソースを管理および公開して、アプリケーションがそれらを共有できるようにします。 OSは、さまざまな種類の機器がデバイスに接続できるようにするソフトウェアインターフェイス（API）、およびこの機器へのアクセスをアプリケーションに提供するAPI、およびOSのシステムサービスも提供します。 基本レベルでは、OSはハードウェアリソースのみを提供しますが、実際には、「OS」には、グラフィカルユーザーインターフェイス、書式付きテキストの表示および編集またはHTMLの埋め込みのための複雑なコントロール、高レベルネットワークサポート、ファイル管理、メカニズムなど、他の多くの高レベル機能が含まれますアプリケーション間だけでなく、ブラウザ、メールクライアント、写真やカメラを操作するアプリケーション全体の間でデータや機能を交換するため。 OSの歴史、特に消費者の世界では、ユーザーに直接提供されるか、アプリケーションのAPIとして公開される高レベルのサービスがますます増えています。
この高度な機能の開発は、OSビジネスに固有の有益なサイクルと多国間のネットワーク効果によるものです。 より多くのOSユーザーがより多くの開発者を引き付けています。 より多くの開発者がより多くのアプリケーションを作成するため、OSはユーザーにとってより魅力的になります。 これにより、さらに多くのユーザーが開発者の数をさらに増加させるサイクルにつながります。 提供されるオペレーティングシステムAPIは、このコンテストの勝者にとってビジネス戦略を非常に成功させ、安定させるものです。 全体で数百万人の開発者が、システムAPIとサービスのプログラミングに多大な労力を費やしています。 特定のOSによって提供される複雑なAPIにアプリケーションが強く依存するほど、このアプリケーションを他のOSに移植することが難しくなります。 そのため、競合他社が別のOSの主要な機能を繰り返し使用したとしても、これらのアプリケーションを受け取ることはできません。 単一のOSベンダーが何百万人もの開発者が費やした労力を複製することは完全に不可能です。
このようなダイナミクスにより、サプライヤーがより複雑な機能とAPIをOSに追加し、開発者がこの機能に簡単にアクセスできるようにする多くの相互補強理由があります。 複雑な機能は開発者を引き付け、シンプルなAPIを使用してより優れたアプリケーションをすばやく作成できます。 これらの最適なアプリケーションは、より多くのユーザーを引き付けるという有益なサイクルをすぐに開始します。 古典的な例は、WindowsがHTMLドキュメントをアプリケーションに直接埋め込むことができる最初のOSになったときです。 非常に重要なことは、この機能を使用した後、アプリケーションを別のOSに転送することがより困難になったことです。
Windows、iOS、Androidを見ると、すべて同じ戦略を使用していますが、Microsoft、Apple、Googleの収益化方法は異なります。 マイクロソフトは従来、すべてのデバイスでライセンス料を請求します。 Windowsでデバイスを販売するOEMビルダーによって支払われます。 これは、多数のOEMによる水平的なビジネス戦略であり、各OEMは、組み立てられて販売されたデバイスごとにMicrosoftに支払います。 Appleは、製造および直接販売のデバイスを通じて収益化されています。 Googleは、主に検索によるアフター収益化に依存しています。 実際、AppleとMicrosoftがモバイル検索市場（およびモバイルサービス全般）を奪うことを恐れていることが、GoogleがAndroidに投資している主な理由です。 また、Microsoftは（Surfaceラインを介した）デバイスの販売からの直接の収益化、および（BingおよびOffice 365などの有料サブスクリプションを介した）アフター収益化への切り替えを行っています。
ここで考慮すべきもう1つの重要な部分は、JavaやAdobe Flashなどのサードパーティのミドルウェアです。 ある意味では、サードパーティ企業によって作成および提供されることを除いて、高レベルのOSサービスと違いはありません。 OSプロバイダーとミドルウェア開発者には、愛と憎しみが混在しています。 ミドルウェアを使用すると、開発者がプラットフォーム用の優れたアプリケーションをすばやく作成できるという意味で、これは愛です。 「憎悪」の一部は、いくつかの推進力によって推進されています。 特定のタイプのミドルウェアは、異なるプラットフォームで実行されるアプリケーションを作成する問題を特に解決します。 JavaやFlashのようなミドルウェアは、「一度書くだけで、どこでも実行できる」というモットーで配布されています。 このようなミドルウェア上に構築されたアプリケーションは、OSのAPIに直接依存しないため、このミドルウェアが存在するプラットフォームで動作します。 APIをネイティブオペレーティングシステムAPIに変換します。 （最近の読者は、JavaをWebサイトのサーバーインフラストラクチャとして、またはAndroidアプリケーション開発用の優先言語として表現できることに注意してください。ブラウザベースのアプリケーションの言語としてオンデマンドで作成される根本的な原因を意味します。 Vistaが計画されたとき）。
クロスプラットフォームミドルウェアは、そのOSに固有の排他的なAPIを介して特定のOSにアプリケーションをバインドした結果として作成されるネットワーク効果を破壊します。 このようなミドルウェア上に構築されたアプリケーションも、すべてのOSの「最も一般的でない機能」を使用する傾向があり、OSに登場する新機能をそれほど迅速に採用しません。 一部のタイプのOS機能は、独自の内部ネットワーク効果を作成します。この機能を使用するアプリケーションが多いほど、すべてのアプリケーションの動作が向上します。 典型的な例は、フォーマットされたコピーアンドペーストです。 フォーマットされたコンテンツのコピーと貼り付けをサポートするアプリケーションが増えるほど、各ユーザーにとってOSの価値が高まります。 サードパーティのミドルウェアプロバイダーがこの動的をブロックすると、時間が経つにつれてOSの安定した差別化の可能性がブロックされます。
アプリケーション配信プラットフォームとしてのブラウザは、おそらくシステムAPIのダイナミクスを混乱させるミドルウェアの最も安定した例です。 35年のコンピューターの歴史を見ると、ある時点で他のアプローチが登場しましたが、ここでは説明しない理由ですべて失敗しました。 私たちの歴史にとって、重要なことは、20年前にはすべてが何に注がれるのかがそれほど明白ではなかったことです。 ミドルウェアへの恐怖とAPIの安定した差別化の混乱がVistaの主要な要因でした。
Windowsの歴史と、このプロジェクトの実装における問題を見てみましょう。
結果をまとめるという大変な仕事をするつもりですが、その本質を失うことはないと思います。 通常、Windowsの各リリースにはメインテーマとおおよその期限がありました。 たとえば、Windows 95はユーザーのWindowsを32ビットで更新し、最新のファイルシステム、新しいUI、および標準のネットワークツール（ブラウザーを含む）をインストールすることになっています。 主なトピックに加えて、個々の開発者とグループがそれぞれの分野の重要な機能を独自に決定し、開発を開始しました。 開発中の製品は不安定であることが判明しました。これは、長い間、新しい機能が相互に安定して機能しなかったためです。 ある時点で、開発者は機能を十分に開発したと判断し、安定性に取り組み、リリースの準備を始めました。 歴史的に、Windows開発者は通常、リリース予定日が非常に遅く（Windows 95は元々Windows 93と呼ばれていました）、重要な計画機能は破棄されるか、元の計画から大幅に削減されました。 リリースの準備段階は、多くの場合、バグが夜遅くと週末に修正されたときに「死の行進」に変わりました-そして、締め切りは絶えずシフトしました。 WindowsとOfficeの主な違いは、Office 97以降、Officeチームが次のバージョンのリリース日を設定し、通常は期限を守っていたことです。 これにより、最小限のオーバーヘッドで幅広い調整が可能になりました。
このプロセスは、現在の開発プラクティスとは大きく異なりました。 とにかく、別の機能のアイデアは、幅広いビジョンの一部として上から下へ、または個々の開発者やグループから下から上へと生まれましたが、現代の慣行には通常、継続的な品質管理とユーザーへの頻繁なリリースが含まれます。 サービスは1日に数回実稼働環境で更新でき、新しいクライアントコードは毎週または毎月リリースされます（クライアントの更新はプロバイダーとユーザーの両方にとって高価であり、更新が頻繁になりすぎます）。 これには、WindowsやOfficeなどの大規模で複雑なシステムで確実に動作するための基本的なアーキテクチャおよびエンジニアリングインフラストラクチャが必要です。 このプロセスにより、複雑な機能の重要なブレークスルーが常に容易になるわけではありませんが、開発チームの柔軟性と外部イベントや現実に対応する能力が劇的に向上します。 また、実際の現在の進捗状況をより正直に評価できます。 Office部門がこれらの最新の開発プラクティスにどのように移行したかについて、別の記事を書く価値があるかもしれませんが、当時のWindows部門はそれらにさえ近づいていないと言えば十分です。
Windows XPは大規模なリリースになり、前述の悲しいテンプレートにも対応しました。 堅牢なWindows NTカーネル上のビジネスプラットフォームとユーザープラットフォームを、使いやすいインターフェイスで組み合わせました。 Windowsプラットフォーム用に作成されたすべてのアプリケーションとの互換性を実現することは困難でしたが、これは単一のビジネスプラットフォームおよびユーザープラットフォームに移行する重要な要因でした。 残念ながら、Windows XPは、公開日当日に見出しにヒットする0day脆弱性を発見しました。 情報セキュリティの分野におけるこのような災害により、マイクロソフトはソフトウェアの根本的な近代化とセキュリティ分野における開発慣行の改訂を余儀なくされ、最終的にWindows部門の大部分によって作成されたWindows XP用の無次元サービスパックをリリースしました。 さらに、主要なWindowsカーネル開発グループ（コアグループ）は64ビットバージョンで機能しました。これは、Windowsのクライアントとサーバーインストールを結合するために特に重要です（一方、Windowsは64ビットコンピューティングのSun Solarisのような他の企業プラットフォームに遅れをとっていました） 。 これは、Windowsが大規模なエンタープライズサーバーで競合している（そして成功している）ために重要でした。
Windows部門の大規模な部門はこれらのイニシアチブに重点を置いていましたが、小規模な組織が「管理された」C＃プラットフォームの上に次世代のWindowsを作成することに従事していました。 ここで、少し背景を説明する必要があります。
最初の数日から、ブラウザはアプリケーション配信プラットフォームとして開発され始めました。 マーク・アンドリッセンの悪名高い引用「Netscapeは、Windowsのデバイスドライバーの調整が不十分なセットのみをまもなく残す」は1995年に遡ります。 これにより、抱擁および拡張戦略が実装され、Microsoftが独占禁止法の調査で多くの問題を引き起こしました。 Microsoftは、独自のブラウザと独自のActiveXコードを実装するメカニズムを作成および開発しました。 当時、Javaは代替アプリケーション配信戦略として登場しました。 開発者は、独自の豊富なAPIセットを備えた高レベル言語であるJavaを使用できます。この場合、コードは自動的にダウンロードされ、ブラウザーで実行されます。 Javaは、「一度書き込めば、どこでも実行できる」テクノロジーとして宣伝されました。これは明らかに、ミドルウェアに対する「憎悪」反応のスペクトルに陥りました。 突然、MicrosoftはJavaに関してSunとライセンス契約を締結しましたが、MicrosoftはネイティブWindows APIへの直接アクセスのためにJavaを拡張したときに訴えられました（「どこでも実行」の原則に違反しましたが、Java開発者はより豊かで成長しているセットにアクセスできました）プラットフォーム上のAPI）。 マイクロソフトは、Java訴訟の取り決めを交渉し、最終的にC＃プログラミング言語で独自の方法で進むことを決定しました。 この決定は多くの理由で悲惨なものでした。 （C＃自体が技術の優れた例であることに注意してください-災害は戦略でした）。
C＃は「管理された」言語です。 これは主に、開発者がメモリの割り当てと解放を「手動で」管理する必要がないことを意味します。 言語とランタイムは、 ガベージコレクションを使用して、使用されなくなったメモリ部分を自動的に解放します。 ランタイムは、その時点で多くのセキュリティ脆弱性を引き起こしたメモリ内のエラーのタイプも防止することが重要です。 当時、しかし実際には次の10年間にわたって、プログラミングのパフォーマンスとセキュリティに対する自動メモリ管理の影響について熱心な議論が続けられました。 私はここでそれらの論争を再び語ることはしません。 最も成功した最新のiOSオペレーティングシステムがこれらのゲームをプレイしないことを決定したと言えば十分です（Androidは大量に販売されていますが、iOSは利益の大部分を獲得しています）。 管理対象環境では、管理対象外環境と比較してリソースがオーバーランするため、使用するメモリが多くなります。 マネージコードのパフォーマンスを活用するほとんどの環境は、最も意味のある場所でのみ使用を慎重に制限し、どこでも盲目的に使用しないようにします。
プログラマーが最初にこのタイプの環境（当時のWindowsプロジェクト開発者のほぼ100％）に遭遇した場合、彼らはメモリの使用について真剣ではありません。 しかし、メモリがどのように自動または手動で制御されても、それはリソースを表しており、リソースに対する軽薄な態度はコードが肥大化し、動作するためにより多くのメモリが必要になります。 実際、「高い生産性」（大量のコードを生成する）でさえ 、プロジェクトの成功の主な基準とは限りません（ 「時間があれば、短い手紙を書く」 ）。 当時、システムのコンピューティング機能に対するシッククライアントの重要性が強化されたため、より多くのリソースの使用がバリューシステムの一部でした（Webページを介して実行される単純なアプリケーションのような「シンクライアント」と比較）。 Longhorn更新プログラムを作成するとき、Windows開発者は、作成した新しいAPIの数について自慢していました。
C＃への賭けの一部は、コアクラスの豊富なライブラリへの賭けであり、このベースの上にクラスライブラリのセットとして新しいクライアントテクノロジを作成しました。 コアライブラリは、文字列や配列などの単純なタイプに加えて、リストやハッシュテーブルなどのより複雑なデータ構造やサービスを提供しました。 重要なのは、これによりWindows API全体に統一性が提供されることです。 Win32は当初、比較的小さな均一なAPIでしたが、過去10年間で、単一の一貫した概念なしにAPIセットに追加された非常に多くのグループの努力によって大きく膨らんでいます。 この新しいライブラリは、すべてを元の状態に戻す機会と見なされていました。
他のオペレーティングシステムがこの方法を選択しなかったという事実は、一種の「大きな賭け」と見なされていました。これは、Microsoftの内部文化における価値システムの基本的な部分でした。 残念ながら、膨張したリソースの使用に伴う問題に加えて、オペレーティングシステムで新しいテクノロジーを使用することには根本的な課題がありました（特に、OSの重要な部分でリソース障害を処理する方法、アプリケーション、ランタイムおよびOSを個別に更新する方法、およびさまざまな互いに独立して開発されたOSの部分）は、その時点で決定しなかったか、完全に理解していませんでした。 管理されていないWin32上に構築された既存のアプリケーションには、文字通り移行戦略はありませんでした。 それにもかかわらず、開発者の巨大な軍隊は、この不安定なプラットフォームの上に建設を開始しました。 彼らは何に取り組んでいましたか？
この場所では、ビルゲイツをストーリーに結び付けるのが理にかなっています。
創業以来のマイクロソフトの歴史はすべて、ハードウェアに対するソフトウェアの優位性に専念しています。 ソフトウェアはユビキタス製品であり、価値はプログラムにあります。 PCエコシステムの持続可能な利益を見ると、この見方は本当に正確に思えます。 OEMとMicrosoftの関係に関しては間違いなく正確です。 インテルは、すべてのコンピューター機器のメーカー間で利益の大部分を占めました。 同時に、ムーアの法則やその他の指数トレンドの影響下で鉄の生産性が無限に指数関数的に増加することにより、コンピューターエコシステム全体のダイナミクスがサポートされました。 最終製品から主な経済的利益を受けたのはソフトウェアだったからです。OSの基本的な重要な役割は、アプリケーションが公正に使用できるようにハードウェアリソースを提供することです。
ハードウェアとソフトウェアの役割が絡み合っていると、価値の分布を評価することが困難になる場合があります。実際、スマートフォン市場の分析は明らかにするのに役立ちます。 RIMエンジニア（支配的なBlackberry電話のメーカー）が最初のiPhoneのデモを見たとき、彼らの最初の反応「これは不可能です！」タッチインターフェイスを備えたフルスクリーンの軽量の携帯電話と、バッテリーが十分に長く続くような性能を設計することは不可能です。しかし、実際にはこれが可能であることが判明しました。過去10年間、市場はOSソフトウェアを介して間接的に継続的なハードウェアの革新（より良い画面、より高速な通信、より効率的なプロセッサー、より多くのメモリ、より良いカメラ、新しいセンサー、より大容量のバッテリー、軽量化、瞬時の電源投入）によって推進されてきました。
iOSがサードパーティのアプリケーションを開いたとき、デバイスの全体的なパフォーマンスを維持するためにOSがアプリケーションの動作をどれだけ慎重に制御していたかが印象的でした。 Appleアプリケーションの監視対象カタログの標準および必須レビューから、サンドボックス内のアプリケーションの思慮深い分離、バックグラウンドプロセスのない1つのタスクの最初の制限から、アプリケーションの応答およびハードウェアアクセラレーションと低電力消費を伴うオーディオおよびビデオの処理の厳格な制限、および他の多くの技術まで、貴重なバッテリーエネルギーを節約することを目的としています-iOSの革新の多くは、ハードウェアの正確な露出を管理するためのOSの主要機能に根本的に関連していますLASアプリケーション。
VistaのリリースでWindows部門の開発者が採用したアプローチとの大きな違いに気付かないのは難しいことです。ハードウェアイノベーションの役割は、ソフトウェアイノベーションを可能にすることであり、ソフトウェアがハードウェアイノベーションを擬人化することではありませんでした。
Longhornプロジェクトが開始されたとき、3つの大規模なグループが、管理されたC＃プラットフォーム上でクライアントソフトウェアスタックを再考するための大規模な作業を開始しました。 WinFSチームは、アプリケーション用のユニバーサルストレージの新しいレイヤーを作成することになっていた。ファイルとディレクトリの単純な階層選択の代わりに、ファイルシステムはフル機能のリレーショナルエンジンを実行していました。これにより、強力な新しいアプリケーションの作成が容易になるだけでなく、それらのデータは不透明なファイルにロックされず、他のアプリケーションやリレーショナルテーブルで使用可能になります。これらは、競合他社に対して強力な溝を作る内部ネットワーク効果の例です。情報は、単純な検索と複雑なクエリのために、新しいファイルマネージャーにも開かれました。したがって、ユニバーサルカイロストレージのアイデアは最終的に実現されるべきであり、Windows 95での実装を放棄して失敗しました。
Avalonチーム（後のWindows Presentation Foundation）は、強力なGPU上でのプレゼンテーションのレベルを再考することになっていた。プレゼンテーションレベルは、ユーザーインターフェースと豊富なアプリケーションのコンテンツがわずかに混ざり合ったユニバーサルキャンバスの作成に集中していました。その結果、一部はドキュメントであり、一部はユーザーインターフェースであり、すべて3Dゲームを処理できる強力なグラフィックプロセッサの制御下にありました。
3番目のグループは、Windows Communication Foundations（WCF）として出てきたコードを作成して、ネットワーク機能を作成しました。これは、ほとんどすべての最新アプリケーションの重要なコンポーネントです。
豊富なストレージと豊富なパフォーマンスの組み合わせは、ビルにとって最高の目標でした。安定したC＃管理インフラストラクチャ上に構築されたこれらのコンポーネントにより、開発者が迅速かつ効率的に構築できる強力なアプリケーションの新しいクラスを作成できます。豊富なインフラストラクチャとAPI溝は、OSに好循環を与え、さらに10年前から肯定的なフィードバックを提供します。
それで何が間違っていたのでしょうか？一言で言えば、それがすべてです。
短期的なタスクの失敗に起因する問題もあれば、長期的な戦略的エラーに起因する問題もありました。
コアグループがセキュリティと64ビットWindowsを強化するプロジェクトを思いついたとき、Longhornプロジェクト全体のステータスを再評価しました。開発者は巨大なコードの量。残念ながら、複雑なシステムを構築し、明確な制限と期限なしで作業する場合、多くのコードを生成するチームの正しい精神状態は、全国で鉄道を建設し、すでに90％完了している人々の精神状態に対応していません。むしろ、彼らは信じられないほど深い穴を掘った人々と比較することができ、今、それをどうやって外に出し、埋めるかを考えています。チームは、この管理されたインフラストラクチャ上でOS機能を提供する試みの結果をすべて理解することができました。彼らは、基本的な前提を現実にするためだけに膨大な仕事があることに気づきました。これらすべてに加えて、主要なコンポーネントの1つが準備段階に入っていません。また、主要な新しいサブシステムを既存のコードに導入する際のパフォーマンスの制限を理解し始めました。WinFSおよびAvalonプロジェクトは、既存のOSインフラストラクチャを置き換えるものではなく、その上に置かれました。そのため、コンピューティングリソースの多大なコストが単純に追加されました。
2005年のWall Street Journalの記事で説明されているように、Olchinは開発から継続してこれらのコアコンポーネントをリリースから削除することを決定しました。その結果、製品サイクルの3年後、それらの作業は事実上ゼロから開始する必要がありました。これらの管理機能はすべて、OSのメイン構造から除外し、個別に提供する必要がありました。それらの除外は明らかに正しい解決策でしたが、両方のサブシステムを除外すると、問題が明らかになり、その後10年間続く問題が発生しました。
C＃とマネージコードへの賭けには、Win32アンマネージレイヤーへの投資を削減する戦略が含まれていました。私は、Windows部門の代表者を説得してOfficeに必要なテキストおよびグラフィック機能に比較的小さなコミットをしようとする長い会議を覚えています。これらのC＃コンポーネントのリリースの例外により、WindowsがコアWin32 APIで開発者向けの主要なUIコントロール（Officeなど）を数年も残さないことがさらに明確になりました。
また、Avalonへの賭けがIEに関する作業の大幅な削減を伴うという事実も悲惨でした。 IEグループはスタッフの一部をAvalonプロジェクトに移すことで削減され、IEは多数のセキュリティ問題を解決できず、その数は絶えず増え続けており、生命維持に取り残されました。長期的なビジョンは、HTMLが古代の技術になり、競合他社がブラウザとHTMLで使用するアプリケーションが新しいAvalonインフラストラクチャ上で動作することでした。
これは、Firefox、そしてGoogleのChromeブラウザーの配布への扉を開いた大きな戦略的ミスでした。言うことはできませんが、IEへの投資はそのような結果を防いだでしょうが、それは確かに悪化することはなかったでしょう。また、投資の終了はIEチームを弱体化させ、Web開発者の間でIEの評判を破壊するWebテクノロジーの進行中の急速な進化に直面して、彼らに準備ができておらず、スタッフが不足していました。間違いの事実は、社内の全員にすぐに明らかになりました。特別な先見者を置く必要はありませんでした。会社のオフィスおよびその他の部門は、WebおよびHTMLに積極的に投資しました。これらのツールをAvalonに、そしてさらには業界全体に適用する方法はありませんでした。実際、Avalonチームはこの本当の方法を決して説明しませんでした。魔法のようなことが起こりそうでした-そして突然、誰もがHTMLの代わりにAvalonアプリケーションを書き始めました。それは不un慎であるのと同じくらいばかげていた。ブラウザ戦争に「勝ち」、AOLによるNetscapeの吸収を観察した直後に、これらのオープンスタンダードでの技術のさらなる開発を大幅に削減しました。プロジェクトの開始時にのみ、Windows 7はIEグループのスタッフを募集し、IEおよび標準のWebテクノロジーへの積極的な投資を再開しました。プロジェクトの開始時にのみ、Windows 7はIEグループのスタッフを募集し、IEおよび標準のWebテクノロジーへの積極的な投資を再開しました。プロジェクトの開始時のみ、Windows 7はIEグループのスタッフを募集し、IEおよび標準のWebテクノロジーへの積極的な投資を再開しました。
Avalonに関連する他の問題があります。
Avalonモデルは、アプリケーションのランタイムであるユニバーサルキャンバスを提供するというBillのコンセプトに基づいていました。「アーキテクチャレベルのリーク」という記事で説明したように、Avalonなどのフレームワークの開発者にとっての主な問題の1つは、アプリケーションが対応する機能レベルでそれらにバインドでき、余分な生産性コストが発生しないように、さまざまなレベルで関数を開く方法です。機能を最高レベルでのみ開くと、すべての作業は基本的に、より低いレベルでバインドする必要があるより複雑なアプリケーション（Officeアプリケーションなど）にはアクセスできなくなります。これらの問題がアーキテクチャレベルで解決されるまで、Windows 10のリリースまでにさらに10年かかりました。
また、Avalonはエネルギーを大量に消費するグラフィックカードにも依存していました。モバイルグラフィックモデルは同じ要素の一部を使用していましたが、ズーム、パン、およびブレンドを使用して事前に描画されたテクスチャまたはレイヤーによるスムーズなアニメーションの実現に主に焦点を合わせていました。レイヤーの数はきちんと制限されているため、モバイルグラフィックプロセッサは、少ないエネルギーを消費しながら、スムーズなアニメーションとユーザーインタラクションに必要な高フレームレートを表示します。 Avalonのグラフィックモデルは事実上反対方向に動いていました。
ある意味でのWinFSの問題は、Avalonの問題よりもさらに根本的なものでした。 Avalonは個別に出荷され、いくつかの重要な概念がWindows 8および10のUIコンポーネントの基礎として使用されましたが、WinFSプロジェクトは完全に中止されました。
WinFSは元々、ファイルシステム。古いファイルシステムを、いくつかの重要な新機能を搭載した完全に新しい実装に置き換えると同時に、膨大な数の既存ソフトウェアの目に見える不変性を維持することは、非常に困難な作業でした。特に、基本的なWindowsサブシステムの主な開発者が他のタスク（セキュリティおよび64ビットバージョン）に従事していたという事実を考慮してください。そのため、WinFSは、検索と豊富なクエリに追加機能を提供するサードパーティコンポーネントとして作成されました。この設計により、WinFSは、エンドツーエンドの最適化の機会が少なくなり、パフォーマンスのオーバーヘッドが大幅に増加します。すべての新機能と同様に、これらのコストとその利点を組み合わせる必要があります。しかし、その瞬間、WinFSは実際には検索のみを提供しました。これは、ビルが提案したパラダイムシフトではなく、「単なる機能」でした。 Microsoftは、WinFSよりもはるかに少ないリソースを消費するデスクトップ検索エンジンを既に持っていました。さらに、ほとんどの情報がPCからクラウドに移行したローカルPC検索のエコシステムでのこのような革命の実装は、飽和したクライアントにイノベーションを集中するこれらのたゆまない試みによる現在の傾向の大きな誤解を示しました。ほとんどの情報がPCからクラウドに移行されたとき、彼らは飽和状態のクライアントにイノベーションを集中しようとするこれらのたゆまぬ試みのために、現在の傾向に対する大きな誤解について話しました。ほとんどの情報がPCからクラウドに移行されたとき、彼らは飽和状態のクライアントにイノベーションを集中しようとするこれらのたゆまぬ試みのために、現在の傾向に対する大きな誤解について話しました。
より深いレベルでは、すべてを独自に保存し、このリレーショナルリポジトリでデータを共有するビルのアプリケーションエコシステムのビジョンは、アプリケーションがデータモデルを構築する方法と直接矛盾します。一部のデスクトップアプリケーション（およびほぼすべての内部ITアプリケーション）は、内部データモデルにリレーショナルストレージを使用しますが、これらのデータモデルを他のアプリケーションによる制御されない読み取りおよび書き込みに提供することは望みません。前述の記事「建築レベルでの漏出」で基本的な理由のいくつかを説明しました。リレーショナルストレージを使用するアプリケーションには、他にも多くのオプションがありました（現在もあります）。そしてもちろん、長期的な傾向として、これらのデータはすべてローカルのPCストレージにロックされず、クラウドに移動されています。
この管理されたスタックへの投資を継続し、OSリリースから削除するという決定は、Vistaのリリース後に長期的な結果をもたらします。経営陣は、それがリリースの一部にならないという現実と和解したが、これらの技術をクライアントの革新の主要なリンクと見なし続けた。 Sinofskyは、Windows 7製品サイクルのWindows組織構造を再編成したときに、マネージコードプロジェクトをすべてWindows部門から開発部門（DevDiv）に削除し、マネージコンパイラ、ランタイム、ベースライブラリ、および開発環境を作成した他のDevDivチームと共に構築しました。後で、彼はWindows 8製品サイクル中にWindowsのメインランタイムと見なされるものの闘争に入りますが、今では事実上、闘争を延期しています。これらのコマンドを置き換え、Windows組織内で代替プロジェクトを作成しない。これは長期的な結果をもたらしました。プロジェクトは引き続き国内投資と資源を消費しました。一般の人々は、マネージドランタイムがWindowsの未来だと考え続けていました。 「焦土」の領土は、管理エリア外で大きな投資が行われなかったときに形成されました（したがって、Officeおよびその他の大規模な非管理アプリケーションへの投資はありませんでした）。さらに、マネージコード開発チームは現在、新しいハードウェアの革新に関連する深刻な投資についても考えていませんでしたが、完全に独立したミドルウェアレイヤーの構築についてのみ考えていました。これらの管理ライブラリとランタイムは「純粋なミドルウェア」になりました。実際、Flash（後に放棄された）と競合するために、これらのコンポーネントはSilverlightの形で一緒にパッケージ化され、異なるOSプラットフォームで配布されました。これらすべてのソフトウェアイノベーションが、ハードウェアイノベーションの翻訳に専念することから完全に離婚したという、より明確な証拠を提供することは困難です。
ミドルウェアを、調停の独占権を失うという点でOSベンダーにとって最悪の悪夢の1つと考えると、「私たちは敵に直面しており、これも私たちの1人である」ことが明らかになります。その期間のインサイダー情報があることは宣言しませんが、戦略年の問題を明確に述べることはできませんが、管理された年の層への集中とほとんどのOfficeシナリオの役に立たないことによる不快感を覚えています。実際、iOSのシステムイノベーションによって、仕事のためにどれだけ間違った方向が選択されているかについて、後知恵で明確に理解することができました。
マネージコードがリリースから引き出されたため、私がC＃スタックに対して行ったコード肥大化の申し立ては、明らかにVistaのパフォーマンスの問題を説明していません。 Windows XPの最小システム要件は64 MBのRAMで出荷され、Windows XPのメインのセキュリティサービスパックのリリース後に128 MBに増加しました。 Vistaでは、通常の操作に1 GBを使用するのが現実的でしたが、メモリ要件は512 MBに増加しました（古い読者はコンピューター上の疑わしい「Vista Capable」マークのスキャンダルを覚えているかもしれません）。最小システム要件を引き上げる理由を明確に説明した人はいません。ムーアの法則による「避けられない」生産性の向上を利用しようとする多くの別個のチームがあり、累積的な影響はこのコードの肥大化でした。実際には、全体的な生産性（および全体的な品質の問題）の重要な要因は、プロジェクトの終わり近くに始まったリリースの急ぎでした。不十分なパフォーマンスは、大きな意思決定だけでなく、多くの場合、長時間のコード分析後に結果を得るためだけの時間がない場合に、長所と短所の妥協として行われる多くの小さな決定の結果でした。 Windows 7で行われた最適化は、改善の機会があったことを明確に示していますが、時間がありませんでした。単に時間が残っていなかった長い時間のコード分析の後に結果を得るためだけに。 Windows 7で行われた最適化は、改善の機会があったことを明確に示していますが、時間がありませんでした。単に時間が残っていなかった長い時間のコード分析の後に結果を得るためだけに。 Windows 7で行われた最適化は、改善の機会があったことを明確に示していますが、時間がありませんでした。
Vistaの安定したシステムとしての評判に対するもう1つの打撃は、ドライバーの問題のある性質でした。OSに組み込むための機器（グラフィックカード、ネットワークカード、ハードドライブなど）のメーカーによって書かれ、配信された主要なソフトウェアです。 Vistaは、ドライバーモデルに重要な変更を加えました。OSカーネルから管理の信頼性がより高いレイヤーに削除されました。オペレーティングシステムの障害後のWindows XPの有名な「死のブルースクリーン」は、ほとんどの場合、サードパーティのドライバーの障害が原因で発生しました。カーネルからこのコードを削除すると、Windowsはシステムの全体的な信頼性を高めることになっています。
ドライバーモデルの変更には、すべてのハードウェアメーカーのWindows用ドライバーコードの大幅な変更が必要でした。競合他社からのこの大きな蓄積の利点は、エコシステム全体でこのような大規模な変更を行おうとするとき、首に石になります。 Vistaは遅れることが多かったため、ハードウェアメーカーがこの作業とその期限に優先順位を設定することは困難でした。多くはVistaのリリースの準備ができていませんでした。これは、新しいシステムを使用する多くのユーザーとの最初の経験が、ドライバーの欠落または非常にバグが多いことに関連していることを意味していました。
この記事の冒頭で述べたプロセッサ速度のスケーリングの崩壊は、パフォーマンスの問題の一因となっています。コンピュータ業界は、データ処理の急激な成長の影響を受けて発展しました-格納および処理できるデータの量、処理速度、帯域幅、異なるデバイス間の通信遅延。これの多くは、ムーアの法則-集積回路の同じ領域に配置されるトランジスタの数を定期的に2倍にすることによるものです。この単純な倍増の法則は、ユーザーになじみのあるものです。彼らは、ムーアの法則が、プロセッサ速度、RAM容量、ストレージ容量、通信速度の増加に現れることを期待できます。
現実はもう少し複雑です。プロセッサ速度の増加は、消費電力と熱放散の増加を伴います。 Intelプロセッサの熱放散の増加を描いた図を覚えています。対数目盛は、最初のIntelプロセッサーからPentiumを通り、太陽の表面での熱放散までの直線を示しています。スタインの法則が頭に浮かぶのは、「何かが永遠に続くことができないなら、そうはならない」ということです。コンピューター産業は「エネルギー障壁」に突き当たりました。プロセッサの速度は、許容できない電力消費と熱放散の増加なしではスケーリングできませんでした。プロセッサ速度でグラフィックスを見ると、Vistaの大失敗の真っat中に、2003年に転換が起こりました。他の傾向も、パフォーマンスの改善に対する単純な認識を危険にさらしました。マイクロチップメーカーは、より高密度のトランジスタを備えたメモリチップを製造しましたが、「メモリバリア」により、CPUとメモリ間の遅延により、このメモリをすべて効率的に使用することがますます困難になりました。おそらく、バランスのとれたPCシステムを作成する際の最大の問題は、ディスク容量の増加でしたが、1秒あたりのランダムI / O操作の数の増加はずっと遅くなりました。これは、より大きなプログラムがより大きなディスクに収まることを意味していましたが、ロードはずっと遅くなりました。不均衡のため、高速プログラムは、ディスクが処理できるよりも簡単にI / O要求を高速化できました。その結果、プロセッサ速度とメモリ容量が増加したにもかかわらず、システムが遅くなりました。CPUとメモリ間の遅延により、このすべてのメモリを効率的に使用することがますます困難になっています。おそらく、バランスのとれたPCシステムを作成する際の最大の問題は、ディスク容量の増加でしたが、1秒あたりのランダムI / O操作の数の増加はずっと遅くなりました。これは、より大きなプログラムがより大きなディスクに収まることを意味していましたが、ロードはずっと遅くなりました。不均衡のため、高速プログラムは、ディスクが処理できるよりも簡単にI / O要求を高速化できました。その結果、プロセッサ速度とメモリ容量が増加したにもかかわらず、システムが遅くなりました。CPUとメモリ間の遅延により、このすべてのメモリを効率的に使用することがますます困難になっています。おそらく、バランスのとれたPCシステムを作成する際の最大の問題は、ディスク容量の増加でしたが、1秒あたりのランダムI / O操作の数の増加はずっと遅くなりました。これは、より大きなプログラムがより大きなディスクに収まることを意味していましたが、ロードはずっと遅くなりました。不均衡のため、高速プログラムは、ディスクが処理できるよりも簡単にI / O要求を高速化できました。その結果、プロセッサ速度とメモリ容量が増加したにもかかわらず、システムが遅くなりました。ただし、1秒あたりのランダムI / Oの増加ははるかに遅くなります。これは、より大きなプログラムがより大きなディスクに収まることを意味していましたが、ロードはずっと遅くなりました。不均衡のため、高速プログラムは、ディスクが処理できるよりも簡単にI / O要求を高速化できました。その結果、プロセッサ速度とメモリ容量が増加したにもかかわらず、システムが遅くなりました。ただし、1秒あたりのランダムI / Oの増加ははるかに遅くなります。これは、より大きなプログラムがより大きなディスクに収まることを意味していましたが、ロードはずっと遅くなりました。不均衡のため、高速プログラムは、ディスクが処理できるよりも簡単にI / O要求を高速化できました。その結果、プロセッサ速度とメモリ容量が増加したにもかかわらず、システムが遅くなりました。
Vistaは、モバイルプラットフォームへの移行がますます加速している期間に入りました。 2003年のラップトップの売上はデスクトップの売上を上回りました。 2005年までに、ラップトップは販売されたデバイスの数の点でデスクトップPCを上回りました。 Vistaは新しい安価なラップトップ（「ネットブック」）であまりうまく機能しなかったため、MicrosoftはOEMビルダーがこれらの低コストマシン用にWindows XPを提供し続けることを許可する必要がありました。
ここで起こっていることの重要な部分は、より深い問題でした-それが解決したタスクのためのデスクトップPCフォームファクタの基本的な十分性。主な使用分野は、生産性（主にOffice）、コミュニケーション、サーフィン（検索、Webサイト、Webアプリケーションを含む）、一部の内部ビジネスアプリケーション、専用デバイスのフロントエンド（歯科医のX線装置を思い出してください）です。これらはすべて、2000年までにほぼ安定しており、それ以来あまり変化していません。 Microsoftは新しいAPIを作成できましたが、コンピューターはユーザーが必要とするほぼすべてのことを既に実行していました。人々が必要とする改善-管理性、安定性、パフォーマンス、ソフトウェアセキュリティの向上、バッテリー寿命の延長、軽量化、プロセッサの高速化、通信速度の向上、大画面-ハードウェア側から。これらの改善の多くでは、ソフトウェアの量を増やすのではなく、減らす必要がありました。
このビジネスの充足は汚い言葉ですが、それが引き起こす問題はよく説明されており、Chrissensenの本、The Innovator's Dilemmaのおかげで広く知られています。より最近の本、アメリカの成長の台頭ロバート・ゴードンは、アメリカ経済のはるかに広い範囲における自給自足の概念を説明しています。十分性は経済不況の一形態です。景気後退は、2四半期連続の生産削減の後に発表されます。つまり、実際に知る前に、6か月以上の間景気後退に陥っています。デスクトップコンピューターのユースケースは変更されていないという事実にもかかわらず、基本的な機器の重要な進化が続き、PCを使用するための新しいオプションにこれらのイノベーションを使用しようとするエコシステム参加者の努力を支えました。ラップトップの登場から数十年経った今でも、バッテリー寿命がさらに長く、より軽量なラップトップが必要です。しかし、このラップトップの使用方法は全体的に変わっていません。
ここでは、フォームファクタの十分性に焦点を当てていることに注意してください。経済における一般的なコンピューティング要件は爆発的に増加し続けました。しかし、より高速でユビキタスな通信は、アプリケーションがシステム内の異なるノード間でコンピューティングリソース（データと処理）の要件を分散する方法の柔軟性を暗示しています。過去20年間の多くの要因の影響下で、処理の増加部分はサーバーまたはクラウドに送られます。私はバッテリーを携帯するよりも、ワシントン州東部のサーバーを使用して、Grand Cooley HPPからこれらの計算サイクルに電力を供給したかったのです。異なるデバイスまたは複数のユーザーからのデータにアクセスする必要がある場合は、ローカルPCではなくサーバーにデータを保存および処理します。ワイヤレス通信の進歩（およびエンドツーエンド通信の一般的なスループット）により、このデバイスシナリオは非常に安定しています。
これは、デスクトップコンピューター（ラップトップを含む）でのみ確認されていません。タブレットはおそらく、フォームファクターの充足率が他のどの製品よりも強くなる傾向を示しました。広い視野ではこれはそうではありませんが。何十年もの間、タブレットのさまざまな転生において、重量、バッテリー寿命、計算能力、入力モード、合計応答時間に満足していませんでした。しかし、iPadが画面サイズ、重量、バッテリー寿命、タッチ入力、プロセッサ速度、インスタントオンの組み合わせでシーンに登場すると、十分なポイントに達しました。それ以降に行われた変更は、本質的に漸進的なものであり、これらのことに取り組むエンジニアを駆り立て、多くのエネルギーと創造力を夢中にさせます。新しい洗濯機で作業しているメイタグのエンジニアも同じように感じるはずです。
はい、人々はより良い画面、より高速なプロセッサー、および大容量バッテリーを望んでいました。しかし、一般に、デバイスはそのタスクを果たしました。これは、多くの点で、タブレットの売り上げの急速な均等化を説明しています。スマートフォンもこの段階を通過したようです。実際、これは、サービスとデバイス間のデータを透過的に管理する通信およびソフトウェアが向上するにつれて、さらに公平になります。
この物語から学ぶことができる主な教訓は何ですか？
それらの最初のものは非常に基本的であるため、当たり前のようです。実装の問題。実装しないとイノベーションはありません。
次のキャリアで心に刻んだ2番目のレッスン。あなたが大きくて野心的なことをしたいなら、あなたはそれらがなぜ行われるべきかを明確にする責任を負う必要があります。主な論文と証拠を書き留め、それらを守ることができるはずです。現実には、あなたが持っている力が大きいほど、事実または論理によって正直な挑戦を受け入れなければならないより多くの責任と準備が必要です。事実と論理は変化する可能性があるため、これは急速な変化の時代にはさらに重要です。責任と透明性は、調査結果を過大評価し、迅速に対応できることを意味します。
このすべてを生き延びたとき、私は若い頃読んだ小さなSF小説を思い出し、この物語にふさわしいと私の記憶を一周しました。最後に、私はそれを理解し、それが1951年に最初に出版されたアーサー・クラークの有名な作品「絶対的優位性」であることを発見しました。これは短い話です-リンクをたどって、すばらしい類似点をいくつか見ることをお勧めします。