世界中から集まった技術者たち。革新的な技術が発表されるたび,わき上がる拍手。セッション会場の前にできる長蛇の列。言葉に表すことのできないある種の興奮が会場を包んでいた。米サンフランシスコで2003年6月10日~13日に開催されたJavaの開発者会議「2003 JavaOne Conference」での光景である。生まれて初めてこの場に身を置いて,Javaの開発者の勢いを肌で感じることができた。

 1996年から毎年開催されているJavaOneだが,以前から何度もJavaOneに参加している人々に言わせれば「今年は当たり年」だったという。2000年前後に大きな盛り上がりを見せたものの,参加人数も会議の内容も,ここ数年は停滞が続いていたらしい。それが今年のJavaOneでは,Javaに大きな変革をもたらす発表がいくつもあった。中でも大きかったのが「Ease of Development」。Javaによるソフトウエア開発を簡単に,である。

WebアプリでもVBライクな開発が可能に

 Ease of Developmentは,米Sun Microsystems社がJavaの普及を促進するために打ち出した策である。同社は,現状300万人とされているJavaの開発者数を1000万人まで増やすという目標を掲げた(関連記事)。開発者の裾野を広げるためには,Javaによるソフトウエア開発が簡単にならなければならない。現状のJavaでは,まだこの部分が弱い。特にJavaが得意とするWebアプリケーションの分野では,J2EE[用語解説]が規定する複数の規約を上手に使いこなすのが難しい。

 そこに開発ツールが対応し始めた。具体的には,Webアプリケーション開発の際に,部品をドラッグ・アンド・ドロップで貼り付け,それをダブルクリックしてコードを記述していくツールの実現である(関連記事)。いわば,Webアプリケーション開発のVisual Basic(VB)化だ。これまでは,Webページを開発するにもJavaServer Pages(JSP)のタグを一から書く必要があった。それが,マウス操作だけで可能になる。

 JavaOneでは,こうした開発ツールのデモが相次いだ。初日の基調講演では米Oracle社,二日目にはSunが新しい開発ツールを発表した。JavaOne会場では見かけられなかったが,米IBM社や米Borland Software社もこの手のツールの開発に着手している。例えばIBMは,2003年5月に東京で開催した開発者会議「IBM developerWorks Live! with WebSphere 2003」で,同種のツールを既に披露している(関連記事)。

 これらのツールはすべて,現在JCP(Java Community Process)によって仕様策定が進んでいるJavaServer Faces(JSF)というフレームワークの上に作られている(関連記事)。JSFの仕様がほぼ固まり,Reference Implementationという形で実装も公開されたことから,各ツールベンダーの対応が一気に進んだと考えられる。「JSFは今年度中の正式リリースを目指している」(JSFの開発責任者である米Sun Microsystems社Senior Staff EngineerのCraig McClanahan氏)ため,対応ツールも2004年には出てくることになるだろう。

