BPM/SOAの設計・実装アプローチ

モデル駆動開発とは

モデル駆動開発とは、自然言語を主体としたドキュメントではなく、図形言語を用いて要求仕様をモデル化（形式化）し、あいまいさを排除するソフトウエア開発方法論です。

モデル駆動開発の例として、UML（Unified Modeling Language）が、主に組み込み系のソフトウエア開発で広く利用されています。では、業務アプリケーション・システムの開発において、同様の方法論が一般的になっているでしょうか。

現実は、限定的に、詳細設計以降のごく一部でしか利用されていないのが実情です。筆者が知る限り、表向きはUMLを標準にしていると言いながら、裏では相変わらず自然言語を用いたドキュメントを中心に開発を進めているプロジェクトが多いです。

この原因は、3つあると考えます。

1. スクラッチでゼロからソフトウエアをコーディングする比率が低くなった。
2. ユーザー部門とUMLで仕様を確認することが難しい。
3. オブジェクト指向を理解できるアプリケーション側のSEがいない。

1.については、既存システムの改修や導入済のERPパッケージとのインタフェース開発など、業務システムの改善がIT部門の中心作業になっている背景があります。

2.については、ソフトウエアの製作図面を見せられても、ユーザー部門は理解できないという背景があります。ユーザー部門の業務遂行場面のどこでITを利用し、どんなメリットを得られるのか、ビジネス視点に立ったドキュメントが多く求められるからです。

3.については、1.と2.の背景が影響した結果として、ソフトウエア要求のモデル化だけがSEの職務ではない、という状況があるでしょう。

モデル駆動開発の原点を振り返る

モデル駆動型開発の発想の原点は、ジョン・A・ザックマン（John A. Zachman）が1987年に提唱した「ザックマン・フレームワーク」（図1）だと思います。

ザックマン・フレームワークでは、図1の最上位にいるプランナが発した抽象的な文脈定義が、最下位にあるプログラム・コードとしてコンピュータに実装されていく過程を、5段階に分けて、5W1Hの観点で分類しています。企業のビジネス・システムをIT化するためには、何らかの方法でこの過程を経ています。このため、ドキュメントの種類、内容も、多岐に渡ります。

1990年代には、このフレームワークを基にシステム開発支援ツールと開発方法論を統合してシステム開発作業の効率化を狙ったCASE（Computer Aided Software Engineering）の考え方が登場しました。データ・モデルとデータ・フロー・ダイアグラムを基軸に、データ・モデル駆動型開発がクライアント／サーバー開発時代の一翼を担いました。

また、近年のWebアプリケーション開発においては、その開発の複雑さが背景となって、UMLと各種プログラミング・フレームワークを統合し、ソフトウエアのコード生成を自動化する開発スタイルが一般的になっています。

しかし、ザックマン・フレームワークの全範囲をサポートできる方法論は登場していません。なぜなら、ザックマン・フレームワークは、プログラム・コードを生産する手組開発工程を、工学的に分析したにすぎないからです。この工程通りに自動化支援を行うと、検証すべき中間成果物が多くなり、多大な労力がかかってしまいます。日本でも、1990年代に、国内メインフレーム・ベンダーが集まって統合CASEツールを国策で開発し、失敗した経緯があります。

SOAとアプリケーション構造改革の動き

SOA（サービス指向アーキテクチャ）は、端的に表現すれば「企業内のアプリケーション構造改革」です。Webサービス技術をベースに開発したビジネス・サービス部品を組み立てていく、というアプリケーション生産スタイルを適用して、ソフトウエアの再利用性やアプリケーションの保守性を向上させる狙いがあります。

つまり、SOAは、従来の手組開発を極小化して、開発コストと保守コストの削減、工期短縮を図ります。ザックマン・フレームワークを借りて説明するならば、最下位のサブコントラクタのコード作成部を排除するアプローチと言えます。

このアプローチは、住宅産業に例えるならば、古典的な注文建築工法ではなく、近代的なプレハブ工法の採用と言えるでしょう。昔の大工は、ノミ、カンナで柱を削り出しましたが、今はノミ、カンナを使える大工が少なくなりました。同様に、サブコントラクタの職人芸は、サービス部品の開発企業には求められるものの、企業アプリケーション・システムの開発には不要になる時代か到来するかも知れません。