Webの黎明と商用インターネットの始まり

1989年にスイスのCERNに在籍していたティム・バーナード・リー（彼自身はイギリス人である）は、ネットワークを通じて互いに連携した文書に関するプロジェクトを提案した。このプロジェクトがWorld Wide Web――マークアップ言語のHTML、転送プロトコルのHTTP、名前指定のURI―（以下ではWWWと略す）の始まりである。そして1990年クリスマス、NeXTコンピュータ上にObjective-Cでプログラムされた最初のサーバーhttpdとクライアントWorldWideWebが完成した。この1990年という年はまた、ARPANETの終了の年であり、一方でワールドコムオンラインが一般ユーザーにダイアルアップサービスの提供を開始した年でもある。1989年のインターネット上での商業用電子メールの解禁と共に、まさにインターネット時代の始まりと言えよう。 リーが考えたWWWは以下の言葉に示されている。

「it was designed to allow people to work together by combining their knowledge in a web of hypertext documents（人々がハイパーテキストドキュメント――相互リンクされた文書――のウェブの中に知識をまとめることで協働できるように設計された）」Longer Biography

この言葉をあらためて現在の目線で読み返すと、現在進行形で起きているWeb 2.0という潮流は、ティム・バーナード・リーのオリジナルなWeb 1.0へのルネッサンス的な要素があることに気付くだろう。

だが、Web 2.0（すなわち現在）へ進む前に、このオリジナルのWWWがどのような変化を遂げて来たか、あらためて振り返ってみよう。

もう一度、冒頭の1990年にティム・バーナード・リーが最初のWWWをプログラムした時のことを思い起こしてみよう。彼が利用していたのがNeXTだという点は実に象徴的だ。NeXTはアップル社を追われたスティーブ・ジョブズが産み出したウィンドウシステムを持ち真のマルチタスクで動くUnix系のワークステーションである。NeXT自身はそれほど強い影響力を市場へ与えることはできなかったが、その兄弟とも言えるコンピュータ群が企業へ一斉に導入された時期と重なるからだ。

1つはUnixサーバー。ダウンサイジングという言葉と共にメインフレームやミニコン／オフコンをリプレースしていくことになる（この流れは1980年台中頃から始まっている）。

そしてももう1つはWindowsパソコン。Windows 3.0（1990ただし日本では1991）と続くWindows 3.1（1992ただし日本では1993）は、その利用のしやすさにより急速に企業内に導入されていった。

この2つの組み合わせは、従来のメインフレームとダム端末の替わりにクライアント／サーバシステムという名前でまたたく間に企業システムを変えていった。

なお、IBMが創業以来の初めて赤字計上（17億ドル）したのが1991年だということもこの時期を象徴する出来事である。

が、この時、より重要な変化が企業システムのインフラとしてもたらされたことに注目したい。メインフレームからクライアントサーバへの移行によるインフラ上の最も顕著な変化はネットワークにあった。従来メインフレームにぶら下がる形で配置されていたダム端末を、各自のデスクトップのクライアントPCによって置き換えるためにLANが導入されることになったからだ。なおこの時期に利用されていたプロトコルは必ずしもTCP／IPだけというわけではなく、特にPCだけで構築されているような場合にはNetBEUIやIPXなどの比重が高かったように思われる。

このようにして、1993年頃にはUnixサーバ、Windows PC、LANといったインフラとVisual Basicによるクライアントアプリケーション、サーバー上のOracle、サイベースといったRDBMS、TUXEDOなどのOLTPモニターを利用したサーバーアプリケーションといったクライアントサーバコンピューティング環境が実現した。ちなみに、IBM中興の祖のルイス・ガースナーが会長兼CEOに就任したのも1993年である。

1991年以降、ティム・バーナード・リーはWWWをオープンな状態で公知していった。これにより、プトロコルのHTTP、文書記述のHTML、文書位置指定のURIはインターネットで共有される重要な知的資産として広く利用されることになり、クライアント、サーバー共にオリジナルな実装が出現することになった。

この流れの中で、1993年NCSA Mosaicブラウザーが登場し、1994年にはNCSAからスピンオフしたマーク・アンドリーセンらによってネットスケープ社が設立されNetscapeブラウザーが公表された。

