連載：Visual Studio Team Systemで開発プロジェクトはこう変わる 第1回 Visual Studio 2005 Team Systemはココがうれしい 日立システムアンドサービス　酒井 達明 Microsoft MVP for Solutions Architect（Jan 06 〜 Dec 06） 2006/03/08

Page1 Page2 Page3

Visual Studio 2005 Team Systemとは何か？

　Visual Studio 2005（以下、VS 2005）パッケージ版が正式にリリースされ、いよいよ.NETもバージョン2の時代が到来した。今回リリースされたVS 2005は、Windows Vistaで新たに提供されるWinFXへ向けたマイナー・アップデートと思われがちであるが、実際にはそれは大きな間違いだ。

　というのもVS 2005のラインアップには、今回紹介するVisual Studio 2005 Team System（以下、VSTS）が含まれており、これこそが「大きな変革」を象徴しているのである。VSTSの登場により、これまで単なるソフトウェア開発の統合環境（IDE）であったVisual Studioは、ソフトウェア・ライフサイクルにおける企画〜設計〜生産〜運用のすべてのステップをサポートする開発環境へと大きく変化したのだ。

　これらのソフトウェア・サイクルを担うメンバーには、ソフトウェアのアーキテクチャを定義し、ソフトウェアの仕様や制約事項を決定する役割を担う「ソリューション･アーキテクト」、サーバおよびネットワーク構成を定義し、開発されたソフトウェアを安定稼働させることに責任を持つ「インフラストラクチャ・アーキテクト」、そしてソフトウェアのテストを担当し、ソフトウェアの機能要件および非機能要件を満たすことを検証する「テスティング・エンジニア」、さらにはソフトウェア開発プロジェクトのスケジュール、コスト、品質を管理する「プロジェクト・マネージャ」が存在する。

Visual Studio 2005 Team Systemがサポートするプロジェクト・メンバー

VSTSは、ソフトウェア開発者以外のロールを持つプロジェクト・メンバーに対しても、さまざまな側面でシステム開発を支援する。

　つまり、このようなソフトウェア開発者以外のロールを持つプロジェクト・メンバーに対しても、Visual Studioがさまざまな側面で支援することになるのである。

■Visual Studio 2005 Team Systemの各エディション

　VSTSには大きく分けて、以下の3種類のエディションが存在する。

• ソフトウェアの企画〜設計を担うアーキテクト向けのエディションである「Team Edition for Software Architects」

• 設計〜開発〜単体テストを担当する開発者向けの「Team Edition for Software Developers」

• 組み合わせテスト〜負荷テストを担当するテスティング・エンジニア向けの「Team Edition for Software Testers」

　以上が、それぞれの役割に向けられたエディションである。また、これらのすべてのエディションで提供される機能を含むTeam Suiteも提供されている。

　これらに加えて、チーム開発に必要な変更管理や進ちょく管理、作業項目管理、バグ・トラックなどの機能を搭載した「Visual Studio 2005 Team Foundation Server」が2006年夏ごろに提供される予定である。

　以下にこれら3つのエディションとTeam Foundation Serverの機能構成図を示しておく。

Team Systemの3つのエディションとTeam Foundation Serverの機能構成図

■Team System誕生の背景

　ではそもそも、VSTSはなぜ生まれたのであろうか？ もともと「Whitehorse」という開発コードで呼ばれていたこの製品（主にTeam Edition for Software Architectsのデザイン・ツールの機能）は、.NETがエンタープライズの世界で広く利用されるようになり始めた2002年ごろに開発がスタートしている。従来のVisual Studio .NET（以下、VS.NET）においてもエンタープライズ開発を意識した機能は提供されていたが、エンタープライズの現場で利用するにはシステム設計におけるモデリング機能やシステム運用に関するサポート、システムの品質を高めるためのテスティング機能などの面で力不足であったことは否めない。

　そのためわれわれは、サード・パーティ製のさまざまなツールを組み合わせて、それぞれの工程で利用してきた。例えば、設計の段階ではUMLモデリング・ツールなどを用いてドメイン分析を行い、クラス、コンポーネントの関連およびインターフェイスを設計してきた。また、インフラ系のエンジニアは、サーバをどのセキュリティ・ゾーンに何台配置し、そこにインストールされるOSのバージョンやエディションが何であるかといったサーバ構成図を、Visioなどの描画ツールを用いて記述していた。一方でテスト担当者は、高価なテスト・ツールを用いてアプリケーション機能のテストや負荷テストを実施してきた。

　しかし、それぞれがまったく連携することのできないツールを利用していたために、設計やテスト実行結果の妥当性を検証するには専ら人手に頼るしかなかったのである。従って、属人性（＝人によって作業にばらつきがあること）を排除することができず、検証の誤りや漏れを生み出す要因にもなっていた。そのため、良いシステムを作り出すための基本は「あいまいになりがちな要求仕様や品質基準に対する認識を統一するための十分なコミュニケーション」というベテラン・エンジニアもいたほどである。

