モデル駆動開発に関する誤解と課題

長い年月を経て、未だMDDの導入レベルは期待されるものに達していないように思えます。実用的なMDDのサクセスストーリーについての認識不足、どのようにして日常的に使用できるのかという疑問、先行投資についての資金調達モデルの欠如、または戦略的イニシアチブについての焦点の欠如など、MDDの使用法を制限する多数の抑制要因が存在します。

過去にMDDの使用を試みて、難題に遭遇し、その結果、現在はMDDを使用していない方がいるかもしれません。または、現在MDDを導入しようとしていて、難題や障害に直面している方がいるかもしれません。ご自分がこのような状況のいずれかに該当することに気付いたなら、この論文はあなたの為にあるといえます。この論文では、MDDの導入に関する課題と誤解について考察します[1]。

モデリングは、コミュニケーション、ビジネスアラインメント、品質、および生産性を向上させることによって価値を提供するという能力を証明しました。その適用性には、分析、設計、開発などの多くの専門分野が含まれます。これを念頭に置いて、MDDに関する多数の誤解と課題についてと、現代のアプローチおよび関連するツールセットでどのようにそれに取り組むことができるかについて考察します。

1 – 課題: メソッドは準備万端に整っておらず使いやすいものではなかった

モデル駆動開発（MDD; Model Driven Development）の主な抑制要因の1つは、人々が自分達の業務を行うときにMDDのベストプラクティスが容易に利用可能でなかったということでした。たとえば、人々は、特定のタスク（たとえば、高度に利用可能なソリューションの設計）の実行方法に関するプロセスドキュメンテーションを入手できましたが、その記述にはMDDコンテンツが含まれていませんでした。MDDのプラクティスを入手するには、論文や本で調べ、それを既存のMDDでないドキュメンテーションに適用する必要がありました。

現在では、プラクティショナー（実践者）は自分達の日常業務を行うときに多くのMDDガイダンスを利用でき、その情報は日常的に使用するツールに埋め込まれています。我々は、開発プロセスを目にし始めています。これには、MDDの原理を利用する「ツールメンター」のベストプラクティスが含まれます。「ツールメンター」はメソッドとプロセス全体に適用されます。

現在、特定のタスク（要件のレビュー、ユーザーインターフェースの設計、高度に利用可能なソリューションの設計など）のガイダンスには、MDDコンテンツへのリンクが含まれています。たとえば、デザインパターンが推奨され、手元のツールのパターン実装を使用した、パターンを設計に適用する方法について、ガイダンスが提供されます。

別の抑制要因は、MDDが特定の開発メソッドと混合され過ぎているせいで、人々がMDDのベストプラクティスを抽出し、異なった状況でそれらを適用できなかったことです。典型例は、オブジェクト指向分析設計（OOAD; Object Oriented Analysis and Design）に大量のマテリアルがあり、完全なOOADコンテンツを導入し、その一部としてMDDのメリットを得ることができたか、またはOOADをまったく導入しなかったかのいずれかです。MDDのベストプラクティスはOOADフレームワークの一部でしたが、人々は、これらのベストプラクティスをフレームワーク外で活用する方法を知りませんでした。MDDコンテンツを抽出して、異なった状況でそれらを適用することは不可能でした。

上記およびその他の要因は、企業が自社の環境にベストプラクティス（MDDのベストプラクティスを含む）を導入することを困難にしていました。企業は既存のプロセスとメソッドを配備しており、MDDの側面をそのメソッドに追加することは困難でした。

業界は現在、特定の開発プロセスを、組織および特定のタイプのプロジェクト向けに導入するよう調整できる能力が向上しています。たとえば、カスタマイズした開発プロセスの開発にチームを誘導することを目的としたワークショップがあります。これは通常、「メソッド導入ワークショップ」と呼ばれています。ワークショップの目標は、特定のプロジェクト向けに既存のメソッドコンテンツを調整することであり、これには通常、プロセスエンジニア（組織の開発プロセスを所有する人物）、アーキテクトリーダー、開発者リーダー、およびプロジェクトマネージャーが関与します。

こうしたカスタマイズをサポートする、Rational Method ComposerやEclipse Process Framework Composerなどのメソッドツールが登場しました。これらのツールには、コンポーネント化されたベストプラクティスライブラリが含まれています。これらのツールのアイデアはベストプラクティスが成文化およびパッケージ化されていることであり、ツールを使用して、ベストプラクティスを自身の組織向けに調整し導入できます。ツールでは、導入したい特定のメソッド要素を選択し、それを修正し、独自のものに成文化し、そのコンテンツを希望するプロセスに編成します。その後、結果のプロセスを、プラクティショナーが日常業務を行うときに読み取り可能な形式（HTMLなど）にし、組織が利用できるものにします。

