チーム開発とVisual Studio 2005 Team Foundation Server

はじめに

第2回ではVisual Studio 2005 Team Edition for Software Architects（以下VSTE for SA）、第3回ではVisual Studio 2005 Team Edition for Software Developers（以下VSTE for SD）、Visual Studio 2005 Team Edition for Software Testers（以下VSTE for ST）のそれぞれについて、開発ライフサイクルとの対応という観点で解説してきました。

これらの3製品は、アーキテクト（システム基盤アーキテクト／アプリケーションアーキテクト）、開発者、テスト担当者（第三者検証担当者）というロールメンバーをターゲットとしたものです。

Team SystemによりVisual Studioのターゲットは、"開発だけ"から"設計・開発・テスト"というプロセスまでをカバーするようになりました。しかしながら実際のプロジェクトの運営を考えるとそれだけでは不十分です。

そこでVisual Studio 2005 Team Foundation Server（以下VS TFS）が重要になってきます。最終回の今回はチーム開発とVS TFSという観点で解説していきます。

 

チーム開発の難しさ

皆さんのチーム開発はうまくいってますでしょうか。なかなか一筋縄にはいかないという印象があるのではないでしょうか。

その理由には2点あると思います。

 

万能な開発ライフサイクルは存在しない

1点目は、どんなプロジェクトにも万能な開発ライフサイクルは存在しないということがあげられます。

非常に大規模なプロジェクトでは、タスクのボリュームが大きく、全体の状況をグリップするために細かなチェックポイントやプロセスを必要とします。線密だからといって、大規模向けに作成した開発ライフサイクルを小規模なプロジェクトに適用すると、かえって効率が悪くなってしまいます。

また開発者の地理的な分散による影響を受けます。1ヶ所に全員が集まって開発する場合とオフショア開発を行う場合とでは役割分担や責任の柔軟性が変わってきます。プロジェクトに参画するメンバーのスキルによっても変わってくるでしょう。

さらにプロジェクトを取り巻く環境にも影響を受けます。ユーザ企業の社内SEによって社内のメンバーが使用するアプリケーションを作成する場合と、弊社のようなSIerが受託開発を行う場合とでは、評価する観点が異なっているからです。

前者では、納期やコストよりも実際にシステムを使うユーザの要求を組み込むことを重要視するでしょうし、後者では納期とコストのバランスを取る必要があります（もちろんユーザの要求を重視した上で、ほかの要素との兼ね合いを考え最大限の努力をいたします）。実際のプロジェクトの遂行にはそうした要因を考慮し、開発ライフサイクルの選択・調整が必要となってきます。

 

開発ライフサイクルを回すのは人間

もう1点は、結局のところ開発ライフサイクルを回すのは人間だということです。

複雑なアプリケーションになればなるほど様々な専門性を持ったチームを必要とします。個々のチームが最大限に効果を発揮するためにはチーム内でのコミュニケーションが重要ですし、プロジェクトとしての成功のためには、それに加えてこれらチーム間のコミュニケーションが鍵となります。

チーム開発は、完璧な開発ライフサイクルを用意してチームメンバーを型にはめてしまえばうまくいくというものではありません。結局、人間のコミュニケーションが重要な要因となります。

こうした難しさを持つチーム開発へのマイクロソフトの回答がVS TFSです。

ワークアイテムを用いて開発ライフサイクルを表現し、プロジェクトに関する成果物と報告を一元管理できます。関係者があーだこーだと議論するような機能も用意されています。ただし、すべてのプロジェクトに万能な開発ライフサイクルは存在しないことと、カスタマイズを前提としている点がありますので、何も考えずに導入して効果がでるといった類のものでもありませんので、注意が必要です。