業務用アプリケーションが「運用を意識して設計されている」のは，当たり前のことのように聞こえる。開発者がアプリケーションを実際に運用する人のことを考慮していれば，運用部門はアプリケーションのパフォーマンスやセキュリティ，ヘルプ・デスクといった問題に頭を悩ませる必要はなくなる。しかし，アプリケーションの多くはいまだに「運用のことを意識」しておらず，管理機能も内蔵していないのが実情だ。

　米Microsoftが提唱する「Dynamic Systems Initiative（DSI）」は，こううった状況を変えようとするための取り組みだ。同社は現在，システム管理製品群「System Center」に新しく追加される「Service Desk」（開発コード名）というツールを開発中だ。Service Deskを使うと，「Visual Studio 2005 Team System（VSTS）」に既に組み込まれている機能を利用することによって，運用部門のニーズを開発部門にフィードバックする統合ワークフローを実現できる。System Center Service DeskとDSIにおけるVisual Studio Team Systemの役割についてより詳しい情報を得るために，筆者はVisual Studio Team Systemグループのグループ・プロダクト・プランナであるSam Guckenheimer氏に話を聞いた。

運用部門と開発部門はどちらも孤立している

Service Deskは，ITのどのような問題を解決しようとしているのか？

　IT分野における大きな問題は，IT組織のいたる所で活動が孤立していることだ。これはIT業界の歴史が引き起こした問題でもある。例えばユーザーは，特定の機能に特化した高性能のツールを入手できるし，そのツールの機能を大まかになら推測できる。

　しかし，CIOやアプリケーション開発部門の責任者の多くは，ツールが細分化することの弊害をこうも語っている。「ツールの機能が推測できるだけでは意味がない。本当は，そのツールを使ってどの程度ビジネスに役立つアプリケーションを開発できるのか，われわれの能力がツールによってどの程度強化されるのか，経営者を救うことができるのか−−そういったことが計測できなければならないのだ」。

ITの活動が孤立しているというのは，アプリケーションのアーキテクトや開発者，テスター，プロジェクト・マネージャ，運用担当者のそれぞれが孤立しているということか？Visual Studio Team Systemやそのサーバー製品「Visual Studio 2005 Team Foundation Server」は，アプリケーション開発者側における孤立を解消する製品だったはずだ。

　われわれがVisual Studio Team Systemをリリースしたのは，2005年だった。そして2006年に，「Visual Studio Team Edition for Database Professionals（VSDB Pro）」を追加した。VSDB Proは，Service Packのレベルを超える最初の大型アップデートだった。VSDB Proは，アプリケーション・ライフサイクル管理（ALM）分野におけるわれわれの挑戦だ。

データベース管理者にもアプリケーション開発者並みのツールを

VSDB Proは，データベース管理者に向けた製品であり，アプリケーション開発に関する「管理の孤立」の解消が目的だったわけだ。様々な「孤立した活動」を結びつけるに当たって，VSDB Proを最初の一歩に選んだ理由は何か？

　VSDB Proをリリースすることによって，われわれは巨大な肩の荷を1つ降ろせた。これまでのアプリケーション開発プロセスでも，.NET言語やそれ以外の3GL（第3世代プログラミング言語）を使って作業する開発者すべてが，最上級のツールと最上級の変更管理システムを保有しており，高水準のテストや追跡を実行できた。その一方で，データベース担当者は二流のツールしか使えなかった。多くの場合，オフラインで作業することは不可能だったので，データベース担当者は自分の持ち場にずっといる必要があった。そして，自分が本当に実稼働システムと一致するオフライン・イメージを使って作業しているのかどうか，確信を持てなかったのが実情だった。

