リリースのスケールの判断 – メジャー リリース？

たくさんのフィードバックをいただき感謝しています。またそれらの多くがポジティブな内容であったことをありがたく思います。私はできるかぎり皆さんからいただいたメールに回答し、チームのメンバーと共にそれらのコメントについて議論してきました。詳細なことや希望、要求に関し皆様それぞれの立場での意見を共有する努力をしていただいた事にも感謝しています。私はこれらのメールを受け取ること、そしてコメントを読むことを本当にうれしく思います。まさに素晴らしいことです。いただいたコメントに一つ一つ回答できないことをお許しください。 私たちがやるべきことは、今後取り上げるべきトピックスを考える上で、メールやコメントを参考にしていくことだと考えています。すべての方々からの温かい反応にチーム全体が感謝しています。多くのエネルギッシュな議論をこれからできるであろうと思っており、そのような場を開始できたことを本当に幸せに思っております。

この投稿では、私たち「Win7チーム」が内部でどの用に物事を考えるかについてのお話を続けたいと思います。範囲を少し広げ、私たちが行ったリリース (出荷) の計画に関する話し合いについて少しお話します。リリースがメジャーかマイナーということについての会話は、プランニングを開始するにあたって私が上司とした会話とそっくりです :-)

リリースの計画を開始する際、まず決定しなければならないのが、Windows 7 (クライアント) は「メジャー リリース」かどうか、ということと思われるでしょう。ここで「メジャー リリース」を「」で括ったのは、これは実際にはお客さまが決めることではないですし、ひとつしか答えがないことでもないからです。リリースがメジャーかそうでないかということは、機能そのものが要因となると同時に、機能に対するお客様の見方も要因となります。メジャー リリースと宣言されることはほめ言葉か、と尋ねられることもあるでしょう。製品を計画するエンジニアとして、私たちは前もって、そのリリースに携わる開発チームの割合とスケジュールの限界を決定します。その結果、お客様は自分自身にとってそのリリースは「メジャー」かどうかを判断することになります。もちろん、私たちはその判断についての意見も伺いたいと思います。server blog では、スケジュールについて話したり、Windows 7 クライアントおよびサーバーのリリースのスケールの意見を共有したりしています。

私たちの目標はWindows 7 を最高のリリースにすることです。

すべてのお客様には、メジャー リリースは自分のための機能があるものであり、マイナー リリースは自分のためのものが何もないもの、という見方が常にあります。そうであれば、メジャー リリースの計画はとても簡単なものになるはずです – すべての人にとってまさにぴったりの機能であることさえ確実にすればよいのです! (パフォーマンスについて取り組んでいる限り、余分な機能は、たとえ他の人が欲しいと思ったとしても、入れません。) エンジニアとして私たちは皆、そのような設計プロセスは実際には不可能だということを知っています。特に、ある二人の顧客はまったく反対の機能を望むことがよくあるためです。実際、私がこれをタイプしているときに電子メールを続けて受け取りましたが、ひとつは「誰もタッチ スクリーンについて気にしていない、ナンセンスだ」というもので、もうひとつは「Win7 はもっと高度で堅牢なタッチ機能が必要だ」というものでした。あなたも、組織化されてない一方的なインプットを受け取ったとき、このような正反対のものをかなりよく見かけると思います。また、ブログのコメントでもお気付きかと思います。

さて、さまざまな (すべてではありません) 顧客の種類 – 一般ユーザー、開発者、パートナー、IT 技術者、およびインフルエンサー － に対する多種多様のリリース規模について検討してみましょう。

一般ユーザーは通常、リリースがどの規模になるかを決定するという点で、もっともシンプルです。一般ユーザーにとって、もしアップグレード版または新しい PC を買いに出かけたいと思えば、そのリリースは一大事で、メジャー リリースと呼べるでしょう。十分に単純で、メジャー リリースは誰にとってもよいことのように見えます。その一方で、リリースはとても素晴らしく買いたいと思っても、既存の PC を使い続けたく、新しいリリースを十分に使うにはもっとたくさんのメモリ、入手困難なドライバのアップデート、特殊なハードウェアなどを必要とする、というケースも想像できます。そうすると、メジャー リリースは肯定的なイメージから少々押され気味になり、その輝きの一部を失うでしょう。もちろん、私たちは皆、人々が本当に必要とするものは、彼らが必要とするハードウェア上で動作するすべてのもので、それが (メジャーであるかどうかにかかわらず) 優れた製品であることを知っています。

開発者は違った視点でリリースを捉えます。当然ながら、開発者にとって、新しい API や彼らのソフトウェアにとって利点となるような能力がある場合、リリースはメジャー リリースとなります。これも、十分に単純です。一方、前回のリリースでたくさんの新しい API があり、やっとそれらに慣れてきたところで、実際に望むのはそれらの API を完結させてパフォーマンスを向上させること、というケースも考えられます。その場合、最初のリリースがメジャー リリースで、二番目がマイナー リリースではないかと思うでしょう。しかし、ソフトウェア製品の歴史を見ると、これらの「マイナー」リリースがメジャー リリースになることはよくあることなのです。たとえば、Windows 3.1 であったり、Office 4.2 であったり、Windows XP SP2 もそうです。それぞれのケースでは、開発者対象では「マイナー」リリースでしたが、市場的には「メジャー」リリースでした。開発者が新しい API を使用したい理由は、製品を差別化するためであったり、エネルギーを専門分野に集中させるためであって、単に新しい API を呼ぶために呼んでいるのではありません。その意味で、ソフトウェア メーカーの時間を節約できるのであれば、リリースはメジャーと言えるでしょう。なぜなら、新しい API に賭けることによって、彼らにとってメジャーな取引に集中できるからです。

