2000年、ドットコムバブルが崩壊したとはいえ、WebによるECサイトは確実に増えていました。天下のショッピングモール、楽天が躍進していたのも、このころだったと思います。「Webの効果」を確信したIT先進企業は、一斉に、過去に作った社内業務システムを、Webアプリケーションに移植し始めます。

VisualBasicやDelphiなどで作ったクライアントサーバ型のシステムを、J2EEのWebアプリケーション型システムに移行する。そういうプロジェクトがものすごく多かったのです。
立派に働いているシステムを、なんでそんなに作り直したかったのか、いまだに理解できないことも多々ありますが、とりあえず、業界全体が大忙しでした。

当時のWebアプリケーションのウタい文句は、

でした。確かにそうです。そのためのWebです。
しかし、クライアントサーバでできることが全部、Webでできるわけではありません。Webを使うということは、さまざまなモノとのトレードオフを考慮しなければならないはずでした。その認識が、当時の関係者はみんな、甘かった・・・。

クライアントサーバ型のシステムは、画面が非常にきめ細かに動きます。情報量も多いし、お客さんが望めば、それこそ計算シートでもお絵かきツールでも、なんでも作りこむことができました。

一方で、Webの画面には限界があります。まず基本的に受け入れなければならない制限は、画面遷移（RequestとResponse）、HTMLの表現能力です。この基本を理解しているお客さんは稀でした。

仮に理解していたとしても、やっぱり妥協はしてくれません。どうしても、いままで使っていた画面と同じ画面を要求してきます（・・・だったら作り変えなきゃいいのに）。
あるプロジェクトでは、HTMLフレームを４つも５つも分割する画面もありました。よくあった要求は、ブラウザの戻る/閉じるを消してほしい、右クリックできないようにしてほしい、ポップアップしたら親画面をロックしてほしい、などなど。「できない」ことを伝えると、「何でできないのか報告書かいてほしい」。そうこうしていると、みんな疲れ果ててきて、「なんでWebにしたんだっけ？」なんていう話に落ちついてしまったり、最後には、「努力した跡だけでも残してほしい」って・・・。

時が進んで、全てのパソコンユーザーがWebの操作性に慣れてしまいました。そうなってからは、このようなドタバタ喜劇はなくなりましたが、最近また、AjaxによってWebの操作性が変わろうとしています。またあんなことを繰り返さなければいいのですが。

クライアントサーバではあたりまえのこの機能は、Webだとめっぽう難しい。
Webは、不特定多数のユーザーにたくさんの情報を公開するために発展してきました。ですから、ひとりのユーザーにひとつのデータを紐づけるという仕組みとは、根本的に目的が違う、というか矛盾しているのです。

例えば、クライアントサーバ型では、データベースのロックやトランザクションは、好きなところで開始・終了できます。Webでは、画面が１回遷移したら、それでロックもトランザクションも終わり。※無理やりできるかもしれませんが、これもまたいろいろな弊害とのトレードオフですし、だいいち工数がかかります。

このクライアントサーバとの大きな（致命的とも言える）ギャップを、プロジェクトの開始前に説明できていたら、作り変えを希望するお客さんが減っていたかもしれません。あるいは、Webだからこそできることを、ゆっくり考えたのかもしれません。

あの当時はとにかく、みんな急ぎすぎでした。
良く言えば、「そういう先人の挑戦があって、今がある」のかもしれない。でもやっぱり、同じものを違うアーキテクチャで作り直すことに、大義はありませんよね。

システム移行では、ほとんどの場合、過去に蓄積したデータには手を入れません。データは企業の命ですから、そう簡単には、設計変更はできないでしょう。

オブジェクト指向が普及する前は、超正規化された複雑なデータベースであることが多いです。しかも、テーブル名が「T_00001」なんて、連番だったりね。カラム名も「S_FLG」とか「GMN_KBN」とかで、いったい何のことかと思ったら、画面を制御するためのパラメータが、データベースに入ってたりしてたものです。

もちろんSQLさえ引き継げば、スムーズにプロジェクトは進行したのですが、このデータベースにあわせて設計したものを、「オブジェクト指向」と呼ぶのは気が引ける思いでした。

いまだにJavaを使ってもオブジェクト指向っぽい設計ができなかったり、EntityBeanが無用の長物あつかいを受けているのは、こういう過去の遺産を引きずっているからなのかもしれません。
第１回でもちょっと触れましたが、Javaという言語は、過去も未来も背負って、どっちの意見にも応えなければならない。ゆえに肥大化して、使いづらいとののしられ・・・かわいそうな言語です。

それに引きかえ、Railsの軽やかなことっ。

この本は当時のWebアプリケーションのバイブルでした。ちょっとだけ古い本ですが、J2EEをこれから学ぶ方にも上級者にも、おすすめです。これ一冊でコトたります。