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

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

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

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

尾島：技術的には可能です。これには2つの方法があります。1つは、.NET Frameworkよりも大幅に簡単なラッパーを開発する手段です。汎用のアプリケーション・フレームワークである.NET Frameworkがカバーする範囲は非常に広範ですが、そのうちビジネス・アプリケーションで使う範囲は限られます。そこで、あらかじめ使用する範囲のものだけしか利用できないような環境を作ってしまうのです。しかしこの方法では、開発範囲を狭めてしまうので、それによってどれだけ見返りがあるかは疑問です。もう1つは、.NET Frameworkよりも分かりやすくコーディングしやすいAPIを作成する方法ですが、これはあり得ないでしょう。百歩譲ってそのようなAPIが開発できたとしても、マイクロソフトの優れた開発ツールはそれらをサポートしません。いずれにせよ、実質的には不可能だということです。

猪股：APIではなく、CASEツールのようなものなら、適用範囲を絞ることで、マイクロソフト製品よりも使い勝手のよいものは開発可能ですし、実際にそうした製品もあります。例えば、データ・アクセスの部分だけに特化して、与えられたデータを表示し、データベースに格納するというだけなら、かなり生産性の高いCASEツールを開発できます。ユニシスでもそのような製品を提供しています。

猪股：実装の再利用は困難ですが、アーキテクチャのような構造を再利用していくことは可能です。ユニシスでは、アーキテクチャ中心主義のアプリケーション開発を推奨しています。

尾島：ここでいう「アーキテクチャ」とは、Rational社が提唱するRational Unified Process（RUP）でいうところの「アーキテクチャ」です。簡単にいえば、情報システム全体の論理構造をどのように分離すればよいのかを明確化するコンセプトです。アーキテクチャ中心主義をコンセプトとして、アプリケーション開発を支援するのが、ユニシスが提供している「LUCINAテクニカルドキュメント for .NET」（以下LUCINA）と呼ばれるものです。

尾島：広義の意味では、フレームワークと呼んでもおかしくないものだろうと思います。しかしこれまでお話ししてきたとおり、安易にフレームワークという言葉を使うとお客さまに誤解を与える可能性があるので、このような名前にしました。分かりにくいという点は私たちも同意見なのですが、技術者の良心のようなものだと考えてご容赦ください。

尾島：LUCINAではまず、フロントエンドとバックエンドを分離して考えます。そしてバックエンドをビジネスロジックとデータ・アクセスとデータ層に分けます。さらに、ビジネスロジックの中にコントロールとビジネスという論理的な構造を作り、その論理構造をどのような実装技術を使って作成していけばよいのかを定義しています。例えばコントロールやビジネスであれば、COM＋コンポーネントを作成する、データ・アクセスであればVisual Studioで自動生成させるなどです。実装技術の選択肢は基本的に1つですが、別のオプションが存在する場合にはそれらも提供します。また、これらの概念で実際に作成されたソース・コードも併せて提供します。さらにLUCINAでは、こうしたシステムの構造を規定するアーキテクチャに加え、それをどのように開発するかというプロセスまでを規定します。開発プロセスには複数の道筋があるので、実際にどのような手順で開発するのが妥当か、プロセスの重要ポイントはどこかなどを踏まえて、プロセス・フレームワークを定めています。

尾島：繰り返しになりますが、この部分に狭義のフレームワークは適用できません。そこでLUCINAでは、一方にアーキテクチャを適用し、他方に実装に使えるコンポーネント群を適用して、システムの要件に合わせてその間を詰めていくというアプローチをとります。

尾島：あまり依存しないと考えます。例えばマイクロソフトは、.NETテクノロジをベースとするアプリケーション開発のアーキテクチャ・ガイドとして、「Application Architecture for .NET: Designing Applications and Services」というドキュメントを提供しています。これは特定の業務を意識しない一般的なアプリケーション開発について述べたものですが、このドキュメントのガイドラインに従って、業務によらず70〜80％程度は開発が可能でしょう。ただし、アーキテクチャの方は業務にはあまり影響を受けないのですが、開発プロセスは業務によって大きく違ってきます。例えば、金融向けのシステムと、流通向けのシステムでは、開発プロセスのポイントや手順などがまったく異なります。このためLUCINAでは、開発プロセス部分については、柔軟性を持たせて入れ替えができるようにしています。

尾島：実装基盤が異なるので、まったく違うものです。Java版とは別に新規に作成しました。JavaバージョンのLUCINAと.NETバージョンのLUCINAでは、定義されるアーキテクチャに大きな違いがあります。加えて、Javaバージョンでは、J2EEがプリミティブなインフラの機能しか提供しないので、独自にフレームワーク製品を提供しています。一方、.NETには.NET Frameworkがあるので、独自のフレームワークは提供していません。ただし、.NETとJavaのアプリケーションが企業全体の視点で柔軟に整合性を持って結合できるよう、互いを意識しています。

尾島：速く、低コストで開発したいというなら、.NETの方が圧倒的に有利だと思います。理由は、.NET Frameworkとして標準で提供されているAPIのレベルが高いので、独自に実装が必要となる部分が少ないと考えられるからです。

