タグ: 組織

原文：”What Really Happened with Vista: An Insider’s Retrospective” by Ben Fathi

必要のない体験を得ることはできない、必要とされるまでは。

 — Steven Wright.

著者のノート：オリジナルの記事はこちらにあります。元々はドッグフーディングに関する自分のブログで発表したものですが、バズってたくさん読まれたためにMediumに再投稿することにしました。

 　Terry Crowleyの注意深く書かれた記事(What Really Happened with Vista)を楽しく読みました。外から観察していて、Terryは元々はOfficeの部門で働いていて、 複雑な機能化に関して素晴らしい仕事をしました。そしてその仕事はWindows Vistaとお蔵入りとなったLonghorn projectにも引き継がれました。

　彼はプロジェクトを頓挫させた多くの問題を明示していて、私はここでその二番煎じをするつもりはありません。私は同じ事象に関して内部の人間からの視点を提供することがフェアだと考えます。Terryのように雄弁で緻密にはなることができませんが、何が本当に上手くいかなかったのか表面化してみましょう。Windows Vistaがリリースされてすでに10年以上の月日が経ちましたが、そこからの学びは今にこそ活きるものです。

　Windowsは野獣です。数千人の開発者、テスター、プログラムマネージャー、マネージャー、セキュリティー専門家、UIデザイナー、アーキテクトなどなど。それだけではなく、人事、採用担当者、マーケティング、営業、法務にそれを管理するマネージャーやディレクターたち。そしてこの全体がさらに何千ものパートナーにサポートされ、ハードウェアからデバイスドライバー、アプリケーションがプラットフォーム上に開発されていきます。

　組織的に言えば当時のWindowsはコア、サーバー、クライアントの3チームでした。コアチームは「配管 “Plumbing”」を作る役割です。全てのWindowsのバージョンと共有するカーネル、ストレージ、セキュリティー、ネットワーク、デバイスドライバー、インストールとアップグレードのモデル、Win32などOSのコアコンポーネントを開発します。サーバーチームはサーバー市場に必要な技術にフォーカスし、クライアントチームはWebブラウザー、メディアプレイヤー、グラフィックスにシェルといったデスクトップやコンシューマー向けの技術に責任をもちます。

　もちろん、組織変更もありましたが基本的なストラクチャーはWindowsの成長とともに組織が大きくなっても変わりませんでした。文化的にも組織的にもコアチームはクライアントチームよりもサーバーチームと近かったと言えるでしょう、少なくともVistaが出荷されるまでは。

　私が1998年のはじめにMicrosoftに入社した時、Windowsと言えばWindows NTでした。アーキテクチャーとしても、組織的にも、製品的にも。Windows 95のコアのほとんどは破棄され、Windows NTがラップトップからサーバーまで全てのWindowsに適用されました。2年後にWindows 95/98のコードベースは悪名高いWindows MEという最後のリリースに再構成されましたが、これは非常に小さなチームによって開発されました。ほとんどの開発者はWindows NTのコードベースに関わっていました。私はWindows 2000の全盛期からWindows 7の完成までの12年間、この野獣の腹のなかで過ごせたことは非常に幸運でした。

　私はストレージ、ファイルシステム、ハイアベイラビリティ、クラスタリング、ファイルレベルのネットワークプロトコル、分散ファイルシステムやそれらに関連する技術を開発するチームのマネージャーとして最初の7年間を過ごしました。その後、1、2年の間だけマイクロソフトのセキュリティーに関わりました。セキュリティーに関するWindowsの技術からアンチウィルスやパッチの緊急対応まで。この時期はWindows Vistaの終わり頃で、ウィルスやワームがWindowsを跪かせ、安全なソフトウェアとしてのマイクロソフトが市場で大きく打撃を受けていた頃です。

　最後の3年から4年はWindows 7の出荷時期で、私は全てのWindowsコアの開発を管理していました。つまりクライアントとサーバーチームが使う技術の「縁の下」全ての開発の責任を負うことになりました。Visutaが出荷された後、Windowsチームは職種によって構成されるようになり、と「トライアード（開発／テスト／PM）」が組織の全てのレベルの責任を持つようになったため、私は開発をリードし、そのほか二人がテストとプログラム管理をリードすることになりました。

