Consumer Preview リリースとその変更点や、まだブログで触れる機会がなかった機能についてさらに詳しくお話しする前に、少し立ち止まってチームについてもう一度紹介したいと思います。Windows 8 の構築はかなり重要な仕事ですので、さまざまな背景や経験を持つチームが関与しています。私たちのチームの多様性が、世界中で Windows を使っているお客様の多様性を反映していることに誇りを感じています。前回のリリースでは、チーム メンバーの一員である Larry Osterman が、以前のリリースと比較した Windows 7 での仕事について書きました。この記事では、Larry が他の 2 人のチーム メンバーを通して Windows 8 プロジェクトについて考えます。
--Steven


3 年前、私は Windows 7 の開発プロセスについて Engineering Windows 7 ブログに記事を書きました。今回は、2 人の Windows Runtime Experience チーム メンバーと共に非公式な Q&A セッションを行うことで、チームの新しいメンバーにインタビューしてみたいと思います。2 人は、Windows 8 の計画が始める少し前に Windows の開発作業に参加しました (ですから、2 人にとって Windows の開発に最初から最後までかかわるのは Windows 8 が初めてです)。

ご自身について少しお話を聞かせてください。経歴と Microsoft に在籍している年数を教えてください。

Chris: こんにちは、Chris Edmonds です。オレゴン州出身で、オレゴン州立大学で学び (Go, Beavers!)、NASA と Garmin のインターンシップに参加していました。そうした経験を通して、ロボット工学や航空電子工学などのプロジェクトにかかわり、多コア プロセッサの高速ルーティングに関する研究を行いました。Microsoft にはオレゴン州で採用され、およそ 2 年半前に Windows チームに加わりました。

Mohammad: こんにちは、Mohammad Almalkawi です。私は、Microsoft の Windows 部門でソフトウェア設計エンジニアをしています。Microsoft には約 2 年半勤務しています。イリノイ大学アーバナ シャンペーン校 (Go, Illini!) を卒業し、フォールト トレランスとリアルタイム システム統合の研究を行っていました。

Windows 8 については、どんな仕事を行っていますか。

Chris: 私は、Windows 7 の製品版がリリースされる数か月前に Windows チームに加わりました。その後すぐに、新たに設けられた Windows Runtime Experience チームに参加しました。Runtime Experience チームは、たくさんの Windows Runtime (WinRT) インフラストラクチャを構築しています。Windows 8 の開発中、WinRT の多くの部分に携わる機会がありました。

1 つ目のマイルストーン (3 つあります) では、WinRT システムのコア パターンの定義に取り組みました。私たちは、プロジェクトを 3 つのマイルストーンに分類してアーキテクチャと実装をそれらのマイルストーンに分け、まっさらな状態から完成品までたどり着きました。Windows 8 全体で使用されているさまざまなテクノロジをまとめるのに必要なすべての作業を含める必要がありました。1 つ目のマイルストーン (M1) では、イベント、オブジェクト構築、非同期メソッド、メソッド過負荷のパターンを設計しました。WinRT と相互に作用する各プログラミング言語で、開発者が慣れている仕方で自然にそうした基本的な概念を表すには、そうした概念の強力なパターンを定義することが重要でした。

2 つ目のマイルストーンでは、Metro スタイル アプリケーションの開発にかかわる機会がありました。具体的には、Metro スタイル アプリケーションを起動してコントラクトと相互作用できるように、Metro スタイル アプリケーションを WinRT に登録する仕事です。

3 つ目のマイルストーンでは、たくさんのグループ間コラボレーションを行いました。このようなコラボレーションは、Windows 8 のように大規模で広範なプロジェクトではきわめて重要であることを学びました。そして、あるチームと連携して、Metro スタイル アプリケーションのアプリケーション モデルのコア部分を定義し、実装しました。この仕事の結果、Metro スタイル アプリはさまざまな言語で記述され、異なる UI プラットフォームでもコントラクトとアプリケーション ライフタイムの点において一貫した方法で動作するようになりました。

Mohammad: 私は、ごく初期から Windows 8 の作業に参加する機会をいただきました。Windows 8 の目標を理解するため、3 つの主な機能マイルストーン (M1、M2、M3) を設けました。各マイルストーンは以下のような構成です。

  • 仕様および設計フェーズ: フィーチャ クルー ミーティングを行ったり、Windows のパートナー チームや社内全体と積極的に協力することで、要件を導き出しました。フィーチャ クルーは、特定の機能にかかわる開発者、テスター、プログラム マネージャーで構成されており、通常は 4、5 人です。このフェーズの結果として、一連の仕様ドキュメントが作成されました。機能 (プロジェクト マネージャー)、開発設計 (開発者)、テスト設計および脅威モデル (テスター)、実行計画 (全員) です。これにより、機能について詳細に理解することができ、確かな自信を持って必要な作業に取り組むことができました。
  • コーディング フェーズ: 仕様フェーズで識別された機能を実装し、ユニット テストと機能テストを行いました。
  • 統合および安定化フェーズ: 各チームの成果を 1 つに統合し、バグを修正しました。

