3.1.2 サーバー環境Team Foundation Server
Team Foundation Serverは、マイクロソフト社内のバグ追跡システムであるProduct Studio*6を原型にして作られた、チームアプリケーション開発のためのサーバーシステムである。ざっくり言えば、以下の5つの機能を持つ。
- ソースコード管理システム（変更管理システム）
- 自動ビルドシステム
- ワークアイテムトラッキング（作業項目トラッキング、WIT（Work Item Tracking））
- TFSデータウェアハウスとレポーティング機能
- チームサイト機能
しかしこのような切り口の説明だと、TFSがなぜ開発プロセス全体をカバーする製品なのかが今ひとつはっきりしないだろう。そこで、別の切り口でTFSという製品を解説してみよう。TFSという製品を理解する上でのキーポイントは、以下の2点である。
- TFS はリソース（資産）とタスク（作業）を総合的に管理するシステムである。
- TFS は開発方法論による「色付け」を持たない。
A. TFS上で管理できるもの
一般論として、開発作業において特に管理しなければならないものは、リソース（資産）とタスク（作業）の2種類に大別できる*7（図 3-3）。これらを総合的に管理するために、TFSは複数のストレージを利用する。例えば、ソースコードについてはTFSソースコード管理システムによって管理し、ビルドについてはTFSビルドシステムによって管理する。またバグの修正作業情報やプログラミング作業情報などについては、ワークアイテムトラッキング機能によって管理する*8、といった具合になっている。さらにこれらを総合的にデータ分析したり確認したりできるように、TFSデータウェアハウスとレポーティング機能、そしてチームサイト機能が備わっている。
 |
| 図 3-3 開発プロセスにおいて管理しなければならない主なリソースとタスク |
|
*7 リソースとタスクは混同しがちな概念なので、はっきり区別するようにしていただきたい。例えば、「個別業務要件定義書」（＝Wordファイル）はリソース（資産）だが、「個別業務要件定義書を作成する」というのはタスク（作業）である。同様に、「ソースコード」はリソース（資産）だが、「ソースコードを開発する」というのはタスク（作業）になる。ワークアイテムトラッキング機能で管理をするのは、後者のタスク（作業）のみである。 |
|
*8 このワークアイテムトラッキング機能について以下に補足しておく。もともとTFSの原型となったProduct Studioは、バグ追跡データベースとして障害情報を登録・管理する機能に限定されたシステムであった。しかし、バグを修正するという作業は、テスト担当者やプロジェクトリーダー、開発者たちの間で情報を共有しつつ、タスクをキャッチボールのようにやり取りしながら進めていくものである（例：テスト担当者がバグを発見する→プロジェクトリーダーが確認し、開発者に修正作業を依頼する→開発者が修正し終わったらテスト担当者に差し戻す→テスト担当者が追試してバグをクローズする）。この「タスクを互いにキャッチボールしながら作業を進めていく」という考え方は、実はバグの修正に限った話ではなく、チーム内で行われる開発作業のタスクすべてに当てはまるものである。このため、Product StudioからTFSが開発される際に、バグ追跡データベースに限定して機能を実装するのではなく、「タスクを担当者間でキャッチボールのようにやり取りする」ための汎用的な機能を実装することとなった。これが「作業項目トラッキング（ワークアイテムトラッキング）」機能である。このため、TFSをバグ追跡データベースとして利用するためには、（後述するプロセステンプレート機能を利用して）作業項目の1つの種類として「バグ修正」というタスクを定義（登録）する必要がある。これにより、TFSの作業項目トラッキングシステムは、バグ追跡データベースとして機能するようになるわけである。 |
B. TFSと開発方法論の関係
さて、図 3-3に示したリソースやタスクのうち、「ソースコード」や「ビルドにより作成されたバイナリファイル」といったものについては、どのような開発方法論でも、管理すべきものや管理する方法についてそう大きな差はないだろう。しかし、業務設計書や方式設計書、あるいはチーム開発で行われるタスク（作業）については、開発方法論によって大きく変わる部分である。実際、代表的な開発方法論（MSF、RUP、FDD、Scrumなど*9）だけ見ても、開発すべきドキュメント、標準的な作業タスクはかなり異なる。
|
*9 それぞれMicrosoft Solutions Framework、Rational Unified Process、Feature Driven Development。 |
このような状況に対応できるようにするため、TFS本体に組み込みで用意されているのは、以下のような「極めて汎用的・標準的なリソース管理システム」に限定されている。
- ソースコード管理
- ビルドにより作成されたバイナリファイル*10
- テスト結果データ
|
*10 ただしビルドプロセスそのものはアプリケーションにより大きく異なるため、自在にカスタマイズできるようになっている。 |
逆に、これら以外のリソースや作業タスクの種類については、比較的自由にカスタマイズを加えることができるようになっている。例えば、汎用的なドキュメントレポジトリとしてはSharePointのドキュメント管理システムが提供されており、また汎用的なタスクのレポジトリとしてはワークアイテムトラッキングシステムが提供されている。そして、開発方法論に対応するプロセステンプレートをインストールすると、その開発方法論固有の標準ドキュメントテンプレートや作業タスク種別がTFSに格納され、TFSを「色付けして」使うことができるようになっている。
既定では、TFSにはMSF（Microsoft Solutions Framework）に基づく以下の2つのプロセステンプレートが標準添付されている。
- MSF for Agile Software Development v4
- 中間ドキュメントがあまり要求されない短期プロジェクト向けアジャイル開発プロセステンプレート
- MSF for CMMI Process Improvement v4
- 広範囲の品質保証やプロセス改善が求められる場合にも適用可能な長期プロジェクト向け開発プロセステンプレート
これらはいずれもマイクロソフト社内やコンサルティングサービス部門などにおける開発のベストプラクティスを反映するような形で作られたプロセステンプレートである。しかし、日本のシステムインテグレーションの実情には必ずしもそぐわないところもあるため、そのまま適用すべきか否かについては個別に検討が必要である。米国ではすでに様々なプロセステンプレートが実装されているため*11、必要であれば入手して利用する手も考えられるだろう*12。
|
*12 なお独自のプロセステンプレートを作成しようという場合には、そもそも自らの開発方法論が十分に「固まったものであるか否か」を考えた上で行うようにしていただきたい。昨今、オフショア開発などにおいてVSTSやTFSを利用した開発工程管理に期待を馳せる方が非常に多いが、VSTSやTFSのプロセステンプレートを自作して開発工程管理をするためには、その開発方法論における作業タスクがきちんと「定型化」「標準化」されていることが欠かせない。しかし実際の開発現場では往々にして臨機応変に対応しながら作業を進めていることが多く、このような状況で無理にプロセステンプレートを適用しようとすると、それがかえって作業の足かせになるリスクが生じる。 |
Insider.NET 記事ランキング
本日
月間