記載したツールおよびアプローチを使用する多くのガイダンスが利用可能になっていますが、依然としてユーザーはそのガイダンスを探し、解釈し、それに従うことが必要です。この障害を克服する助けとなる一歩は、ガイダンスを提供するだけでなくソリューションの側面を自動化できるツールを取り入れることです。たとえば、Eclipseベースの製品を使用すると、Cheat Sheetを利用できます。Cheat Sheetは、タスクを完了するための段階的なガイダンスを提供し、ワークフロー内のステップを自動化できます。

3つ目のメカニズム、パターン実装については、次のセクションで論じます。選択したメソッドに関係なく、重要な点は、ますます多くのガイダンスが取得および導入されており、ユーザーが取り組みの中でモデルを利用しようとする際にツールはより良く導くことができるようになっているということです。

ソフトウェアソリューションを過剰設計する可能性があるように、ガイダンスを作成する場合も同じことが起こり得ます。この課題の克服に必要な最終要素は、現実的で、実践的で、先見的になることの必要性です。ソリューションの増築に必要なすべてのステップに関するすべての詳細を理解することに、意味や価値（そして適切な時）はほとんどありません。重要なステップは何でしょうか? それらはどのようにチームのスキルと調和するのでしょうか? ステップの文書化に時間をつぎ込むことが賢明なところはどこでしょうか? 自動化に対し、静的なドキュメンテーションの作成にはどのくらい投資すべきでしょうか?         

プロセス、および特にMDDは、誤解4で論じているとおり、フリーサイズのソリューションではありません。

2 – 課題: MDDのメリットを得るための適切なインフラストラクチャとツールの準備が整っていなかった

近年、モデリングツールは、統一モデリング言語（UML; Unified Modeling Language）などの特定のグラフィカルな表記法を単にサポートするものから、プラクティショナーの業務を大いに支援するものへと進化しています。ツールは、グラフィカルなモデリング記法をサポートするだけでなく、現在では次のようなメリットをもたらすMDD機能が組み込まれています。

• ビジネスアラインメント: ビジネスアラインメントは、サービス指向アーキテクチャ（SOA; Service Oriented Architecture）のような成功したアプローチの重要な側面です。MDDモデルと自動化およびそれらに関連する「追跡」を使用することで、ビジネス要件まで追跡し、決定を下す理由を追跡記録します。さらに、ビジネス駆動開発（MDD; Business-Driven Development）など、MDDの特殊バージョンを利用することを検討できます。BDDはその名が示すとおり、ビジネスをモデル化することに関係しています。この場合、ビジネスを構成するプロセスをモデル化でき、場合によっては、シミュレートできます。
• 品質の向上:プラクティスがツールで成文化され、自動化されているため、エラーの余地はほとんどまたは一切ありません。
• 一貫性とガバナンス（統制）の向上: ツールがベストプラクティスのガイダンスと自動化のサポートを提供するため、ソリューション内の要素の一貫性が向上します。また、ツールは、構築された要素が要件とベストプラクティスの両方に関連付けされ連携することを確実にします。
• 生産性の向上: 繰り返しの、時間のかかるタスクは現在、自動化されています。プラクティショナーは、「再利用」して、最も重要なこと（ビジネスロジックなど）に時間を当てることができます。構築された自動化や、ユーザー基盤の高度化のレベルや、自動化される側面に応じて、投資に対するROIは、現在のプロジェクト内で達成できるか、または複数のプロジェクトにわたって広がる場合があります。
• コミュニケーションの向上: モデル、ツール、自動化の使用により、プラクティショナー（アーキテクトなど）は、様々なオーディエンスを対象とする様々な観点を得ることができます。
• 影響分析: MDDのトレーサビリティにより、ソリューションに対する要件変更の影響、およびその逆の影響を分析できます。

MDDがルによってどのように活気付けされるかを例証するために、デザインパターンを例として使用します。たとえば、本に記載されているデザインパターンがあると考えてください。これをパターン仕様と呼びます。その仕様は非常に役に立ちます。それは、パターンを使用すべき時の要因、パターンのパラメータ、パターンを使用することの利点および影響について説明しています。パターン仕様は、人々がパターンを理解できるよう手助けし、該当するものがあればそれを選択する手助けをします。ただし、パターン仕様は設計の品質向上や生産性の向上を保証しません。これらのメリットを得るには、パターンを「自動化する」必要があります。これを、パターン実装と呼びます。ツールで再利用可能なパターン仕様の成文化です。パターン実装を使用して、設計者は現在、非常に素早くパターンを設計に適用でき、それが正しく適用されることを確信することができます。

