連載：Visual Studio Team Systemで開発プロジェクトはこう変わる 第2回 Team Foundation ServerによるTeam System運用の実際 日立システムアンドサービス　酒井 達明 Microsoft MVP for Solutions Architect（Jan 06 〜 Dec 06） 2006/04/08

Page1 Page2 Page3 Page4

　前回では、Visual Studio 2005 Team System（以下、VSTS）の概要と、VSTSに含まれるVisual Studioの3つのエディションについて解説した。

　今回はまず、VSTSを「チーム・システム」として利用するために不可欠な製品「Visual Studio 2005 Team Foundation Server」（以下、TFS）を紹介した後、VSTSに適したプロジェクト・チームの構成方法やVSTSにおける開発プロセスの活用、そして現場プロジェクトへのVSTSおよびTFSの導入／設定方法までを解説する。

システムとしてのVSTS

　マイクロソフトがVisual Studio 2005（以下、VS 2005）をリリースするに当たり、「Visual Studio Team System」と銘打ったことには大きな理由がある。過去にもMicrosoft Office 2003で「Office System」と銘打ったことがあるが、この場合にはOffice SharePoint Portal ServerやProject Serverといった、「System」を実現するためのサーバ製品がOffice製品本体とは別に提供された。

　同様にして、VSTSにおいても「System」を実現するためのサーバ製品としてTFSが提供される。実は、このTFSなくしてはTeam Systemを実現することができないといっても過言ではないほど、重要な位置付けの製品である。

　まずは以下にTFSのアーキテクチャを示しておく。

TFSのアーキテクチャ・モデル

TFSは論理3階層モデルのアーキテクチャを採用している。開発プロジェクトの規模に応じて物理配置を決定できる。

　TFSのメインのクライアントになるのはもちろんVSTSであるが、開発者以外のプロジェクト・メンバーはExcelやOffice Project、IEなどからもTFSにアクセスできる（詳細は後述）。

　なお、TFSの製品版は2006年の夏ごろ提供開始予定であり、本稿ではTFS Beta 3 Refresh版を用いて解説している。このため、製品版での内容とは異なる可能性があることをあらかじめご了承いただきたい。

■Visual Studio Team Foundation Serverで提供される機能

　TFSは、チーム開発に必要なプロジェクト管理やリポジトリの変更管理、そして品質の指標となるバグのトレースや残存作業の推移状況、バグの解決状況をレポートする機能や、チーム内のコラボレーション環境も併せて提供する。

　TFSではチーム開発の単位を「チーム・プロジェクト」として管理する。チーム・プロジェクトが新規作成されると、以下のプロジェクト要素が新たに作成される。

プロジェクト要素 内容 作業項目 （ワーク・アイテム） チーム・プロジェクトを遂行するために必要なさまざまな「活動」を管理する ドキュメント プロジェクトの概要やセキュリティ、開発、テスト、プロジェクト管理に関するドキュメントやそのほかの種類の共有ドキュメントを格納し、バージョン管理機能を提供する レポート TFSが管理するさまざまな情報を基に、プロジェクトの状況を可視化するためのレポートを提供する チーム・ビルド ソース・コードの自動ビルドやビルド時におけるコード分析やテストの機能を提供する ソース管理 チーム・プロジェクトで共有されるプロジェクトおよびソース・コード、リソースの変更管理機能を提供する

チーム・プロジェクトに含まれるプロジェクト要素

　新規にチーム・プロジェクトを作成する際には、チーム開発で採用すべき開発プロセスをチーム・プロジェクトに割り当てる。この開発プロセスは「プロセス・テンプレート」というXML形式のドキュメントで定義されており、Beta 3 Refresh版で提供されているプロセス･テンプレートは、「MSF for Agile」および「MSF for CMMI」の2種類である*。

* MSF（Microsoft Solutions Framework）はマイクロソフトが提唱するプロジェクト遂行のためのフレームワークであり、ITソリューション提供のために必要となるプロセス、チーム編成、ベスト・プラクティス、ガイドラインなどから構成される。MSF for AgileおよびMSF for CMMIはMSF Ver 4.0に含まれるプロセス・ガイダンスであり、MSF for Agileはアジャイル開発向けの開発プロセスを提供し、MSF for CMMIはCMMI（Capability Maturity Model Integration） Lv.3の要件を満たし、Lv.4〜5へ容易に移行可能な開発プロセスを提供している。