1993年にはサーバー側にも大きな変化があった。それは同じくNCSAがリリースしたNCSA HTTPdだ。NCSA HTTPdは、単に存在するファイルをクライアントへ送るだけではなく動的なコンテンツを生成する機能を2種類実装していた。1つをCGI（Common Gateway Interface）と呼び、外部のプログラムを実行して出力結果をクライアントへ送るアプリケーションサーバー機能である。もう1つはSSI（Server Side Include）であり、HTML上に決められたフォーマットで記述したコメントをサーバーが出力時に外部のコマンドを実行したりして埋め込む機能である。

NCSA HTTPdをもってWebアプリケーションの嚆矢とするのが妥当であろう。





CGIとSSIはどちらも現在も利用されている機能である。特にLAMP（Linux + Apache + MySQL + PHP／Perl）またはLAPP（Linux ＋ Apache ＋ PostgreSQL ＋ PHP／Perl）と呼称されるオープンソースソフトウェアを利用するシステム構築ではこれらの機能を抜きに語ることはできない。

また、JavaのようにWebサーバーとアプリケーションが一体化しているシステムにおいてもCGI的な機能（Java Servlet）とSSI的な機能（JavaServer Page）の両方がサポートされていることは、NCSA HTTPdのアプリケーションインターフェイス設計の良さを物語っていると言えよう。

1994年8月11日にニューハンプシャー州ナシュアに設立されたNetMarketというオンライン小売店が世界最初のEコマースサイトと言われている。この説が本当かどうかは議論が分かれる点があるようだが、Eコマースが1994年の夏頃から始まったということでは意見が一致しているようである。

しかし、実際にEコマースが本格化するには乗り越えなければならない壁があった。それはセキュリティである。インターネットは支払情報を交換するのにはあまりにもオープンだったからである。Eコマースのブレークスルーは、1995年にネットスケープがブラウザーにSSL（Secure Sockets Layer）を搭載したことによって起こった。マイクロソフトもIEでこれに追随したため、インターネット上の商取引にSSLを利用することがデファクトスタンダードとなった。

なお、1995年はAmazon.comの創業の年でもある。

1995年

1995年は企業システムとインターネットの両者にとって大きなインパクトがもたらされた年である。

具体的には、Windows95、Apache、Java、JavaScript、PHPの登場である。

Windows95は言うまでもなくマイクロソフト社のコンシューマ用OSとしては初めて32ビット空間と横取り制御による完全なマルチタスクを実装したOSである。Windows95のインパクトは、あらかじめTCP／IPプロトコルスタックが搭載されていたことと、32ビット仮想デバイスドライバの採用によりWindows3.xでは避けようがなかったドライバによるメモリコンフリクト障害が減少したことでインターネットの利用が飛躍的に簡単になったことである。

