LINEのニュースタブをReact.jsで開発しているフロントエンド、JavaとPerlで開発しているサーバーサイドのエンジニアの方々に、どんな開発技術や体制で開発しているのか、HTML5 Experts.jp白石俊平編集長が直撃インタビューしてきました！

今回お話を聞いた「LINE NEWS」開発チームの皆さん

LINE株式会社 前澤 春樹さん
Javaのサーバーサイド担当。200以上の媒体社様向け管理画面のコンテンツ入稿システム開発や、公式アカウントから発信されるメッセージ配信システムが主な担当。

LINE株式会社 森藤 賢司さん
Perlで作られている一般ユーザーから見えるニュースタブ、記事ページのバックエンドや社内向けの管理画面を担当。

LINE株式会社 大槻 友諒さん
フロントエンドエンジニア。WebViewでつくられているニュースタブの実装を担当している。React.jsなどの最新技術に触れることも多い。

LINE株式会社 富田 梓さん
マークアップエンジニア。デザイナーの作成したPSDをもとにしたCSSの設計と実装を行う。ニュースタブの他、PC/SPのWeb、キャンペーンページなどニュース関連全般を担当。

なぜ、ニュースタブはWebViewなの？

白石：今日は主にニュースタブにフォーカスしてお話を聞いていきますね。LINEのニュースタブは、なぜWebViewを使ったのでしょうか。

大槻：もともと記事ページはWebViewで作っていました。ニュースタブを作ろうという話になったときに、記事ページと同じ技術で作るほうが開発スピードも早いし、やりやすい。バージョンアップなども、そろえたほうがリリースしやすいということでWebViewで作ることになりました。

白石：じゃあ、ニュースタブ以外はネイティブでできているんですね。

大槻：そうです。トークやタイムラインなど、メインの機能はネイティブで実装されています。並んでるタブの中だと、ニュースタブだけがWebViewです。

白石：WebViewとネイティブといった複数の技術を混ぜるのって、大変だったんじゃないでしょうか。

大槻：ネイティブとWebView間でデータやイベントをやり取りする必要があって、そのための仕組みをアプリエンジニアと協力して実現しました。ユーザーにはLINEアプリの一部として見えるので、挙動やパフォーマンスに違和感が出ないようにするのが大変でした。

白石：WebViewだと、読み込みや表示が遅かったりしません？

大槻：いえ、結果的にそこまで遅いということはなかったです。Webだからの限界はありましたけど、WebViewだから特別つらいことはありませんでした。

LINEバイトやLINEギフトといったファミリーアプリにはすでにWebViewの技術が使われていて、知見があったことも役立ったんだと思います。

白石：React.jsを使っているとのことですが、SPA的な開発だとマークアップはそんなに必要じゃないと思うんですが、両方必要なのはどうしてなんでしょう。

富田：うちは分業体制をとっていて、僕と大槻さんが所属しているチームはフロントエンドを担当しています。案件によってJSとマークアップの両方を一人が担当することもありますが、newsでは規模の大きさもあって担当が分かれています。

デザインからHTMLを起こして、それを渡しているので、一般的に言われているReactを使うイメージとはちょっと違うかもしれません。

大槻：セマンティックなHTMLを書くとか、CSSを設計するといったところは完全にお任せしてします。一回組んだものを、パーツとして分解してJSXに落とし込んでいます。

白石：PCでも記事ページそのものは見られるんでしたっけ？

富田：記事ページは見られます。

白石：あ、レスポンシブ対応しているんですね。

富田：いえ、レスポンシブとかではなくて、PC専用に作っています。SNSなどでシェアされたURLはPCからでもアクセスできるため、PC用の記事ページを用意しています。

JavaとPerlでサーバー管理

白石：サーバーサイドでJavaとPerlという複数言語を使っているのはなぜですか？

森藤：もともとPerlで全体が作られていたのですが、社内の方針で最近はJavaで作ろうという流れになってきています。なので、最近のレポジトリとかはJavaで作ってます。まあ、歴史的背景です(笑)。

Perlはニュースタブと記事ページ、あと社内向けのCMSもPerlで作られています。

白石：へえ！CMSは自作なんですね。ちなみに、ReactはAPIを出すのに使ってるんですか？

森藤：はい、ニュースタブの部分は、全てAPIで実装されています。

白石：Reactでサーバーサイドレンダリングしているのでしょうか。

大槻：いえ、クライアント側でレンダリングしています。

APIでとってきたデータをローカルストレージにのせておいて、ネットワークがないところでも画面が真っ白にならないように工夫しています。

白石：JavaとPerlで分かれていますけど、システム間連携しているんですか？

森藤：データベースで連携しています。データベースはMySQLを使っています。

白石：MySQLをクラウド上で？