ドメイン非依存のツールに、自身のドメインに必要なすべてのMDD成果物が組み込まれているというのは、非常に考えにくいです。ツールで提供されるすぐに使えるMDD成果物（デザインパターン実装セットなど）があるほか、ツールを使用して、提供されるものを「拡張」し、独自のものを構築することができます。ツールには現在、ベストプラクティス、テンプレート、およびAPIを備えた「拡張性フレームワーク」が含まれています。Rational Software Architectなどのツールを使用して、自身の分野に適用できるMDD成果物（パターン実装、規則、制約など）を構築できます。

MDD成果物を構築できるようになった今、アセットベース開発（ABD; Asset Based Development）が提供するプラクティスとインフラストラクチャにより、これらの成果物を他の人と共有して再利用性を促進することができます。言い換えれば、ABDのベストプラクティスとインフラストラクチャ改善はMDDの導入をサポートします。Rational Asset Managerなどの再利用可能なリポジトリでは、再利用可能なソフトウェア成果物を管理し、開発コミュニティに成果物を共有および再利用してもらうことができます。自身のドメイン向けに作成されたパターン実装について考えてください。それを資産リポジトリに登録し、レビューや承認をしてもらうことや、コミュニティ内の他のプラクティショナーに再利用してもらうことができます。このエコシステムの一環として、資産がいつどのように再利用されるかを監視し、フィードバックを集め、チーム全体が適切な資産の適切なバージョンを使用していることを確実にすることができます。

再び、実践的で実用的になることに戻ります。ABDおよび再利用のイニシアチブは、あなた自身とあなたの組織にとって理にかなうことであるため、導入する必要があります。成熟度を認識し、それをサポートする必要なツールとプロセスを導入する必要があります。先見と計画により、必要に応じてABDプログラムを拡大および展開し、不要なオーバーヘッドとコストを回避することができます。

3 – 誤解: MDD == UML?

1つの誤解は、MDDでは、統一モデリング言語（UML）を、オブジェクトマネジメントグループ（OMG; Object Management Group）のUML仕様に定められているとおり、そっくりそのまま使用する必要がある、ということです。この誤解を解くことができる方法は多数あります。

この考えを払拭できる最初の方法というのは、MDDアプローチで作業するために必要なことは、実行する作業でモデルを重要な成果物として使用し、自動化によってこれらのモデルを利用することだけである、ということです。この文脈において、モデルとは、明確に定義された構文と意味論を持つ言語を使用して現実を単純化したものです。したがって、MDDで使用できる言語はUMLだけでなく、多数あります。

大半のシナリオと同様に、手元のタスクに適切なツールを選定することに焦点を当てる必要があります。MDDの取り組みに関して、標準化された、有名な、広くサポートされている言語を必要とするなら、UMLは良い選択です。また、UMLは、拡張可能なように構築されています。プロファイルの使用によってカスタマイズ可能であり、要素、プロパティ、および制約をカスタマイズできます。これによって、UMLをあなたが実行している作業に特有なものにすることができ、言語を習得および使用しやすいものにすることができます。モデリング言語の使いやすさ（consumability）または特異性を向上させる別の選択肢は、ドメイン固有言語（DSL; Domain Specific Language）を作成することによって達成できます。

覚えておくべき重要なことは、使用する言語と作成したモデルからメリットを得るということです。投資を誘導するために、次の質問を利用できます。

• ソリューションスペースを効果的に設計および理解できますか?
• 他の人と容易にコミュニケーションを取り合うことができますか?
• モデル化されたものをベースにして、ソリューションの他の部分を生成できますか?
• その成果を開発ライフサイクルの外部で効果的に活用できますか?
• 設計に対する実装を効果的に追跡できますか? 要件に対してはどうですか?

4 – 誤解: MDDはフリーサイズのソリューションである

前の誤解に続き、MDDがフリーサイズのソリューションでないということは、デフォルトの工業製品ラインのツールセットを使用して製品を構築できないのと同じで、明らかです。MDDとは要するに、特定の状況に価値をもたらし、特定のドメインに適用でき、開発中のソフトウェアのタイプに適した方法で、モデルを使用することです。その目的に向け、我々はMDDを使用できる多数の方法を検討し、自分達の状況で意味をなすように実行できます。

1つの例は、従来のオブジェクト指向分析設計（OOAD; Object Oriented Analysis and Design）アプローチとともにMDDを使用できる方法です。OOADとMDDに注目するとき、たいていは、ユースケース、分析、設計、実装などの多数のモデルの使用を確認します。これらのモデルがソリューションの作成のために併用されていることを示す、多くの例と多くのドキュメンテーションが存在しています。しかしこれは、これらのモデルをすべて使用しなければならないと言っているのではありません。重要な点は、我々が抽象化を効果的に利用するということです。抽象化のレベルの数は、自動化が影響するほか、各自の状況、使用中の言語、関連付けされた制約、規則、仮定によって異なります。