　Windowsチームは歴史的に巨大で野心的なプロジェクトに取り組み、多くの場合にそれを捨て去ったり、別の目的で再利用するという歴史を繰り返してきました。最初の頃の例で言えば焼き捨てられたCairoプロジェクトで、一部だけWindows 2000の機能としてサルベージされました。

　私の控えめな意見では、Windowsリリースの最大の問題はリリースの遅れです。平均的にリリースは3年間かかりますが、そのうちの6から7ヶ月くらいしか新しいコードの開発には使われませんでした。それ以外はインテグレーション、テストと数ヶ月のアルファ、ベータ期間です。

　いくつかのプロジェクトは6ヶ月以上必要で、同時進行することで準備ができたらメインのコアコードにマージしました。つまり大きなピースとしては統合され、置き換えられているためメインのツリーは常に半分壊れた状態でした。Windows 7ではよい状態で動くコードであるために、もっと厳密に管理されていましたが、初期のリリースは月に不安定な状態が何日も続くことがありました。

　このような混沌とした開発の性質は「スケジュールチキン（他のチームも非現実的なスケジュールで結局は遅れるだろうと想定して自分たちのスケジュールも非現実的にすること）」の状態になる傾向にあります。つまり自分たちのコードは他の人たちよりもいい状態だろうと自分たちと周りを納得させ、あとは「磨き上げるだけ」ということで、完成した状態でチェックインさせてしまいます。

　三年のリリースサイクルでは、開発を始める段階でリリースするときに外部環境としてどのような競合状態になってエコシステムが存在しているのか知るすべはありません。リリースを延期させるはキャンセルまたはシベリア送りになります。シベリア送りの場合は引き続き他の組織からは見捨てられた機能を開発をして最終的には失敗プロジェクトとなることです。それでもチームや役員があきらめきれずに続けてしまうことがありました。私もいくつかのプロジェクトに関して個人的に責任があります。ことが終わった後の後知恵ではいくらでも完璧な予測ができます。

　それぞれのチームは自分たちのやることで忙しく、その他のコンポーネントやUIとのインテグレーションやテストはおざなりにしがちで、アップグレードのような厄介な問題は後回しにしがちです。そのためにみんなUIやアップグレードテストのために最後の最後に支援を得ようと躍起になることから、いくつかのチームがボトルネックとなります。

　開発中はいつでも複数のメジャーリリースとサイドプロジェクトが進行中でした。それぞれのチームが自分たちのコードベースの各段階に責任を持ち、それは結果的に「金持ちはより金持ちに、貧乏人はより貧乏に」という傾向へと向かいました。遅れるチームはいくつかの理由で常に遅れるようになります。

　プロジェクトが完成に近づくにつれ、PMは次の要求を意識しはじめ、「金持ち」で「健康的」なチームは新しいコードの開発に着手しはじめます。しかし、ほとんどの「貧乏」なチームは現行のリリースに行き詰まります。特にテストチームは出荷までリリースから解放されることはなく、新しいコードはほとんどテストされることはありませんでした。「不健康」なチームは常に遅れ、現行リリースの最終調整によってさらに遅れることとなりました。これらのチームはチームの士気も低く、離職率が高いため、エンジニアたちは自分たちが書いていない理解不能な不安定なコードを引き継ぐことになりました。

　Vista/Longhornの期間において、私はストレージとファイルシステムの技術に責任を持っていました。つまりWinFSについてもです。当時はWindowsチームの姉妹チームであるSQLデータベースが主にリードをしていましたが。

　Bill Gatesは個人的にも細かい点においてまで大きく関わりを持ち、WinFSのPMとまでジョークで言われていました。数百人月（数千でなければ）のエンジニアリソースがこのプロジェクトに投入され消費されました。もしデータベースのクエリー機能とファイルシステムの非構造化データの機能が合わさって全く新しい「リッチ」アプリケーションを生み出す新しいプログラミングのパラダイムとなったとしたら。

　後付けで言えば、Googleが手際よくこの問題を解決しました。非構造化データをシームレスで高速なインデックスエクスペリエンスを実現しました。しかも、彼らはローカルディスクだけでなく、インターネット全体でそれを成し遂げました。さらに言えばその機能を享受するためにアプリケーションを書き直す必要すらありませんでした。WinFSが成功したとしてもそのメリットを享受するためにはアプリケーションの書き換えが何年も必要となったでしょう。

