プロジェクトの工程とVSTSの位置づけ
開発プロジェクトでは多少の名称の差こそあれ、作業工程は一般的に図3のようになるかと思います。
これに対し、VSTSの各製品が利用されるシーンを大雑把に現すと図4のようになると考えられます。
VSTAは要求分析でシステム全体像を描くタイミングから、外部設計でシステムの全体構成を決定するまで利用できます。VSTDは、主にプログラム設計の最中に単体テストを作成するタイミングから単体テストの完了まで利用できます。VSTTは、VSTDで作成した単体テストを受け継ぎ、テスト工程で機能テスト、負荷テストを行うタイミング、パッケージ製品の場合には、その後のエンハンスで利用できます。VSDPは内部設計でデータベーススキーマが確定した段階から利用していくことができます。最後に、TFSはプロジェクトの開始からシステムが稼動している限り、プロジェクトを管理する目的で随時利用していくことができます。
VSTSの利用シーン
今まで解説を行ってきたVSTS製品群の各機能や、プロジェクトの工程とVSTS製品群の位置づけをもとに、VSTSを利用したプロジェクトの進め方を考えてみます。例として、非常にシンプルなWebアプリケーションを開発する例を考えます。まず、全体を図示すると図5のように利用できると思います。
まずは、VSTAの機能を利用して、アプリケーションの全体構造やハードウェアへの配置などを設計します（詳細は本連載の第2回にて解説しますのでここではイメージだけ汲み取ってください）。
アプリケーションデザイナなどで作成した成果物はVisual Studioのソリューションとその項目として出来上がるので、これをTFSのソースコード管理下で管理できます。また、アプリケーションデザイナのモデルを基にVisual Studioプロジェクトの雛形を作成し、実際に開発するプロジェクトを生成することもできます。実際の開発では、内部設計や共通化などにより新たに追加されるプロジェクトをソリューションに組み込んだ上で、VSTDによるソースコード開発に取り掛かります。
次にVSTDの機能を利用して、ソースコード開発を行い、コード分析や単体テストなどを通してソースコードの品質を高めることができます（詳細は本連載の第3回にて解説します）。
ソースコードをTFSのソースコード管理下におくことはもちろんのこと、単体テストによって発生したバグは、TFSの作業項目の1つとして、バグの修正まで追跡管理することも可能です。ソースコード開発があらかた終了したら、テスト工程に移ります。ここで、TFSに用意されたチームビルド機能を利用することで、TFSのソースコード管理と連携して、最新のビルドを構築できます（詳細は本連載の第6回にて解説します）。このビルドを利用することで常に最新のソースコードに基づいた、VSTTによるテストが可能となります。
最後にVSTTのWebテスト、負荷テストによるテストを行い（もちろん目視によるテストも必要です）、出荷に耐えられると判断されるという流れになります（テスト機能の詳細は本連載の第4回で解説します）。
VSTTのWebテスト、負荷テストのテストファイルや、実行結果もTFSにて管理することができ、うまく使うことができれば、どのビルドに対して行われたテストがどのような結果になったのか、またその結果を招くことになったソースコードやバグの一覧はなんなのか、といった内容をいつでも確認できるように使用することも可能です。
まとめ
今回は、VSTSの全体像や、用意されている機能、実際のプロジェクトの工程での使いどころについて、ざっと解説しました。すべての機能をあまねく使用することができれば、プロジェクトの遂行にとって非常に強力なツールとなる可能性を秘めていることはご理解いただけたのではないかと思います。しかし、これらのすべてをいきなり導入していくことは、教育コストの増大や作業の混乱といったリスクにも繋がると考えています。今後の本連載では、それぞれの製品の機能や使い方を説明すると共に、使いどころについても適宜触れていきます。それらを通じて、リスクを抑えて、必要な機能を導入していく足掛かりにしてもらいたいと思います。