　また、こうしたツールの選定はプロジェクト単位にまちまちであることが多い。大企業になると、標準的なツールセットを提供し、どの工程でどのようなツールを用い、どのようなアウトプットを出すべきかが明確化されているケースも存在する。しかし、多くの場合これらのツールを使うか否かは現場の判断に任されている。さらに、現場サイドのエンジニアの本音をいえば「いくつものツールの操作方法を習得するだけの時間が取れない」のである。

　こうしたことからも、「すべてVisual Studioで利用できる」というメリットは大きい。今回リリースされたVSTSはこうしたエンタープライズ向けソフトウェアの開発現場の声を受けての登場といえよう。われわれのようにエンタープライズ向けのソフトウェア開発を常とするものにとっては待望の製品だ。

■Team System導入で期待できる効果

　VSTSの導入で期待できる効果は、とらえ方によってそれぞれ異なると思われるが、エンタープライズ開発の現場においては、大きく分類して次の3点が期待できる。

　第1の効果は、「コミュニケーション・ギャップの解消」である。

　エンタープライズ向けソフトウェアの開発プロジェクトにおいて、数十〜数百人単位のさまざまな役割のスタッフが同時に作業を進めることは日常的である。そしてプロジェクトにかかわる役割やその人数が増えるに従い、プロジェクト・メンバー間の意思伝達はますます困難になる。

　そのため、長期にわたって紙ベースの仕様書が一般的に用いられてきた。こうした背景には、メインフレーム全盛の1970年代に、メインフレーム系各社のシステム・インテグレータ（SIer）が独自の開発方法論や標準的なドキュメント・セットを整備した歴史がある。当時は、現在よりもマシン利用のコストが高価であったため、できる限りマシンを利用しない設計方式である紙ベースの方法論が採用されていた。これらの方法論やドキュメント･セットを慣習的に利用し続けたことにより、現在でも紙ベースのドキュメントが広く普及しているのである。

　しかし、紙をベースにしたコミュニケーションは読み手によってさまざまな解釈を与えてしまいかねず、これがしばしばコミュニケーション・ギャップの原因となる。それ故に、VSTSに対する期待はおのずと大きくなる。

　例えばVSTSでは、インフラ設計者やアーキテクト、そしてソフトウェア設計者の意図が、そのまま開発環境の「プロジェクト・テンプレート」や「制約」となる。開発環境に直接作用するため、その効果は大きい。

　特に分散型アプリケーションの開発においては、各アプリケーション・ブロック間のコントラクトおよびインターフェイスを明確に定義できるため、「つながらない」という最悪の事態を事前に回避することが可能である。実際、このような事態は大規模システムではしばしば発生するトラブルなのである。

　またVSTSでは、詳細な仕様を定義する際に、テスト駆動モデルを活用してあらかじめ単体テスト・コードを記述することにより、開発前にクラスのインプットとアウトプットが明確化される。これにより、テストのあいまいさを排除することが可能になるという効果も期待できる。

　第2の効果は、「プロジェクトの見える化」が可能になることである。

　VSTSには、従来のVisual Studioと一線を画するプロダクトであるTeam Foundation Serverが含まれる。これは、開発者がエンド・ユーザーとして利用するサーバ製品である。このTeam Foundation Serverの導入により、「プロジェクトの見える化」が実現されるのである。

　Team Foundation Serverでは、ソフトウェア開発プロセスを定義した「プロセス・テンプレート」が数種類提供される予定である。このプロセス・テンプレートにはソフトウェア開発プロセスにおける作業項目がスキーマ化されており、作業すべき内容とそれらの順序が明確化される。

　プロジェクト・マネージャが、これらの作業項目を各メンバーに割り当てることで、開発メンバーは「自分がいつまでに何をすべきなのか」が明確になるのである。混乱した開発現場でありがちな「いま、自分が何をすべきなのかを把握できていない」といったことは、Team Systemを利用する限り発生しづらいのである。

　プロジェクト・マネージャの視点に立てば、「誰がどこまで進んでいるのか」が明確になるという利点がある。例えば、ある開発者の作業が遅れているならば、比較的余裕のある開発者に作業を割り当て直すといったように、進ちょくの遅れなどのリスク要因を早い段階で察知し、リスクに対する迅速な対策を打つことが可能である。

　また、このようにして開発作業を進めていく中で発見されたバグおよび、その解決状況などをリアルタイムに把握できるのも、品質管理において重要なメリットであるといえよう。

　第3の効果は、上述した2点の効果からもたされる「生産性向上」である。

　例えば、コミュニケーション・ギャップを解消することで設計者の意図が正しく伝わるようになり、開発作業の手戻りの発生を抑えることができる。あるいは、テストを無人化することで、テスト効率を向上させることが可能になる。

　また、開発状況の見える化を促進することで、連日繰り返される退屈な定例進ちょく会議から開発者を解放し、開発者は本来実施すべき作業に専念することが可能になる。

INDEX
	Visual Studio Team Systemで開発プロジェクトはこう変わる
	第1回 Visual Studio 2005 Team Systemはココがうれしい
	1．Visual Studio 2005 Team Systemとは何か？
	2．Team Edition for Software Architects
	3．Team Edition for Software Developers／Team Edition for Software Testers

　

「Visual Studio Team Systemで開発プロジェクトはこう変わる」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）