連載：VSTSで開発プロジェクトはこう変わる 第2回 TFSによるTeam System運用の実際 日立システムアンドサービス　酒井 達明 2006/04/08
Page1 Page2 Page3 Page4

VSTSの導入モデル

　ここでは、VSTSを導入するために、どのようなプロジェクト・チームを編成すればよいのかについて考察する。

　前回で触れたとおり、VSTSはエンタープライズ向けの開発プロジェクトに適用されることが想定される。あるいは、ISVなどでパッケージ製品を開発するようなプロジェクトにも適用されるだろう。またあるいは、実際の導入前に評価用としてTFSを構成し、利用することも想定される。こうした開発の現場にどのようにVSTSを適用すべきかを考えていこう。

■プロジェクトの規模と内容

　まず、最初に考慮すべき点は「VSTSをどのように配置するか？」ということである。前述したとおり、TFSをはじめとしたVSTSは論理3階層モデルを構成している。そのため、開発プロジェクトの規模に応じた展開が実現可能になっている。

　例えば、小規模な開発であれば、サーバ1台にすべてを配置し、小まめにバックアップを取る運用をすれば、十分利用できる。一方、開発要員が数百人というプロジェクトになると、データベースのバックアップだけでなくデータベース・サーバの多重化や、場合によってはロード・バランスを考慮しなければならないケースが想定される。

　このように、TFS導入時にはプロジェクト規模を考慮して、事前に配置計画を立てることが必要となる。

　TFSの展開スタイルには以下の3通りが考えられる。

【ケース1】
クライアント〜アプリケーション層〜データ層すべてを単一マシンに配置

　このケースは、主に評価用やデモンストレーション環境での利用を想定している。従って、実際の開発プロジェクトに適用するようなケースでは推奨できない構成である。

【ケース2】
アプリケーション層およびデータ層を単一マシンに配置
（シングル・サーバ構成）

　このケースは2〜100人程度の中・小規模開発に適用されるケースである。

　このシングル・サーバ構成では、Active Directoryの構成は必須ではないが、プロジェクト・チームの規模が20人程度以上の規模になることが予想される場合には、Active Directoryの導入を検討する方がよいだろう。

　なお、TFSにはパッケージとして提供される製品以外に、MSDN Premiumサブスクリプションにて「Team Foundation Server Workgroup Edition」が提供される予定になっている。これは5人以内の開発チームに適用することが可能なエディションである。よって、5人以下のチームであれば、コスト的にもこのTFS Workgroup Editionを適用するケースが有効である。

　プロジェクト・チームの規模が100人に近く、サーバへのアクセスが頻繁に発生することが予想されるような場合には、次に紹介するデュアル・サーバ構成を検討することも必要となってくる。

【ケース3】
アプリケーション層、データ層を別マシンに配置
（デュアル･サーバ構成）

　このケースはプロジェクト・チームの規模が100〜2000人という大規模開発に適用されるべきケースである。アプリケーション層とデータ層を分割することで、サーバの負荷を低減させるだけでなく、データベース・サーバの多重化などのアプローチも取れ、高信頼化させることが可能になる。

　このケースの場合、Active Directoryの導入は必須となる。加えて、ある程度以上（筆者の経験則では200人程度以上）の規模になるようであれば、ビルド専用のサーバを設置することで、ビルド時のサーバ負荷を分散させることが期待できる。

　また、複数の物理的に離れた拠点に開発メンバーが点在するような場合ならば、Team Foundation Proxyを導入することも検討しなければならない。

VSTS導入のモデル

プロジェクトの規模に応じて、物理的な配置を決定する。

　このように、TFSはプロジェクトの規模に応じてさまざまな展開形態を採用することが可能である。従って、10人程度のプロジェクトへの適用時にわざわざActive Directory環境を構築したり、データベース・サーバを別マシンに配置したりするような必要はないため、比較的小規模なプロジェクトへも適用しやすい。

　一方、大規模な開発プロジェクトでは、専任の開発プラットフォーム管理者を配置することが可能なケースも多いため、成果物を確実かつ安全に管理するための環境を構築するためのアプローチを取るべきである。

■プロジェクトのチーム編成

　これまでに紹介したとおり、VSTSにはソフトウェア開発現場におけるさまざまな役割を担うメンバーをサポートするための機能が提供されている。

　ここでは、VSTSを効率的に活用するためにはどのようなチーム編成にすべきかを紹介しよう。チーム編成については、後述する開発プロセスと関連する部分があるので、プロセスに特化した部分に関しては、ここでは割愛させていただく。

　従来から見受けられるウォーター・フォール型開発の現場では、チームを階層型で編成しがちであった。このチーム・モデルの場合、プロジェクト規模によっては階層が深くなったり、サブ・システムを担当するサブ・リーダーの数が増えたりする傾向がある。

ウォーター・フォール型プロセスで見られるチーム編成