モデルの数（および関連する抽象化のレベル）に関して実践的になることに加え、モデル内で使用するダイアグラム（図）を選ぶことに関しても、同じくらい実践的になる必要があります。ダイアグラムは、パースペクティブを伝えるのに使用されます。たとえば、モデリングの言語としてUMLを使用している場合、利用可能なダイアグラムの各タイプ（クラス、相互作用、…）を使用する必要はありません。言語にはそうした様々なダイアグラムの選択肢があり、幅広いニーズに対応する汎用モデリング言語であることが分かります。自身の特定の状況において、価値をもたらし、達成しようとしているものを伝えるのに役立つダイアグラムのみを選ぶことが賢明です。そして、完全を期すために議論をさらに一歩進めて指摘すると、ダイアグラム内でも、利用可能なすべてのモデル要素を使用する必要はありません。

5 – 誤解: ダイアグラムはモデルである

MDDにおいて重要なことは、モデルを作成しているということを認識することです。前に述べたように、モデルとは、明確に定義された構文と意味論を持つ言語を使用して現実を単純化したものです。そのモデル内には、多数のモデリング要素とダイアグラムセットがあります。各ダイアグラムは、モデル要素のビューを提供します。各モデル要素は、ゼロ個以上のダイアグラムに属することができます。我々は、それらのモデル要素に焦点を合わせる必要があります – モデル要素は何か? その関係はどのようなものか? 特性はどのようなものか? 通常、ダイアグラムを使用して、こうした側面を検討することができます。また、他の人とコミュニケーションを取る方法としてダイアグラムを使用します。ただし、モデルからの重要な情報はモデル要素内にあります。これにより、必要なビューを生成でき、必要に応じてダイアグラムを作成でき、モデルからの他の要素の生成をサポートすることができます。もしMDDがほぼダイアグラムだったら、ツールに必要なものは、きれいな絵を描画できるアプリケーションだけでしょう。ダイヤグラム（および、それらのツールサポート）が重要でないというわけではありません。内部でモデルとダイアグラムを作成するためのツールは、対象のオーディエンスに合わせて調整する必要があります。

ダイアグラム内で選択的であると同時に、モデルをより使いやすくコミュニカティブなものにする方法としてビューポイントの利用を試みることができます。ビューポイントは、モデルの特定の領域が複数のオーディエンスを対象としたモデルを作成するための追加ダイアグラムを提供するように、モデルを編成する方法です。通常、パースペクティブにはダイアグラムのみが含まれ、意味論的要素は追加されません。そのため、意味論的要素をアップデートすると、パースペクティブは自動的に同期が保たれます。パースペクティブの使用は、他の役割やグループとのコミュニケーションを効果的にサポートできるようにすることで、MDDの取り組みに価値をもたらします。各グループは、各自のニーズに関連したソリューション部分を理解したがるでしょう。パースペクティブの使用により、モデルを乱したり、個別のモデルを構築したり、同じ要素の複数のバージョンを維持管理して時間を無駄にすることなく、こうしたニーズをサポートすることができます。ありとあらゆる様々なグループをサポートし、膨大なパースペクティブセットを作成する必要があると言っているわけではないことを覚えておいてください。またしても、重要なことは、実践的になることと、意味をなし価値をもたらすダイアグラムとビューポイントを作成することです。

6 – 誤解: コードはモデルであり、モデルはコードである

初期のMDDの誤解の1つは、MDDがコードにしか適用できないということでした。基本的に、MDDは低レベルの抽象化に制限されていたため、限定的な影響しか与えることができませんでした。多くの人々が、単にコードを「ビジュアル化」する方法としてMDDツールを使用していました（コードのグラフィカルなビューを与える逆の変換を考えてください）。これには、利点があります。たとえば、コードの大部分と、コンポーネント間またはクラス間の関係をより良く理解できます。しかし、コードのビジュアル化は、それだけでは、前に論じたようなMDDのメリット（ビジネスアラインメント、品質向上、生産性向上、または影響分析など）を得ることを可能にしません。コードをグラフィカルに表示できるようにするだけです。これは、ダイアグラムを使用する基本的な低レベルのアプローチであり、案の定、少ない投資で少ない利益しかもたらしません。

もう少し高度にする次のステップアップは、コードをビジュアル化し、それを意図した設計を使って調整できるようになることです。たとえば、設計者またはアーキテクトが、開発チームによって作成されたコードをレビューしたがっていると想像してください。コードのグラフィカルなビューによって、彼らはコードを自分達の設計と比較することができます。同じビジュアル化（たとえばUMLクラス）が使用されているからです。しかし、どちらも同じ言語を使用して表現されますが、異なるレベルの抽象化に存在するため、2つの表現の間には依然としてギャップがあります。MDDツールは、ビジュアル化、トレーサビリティ、分析、発見の機能、およびリファクタリングのサポートを通じて、設計者の取り組みを支援できます。設計とコードの相違の領域にフラグが立てられると、通常、設計者は開発チームと連絡を取るために、手動の介入が必要になります。これは価値をもたらしますが、MDDの十分なメリットを得ることはできません。分析とコミュニケーションをサポートするための時間と労力がプロジェクトに追加され、1つのプロジェクトにつき複数回の投資が必要になります。