パートナーとは、Windows を含むエコシステムを形成する PC、ハードウェア、インフラなどを制作する広い範囲の人々を示します。パートナーはメジャー リリースをチャンスという意味で考える傾向があり、そのため、メジャー リリースとはたくさんの変更があるものであり、つまり、新しいハードウェアやインフラを顧客に提供するチャンスをもたらしてくれるものです。その一方で、過去との非互換は、パートナーに前進を中断させて新しい Windows との互換性を保つために過去の仕事の見直し作業を必要とする場合、決して肯定的な面では見られません。もし、いくつかの理由によりパートナーがそのような作業をしないと選択したならば、リリースはエコシステム サポートの欠如からマイナー リリースと見られるでしょう。つまり、大きな変化はメジャーまたはマイナー リリースのレンズを通して見られます。

IT 技術者はしばしば、生来保守的で変化に対しても保守的な見方をするとみなされています。ビジネスに重点を置くという役割の性質上、ソフトウェア製品の評価は投資収益に即して行われます。そのため、IT 技術者にとってのメジャー リリースとは、大幅なビジネス価値をもたらすものということになるでしょう。このビジネス価値は、たとえばソフトウェアの導入や管理における大きな投資と定義することができます。一般ユーザーや開発者にとって、これらの機能は興味の対象にもならないことはもちろん、メジャーかマイナー リリースであるかにも値しません。

インフルエンサーは、私たちの作ったソフトウェアに対してアドバイス、分析、および視点を提供するビジネスに従事する人々です。これらの人々はしばしば、「変化」の基準を通してリリースを見ます。大きな変化がメジャー リリースです。大きな変化は、Windows 9x から Windows 2000 への移行で見たような「再設計」かもしれません。– これらの製品は似ていましたが、中身には大量の変更がありました。そのため、批評家やアナリストにとって、これは当然ながらメジャー リリースでした。大きな変化は、ユーザー インターフェースでの大きな変化でもありえます。なぜなら、それはたくさんの議論を促しますし、変化を表現するのは簡単だからです。けれども、このメジャーの定義は、肯定的には捉えられないこともあります。再設計は非互換の可能性を意味します。新しいユーザー インターフェースはすでに学び慣れ親しんだものからの移行を意味します。

私たちは、メジャー リリースのシンボルとして Windows の再設計について論じられているコメントを多く見てきましたし、私自身もそのような電子メールをたくさん受け取っています。また、私たちは、メジャー リリースがどのように過去のサポートを断ち切ったかについてのフィードバックもたくさん受け取ってきました。一般的には、もし私たちがそのようにすると、たくさんの他の大きな利益が付いてくるであろう – 再設計はよりよいパフォーマンスを、過去との決別はより少ないメモリ使用量をもたらす – と人々は言っていることが多いようです。これらのことについて議論するときはいつも用心しなければなりません。どうやって修正したらよいかわかっている箇所一つ一つのことと、もしかしたら新たな問題を引き起こしてしまうかもしれず結局修正できないようになってしまうかもしれない、という両方のことを、いつも比較検討しているのです。そのため、実装という点に関してメジャーリリースを定義するよりも、実装そのものがどうあれ、その利点ということに関してメジャーリリースの成功を定義する方が、より意味のあることだと考えています。この議論はこれからも継続させていただきます。たくさんお話があります。

鍵となるのは常にバランスです。もし、すべての必要な人々が変化に対応できるよう準備できるのであれば、すべての顧客に対して大きな変化を実現できるでしょう。正しいタイミングの正しい変化であれば、小さい変化でも大きなインパクトをもたらすことができます。そして、それはいずれメジャー リリースとして記録されるでしょう。

タイミングとチームの編成方法についてお話してきましたので、どんなときにWindowsの開発プロジェクトに対して“インプット”をしていけばよいか、おわかりいただけたと思います。私たちがよく耳を傾け、努力を正しく集中させれば、それぞれのタイプのお客様は製品の価値に気付いていただけると思います。そして、私たちが効率的に製品についてコミュニケーションしながら仕事をすれば、「問題」となるようなこともエコシステムのより広い意味で捉えられ、一部の人たちが大いに利益を得るときもあれば、あらゆる人がトータルで恩恵を享受するようになるかもしれません。

私たちの立場からすれば、Windows 7 クライアント OS を作り上げるために、Windowsグループのすべてのエンジニア チームとその膨大な時間をささげています。このことは、あらゆる定義において、メジャーな取り組みであることを示しています。私たちは Windows 7 を最高のリリースにするつもりです。

それぞれの種類の顧客にとってリリースがどんな規模であるか決定する際には、物の見方がすべてあることを理解していただけると幸いです。

--Steven