1 つ目のマイルストーンでは、アプリケーション拡張の検出およびアクティブ化の設計と開発にかかわりました。この WinRT インフラストラクチャにより、アプリケーションは OS によりサポートされるコントラクト (英語) (検索や共有など) に参加し、検索チャームや共有チャームなど、Windows のすばらしい機能の基盤としての役割を果たすことができるようになります。

2 つ目のマイルストーンでは、Windows メタデータ解決機能の実装を担当しました。これは、WinRT ツール チェーンにより生成される Windows メタデータと、JavaScript および C# 言語のプロジェクションを結び合わせる主要な API です。

そして M3 では、名前空間 API の設計と開発を担当しました。この結果、Chakra JavaScript エンジンで WinRT の名前空間と型を介したリフレクション機能がサポートされるようになりました。CLR でも、この API を使ってメタデータ解決が実装されており、Visual Studio ではこれを使って WinRT 型用の Intellisense がサポートされています。

普通の日はどのような仕事をしていますか。
Chris: 普通の日ですか? Windows の仕事でとても気に入っている点の 1 つが、普通の日がめったにないことです。製品サイクルの時期に応じて、1 日の仕事は仕様を書いたり、コードを書いたり、チームのメンバーとアイデアを出し合ったり、バグを修正したり、その他さまざまです。仕事の内容は違っていても、いつも何らかの形で問題の解決がかかわってきます。クラッシュの原因特定や、機能の設計補助などで、賢い仲間と協力して毎日興味深い問題の解決に取り組んでいます。

一番驚いたことは何ですか。

Chris: Windows の仕事をしていて一番驚いたのは、最初から最後までかかわっているチームの規模と活動の数でした。私に割り当てられたいくつかの機能に取り組んでいるとき、チーム全体の何百人ものメンバーと協力して、仕様や解決策を導き出す機会がありました。実際に厳しい作業に思えますが (最初は圧倒されそうでした)、チームが互いにコミュニケーションを取ってすばらしい解決策を見つけ出すやり方は驚きの連続でした。Windows を使っている人の数や Windows が使われている用途の数を考えると、こんなにわずかな人数でこれを行っているのは驚きですね。

Mohammad: Microsoft にいて一番驚いたのは、現実世界の問題の中に放り込まれ、重要な仕事をまさに初めから任される機会が与えられたことです。必要であればトレーニングを受けこともできますが、仕事を通じて学ぶのです。

もちろん、サポート チャネルがたくさんありますし、各分野の専門家や先輩のエンジニアたちが必要なときにサポートしてくれるので、暗闇の中に 1 人で置き去りにされるわけではありません。

Windows 8 は、これまで携わってきた他のプロジェクトとどう違いますか。

Chris: オレゴン州立大学と以前のインターンシップでかかわってきたのは、そのほとんどがこれより小さいプロジェクトでしたので (ほとんどのコード プロジェクトは Windows と比較すると小規模でした)、最大の違いは毎日読むコードの量です。Microsoft に来る前に他のチームが書いたコードを読んだりデバッグしたりするのに加えて、以前のマイルストーンで自分が書いたコードを見直すことは、有意義な時間になりました。その結果、よく書かれたコードの価値が本当にわかるようになりましたから。

解決しなければならなかった最も大きな課題は何でしたか。

Mohammad: チームに参加してすぐ、COM のアクティブ化に関するよく知らないコードに修正を加える必要がありました。このコードは、まさにインフラストラクチャでした。Windows の多くのコンポーネントがこのコードを基盤として構築されているためです。きわめて重要な部分であるため、私が加えた変更によって悪影響を及ぼすことがないようにしなければなりませんでした。

このコードは、チームの上級者にとってはわかりやすいようでしたが、私のような新人にとってはまったくそうではありませんでした。私はたくさんのコードを読み、デバッガーの手順に従い、たくさんのテスト ケースを書くことで、理解と自信を深め、何も壊すことなく必要な変更を加えることができました。

Windows 8 の計画の着想作業はどのようなものだったか話していただけますか。

Chris: Windows 8 の計画は、チームのメンバーごとに形が異なります。計画作業の一環として、新たに形成された Runtime Experience チームは 1 週間かけて、さまざまな言語、スタック、フレームワーク、テクノロジを使ってアプリを構築しました。Windows 8 の設計理論は、複数の言語でプログラミングできることです。この作業の目標には、各メンバーが学習曲線を経験できるように、それぞれまだよく知らない言語を強制的に使う旨が含まれていました。私は、IronPython と XNA を使った 3D 地形生成プログラム、HTML/JavaScript を使ったフォト ギャラリー アプリ、描画に GDI を使った C++ の簡単な 2D 物理エンジンに取り組みました。私たちは、アプリ構築作業を通して、各アプリの構築経験をチームに見せるプレゼンテーションと、各経験の良かった点、悪かった点、失敗した点をまとめたリストを作りました。

