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

Page1 Page2 Page3 Page4

5.3 分散開発されたアプリケーションを集約し、リリースするまでの流れ

　図5-4が、この作業に必要な環境と作業フローの概略図である。この作業フローの要点を以下に整理する※5。

図5-4 分散開発されたアプリケーションを集約し、リリースするまでの作業フロー

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

※5 なお図5-4において、ステージング環境と運用環境には「全く同一構成のハードウェア」を用意しておくべきである。予算の都合によって、運用環境に比べてステージング環境のスペックや構成が削られている場合があるが、これではステージング環境としての価値が半減してしまう。例えば、DBサーバがクラスタリングされているか否かで、サービスパックやセキュリティアップデートの適用順序は異なる。またドライバ同士の相性問題が発生した場合などに、ステージング環境での再現テストが実施できなくなり、本番系でのライブテストが必要となってしまう。このようなことから考えても、ステージング環境と運用環境は同一のハードウェア構成を持たせておく必要がある。

5.3.1 品質チェックチーム

A. 概要とその役割

　品質チェックチームの役割は、各開発チームにより開発されたアプリケーションを収集し、クォリティコントロールを行うことにある。

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

　本シリーズでは、システムの各種の非機能要件、例えば性能やスケーラビリティ、セキュリティ要件などに対して、アプリケーションの内部設計や実装が極めて大きな影響を及ぼすことを繰り返し述べてきた。

　そうした優れた設計と実装を守るものがアーキテクチャでありフレームワークであるが、残念ながら、そのような「開発標準」に準拠した設計・実装になっているかどうかを自動的に確認するためのチェックツールは今のところ存在しない※6。このため現状では、最終的な歯止めは目視に頼らざるを得ない。

※6 ソースコードが、各種のコーディング標準（例えば命名規則など）や最低限のデザインガイドラインを守っているか否かに関しては、GotDotNetで提供されているFxCopなどのツールによりある程度まで確認することができる　（http://www.gotdotnet.com/team/fxcop/）。しかし、アーキテクチャとして定めた設計標準を適切に遵守しているか否かまでは残念ながら確認できない。

　原則論から言えば、こうした開発標準を遵守しているかどうか、非機能要件を満たしているかどうかは、各開発チーム内のリリース責任者により確認されていなければならない。しかし、念のためにダブルチェックをかけ、コアチームの定めた開発標準や各種の非機能要件、例えば性能やセキュリティ、保守性要件などを正しく満たしているか否かを最終チェックするのが、ここに示す品質チェックチームの役割となる。

　現実的には全ソースコードの検査は困難であろうから、リリースされた内容物の確認や抜き取り検査、テストスクリプトやテストプログラムの動作確認、あるいは運用環境と同スペックのハードウェア上での応答時間やスループットの測定などを限定的に行うことになる。

C. 特に注意すべき点

　品質チェックチームを用意する上で特に注意すべき点は、他チームとの役割分担である。この役割分担をあらかじめ明確化しておかないと、何らかの問題があった際や作業負荷が増えてきた場合に、責任のなすり合いという最悪の事態を引き起こしかねないからである。

　そもそもこの品質チェックチームを配置しようとする背景には、運用チームのメンバだけではアプリケーションの品質に関するレビューを行うことが困難であるという事実がある。運用チームはシステム運用のスペシャリストであり、アプリケーション開発のスペシャリストではなく、アプリケーションの設計・実装スキルに長けたチームではない。このため、各開発チームから納品されたアプリケーションの設計品質などを運用チームが確認することは非常に困難である。そこで、最終的な運用インフラに載せる前に、アプリケーションの設計的な観点から品質の最終確認を行う、というのがこのチームを配置する目的である。

　しかし半面、品質チェックチームを配置すると、テストや品質に対する最終責任の所在が不明瞭になりがちであり、また作業内容も運用チームや各開発チームと重なる部分が多い。また、このチームは実質的に各開発チームと運用チームとの間をつなぐ役割を担うため、かなりの作業負荷がかかることになる。このため、タスク設計上は開発チームと運用チームだけですべての作業（品質確認や性能テスト、リリース計画など）を終えられるように役割分担を定めておき、さらに品質チェックチームのダブルチェックによってリスクを軽減するのが望ましい。

5.3.2 運用チーム

A. 概要とその役割

　運用チームの基本的な役割は、もちろん開発されたアプリケーションとインフラを安定的に稼働させることである。しかし、システム運用は、今日ではリアクティブ（受動的）な対応から、プロアクティブ（能動的）な対応が求められる分野へと変貌しつつある。

　開発者の中には、運用に馴染みが薄いという方もいるかと思われるが、システムの全体コストに対する運用コストの比率は大きい。運用管理担当者の人材確保、拡張時のケア、トラブルへの対処といったコストがIT投資全体の半分以上を占めるという企業も多い。また効率性や合理性を重視する企業ですら、運用に関しては、それまでの慣習やシステム担当者の勘、人海戦術に頼っているケースが数多く見られる。

　最近ではこうした状況を打破し、ITサービス管理という考え方に基づいた高度な運用サービスを提供することがシステム運用に求められるようになってきている。

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

　ITサービス管理の業界標準としては、ITIL（IT Infrastructure Library）と呼ばれるガイドラインが有名である。これは英国の政府機関により開発されたガイドラインで、ITサービス管理の理想像を示したものになっている。大手SIerやコンサルティング企業はこのITILに準拠しつつ、さらに発展・拡張させた各種の運用ガイドラインを開発しており、マイクロソフトの場合にはMOF（Microsoft Operations Framework）と呼ばれる運用フレームワークを提供している。

　例えばこのMOFでは、システム運用に必要な管理プロセスとして、以下のようなものを挙げている※7。

• 可用性管理
• キャパシティ管理
• 構成管理
• ネットワーク管理
• 問題管理
• 変更管理
• リリース管理
• セキュリティ管理
• サービスデスク（ヘルプデスク）

※7 より詳細な情報は、以下のアドレスを参照のこと。「TechNetのMicrosoft Operations Framework 〜 ミッションクリティカルなシステムに対する卓越した運用性」（http://www.microsoft.com/japan/technet/itsolutions/tandp/opex/default.asp）。

　例えば、アプリケーションをスムーズにリリースし続けられるようにするためには、変更管理やリリース管理といったプロセスが必要になる。このことからも分かるように、場当たり的な作業を避け、各種の管理プロセスを適切に設計し、実践していくことが、運用チームに求められるわけである。

C. 特に注意すべき点

　本シリーズはアプリケーション開発にフォーカスしているため、これ以上の深入りは避けるが、上記の内容からも、システム運用は非常に奥深い分野であることが伺えるだろう。アプリケーションアーキテクトは、スムーズな運用作業を妨げないアプリケーションリリースの仕組みを検討する必要がある。

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

　

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

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