　プロセス･テンプレートはユーザーがカスタマイズすることも可能であるため、既存のプロセス・テンプレートに独自の作業項目を追加したり、自社向けの新たなプロセス・テンプレートを作成したりすることが可能である。

　そのほか、［チーム］メニューがVSTSのIDEに追加される。このメニュー項目には、チーム開発環境で利用する、以下のサイトへのナビゲーションが含まれる。

利用可能になる機能 内容 プロジェクト・ポータルの表示 Windows SharePoint Serviceをベースに生成された、チーム・メンバーのコラボレーションをサポートするWebサイトを表示する レポート・サイトの表示 チーム・プロジェクトが生成するレポートを取得するためのサイトを表示する

新規チーム・プロジェクト作成時にVSTSのIDEに追加される機能

　これらのサイトは、VSTSを持たないユーザーからも参照することが可能であるため、それを必要としないビジネス・マネージャーなどがプロジェクトの進ちょく状況を参照するといったことも可能になっている。

　また、プロジェクト・ポータルはWindows SharePoint Serviceがベースになっているため、開発者間の連絡やドキュメントの共有や変更管理なども可能である。

　さらには、プロジェクト・ポータルに存在するドキュメントは、VSTSクライアントで開かれるチーム・プロジェクトの［ドキュメント］フォルダ内に存在するドキュメントと同期しているため、VSTSクライアントが存在しない環境でも、プロジェクト・ポータルのWebサイトからのドキュメント参照やポストも可能になっている。このため、物理的に分散した場所に開発チームが点在していて、ネットワーク・セキュリティ上の制約によりVSTSがTFSに接続できないような場合でも、Webベースの情報共有が可能になる。

　以下では、TFSを利用するうえで欠かせない重要な概念となる「作業項目」、そしてTFSの特徴であるプロジェクト管理者向け機能について見ておく。

■作業項目

　作業項目（ワーク・アイテム）は読んで字のごとく、VSTSにおける作業（活動）の単位を表すものである。長期にわたり、英語版のベータ版を利用されていた方には、「ワーク・アイテム」の方がなじみ深いかもしれないが、日本語版では「作業項目」と訳されている。

　使用される作業項目の種類は適用する開発プロセスによって異なるが、標準で提供されているMSF for AgileおよびMSF for CMMIには以下の作業項目が存在する。

作業項目 定義される対象 管理される項目 MSF Agile MSF CMMI Task タスク 作業概要、作業ログ、担当者、ステータス、作業時間など ◎ ◎ Bug バグ 問題、調査ログ、ステータス、優先度、関連するテストなど ◎ ◎ Risk リスク リスクの概要、経過ログ、ステータス、深刻度など ◎ ◎ Scenario シナリオ （機能要件） ユーザー・シナリオの概要、調査ログ、ステータス、概算見積もりなど ◎ Quality of Service Requests サービス品質要求 （非機能要件） サービス品質要求の概要、調査ログ、品質の区分、概算見積もりなど ◎ Change Request 変更依頼 変更内容、分析結果、調査ログ、優先度、ステータスなど ◎ Issue 懸案事項 懸案内容、分析結果、影響度、アクション・プラン、ステータスなど ◎ Requirement 要求事項 要求内容、分析結果、優先度、ステータス、ユーザー受け入れテスト結果など ◎ Review レビュー結果 レビューの目的、議事録、コメント、参加者、ステータスなど ◎

MSF for AgileおよびMSF for CMMIに含まれる作業項目

　この中で頻繁に利用されることが想定される作業項目は、タスクとバグであろう。

　タスクは、プロジェクト・マネージャーが開発者に対して割り当てる実際の「作業」として利用される。例えば、プロジェクト・マネージャーがあるサービスを実現するコードの実装を開発者Aに依頼したい場合、［タスク］を発行して開発者に指示を出す。

　また、テスティング・エンジニアがバグを発見した場合には、バグ修正の指示を開発者Bに出すために、［バグ］を発行し、現象や調査に必要な情報を連絡するといった具合に作業項目は利用される。

チーム内における作業項目発行のモデル

作業の目的に応じて、それぞれの作業項目が発行される。

　開発者がTFSに接続しチーム・プロジェクトを参照する際には、自分に割り当てられている作業項目を検索することが可能である。これによって、自分が何をすべきかの「見える化」が可能になる。