尾島：当たり前ですが、アプリケーションがマイクロソフト・テクノロジに依存してしまうことでしょうか。もっとも、Javaバージョンにしたところで、程度の違いはあっても同じような問題は発生するので、.NET独自の問題とはいえませんが。

尾島：LUCINAでは、過去の資産継承を重視しています。この点については、エンタープライズ・アーキテクチャ（EA）の4階層に当てはめてシステム開発を進めます。エンタープライズ・アーキテクチャでは、情報システムを上位から「ビジネス」「データ」「アプリケーション」「テクノロジ」と4階層に分類します。そしてこれらそれぞれのレイヤについて現状（as is）から将来（to be）のあるべき姿を明らかにし、そのうえで、現状から将来へ移行するプランを練ります。企業によって考え方に違いがありますが、このエンタープライズ・アーキテクチャによって、ビジネス全体としてのアーキテクチャや、アプリケーションをどのような標準で開発していくかを決定することになります。具体的にいえば、現時点はVisual Basic 6を利用したクライアント／サーバ・システムだが、将来的には.NET Frameworkを利用したコンポーネント指向のアーキテクチャを目指すなどです。しかしこれまでの経験から、ユニシスでは、現実のシステム開発を円滑に進めるために、エンタープライズ・アーキテクチャの4階層における「アプリケーション」を、さらに企業全体を受け止めるような「エンタープライズ」と「アプリケーション」の2層に分離しています。

エンタープライズ・アーキテクチャの4階層

尾島：ベンダによるシステム・インテグレーションでは、自社製品を使うという理由から、テクノロジの部分を中心に考えることになるでしょうが、ユニシスでは「テクノロジ」は統一する必要はないという立場を取っています。

尾島：エンタープライズ・アーキテクチャの4階層モデルでは、状態は常に変化するという前提で、常にあるべき将来の姿を追求していきます。例えば、去年考えていた5年後のあるべき姿と、今年考える4年後のあるべき姿は違うわけです。これを毎年更新していき、ゴールに向かうための道筋も変えていくというのがエンタープライズ・アーキテクチャです。それをうまく進めるためのプラン作成が最も重要になります。優先順位が高く効果も高いものから順に実行していくというプランを立て、次にそのプランを受け止められるだけのアプリケーション・アーキテクチャやテクノロジ・アーキテクチャを検討します。マイクロソフトは、アプリケーションやツールのための優れたテクノロジを作り出していますが、それだけではビジネス・システムとして受け止められるアプリケーション・アーキテクチャは提供できません。そこでユニシスでは、LUCINA for .NETという形でその部分を拡張し追加しています。

尾島：少々難しいですし、現時点では英語版しかありませんが、米Microsoftが提供している“Application Architecture for .NET: Designing Applications and Services”（前出）が参考になるでしょう。

猪股：ただし、入門者にとっては敷居が高いかもしれません。そこでInsider.NETにおいて、このドキュメントのエキスとなる部分を解説する連載を始めました。ぜひとも読んでください。

尾島：.NETではないのですが、SunがJava環境向けに提供しているJ2EE Blue Printは、技術論から始まっていて非常に分かりやすかったです。

尾島：市販のフレームワーク製品が提供する機能が、.NET Frameworkの中ですでに提供されているものかどうかで見分けるとよいと考えます。例えば、市販フレームワーク製品の特徴が「分散トランザクション機能」だとすれば、それは標準のCOM+で可能です。「Webフロントエンドの構築が容易」といわれれば、それはASP.NETで可能です。「分散オブジェクト機能」といわれれば、それは.NETリモーティングやCOM＋で可能です。このように、.NET Frameworkが本来備えている機能しかないのなら、その製品は狭義のフレームワークとしては新しいものを何も追加しておらず、.NET Frameworkと同じものを表面上だけラップしたものである可能性があります。それでも使いやすければよいのですが、たいていは.NET Frameworkにあるものの方が使いやすく、マイクロソフトの強力なツール・サポートも受けられるなどのメリットがあります。

猪股：特定の領域に特化したものなら、狭義のフレームワークとしても有効なものがあると思います。例えば.NET Frameworkは、ビジネスのワークフローまではカバーしていません。ですからワークフロー分野に特化したものなら、優れた狭義のフレームワーク製品もあり得るでしょう。

尾島：例えば、CASEツールや、ミドルウェア・パッケージ製品なら、単純に開発支援ツールやジェネレータなどの完成度を評価するしか方法はありません。他方、開発方法を提唱する製品なら、どれだけオリジナリティがあるかで評価します。多くの場合、ベースになるのはRational Unified Processだと思いますが、それをそのままではなく、ベンダやインテグレータに蓄積された過去のノウハウなどを基に、独自に拡張した部分がどれだけ優れているかに注目しましょう。単純にRational Unified Processを焼き直しただけのようなものは、あまりお勧めできません。

尾島：そうですね。しかしクラス・ライブラリの隅々まで精通しなくても、概要を正しく把握していれば判断はできると思います。