　データベース管理に関連する事柄は，すべて実稼働システム上で処理される。データベース担当者は，オフラインで作業し，その成果を自信を持って実稼働システムに適用することはできなかった。それだけではない。アプリケーション開発部門で発生した変更点が矛盾なく伝えられているのか，あるいはデータベースで加えられている変更点との間に整合性は保たれているのか−−ということについても，確信を得られなかったのだ。そして，情報を受け取る側の運用担当者は，両者（開発部門とデータベース管理部門）からのデータを受け取って，「どちらを信用すればいいのだろうか？」と悩んでいた。

VSDB Proは，こうした状況にどのように対処しているのか？

　VSDB Proの目標は，データベース管理者のことを，アプリケーション開発部門と同一の変更管理サイクル内における最上級の参加者にすることで，運用部門がアクセスするプロセスから，膨大な量のインピーダンス・ミスマッチを締め出すことだった。

　VSDB Proを使うと，コードに適用するのと同じ変更管理プロセスを，スキーマやストアド・プロシージャなどのデータベース資産に適用できる。変更セットの概念や，1つのチームとして進捗状況や機能を測定する能力についても，コードの場合と同じものを適用できる。ビルド番号についても，両方に適用可能な同一のものを利用可能だ。開発中にデータベース関連の作業を行うとき，ユーザーはスキーマやストアド・プロシージャなどに関して，実稼働システムのデータを直接閲覧できる。その後，代替スクリプトなどを直接生成し，そのビルドから生じるキットの一部として，実稼働システムがアップデートされるのを確認できる。

　VSDB Proによって，作業を進める際の能率性を大幅に向上させ，後の確認作業についても多大な労力を削減できる。われわれは，システムの機能障害を示す重要な兆候として，「リアクティベーション（システムが『アクティブ』から『解決済み』に変更になった回数）」を計測している。VSDB Proを実際に導入した現場では，運用部門からもたらされるリアクティベーションの回数が大幅に減少した。これは大きな第一歩だ。

Visual Studioと「Microsoft Project」の連携も果たした

つまり，VSDB Proは開発部門と運用部門の間の最初の架け橋だったわけだ。運用部門で働くほかのシステム担当者に対しては，どのような架け橋を築くのか。そして全体的に見て，DSIはどのような位置付けになるのか？

　われわれはまず，ALM（アプリケーション・ライフサイクル管理）分野の中心的存在であるVisual Studio Team Systemに取り組んだ。ほとんどの企業において，Visual Studio Team Systemはアプリケーション開発ディレクタの管轄下に理由もなく入れられることが多かった。だがわれわれは，Visual Studio Team Systemのようなツールの導入は，CIOの視点からエンド・ツー・エンドに取り組むべきであると考えている。なぜなら，現在のアプリケーション開発は，孤立した活動の集まりではなく，1つの大きな活動になっている可能性があるからだ。

　それでも，アプリケーション開発活動と他の大きな活動，つまり運用とPMO（プロジェクト管理組織）の間には大きな溝が横たわっている。DSIの目標は，こうした溝に橋を架けることなのだ。われわれはまずVisual Studio Team Systemで，この目標に数歩近づいた。まず，プロジェクト・マネジメントと統合できるように，Visual Studio Team Systemと「Microsoft Project」を統合できるようにした。

「論理データ・センター」でアプリケーションを事前テスト

　次に，Visual Studio Team Architectという製品をリリースした。この製品でわれわれは，「運用部門向けの設計」と呼ばれる機能を導入した。アプリケーションが意図通りに機能し，データ・センターが設定通りに機能すれば，アプリケーションとデータ・センターは問題なく連携できるということを，ユーザーは設計段階，つまりコードを記述する前に確認できる，というのがこの機能の狙いである。

　Visual Studio Team Systemにおいてわれわれは，Logical Datacenter Model（論理データ・センター・モデル）と呼ばれるものを採用して，この機能を実現している。これらを統合したのは，われわれが初めてだった。今日DSIは，Team SystemとSystem Centerの関係者，そしてCIOを対象とするプロジェクトに携わっているわれわれの同僚のすべてが共有するビジョンとなっている。