arclamp.jp アークランプ

先日のZope Weekend 5にて、オープンソースCMSという内容のパネルディスカッションに、Java系CMS代表（？）ということで参加してきた。その話題で、いくつかエントリしたいことはあったのだが、まずこの話題から。パネルディスカッション中、モデレーターの桜井さんから、「なぜ、Javaが企業システムに良く使われるのか」ということが指摘された。僕の答えは、簡単に言えば「企業が儲ける構図がはっきりしているから」というものだ。いかにも、卑下した答えに聞こえたかもしれないが、やはりきちんとこのことを理解していないといけないことだ。

儲ける意味とは
まず、企業が儲けられる意味とは、どういうことだろうか。当然のことながら、ほとんどの企業は営利目的であり、株主の利益になることをすべきだ。だから、儲けるというのは、当然の目標になる。企業にまったく永続性がなければ、安心してベンダーを採用することなんてできない。
難しいのは、関係者全員に平等に儲けるチャンスがあるということだ。
たとえば、Zopeであれば、Zope社に利益が集中している可能性が高い。Zopeを利用しようとすれば、すべからくZope社にライセンス料を支払う必要性がある。たとえば、ハードウェアベンダーがZopeを使ったサーバを導入する場合、利益構造は3つになる。1つ目はサーバの販売益、2つ目はZopeのインストール、設定、開発などのSIの販売益、3つ目はZopeの販売益である。当然のことながら、Zopeの販売益が最も利益率が低い。もし値下げ要求があった場合にも、コントロールできるのはハード費とSI費だけであり、Zope社への支払額を下げることは難しい。ていうか、自社で赤字出して下げるしかない。これでは、儲ける構図ができているとは言いがたいのである。
だから、オープンソースであるば、どの企業にも平等に儲ける権利があるかというと、そういうことではない。

Javaの仕組み
まず、Javaを理解するうえで重要なことは、仕様と実装の違いだ。たとえば、サーバーサイドを実装する場合、J2EE（Java 2 Platform, Enterprise Edition）と呼ばる仕様群を使用する。Javaが規定しているのは仕様に過ぎないので、実装をするベンダーが必要になる。たとえば、J2EEの標準的案APIを網羅的に実装した「J2EEアプリケーションサーバ」といえば、IBMはWebSphere、BEAはWebLogic、富士通はInterStageという具合である。
ということは、Javaでは、標準APIだけを使用していれば、ベンダー間のポータビリティが確保されているということである。
なお、Javaが動く基本的な環境であるJavaVMも同じことだ。JavaがOSに依存しないのも、JavaVMの仕様が公開されており、それをOSごとに実装しているからだ。

これは、顧客にとって大きなリスク回避といえるため、Javaを選択する大きな理由となっている。
なお、ベンダー自身は、当然、ロック戦略を考えている。ロック回避がJavaの特徴だというベンダーが、一番ロックする方法を考えていたりするから、マーケティングメッセージとは怖いものである。様々な注意事項があるのだが、細かくなるので書かない。

Javaの儲けの構図は、仕様と実装　
では、Javaの儲けの構図とはなにか。それは、Javaの仕様に従うことで、１から１０まで一通りの利益構造を自社内に揃えることが可能な点だ。サーバ、SI、ミドルウェア、OSのすべてを自分で揃えられれば、利益構造は、かなり自由になる。だから、Javaに対して、大手ベンダーはコミットをすることができるのだ。
ちなみに、Javaの言語として、大規模開発に向くとか、ツールを作りやすいとか、いろいろあるのだが、細かくなるので書かない。

Javaの仕様策定の流れ
では、その仕様をどう決めるべきか。以前は、サンマイクロシステムズが主導的にコントロールしていたが、現在では、まったく異なる方法がとられている。JCP（Java Community Process）と呼ばれるJavaの仕様標準化団体が存在するのだ。新規の仕様は、JSR（Java Specification Request）として、JCPに提出される。すると、責任者となるスペックリーダーと、エキスパートグループと呼ばれる仕様策定委員会が決定される。このエキスパートグループには、JCPのメンバーになれば誰でも可能だ。多くのJSRには、ずらずらとベンダーの名前が並ぶことになる。ちなみに個人でも可能だ。
そして、JSRの作業段階は細かく規定され、進行状況と、その成果物をコミュニティに対してオープンにしている。JSRへのコメントは、どんな人にでもできる。スペックリーダーは、コメントに対応する義務があるのだが、相手が中学生でも真剣に対応しなくてはいけない（JSP2.0の仕様策定で、本当にあった話）。
こうして、みんなの総意で仕様が決定されることで、標準と独自仕様のせめぎあいのバランスが成り立つことになる。