担当する作業項目のクエリ結果

開発者がTFSに接続しチーム・プロジェクトを参照して自分に割り当てられている作業項目を検索できる。作業には優先順位を付与することが可能であり、「自分が何をすべきか」を的確に把握することができる。

　混乱したプロジェクトに遭遇すると、「自分が何をしてよいのか分からない」という開発者を時々目にする。これは、作業項目が「見える化」できていない典型例であり、こうした現場では、作業が適切に割り当てられていないだけでなく、作業の漏れやムラが生じがちになる。TFSを導入することで、こうした事態を回避することも期待できる。

　作業項目には、当該作業が管理する各項目だけでなく、その作業に関連する作業や変更セット、変更管理されている特定のファイル（ソース・コードなど）、その作業に対するテスト結果、関連するURLやファイル・パスなどを関連付けることが可能である。

　例えば、バグを発見したテスティング・エンジニアは、新規作成した［バグ］作業項目に、問題の内容だけでなく、そのバグが存在しているプロジェクト・ファイルやソース・ファイルを関連付けることができる。これにより開発者は迅速にバグ修正作業へ取り掛かることが可能になる。

　また、仕様どおりの動きをしていないケースのバグでは、仕様書のファイル・パスを関連付けることにより、開発者が迅速に仕様書へアクセスすることが可能になる。

■プロジェクト管理者向け機能

　TFS導入によって得ることのできるメリットの1つとして、プロジェクト管理者向け機能が提供されるという点が挙げられる。

　この機能は、TFSで管理されている作業項目の情報を基に、プロジェクトの進ちょく管理や品質管理に必要となる、さまざまな情報の取得や編集を実現するものである。例えば、各担当者が作業項目に入力した作業時間を集計することにより、その進ちょく状況を逐次把握できる*。

* ただし、これらの情報はデータウェアハウスの再構築のタイミングによって内容が変化するため、プロジェクトの状態を厳密な意味での「リアルタイム」に反映しているとはいい切れない。しかしながら、多くのプロジェクトの場合は1日ごとの状態が正しく把握できればよいケースが多いため、実際の利用には大きな影響があるわけではないだろう。

　VSTS（VS 2005）からプロジェクト管理機能を利用するには、チーム・エクスプローラをインストールする必要がある。これは、TFSのクライアント・モジュールに含まれている。

　あるいは、プロジェクト管理者は、作業項目の割り当てや新たな作業項目の追加、進ちょくの更新などの業務にOffice ProjectやExcelを利用することが可能である。つまり、プロジェクト管理用にわざわざVSTSを用意する必要がないのだ（ただし別途CALが必要となる）。

　多くのプロジェクト・マネージャーは従来Office ProjectあるいはExcelを利用していると想定される。そのため、使い慣れたツールを用いてチーム・プロジェクトを管理できるということは、マネージャー層の再教育が不要であるという点でアドバンテージといえよう。

Office Projectによるチーム・プロジェクトのガント・チャート

Visual Studioを持たないユーザーであっても、TFSのプロジェクト管理機能が利用できる。 　 Office Projectで編集した作業項目をTFSに反映させるには［発行］を実行する必要がある。

　また、TFSが出力するレポートを参照することで、現在アクティブ（未解決）なバグの件数や、そのフィックス状況、チーム・プロジェクトの作業スピード、残存作業の推移、品質指標などの統計情報を取得することが可能である。このように、進ちょく管理以外にプロジェクトの状態を「見える化」するための各種情報を提供する機能もTFSを導入することで利用可能になる。

　以上のように、TFSではプロジェクト・マネージャーを支援するさまざまな機能が提供されているが、当然ながらプロジェクトの状態を正確に把握するためには、各担当者が作業項目の作業時間や状態を正しく入力する必要がある。

　最終的には、プロジェクトの各担当者の協力なしでは生かせない機能であることは否めない。そのためには、TFSを始めとしたVSTSを活用するためのチーム編成が重要になる。これについて次に述べる。

INDEX
	Visual Studio Team Systemで開発プロジェクトはこう変わる
	第2回 Team Foundation ServerによるTeam System運用の実際
	1．システムとしてのVSTS
	2．VSTSの導入モデル
	3．VSTSにおける開発プロセス
	4．VSTSの構築と運用

　

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

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