プロジェクトの規模が大きくなればなるほど、階層が深くなりがちである。そして、階層上位のメンバーほど、複数の役割を兼任しなければならなくなるという問題がある。

　そのため、プロジェクト内部で共有されるべき情報が正しくかつ確実に伝達されないという弊害が生じる。特に、サブ・システム間に横断する情報を共有しづらいモデルになっているため、システム稼働直前になってリスクが表面化するような事態に陥るケースも想定される。

　また、階層構造の特性上、システム開発がトップダウン的になりがちである。これが原因で、開発者レベルで発見された問題を上位に報告しづらい雰囲気があり、問題を隠ぺいしてしまうような状況も作り出しかねないのである。

　さらに、このチーム編成のウイーク・ポイントとして、階層の上位になればなるほど、メンバーの役割があいまいになるということが挙げられる。上の図で示した階層構造では、最上位にプロジェクト・マネージャーが配置されているが、このメンバーは同時にシステム仕様の取りまとめや、顧客との折衝などといった役割を併せ持つことが多い。

　また、サブ・システムごとに配置されるサブ・リーダーは、サブ・システムの仕様の取りまとめだけでなく、サブ・システム内のプロジェクト管理も同時にこなさなければならないのである。

　こうした状況では、本来遂行すべき役割があいまいになり、最終的にはどっちつかずの状態に陥るのである。そして、それを補おうとすることで残業時間の山を築き上げるという最悪のシナリオへ突入するのである。

■VSTSが想定しているチーム・モデル

　一方、VSTSが想定しているチーム・モデルを考えてみよう。VSTSは基本的にMSFのチーム・モデル*を想定しているため、「説明責任（役割分担）を明確化し、実行責任を共有する」というMSFチーム・モデルの原則がVSTSにも受け継がれているように見受けられる。

※ MSFのチーム・モデルについては、「マイクロソフトが提供する開発指針「MSF」とは何か？」を参照。ただし、この記事で紹介しているMSFはバージョン3.0の仕様であることに注意すること。VSTSが対応しているMSFは4.0である。

　前回、VSTSが支援するさまざまなロール（役割）について触れたが、これらのロールをMSFチーム・モデルに当てはめてみると以下のようになる。

VSTSを活用するためのチーム編成

MSF 4.0で定義されているチーム・モデル。各ロール間には上下関係がない点がポイントである。

　このチーム・モデルにおいて、各ロールが担当する責任範囲を以下の表にまとめた。

ロール 担当する範囲 アーキテクト ソフトウェアのアーキテクチャを定義し、ソフトウェアの仕様や制約事項の決定に責任を持つ ビジネス・アナリスト ビジネス要件を理解し、シナリオおよびサービス品質要件として明確化することに責任を持つ プロジェクト・マネージャー プロジェクトのスケジュール、コスト、リスク、品質を管理し、スケジュールどおりに開発プロジェクトを進行させることに責任を持つ 開発者 コードを開発し、開発したコードが定義された仕様を満たし、かつ品質を確保することに責任を持つ テスター ソフトウェアのテストを担当し、ソフトウェアの機能要件および非機能要件を満たすことを検証することに責任を持つ リリース・マネージャー 開発されたソフトウェアのリリース計画や実際のリリースに関する責任を持つ

MSF 4.0チーム・モデルにおける各ロールの責任範囲

　このチーム・モデルはMSF 4.0で定義しているチーム・モデルである。MSF 3.0以前と比べ若干変更されているものの、担うべき役割が明確に分担され、共通のゴールに対して各自の実行責任を果たすという点では共通している。このモデルで重要な点は、ロール間に上下関係がないことである。

　上下関係がないので、特定のロールの意向を一方的に押し付けられることがない。また、プロジェクト進行中に問題が発生した場合には、問題事象を共有しやすいというメリットがある。

　実際には、開発者やテスターは複数のメンバーで構成されることが多くあるため、厳密にはこのモデルにプロジェクトの体制が1対1でマッピングされることはない。しかし、このようなモデルを採用することで、各チーム・メンバーの役割が明確化されるだけでなく、情報もスムーズに伝達されるという効果を期待できる。

　大規模な開発プロジェクトでは、システムの中核的な役割の開発に責務を負うコア・チームと、分割されたアプリケーション・ブロック（サブ・システム）を開発するサブ・チームに役割を分けるケースも考えられる。

大規模開発のチーム編成のアイデア

このケースでも、コア・チームとサブ・チームの関係は対等である必要がある。

　念を押しておくが、このチーム・モデルは唯一絶対の解ではない。例えば、アーキテクトおよびビジネス・アナリストはコア・チームに存在すればよいし、規模によってはリリース・マネージャーをほかのロール・メンバーが兼任してもよいのである。

　また、ネットワーク設計やデータベース設計のスペシャリストがアーキテクトとして加わるケースもあり得る。

　このように、プロジェクトの規模や内容によって、プロジェクトのチーム編成を適宜テーラリングする（適切にカスタマイズする）ことが肝心である。

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

　

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

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