JJUG CCC 2013、お疲れ様でした。拙い講演にも関わらず、多くの方に聴講頂き大変感謝しております。
今回、HTML5時代に融合しようと各ベンダ製品が実装しつつある機能に焦点を当て、Javaがどういう道に進もうとしているのかというテーマで講演させて頂きました。
ただ、今回は本当の本当に時間が無かったため、うまく伝えきれていなかったと思える点が多くありました。網羅性に欠けると議論として成立しにくいと考えておりまして、かなり詰め込んでしまいました。
後出しで申しわけ無いですが、ここで補足をさせて頂きます。
EclipseとWeb開発
今回、Javaの開発ツールとしてEclipse前提に解決方法についての提案をさせて頂きました。
画面作りなんだし、普通はNetBeansじゃね?と言われてしまいますが、こういった講演活動をしていると「いやいや、エンタープライズってぶっちゃけEclipseでしょ?」というご指摘を受けます。そして、Eclipseを中心に語ると、聴講者もしっくりくるような反応をされます。
多くのSIがEclipseにうんざりし、自分たちだけが世の中に置いて行かれているという印象を持っているようですが、ご安心下さい。あなたが思っている以上に、みんなEclipseを使っています。
EclipseはそれぞれのSIで、様々な開発効率化を行う工夫を凝らし独自進化を遂げたようです。NetBeansの方が動作も軽く優れていると思われているようですが、社内ノウハウを結集し統制や標準プロセスへの最適化のため創意工夫を凝らしたIDEからの乗り換えを行うには、リスクが高いという判断になるでしょう。
勿論、全社的な統制を全くしていないSIは、NetBeansでもいいはずですが。
OSSによるフロントエンド開発ツールの問題点
今回このテーマを選ぶきっかけになったのは、2つほどあります。
ひとつは、現在フロントエンドで広がっているGruntが、ほんのこの半年でデファクトという地位に昇格しようとしている中、業務系でなかなかこの議論が出てこなかったことです。ネット系の業界に閉じて広がろうとしているようです。当然、業務系の世界だと、そんなOSS使うにはリスクが高いと思われてしまうからでしょう。
しかし、FlexやSilverLightが終わる方向に向かっている中、わざわざこれらの製品を使おうという企業は無いという状況です。JSベースへの置き換えは検討されても、いまさらFlexやSilverLightのようなプラグインベース開発だなんて誰も言い出しません。エンタープライズにもなると、長いライフサイクルを持つソフトウェアに、先が無い技術を利用するのはリスクが高いと感じるのはごく自然なことでしょう。
ただ、ぶっちゃけたことを言いますと、安定しているのは断然FlexやSilverLightです。これは間違いありません。HTML5は技術から先に出てきたということもあり、周辺ツールが遅れて部分最適にバラバラな状態で出てきているという状況です。ハッカー不在を前提とした私たち業務システムの開発では、無条件でHTML5を選択するというのはむしろリスクとして最悪なようにも思えます。しかし、そうしざる得ないのもまた事実です。
そこで今回「Grunt」という開発ツールを紹介させて頂きました。
Gruntは、この混沌としたJSベースなリッチアプリ開発を「今だけ」でも何とかできる打開策になるのではと考えました。Gruntは確かに出て日の浅い技術ですが、エンタープライズ系のシステム開発で求められる、標準的開発プロセスの構築において、かなりのポテンシャルを持つ製品です。FlashもSilverLightも使えない状況でどうにかしなきゃいけない今のこの状況を何とかするには、Gruntを使わないとどうしようもないという状況です。ノーチョイスと言っても過言ではありません。
Visual Studioはもう十分に機能を持ちます。Senchaもです。ただ、JavaはEclipseプラグインに閉じて考えると、時代として3年以上開きがあり、そこにFlashやらSilverLight的リッチなアプリ開発へ適用させるのは問題が大きます。大規模なモノを高い品質で作れるほどの根拠を、メトリクスを、全然拾ってこれません。だからこそ、Gruntという製品の存在を、サーバ屋だらけになってしまった業務系の界隈にも伝える必要があると感じました。
フロントエンド・サーバ、同じツールである必要があるのか?
そしてもうひとつ、私は偶然にも、ほんの二ヶ月前まで社内の標準開発IDEのテストに関わっていました。その中で、様々な気付きを得ました。
まず価値観の破壊です。そもそもなぜ、業務系ではフロントエンドとサーバサイドで同じ開発ツールを使っているのか?っということです。
HTMLサンプルを作る時は別のエディタなのに、JavaScriptを書くのも別のエディタなのに、なぜこの手の開発ツールはIDEに繋げようとしているのか。本当にそれは役に立つのか?現場の開発業務フローに合っているのか?・・・と、疑問に感じました。
「ツールが含まれているから大丈夫。」という発想はもはや通じないほどに、現場の開発フローは複雑化したように思えます。ただ、それはオープン系の本質に思えます。
バラバラの思想を持った製品をつぎはぎで繋げて使えるものに変えていくという過程から生じた歪みたいなものが必ず出てくるはずです。本来オープン系のツールは、そこまで整合されたソフトウェアでは無いのです。そしてフロントエンドはもう、本当に何もかもがバラバラなのです。黎明期のLinux状態です。
JSPがWeb標準から乖離して長くなり、JSFかJAX-RSか、あるいはSpringかという議論が繰り広げられ徐々に移行する流れに入っていますが、こうした中で、開発のあり方を一度見つめなおす必要があるのかと感じたのです。「技術的にできるかできないか」でなく、みんなが現場では「どのようにモノを作っているのか?」という点にフォーカスしたかったのです。
そこで今回、私は素直にもう「別ツールでとりあえず作ろうよ」という提案をしてみました。無理をしてGruntが無い状況になるのは良くないと思うからです。
もちろん、今後もこの状況が続くと思っていません。どこかでIDEに再び機能として加えられるのでしょう。Visual Studio2013があそこまで先進して、うまくワンツールに全てを詰め込めたわけですから。OSSでは今が無理なのだから、今だけでもやり過ごすためにGruntを使ったほうが良いですよ、という提案です。
次世代型と呼ばれるものの正体、レイヤーの上昇とは?
次世代型とは呼ばれていますが、その正体は多くの人がpjax+XHR+RESTなアプリケーションを想像すると思います。
ただ、私はこれは殆ど正解で、微妙に違うと思っています。Oracleの寺田氏は次世代型のWeb開発技術に「WebSockets」を加えている所がキモだと思ってて、アーキテクチャの本質的な変化は、通信技術レイヤーの上昇、そして最終的にそれがクラス設計の変化として現れてくると考えています。
恐らくですが、数年後にはプログラマはクライアント・サーバ間の通信技術に、HTML4〜5時代のどの技術を使っているのかを意識しない時代になっているでしょう。WebSocketかXHRかなんて、パフォーマンスチューンの時ぐらいしか意識しなくなるはずです。既に多くのベンダ製品はそういう時期に差し掛かっています。
そして残るのは、ソフトウェア開発で最もプリミティブな単位である「クラス」というレベルでの設計になると私は予想しています。
JavaはProject Avatorによって、WebSocketとXHRの双方でようやくJAX-RSが疎通しようとしています。挙句、サーバ側でもJavaScriptが動作するため、EJB程までにはいかなくても、クライアント・サーバなどの場所を意識させないJavaScriptクラスの呼び出しが実現できるようになりつつあります。
そうなると、次は通信というレイヤーをいかに抽象化・隠蔽化すべきかという議論へ移るでしょう。また、JAX-RSがモジュール間通信というレベルにまで到達していないが故に生じる問題の解決方法という方向でも議論されるでしょう。それが結果として、「シム・ライブラリ」という形でOSS製品がいくつか出てくるんじゃないかと思っています。Strutsのように間に下駄を履かせる感じかもしれません。
Javaだから特別というわけでもなく、他の製品でもそうりつつあるから。きっとJavaもなんだろうなぁと、そう感じました。
フォーマットの問題
現在のJavaのServer-side Script、MicrosoftがView Engineと読んでいるものですが、フロントエンド系の人間からは非常に問題が大きいと感じています。
フロントエンドエンジニアが必要なレベルの開発だったら、SPA(Single Page Application)でいいよね?っという安直な答えを求めるのは危険で、どう頑張ってもサーバ側でデータを埋め込んだ状態でHTMLドキュメントを返すという仕組みを無くすことはできないと思っています。
そもそもWebが、pjax的な思想をあまり歓迎していないため、標準として歓迎されるのか私は不安を感じています。昔はあれだけ多くのサービスのURLが「#!」を埋め込んでいたのに、どんどん使わなくなっています。
「いやいや、業務系はイントラ向けだから、クロスブラウザとか無関係でしょ?」っという指摘も受けます。ただ、Webはインターネット上のサービスの課題を解決するための標準は策定しても、イントラ向けについては想定していないように思えます。少なくとも、国内の業務システムみたいなコアなやり方は想定していません。そういう前提でWebの標準化は進むでしょう。
そうなると、長い目で見ればダメージを受けるのは明白でしょう。それこそ、「SIはまだ失われた技術にしがみついているの?」っということにもなりかねません。
そこで私が伝えたいと思ったのは、RESTが解決策ではなく、成果物の分離、技術の分離。「分離」を行うための技術に注目すべきでは、っと言いたかったのです。むやみにRESTという「分離」のための手段の一つを、常にベストな手段だという前提で議論するのは危険ですよと言いたかったのです。Server-side ScriptがJSPからJSFに移り変わってもなかなか解決されなかった問題を、これからも議論していく必要があると思うのです。
JSFはフロントエンド屋からはあまり好まれない点もありますが、それでもいいんだと放置するのはリスクが高いと感じています。スライド内でも触れているTemplate Engineなどの存在は切っても切れないのではないか、というのが私の意見です。
最後に
ここからは今月末に開催されるHTML5 Conferenceでのセッション内容についてです。ここでは、今回扱ったJavaとか、先週に扱ったASP.NETとか、そういう特定の技術に特化しない汎用的なテーマをもたせセッションにしていく予定です。
来年、恐らく4月あたりからいよいよ開発スタイルの変化が本格化してくると予想されますので、そこに何かヒントみたいなものを残せないかと考えています。
私たちHTML5jえんぷら部ですが、設立時には全くもって想像できなかった、本当に色んな議論ができました。コミュニティメンバの中には仕事に大きな影響を与えた者も少なくなく、「趣味」の範疇を遥かに超えた活動になっているのは間違いないという状況です。
HTML5 Conference 2013は、次の成長を迎えるにはとても丁度良い時期だと思っています。
果たして世の中がどう感じるのか?未だに情報を外に向けて発信することに恐怖を感じることがあるのですが、ここまでコミュニティの中で議論されてきたこと、私自身が見て聞いて実際に手を動かして知ったことを、世の中へしっかりと発信することは重要と感じています。
11月30日、会場でお会いしましょう!
かなり挑戦的な言葉を投げかけると思います。もし可能なら、現地ででも、Twitterでも構いません。ご意見下さい。