サーバーに目を向けるとWebサーバーのApache 0.2の登場が同じく1995年（こちらは3月と早い）である。NCSA HTTPdにパッチを当てた（A patch）という洒落から命名されたと言われる(追記：http://www.apache.org/foundation/faq.html#name ではネイティブアメリカンのアパッチ族に対する敬意から採用されたとしている)Apacheは、ブラウザーでネットスケープが果たしたようなNCSA離れをWebサーバーで巻き起こした。ただし、ネットスケープと異なるのはApacheがNCSA HTTPdの運用に困った全米のネットワーク管理者たちの連合のような形式で運用が開始されたことである。このため、Apacheはオープンソースソフトウェアの管理母体として運用されて行くことになった。

Apacheのインパクトはある意味においてはWindows95より大きいかも知れない。なぜならばApacheは単にインターネットに対する影響だけではなくその後のオープンソースソフトウェアの展開にも大きく寄与しているからである。クライアントに関しては企業システム、インターネットともにマイクロソフト社のOSを搭載したPCが主流となったのに対し、サーバーについてはBSDやLinuxなどのオープンソースシステムが一定の割合を占めている理由の1つに、最も利用されているWebサーバーのApacheがオープンソースソフトウェアであり実行のためのライセンスフィーがかからないことや、移植性の高さのためにサーバーOSを問わないということが挙げられるだろう。ちなみにThe Internet Operating System Counterの1999年4月の調査では、インターネット上のホストの44％がLinuxとBSDの2つのオープンなシステムで、続くWindows95/98/NTが全体の24.5%を占めている。これに対して同年3月のWebサーバーアプリケ

!<%7%g%s$N%7%'%"$O[[Netcraftによれば|http://news.netcraft.com/archives/web_server_survey.html]]Apacheが約60%、Microsoftが約25%である。MicrosoftのシェアがOSとWebサーバーでほぼ等しいのに対し、Apacheのシェアの大きさはいかにUnix系のOSでApacheが利用されているかを物語っていると言えよう。

一方、サンマイクロシステムズがそれまでセットトップボックス用に開発していたプログラミング言語とその実行環境を、Javaと命名して公表したのも1995年である。Javaの特徴はOS非依存の実行コード形式と、ネットワーク上から取得しても安全に実行するためのセキュリティ機構にある。特にOS非依存という点がその後のサーバー上での展開に有利に働くことになったと考えられるが、この時点ではPCの能力不足やネットワークの速度不足により十全な働きをすることができなかった。このためJavaが特に重視されるようになったのは、プロプライエタリ路線からオープンシステムへの移行中のIBMが、Javaを全面的に取り入れるようになった1997年以降と考えられる。以降、J2EEと呼ばれるサーバーアプリケーション用の共通仕様が制定されたこともあり、企業システムにおけるWebアプリケーション開発の主流言語の位置を占めるに至ることになる。

JavaScriptはネットスケープ社がブラウザー上のコンテンツを動的に制御するために開発したプログラミング言語である。元々はLiveScriptという名称だったがJavaの人気に便乗してJavaScriptと途中で名称変更したものである。JavaScriptは名前を借りたJavaと同様に当初の想定とは異なる分野で重要な役割を持つことになった。それはネットスケープ社が開発したWebサーバーのアプリケーション記述言語としての利用である。実際にはネットスケープ社のWebサーバーのシェアは1995年から1996年にかけて約20％まで占めたもののその後急速に減少したためそのものとしてのインパクトは無かったと言えるかも知れないが、

クライアントコンピュータ用の簡易言語によって

Webサーバー内で直接Webアプリケーションを実行可能

という2つ特徴を持つアプリケーションモデル（サーバーサイドスクリプティング）は、1997年にWindows NT Option Packで提供されたマイクロソフトのIIS 3.0 とASPに影響を与えたと考えるほうが自然であろう。いずれにせよホームページにちょっとしたアクセントを付けるためにエンドユーザーでもプログラミング可能な程度の簡易さと、CGIのように外部プログラムを実行しなくてもWebサーバーが直接実行できる実行効率の高さという、サーバーサイドスクリプティングが持つ2つの特徴は企業システムをWebアプリケーションとして実装するための大きなモチベーションとなったと言えよう。

そしてPHPの登場である。PHPはSSIのようにHTMLへプログラムを埋め込む形式のプログラミング言語である。それまでWebアプリケーションの開発にはテキスト処理に向いていて高速で何でもできるという点からPerlを利用したCGIが主流だったのに対し、HTMLの中にプログラムを埋め込むというWebアプリケーションの開発に特化したプログラミング言語の出現は、静的なコンテンツの中に動的な処理もある――たとえば多数の静的な文書の中に数箇所SSIによるカウンターが埋め込まれ、1つのCGIによる掲示板があるというようなインターネットのあり方に対して、サイトのほとんどを動的なWebアプリケーションによって構築するという時代への転換の原動力なったと言っても過言ではないだろう。なお、1995年にリリースされたPHPはPHP／FI（Personal Home Page Tools／Form Interpreter）と呼ばれるパーソナルユースに限定されたバージョンであった。実際にPHPが飛躍的に利用されるようになったのは1997年にリリースされたPHP3（PHP

'Hypertext Preprocessor）からである。PHP3はPHP／FIとの上位互換性を保ちながら、データベースへのアクセス機構の組み込みやモジュールによる拡張性の確保、そしてライセンスの見直しなどを行い、完全に作り直されたバージョンである。なお、現在PHPは、オープンソースソフトウェアとしての状態を維持しながらPHP3の開発者が創業したゼンド社によってサポートされている。

Webアプリケーション環境の充実

NCSA HTTPdに実装されたCGIとSSIは、いずれもWebサーバーとアプリケーションのインターフェイスである。Apacheの占めるシェアの高さからわかるように、インターネットの多くのホストで稼動するWebアプリケーションはこれらの機構を利用している。

しかしCGIにはWebサーバーとWebアプリケーションを異なるプロセスとして実行しなければならないという制約がある。プロセスの生成と消滅はどちらもシステムにとって負荷がかかる処理のため、個々のWebアプリケーション実行にはオーバーヘッドとなり、またスケーラビリティを低く抑えるインパクトでもある。それだけではなく、クライアントからの1回のリクエストの都度プロセスが新たに生成されるということは、セッション管理のための考慮が特別に必要になるということでもある。

したがって、CGIが広く普及した1996年以降のWebアプリケーション環境で特に重視された機能は、

プロセスを新たに生成せずにWebアプリケーションを実行できるようにすることによる実行効率の向上 セッション管理の複雑さを個々のアプリケーションが意識せずに済むようにするための機構の提供

の2点に対するものである。

Apache

Apacheの場合、モジュールと呼ばれる独立したライブラリを直接呼び出す機構が用意されている。そのため、CGIで外部プログラムを呼び出す代わりに、あらかじめプログラミング言語とその実行環境をモジュールとしてApacheのプロセス内に組み込む方法を採用することでプロセス実行のオーバーヘッドを解消できる。このため、CGIで利用されるPHPやPerlなどはMOD_PHPやMOD_PERLといったモジュールを提供している。言い方を変えるとモジュールを利用することでPHPやPerlによってサーバーサイドスクリプティングが可能となるということである。ただしセッション管理のための機構はプログラミング言語とその実行環境側で用意することになるため、開発性の良さは個々のプログラミング言語のセッション管理ライブラリに依存することになる。たとえばPHPについて言えば、PHP4以降に洗練されたセッション管理機構を組み込んだことにより、Webアプリケーション開発環境としての磐石の地位を築いている。

IIS

マイクロソフトは、比較的早い時期からCGIの実行効率の悪さという問題点に対するソリューションを提供している。これは、Windows NTが当初からスレッドをサポートしていたことと無縁ではあるまい。このため、CGIのように外部プロセスを実行するのではなく、IIS内のスレッドでWebアプリケーションを実行するように設計することが自然だったと考えられるからである。

1996年のIIS2.0（Windows NT4.0に搭載）は、ISAPIと呼ばれるAPIを提供することで、人気があったVisual C++のMFCと呼ばれるクラスライブラリを利用したマルチスレッド用Webアプリケーションの開発／実行環境を提供した。しかし、C++のプログラミングの難しさやマルチスレッドアプリケーションのデバッグのしにくさなどの複数の要因からそれほど広く成功したとは言えない。

マイクロソフトのIISが企業システムのWebアプリケーションプラットフォームとして支持を受けることになるのは、1997年に発表されたNT Option packからである。このWindows NT4に対するアドインに含まれているIIS 3.0にはASP（Active Server Page）と呼ばれるISAPIアプリケーションが搭載されていた。IIS2.0の頃のISAPIアプリケーションをユーザーに開発させる方法から、ユーザーが開発したサーバーサイドスクリプトを実行するISAPIアプリケーションをマイクロソフトが用意するという構造である。

ASPは、VBScriptまたはJScript（マイクロソフト社のJavaScript実装）のいずれかを利用した埋め込みHTMLの実行エンジンである。この場合、セッション管理のための機構はスクリプトから操作可能なオブジェクトの形式でプログラムに提供されている。また、データベースと簡単にインターフェイスするためのADO（Active Data Object）と呼ばれるオブジェクトも同時に提供された。

ここまででお気づきのように、PHPとASPには共通点がある。それは、

埋め込みHTML

サーバーサイドスクリプトとして実行可能

データベースへの容易なアクセス手段

組み込みセッション管理機構

である。

本節の最初に、Webアプリケーション環境で重視された点として実行効率とセッション管理の2点を挙げたが、実際に成功したWebアプリケーションの開発環境にはそれに加えて、データベースアクセス機構と開発容易性の2点が不可欠であったことがうかがえる。

Java

現在の企業システムにおけるWebアプリケーション開発の主流と呼んでも過言ではないJavaについては事情は多少複雑である。

Javaは仕様制定のためにはJCPと呼ばれるベンダー間の合意形成のためのプロセスを経なければならないことが、オープンソースとして身軽に開発が可能なApache、PHPといったソフトウェアや、1社でOS、開発言語、サーバーアプリケーションのすべてを開発しているマイクロソフトに比較してどうしても後手に回らざるを得ないからである。

年代順にJavaにおけるWebアプリケーションへのコミットを以下に示そう。

1997年に、JavaServerと呼ばれる仕様が発表された。これはIISに対するISAPIアプリケーションのように、マルチスレッドで実行されるJavaのクラスに関する仕様で一般にServletと呼ばれる実装方法である。

1998年には、Enterprise JavaBeans（EJB）が発表されている。EJBはTPモニターを含む分散オブジェクトとデータベースのオブジェクトマッピングについての仕様である。

1999年には、JavaServer Page（JSP）を発表。JSPは、ASPやPHPのようにHTMLへJavaプログラムを埋め込むための仕様である。

1997年のASPに遅れること実に2年である。おそらくマイクロソフトのWindows NTがASP発表時点で基幹系ホストコンピュータとしての地位を確立していたら、現在とはずいぶん様相が異なっていたと考えられる時間差であるが、この時点でのWindows NTが部門サーバーからせいぜい基幹系のフロントエンドに配置されるWebサーバー程度にしか認知されていなかったことなどから、この速度でも問題がなかったといえるであろう。

なお、J2EE（Java2 Enterprize Edition）と呼ばれるJava環境は、JavaServer、EJBなどの複数の仕様をある特定の時点でバージョン合わせをした仕様の集合体である。

マイクロソフトが2000年に発表し、2002年にリリースした.NETは、それまでにマイクロソフトが培ってきたVisual C++、Visual Basicといった開発言語、ADOなどのコンポーネント、ASPなどの実行環境を、Javaと同様な仮想マシンの上に再構築した壮大なプラットフォームである。

.NETが提供するWebアプリケーション環境を、ASP.NETと呼び、従来のASPが持つ埋め込みHTMLを残しながら、より洗練されたVisual BasicのようなイベントドリブンモデルをWebアプリケーションの世界に持ち込んだものである。

ここで重要な点は、既にASPによって一定の成功をおさめたマイクロソフトがなぜ埋め込みHTMLという手法から離れたのか、である。

その理由の考察については次節にゆずるが、出遅れた感があるJavaが現在の企業システムの主流となった理由と重なる点があるということは指摘しておこう。

その他のアプリケーション環境

ティム・バーナード・リーにより最初のWWWが実装されたNeXTが1996年に世に出したのがEnterprise Objects Framework（現アップルのWebObjects）というObjective-Cを利用したWebアプリケーションサーバーである。

WebObjectsはそれまでのルールを完全に変える独特なWebアプリケーションの実行環境を提供する。Webアプリケーション開発時に問題となるHTTPというステートレスな通信にステートを持たせてアプリケーションとしての一貫したフローを構成するのが個々のアプリケーションの役割だった1996年という時代に、オブジェクト指向とフレームワーク技術によってアプリケーション開発者がステートを意識する必要をほとんどなくしてしまったからだ。また、RDBMSとエンタープライズオブジェクトのマッピングやSQLの自動生成なども行う。WebObjects相当の環境を他に求めるためには2002年のASP.NET（マイクロソフト）や2004年のJavaServer Facesを待たなければならないのだから、その先進性には目を見張るものがある。なお、WebObjectsを開発したジャック・グリーンフィールドは現在マイクロソフトでSoftware Factoriesのアーキテクトを勤めている。

WebObjectsは当初からJavaをサポートしていたが（2001年に完全にJavaベースとなる）、主となる開発言語がObjective-Cという現在では主流とは言えない言語であったこと、アップルのシェアが低いことなどからほとんど普及していない。とは言うもののアップルストアとiTMSという2つの大規模サイトがWebObjectsで構築されている事は指摘しておこう。

また、フラッシュで知られているマクロメディアは、ColdFusionというPHPのような埋め込みスクリプト型のWebアプリケーション環境を出荷している。ColdFusionは1994年頃にAllaire社が開発した製品であるが2001年にマクロメディアに買収された。

これらの製品はいずれも優れた特徴を持つが、独自の環境であることやシステムとは別に購入が必要となることからいずれも主流とはなり得ていない。

インターネット上のWebアプリケーションと企業システムのWebアプリケーションの差

最初に押さえておかなければならない点は、インターネット上のWebアプリケーションには2種類あることと、これらがいずれも企業システムの特に基幹系システムでのWebアプリケーションのあり方とは全く異なるということである。

インターネット上のWebアプリケーションは大きく次の2種類に分類できる。

Eコマース

サービス

前者の特徴は、信頼のおける通信、カタログ、確実な配送であり、実際のところWebアプリケーションが占める役割はそれほどは大きくは無い。たとえば、Amazonのページ数と企業システムのページ数は一般論としてどちらが多いか考えたことがおありだろうか？ Amazonのページは商品ごとに出てくるため一見すると全商品数以上あるように見えるかも知れない。しかし実際には表示する内容が異なるだけでそれほど多いわけではないのだ。筆者もきちんと数えたわけではないし内部のアプリケーション構造がわかるわけではないのであくまでも推測に過ぎないが、表紙、商品、カートの内容表示、確認画面、配送指定など、アフィリエイト関連やサービスのためのページを除けばせいぜい10数ページ程度ではないかと推測される。

それに対して企業システム、特に基幹系システムをWebアプリケーション化するということは、従来紙ベースで出力していたレポート数以上のページ数が必要だということを意味する。これは、間違いなく企業システムのほうが開発しなければならないページ数が多いということだ。

その一方で、ページの変化――単にレイアウトのような見た目のデザインだけではなく、表示する情報量や質の変化などを含む――については、Eコマース側のほうが激しいはずである。企業システムの帳票の代替となるページが頻繁に変化するということは、そのアプリケーションの意味からもそれほどはあり得ることではない。

後者のサービスは、どちらかというとインターネット固有のWebアプリケーションである。たとえばGoogleのような検索サイト、ミクシのようなSNSサイト、はてなのような独特なコミュニケーションサイト、MSNやYahooのようなポータルサイトがこれにあたる。収益モデルのほとんどが広告に依存するこれらのサービスの特徴は、次々に打ち出す新しいサービスの提供であり、日々進化する姿そのものである。その特徴をGoogleのサービス提供スタイルから永遠のベータ版と呼ぶことができよう。現在日本最大のSNSサイトのミクシもトップページにはmixi βversionと誇らしげに記されている。これは、企業システムではちょっと考えられないことだ。

なお、サービス分野のWebアプリケーションと言っても必ずしも企業システムとは無縁ということはない。たとえばサイボーズといったベンダーが提供するグループウェアはこの系統のアプリケーションであるし、企業内にBlog（シックスアパートのMovable Typeが有名である）をコミュニケーションツールとして取り込といった動きも最近では見ることができる。

インターネット上のWebアプリケーションと企業システムとしてのWebアプリケーションの差がはっきり分かれたのは、良くわからないがクライアントサーバよりもROIが低減できるはずだからWebベースに変えようという、インターネットでうまく行くから企業システムでも真似をしてみようというレベルから、基幹系システムにWebアプリケーションを取り込むということがどのようなことかが正しく認識されてきたからに他ならない。

そもそも、開発しなければならないアプリケーションの種類が全く異なるのだから同じような方法論を適用することはできないと考えるほうが自然である。

最初に、アプリケーションの構築方法について言及したのは1998年にマイクロソフトが打ち出したWindows DNAだと考えられる。

Windows DNAは、ASP、ADO、MTS、MSMQといったマイクロソフトの複数のテクノロジーによってクライアント―サーバを単にWebで構築するということを超えて、企業システムを構築するためにどのようなテクノロジーをどのように配置するか、の設計指針（今風に言えばアプリケーションアーキテクチャ）を示したものだ。

Windows DNAに対応してアプリケーションアーキテクチャを示したものが同じ1998年のEJBを含めたJ2EEと言えよう。

さらに、2000年にApacheファウンデーションのJavaプロジェクトJakartaからリリースされたStrutsで、MVC（JSPタイプ2）によるWebアプリケーション構築という文字通り骨組みが提供されたことで、Webアプリケーション開発にはフレームワークの適用が必須という機運が生まれることになった。

これらは、いずれも大量のWebアプリケーションを多人数で構築する、いわゆる大規模プロジェクトを前提とした場合に求められるものだったのである。

このようなWebアプリケーション開発手法が、少数精鋭のネットベンチャーによって素早く斬新なサービスを次々と提供するというインターネットの開発手法と異なるのはある意味当然である。

その一方で、このような手法の限界も見えてきた。インターネット上のWebアプリケーションが永遠のβ版なのは必ずしも次々に新機軸を打ち出すことだけが原因ではないということだ。それは既に10年にもおよぶインターネットを利用するコンピュータの成熟（あるいは多様化）に起因する。

たとえば、同じIEという名前のブラウザーであってもバージョンどころかサービスパックや場合によってはセキュリティフィックスのアップデートによっても挙動が異なるということや、ダウンサイジングによってもたらされたメインフレームからオープンシステムへの移行が真に意味する点が明らかになったということである。オープンシステムの収益モデルは頻繁なバージョンアップ――当然、それをバージョンアップする理由を裏打ち可能なサービスの追加や変更を伴う――だ。このことは、メインフレーム時代のように安定したプラットフォームが望めないということを意味する。実際に動かしてみるまではAPI説明書に書いた通りの挙動をするのか、あるいはテスト用に利用した環境と同等の動作をするのか、そういったことが必ずしも予見できるわけではないのだ。もちろん、企業システムであればすべての更新を停止してクライアントの動作を固定するという選択ができないわけではない。しかし、インターネットと企業が結合されるようになったため、セキュリティ上の問題に対する更新まで行わないわけにはいかず、そして収益モデルとの兼ね合いからサポート期間

$K$O@)8B$,@_$1$i$l$F$$$k!#$^$7$F!"%$%s%?!<%M%C%H>e$GI}9-$/%5!<%S%9$rDs6!$7$F$$$k>l9g$K$O!"$"$i$f$k2DG=@-$X$NBP1~$r$r$"$i$+$8$a@9$j9~$`$3$H$O;v<B>eIT2DG=$@!#$7$?$,$C$F!"$=$l$,2DG=$J4D6-$G$"$l$P!"KhF|$N$h$&$KH/3P$9$kLdBj$KBP$7$F7QB3E*$J%=%U%H%&%'%"$N=$@5$H99?7$r9T$&$3$H$K$J$k!#1J1s$N&BHG$K$OM}M3$,$"$k$N$G$"$k!#