森藤：いえ、オンプレです。本番環境は、現在ほとんどオンプレのサーバーで動いていますが、最近構築したサーバーや開発環境はプライベートクラウドの「Verda」というサービスを使っています。

白石：えっ、どこかの製品を買うのではなく、自分たちで作ってるんですか。かっこいいですね。

森藤：DB周りはDBA（データベース管理者）のチームが運用しています。DBサーバーの構成は、マスター1台に参照やバックアップに使うスレーブが数台ある感じです。テキストで入稿するデータなので、データ容量が一気に増えて困ったとか、容量が足りなくなったという話も聞いたことがないですね。

白石：Javaで入稿システムを作っていらっしゃるんですよね。ScalaやKotlinなんかも使っているんでしょうか？

前澤：Javaだけです。最近のモダンな言語に比べると、やっぱりJavaは冗長というかすごいコード量を書かないといけないのは大変なんですが…。

白石：ぼくは昔Javaエンジニアだったのですごく気になるんですが、Javaのバージョンは何ですか？

前澤：Java 8です。

大槻：僕も前職では、エンタープライズ系のサービスをJavaで書いていました。その時はバージョンが古くて4でした。あと8をちょっと触ったくらい。当時はジェネリクスもアノテーションもなくて(笑)。

白石：僕はXML地獄でしたね(笑)。EclipseみたいなIDEとかは使ってますか？

前澤：Eclipseは使ってなくて、IntelliJ IDEAを使ってます。

React.jsを選択した背景は？

白石：フロントエンドのReact.jsはいつから使ってるんですか？

大槻：ニュースタブができてからなので、2017年2月からですね。

白石：苦労したこととかありますか？

大槻：React.jsだから苦労したことは特になかったんですが、どのライブラリにするかは結構検証しました。Vue.jsやRiot.jsなんかもいろいろ試してみたのですが、結局React.jsにしました。

Create React Appでベースを立ち上げた経緯もあって、最初の環境を整えるのはすごくスムーズでした。React.jsは結構書きやすくて、世の中で使われているアプリも多く、バージョンアップも早いし、安定していて信頼できました。

白石：なるほど。stateの管理とか、Reduxは使ってますか？

大槻：Reduxは最初は使おうと思ったのですが、意外と過剰なスペックがあってやめました。代わりにFlux Utilsを使っています。

足りない開発ツールはどんどん作る

白石：ほかにLINEさん独自の開発手法があれば教えてください。

大槻：フロントのアクセス解析はGoogle アナリティクスを使っているんですが、そのほかに社内で開発した「LINE Analytics」という解析ツールを使っています。JavaScriptのエラー部分もリアルタイムに収集できるので、リリース直後に増減を確認したりしています。

白石：LINEさんは結構社内で作る文化があるんですね。自分たちでも作るというのは、意思決定が必要だと思うんですが、どんなかんじで決めているんですか？

富田：その辺は結構自由にやらせてもらえる風土ですね。プロジェクトで使うツールだけでなく、たとえばメーラーやスケジュール管理といった社内システムについて内製する部署があります。既製品でもの足りなかったら、自分たちで作っちゃおうみたいな。

大槻：分業しているのでサーバーに触れること自体は少ないんですが、JSやCSSの配信ツールをフロントエンドチーム内で開発したりと、役割内で足りないものは作って配布させたりする人が多いですね。

サーバー側はCIも自前で作ってると聞きました。社内の承認フローがそれほどかたくないので、わりと気軽に自前で作ってます。

白石：CIもですか！Jenkinsとかを使わずに？

前澤：Perlでは内製のCIを使っていますが、JavaではJenkinsを使ってビルドしていて、ビルドした成果物をサーバーに配布するシステムは内製です。CDNのオリジンサーバーも自作してますね。

秒間2万のアクセスを捌くパフォーマンス

白石：パフォーマンスなんかもかなり気をつかっているんじゃないでしょうか。

森藤：はい。APIアクセスが秒間2万くらいのアクセスがあるので試行錯誤しています。APPサーバーの台数は約30台くらいなんですが。

森藤：去年の6月に高速化プロジェクトがあって、CDNを追加しました。CDNはAkamaiを使っています。クエリーをちゃんと書いてなかったりするとサービスが止まるので、SQLには気をつけてキャッシュに貯めるようにしていますね。

白石：フロントエンドのパフォーマンスで工夫した点はどうですか？

大槻：ニュースタブは縦に長いんですけど、DOMが増え過ぎるとメモリを食ってアプリがクラッシュしてしまう問題がありました。

iPhoneでは横スワイプでタブ移動できるので、左右のタブを予め描画している分よりDOMが多く、見えないDOMをいかに削除していくかなどの工夫をしています。

タスク管理・チーム間の共有ツールは？

白石：皆さんは所属する組織は違うとのことですが、「LINE NEWS」プロジェクトのタスク管理やチーム間の共有ツールはどうしていますか。

