“アジャイルイノベーション”に舵を切るMS――開発文化を根本的に見直し（4/4 ページ）

[Michael Cherry，Directions on Microsoft]

　例えば、ネットワークスタックに変更を加えてパフォーマンスとセキュリティを強化し、新しいネットワークプロトコルをサポートする場合は、ほかのアーキテクチャ変更は後続のリリースで行うべきだろう。

　マグリア氏は以前から、メジャーリリースとマイナーリリースを交互に提供するというサイクルを実施すれば、より予測可能なロードマップとリリーススケジュールを設定できると語ってきた。だが、長い製品サイクルは一筋縄ではいかない場合がある。MicrosoftはSQL ServerやWindowsのような製品の開発チームに、補助的なコンポーネントアップデート（SQL ServerのReport Servicesや、Windows XPのSP2など）の提供を奨励してきたが、これはリリースサイクル全体の長期化を招いた。そして同社はメジャーリリースの出荷延期を余儀なくされ、そのリリース間隔は5年も空くことになった。だが、そもそもリリースが遅れた原因は、多くの技術を追加したことにある。

現実的なリリーススケジュールを組む
　Microsoftの従来のもう1つの強みとして、ソフトウェアの力に対する同社の楽観的な信念がある。この信念に基づいて、同社は大きな構想を描くことができた。だが同社は、それに基づく製品の開発／テスト期間を正確に見積もることができていない。Microsoftは社内の開発チームに、新バージョンの機能仕様をより現実的に作成し、新バージョンがより短期間で開発、テストできるようにすることを奨励する必要がある。そうした機能は、明確に定義された小さなコンポーネントとして提供され、ほかのコンポーネントや製品への依存が少なく、リリースされた後で、それらと幅広く統合することが可能だろう。