2015年3月14日 3:27 PM

Windows Insider Program へのビルドの提供頻度と時期について

皆様、こんにちは。

Windows Insider Program のしくみや Windows 10 の開発状況については、Windows 10 コミュニティ フォーラムや Twitter を通じて皆様から多数のご質問が寄せられています。しかしこれらの場所では、皆様一人ひとりに向けて回答したり、思ったように詳細な内容を説明することはなかなかできていません。その代わりとして定期的に使用しているのが、Insider Hub や、今回のようなブログ記事です。Insider Hub にはよく寄せられる質問を投稿したりしています。

今回最初にご紹介したいのは、私の Twitter フィードをこの 2 週間ずっと埋め尽くしているあるご質問についてです。それは、「次のビルドを早く提供して!」というものです。まずお伝えしておきたいのは、皆様から「新しいビルドを早く手に入れて、新機能を試したい」という声をいただけるのは、私たちにとって大変な喜びであるということです。これは、Windows Insider Program を立ち上げた当初から願っていたことです。皆様の熱意に心から感謝いたします。

新しいビルドを熱望する声のほかにも、さらに以下の 2 つの質問が寄せられていました。これらに対しても、140 文字という Twitter のテキスト制限ではうまく回答することができませんでした。

  1. 「これからはもっと速いサイクルでビルドが提供されるという話が 1 月にあったと思いますが、どうなっていますか?」
  2. 「次のビルドのリリース日だけでも教えてくれませんか? もっと情報を多く開示してもらえませんか?」

この記事では、この 2 点についてもう少し明確に説明させていただきたいと思います。もちろん、私たちは情報を隠そうとしているわけではないのですが、皆様のご納得のいく回答をさせていただくのは思ったよりも難しいことで、皆様を長らくお待たせしてしまっていることに弁解の余地もありません。

ビルドの提供頻度と「より速いビルド提供」の可能性について

このご質問に簡単に答えるとすれば、Fast リング (提供頻度が高い) を選択した皆様へのビルドの提供に保守的になりすぎていた、ということです。

社内では今、Fast リングの今後の扱いについてさまざまな議論が交わされており、一部のプロセスでは既に変更が加えられています。現実問題として、ビルドを速く提供するほどバグの数も増えるということがあります。そのため、これまでは安定性を重視しすぎていたのかもしれません。この過程では、Fast と Slow の違いをあまり意識して来なかったのも事実です。社内では Canary というテスト段階を設けており、OSG と比較して 2 ~ 3 倍のペースでビルドを提供しています。こうすることで Canary の段階で問題を検出し、OSG に持ち越さないようにしています。

ビルドは、フライティングの段階を経て最終的にリリースされる。ビルドが条件を満たすと、次の段階に移行する。

 

これは私たちにとって新しい手法であり、実際に進めながら学習していき、改善しているところです。外から見れば過去のプレビュー プログラムや Vista 以前の CTP プログラムと似ているように思われるかもしれませんが、手法や基盤となるテクノロジには無数の違いがあります。そして、まだ実装していない優れた機能もいくつかあります。現在は、Fast リングのスピードとリスクのバランスを調整するだけでよいのか、あるいは、それよりも頻繁にビルドを入手したいと望んでいる方々のために新しいリングを設けるべきなのかについて議論しています (先週、「Ludicrous Speed (ありえないスピード)」リングを設置しようかと、メンバーと話していました。冗談ではなく)。これについては、結論が出ましたら皆様にも発表したいと思います。

この他にも、ビルドに新機能を追加する場合は、皆様に提供する前に、安定性を確保しうまく統合させるまでに多少の時間が必要になります。必要な期間はまちまちであるため、ビルドの提供スケジュールを予測してお伝えすることはできないのです。思ったよりも早く完了する場合もあれば、遅くなる場合もあります。以前 Twitter で、ビルドの提供は「月に 1 度ほど」とお伝えしたのは、こうした理由からでした。通常なら約 30 日に 1 度のサイクルで新しいビルドをリリースできますが、場合によっては (ちょうど今のように) もう少し時間がかかります。

次期ビルドのリリース日を公表することが難しい理由