富田：ニュースチームのプロジェクトとして定例ミーティングをして、進捗管理しています。管理に使っているツールはJIRAですね。

白石：進め方はアジャイルですか？

富田：そんなにアジャイルぽくはないです。企画チームが20人くらいいて、案件ベースを作ってくれるので、早い段階で開発からもフィードバックしたり、企画と一緒に練ったりします。1週間のスプリント制でやっています。

白石：ニュースチームは全体で何人くらいいらっしゃるんですか？

前澤：企画や開発、制作、編集、アライアンス、モニタリング、PR・マーケティングなどを含めると、プロジェクトに関わっている人は100人を超えています。エンジニアは現在、バックエンドが8人、フロントエンドが4人です。

白石：大型プロジェクトですね。CIは自作されてるとのことでしたけど、DevOpsみたいな工夫ポイントはありますか？

前澤：これまでは五月雨で流動的だったけど、人が増えてきたので週1回のサイクルを整えたり、模索しているところです。

白石：ソースコードの管理やリリースのルールとかはどうでしょう。

森藤：ソースコードの管理はGitHubです。Perl側は最低2人レビュアーがいないとリリースやマージしちゃいけないことになっています。

急成長するサービスと開発体制に合った環境を構築

白石：最後に今後こうしたいという抱負や、チャレンジしたい目標を教えてください。

前澤：LINEのサービスが急速に成長して、エンジニアも増えているので、開発時期によってリポジトリやフレームワークの使い方も違ってきています。それを統一したいと思っているんですけど、結構大変そうです(笑)。

森藤：これまでのサーバーサイドはほとんどPerlだったんですけど、ここ数年みんなJavaを書くようになって、Perlを書くエンジニアが減ってきているんです。サーバー側をもっとJavaに置き換えていけたらと思ってます。

大槻：TypeScriptを導入も検討していきたいです。依存するライブラリの都合もあって、簡単ではないかもしれませんが。

富田：ニュースのプロジェクトが始まったのが2013年で、最近では更新が滞っているruby-sassやgrunt、compassといった古い環境に依存しており、日々の更新に忙しくてそういった根幹部分はなかなか手を入れることが難しかったんですが、最近のリリースで、タスクランナーに依存したコンパイルをやめたり、node-sassへの移行したりしました。

それに伴ってチームで使っている社内用のツールやsassのライブラリを更新しているので、今後も新しい技術についてそれらに生かせるか検証しつつ対応できればと思っています。

白石：LINEさんは独自の開発ツールをどんどんつくっていく行動力と技術力が素晴らしいですね。今日はいろいろ面白い話をありがとうございました！

LINEさんでは、9月28日(木) にエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2017」を開催するそうです。LINEの様々なサービスにおける技術領域でのチャレンジや開発体制などについて語られるとのことなので、興味のある方はぜひ参加してみてください。

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、エンタープライズ・アーキテクチャについて取り上げます。

