読者です 読者をやめる 読者になる 読者になる

Vista と .NET の Agile な行方

Vista .NET

ちょっと前の記事ですが,ここ数年の混乱にまつわる問題点を突いた分かりやすい記事だと思います.私自身はそこまでアジャイル好き好きな人間ではないのですが,非常に示唆に富む内容でおすすめです.

アジャイルイノベーション”に舵を切るMS――開発文化を根本的に見直し
http://www.itmedia.co.jp/enterprise/articles/0609/06/news012.html



ちなみにこのあたりの話,内情知ってて書いているとしか思えないような.

また、一部のチームの作業はWinFSファイルシステムなど、Vistaから後に外された技術に依存していた。WinFSVistaへの搭載を前提にして、WinFSに関連するコンポーネントの開発作業が進められていたことが、それらのコンポーネントや、ひいてはVista自体の完成を遅らせた可能性もある。

この優先順位の変更により、Microsoftはより迅速に製品を出荷できるかもしれない。だが、この変更は、顧客に一貫性のないメッセージを送ることになる恐れがあるなど、固有の問題をはらんでいる。例えば、Officeは従来から、大幅に遅れることなく、かなり予測可能なスケジュールで出荷されてきたが、それはOffice部門が多くの場合、他部門のコードへの依存を拒否してきたからだ。このため、Microsoftは.NET Frameworkのメリットを顧客やパートナーにアピールしているが、Officeを.NET Frameworkの宣伝の目玉にすることはできない。WordやExcelのようなOfficeの主要製品では.NET Frameworkは使用されていないからだ。



しかし何より頷けるのが,この部分です.

依存関係に縛られる統合の問題点

しかし、統合には弊害もある。統合を進めることでさまざまな面で依存関係が増大するため、チーム間の調整が煩雑になり、製品のビルドを定期的に作成するなどの重要な作業が複雑化し、開発サイクルが遅くなることだ。

例えば、Windows VistaVisual Studio 2005、SQL Server 2005の出荷が遅れた一因は、統合イノベーションへの取り組みに伴い、これらの製品のさまざまなコンポーネントを担当するチーム間や、こうしたチームと、これらの製品に依存するほかの製品の担当チームとの間で多くの依存関係が生じたことにある。これらのチームは一般に、それぞれ異なる顧客層に対応していたため、優先事項がそれぞれ異なっていた。その結果、効果的に協力し、コミュニケーションを取ろうという動機が乏しかった。

さらに、依存関係が循環し、関連するすべてのチームの進捗に支障が生じてしまった。例えば、Visual Studio 2005とSQL Server 2005が開発されていた当時、SQL Serverチームは、開発ツール部門が担当する.NET Frameworkを必要としたが、開発ツール部門は、.NET Frameworkベースのデータベースツールを作るためにSQL Serverを必要とした。

この依存性循環の悪夢には,開発プロセスに関わるベータテスターも含まれています.
ベータ版は使いにくいために使ってもらえず,その結果ごく単純なフィードバックすらもらい忘れた状態で初期リリースがなされてしまう,という問題.そしてリリースが宣言されたことで「ちょっと試してみた」ところ大量に不具合が発覚し,それを元に ServicePack でブラッシュアップするという構図が出来上がってしまう.と.そんなことが何回か繰り返されるうちに,ある人は「SP2 が出たら使うべし」と言いだし,さらにベータ版は避けられるようになる,というわけです.今のように OS リリースが巨大化している状況では,このリスクはどんどん高まっているのではないでしょうか.
現実的に考えて,今から Vista の UI には数多くの改良すべき点があるを訴えたところでリリースまでに修正するのはまず無理でしょう.今は少しでもクラッシュバグを減らし,パフォーマンス・チューニングに努める時期です.本当にコミュニティからのフィードバックで UI を良いものにしていきたければ,もう 1 年以上は早く「十分軽快に動く」評価版を用意すべきでしたし,そんなことは当事者もよく分かっていることでしょう.



ベータテストへの開発者の参加が十分かどうかもかなり怪しいところです.特に日本の開発者の参加が遅れると,日本固有の問題,例えば日本語変換周りの API が悲惨なままリリースされてしまう可能性はかなり高くなります.実際 WPF は IMM API ではなく TSF をベースにしているため,従来できていた変換処理ができなくなるといったトラブルが予想されますが,はたして何人の開発者が WPF での IME 処理などというニッチな分野を本格的に試しているでしょうか?*1
一方で,今回「問題が明らかになった」ところの「統合イノベーション」ですが,これが盛んであった分野の MSDN blog などを見ていると確かに興味深い統合作用のようなものがおきていたように思います.明らかにコアな開発者を意識して書かれたエントリが MSDN blog に並び,分野を越えて盛り上がるという光景が,製品リリースまでに何度も見られました.この川西さん曰く「カオス」な世界は,これはこれで楽しめるうちは楽しいものだと思います.問題はそういう楽しさを振り切ってでもちゃんとリリースしなきゃだめということと,そういった資料を入手するためにカオスな世界に足を踏み入れなければならない状況を何とかすべしということと,何よりそこに日本語の入り込む余地がない,ということでしょうか.あちらで楽しくやっている感覚が,国内になかなか伝わって来ない状況はもうちょっと何とかならないかなぁという気がします.


さて,話を Vista に戻すと,結局私が本格的に Windows Vista という OS を試し始めたのは,フィーチャフリーズ直前のベータ 2 のころでした.Visual Studio 2005 をはじめとした「いつものアプリケーション」が一通り動く環境がハードウェア的にもソフトウェア的にも実現され,「いつも通り」の心境で「いつも通り」の作業ができるようにならないと,「いつもと同程度」の評価作業すらままなりません.
本当は,Transactional NTFS やカーネルのメモリ管理といった,GUI 以外の部分だけでももっと早く評価したかったのですが,腰を据えてデバッガに向き合える程度まで完成してくれないことにはやはり使う気になれませんでした.
まあなんにせよ,「なぜソフトウェア開発に循環依存性を持ち込むべきではないのか」「究極の統合に世界随一の資金力で挑むとどうなるか」といった事柄に関する,非常に興味深い事例の宝庫だったりするのではないかと思います.数年後でよいので,今回の教訓を伝える名著が登場することを祈りましょう.
最後に独り言ですが,LINQ プロジェクト,うまく行くといいですねぇ.

*1:余談ですが,Vista からは従来の IMM API から TSF への明確なシフトが打ち出され,標準では TSF タイプの IME しか付属しません.ATOK 2006 などの既存の IME をインストールすれば IMM API は直接ネイティブで動作しますが,TSF のみの環境では IMM API はエミュレート・レイヤーによって互換動作させられます.この互換処理は Vista に搭載される TSF の新機能を必要としますが,WPF はこれらの TSF 新機能をサポートしない公算が強いです.詳細については『Windows Vista 評価ガイド』を参照してください