MDDはどんな抽象化レベルでも適用し、異なったレベルをトラバースすることにも役立ちます。高い抽象化レベルでモデル化することが必要です。たとえば、設計モデルへの変換の情報として使用される分析モデル（システムユースケースモデルなど）について考えてください。分析モデルの中には、設計において利用できるものが存在します。たとえば、機能領域への情報のカテゴリ化（パッケージ）、または各ユースケースを使用して、ユースケースが実現される設計モデル内の相互作用図のベーステンプレートを作成することができます。ツールとその拡張機能を使用して、この「分析から設計への」変換を成文化し、組織内の人々がその品質と生産性のメリットを得られるようにすることができます。

MDDはどんな抽象化レベルでも適用するため、無限の抽象化レベルが存在します。自身のドメインおよび自身の組織に適した抽象化レベルを使用してください。例として、サービス指向アーキテクチャ（SOA; Service Oriented Architecture）では、ソリューションを開発する際に次の抽象化レベル[2]を検討できます。

• ビジネス: このレベルはビジネス戦略家、ビジネスアナリスト、またはプロダクトオーナーに適しています。このレベルでは、モデル要素は企業目標、重要業績評価指標、営業方針、機能領域のようにものです。
• 分析: 通常、分析と設計は一緒に検討され、分析モデル要素は時として設計要素に発展します。SOAとの関連においては、分析を検討することが重要であると我々は信じています。なぜならそれが、ビジネス要素をサポートするための、技術的なモデル要素が生じるところだからです。
• 設計[3]: 設計レベルでは、SOAソリューションのアーキテクチャ上重要な要素の大半がモデル化されます。設計は、アーキテクチャの重要な要素と、それらがどのように実現されるかを文書化します。
• 実装: 実装は抽象化の「コード」レベルです。これは、MDDの使用により、設計に基づいてコードスタブを生成し、必要に応じてコードと設計を調整することが可能な場所です。

その対極で、人々がモデルとMDDにあまりに夢中になって、モデリングのために単にモデル化だけして、そのモデルを実用的なものや実行可能なものに変えることを忘れるといった状況があります。アーキテクトは、利害関係者、設計者および開発者とコミュニケーションを取ることができます。しかしまたしても、ご察知のとおり、MDDの十分なメリットを得ることはできません。MDDの戦略とメソッドを計画するときは、必ずモデルをどのように利用するかについて考えてください。たとえば、ソリューションが最終的に配備されるプラットフォームは何ですか? どのようにコードの品質と開発者の生産性を向上させることができますか? モデルを取得してそれらをコードスタブに変えるような変換がありますか?

また、作成されたモデルには、コード生成に必要なものを超える、設計に関する役立つ情報が含まれているため、取得した重要かつ貴重な情報を利用できる他の方法を検討することができます。これには、ドキュメンテーション、テストケース、配備スクリプトの生成などがあり、プロジェクトの全体的な生産性を大幅に向上させることができます。誰もが知っているとおり、実際のコードの記述は、プロジェクトを始動する取り組み全体の一部にすぎません。

銀の弾はありません。必要なコードがすべて自動的に生成されるようになるわけではありません（ドメインがかなり小さいなら別ですが）。最終的に、モデルとコードを管理する必要があります。MDDは、モデルを活用できるように、そして、コードがモデルと同期するように導いてくれます。

しかし、ラウンドトリップエンジニアリングについてはどうでしょうか? 抽象化レベルをまたいでモデルの同期を保つために、どのように自動化を利用できるでしょうか? これはまだ、一般のソリューションで解決するには手ごわい問題です。たとえば、上位レベルのモデルから下位レベルのモデルへ移行すると、要素の外に扇があり、そこでは、1つの要素が下位レベルで多数の要素を生み出すことができます。作成後、ユーザーは、要素をアップデートしたり、削除したり、下位レベルのモデルに追加することができます。再度その上位レベルにマップするにはどうすればよいでしょうか? 詳細な要素のセットから、より少ない数の上位レベルの要素への変換/マッピングはどうなのでしょうか? 課題に関連して、これが自身の開発アプローチの一部として追求したいアプローチであるかどうかに疑問を持つことが賢明です。