HTML5・モバイル・IoT・ウェアラブルなどビジネス環境が激変する中、エンタープライズ・アーキテクチャはどういう課題を抱えていて、どうあるべきなのか。今回は、JJUG (日本Javaユーザーグループ）でご活躍中のお二人に話を伺うことにしました。

アーキテクチャを主軸に第一線で活躍しているグロースエクスパートナーズ株式会社 執行役員の鈴木雄介さんと、「流しのアーキテクト」を自称する株式会社アーキテクタス 代表取締役の細川努さんを交えて、エンタープライズ開発出身の白石俊平編集長がさまざまなトピックスをぶつけていきます。

XML Webサービスは今どうなったのか

白石：とりあえず、昔話から軽く聞いてみたいですね。まずは、エンタープライズ内のシステム間連携でよく話題に上がる、SOAPとRESTについての現状について、どうお考えでしょうか？

鈴木：SOAPは下火だと思われがちですが、私の知る限り、今でもよく利用されています。RESTとJSONの組み合わせも当然よく使われているんですが、（SOAPは）WSDLで型定義ができるので、それなりにかたいシステム間連携だったりすると、WSDLがあるほうがコードの自動生成もできるし、非常に楽なのでよく使われています。

　　 ▲グロースエクスパートナーズ株式会社 執行役員 鈴木雄介さん

細川：とはいえ、SOAPの上位レイヤで規定されているWS-ReliabilityだとかWS-Securityなどの様々なプロトコルは、あまり使われていない印象です。

白石：では、システム間連携などではプレーンなSOAPがよく使われているということですね。

鈴木：まあSOAPもRESTも用意する、というパターンが多いんじゃないでしょうか。オブジェクトモデルは同じで、それをSOAPでもJSONでも表現できるように設計しておくというパターンは、比較的多いような気がします。

細川：あと僕が気になるのは、スケーラビリティなんですよね。SOAPだとちょっと気になるのはやっぱりシリアライズ・デシリアライズの処理が重いし、トラフィックも増大するじゃないですか。そういった意味だとやっぱりREST + JSONのほうにもメリットがありますね。本来だったら使い分けみたいなところが重要なんですけど、いまだにSOAP一択という開発現場も多い。

　　　▲株式会社アーキテクタス 代表取締役 細川努さん

白石：どっちかに寄せちゃったほうが考えることが少なくて、楽ってこともあるかもしれないですね。

鈴木：一長一短…というとつまらない話になってしまいますが（笑）、実際のところそういう結論になっちゃいますね。HTML5が盛り上がっている現在、JavaScriptと相性が良いJSONにはすごく価値がある。一方で例えば、日付型をどう扱うんだとか、型定義やコードの自動生成がしづらいというJSONには苦手な分野もあるのですが、SOAPはそういう部分に強い。「SOAPはXMLだからダメ・ダサい」ということは、実際のシステム開発には全く当てはまらないと思いますよ。

エンタープライズアーキテクチャパターンは今も有効か

白石：アーキテクチャという点では、マーティン・ファウラーのエンタープライズ アプリケーションアーキテクチャパターンが昔は王道だったかとと思うんですが、それは今も有効なんでしょうか？

鈴木：あれは普遍的なものなので、時代が変わったからといって使えなくなってしまうようなものではありません。ただ、昔と比べると今はWeb API主導型のアプリケーションが主流になりつつありますね。クライアントのマルチデバイス化は当然エンタープライズでも相当重要なので、「サーバー側はAPIを提供するだけ」というスタイルに移行しつつあるのは、Webでもエンタープライズでもまったく変わらないと思います。

白石：具体的には、JAX-RSを利用するとか？

鈴木：JAX-RSもありますし、JSON用のバインディングAPIもJava EE 7で標準化されたので、何の違和感もなく使えますね。

細川：エンタープライズ アプリケーションアーキテクチャパターンは非常に洗練されていたのですが、実際のエンタープライズ・アプリケーションはもっと泥臭いです（笑）。 例えばマーティン・ファウラーの提唱するモデルだと、プレゼンテーションレイヤからデータレイヤまでが3、4層ぐらいなんですが、実際はビジネスロジックだけで3層以上に分けたりとか、ビジネスロジックとプレゼンテーションの間にいろいろ挟んだりとか、端から端まで数えると下手したら10層ぐらいあるものも実際のプロジェクトでは山ほどありました。

白石：僕もそういうプロジェクトをやったことがあります。なんか別のメソッドを呼び出してるだけのメソッドが大量にあったり（笑）。

細川：そうそう。なので、どちらかというとほんとに綺麗なレイヤリングはできてなかったというのが現実ですね。最近、６〜７年以前につくられた数十万ステップくらいのシステムをいくつか実際に解析してみたんですけど、結構面白い結果が出たんですよ。サーバーサイドJava（JavaEE）としては最新ではなく、まだJ2EEと呼ばれていた頃のシステムです。どのシステムも、一番複雑度が高いのはビューとデータアクセス（永続化）、アーキテクチャ共通系のモジュールです。ビジネスロジックの部分は量は膨大なんですけど、複雑度自体は比較的シンプルなんです。

何が言いたいかというと、古い世代のサーバーサイドJavaは、ビューとアーキテクチャ制御に作り込みが必要で、そこのところが本当に大変だった。例えば、ビューのところのバリデーションなんかは、かなり作り込みが必要で、簡単な画面作るのも相当手間がかかってたんですよね。結局は、かつてのJava EE（J2EE）って、エンタープライズ系プログラマーが本来集中すべき業務上のロジックにあんまり集中できていなくて、もっと簡単にできるはずのところに手間がかかっていたのが現実だったんじゃなかったかなと。

白石：ほんとにそうですよね。オブジェクトの変換とか、別のメソッド呼び出すだけとか、ファサード作ってそこに一生懸命集めるだけとかやっていて、なにやってるんだろうこれは…とか思っていました。

細川：以前はそうでしたね。そのレガシーなところが今はみんなの足を引っ張ってる（笑）。現在は、それがどれだけ良くなってるか、というところですよね。

白石：今の流れをまとめると、ビューの複雑なところっていうのが、だんだんクライアント側に寄ってきていて、ようはHTML5でリッチクライアント化されてきて、サーバー側はAPIを提供しているだけになっていると。

鈴木：大きくはそうです。ただ、エンタープライズシステムの場合、とにかくシステム間連携が多くて、1つの企業の中でいろんなシステムがあって、ほとんどのシステムが関連付いているのが当然になっています。そうするとクライアント側からするといろんなシステムにいちいちログインして使うのは面倒くさいので、どうやってシンプルに使うのかというのが今の大きなテーマになっていると思います。サーバー間で連携したり、クライアント側でアグリゲーションしたりというのが今の課題としてあって、エンタープライズの場合は、そこがシンプルにならないので、それがひとつの前提になっています。

白石：なるほど。そのシステム間連携がさきほどおっしゃっていたようにXMLベースだったり、RESTだったりという感じですね。

鈴木：はい。企業って、いろんなユーザーといろんなシステムがあるので、いわゆる一般コンシューマー向けのECサイトのようなシステムもあれば、例えば人事システムみたいなものもありますよね。人事システムだと、人事部だけが使うのでユーザーが10人しかいなかったり、でも社員数10万人を支える人事システムっていうと相当でかいっていうものだとか。じゃあその2つが同じアーキテクチャで、同じ作り方でいいんですかっていうと全然そうじゃないですよね。

企業の中のさまざまなシステムの中で、HTML5に合うものもすごく増えてますし、HTMLの可能性が広がったことでやれることもすごく増えましたが、一方でそれが銀の弾丸ではないです。ここはRESTでつくったらいいよねとか、ここはWSDLがちゃんとあってSOAPでやったほうがいいよねっていうのがある。そこは全体の中での選択してやっていけばよいことです。エンタープライズの人って古めかしい人印象があるかもしれないですけど、新しいことも古いこともやらきゃいけないので、そういう意味ではちゃんとまともにやっている人は、それを両方うまくバランスよくやっていますね。

エンタープライズとモバイル

白石：最近のエンタープライズ業界に疎くて、初心者的な質問で申し訳無いのですが、モバイルをエンタープライズで使うというのはもうかなり普通に行われていることなんでしょうか。

鈴木：そうですね。モバイル、タブレット、PC、専用の機器とか、何を何に使うといいよねっていうユースケースはちゃんと考えなきゃいけないですが、モバイルはものすごく重要なツールとして使われています。

白石：エンタープライズでモバイルといえば結構HTML5が使われているという話を聞くのですが、実際そうなんですか？コンシューマ向けだと、ネイティブアプリが全盛です。

鈴木：そもそもモバイルという文脈で求められる操作性とか機能が、エンタープライズの場合はそんなにネイティブでやらなくてもいいようなものが多いので、HTML5がフィットしてるんじゃないかと思います。例えば、ゲームはネイティブアプリがいいといわれますが、別にあそこまでビジュアル的なものとか、細やかな操作性はあんまり求められることはないと。

なので、HTML5でやるっていうのは多いんじゃないでしょうか。Webアプリであれば、リリースも楽ですしね。去年ぐらいまでは写真とか音声とかでいろいろやろうとすると、まだまだHTML5では制約が多いということでネイティブアプリという選択もありましたが、そうした制約もブラウザが進化してきてだんだん問題にならなくなってきています。

白石：なるほど。ちなみに、そうしたHTML5で書かれた業務アプリは、ハイブリッドアプリとしてインストールする形が多いのか、それともWebサイトとしてURLでアクセスする形で作るんでしょうか。

鈴木：それは両方あります。どちらにも利点があるので。

クラウドがアーキテクチャに与えた影響は？

白石：これも初心者的な質問で恐縮です。クラウドがエンタープライズのアーキテクチャに与えた影響はありますか。

鈴木：もちろんあります。クラウドができたことで一番大きかったのは、PaaSという概念ができたことですね。あるニーズに特化したものっていうのは共有化されたものが使われるべきだっていう概念がはっきりしたのはPaaSのおかげです。例えばAWSのラインナップを見て貰うとわかるんですが、CDNありますねだとか、ロードバランサありますねだとか、ストレージ、サーバーノード、認証認可とか、メールの配信サービスとか、ああいうものはPaaSとしてみんなが共有して使うべきだという概念ができた。

なので、そういうプラットフォームを用意してその上にアプリケーションを作って、アプリケーションはUIを含めてそれだけに特化して、なるべくプラットフォームの機能をうまくつかってやっていくていうアイデアは、今のエンタープライズでも浸透している考え方だと思います。

細川：開発者視点でいうと、開発者ができる領域が増えてきましたね。従来だと、サーバ構築とソフトウェア開発は別々のものでしたが、プログラマーがだんだんとクラウドを前提にして、環境を構築するようになってきた。そうすると、同時にパフォーマンスだとかセキュリティだとかをエンジニアが自分で考えなきゃいけない時代になってきていて、Webエンジニアだとかエンタープライズエンジニアとかの区別はなくなってきている。そういう意味では、フルスタックで両方できなきゃまずいんじゃないでしょうか。

鈴木：もうそれはエンタープライズでも間違いなくそうですね。

細川：もうひとつの特徴としては、昔は大規模＝エンタープライズということが多かったんですが、今ではコンシューマー向けとかゲームだとか、そっちのほうがより大規模なんですよね。それを実現しているのがやっぱりクラウドなのかと思っています。そういった意味でも、これからはWebエンジニアこそ大規模を得意にならなきゃいけないんじゃないかと。サーバーとクライアントのメッセージの単位なんかもパフォーマンスに大きく影響するので、そういったところも、かなりノウハウを積まないといけなくなってきています。

エンタープライズ・アーキテクチャの未来像

白石：IoTとかウェアラブルとかを見据えて、今後どういうふうにエンタープライズ・アーキテクチャが変わっていくべきか、ご意見はありますか？

鈴木：IoTを真剣にやろうとすると、先ほど細川さんが言っていた大規模っていうのがエンタープライズに戻ってくるんですよね。対応するデバイスの数が、今まではユーザーが数万人ですんだのが、億になるかもしれない。例えば、すべてのダンボール箱にチップがついたらどうなるんだろうっていう世界を考える。そうすると日本で流通しているダンボール箱は何箱あるんだとか、ものすごいクライアントの数になってしまう。そうなってくると、エンタープライズがまた大規模な性能を頑張らないといけなりますね。

例えば、わかりやすい例でB2Bのケースを考えると、トラックをトレースする仕組みを作ることになったとします。じゃあ全国にあるトラックを全台管理しますとなったときに、全部で何台あるのか。1台のトラックにセンサーがいくつついているのかということになると、センサーが車輪それぞれにあって、それぞれのタイヤのすり減り方を計測して、運転手が寝てるんじゃないかというのを監視するセンサーがあって、速度・加速度をとるセンサーがあって…というようにトラックにすごい数のセンサーがある。

そして、トラックを1万台管理します、データを500msごとに取るとすなると、ものすごい数になる。つまり、B2BでIoT、ウェアラブルというのはB2Cのスケーラビリティをエンタープライズでもう1回頑張らないといけないということになる。今、Webの人が大規模で頑張っているテクノロジーセット、例えば大量のストリームを処理しながらイベントドリブンでやるっていうのは昔からエンタープライズにあって、それがWeb側ですごく実用化されて使われていたのが、またエンタープライズに戻ってくる。そういう流れが未来にはやってくるんじゃないかなと考えています。

白石：なるほど。ちなみに、もう実際にIoTの案件とか発生しているんでしょうか。

鈴木：相談はかなり増えてきてますね。まだ実証実験ぐらいが多いという感覚ですが。今は車がうまくいっていて、ホンダの事例がわかりやすいです。日本中の車のブレーキの発生情報を集めてるんですけど、それを解析すると事故が発生しやすい曲がり角がわかるんですよね。みんながたくさんブレーキを踏んでいる曲がり角がどこかっていうのを提供しているんですよ。そしたらそれを元に道路の信号とか標識とかを改善するってことをやっています。

まとめ

白石：本日は、エンタープライズ・アーキテクチャについて様々なご意見をいただき、誠にありがとうございました。最後に、読者に向けて一言お願いします。

鈴木：自分たちの生活を考えると、やっぱりエンタープライズ業界の会社が自分達の生活を支えてるわけじゃないですか。それがより便利になったり、役立つようになったり、世の中が進化するっていうのはとても大事なことだと思うんですよ。なので、それが実現されるためにはどうしたらいいのかっていうときに、エンタープライズとかWebとかそういう区切りはどうでもよくて、どうやれば本当に価値がでるのか、そういうのを考えるのが面白い。

ただ、社会基盤として変えてはいけないところもエンタープライズにはどうしてもあるので、それをどのように変えずに、より新しいことにトライしながら今あるものの価値をより高めるのかというところが大事ですね。なので「エンタープライズwww」という風潮はよろしくないと思います（笑）。

細川：2点あって、ひとつは、今までのエンタープライズ開発は、ユーザーの言われたものを作るという風潮が多かったんですが、今後はユーザーと一緒につくるっていうのは大事になってくるんじゃないかと考えています。そういう意味ではエンタープライズ業界もWeb業界と同じようにUXとか、よりユーザーが求めるものは何かというところを柔軟に対応してかなきゃいけない。エンタープライズもWebに学ばなきゃいけないということ。

もうひとつは、今後、変化がたくさんあって、それに対応するためにエンタープライズ側、Web側が両方対応しないと対応できないんじゃないかなと思う。これらの技術の変化に対応できるようにフルスタック、両方できるようなエンジニアが増えてくると心強いんじゃないでしょうか。

はじめに

HTML5が2014年に正式勧告されることを受け、フロント業務アプリケーションに影響を与えています。より多くのことがHTMLやCSSでできるようになり、現場レベルでは開発スタイルそのものの見直しも行われています。実際、私が担当しているプロジェクトではJava中心の開発からHTML、CSS、JavaScript中心の開発へと開発環境を変えています。具体的に何をどのように変更しているのかを、私が担当しているプロジェクトの内容に沿ってご説明したいと思います。

私が携わっているシステムは「営業が客先面前で使用するアプリケーション」を作成しています。アプリケーションとしては、基幹システムというより営業支援システムあるいは営業コンサルティングシステムにあたります。ここではアーキテクチャの詳細に関する説明は割愛させて頂きます。それぞれの事項についてはURLを記載していますので、該当サイトをご参照ください。

従来型のWebアプリケーション

JSPを用いたWebアプリケーションは

1. リクエストをサーバへ送りサーブレットであるControllerへ送付する
2. Controllerは必要な情報をPOJO → Business Logic → O/Rマッパー → Databaseで取得（登録・更新）する
3. ページをJSPで生成しController経由でクライアントへ返却する
4. 各ページではAjaxにより部分的な情報の取得を行う

従来型のWebアプリケーション開発では、ほとんどを「Java」で実装しています。

JavaScriptでの処理は

• 簡単なポップアップ画面ライクな画面表示
• Ajaxを利用して情報をその都度取得

を目的として使用していました。

JavaScriptフレームワークを用いたWebアプリケーション

JavaScriptフレームワークを用いたWebアプリケーションで何がどう変わったか？従来型Webアプリケーションとの違いは、画面遷移も含め、ほとんどの処理をJavaScriptで作っているということが大きく異なります。

1. HTMLで作成された画面を表示
2. 必要な情報をRESTで取得（登録・更新）し、画面へ表示する
3. 取得したトランザクション情報をWeb Storageへ格納する。プルダウン等で使われるマスタ類はJSONで作成し、クライアントへ配置する
4. 以後、画面とWeb Storageで情報のやり取りを行う
5. 一連の業務完了後、データをRESTでサーバへ送信し、Web Storageのデータとサーバ上に配置されたデータベースとの同期を行う

このWebアプリケーションでは、ほとんどの処理をJavaScriptで作成しています。Javaは「情報を永続化するため」に使用されます。JavaはWebアプリケーションのバックエンド機能としての役割に特化しています。このことは、「業務系システムは今すぐ脱Strutsを！」業務システムエンジニアのためのHTML5勉強会#04 活動報告で寺田氏が挙げているように「次世代型WebアプリケーションとJava標準『Java EE 7』」であると考えています。

注意することとしては、「一連の業務完了」というものが、業務アプリケーション毎に異なる点です。在庫管理に、直にサーバに確認したいようなアプリケーションでは頻繁に発生しますが、ライフプランニングのように一日や数日経過しても問題ないようなアプリケーションでは時間枠が異なります。後者のケースでは特にWeb Storageの機能が本領発揮となるでしょう。

Web StorageやApplication Cacheを使うメリット

Web StorageやApplication Cacheを利用することで、サーバとの通信を行わず、ページ切り替えをブラウザ内のみで処理することができます。従来型ではページ切り替え時の通信時間に、少なくとも数秒要していましたが、この時間を発生させないためのレスポンスに有利になります。

これはユーザビリティの向上にとって非常に重要なことです。従来型のWebアプリケーションではもっさりした感覚のあるものがほとんどでしたが、Web StorageやApplication Cacheの恩恵により、限りなくファットクライアントに近いリッチクライアントを作ることができます。

開発スタイルがどう変化したか

開発のウェイトがJavaからJavaScriptへ移ったことにより、アプリケーション開発環境も大きく変化しています。従来型では

• Eclipse or NetBeans
• maven
• svn
• JUnit & DBUnit
• Jenkins

が主たる開発環境でありましたが、JavaScriptフレームワークを用いたWebアプリケーションでは

• sublime textとか何でも
• Yeoman(yo, grunt, bower)
• Jasmine
• git & github
• travis

といった開発が有用です。

「開発者にとって開発環境がすべて」という表現をされる方もいますので、ここで少し私が使用している開発インフラYeomanについて触れたいと思います。

Yeomanはyo、grunt、bowerの3つのツールで構成されている「Web App Development Through Tooling」です。それぞれの役割はYeomanのサイトから引用すると次の通りです。



Yeomanは次の目的のために使用しています。

1. yoによるテンプレートの作成。
2. bowerによる依存関係を管理
3. gruntによるアプリケーションの開発およびリリースビルド

特にビルドプロセスでは

• JavaScript/CSS等の圧縮
• JavaScriptに対してUnitテストを実施

などを行っています。テンプレートに関しては必要となるJavaScriptフレームワーク、ユニットテストツール、altJS、Sass/Compass、csslint、jslint等が含まれています。このテンプレートは初めから作成することも可能ですし、すでにあるテンプレートをカスタマイズして利用することも可能です。一般的にプロジェクトで使用する場合はある程度カスタマイズした方が良いでしょう。grunt、bowerですが、mavenやantを利用したことがある方ならイメージがつきやすいかと思います。Yeomanの詳細については次の機会に紹介します。

当然ですが、サーバサイドのモジュールを開発するときには従来型の開発環境を使います。

開発要員構成

JavaScriptフレームワークを用いたWebアプリケーションの開発により、開発要員のスキルセットが変化しています。従来型ではそのほとんどがJavaエンジニアで

• Javaエンジニア：24名
• デザイナー：1名
• その他スタッフ：3名

したが、Web 開発では

• Javaエンジニア：3名
• JavaScriptエンジニア：21名
• デザイナー：4名
• その他スタッフ：3名

です。これはあるプロジェクトの要員バランスですが Javaエンジニアが 1/8 に成ってしまったことはエンジニアにとっては感慨深いものがあります。

JavaScriptフレームワークの導入

JavaScriptでのコーティング量が増加しているため、実装を整理する意味においても JavaScriptフレームワークの導入検討を行うのは有用だと言えます。様々なところで言われていることですが、フレームワークの導入は「処理を系統立てた仕組みにのせプログラマの作業の効率化とアプリケーションの保守性を高めること」にあると考えています。

すでにJavaScriptフレームワークは数十種類以上あります。私のプロジェクトでは Backboneを使用しています。Yeomanを用いることでBackboneを利用する環境を容易に導入することができ、

• データバインディングとカスタムイベントを備えたModel
• ModelのイテレーションであるCollection
• イベントをハンドリングするView
• サーバサイドのアプリケーションと連動するためのRESTful JSONなど

が、提供されます。 



このフレームワークはその名の通り骨組みの提供であり、実質的には、Requirejs、Underscore、jQueryの恩恵を受け、強固なフレームワークになります。 Requirejs は JavaScript ファイルのモジュールローダーです。呼び出す JavaScriptファイルを定義できるので、コードの品質を向上させることができます。 Underscore は、JavaScript のユーティリティ郡です。

JavaScriptフレームワークを用いたWebアプリケーション開発におけるもうひとつの変化 業務アプリケーションはあまり画面に動きのあるサイトは作りませんがボタンの形状やグラデーションは頻繁に利用します。従来pngで作成していた

• イメージボタン
• divの角を丸める

といったことがCSS3で作成可能となったことから、カスケードスタイルシートのコーティング量が急増しています。そのため、デザイナーでもある程度のHTML、CSS実装ができることが要求されています。

開発インフラとしては、例えば

• Sass & Compass

の導入により、より効率のよいアプリケーション開発を行うように なっています。私の考えですが、CSSはHTMLの表現を定義する設定ファイルの位置付けは、Sass/Compassによりプログラム言語としての位置付けに移ったと考えています。 Sass は CSS にはない次のことが可能で、CompassはCSSオーサリングフレームワークです。

• 変数
• セレクタのネスト
• ミックスイン
• セレクタの継承

SassとCompassを利用するためには、ビルドが必要になります。そのためgruntによるビルドを行います。Yeomanで作成したテンプレートには、livereloadという機能が含まれていて、開発環境を常に監視していて変更があるとビルドしブラウザへ変更内容を適用します。

CoffeeScript の導入メリット

全体像としては、JavaからJavaScriptへの開発ウェイトが移っています。開発に携わるすべてのプログラマーが正しく、JavaScript モジュールを開発できるスキルを有する必要があります。「モダンな言語でHTML5を開発しよう！俯瞰して理解するaltJSの比較（前篇 – TypeScript, CoffeeScript, Haxe）池田 泰延」でまとめられているように、「altJS」はスマートにコードを書くための仕組みが用意されています。詳細についてはそちらをご参照ください。

私のプロジェクトでは、CoffeeScriptを導入しています。導入メリットを何点か挙げると

• コーティング量が少ない
• JavaScriptの罠に引っかからない
• 書き方がある程度統一される

ということがあります。特に

• varの書き方（varの書き忘れ）
• this の定義
• returnの明確化
• == と === の違い

等がありますが、これらをCoffeeScriptがうまく補完してくれています。 CoffeeScriptもSass/Compass同様にビルドが必要になります。やはり、gruntによるビルドを行います。

JavaScriptのセキュリティ

JavaScriptでのコーティング量が増えたことから、JavaScriptのセキュリティについてもより多くのことを考える必要があります。

• ロジックをオープンソース化してしまうこと
• Web Storageにある情報が読み取り可能

JavaScriptに関しては難読化、情報に関しては暗号化してからWeb Storageへの保存等、考慮すべきことがいくつかあります。

最後に

HTML5の到来により、今までとは異なるアーキテクチャでの実装が必要となっています。アーキテクチャが変わったことにより実装環境も大きく変える必要が当然あります。これからはJavaScriptコーティングスタイルに合った開発環境を作るべきだと考えています。ここで述べた開発スタイルは、まだエンタープライズでは少数。いずれくるであろうHTML5時代の準備を今からするのは有効と考えて間違いないでしょう。