もう1つの問題は、ユーザー側の意識の変化である。家庭でインターネットを利用する環境と、企業でイントラネットを利用する環境で、利用しているハードウェアやソフトウェアが同じことによって生じる錯誤である。前者は永遠のベータ版が許容される世界で、後者はそうではないにも関わらず、後者に前者と同等かそれ以上のフレキシビリティを当然のように求めることになるからだ。

このように、企業システムの開発は大規模プロジェクトでありながら、変化を柔軟に受け入れる必要が生じてきた。EJBやStrutsで、柔軟性を確保するために選択された技術はXMLである。どのプログラムを実際に動かすかを実行時まで遅延させるためのパラメータとしてXMLを利用するという手法である。また、プログラム自身を柔軟に構成可能とするためにJavaでシステム開発をしてきたグループによって、2004年から草の根的に提案されたのがDI（Dependency Injection――依存オブジェクト注入）であり、AOP（Aspect Oriented Programing）である。

DIとAOPは、実際に利用するプログラムをコンポーネントとして分離し、実行時に結合するためのシンプルな機構である。利用することで、後からのコンポーネントの交換を比較的簡単に行うことができるようになることや、変化することが考えられないコアなコンポーネントと、後から変更されることが予期されるコンポーネントをあらかじめ分離して開発することで変更のためのダメージを最小限に押さえたり、処理の分離度を高めたりするための技術である。