何が印象的でしたか。

Mohammad: 整備された Windows エンジニアリング システムの質に感動しました。何千人もの Windows ソフトウェア エンジニアをサポートしており、ビルドと品質ゲート実行を毎晩行うことでオペレーティング システムに存在する何百万行ものコードを正常な状態に保っているのです。自動化された品質ゲート実行には、重要なエンド ツー エンド テスト、パフォーマンス テスト、アプリケーション互換性テスト、静的コード分析、他のいくつかのテストが含まれます。私たちは、これらのテストを使って問題をすばやく検出し、前方統合と後方統合によってブランチ間の伝播をしっかりと制御します。

マイルストーン品質 (MQ) とは何ですか。

Chris: このマイルストーンは、次の製品サイクルへの準備が整っているコード ベース、エンジニアリング ツール、エンジニアリング プロセスに関するすべてです。私が学んだ点で言えば、MQ はコードを見渡してハウスキーピングを行うタイミングです。これには、ソース ファイルをきれいにすることから抽出をやり直すことまでが含まれ、私たちはこれによって Windows 8 で行う作業に備えることができました。コードは私たちの資産ですので、その資産をメンテナンスするタイミングを示すことはかなり重要です。Windows 8 の MQ で、私は 3 つの作業にかかわりました。第 1 の作業は、毎日のテストの合否に基づき、チームの内部ダッシュボードを通してコード範囲番号を自動的に報告するシステムを作成することでした。これは、私が初めて Microsoft で行った仕事の 1 つであり、私たちのエンジニアリング システムについて知る良い機会となりました。第 2 の作業は、コード ベース全体でアサートを使用する方法を標準化するのに役立つコード消毒作業でした。第 3 の作業では、IntelliSense インフラストラクチャの一部を使用して SDK のすべての部分を自動的にカタログ作成するプロトタイプ システムに取り組みました。

今、重点的に取り組んでいるのは何ですか。

Mohammad: パフォーマンスです。これしかありません。

私が担当した機能はソフトウェア スタックの底辺に近く、かなり頻繁に使用されるので、パフォーマンスが非常に重要です。したがって、今はパフォーマンス分析に重点的に取り組んでおり、さまざまなパフォーマンスの改良点をプロトタイプ化し、統合しています。ものすごい量のコードがインフラストラクチャに記述されていますが、最初から高いパフォーマンスになるように構成したので、今はパフォーマンスの微調整を行っています。

どのようにしてエンド ツー エンドで作業内容を検証していますか。

Chris: アプリケーション開発者のエクスペリエンス向上に専念するチームの一員として、オペレーティング システム開発者としてではなく、アプリケーション開発者としての帽子を定期的に被っています。毎日の作業の中で占める割合は大きくありませんが、最もはっきりした形としてアプリケーション構築ウィークがあります。計画時に行われた最初のアプリケーション構築ウィークに基づいて、さまざまな言語や API に取り組んでいる各種チームと共に、WinRT を使ってアプリケーションを開発する時間をマイルストーンごとに設けました。まだ開発段階のプラットフォームでアプリを記述すると興味深い課題が生じますので、このようなウィークはいい気分転換になります。そうしたアプリ構築ウィーク (一部のウィークにはさらに多くのチームが参加します) の結果として多くのバグが浮かび上がり、各開発者のエクスペリエンスをより自然でなじんだものにするために API ガイダンスの一部を考え直して変更する機会となりました。"バグ" は、致命的なクラッシュ、メモリ リーク、セキュリティ ホールから "何かが間違っているように思える" という報告まで、さまざまです。私たちは、バグなどの問題すべてに対応し、それらの報告を分類して優先順位を付けるプロセスに従います。私たちの API の上に Windows を構築しているグループ、Microsoft の他のグループ、デバイスや PC メーカーなどの初期パートナー、インターン (//build/ で見たように)、現在 Developer Preview でアプリを構築しているフォーラムの人たちから報告が届きます。

これまでに学んだ最も重要な教訓は何ですか。

Mohammad: 私は、製品の大きさと規模や、多くのユーザーがいることを考慮に入れた "失敗する可能性のあるものはすべて失敗する" という考えを体験することになりました (ちなみに、私たちは最初から内部の主要開発コンピューターで作業内容のドッグフーディングを行っています)。このことから、コードの全行の細部に注意を払い、品質に集中することは、製品全体の安定性にとって非常に重要であることを学びました。もちろん、これは今までに学んだ数ある重要な教訓の 1 つにすぎません。今はまだ、私にとって初めての Windows リリースに関する仕事を徐々に進めている段階ですので、今後の製品フェーズでさらに多くのことを学べるものと期待しています。

そうした体験は、今でも待ちきれません。

Chris: 私もです。