皆様のご想像とはうらはらに、リリース日を公表すると、公表しない場合と比べてビルドの公開ペースは落ち、最新ではないコンテンツを提供しなければならなくなります。それはなぜでしょうか? これには次のような理由があります。

  • リリース日を公表する場合、その期日に必ずリリースできるという確信がなければなりません。もしリリース日に間に合わなければ、私たちが動揺するだけでなく、皆様にも不愉快な思いをさせ、期待を裏切ることになってしまいます。さらに、エンジニアリングのペースも落ちます。期日を守れなかったことで混乱したエンジニアも、リリース日が確定されていなかったとしたらもっと積極的に作業を進められていた可能性があるからです。
  • 確実に期日を守るためには、実際に提供が可能になるよりもずっと先の日を期日として設定することになります。これは、バグを見つけた場合やビルドの再テストが必要になった場合に、それに対応できる時間を確保するためです。
  • これはよくあるケースですが、最新のビルドが完成していても、公表したリリース日がまだ先であれば、公開せずにその日をじっと待つことになります。つまり、ビルドを「温存」しておくのです。前倒しで提供してもよさそうなものですが、突然前倒しになることを嫌う人もいれば、「予告した日付を守ったり、守らなかったりする」という印象を植え付けてしまうことにもなります。リリース日を決めたからには、確実にその日に提供されるものだと思っていただく必要があります。
  • 最悪のケースでは、難しいバグに直面して時間がなくなり、期日に遅れてしまうということも考えられなくはありません。もちろんこれは突然前倒しで提供するよりも避けるべきことですが。いずれにしても、発表された日付に提供されると信じてくださった方々を失望させることになります。

では、この方法を次期ビルドのリリースに当てはめて考えてみましょう。今日は 3 月 9 日で、3 月中には必ずビルドを提供したいと考えているとします。リリース日を公表するとしたら、確実にお約束を守るために、3 月 26 日あたりを選びます。それだけの時間があればビルドの安定性を確保できますし、その日はちょうど木曜日です (月曜日や金曜日は避けるようにしています)。それまでの間に、さらに新機能を追加していきますが、3 月 17 日前後には安定性を確保する段階に突入し、限定的な変更のみを加えるようにします。安定性を確保するためには新規コードが少ない方が簡単なので、主要な修正のみに絞り込むことになります。3 月 23 日にはリリース候補のビルドが完成し、社内に広く配布して潜在的な問題がないかどうかを確認し、準備万端でリリース日を迎えます。これも決して悪くなさそうですが、「最悪の事態」が起きたら話は別です。何らかの理由で期日を守れなくなれば、皆様を失望させてしまいます。こうなると、月に 1 度と公表したリリース日には、最新ではなく「比較的新しい」ビルドを提供するしかありません。

次は、私たちが実際に試している方法をご説明しましょう。今日は 3 月 9 日で、次期ビルドのリリース日は設定していません。私の手元には、既に先週の金曜日に完成したビルドがあります。自動化されたテストでの検証を終え、これから社内の複数のテスト段階に入り、何千ものマイクロソフト社員がインストールして使用することになります。これは最も新しい機能と修正が反映された、まさに「最新」のビルドです。社内の評価基準をすべてクリアすれば、今週後半から来週前半には皆様に提供できるでしょう。うまくいけば、3 月中に 1 つではなく複数のビルドをリリースすることも可能で、リリース日を公表した場合よりもさらに新しいビルドを提供することもできます。もちろん現実には、最後のビルドがリリースされてから 40 日以上も経っている状態なので、1 か月に複数のビルドを提供するなど現実味のない話かもしれません。ここでは私たちの目標とそれに向けた取り組みをご紹介しました。従来の方法ではなく、この新しい方法で開発を進めていきたいと考えています。ビルドの公開日が確定しているという制約がない方が、かえってビルドを速くリリースできるからです。実際の例で言えば、1 月 21 日の Windows 10 イベントの翌々日にリリースされたビルド 9926 は、リリース日を公表するかどうか社内で議論が交わされました。このとき、私たちには次の選択肢がありました。

  1. リリース日を「1 月 23 日」と公表し、何週間も前に完成させた、Windows 10 イベントでのデモで紹介した多くの新機能が含まれていない状態のビルドを提供する。
  2. リリース日を「2 月 15 日」と公表し、私たちが余裕を持ってビルドの開発に取り組み、満足のいくものが完成したら発表日まで「温存」させておく。
  3. リリース日を発表せず、段階的なテストを実施していき、準備が整った時点でリリースする。

私たちは 3 番目の選択肢を採用し、これが功を奏しました。最も新しい機能や修正を追加した最新のビルドを、目標どおり 1 月 23 日にリリースすることができたのです。

フィードバック、ご質問をお寄せください

この記事によって、私たちのビルドの提供頻度に対する考え方や、皆様からのフィードバックへの対応の仕方について、皆様に少しでもご理解いただければ幸いです。製品を使用したご感想やフィードバックを熱心にお寄せくださる Windows Insider Program のすべての皆様に、改めて感謝を申し上げます。皆様からのフィードバックは、この製品のあらゆる側面に反映させていただいています。近日中には今回と同様の記事を公開し、皆様からよく寄せられるもう 1 つの質問である「フィードバックの活用方法」についてご説明したいと考えています。

どうぞお楽しみに。 Gabe Aul