β版とCTP版は何が違う？――変わるソフトウェアのリリースプロセス（2/3 ページ）

[Greg DeMichillie，Directions on Microsoft]

　だがVisual Studio 2005では、Microsoftはあえて、同製品のコアユーザーであるソフトウェア開発者がプレβソフトウェアの本質を理解し、このリリースをその用途のとおりに受け止めてくれる可能性――つまり、ソフトウェアに変更を加える時間があるうちにフィードバックを集めるための早期ビルドであるという点を理解してもらえる可能性――に賭けてみた。また、顧客によるフィードバックの提供を促進すべく、Microsoftは顧客向けにデータベースを公開し、各自が自由に同製品のバグを記録したり、書き直しが必要な機能を特定したり、新機能を提案したり、バグの優先順位について投票したりできるようにした。Microsoftの開発チームは、このデータベースをモニタすることで、開発者である顧客たちの意見をかつてないほど深く洞察することができた。

製品の構築／出荷を実習

　MicrosoftはVisual Studio 2005のCTPをリリースすることで、顧客からフィードバックを集めるための手段を得ただけでなく、製品の構築と出荷を実習することができた。

　Microsoftの重要な製品は大半が大規模なソフトウェアプロジェクトで、そこには、何千人とは言わないまでも、何百人もの開発者がかかわり、複数の開発チームによって生産される何千ものコードモジュールがかかわっている。多くの場合、プロジェクトを組み立てる（ソフトウェアの実行可能なコピーを作成する）という一見シンプルなタスクは、それ自体が大変な仕事になりかねない。何千というソースコードファイルのそれぞれについて、適切なバージョンを1台のマシンに集め、それを適切な順序でコンパイルし（テキストからバイナリコードに変換する）、最終プログラムを構成する多数の実行ファイル、DLL、.NETアセンブリにアセンブルしなければならない。

　だが、製品の構築は平凡で、しかも報われないことの多い作業だ。チームが製品ビルドを定期的に（できれば毎日）入念に確認し、ビルドのエラーを退け、修正することを開発者の最優先項目とするのでなければ、製品ビルドにはすぐにも遅れが生じ、製品を完成させることが困難になりかねない。McCarthy氏はこの点を次のように説明している。

　「頻繁なパブリックビルドは、想定ではなくリアルな依存ツリーをあらわにする。すべての要素が適切に揃っていなければ、製品は構築できない。開発チームはビルドの問題によって、できれば無視したかったような問題に直面させられる」と同氏。

　従って、CTPの定期的なリリースを公言すれば、チームにとってはそれが強制力となり、CTPを提供していなければ便宜上無視してしまっていたであろうビルドの問題を修正せざるを得ないことになるだろう。つまり、CTPを定期的に作成できるチームは、「ビルドの問題」を解決できたチームということになる。

CTPのリスク

　CTPの提供はこれまでのところプラスに作用しているが、Microsoftと顧客は幾つかのリスクにも直面している。特に、同社が開発サイクルの後期の段階でCTPを使用していることによる影響が大きい。

CTPはβの代替になるか？

　Visual Studioチームの成功を受けて、CTPモデルはMicrosoft社内のそのほかのチームでも採用されるようになってきている。最初は、SQL Server 2005、Windows Presentation Foundation（WPF）、Windows Communication Foundation（WCF）など、開発者向けの製品で採用され、その後、Windows自身にも採用されている。

　だが、MicrosoftがCTPの使用方法を最も大きく変更したのは2006年初頭のことだ。同社はWindows Vistaについては今後β版をリリースせず、代わりに一連のCTPをリリースするという方針を発表した。より頻繁にCTPをリリースすることで、MicrosoftはOSで必要となる広範なハードウェア／ソフトウェアの互換テストを実施しやすくなるだろう。だがその一方で、より頻繁なCTPのリリースは、全般的な品質目標とスケジュール目標の達成を難しくする可能性がある。

　CTPをリリースする場合には、その都度、そのビルドが基本的な品質要件セットを満たしていることを確認するために、ある程度のテストが必要となる。たとえ、きちんと組織化され、うまく機能している開発チームであっても、顧客にそのまま提供できるデイリービルドを作成するのはほとんどあり得ないことだ。テストと安定化のための期間が必要となるからだ。こうした安定化のための期間中は、開発者は最も深刻なバグしか修正できない。なぜなら、ソースコードへの変更は、たとえバグをフィックスするためのものであれ、新たなバグをもたらす危険や、古いバグを再度もたらす危険を伴うからだ。McCarthy氏はこのプロセスの説明に「Don't Shake the Jell-O（ゼリーを揺らさないこと）」という表現を使っている。

　「製品を出荷するということは、揺れている巨大なゼリーを給仕するのを監視するようなものだ。ゼリーの揺れは徐々に緩まるが、バグをフィックスすれば、たちまち逆上したかのように再び揺れ始める」と同氏。

　Visual Studio 2005では、Microsoftは開発プロセスの早期段階でのみCTPを使用し、顧客に対しては、各CTPには以前の開発プロセスほど十分なテストや安定化作業を行っていないことを明言した。つまり、リリースの頻度を高めることを優先し、各リリースのテストの徹底を妥協したということだ。早期段階でCTPを提供する目的はフィードバックの収集であったため、この折り合いは無駄ではなく、適切な製品を出荷するというMicrosoftの取り組みにもプラスに作用した。