スキルの固定化を招きやすい

 Ease of Developmentに向けたこれらの動きは,Javaによるソフトウエア開発を大きく変えることになりそうだ。まず,開発者を増やせる。新たにJavaを始めようとする開発者にとって,敷居が格段に低くなるからだ。教育コストだって今より下がる。次に,生産性が上がる。アプリケーションの多くの部分をツールが自動生成してくれるのである。ごく単純なシステムならば,ほとんどマウス操作だけで済んでしまう場合もあるだろう。

 これはもちろん,歓迎すべきことだ。しかし本当に,単純に喜ぶだけでいいのだろうか。「Ease of Development」を繰り返すSunの講演者の話を聞きながら,一抹の懸念を感じた。

 簡単なことは,いいことだ。ただしプロの開発者としてJavaにかかわる場合,そこに潜んでいる弊害にも目を向ける必要があるのではないだろうか。開発を簡単にするということはすなわち,複雑な部分を隠蔽し,開発者にそれを意識させないということに等しい。それは,初級技術者のスキル向上の妨げとなる側面がある。世界中から先進的な技術者が集まっているJavaOneの会場で,この場にはあまりいないであろう初級技術者のことが頭に浮かんだ。

 実は記者には,ソフトウエア開発者として働いていた経験がある。開発経験ゼロの状態からスタートし,まさに初級技術者としてプログラミングに従事する毎日を送っていた。便利な開発ツールには本当にお世話になった。マウス操作でGUIやイベントの設定をするだけで,かなりのソース・コードを自動生成してくれる。ツールがシステムの複雑な部分を隠蔽してくれるのだ。しかし半面で,「ツールがやってくれる部分」を知らなくても動くシステムが作れてしまうことに,少なからぬ不安を感じていた。

 それなら,ツールが生成するソース・コードを追いかけて勉強すればいいではないか。確かにその通りだ。しかしこれが結構難しい。ツールがせっかく複雑さを隠してくれているのに,その中身を調べ,詳細を知ろうという気になりにくい。記者の場合,次から次へと降ってくる作業に追われる中で,既に「動くもの」として用意されているソース・コードの詳細を調べることに労力は割けなかった。いかに手早く,要求されるシステムを作り上げるかに主な注意が向いてしまう。「簡単」であることに甘えてしまうのだ。結果として,システムの下層部分に関する知識はあまり身につかなかった。

 同じことを,日経バイトの2003年7月号で取り上げたJavaのフレームワークの取材を進める中でも感じた。Javaによるソフトウエア開発を支援するものとして,広く使われつつあるのがフレームワークである。フレームワークはいわば,アプリケーション・ソフトのひな形だ。アプリケーションの共通の土台が既に用意されており,開発者は独自の機能だけをその上に積み上げていけばよい。開発効率が上がるし,フレームワークの約束事に従うことでそれなりの品質が確保できる。

 しかし,フレームワークを使うことだけに従事していては技術者としてのスキルの向上は望みにくい。あらかじめ用意された枠組みの中でしか開発ができなくなるからだ。実際,現場の技術者からも「フレームワークの上に積み上げる部品を作ることに終始していると,スキルの向上という意味では妨げになる」(デュオシステムズ開発本部ハイエンドチームシニアシステムエンジニアの中村光志氏)という声を多く聞いた。

 具体的には,「フレームワークの利用が進むと,システムの詳細な部分を知らない人がどんどん増えていく。物理的なところを知らずにシステムを作るので,パフォーマンスを上げられない」(豆蔵ITソリューション事業本部ES事業部の森下敦司マネージャー)。結果として,「フレームワークだけ使っていたら,バカになる」(ウルシステムズ執行役員兼CTOの山岸耕二氏)という声も聞かれたほどだ。

 Ease of Developmentにも同じことが言える。システムの詳細を知らず,あらかじめ用意された部品をマウスで貼り付けることしかできなくなるJavaの開発者が多くなることになるだろう。プログラマの「数」は確かに増えるかもしれない。ただし「質」を向上させることには必ずしもつながらないのである。

Javaの普及の証

 見方を変えれば,これはJavaが成熟し,普及したことの証でもある。こうした議論は,米Microsoft社のVBのような開発環境には従来からつきものだった。同じことがJavaにも当てはまるようになってきたのは,JavaがようやくVBと肩を並べる程度にメジャーな言語になったことを意味するのだろう。

 今後は,いわゆる「Java技術者」の肩書きを持つ人がこれまで以上に増えることが予想される。Ease of DevelopmentによってJava習得の門戸が広く開かれ,フレームワークのようなソフトウエア資産も充実してきたからだ。だからこそ,その門をくぐったばかりの初級者にとって重要になるのは,プロの技術者としてどこまで先に進めるかである。

 隠蔽された複雑さを知らずに終わるか,複雑さに真っ向から取り組み,それを克服できる技術者になれるか。「簡単」であることだけに甘んじていたら,先に続いている道を進むのが「難しく」なるに違いない。

(八木 玲子=日経バイト)