モデル駆動型開発とモデル実行がコード生成とは違う9つの理由
Hans de Visser
2014年7月2日
Webアプリケーションやモバイルアプリケーションを迅速に構築、統合、展開する際には、コーディングに焦点を当てたプラットフォームから、モデル駆動型開発（MDD）に焦点を当てた高生産性プラットフォームまで、さまざまなaPaaSソリューション（サービスプラットフォームとしてのアプリケーションプラットフォーム）を検討する必要があります。
高速開発の開発者をターゲットにした高生産性aPaaSカテゴリでは、MDDの原則を何らかの形で適用するいくつかの製品があります。
この中には開発者の生産性を向上させる目的で、MDDとコード生成を組み合わせたベンダーもあります。
単純なアプリケーションにはMDDを使用し、アプリケーションのより複雑な部分にはプログラミング言語でコーディングと組み合わせて使用するというアプローチです。
ところが、このアプローチは生産性の向上をもたらしますが、MDDの本当の意味を失います。
従来のコーディング手法の生産性の問題に対処するだけでなく、MDDの真の可能性が浮かび上がってきます。ビジネス＆ITのギャップを埋めることと、アプリ提供上の問題に対処するという基本的な問題を解決することが鍵です。
アプリ配信の障害
Standish Groupによると、大規模なITプロジェクトの94％は「問題を抱えている」（予算超過、スケ
ジュールの遅れ、ユーザーの期待を満たしていない）、または失敗しています。
失敗のうちの71％が要件管理ができていないのが原因だとCIO Magazineは指摘しています。
これまでの歴史によると、開発者の生産性を向上させるだけでは、ITプロジェクトの成功に大きな影響はありません。
より良いソフトウェアをより迅速に提供するためには（特にビジネスのアイディアをカタチにするような革新的なアプリケーションは）、組織としてITとビジネスのコラボレーションを実現させる必要があります。
これには、MDDが完全なアプリ配信サイクルの一部となるアプローチが必要です。
まず要件を捉え、設計、開発、デプロイメントを繰り返します。
最新のアプリケーションプラットフォームは、アプリケーションの開発段階をサポートするだけでなく、モデル実行とMDDを組み合わせることによって、ビジネスそのものをアプリケーションにすることができます。
Mendixプラットフォームは、ビジネスとITのギャップをなくし、アプリの配信ライフサイクル全体を通してコラボレーションを促進するよう独自に設計されています。
その結果、迅速な変更サイクルをサポートするためのモデル駆動型の設計と実行、柔軟なアプリケーション監視、制御可能なアプリの拡張機能、厳しい基準を満たすセキュリティなど、いくつかの主要なアーキテクチャについて検討しなければなりません。
モデル駆動型開発（MDD）
ユーザーが積極的に参加できるレベルのアプリケーションの設計と開発にビジネスを関与させるために、モデル駆動型開発（MDD＝Model-Driven Development）アプローチの利用が増えてきています。
MDDは、ビジネスとIT、両方のステークホルダーを納得させるコミュニケーション・メカニズムを提供し、より高い品質とより成功した成果を期待できます。
また、迅速で協調的な開発を可能にする有力なアプローチ方法の1つとしても注目されています。
MDDは、データモデル、アプリケーションおよびプロセスロジック、ユーザーインターフェイスなどを定義するビジュアルモデルを使用しているため、開発者とビジネスユーザーは、労力がかからないノンプログラミングの手法でアプリケーションを迅速に構築できます。
したがって、C＃やJavaなどの従来のプログラミング言語よりも大幅に高速です。
すべてのモデリングがそのまま利用できるとは限りません
MendixのMDDアプローチは、ビジネス・ステークホルダーがグラフィカル・モデルを理解し、IT側と共同設計できるようにするところが特長です。
これは、アプリの成功と普及にとって要となります。
このコンテキストでは、モデルの適切なレベルの抽象化が重要です。
ビジネス関係者は、モデルを実際に理解し、設計に影響を与えることができるはずです。
開発者は、技術的な実装が機能するようにモデルを拡張する必要があります。
例えば、クラウドベースのデータサービスを活用するためにプロセスモデルにRESTサービス をバインドする必要があります。
このため、MendixはBPMNのような標準記法を採用してアプリケーションとプロセスロジックをモデル化しています。
これは業界で広く採用されている規格です。
独自のモデリング表記法を用いることでMDDの抽象度レベルが低すぎる場合のリスクとしては、基本的には開発者の効率のみをサポートし、データベースへのアプローチであるSQLやトランザクションスコープの定義など幅広い知識を含む、深い技術的なスキルが必要となります。
モデルの実行：モデル化したものが動作します
重要な特徴として、Mendixプラットフォームはランタイムでモデルを実行します。
アプリケーションを実行するためにアプリケーションモデルからコード（Javaや.NETなど）を生成するアプローチとは対照的です。
コード生成の問題は、柔軟性がなく、保守性の問題が発生し、セキュリティ、スケーラビリティ、およびパフォーマンス要件をカバーするために手間がかかることです。
モデル駆動型の9つのメリット
- すばやくモデル変更： モデルの変更には、明示的な再生成、再構築、再テスト、および再デプロイのステップは必要ありません。これにより、処理時間が大幅に短縮されます。
- 制御された拡張機能： モデル内のAPI層を介してモデルがカスタムコードを認識しているので、カスタムコードによるモデルの拡張はよりエレガントに制御されます。
- クラウドへのデプロイの柔軟性： ランタイム環境（Mendix Business Serverなど）は、インフラストラクチャの上に追加のレイヤーを提供します。下にあるものはすべて抽象化され、それはPaaSの本質です。Mendixはクラウド向けに構築されています。
- 柔軟な移植性： Mendix Business Serverのようなランタイム環境を複数のプラットフォーム（複数のOS、 複数のクラウドプラットフォーム）に移植することが簡単です。
- ワンクリックデプロイ： デプロイメントのためには、ランタイム・サーバーを起動してその中にモデルを入れるだけです。Mendixは1クリックデプロイでこのプロセスを自動化します。
- モニタリングの柔軟性： アプリケーションのモニタリングは、生成されたコードに必要なモニタパラメータを事前に定義するよりも、より動的かつ柔軟に設定できます。
- 更新が容易： ランタイムエンジンに変更を適用し、同じモデルで再起動する方が簡単です。更新されたジェネレータを使用してコードを再度生成する必要はありません。
- 高い安全性： モデルは（クラウド）環境でのみアップロードする必要があります。ファイルシステムやその他のシステムリソースにアクセスする必要はありません。ランタイム・サーバーのコードだけがシステム・ライブラリーにアクセスできます。開発者は、モデルのアクセス制御を構成する以外のセキュリティについて考える必要はありません。
- 実行時に分析する： モデルは実行時に利用できるため、実行時にモデルをデバッグすることができます（モデルレベルでブレークポイントを追加するなど）。したがって、ドメインエキスパートは、このデバッグに基づいて、独自のモデルをデバッグし、アプリケーションの機能的な動作をデバッグすることができます。
アプリケーションの総所有コスト（TCO）のかなりの部分が最初のリリース後にかかることを考慮すると、MendixのMDDとモデル実行へのアプローチは、大幅な節約となり、アプリケーション変更サイクルの機敏性と柔軟性が向上します。
有名な業界アナリストは、モデル実行の利点を認識しています。
以下は、古典的なコーディングからメタデータ（モデル）の実行までの開発ツール/プラットフォームを進化に関するForresterの見解です。
「新しい生産性プラットフォームのほとんどは、メタデータの実行と呼ばれる基盤技術を採用しており、アプリケーションの設計と保守に大きな柔軟性を提供しています。簡単に言えば、ツールはコードではなく定義を出力し、定義はプラットフォームによって解釈され、実行中のアプリケーションが作成されます。メタデータ定義は、それ以前の生産性手法であるコード生成よりはるかに柔軟性があります。」
Forrester Research、新しい生産性プラットフォーム – AD＆D危機へのあなたのソリューション
ビジネスとITのコラボレーション
MDDとモデル実行のメリットを見てみると、ビジネスの利益にどのように変換されているでしょうか。
基本的に、このアプローチはビジネスとITを一体化させるのに役立つと考えています。
生産性が低いのではなく、ビジネスとITのコラボレーションが不足しているために、多くのITプロジェクトが失敗しています。
私たちの焦点は、技術側ではない人々が実際に理解した共同設計モデルを通じて、設計と開発のプロセスにビジネスステークホルダーを積極的に関与させることです。
コラボレーションでは、ライフサイクルのあらゆる段階で、反復性の高いアプローチと即時のフィードバックメカニズムも必要となります。
より優れたアプリケーションをより速く構築するためには、これが不可欠です。
Mendixは、プラットフォーム内で完全なアプリ配信ライフサイクルをサポートするサービスプロバイダとして唯一のプラットフォームです。
コード生成の「ノー・ロックイン」神話
より古典的なアプローチで、モデルの実行に向けて一歩踏み出したことがないベンダーは、ランタイムにおけるモデルの実行がベンダーのロックインにつながるとあなたに思わせたいと思うでしょう。
問題の真実は、最も原始的な技術を除いて、すべてのアプリケーションプラットフォームにロックインの側面があることです。
アプリケーション開発チームは、技術選択を行い、その技術に対するリソースとノウハウをコミットしています。
これにより、一定期間、その技術の使用にチームをロックすることができます。
たとえば、生成されたコードは、ベンダーがプラットフォームサービス用に追加する複数のライブラリに依存しています。
これらのサービスから移行したい場合、開発者が実際に「開発した」アプリケーションではなく、所有権を取得するアプリケーションを本当に維持して拡張できますか？
そして、サポートプラットフォームなしでセキュリティ、スケーラビリティ、パフォーマンス、モニタリングなどのアプリケーションの非機能的な側面について生成されたコードをどのように扱いますか？
あなたのコードにアクセスするだけでは、ロックインを回避するための救済策ではありません。
ブラックボックスアプリケーションに触れることはないでしょう。
その観点からは、ベンダーがオープンスタンダードを採用することがより適切であるため、移行が容易になり、ロックインがソースで処理されます。
たとえば、Mendixは次のことを行います。
- パブリッククラウド、プライベートクラウド、およびパブリッククラウドインフラストラクチャプロバイダの複数のオプションを含むオンプレミス展開の選択の自由を顧客に提供します。
- データモデルの透明性を含むデータの顧客所有を保証します。
- 互換性のためのオープンスタンダードの採用に重点を置いています。たとえば、エンティティとその関係を定義するドメインモデルはUMLに基づいており、XSDとしてインポートおよびエクスポートできます。プロセスおよびアプリケーション・ロジックが定義されているマイクロフローは、BPMNフローとして保管されます。UIモデルはCSS3とHTML5に基づいています。
- 固有のドキュメントを提供します。Mendixは、要件の取得やユーザーのストーリーとデザインの成果物のリンクなど、アプリの配信ライフサイクル全体をサポートしているため、Mendixで開発されたアプリケーションにはドキュメントが組み込まれており、構造的観点から完全に透過的です。モデルはアプリケーションなので、定義上、ドキュメントは期限切れになることはありません。
顧客がMendixから離れたければ、モデルを文書化して設計成果物をエクスポートする以外に、再プラットフォーム化の出発点はありません。
これらの設計成果物は完全で正確で最新のものであることが保証されています。
結論
コード生成にはメリットがありますが、それは企業を何十年も悩ませてきた基本的なアプリケーションの課題に対処することはなく、プログラマーの生産性向上だけを提供する従来のアプローチです。
モデルの実行は、コード生成に取って代わるものであり、アプリケーション配信ライフサイクル全体を通じてビジネスに積極的に関わるアプリケーションを構築および展開する全く新しい方法です。
モデルがアプリケーションになる場合、企業は技術的な詳細に悩まされることなく、ビジネスの問題解決に集中できます。その結果、市場投入までの時間の短縮、ビジネスの俊敏性の向上、ビジネスへの即時かつ持続的なインパクトがもたらされます。
Mendixは、モデルが常にアプリケーションであるという原則に基づいて根底から設計されています。
Mendixの力を探る最良の方法は、無料のCommunity Editionにサインアップして使い始めることです。
※このコラムはMendix社が作成してビルドシステムが翻訳したものです。