修正はコードレベルで生じやすいため、モデルとコードの「調整」を試みるアプローチなしでは、モデルはすぐにドキュメンテーション専用として見なされるでしょう。最近、Rational Software Architectなどのツールは、「調整」の領域で大いに改善され、コードのビジュアル化、diff、およびマージの機能を提供します。これらの変更を調整するためのアプローチはツール機能よりも重要であるということに注意してください。これは、ガバナンス（統制）に関係しています。たとえば、アーキテクトがコードとモデル間の相違を見つけた場合、どうなるでしょうか? アーキテクトは開発者と議論するのでしょうか? アーキテクトはコードを変更するよう開発者に依頼するのでしょうか? アーキテクトはモデルを変更するのでしょうか? お分かりのように、完全に自動化されたアプローチにはならないでしょう。

大きな成功を収めている別のアプローチは、制約、規則、および仮定を使用して問題空間を狭くする（購入された、または慣習で使用されている）ツールに前もって投資することです。問題空間を抑制できるほど、高い割合のソリューションを実現し、抽象化のレベルを減らし、ラウンドトリップの必要性を排除できる可能性は高くなります。そのような状況では、焦点はフォワード専用エンジニアリングにあります。

7 – 課題: プラットフォーム非依存は困難である

いつなぜ起こったのか分かりませんが、非常に高いレベルのモデリングという考えに大きな注目が集まり、ソリューションの生成が可能になりました。恐らくそれは、他のところ、つまりMDAプラットフォーム非依存のモデルによるものでしょう。起因に関係なく、非常に高いレベルのものから進み、多くの異なる種類の実装を対象とする1つの表現を使用することは、非常に困難であることを認識することが重要です。ユーザーがモデルを利用してソリューションの結果コードを100%生成することを可能にするソリューションは、いくつかありました。しかし、そうしたケースでは、前のセクションで触れたように、ツールはドメインに固有であり、その移行を可能にするために制約、規則、仮定が利用されました。ソリューションスペースは非常に狭く保たれたため、高レベルな生成の機会を提供します。ソリューションスペースの範囲を広げるにつれ、生成はより困難になります。

DSLの質問に移行しても、複数の基礎となる実装を生成するための情報として役立つ同じモデルの使用が、いかに容易であるかについて取り上げられます。DSLの利用を検討する場合に重要なことは、ドメインと現在のプロジェクトの詳細についてです。我々が多くのアジャイルプロセス（および自らの経験）を通じて学んだように、あらゆる可能性の過剰な設計と説明に支払うべき代価というものがあります。モデリングおよび我々が使用する言語にも同じことが言えます。ドメインに固有であることは、必ずしも悪いことではありません。実際、我々にとって最善である場合があります。しかし、ドメイン固有のソリューションを作成し、それを広範なソリューションに適用できることを期待するというのは非現実的です。

8 – 課題: プログラマを創造的に保つ

MDDに移行し、デザインの取得、コミュニケーションの改善、ソリューション要素の生成を行う方法の単純化を目指す場合は、それがチームに影響を与える場合があることを認識しなければなりません。チームメンバーの中には、低い抽象化レベルで作業することを好む人がいるかもしれません。モデリング環境に拘束されていると感じるかもしれませんし、ソリューションにどのように取り組むかについて、もっと自由でありたいと思うかもしれません。こうした懸念のすべてが有効な懸念であるわけではありません。しかし、内在するテーマを認識することが必要です。チームの各メンバーから最高の力を引き出そうとすることが必要です。

モデルを使用して作業する場合でも、基礎となる実装についての専門知識が必要です。どんなフレームワークを使用すべきでしょうか?フレームワークはどのように一体化するでしょうか? パターンの例を見てみましょう。パターン実装の構築に重要なものは、手本（exemplar）と呼ばれるリファレンスソリューションです。これは、どのようなパターン実装がどのように機能すべきかを決定するために使用されます。独自のパターン実装を構築する場合、誰が手本を構築するのでしょうか? 手本が本当に問題を解決する最適な方法かどうか、誰が判断するのでしょうか? モデリング経験の単純化を検討する場合、誰が規則、仮定、および制約を考え出すのでしょうか? それらは皆が使用するツールにどのように成文化されるでしょうか? 願わくは、これらの質問が、専門知識、創造性、および問題解決スキルが必要な多くの場所があるという事実を浮き彫りにすることです。MDDの取り組みを計画および開始するとき、これらの課題をチームに伝え、チームの皆がプロジェクトに建設的かつ生産的に貢献できる方法を見つけることができるようにすることが、重要です。過去のプロジェクトを振り返ってください。真に創造的な作業にどのくらいの時間をかけてきましたか? 機械的で退屈な繰り返しのタスクにどのくらいの時間をかけてきましたか?

9 – 課題: 活用できるコンテンツが存在しなかった

