昔、高校のコンピュータ サイエンスのクラスで A を取るため短期間にジャグリングを習得しなければならないことがありました。これは作り話ではありません。全身を使って行うジャグリングは、プログラムを記述する作業に何となく似ています。とにかく、そのときにはそれが意味のある作業だったのです。

その学期 (最後の学期でした) はがんばったので、良い成績を取れるだろうと期待していました。しかし、担当の先生 (多分私が会った中で一番の教師) が見せてくれた成績は、期待していたより低かったのです。詳しいことは省きますが A より下の成績では困る事情があったので、原因を教えてくれるように先生に頼みました。2 人で採点簿を確認したところ、その学期の前半に出された課題を終えていないことがわかりました。その課題がジャグリングだったのです。さかのぼってよく考えたところ、ジャグリングの日に欠席したことを思い出しました。別の高校で開催された物理学のセミナーに招かれて出席していたのです。その後、ジャグリングのことはまったく忘れていました。この課題を終えなくてはならなかったのですが、最終日は翌日に迫っていました。

単位を取るには、3 つのボールを使ったジャグリングで、ボールを一度も落とさずに 3 周連続して受け止められるようにならなければなりませんでした。私の腕前では、1 つのジャグリング ボールを上げて、それを落とさずに受け止めれば上出来といったところでした。祖父母が引っ越しするときにもらい受けたボロボロの電子オルガンがなければ、これを成し遂げることはできなかったと思います。それはグランド ピアノよりも大きい古い巨大なオルガンで、足踏みペダル、2 列の鍵盤、特殊な "コード モード" などがありました。とりわけすごかったのは 2 ダースほどのボタンで、押すとドラムのリズムを付けられるのです。鍵盤の電気回路は傷んでいましたが、リズム ボタンはうまく働きました。私はボタンを "ワルツ"、スピードを "スロー" に設定してメトロノームのように使い、4 時間ほどジャグリングを練習しました。練習中、徐々にスピードを上げました。手短に言えば、この方法が功を奏して A を取ることができたのですが、それ以来、ワルツのビートが頭から離れなくなってしまいました。

Visual Basic とジャグリング

現在 VB チームは、たくさんのボールを空中に投げてジャグリングしている最中です。製品サイクルの最初と最後は、いつも一番忙しい時期です。それに比べたら、実際のコーディングのマイルストーンは楽なものです。現在進行中の作業は次のとおりです。

        VS2008 のリリース。タイプミスではありません。VS2008 には多数のローカライズ版があり、現在リリースに向けて準備中なのです。Visual Studio のこれらのバージョンも英語版と同じ配慮をして処理する必要があるため、かなりの時間をかけて準備しています。優秀なインターナショナリゼーション チームが中心となって作業を進めていますが、私たちすべてが、多かれ少なかれこの作業に携わっています。

        バグの修正。通常は、製品をリリースした翌日に、顧客が見つけたバグ (または顧客の提案) についてのフィードバックの収集を開始し、バグの修正を始めます。こうした修正を含んだサービス パックがリリースされたり、製品の次のバージョンに修正が組み込まれたり、その両方が行われることがよくあります。バグを発見した場合の対処方法については、http://connect.microsoft.com/visualstudio (英語) をご参照ください。現在もこの作業が進められており、適切に修正できるように、優秀な QA チームが多くの時間を費やして処理しています。

        MQ"M" はマイルストーンを、"Q" は品質を意味します。次の製品サイクルを開始する前に、私たちはエンジニアリング プロセスをすべて見直し、適切に調整する必要があります。前回この作業を行ったのは VS2005 のリリース後で、すばらしい成果を上げることができました。たとえば、新しいプロセスでは、チェックインされたコードの欠陥を、製品開発中に全体で 75% も解決することができました。これによって、大幅なパフォーマンスの向上も実現できました。

 

今回の MQ での大きな目標は、製品サイクルの早い段階で "ドッグフーディング" を行うことです。"ドッグフーディング" とは、開発途上の製品を自分たち使うことです。そうすることによって、部門内のすべての人がさまざまな条件下で製品をテストできるようになります。テスト ラボで扱うことができる条件は限られているので、ドッグフーディングは問題点を早期に把握するのに役立ちます。以前は、2 番目のベータ版ぐらいまで、前バージョンの製品を使って新バージョンを開発していました。その後で新バージョンに切り替えて、それまでに見つかった問題点を処理するという方法でした。この切り替えを徐々に早めてきましたが、今回の目標は、コーディングのマイルストーン中に新バージョンの製品をインストールしてフルに使えるようにすることです。これには、コンパイラ機能からプロダクション ツールまでが含まれます。

 

この目標を達成するには、(VS2008 のインストール済みバージョンを損なわないようにするなどの目的で) 製品を前のバージョンと "併用" できることを確認する必要があります。また、簡単にインストールできること、および自動化されたテストを新しいバージョンに切り替えることができることも確認する必要があります。さらに、コードをチェックインして操作できるように、新しいバージョン用の適切なコード保存場所とバグ追跡システムをセットアップし、コードをメイン ビルドに回す前にできるだけ多くのバグを見つけることができるように、新しいコード用のチェックイン要件を調整する必要もあります。これら以外にも、エンジニアリング作業の効率性を高めるための多くの取り組みが進行中です。この作業をこれほど早く開始するのは大変で、時間も人手もかかりますが、これが成功すれば皆さんと私たちの双方に大きなメリットがもたらされます。

        次のバージョンの準備。私たちは、これまでに書いてきた作業と同時に、次のバージョンの計画にも精をだしています。皆さんから多くのご提案をいただいているだけでなく、チームのメンバからもさまざまなアイデアが出されており、Visual Studio の次のバージョンに向けたロードマップの作成に取り組んでいます。この時期はいつもとてもエキサイティングで、プロトタイプや提案を見るのが楽しみです。最高なのは、すべてが終わってから振り返ってみて、"目標を達成できたぞ!" というときです。今、VS2008 をリリースして、この気分を味わっています ("LINQ はなんてすごいんだ!")。次のバージョンをリリースするときにも、この気分を味わいたいと願っています。今後数か月のうちに、次のリリースに盛り込まれる機能についての情報発信が始まりますが、皆さんに期待していただける機能をお届けできると確認しています。

このように、私たちのチームでは多くの作業が一度に進行しています。私の場合、3 つの異なるトピックについて 3 つの異なる会話を平行して進めているように感じることがあります。私が空中に投げたボールを 1 つも落とさずに、すべての作業を処理できるように願っています。ここでは電子オルガンでワルツのテンポをきざんでも役に立ちそうにありませんが、ジャグリングのときとは違って、すばらしいチームと一緒に作業しているという利点があります。

来月には、このブログ用にもっとコーディングをお見せしたいと思っています。私の投稿ではまだ LINQ を取り上げていなかったと思うので、これについてもカバーする必要があります。なお、前にお見せしたコードに簡単にアクセスできるように、新しいコード ギャラリー サイトに追加しました。このギャラリーには、http://code.msdn.microsoft.com/templeofvb (英語) からアクセスしていただけます。VB Euchre ゲームのインストール可能なバージョンも含まれていますので、ぜひご利用ください。

次回をお楽しみに。

  --Matt--*

VB チーム

投稿 : 2008 1 30 8:20 PM

分類 :Matt Gertz, VB2008

VB チームの Web ログ - http://blogs.msdn.com/vbteam/archive/2008/01/30/preparing-for-the-next-product-cycle-matt-gertz.aspx (英語) より