アプリケーション・フレームワークの誤解と真実

尾島：確かに分かりにくいと思います。ユニシスでは、「フレームワーク」には2種類の意味があると考えています。これらは「広義のフレームワーク」と「狭義のフレームワーク」の2つです。このうち「広義のフレームワーク」は、「アプリケーション開発を実現する枠組み」と考えます。こちらには、システム開発を支援するコンポーネント群やツール、ドキュメントをはじめ、開発の考え方や哲学などまでを幅広く含むものだと考えます。一方、「狭義のフレームワーク」は、「ユーザー・コードを呼び出すオブジェクト指向的なクラス・ライブラリ」に限定しています。

尾島：そのとおりですね。「広義のフレームワークの定義」によると何でも「フレームワーク」になってしまいます。ですから私は、「広義のフレームワーク」を「フレームワーク」という名前で定義すること自体にはあまり意味がないと考えています。「フレームワーク」と定義して意味があるのは、「狭義のフレームワーク」だと考えます。ただしこれらは、あくまでユニシスでの定義であって、世の中一般の認識と必ずしも一致しません。一般には、「広義のフレームワーク」も、「狭義のフレームワーク」も一緒くたにして、「フレームワーク」と呼んでいるケースが多いようです。

尾島：一般的には、土台となるフレームワークが提供されることで、開発者が作成すべきコード量が減り、開発生産性が向上します。また同時に、個々の開発者のスキルなどにあまり依存せず、完成品の品質が一定するという利点もあります。

尾島：それはあまり信用していません。例えば、Java向けのフレームワークとして提供され、広く利用されているJakartaプロジェクトのStrutsがあります。しかしこのStrutsが提供するのは、Webフロントエンド部分だけです。また、EJB（Enterprise Java Beans）をフレームワークと呼ぶかというと、本質的にはフレームワークではないと思います。また、EJBにはトランザクション管理用のSession Beanなどもありますが、使いづらい部分が多かったので、ユニシスではトランザクション管理や分散オブジェクト管理を実現するためのライブラリを独自に開発しました。こうした現実を考えると、フレームワークがアプリケーション全体のアーキテクチャを強制して、プログラムの再利用を進めるというのは、幻想にすぎないと感じます。

尾島：はい。しかしだからといって、Javaと.NETを同列にして、フレームワークが有効だという結論にはなりません。これを理解するには、Javaと.NETにおけるアプリケーション階層を比較してみる必要があります。

Javaと.NETにおけるアプリケーション階層比較

尾島：Javaでは、最下層のインフラストラクチャの部分にJ2EE（Java2 Enterprise Edition）が位置付けられます。Strutsは、その上位のアプリケーション・フレームワーク（狭義のフレームワーク）層でWebフロントエンドの開発を支援するものです。これに対し.NETでは、インフラストラクチャにもその上位となるアプリケーション・フレームワーク層にも.NET Frameworkが位置付けられます。例えば.NET Frameworkでは、Strutsに相当する機能を.NET Frameworkの一部であるASP.NETが提供してくれます。

尾島：そうです。

尾島：図のアプリケーション・フレームワークは、特定の業務に依存しない汎用的なフレームワークを意味しています。業務非依存の基本的な部分でアプリケーション実装を支援するものですね。これに対しドメイン・フレームワークは、特定業務に密着し、業務と不可分の関係にあるフレームワークです。こちらは、アプリケーション・フレームワークとはまったく違った条件が必要になります。

尾島：ええ。狭義のフレームワークとして、このレイヤに位置づけられるものはJava向けにも.NET向けにも存在しないと考えています。

『ソフトウェア再利用の神話』 IBMのエンジニアが記したソフトウェア再利用に関する解説書。ソフトウェア開発に関する解説書だが、プログラム・コードの例示を中心とするのではなく、あくまで読み物としてソフトウェア再利用の概念とポイント、落とし穴などについて説明している。

尾島：現実問題として、ドメイン・フレームワークに位置付けられる狭義のフレームワークを開発するのは不可能だからです。ソフトウェアの再利用に関するバイブルと私が考えている書籍に『ソフトウェア再利用の神話』（ピアソン・エデュケーション発行、ISBN4-89471-425-6）があります。業務（＝ドメイン）を完全に固定化できれば、業務アプリケーションの70〜80％は再利用可能になるはずだと説明されており、私自身もそう思います。例えば数式処理アプリケーションのMathematica（Mathematicaのホームページ）を見ていると、非常に再利用性が高い。さまざまな数式を入力すると、答えを算出してくれて、グラフのビジュアル化まで行ってくれる。しかしこれが可能なのは、数式処理という「ドメイン」が固定化されているからにほかなりません。ビジネスについても、ドメインを完全に固定化できれば、業務に依存したフレームワークを開発することは可能でしょう。

尾島：ビジネスの環境は常に変化しており、変化のスピードは衰えるどころか加速する方向にあります。ソフトウェアの再利用によって利益を得るには、少なくとも5〜10年はドメインが固定化されなければならないと考えます。ソフトウェアを再利用可能なものとして開発するには、そうでない場合に比較して3〜5倍のコストがかかるといわれます。またそれらをフレームワークとして一般化するには、5〜10倍のコスト増になるでしょう。つまり、変化の激しいビジネス・アプリケーション向けのドメイン・フレームワーク開発には、それに見合う見返りが得られないということです。

尾島：異なるドメインでは困難だということです。ビジネスのドメインは時間とともにどんどん変化するため、同じ業務分野のプロジェクトであっても、過去と現在ではドメインが異なります。またいうまでもなく、異なるプロジェクトでは、時間的な差がなくてもドメインは異なります。これらのケースでは再利用は困難です。例えば、金融業務向けに設計された顧客オブジェクトと、流通向けに設計された顧客オブジェクトは、まったく性質が違います。しかし唯一、単一のアプリケーションや単一のプロジェクト内部なら、ドメインが同じなので再利用は非常にうまくいくと思います。

尾島：ここで話題にしているのは、あくまで狭義のフレームワークとしてのドメイン・フレームワークです。例えばSAPのパッケージ（業務分野ごとに提供されるコンポーネント）などは、このレベルでのアプリケーション開発支援に成功している例でしょう。しかしSAPのパッケージは、狭義のフレームワークではありませんね。これ以外にも、システムの運用管理機能などを提供するミドルウェア製品などもこのレベルに位置付けられることがありますが、やはり私たちが考えるフレームワークではありません。CASEツールとジェネレータがこのレイヤで利用されることもありますが、これも狭義のフレームワークではない。

猪股：狭義のフレームワークを考えるときには、業務非依存の部分と、業務依存の部分を明確に分ける必要があります。そしてそう考えると、業務依存部分で、狭義のフレームワークと呼べるものは存在しないということです。しかし実際には、狭義のフレームワークのメリットを、あたかも広義のフレームワークに適用できるような誤解を与える説明を行っている製品も存在するようです。

尾島：しいていえば、マイクロソフトの「Commerce Server」はドメイン・フレームワークを目指した製品と考えられるでしょうか。しかしこれまでの実績を見る限り、成功しているとは考えにくい状況です。逆にいえば、ドメイン・フレームワークの開発はそれだけ困難だという証しかもしれません。