同様に開発プロセスとして、最初から細部まで固定的に設計せずに後回しできる部分は後回ししたり、あるいは細かい単位で実装を繰り返す（ちょうど雪ダルマを作るように何度も転がして雪を付けて行くようにしてシステムを構築する）手法を取り入れることも行われるようになった。

ただ、これらの手法によっても問題が完全に解消できるわけではないということも事実である。たとえばXMLによるパラメータは実行時まで記述ミスがあってもわからないという問題がある。また、柔軟な構成が必要となればなるほどXMLによる動的な設定が増えていくため、固定的であるべき部分と柔軟でなければならない部分の境界があいまいになり結果として不安定なシステムとなってしまうということもあり得る。

企業システム開発の将来展望

企業システム、特に基幹系へのWebアプリケーションの導入は上記のように種々の問題点を抱えている。

これを打開するための技術のうち、現在既に完成しているものから近い将来に出現する可能性があるものまでを列挙する。

プログラムの中に動的な構成のための情報を埋め込む技術である。動的な構成情報をすべてXMLという単なるテキストに持つのではなくプログラムそれ自身が提供できるものはプログラムの中に埋め込むことでミスを無くすことや、人間が手で設定しなければならない要素を減らすことが可能となると考えられる。たとえばSeasarファウンデーションのS2のようなDI＋AOP環境では既にアノテーションを利用することでXMLの必要性を大幅に減らすことに成功している。