　Longhornがキャンセルとなり、その残り火からVistaがかき集められた時、WinFSはOSのリリースから除外されました。SQLチームによってさらに数年独立したプロジェクトとして進められました。その時にWindowsはインデックスエンジンが組み込まれ、検索エクスペリエンスがインテグレートされていました。コアでない部分でしたのでアプリケーションの変更も必要ありませんでした。そのためにWinFSの必要性はさらに薄まりましたが、それでもプロジェクトは続きました。

　Longhornにおけるセキュリティーに関するアーキテクチャー上の膨大な変更はWindows Vistaの一部として引き継がれました。私たちは急拡大するインターネットの世界からセキュリティーに関して大きく学び、その学びをOSのアーキテクチャーレベルで適応して顧客のために全体のセキュリティーを底上げしたいと考えていました。

　私たちはやるしかありませんでした。Windows XPはその成功の犠牲者となりました。使いやすさのためのデザインはインターネット時代のセキュリティーに必要な現実にそぐわないものになっていました。その対応をするということは、Windows XP Service Pack 2と同時進行で進めなければいけないということでした。Windows XP SP2はその名前から反してLonghornのかなりのリソースを吸い上げたものでした。

　私たちは次のOSのセキュリティーに関して後ろに戻ることはできませんでした。そのために、VistaはこれまでリリースされたどのマイクロソフトのOSよりも強固なセキュリティーを兼ね揃えていました。しかし、その過程でアプリケーションやデバイスドライバーのこれまで経験のない規模のエコシステムにおいて対応する必要がありました。顧客はアプリが動かないからVistaを嫌い、エコシステムのパートナーは対応する時間が少ないためVistaを嫌いました。Vistaは再生しつつあったAppleとの競争のために早くリリースする必要があったからです。

　いずれにせよ、このセキュリティー上の変更はサードパーティーにとってもアーキテクチャーの変更が必要でした。しかし、エコシステムのベンダーは過去のアプリに大きく投資したくありませんでした。いくつかのソリューションはデータ構造に変更を加えるという異例のアプローチをとったり、自分たちの機能を使うためにカーネルのインストラクションに変更を加えました。APIをバイパスし、マルチプロセッサーをロックすることで問題を引き起こしました。アンチウィルスのベンダーがこのようなアプローチを取りがちでした。

　私のマイクロソフトのセキュリティー責任者としての役割において、アンチウィルスベンダーに個人的にも何年もなぜカーネルのインストラクションとメモリ上のデータ構造に「パッチ」を当てることを許可しないのか、なぜそれがセキュリティー上のリスクになるのか、なぜ彼らは正式なAPIを使わなければいけないのか、Windowsカーネルに深く関わるレガシーのアプリをサポートしないのかを説明しなければいけませんでした。それらは顧客のシステムを攻撃するハッカーと同じアプローチです。私たちのアンチウィルスベンダーの「友人たち」は独占を利用して彼らの生きる権利を奪っているということで私たちを裁判で訴えました。このような友達と一緒でどんな敵が必要でしょうか？彼らは昔のやり方を変えたくなかっただけです。それがお互いの顧客のセキュリティーを犠牲にすることであっても。

　この頃、コンピューター業界では非常に重要なシフトがたくさん起きていました。インターネットの到来、モバイルの勃興、クラウドコンピューティングの出現、新しい広告ベースのビジネスモデル、ソーシャルメディアのバイラル、ムーアの法則の更新。オープンソースの人気はWindowsを襲う全方位攻撃の一つのファクターでした。

　大きく成功した企業では驚くに値しませんが、その対応はイノベーションのジレンマそのものであり、頑なに既存のシステムを累積的に改善していくのみでした。こオードがさらに追加され、複雑さが増し、エコシステムは大きくなり続け、それに伴い競争の先を行くことができませんでした。

　競合だけでは足りず、この頃は多くのエンジニアが何時間、何日、何週間、何ヶ月も司法省の代表者と企業弁護士と時間を共にしなければいけませんでした。反トラスト法における裁判の判決に従い以前のリリースにおいての既存のAPIを文章化しなければいけませんでした。

　純然たる現実としてWindowsのメジャーリリースが3年かかるというライフサイクルは市場の速度に対して遅すぎました。WinFS、セキュリティー、、マネージドコードはLonghornの巨大プロジェクトの一部であり、それ以外に何百ものより小さなプロジェクトが存在していました。

