Windows 7 開発プロジェクトの構成

こんにちは Jon DeVaanです。

すでにStevenは、私たちが仕事をする上でとても重要な要素であること、すなわち、いかに私たちがエンジニアリング“チーム”を構成しているかについて書きました。もう一つの重要な要素はいかに私たちがエンジニアリング“プロジェクト”そのものを構成しているかです。

まずは、いくつかのお断りからはじめます。ひとつ目としては、Stevenは私より10倍ほど早く読み書きを行います。ですので、二人の文書を比較した場合、それぐらいの差があってもびっくりしないでください。（でも、安心してください、ここだけの話、私の方がよく考えるほうです。(笑) それとも、ただ嫉妬しているだけかもしれません。）二つ目としては、私たちは“どのようにしてWindowsを開発しているか”というトピックを共有していきたいと思っています、なぜならば、そうすることによりPDCとWinHECが近づいてきて詳細な機能の議論を始める時に共通の文脈を保てるからです。私たちはLonghorn/Vistaの教訓を生かしていかにWindows 7を開発しているかを議論していきたいと思っています。これらすべての事実がWindows7での判断に関係してきます。

それでは、本題を始めたいと思います。

Stevenが以前、Microsoft Secretsという本を紹介したかと思いますが、これは素晴らしい分析結果だと考えており、私はこれをMicrosoftのエンジニアリングシステム Version2と呼んでいます。（Version 1は、索引カードと“フロッピーを使ったネットワーク”が絡んでいて、あまりみなさんが興味ある内容ではないと思います。）Version 2は誰もが思った以上の長い間Microsoftにとって有益でした、しかし、Windows XPより得た教訓やLonghorn/Vistaの時代から顕著になった本質的に違うセキュリティ環境より、製品を開発するアプローチを考える上で世代交代の時期を迎えていたのは明確でした。

XPより学んだ教訓は、私たちの業界を取り巻くセキュリティに関する考え方の変化です。私たちがいかにこの教訓を活かしてきたかは、より安全なソフトウェアを開発するためにMicrosoftが推奨しているエンジニアリング手法についてまとめたSecurity Development Lifecycleを読むことによりわかると思います。私たちは内部でもWindowsを開発する上でこの手法を使っています。

このBlogのコメントを見ると、全体のシステムの品質と言うのは様々な、それぞれに人にとって別々の重要性を持っている事がわかります、またVistaの全体的な品質についても様々なご意見をお持ちだという事もわかります。私はOSの基礎の部分の信頼性についてたくさんの時間をかけており、実際のユーザーより（もちろん自発的にCustomer Experience Improvement program（訳注：日本語訳はカスタマ エクスペリエンス向上プログラム）にご参加いただいているユーザーのみです。）収集したテレメトリー情報の分析にたくさんの時間をかけています。このテレメトリー情報がSP1の時に何をしなければいけないかの指標となりました。私はVistaでスリープ/レジュームが良くなっているという皆様のコメントを読んでうれしく思っています。また、私はこのテレメトリー情報を利用し続けてVistaをもっとも信頼性の高いWindowsのバージョンにする事に努力し続けられる事（実際、私たちはその作業を行っているのです）に興奮しております。Vistaのセキュリティの脆弱性はXPに比べて半分以下にすることに成功したことも指摘しておかなければなりません。これはWindows 7に関するブログですが、Windows Vistaが実世界でどのように稼働しているかについて、深く理解する努力をしながらWindows 7の作業を進めています。

もっとも重要な事として、皆様はメールやコメントを通じて、いかにWindowsのエンジニアリングシステムを改善できるかを指摘していただいています。パフォーマンス、信頼性、コンパチビリティ、と新しいテクノロジーへの対応へのお約束の反故等はそれらのコメントの共通テーマです。それら問題の解決への一つのアプローチは、私たちがいかにWindows 7のコードベースの開発を日々管理しているか、つまり日々のビルドの品質を強化しているかです。