比較的新しい他のアプローチと同様、ベストプラクティスが理解されてインフラストラクチャが配備されるまでは（前のセクションで論じた課題）、非常に限られたコンテンツしか生成されません。現在、MDDはより成長しソフトウェア業界で反響を得ているため、我々は、高品質のMDDコンテンツと資産が生成されているのを目にし始めています。このコンテンツが最初から利用可能であることは、MDDの導入に極めて重要です。

ツールとインフラストラクチャを配備することは、我々が直面するビジネス課題に対処するソフトウェアの実現に十分ではありません。最終的に、問題を解決するのはツールではなく、ツールを使用する人々です[4]。そして、人々にツールを使用してほしい場合、ツールに最初からすでにコンテンツがあると大きな差が生まれます。あなたは今までに空白のホワイトボード、紙、またはIDEワークスペースの前にいたことがありますか? 最初からリファレンスまたはテンプレートといったアプローチを導き構造化するものがあったほうが、楽ではないですか?

ここで我々が話しているMDDコンテンツとは、単なるデザインパターンやUMLプロジェクトテンプレートではありません。業界やソリューションのリファレンスアーキテクチャ（コールセンターのリファレンスアーキテクチャや銀行業のリファレンスアーキテクチャ）、実用的なモデルとしての業界標準の成文化（保険業向けのACORDや電気通信業向けのSIDなど）、または実装スタブの包括的なテンプレートといったものについて話しています。この種の資産の成功例は、WebSphere Business Services Fabric（WBSF）のIndustry Content Pack （ICP）です。WBSFフレームワークは、ランタイムと関連ツールで構成されています。ICPは、特定の業界（ドメイン）向けにカスタマイズ可能なコンテンツを提供することで、フレームワークを補足します。このコンテンツには、その業界の標準を順守する様々な抽象化レベル（ビジネス、設計、実装など）のモデルとテンプレートが含まれ、組織はそれを調整し導入することができます。

この資産の重要な価値命題は、それらがより高いビジネス価値を提供し、組織の戦略に近づくことができるということです。言い換えれば、ビジネス部門は、それらがボトムラインに影響するのを目にすることができます。私たちが再利用可能なデザインパターンと業界フレームワークの価値を比較し始めた場合、もちろん、業界フレームワークはより高い価値を提供します。しかし、業界フレームワークの適用性は、より限られています。たとえば、それが保険業向けのフレームワークである場合、あなたの職業が電気通信業の場合はそれを使用できません。これに反して、デザインパターンは業界を問わず適用できます。ただし、提供される価値は限られ、ボトムラインからはかけ離れています。アセットベース開発（ABD; Asset Based Development）コミュニティによって認められているとおり、このコンテンツをカスタマイズ可能なもの（専門用語は「可変部分」）にすることは、適用性の拡大に役立ちます。

この種のコンテンツは高い抽象化レベル（ビジネスモデルなど）に限定されないということに注意してください。運用資産は実用的かつ実行可能であるため、ボトムラインに影響します。たとえば、セキュリティ領域の資産である、再利用および導入可能な粒度の細かいアクセス制御ポリシーについて考えてください。確実にこれらはボトムラインに影響を与え、人々はそこから高レベルのビジネスセキュリティポリシーへのリンクを作成することができます。

10 – 誤解: MDDは開発のみに関することである

ソフトウェアソリューションを構築するときに、モデルを使用して、アーキテクチャ、関連するサービスとコンポーネント、そしてそこからソリューションの他の側面を指定することには大きな価値があります。しかしそれは、MDDが組織に価値を提供できる場所と方法の一部にすぎません。モデルを活用してメリットを得ようとするときに、その範囲をこうした狭い使用範囲に制限する必要はまったくありません。

前に、MDDの特殊な形式として、ビジネス駆動開発について論じました。その場合、焦点となるのはビジネスをモデル化することです。ビジネス内のプロセスはどのようなものですか? それらはどのように機能しますか? どのようにそれらを最適化できますか? この取り組みの部分をきちんとしなければ、他のすべてがGIGO（garbage in, garbage out）を被るでしょう。

また、我々は、モデルを利用して規制順守の取り組みをサポートすることができます。モデルを使用して、結果のソリューションが規制要件をどのようにサポートするかを詳述する理解しやすい表現を提供できます。たとえば、モデルを使用して、どのように組織は顧客層、LOBまたはチャネル全体に規則を一貫して適用するかを示す規制要件を満たすことができます。単に、コンプライアンスを文書化するコードを提供することは、不十分なソリューションです。

既存のソリューションの機能性を強化することを目指している場合はどうでしょうか? 要件「A」が変更された場合、システムにどのような影響がありますか? ITランドスケープのどの部分を検証、修正する必要があるか、どのように判断しますか? 要件から実装までのトレーサビリティがなければ、これは答えるのが困難で高価な質問になります。

