.NETエンタープライズ Webアプリケーション開発技術大全 大規模プロジェクトにおける開発環境構築術 マイクロソフト コンサルティング本部 赤間 信幸 2004/09/30

Page1 Page2 Page3 Page4

5.2 各開発チームによる分散アプリケーション開発までの流れ

　まず、コアチームによる業務共通コンポーネントの開発から、各開発チームによる分散アプリケーション開発までの流れについて整理する。この作業に必要な環境と、作業フローの概略を図5-3に示す。

図5-3 各開発チームによる分散アプリケーション開発までの作業フロー

（クリックすると拡大します）

　この作業フローの要点を以下に整理する。

5.2.1 コアチームによるSDKの開発

A. 概要とその役割

　コアチームの主なミッションは、大規模開発に備えた下準備を行うことである。具体的には、アプリケーションアーキテクトと上級デベロッパーが協力して設計標準と共通コンポーネントの開発を行い、その成果物をSDK※1といった形で取りまとめ、各開発チームへと配布する。

※1 Software Development Kitの略。ソフトウェアやアプリケーションを開発する際に利用する一連のツールセットのこと。

　無論、こうしたSDKは作りっぱなしでは意味がない。設計や実装に関する情報を適切に各開発チームに伝えると共に、実際の開発フェーズでは設計や実装に関するQ&A対応やコンサルティングなどを実施することになる。

B. 具体的な作業内容や成果物

　開発規模にも依存するが、通常、SDKには以下のようなものが含まれる。

・ 開発標準定義書
	・ アプリケーションアーキテクチャの解説、設計ガイドライン、共通コンポーネントやフレームワークの利用ガイドライン、実装ガイドライン、コーディングドキュメンテーションガイドラインなどが含まれる
	・ また、チーム開発環境構築のためのガイドラインや、各開発チームから品質チェックチームへの納品物などについても規定される
・ 業務共通コンポーネント
	・ .NET Framework単体ではカバーされない各種の業務部品や共通コンポーネント、例えば特殊なWebコントロールや業務カレンダーコンポーネント、あるいはEMAB※2などが提供される
	・ これらのコンポーネントの妥当性や品質については、大規模開発に先立って行われるプロトタイプ開発作業の中で検証されることになる
・ 業務アプリケーション開発用テンプレートやサンプルコード
	・ プロトタイプ開発の成果をVisual Studio .NETのプロジェクトテンプレートやサンプルコードなどの形でまとめ、SDKの中に含めておくとよい
	・ こうしたものが充実していると、各開発チームは作業を進めやすくなる

　

※2 patterns & practicesが提供する例外処理用のアプリケーション部品。正式名称はException ManagementApplication Blockである（http://msdn.microsoft.com/library/en-us/dnbda/html/emab-rm.asp）。

　これ以外にも、データベースをセットアップするために必要なインストールスクリプトなどが提供される※3。

※3 なお本書では深入りを避けているが、ここで述べたデータベースのスキーマやテストデータの管理方法については、業務共通コンポーネントの配布方法と同様に、入念な検討を行っておく必要がある。特にDOA（Data OrientedApproach）に基づく開発を進める場合には、どのチームがどの範囲のスキーマ管理責任を担うのかを定めると共に、スキーマ変更が行われた場合の他チーム、他開発用PCへの反映方法について検討しておかなければならない。この点に関しては、現在でもスマートかつ標準的なソリューションが存在しておらず、ケースバイケースで対処する必要がある。

C. 特に注意すべき点

　コアチームにより作成されたSDKや開発標準、設計ガイドライン類は、「それに従えば必然的に品質の高いアプリケーションが作成できる」ものになっていることが望ましい。そのためにも、必ずプロトタイプでの検証を行い、性能面での問題がないこと、特に高負荷環境でも問題なくアプリケーションが動作することを確認しなければならない。

