アーキテクトへの道シリーズ第四話

「モデル駆動」の本当の意味

モデル駆動という言葉が流行していますが、こういった新しい概念を理解する際には、それが何を解決するものなのかという観点で判断することが重要です。本編では最初に今後のITの進むべき方向を考える上で、現在抱えている課題を整理してみたいと思います。その上で「モデル駆動」のあるべき姿についてご紹介いたします。

■課題の整理

エンタープライズにおいて大規模の情報システムを構築する場合に何が課題となっているのでしょうか？下図をご覧ください。まずはビジネス要件を分析するところから課題を抱えています。現在のビジネスは多くの部分をITに依存しており、その複雑な要件を把握して望みどおりの情報システムを構築することが一番大きな課題となっております。次の課題としてテクノロジー選択が挙げられます。テクノロジーは年々新しくなっています。情報システムを新規に構築する、もしくはリプレースするといった場合にどのベンダーのどのテクノロジーを選定すればいいのか悩まれているケースが多いのが実情です。次に大規模なシステムを一貫性を保って高品質なものに仕上げるためには優れたアーキテクチャが必須となります。本来はエンタープライズ規模で全体を統括するアーキテクトの存在が欠かせないのですが、ごく一部の方を除きそういうミッションを達成できる人材が不足しています。情報システムへのビジネスの依存度が強まるに従って信頼性の要件もますます厳しくなっています、情報システムが止まればビジネスが止まってしまうという時代をすでに迎えているわけです。実際にそういった事故も発生しているのでみなさんもすでに認識されていると思います。過去からの積み上げでITの資産も膨大に膨れ上がりこれらを運用・保守していくことが困難になりつつあります。また一世代前と比較するとビジネスそのものの変化のスピードが加速しています。企業の統廃合はもちろんのこと新規ビジネスへの進出・撤退、ビジネスパートナーとの関係など変化要因は枚挙にいとまがありません。そういった変化への対応も情報システムに求められるわけです。つまり一言でいうと要件分析から保守にいたるまでITのライフサイクル全体にわたる課題を抱えていることがお分かりいただけるでしょう。

IT ライフサイクル全般の課題

図 1 : ITライフサイクル全般の課題

ではこの課題をどのように解決していけばいいのでしょうか。それぞれの課題についてはこう解決したいという考え・意図を漠然と持っていることが多いと思います。問題はその意図を明確化して関係者間で共有できないことにあります。本来は課題を可視化することで明確に認識し、漠然としていてもよいのでお互いが考えている解決策を共有し、それらの整合性を保ちながらシステムの構築を進めることが望まれます。それに対する答えが『モデル駆動』なのです。

図 2 : モデル駆動による解決

上図に示したとおりばらばらな意図を一旦モデルとして可視化して、そのモデルを中心に個々の課題を解決していくというアプローチがモデル駆動です。マイクロソフトはこの『モデル駆動』を強力に推進しています。開発のみならず、要件分析から運用・保守、システムのバージョンアップにいたるまで情報システムのライフサイクル、平たくいうとシステムが誕生してから消滅するまでの間ずっとモデルを中心に据えたアプローチを採用するわけです。マイクロソフトではこれを "LIVE MODEL" と呼んでおります。ツールで作成し、開発完了時点で役に立たなくなる従来の "MODEL" とは別次元だということ意味しております。

■モデル駆動型開発