MDDをエンタープライズで利用できるさらなる例として、エンタープライズアーキテクチャ（Enterprise Architecture）およびオペレーショナルモデリング（Operational Modeling）のサポートが挙げられますが、これらに限定されません。意図やターゲットは異なりますが、我々は依然として、コミュニケーション、抽象化の利用、ガバナンスの確保、コンプライアンスのサポート、および生産性の向上を目指しています。

まとめ

MDDは、コミュニケーション、ビジネスアラインメント、品質、および生産性を向上させることによって多くのメリットをもたらすため、検討すべきものです。過去に検討したことがあるのなら、もう一度見直すときであるかもしれません。今までに検討したことがない場合は、ツールサポートが非常に成熟した今こそ、良い時です。

MDDは、ツールキット内のもう1つのツールです。1つの言語または言語内の1つのライブラリだけを使用するのではありません。成功するための適切なアプローチとMDDの側面を選定する必要があります。プロジェクトでMDDの利用を検討するときに、あなた自身の方法を見つけるアプローチとして覚えておくべき質問は、次のとおりです。

あなたの状況はどのような感じですか?

• あなたの状況はどのような感じですか?
• モデリングツールから何が必要ですか?
• モデリング言語から何が必要ですか?
• どんな抽象化レベルが必要ですか?
• ソリューションの構築をどのように単純化および自動化することができますか? 
• どんなダイアグラムのタイプが必要ですか?  ダイアグラムはいくつ必要ですか?
• 誰とコミュニケーションを取りたいと思っていますか?  彼らは何を知る必要がありますか?
• どのようにして、MDDアプローチとツールをチーム全体が使いやすいものになるようにしますか?
• どのようにチームのスキルを最大限に活用し、皆を関与させますか?
• あなたの問題空間に利用可能な既存のコンテンツはありますか?
• ビジネスのサポートのために、どのようにMDDを利用できますか?  ITのサポートのために、どのようにMDDを利用できますか?  ビジネスとITの連携をもたらすためにどのようにMDDを利用できますか?
• どのコンテンツが利用可能ですか?  自身の状況に合わせてそれをどのようにカスタマイズできますか?

謝辞

この論文の質を高める貴重な助言をし、考えを共有してくれた、Brian Byrne氏、Greg Hodgkinson氏、およびAlessandro Di Bari氏に著者は感謝しています。

リソース

• InfoQインタビュー - MDDとSOAの関わりについて:  http://www.infoq.com/articles/bertrand-portier-on-mdd-soma
• Using model-driven development and pattern-based engineering to design SOA series on devWorks(リンク)
• アセットベース開発での戦略的再利用: http://www.redbooks.ibm.com/abstracts/sg247529.html
• Rational SDPを使用したSOAソリューションの構築:  http://www.redbooks.ibm.com/abstracts/sg247356.html?Open
• SOAにおけるサービスとアーキテクチャの基盤の考察 – パート1: アーキテクチャと抽象化レベルを使用した、より良いSOAの作成: http://www.ibm.com/developerworks/library/ar-archserv1/
• パターンのエピファニー! パターン関連の自動化技術に関する実践的な調査、EclipseCon 2008: http://www.eclipsecon.org/2008/?page=sub/&id=432
• モデル駆動開発（MDD）と関連するアプローチの考察: ドメイン特有のモデリングをモデル駆動アーキテクチャに適用: http://www.ibm.com/developerworks/library/ar-mdd4/
• Eclipseモデリングフレームワーク: http://www.eclipse.org/modeling/emf/
• Eclipseプロセスフレームワーク: http://www.eclipse.org/epf/
• SOA、BPM、およびEAを利用した戦略的なビジネスとITの連携: http://www.ibm.com/developerworks/websphere/bpmjournal/0812_jensen/0812_jensen.html
• パターン: IBM Rational Software Architectを使用したモデル駆動開発: http://www.redbooks.ibm.com/abstracts/sg247105.html?Open

[1] 資金調達モデルや戦略的イニシアチブなどの組織的な側面を考察するのではないことに注意してください。我々は、MDDの導入を試みるときに皆様が直面した可能性のある課題に対処し、これらの課題を克服できるMDDの最新の進歩情報を提供します。
[2] このリストは決してSOAの抽象化レベルの公式の、または、完全なリストではないことに注意してください。ここでは、コード（実装）以外の抽象化レベルの例を示すために使用されています。
[3] 2つの抽象化レベル、すなわち高レベルの設計と詳細な設計を見ることが一般的であるということに注意してください。再び、制約と目標に基づいて選択するのはあなたです。これはほんの一例です。
[4] Scott Schneider氏とRandy Lexvold氏、パターンのエピファニー! パターン関連の自動化技術に関する実践的な調査、EclipseCon 2008

原文はこちらです：http://www.infoq.com/articles/mdd-misperceptions-challenges