オープンソースで実質的な標準を狙う
ただ、最近は、また別の流れもあるようだ。EclipseというJavaで作られたクライアントソフトは、実はJavaの標準仕様に従っていない。クライアントソフトといえば、Swingという仕様があるのだが、それは遅くて使い物にならなかった。そこでIBMがSWTという仕様をつくり、Eclipseを作り上げ、それをオープンソースにした。このEclipseの出来がすばらしかったので、開発者たちは、こぞってEclipseを使った。これに対して、SUNは、SWTが標準に従っておらず、Write Once Run Anywhereを実現していないとして、強く非難している。が、市場はEclipseを選び、既にデファクトスタンダードとなっている（現在では、ElcipseでもSwingが扱えるようにはなっている）。
最近、IBMは、EclipseをLotus Notesのプラットフォームとして採用した。当然、オープンソースコミュニティの成果も大いに取り込まれており、IBMとしては、Eclipseを寄贈したことで、かなりの恩恵に預かったはずだ（誰か、ここら辺を数値化して欲しいものだ）。

こうして、市場に受け入れられれば、結局、標準なんて関係ないじゃんということがわかってしまった。そのため、大手ベンダーが自社製品をオープンソース化して、2匹目のEclipseを狙おうとする動きがある。たとえば、Apache Software　Foundationには、IBMがPureJavaの軽量EDB "Derby"を、BEAは、SOA開発プラットフォーム "Beehive"を寄贈している。

最近のIBMにおけるオープンソース戦略も、Eclipseの成功を受けた意図的なものだろう。大手ベンダは、オープンソースを使って、いかに自社の都合を通せるのかを、必死になって探っているのだ。

スクリプト言語とJava
そんなわけで、スクリプト言語が、いかに優れていようと、こうした儲けの構図がはっきりしない限り、大手ベンダーは手を出さない。だから、Javaは、企業システムで使われるのである。
なお、Javaもスクリプト言語の良さには気づいている。現在、JCPにて、Groovyと呼ばれる、Java用のスクリプト言語を策定中だ。これが、リリースされると、なかなか面白いと思う。つまり、１つの実行環境で２つの言語が動くのだ。たとえば、ユーザーインターフェースに近い部分はスクリプト言語で作り、ロジックは既存のJava言語でがっつり作るといったことが可能になる。Javaの根本的なアイデアは、これを予定していたのだが、こうしたところがJavaの出来の良さを証明している。

まとめ
そんなわけで、Javaが企業システムの標準となり、そして、今後も伸びていく。こういう構図がわかっていると、何がよいのかというと、Java業界の流行に注目出来る点だ。
まず、オープンソースというものも、かなりの部分、企業からの投資で成り立っている。そんなわけで、儲けられる分野にはお金が集まりやすい。つまり、良い製品ができるのである。
たとえば、CMS関連のツールは、Javaでは極端に不足している。特に、Webサイトのコンテンツマネージメントという分野は、それほどシステム規模も大きくなりにくいし、標準仕様を決めてもメリットができにくい。こういったことで、これまでは、あまり投資が行われてこなかった。しかし、コンテンツマネージメントの分野は、注目されはじめている。いくつかの仕様がJCPで議論されているし、オープンソース実装もはじまっている。そんなわけで、CMSといえばJavaという時代が来ることも十分に考えられる。
ただし、儲けられる所に投資が集中しすぎるから、逆に手を引けなくなって、ずっと固執して変な仕様が残るという悪い点もある。EJB1.0とか、EJB1.1とか、EJB2.0のことだ。
一般開発者としては、こういったところをうまく見極めながら、次に、どの製品を使うべきかということを決めればよい。安心して欲しい。最後は、市場が決めるのだ。