ここまでモデルを中心としたライフサイクルをご紹介いたしましたが、これからは特に注目を集めているモデル駆動型開発についてご紹介いたします。下図にご覧いただけるように情報システムを構築していく上でビジネスモデリングから物理的なインフラストラクチャまで、また構築フェーズすべてにわたって複数のモデリング対象があります。マイクロソフトが考えるモデル駆動型開発とは、これらモデル対象に最適なモデリング環境を提供するというものです。モデル対象によってそのモデラーの得意分野はまちまちです。重要なのはそのモデラーの持つ知識・意図であってツールや表記法（モデリング言語）を使いこなすスキルが重要なわけではありません。つまりモデラーごとに使いやすい表記法、ツールが存在していて、知識・意図を正確にインプットして、各モデル間の連携・整合性が確保されていればよいわけです。IT業界では表記法を統一しようという動きもございますが、単一の表記法でこれら多種多様なモデリングに対応するというのは少々無理があり、現時点でその限界は露呈されております。ビジネスプロセスモデリングにおけるBPMNのように、それぞれに適した表記方法があってしかるべきです。エンドユーザーの方は豊富な業務知識を基に、そこからシステムに対する要件をモデルを通じて明確化することが重要ですが、必ずしもすべてをUMLで記述しなければいけないわけではないのです。運用管理についても同じことが言えます。もっと簡単にモデルが作成できる環境があるべきです。Domain Specific Language(DSL) というのは特定問題領域に特化されたモデル言語のことです。マイクロソフトはこのような考え方に基づいてモデル駆動を実現していきます。

図 3 : モデル駆動型開発

上図をご覧ください、左上のビジネスモデルから右下のインフラストラクチャに至るまで各モデリング対象に最適化された環境を提供し、それぞれの成果物として生成されたモデル間を自動的にマッピングすることで、整合性を保つという思想を表しています。モデル間のマッピングをどのように自動化するかというと、例えばデータに関しては、ビジネスモデルとしてその企業で利用されているデータ（顧客、製品、在庫など）を抽出し、論理的なデータパターンを適用することで、アプリケーションで処理しやすいモデルへと変換します。そして最終的にはデータベースサーバーでのデータスキーマ（構造）に変換されるわけです。その際にはデータベースサーバーが最大の性能を発揮できるようにスキーマが生成されます。データ以外の分野についても同様にパターンを適用することで、モデル間のマッピングを達成いたします。ただ現時点では約7割がこのような自動的な仕組みで実現可能と予測されており、残りの3割程度は手作業が必要になります。技術の進歩とともにこの割合も改善していくことになります。

■Software Factory

現時点におけるソフトウェア開発と製造業におけるそれとを比較すると残念ながらソフトウェアは手工業といわざるを得ません。つまり産業革命以前もしくはその途中の状態です。では今後どのように発展していくのでしょうか。まずは下の図をご覧ください。前半でお話したとおりビジネスアナリストから開発者、運用担当者にいたるまでステークホルダーはそれぞれの役割に応じた意図を持っています。つまりこういうITシステムを作りたいという思いから、一度作ったものを再利用したい、効率的な運用管理を実現したい…といった意図が存在するわけです。今後の開発スタイルはこれらの意図を汲み取ってモデルを構築しそのモデルを中心として各成果物をほぼ自動的に構築するというスタイルになります。つまりソフトウェアは手工業からオートメーション化されていくわけです。その夢のような世界を実現するのが Software Factory です。

図 4 : ソフトウェア開発の工業化

Software Factory ではプロダクトラインという考え方をベースとしています。つまり製造業でいうところの生産ラインです。プロダクトとはソフトウェア（システム、アプリケーション）のことです。簡単にいうと Software Factory とはソフトウェアの仕様（漠然とした意図）を生産ラインに乗せればあとは自動的にデータセンターができあがる仕組みです。しかもソフトウェアの場合にはハードウェア製品とは異なり仕様がはっきりしていなくて、かつ多品種少量になります。ですから漠然とした意図を明確な仕様に変換するところから始まり、またソフトウェアの種類に応じて生産ラインを柔軟に組み替える必要が出てくるわけです。詳細を次の図でご覧ください。

図 5 : Software Factory

まず作業手順としては構築しようとしているソフトウェアの中から類似性のある集団を抽出します。この集団をプロダクトファミリーと呼びます。そしてその中身を構築するにあたり、ファミリーごとに図の左側にあるプロダクトラインを構築します。プロダクトラインを構築するには、まずそのファミリーが扱う問題領域（ビジネスドメイン）のモデリングを実施します。そしてその問題領域を解決するソリューションモデリングを行います。これらモデリングの過程で必須のフィーチャー（提供される機能）と可変的なフィーチャーとを識別します。これが FODA（Feature Oriented Domain Analysis）と呼ばれるものです。一旦フィーチャーが洗い出されると、それを実行するためのアーキテクチャを設計します。そしてそのアーキテクチャに基づいて再利用可能なアセット（ソフトウェア資産）を実装いたします。ここでいうアセットとはコンポーネントや開発プロセス、アーキテクチャ、成果物一覧、ドキュメントテンプレートなどがすべて含まれます。