これを読みながら皆様は“何を当たり前の事を！”と感じておられるかもしれませんが、しかし、私の経験では、いくらそのようにしたいと私たちが望んでも、ソフトウェアプロジェクトの規模や組織に関係なく、これはそれほど簡単でも、明瞭に解決できる問題でもないのです。

日々のビルドの品質

ソフトウェアプロジェクトにおいて、毎日の品質はとても重要です、なぜならば毎日残っている作業量の予測をつかって重要な決定をしなければならないからです。日々のビルドの品質が低いと、どれだけの作業が残っているかを知ることはとても困難になります、それは数々の悪いエンジニアリング上の決定につながっていきます。作業に携わるエンジニアの数が増える（なぜなら私たちはたくさんの事をやりたいから）と日々のビルドの品質の重要性がさらに増します、なぜなら一人のプログラマーのエラーの確率に伴い、完成させる労力も増えていきます。問題は製品にいくつバグが潜んでいるかがわからないというだけではありません。もし問題がそれだけなのであれば、少なくとも個々の結末は個々のデベロッパーに委ねられる事になります。もっとも油断のならない副作用は個々のデベロッパーが日々の更新結果を個人の作業に反映する自信がなくなった時です。このような事態がおこってしまうと、私たちの知らないバグ、互換性問題やその他私たちが容易に知りうることができない問題がたくさん発生します。なぜならば、誰も一つのマシン上にWindows 7のすべてのソースコードの変更をまとめていないからです。

この現象を図解かするためにグループのサイズの範囲内（青い線）で個々のプログラマーが100回に1回のエラーレートでどれだけのビルドブレイクがおきるかを予測する簡単な公式を用いたグラフを用意しました。1%のエラーレートというのはとても良い状況です。同時に個人のエラーレートを半分にした場合（赤い線）と、10分の1にした場合（緑の線）のビルドブレイクの確率の線を二つ同時に示します。見てとれるとおり、各エンジニアの日々の品質を向上するメカニズムを導入する事によって日々のビルドの全体の品質を向上するのに大きく貢献いたします。

Windowsの開発チームのような規模になると、毎日のビルドの品質を向上させるのはかなり難しい問題です。

私たちのWindows 7における改善点はWindowsのすべてのフィーチャーチームを横断し構築した共通自動化テストのインフラストラクチャーに注力していることです。これは、Vistaでのエンジニアリングシステムからの大きな改善です。（多くの人は気付きませんが、エンジニアリングのプロセスとチームの組織の間には避けられない関連性があります。）このインフラストラクチャーを使い、私たちはすべてのフィーチャーチームが行ったコードの改変を実際に毎日のビルドにマージする前に確認する事ができます。フィーチャーチーム内部ではこのインフラストラクチャーを日々のプログラマーが行うコードの改変の確認に使う事ができます。図よりビルドブレイクの確率が40人のプログラマーのフィーチャーチームでバランスされますので、フィーチャーチーム内部ではあまり起こらない事が見てとれるかと思います。

Windows 7 においては毎日高いレベルのビルドを作ることに成功しています。もちろん、時にはデベロッパー全員の作業を統合する過程でビルドブレイクは起こります、しかし、自動化テストがそれらを事前に検出し修正する事によりほぼ毎日高い品質のビルドを作成することに成功しています。私はこのプロジェクトの開始と同時にWindows 7をほとんど問題なく使えています。（多くの皆様も、私と同様にWindows 7を使いたいと思われているかもしれませんが、もうしばらくお待ちください！）

ご参考までに、毎日24時間サーバーとクライアントをビルドし検証している私たちのビルドラボの写真をいくつか紹介させてください。

      

まとめ

今回のポストは私が毎日かなりの時間を割いているトピックを駆け足で紹介しました。楽しんでいただけたでしょうか？この例で私たちがいかにWindowsの開発手法の向上を全体的な取り組みとして考えてきたかの一端をご理解いただければと思います。私たちの考えが本当に正しいかどうか、私たちの製品の品質それ自身が証明してくれると思っています。このソフトウェアエンジニアリングの重要な問題に対して、皆様の考えをお聞かせください！