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

日本ユニシス株式会社
サービスビジネス統括部 .NETビジネスディベロップメント チーフSE
尾島良司

日本ユニシス株式会社
サービスビジネス統括部 .NETビジネスディベロップメント
猪股健太郎

聞き手、文責:デジタルアドバンテージ
2003/09/13

Page1 Page2

 .NET Frameworkに対応したアプリケーション・フレームワークが各社から発売されている。業務アプリケーション開発や、情報システム開発を支援するものだとされるが、各社製品とも説明はさまざまで、「アプリケーション・フレームワーク」の定義は必ずしも明確ではない。.NETテクノロジ・ベースのシステム開発において、「アプリケーション・フレームワーク」とはいったい何なのか。プログラマはこれをどのように位置付けたらよいのか。今回は、Javaテクノロジ・ベースの豊富な情報システム開発実績を持ち、最近では.NETテクノロジ・ベースのシステム開発を積極的に進める日本ユニシスの尾島氏、猪股氏のお2人に「アプリケーション・フレームワーク」の実際についてお話を伺った。同社内では、「アプリケーション・フレームワーク」という言葉を独自に厳密に定義して使っているという。インタビューの結果、世にいう「アプリケーション・フレームワーク」の意外な一面が見えてきた。

ユニシスにおける「アプリケーション・フレームワーク」の定義

―― 最近、.NET対応の「アプリケーション・フレームワーク」と銘打った製品が各社から発表されています。しかし製品の形態や適用分野、利用目的などはまちまちで、いまひとつ「アプリケーション・フレームワーク」が何を意味するのか、位置づけられない開発者も多いのではないかと思います。

 

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

 
UNISYSが考える「狭義のフレームワーク」と「広義のフレームワーク」
ユニシスでは、ユーザー・コードを呼び出すオブジェクト指向的なクラス・ライブラリを「狭義のフレームワーム」として定義し、通常はこちらを「フレームワーク」として位置付けている。

―― 「広義のフレームワーク」がカバーする範囲は大変広いですね。

 

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

Javaと.NETにおけるアプリケーション・フレームワーク比較

―― それでは、これより、ユーザー・コードを呼び出すクラス・ライブラリである「狭義のフレームワーク」を「フレームワーク」と呼ぶことにしましょう。その上で、一般論としてのアプリケーション・フレームワークの利点とは何でしょうか。

 

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

―― フレームワークがアプリケーションのアーキテクチャを強制するので、アプリケーションの再利用が容易になるという意見もあります。

 

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

―― しかし、Strutsをフレームワークとして利用することで、Webフロントエンドの開発が大幅に容易になったのは事実ですね。

 

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

 

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

Javaでは、J2EEとしてベース・インフラストラクチャのみがサポートされ、上位のアプリケーション・フレームワークに相当する部分は標準では用意されていない。これに対し.NET Frameworkは、ベース・インフラストラクチャとアプリケーション・フレームワークの双方のレイヤをカバーしている。
 
 

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

―― Javaでは標準で提供されないクラス・ライブラリがアプリケーション・フレームワークとして必要になっているだけで、.NETではそれらが.NET Frameworkとして最初から標準で提供されているということですか。

 

尾島:そうです。

アプリケーション・フレームワークとドメイン・フレームワーク

―― 前出の図には、アプリケーション・フレームワークの上位レイヤとしてドメイン・フレームワークというものがあります。これは何ですか。

 

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

―― Javaも.NETも、このドメイン・フレームワークの部分はブランクになっています。

 

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

―― それはどうしてですか。

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

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

―― 現実のビジネス(=ドメイン)は固定化できないということですね。

 

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

―― 業務アプリケーション分野では、実用的なソフトウェアの再利用などできないという意味ですか。

 

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

―― しかし、アプリケーション・フレームワークとアプリケーションの間のレイヤで、業務アプリケーション開発を支援するパッケージ製品は多数存在するように思いますが。

 

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

―― 当初は図のアプリケーション・フレームワークとドメイン・フレームワークの部分をまとめてアプリケーション・フレームワークと呼ぶのだと思っていました。

 

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

―― ドメイン・フレームワークを目指して開発された製品は本当に存在しないのですか。

 

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

 
 

 INDEX
  [Trend Interview ]
   アプリケーション・フレームワークの誤解と真実(1/2)
     アプリケーション・フレームワークの誤解と真実(2/2)
 
インデックス・ページヘ  「Trend Interview」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間