以上の作業により構築されたプロダクトライン（生産ライン）は似通った各プロダクトを構築する上での最適な環境を提供するので、各プロダクトはそこからのわずかな差分だけを扱えばいいわけです（図中右側）。まず個別の仕様を開発ツールにインプットすることで作業を開始します。開発ツールはプロダクトライン構築作業によって生成されたソフトウェアスキーマ（モデル成果物）をインポートすることで、プロダクトを開発するために最適化（カスタマイズ）された環境に変わります。その最適化された開発環境を利用し、固定的なアセットを利用することでほぼ70%の作業は自動化されます。残り 30% は可変的なアセットを利用しながら開発者が作業を行うことになります。弊社は Visual Studio 2005 という今年リリースされる統合開発環境で、この概念を実現いたします。

■モデル駆動による自律型コンピューティング

ITのライフサイクル全般を考えるとモデル駆動で開発できるだけでは不十分です。構築から配布、運用・保守にいたるまですべてのフェーズで「モデル駆動」を実現することで情報システムは自律性を持つことになります。

図 6 : Dynamic Systems Initiative

弊社は Dynamic Systems Initiative という名称でこの自律型コンピューティングを実現していきます。一般的には「ユーティリティコンピューティング」という名称で知られていますが、つまり仮想的なインフラストラクチャを構築し、システムの負荷状況に応じて動的にハードウェアリソースを割り当てるという試みです。典型的なケースとしては朝一番と帰宅直前などにシステムの負荷が最大になるため、個々のシステムはその最大負荷に耐えられるようインフラを設計するわけですが、全社規模で見ると必ずしもすべてのシステムが同時刻に最大負荷がかかるわけではなく、ただ遊んでいるだけのサーバーも多数あるわけです。こういった冗長なインフラ構成を防ぐために、インフラ自体を仮想化し、負荷に応じてリアルタイムにハードウェアのリソースを現時点で負荷の高いシステムに割り当てることで、全体最適を図ることが可能となります。ただそういった形で負荷に動的に対応できるデータセンターを達成するためにはインフラの仮想化だけでは不十分です。アプリケーション配布や、データセンターの運用ポリシー、またシステム稼動時の運用管理までを視野にいれた包括的な取り組みが必須です。そのために開発の初期段階から運用管理のことを考慮し、アプリケーションの設計を実施するというアプローチを採用しています。Visual Studio 2005 では、アーキテクチャを構築する際に論理的なデータセンター ( サーバー、ストレージおよびネットワークなど ) をビジュアルに表現し、サーバーなどそれぞれの運用ポリシーを定義します。そしてアプリケーションの動作条件（性能、セキュリティ、プロトコルなど）も初期段階から定義をしておくことで、実際に展開する前段階からデータセンターの運用にマッチングさせることが可能となります。これらの情報はすべてモデル ( System Definition Model ) として格納され、アプリケーションの配布、運用はこのモデル ( SDM ) を参照する形でほぼ自動的に実現することが可能となります。またシステム改変時にはこのモデルを変更することで変更部分がこれもほぼ自動的に適用されます。さきほど "LIVE MODEL" と申し上げたのはこういった意味を持っているのです。

■まとめ

今回は「モデル駆動」という概念が、情報システムの構築から運用・保守にいたるまですべてをカバーすることをご紹介いたしました。特に Software Factory によるソフトウェア開発の自動化は今後の IT 産業構造を変革することになるでしょう。次回はこのような開発方法論を実際のプロジェクトに適用するための開発プロセスについてご紹介いたします。

Top of Page