　数千人の組織と数億人の顧客がいるとき、誰でもそれぞれの意見を持っています。今後のタブレットやスマートフォンで動くOSはラップトップでも動くことが期待されます。データセンターで稼働するサーバーは”Powered by Windows”のNASでも稼働することが期待されます。当然ながらクラウドでのハイパーバイザー（HiperV）でも同様です。これらの要件は全てのセグメントにおいて同時に進もうとするチームを反対側に引き寄せました。

　Longhorn抜きでVistaを語ることはできません。Windows 2000／XPとWindows Server 2008 and Windows 7、そのリリース前後を見ることによってどのように業界が変わったのか。

　Windowsは自らの成功の犠牲者でした。様々な市場で成功し、その市場でOSのデザインに関する異なる、時として対立する方向に影響力が動きました。これらの異なる要求に答えるということは、全てにおいて完全に応えることはできないことでもあります。

　90年代に成功したアーキテクチャーは10年後に行き詰ることになりました。世界はより早く変化し、組織はそれになかなか追いつけませんでした。それらのトレンドに気づいていなかったのではなく、それに対応しようとしていました。しかし、比喩を使わせてもらえば、三年のリリース期間の間に二年間の妊娠をしているときに飛行機を急旋回することはとても難しいのです。

　つまり、三年、四年前に計画していたことは出荷するときには笑ってしまうくらい時代遅れで、時には大きく間違っていました。当時できたベストなことは簡潔なデバイスにフリクション無しに蓄積型のアップデートができるクラウド型のサービスだったかもしれません。その代わり私たちはリリースまでに多くの時間が必要なクライアント型のモノリスに機能を追加し続け、スピードが必要な時に速度を落としてしまいました。そして、昔の機能を以前のWindowsとのアプリケーション互換性という理由で削除はしませんでした。

　同じOSを十数年以上の長い期間数億のユーザー、数百万の企業、数千のパートナー、数百のシナリオに数十のフォームファクターをサポートし続ける。徐々に互換性の悪夢に気が付きはじめます。

　後から思えば、Linuxはこの観点でずっと成功しています。オープンソースコミュニティーとソフトウェア開発のアプローチは間違いなく解決方法の一つです。UnixとLinuxのモジュラー型でプラグ型のアーキテクチャーもアーキテクチャーの観点から大きな改善でした。

　組織は組織図をプロダクトとして出荷する。Windowsの組織も同じです。オープンソースはこのような問題はありません。

　これに加えて、社内の組織的なダイナミックスと個性があります。私たちはそれぞれ好みの機能があります。私たちのエコシステムパートナーは新しいスタンダードの適応を求めてきます。彼らのソリューションをプラットフォームで明確にするために、特定のシナリオを実現するAPIを追加するために。私たちはみんな私たちの技術とアイデアが戦いに勝つ野心を持っていました。もし、次のWindowsのリリースに入り、数百の顧客がいれば。私たちは計画の会議やウォールームで戦う意義を信じていました。私たちには昇進して自分の影響力をチームの大きさを測るマネージャーたちがいました。

　開発とテストチームは常に対立していました。開発はコードをチェックインしようとし、後者は実際の顧客では起こりえないようなテストケースを作って優秀さを示そうとしました。社内のダイナミックスは複雑です。年に一回は組織変更があり、新しい組織のダイナミックに対応する必要もありました。

　これらは言い訳でも謝罪でもありません。そのような意図で書いていません。

「私たちは間違えを犯したか？」

　はい、大いに。

「私たちは意図的に間違った判断をしたか？」

　いいえ、私の知る限りでは。

「ものすごく複雑で大きなエコシステムを持つ製品でしたか（少なくとも当時は世界で一番）？」

　はい、そうです。

「もっといい仕事ができたはず？」

　はい、もちろん。

「いまだったら違う決定をした？」

　はい、でも後付けではいくらでも言えます。いま知っていることを当時は知る由もありません。

「私たちは落胆と後悔と共に振り返らなければいけない？」

　いいえ、むしろ学びを得るようにしたいです。同じ間違いをこれからのプロジェクトで犯すことはないでしょう。私たちは体験から学びます。つまり、次はまた別の間違いを犯すということです。間違えるのが人間です。