　また分散チーム開発に先立って、コアチームにもきちんとチーム開発環境や自動ビルドシステムを導入しておくことを強く推奨する。自動ビルドシステムとは、夜間などに、自動的にコンパイルやバックアップ、最新版のファイルの公開といった一連の作業を行うシステムのことを言う。特に、実際の分散チーム開発が始まると、コアチームのメンバは各開発チームのフォローアップ作業に時間を取られ、業務共通コンポーネントのバグフィックスや機能追加にほとんど時間を費やせなくなることが多い。このため、自動ビルドシステムは本格的な分散開発がスタートする前に構築しておくことが望ましい。

　さらに、特に分散拠点での開発を行う場合には、コアチームは情報提供用のチームWebサイトを立てておくとよい。このチームWebサイトを通して、最新版の開発SDKの配布やFAQの整理などを行うと便利である。

5.2.2 各開発チームにおける業務アプリケーションの開発

A. 概要とその役割

　大規模システム開発では、アプリケーション全体を1つの巨大なチームで開発するのではなく、サブシステム単位、あるいは業務単位といった適当な単位で分割し、それらを各開発チームが並列開発することになる。

　よって、コアチームから提供される開発標準やSDKを活用して、割り当てられたサブシステムや業務を適切に開発することが、各開発チームのミッションとなる。

B. 具体的な作業内容や成果物

　各開発チームは主に以下のような作業を行う必要がある。

・ チームベースのアプリケーション開発
	・ 共通ライブラリ管理サーバ、ソースコード管理サーバ、共通データベースサーバ、ビルドサーバ、バックアップサーバなどを用意して、チーム開発を実施する
	・ また各種のグループウェアを利用して、チーム作業の促進を図ることが望ましい
・ 各種のテストの実施と、繰り返しテストのためのテストスクリプトやテストプログラムの開発
	・ 開発標準で定められた手法に基づき、機能テストや性能テスト、結合テストなどを実施する
	・ また、これらのテストスクリプトやテストプログラムは保存しておき、再実施しやすいようにしておくことが望ましい※4
・ バージョニングとパッケージング
	・ 設定されたリリース計画などに基づき、適切なバージョニングとパッケージングを行い、品質チェックチームへと引き渡す

　

※4 アプリケーションの機能拡張時や修正時はもちろんのこと、サービスパックやセキュリティアップデートを適用した際のデグレードテストを繰り返して行っていくためには、こうした「再実施が可能なテストスクリプトやテストプログラムの準備」が重要になる。コンポーネントの単体機能テストとしては、ユニットテストツールNUnit（http://www.nunit.org/）が、Webアプリケーションの機能テスト・性能テストとしてはApplication Center Test（ACT）が利用できる。

C. 特に注意すべき点

　大規模開発では、ソースコード共有やネットワーク構成に関してさまざまな制約が発生することが多い。例えば、協力会社に一部の開発を依頼するケースにおいてはネットワーク的に繋がっていないケースがほとんどであり、また仮に同一ネットワークであったとしても、全社共通コンポーネントのソースコードを各開発チームに公開したくないと考えるケースも多い。このため、コアチームによる業務共通コンポーネント開発と、各開発チームの開発との間をどの程度「疎」とするのかについての検討が欠かせない。

　また非機能的な品質の確保については、開発中にも十分な注意を払う必要がある。セキュリティやスケーラビリティ、パフォーマンスの確保、あるいは高負荷環境下でも問題なく動作するかどうかなどは、アプリケーション開発後のチューニングでは根本解決できない問題だからである。以上が、コアチームによる業務共通コンポーネント開発から、各開発チームによる分散アプリケーション開発までの流れである。引き続き、開発された各アプリケーションを集約し、リリースしていく流れについて解説する。

INDEX
	.NETエンタープライズWebアプリケーション 開発技術大全
	大規模プロジェクトにおける開発環境構築術
	1．大規模開発における全体の作業の流れ
	2．各開発チームによる分散アプリケーション開発までの流れ
	3．分散開発されたアプリケーションを集約し、リリースするまでの流れ
	4．開発プロセスやその環境構築に利用されるマイクロソフトの製品群

「.NETエンタープライズWebアプリケーション開発技術大全」

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