Webアプリケーションを書いていて，なぜ，本来の目的である業務処理以外にこんなにもプログラムが必要なのか，と思われたことはないだろうか。

　読者の皆さんがシステムの開発者であれば，「もっと効率よく開発できないか」と思っていらっしゃるかもしれないし，ユーザーの立場であれば「もっとコストを下げられないのか」と首をかしげていらっしゃるかもしれない。

　例えば，業務システムや会員制サイトの構築では，ユーザー認証のためのプログラム・モジュールを独自に作っているケースが多い。このアクセスはログイン済みユーザーからのものかどうかをサーバー側でチェックし，未ログインであればログイン画面へリダイレクトする，といった処理である。

　ほかにも，SQLを組み立ててデータベースに接続し，処理が終わったら忘れずにDBとの接続を解放したり，表示すべきデータを一行ずつHTMLに加工したり，iモードなどパソコン以外の端末に合わせて表示を変えたり・・・本当の目的は例えば在庫の引き当て，のような単純なものなのに，なぜこんなにプログラムは煩雑なのだろう。

WWWもJavaも“業務処理”を開発する目的で生まれたわけではない

　その理由は，もともとは別の目的のために誕生した技術を，アプリケーションの開発のために転用しているからだろう。WWWもJavaも，もともと販売管理や顧客管理，ECサイトで生じるトランザクション処理，といった“アプリケーション”を構築するための技術ではない。

　だから，業務アプリケーションを組むためにWWWやJavaを利用する際，本来の業務処理の“一つ下の層”で，冒頭の例のようないろいろなプログラムが必要になるのはやむを得ないことではある。

　もちろん出自が違うからといって不適格とは言えない。ある目的で開発された技術の利点を生かして別の目的に転用して成功した例は，コンピュータの歴史を見回してみても珍しいことではない。

　例えばUNIXは，もともとソフトウエアの研究や開発のOSだったが，現在は金融システムをはじめとする大規模業務システムで使用されている。トランザクション処理用ミドルウエアとして30年以上使われているIBMのCICSも，もともとは別の用途のために開発されたと聞いている。

　ただ，これらの製品・技術が当初の目的を超えて幅広く利用されるまでには，長期間にわたる機能拡張と実績の積み重ねがあった。現在のWWWとJavaも，競合技術に比べ優れた特性を備えていたからこそ標準となったのではあるが，いまだその出自と，応用分野の広がりとのギャップを，埋めきれてはいないように思える。

「フレームワーク」が，WWW開発の煩雑さを解決する現実解に

　なぜ今ごろ，こんな目新しくもない話をするかといえば，このところの取材で，Webアプリケーションの基本的な機能を提供する枠組み「フレームワーク」が，Webアプリケーション開発における上記の煩雑さを解決する，有効な手段であると実感したからだ。

　フレームワークという言葉の定義を厳密に語るのは難しいが，ここでは，「冒頭の認証やデータベース連携のように，多くのユーザーがシステム構築の際に共通して利用する機能を一まとめにしたソフトウエアの集合体」，と考えておいていただきたい。

　フレームワークを利用する開発者は，煩雑な処理はフレームワークにまかせ，業務ロジックの開発に集中する。これによって開発生産性の向上が期待できるわけだが，メリットはそれだけではない。認証漏れやデータのチェック漏れは，情報漏えいを招くセキュリティ・ホールにつながることもあるが，これらをフレームワーク側に受け持たせることによって，アプリケーションの品質向上も期待できる。

　多くのフレームワーク開発者は「現場で必要とされる機能を盛り込んだ」と胸を張る。基本的な構造は，米Sun Microsystemsがサーバー・サイドJavaアプリケーションのサンプルとして提供している「J2EE BluePrints」に端を発するものが多いが，認証管理やDBアクセス，HTMLの生成などの追加機能には，確かに現場のノウハウが盛り込まれている。

　住友電気工業の「楽々Framework」など，BluePrintsとは関係なく，全く独自のアイデアに基づいて開発されたフレームワークもある。具体的には，検索や更新などの定型的な処理であれば，データの属性を定義するだけで自動生成できるようにしている。

　便利な機能を作り，煩雑な部分を覆い隠そうというフレームワークの考え方自体は，別に目新しいものではない。汎用機全盛の時代からすでに似たような考え方はあった。今になって，WWWアプリケーションの分野でフレームワークの整備が盛んになった理由は，基盤となる技術（具体的にはサーバー・サイドJavaなど）が業界標準として確立し，長期的に使用できる見込みが出てきたことによる。

　フレームワークを開発する側にとっても利用する側にとっても，ノウハウやプログラム資産の継承という点で，ひとまず安心できる環境になってきたわけである。

社内整備，購入，オープン・ソース・ソフトの3つを組み合わせる

　先ほど「汎用機の時代にも似たような考え」はあった，と述べたが，一つ大きな違いをあげるとすれば，現在のフレームワークの入手法には，自社で独自に整備するという選択肢に加えて，比較的安価に購入するという選択肢が増えたことだろう。Webアプリケーション開発のために社内用に整備したフレームワークを，製品として販売している企業だけでも2ケタに上る。

　フレームワークには開発者のノウハウが詰め込まれている。フレームワークを購入することは，ノウハウを導入するという意味合いもある。イーシー・ワンの「cFramework」やエコスの「ECOSS WAVE3 FRAMEWORK」などは，ホームページから試用版をダウンロードできるので，一度，評価してみてはいかがだろうか。

　社内での整備や，購入に加えて，オープン・ソース・ソフトウエアの利用も，現実的な選択肢になった。ウルシステムズでは，自社のソフトウエア・フレームワークにオープン・ソースのフレームワークである「Struts」を組み込んでおり，400画面以上，約3000クラスの大規模システムを5カ月で開発したという実績がある。

　Strutsは，WWWサーバー「Apache」を開発したApache Software FoundationのJava開発プロジェクトである「Jakarta Project」が提供している。ただし，画面フロー制御などのフレームワークの基本機能を提供するもので，それ自体の機能は少ない。そのため，ウルシステムズでは独自の認証管理やデータ・チェック，DBアクセスなどの機能と組み合わせて使用している。

　より正確に言えば，ウルシステムズではすでにStrutsに相当する機能を自社開発していたが，フレームワークをよりオープンなものとするため，Strutsの正式リリースにあわせて，自社開発部分をStruts置き換えた，というのがこれまでの経緯である。

　オープン・ソース・ソフトウエアであれば，小規模なプロジェクトでも導入しやすいし，ウルシステムズのように必要な機能を付加していくことも，オブジェクト指向の継承機能を使えば，Struts本体には手を加えずに行える。SunのJ2EE BluePrintsもソース・コードごとダウンロードできるので参考になる。

　社内での整備，購入，オープン・ソース・ソフトウエアの利用，という3つの方法は，どれか一つを選ぶようなものではなく，必要に応じて組み合わせていくものだ。

　いかなる優れた製品・技術であっても，個々の開発現場で必要となる機能との間には，ある程度のギャップが生じることは避けられない。それを埋めるのは現場で戦っている技術者の知恵と力である。フレームワークはその結実といえる。

(高橋　信頼＝日経オープンシステム副編集長兼編集委員)

■参考文献：日経オープンシステム2002年2月号特集「フレームワークで生産性を上げる」。各フレームワーク製品の機能，応用事例，使いこなしのノウハウ，などをまとめています（概要紹介はこちら）。