2000年以前～2005年までの流れ
2000年以前から2005年くらいまでは、Webシステムでは主にサーバサイド技術がトレンドが中心でした。当時のその他の技術トレンドやニーズも踏まえて、説明したいと思います。
汎用機モデルからのリプレース
この当時はブロードバンドというネットの常時接続の普及があったのですが、その他にもう一つ大きなポイントがありました。
その背景を示す用語が「2000年問題」です。2000年問題とは、表面的には年号の問題ですが、本質的には当初想定していたシステムの稼働年月を超えて使われてしまったということです。つまり、多くの古くなったシステムでリプレースする時期が過ぎていたにもかかわらず、継続して使われてしまっていたのです。
当時主流だったシステムは、図2のようなPCとデータベースが直接接続する「クライアント・サーバモデル」もしくは「汎用機モデル」でした。
このとき、2000年問題を抱えていたのが主に1970～80年に作られた汎用機システムです。一方、クライアント・サーバモデルは1990年以降のPCの普及により広がったものです。
当時はWindows 95の発売があり、その後もOSの更新が頻繁にされていたため個別の対応が求められていました。しかし、それはOSの性能向上によるUIの改善なども期待されていたからであり、当時のWebシステムではそれらの要望に技術的にもまだ応えられる状況ではありませんでした。
そして、図2の左側を見るとわかるように、汎用機モデルの構造はWebシステムと非常に似ています。そのため、図3のように非常にわかりやすくリプレースが可能になったのです。
Webアプリケーションミドルウェアとスクリプト言語の普及
ハードウェアやネットワーク構造としては、汎用機モデルからWebシステムへのリプレースは親和性が高いのですが、残念ながらWebシステム側ではまだまだ受入環境は整っていませんでした。
2000年当時のサーバはCPUが500MHzでメモリが128MBという、今のスマホやRaspberry Pi以下の性能であることも普通でした。そういった環境で数千以上のクライアントのリクエスト処理をしなければならないのは非常に大変でした。
そのため、データベースへの接続数を節約するためのコネクションプーリングや、同時に多くの端末などからの処理を行うプロセスプーリングやスレッドプーリングなどのリソースを節約する手法は必須にもかかわらず、当時はプロジェクトごとに実装を行っている状況でした。
簡単そうに見える処理でも、このような制御において安定した実績がないなかでリソース管理を間違えるとすぐに問題が生じてしまいます。筆者もWebシステム開発の経験がない中で、こういった実装とその後のトラブルに非常に苦労したことを覚えています。
そして、これらの問題から開発者を解放するためのWebアプリケーションやミドルウェアがすぐに普及しました。例えば、WebLogic やIBM WebSphereなどがその例です。
一方、簡単なWebシステムのニーズも広がり始め、それらのニーズを見事に捉えたのがPHPでした。また、同時に当時はコンピュータのハードウェアの進化も速く、高度なリソース管理をしなくてもよくなり、スクリプト言語の活躍範囲が広がっていきました。
また、スクリプト言語は、比較的小さなプロジェクトで手軽に始められることから、HTMLとプログラムの管理が分かれていないといった問題も顕著になり始めました。
もちろん、この問題はスクリプト言語だけではなく、当時のWebシステム開発の共通的な課題です。その中でプログラム内での役割分担を明確にしようという動きが活発になり、「MVC」の考え方が一般化しました。
フレームワークの乱立と競争
Webシステム開発において「MVCフレームワーク」や「Webミドルウェア」を前提として開発が一般的になる中で、生じた問題が「フレームワーク」の乱立です。フレームワークはそれぞれに一長一短がありますが、以下の点で特徴に違いがありました。
- SQLの扱い方（ORM、もしくはテンプレート型など（下記Note参照））
- HTMLテンプレート（独自タグや独自文法）
- プログラム管理（命名規則かメタプログラムか）
例えば、Javaのフレームワークなどではこれらの組み合わせが自由に選べることが望まれたため、フレームワーク競争はそのままライブラリの乱立につながりました。そのため、新規の開発者がどのライブラリを使えばよいかがわかりにくく、結果として参入しにくいといった弊害も生まれました。
一方、分かりやすいフレームワークを目指すソフトウェアでは、必要なライブラリがオールインワンで提供されます。そのため、どうしても個別の部分で好みや適性が生まれてしまいます。それが開発者間の思想レベルでの違いを示す「フレームワーク戦争」（Note参照）といった言葉が生まれるまでに至った背景でしょう。
また、特にフレームワークの新しい風として大きく名乗りをあげたのが、「Ruby on Rails」です。Webシステム開発に限定すれば、「Ruby」＝「Rails」という図式が成立するほど主流になったため、同じ言語の中でフレームワークの分裂が起きず、非常に分かりやすいものでした。Ruby on Railsの普及はその後、さまざまな他のプロジェクトにも影響を与えPHPなどのLaravel（2011年リリース）などが生まれるきっかけも作りました。
この時期は「開発者自身が開発現場でいかに効率よく開発作業をするか」といった点が注視されていた時代と言えると思います。
［NOTE］O/Rマッパーの種類について
SQLはWebシステムにおいて多く使われますが、プログラム内に異なる文法であるSQLが含まれることでコードがわかりにくくなります。
また、SQLインジェクションのような典型的なセキュリティリスクも生じやすいため、何らかのライブラリを使うことが一般的です。その時、データベースの定義とクラスを結びつけて1:1の定義を強制するORMや、命名規則に厳格な指定があるもの、アノテーションなどで自由度を提供するORMがあります。一方、MyBatis のようなSQLをテンプレートとして処理できる、他と考え方が大きく異なるものもあります。
このように同じ目的の処理をする場合でも設計指向が異なります。このような違いがプロジェクトの規模だけではなく設計指向にも影響を与え、結果的には、開発者の嗜好にも影響を与えました。
［NOTE］フレームワーク戦争について
フレームワーク戦争というのは少々、大げさな表現かも知れません。しかし、開発者にとってはどのフレームワークを採用するかは、個人的な好みの問題だけではなく将来のスキルプランにも影響を与えます。
例えば、自分が経験したことがあるフレームワークであるか否かが、自分がそのプロジェクトに参加できるか、できないかにも直接的に影響を及ぼすため、関心の高い事項だったのです。
今でも求人に特定のフレームワーク経験の必要性を記載している企業もあると思いますが、その会社がほしい人材特性にも影響を与えていると言えます。