関数型言語

JavaやC#、VB.NETといった手続き型言語はプログラムの中で状態を意識する必要があり、これはあまりレベルが高くないプログラマにとってバグを入れやすい原因となると考えられる。また、状態によって実行結果が異なってくるためテストの有効性に限界があることになる。関数型言語（Haskel、F#など）は状態を持たないため、結果はプログラムに記述したそのものとなる。このため、関数型言語が注目されている。

DSL

ドメイン特化言語（Domain Specific Language）には言語内DSL、またはプログラム自動生成言語という2種類の実現方法があるが、いずれの場合も、直接プログラム言語そのものを利用してプログラムするのではなく、より高次元の処理の記述に特化することでプログラミングにまつわるバグの発生や開発に必要となる工数を抑制したり除去することが目的である。マイクソフトのSoftware Factoriesの中心にはDSLの開発が含まれる。

特化クライアント

ClickOnce（マイクロソフト）、JWS（Java）などのクライアントアプリケーション配布技術によって配布／バージョンアップ問題を解決したブラウザーを利用しないWebアプリケーション。この場合、Webサーバーとの通信にはSOAPなどのメッセージングを利用することになる。

SOA

SOA（Service Oriented Architecture）は、端的に言えばアプリケーションを一枚岩で構成せずに、サービスという単位（大雑把には給与計算、勤怠管理、のように一言で呼べる処理のまとまり）で開発し、さらにサービス間のインターフェイスをXMLメッセージのようにシンプルなものにすることで、システムの構成管理を柔軟にするということである。当初、ベンダー固有の製品やSOAPと組み合わせて語られることが多かったため誤解が生じた面もあったが、現在ではアプリケーションアーキテクチャを決定する場合にサービスという単位の考慮は必須となっている。

2001年を象徴するのが、Amazon.comが10-12月決算で創業以来初の黒字（営業利益5,900万ドル。なお前年同期は6,000万ドルの営業損失）を達成したことである。Amazonの特徴は、購買履歴やクリック履歴を最大限に利用して、もっと購入させようとお勧めをしてくることにある。インターネット企業としてのAmazonの真価はこのお勧めの確度にある。

また、1997年に創業したGoogleが単に検索ポータルのトップになっただけではなく（2005年現在、米国で37％、ただし日本ではYahoo!が50％を超えてトップ）、Gmail、Google Mapなどのアプリケーションを次々とリリースした。その過程でAjax（Asynchronous JavaScript ＋ XML）と呼ばれるJavaScriptを徹底的に活用したクライアントサイドスクリプティング技術が注目を浴びることになった。

AjaxはIEに統合されている非同期XML通信コンポーネントを利用してサーバーと会話することで動的にクライアント画面を再構成する技術である。

既に触れたが現在インターネット上のWebアプリケーションはECサイトを別にすればサービスの提供がほとんどである。サービスを支えるのは利用者の数と、インターネット上に遍在するHTML群である。たとえば、はてなの20万人、ミクシの200万人といったユーザー数や、Googleが収集した膨大なデータ量は、そのものが巨大なナレッジであり、これらのサービス提供企業の価値である。しかもこれらのデータはサービスを提供し続ける限り自動的に増加していくのである。サービスの目的が広告収入にあるのであれば（どこまでインターネットへの依存度が高まっても最終的には物の購入は必須であるため、広告が不要化することはない）、どのような広告を表示するかを判断するためのデータ量が多ければ多いほど、ユーザーを特定できればできるほど、質の高い広告をユーザーへ送ることができる。その結果広告の精度を上げることができ、結果的に広告収入をより増やすことが可能となる。

Web 2.0という技術的な意味はないスローガンは、このようなサービスがサービスを提供することにより内部情報を自動的に増加させ、それにより価値を膨らませることを指す言葉といって良いであろう。

まとめ

単なるインターネットの真似事に過ぎなかったイントラネットがインターネットモデルを離れて巨大な情報システムの構築に進んでいるように、あるいはWeb 2.0が非常にスマートな方法でサービスから収益を上げているように、WWWの15年間は絶え間ない進化の連続だった。ティム・バーナード・リーが1989年にナレッジの集合をHTTP、HTML、URIというシンプルな3つ組みで統合しようとした理想は、HTMLそのものではないかも知れないが、企業の基幹系情報システムというナレッジ、あるいはWeb 2.0企業のユーザー群というナレッジの統合という形で着実に定着しているように見える。

参考