前々回、前回と業務アプリのフロントエンドについて主に説明しました。今回は、バックエンドに焦点を当てて説明を行います。

業務アプリの多くは、ブラウザーを通じて利用されるWebアプリ方式で提供されます。この場合、サーバー側でJavaやPHP、Rubyといった言語を用いてサーバーサイドプログラムが実行されます。もちろんHTML5やJavaScriptを用いてリッチなWebアプリを実現することができますが、その場合においてもビジネスロジックのほとんどはバックエンドに記述されてます。

一方、モバイルアプリの世界では、この割合が大きく異なります。たとえば、バックエンドの機能は、フロントエンドと連携するためのAPI機能が中心となります。フロントエンドについては、HTML5で開発しようと、ネイティブで開発しようと、バックエンドから受け取ったデータを表示したり、データを編集してバックエンドに送信するといった機能が必要とされます。

異なるスキルセットが必要

処理がバックエンドとフロントエンドに分散する問題点の一つは、アプリ開発のスキルセットが異なることです。フロントエンド開発では、ユーザビリティに関する知識や、HTML5やJavaScriptといった言語の理解が必要となります。一方、バックエンド開発では、ビジネスロジックの理解と、フロントエンド開発とは異なるサーバーサイド言語の知識が必要です。エンジニアが両者を一手に引き受けるのは簡単ではありません。

また、バックエンドにおいても、モバイルアプリに特化した機能を求められるケースがあります。たとえば、任意のタイミングでアプリに情報を送信するプッシュ通知や、App StoreやGoogle Playストアを経由せずにアプリを配信する機能、モバイルアプリからユーザー認証を行う機能などです。これらはネイティブ機能を用いて実現され、フロントエンド側にも対応する機能が実装されている必要があります。

さらに、業務アプリを考える上でバックエンドに求められる最も重要な機能は、既存システムとの接続です。これは、既存の業務システムやイントラネットに配置されたデータベースと連携するために必要です。そのためには、ファイアーウォール内に配置された各種システムにインターネットを経由して接続する仕組みを構築する必要があります。

こういったモバイル特有の課題を実現するために、専用のバックエンドをゼロベースで開発することは非現実的です。そのために、クラウドやパッケージ形式でモバイルバックエンドを提供するソリューションが存在します。これらのソリューションを使うと、フロントエンドの開発者はバックエンドの知識に乏しい場合でも、安全に業務システムに接続したり、モバイルアプリの機能を実現することができます。

既存システムとの接続

業務システムの運用では、社内ネットワーク（イントラネット）だけでなく、ハイブリッドクラウドやSaaSといったクラウドサービスを利用しているケース、そして両方を使い分けているような場合も考えられます。まずは、こういった多彩なシステムに対していかに接続するか、という観点が重要になります。

接続先として考えられるのは、ERPやCRMといった基幹系システム、Active DirectoryやLDAPといったユーザー管理システム、グループウェアやメールシステムといった情報系システムが挙げられます。B2Cアプリのバックエンドに求められる、FacebookやTwitterなどのソーシャル連携や、広告配信システムなどとは大きく異なることが分かります。

企業モバイルの典型的な接続先

開発後の運用基盤

また、アプリ運用時の基盤についても考慮する必要があります。具体的には、アプリケーションの配布や更新を管理する機能、ユーザーやデータの権限を管理する機能、そしてエラーログや利用状況などを一元的に把握する機能などが挙げられます。

アプリのインストール数が数万台を超えるB2Cアプリと比べて、B2BやB2Eアプリは数十から数千台が中心となります。端末やアプリ管理を集約することで、運用にかかる工数を抑えることができます。

MEAPはスモールスタートに向いていない

モバイルエンタープライズの開発・運用基盤として、これまで中心的な存在であったのはMEAP製品です。MEAPとは、Mobile Enterprise Application Platformの略で、2008年にガートナー社が提唱した概念です。

MEAPは、エンタープライズ向けモバイルアプリに要求される、長期的な開発～運用を担う総合的なソリューションの総称です。MEAPソリューションの具体的な例としては、IBMのWorklightやKonyといった製品が挙げられます。

MEAPの大きな機能の1つに、クロスプラットフォーム開発が挙げられます。実はどの製品も、第1回で紹介したCordovaフレームワークをベースにしており、HTML5ハイブリッドアプリとして開発されます。

MEAPにも問題点があります。それは、オールインワンとしての利用が前提となるため、どうしてもソリューションとしての規模が大きくなってしまい、それに伴い、値段も上がってしまうことです。特に、モバイルプロジェクトはスモールスタートすることが多いことから、MEAPは向いていないと判断される例が少なくありません。

また、モバイルアプリの開発では、様々なツールやサービスを組み合わせてアプリを作っていくことがよくあります。たとえば、プッシュ通知やテスト配信、アプリ管理などに特化した専用ツールが提供されています。MEAPを利用した場合に、こういった外部ツールとの連携がとりづらくなり、結果としてオープンな環境で開発できないといった懸念があります。

エンタープライズ向け次世代モバイル基盤

その中で、次世代モバイル基盤とも言える、新たなエンタープライズ向けのバックエンド基盤が登場しています。2013年末に発表された米Yankeeグループの調査結果によると、サービス形式でバックエンド基盤を提供するMBaaSプロバイダーは既に一般的な存在になっており、より優れた技術を持ち、顧客ベースが確立している成長企業が今後主役になるだろうとしています。

エンタープライズ向けモバイルバックエンド

その中の1社であるKidoZen社を紹介したいと思います。KidoZenはエンタープライズに特化したバックエンドを提供しており、クラウドだけでなくオンプレミスでの運用にも対応しています。イントラネット内で稼働する各種ユーザー認証基盤やデータベース製品に接続できるだけでなく、Salesforce.comやOffice 365といったクラウドベースのサービスとも連携できます。データ仮想化によるセキュリティ向上や、バックエンドの利用統計といった機能も搭載されています。

今後は、こういった単体でも利用でき、様々なツールと組み合わせて活用できるバックエンド基盤ソリューションが普及すると考えられます。使い勝手の面や、導入や運用コストが、従来のMEAP製品と比べて優位であるためです。

ただし、こういった製品には開発機能が含まれていません。そのために、HTML5開発プラットフォームであるMonacaやアプリカンといったソリューションと組み合わせた開発が広がっています。実際に、ガートナーは2013年、MEAPに代わってMADP（Mobile Application Development Environment）という概念を紹介し、開発機能とバックエンド運用機能を別軸で捉えはじめています。

モバイルソリューション全般に言えることですが、バックエンドもテクノロジーの進化が早く、ともすると大きな投資の結果、半歩遅れのものができあがるということも考えられます。一方で、エンタープライズ向けのモバイルアプリ開発ソリューションの選択肢も広がってきました。ツールやサービスを組み合わせることで、開発と運用効率を高めることが、今後も求められることになるでしょう。

エンタープライズモバイル開発で求められる要件については、前回の記事で概説しました。特に、BYODと相性の良いマルチプラットフォームの仕組みや、開発チームの統一、Webとネイティブアプリの両刀対応など、業務で使うアプリならではの特有ニーズがあることが、エンタープライズの特徴です。

この分野では、B2CやPCの世界と比較しても、HTML5が大きな注目を受けています。その背景には、HTML5がモバイルアプリ開発、とりわけ業務アプリ開発との親和性が高いことが挙げられます。

実行速度よりもコストメリットが優先

「モバイルアプリ開発をHTML5で」というテーマで話をした際の反応として、HTML5だと速度が遅くて使いものにならないのでは、という懸念の声が挙がります。確かに、フルネイティブコードで書かれたアプリと比較すると、ブラウザーエンジン上で動作するHTML5アプリは、スピードのボトルネックが発生しやすのが事実です。とはいえ、「ネイティブかHTML5か」が中心テーマだった3年前と比較して、現在は端末の性能が、Android 2.3やiOS 4が主流だった当時と今では大きく状況が異なります。

参考のため、下記にAndroid端末の性能推移を紹介します。4年前の端末と比較して、10倍以上の性能向上が行われていることが理解できます。

Android端末の性能推移

出典: AnTuTuベンチマーク

アプリの実行パフォーマンスの点では、App Storeでトップ10を狙うようなコンシューマーアプリとは異なり、業務アプリで求められる必要十分な速度を満たせば問題ありません。フレームワーク選定の際に、速度重視のJavaScriptライブラリー（Onsen UIなど）の採用を考慮することで、HTML5でも満足できる実行速度が達成できます。

それ以上に、次節の通り、開発時には下記にあるようなメリットがネイティブに勝ります。

HTML5が業務アプリに向いている理由

HTML5のメリットを一言で表現するならば、「つぶしが効く」というのが最も近いかもしれません。対応するOSの種類や画面サイズの広さもさることながら、使用技術やハイブリッド化によるネイティブアプリ作成まで、アプリ開発エンジンとしてHTML5は高い汎用性を備えています。

マルチプラットフォーム・スクリーンサイズに対応

HTMLを使えば、モバイルやPCといった端末の種類を問わず、また、画面の大小を問わず、同じコンテンツを展開できます。もちろん、画面サイズに合わせてコンテンツの配置を変更したり、最適化したりすることはよく行われます。同じコンテンツでも表示端末に最適化するという考え方はレスポンシブデザインとも呼ばれ、具体的にはCSS3メディアクエリーがよく使われます。

Web技術者がヨコ展開できる

HTML5は既存のWeb技術の延長線上にあります。開発言語としてはJavaScriptが用いられますが、AngularJSやjQueryなどのフレームワークやライブラリーもモバイルでそのまま利用可能です。非常に制約の大きかったiモード向けCHTMLなどと比較すると、スマートデバイスのHTML対応度はPCとほぼ同等の機能を備えています。ActiveXやFlashを用いたサイトを除き、スマートデバイスで閲覧できないWebサイトはありません。

レンダリングエンジンの進化、今後はグラフィック性能向上が焦点

端末性能だけでなく、ブラウザーも至る所で進化が進んでいます。その中でも性能強化が著しいのは、グラフィック描画の分野です。モバイルブラウザーが最新HTML5技術の1つであるWebGLに対応することで、2Dや3Dのグラフィックがさらに高速化され、より高い表現が求められるアプリへの適用範囲が広がります。

HTML5ハイブリッドアプリでネイティブアプリ化

ハイブリッドアプリとは、HTML5で作られたネイティブアプリです。具体的には、ネイティブコードとHTML5を組み合わせており、HTML5をベースとした開発でありながらも、プッシュ通知やデバイスAPIといったネイティブアプリでないと実現できない機能を組み込むことができます。

モバイルアプリはHTML5ハイブリッドアプリの道へ

HTML5の技術でネイティブなモバイルアプリ開発ができるハイブリッドアプリは、Web由来のクロスプラットフォーム性能を持ちながらも、端末機能やOS機能にアクセスできます。オフライン対応やパッケージ形式での配布と自動更新など、Webアプリでは実現が難しい課題にも対応できます。

CordovaとPhoneGap

現在、HTML5ハイブリッドアプリのライブラリとしては、アドビシステムズ社が提供する「PhoneGap」がデファクトスタンダードです。また、このPhoneGapの開発元となっているオープンソースプロジェクト「Cordova」は、PhoneGapだけでなく、様々な製品に組み込まれ、エンタープライズソリューションとして利用されています。

Cordovaは様々なエンタープライズソリューションの基盤に

HTML5ハイブリッドアプリ開発の課題

HTML5ハイブリッドアプリにも課題があります。その最も大きなものは、ハイブリッドアプリに特化した開発環境がまだ少ないということです。Cordova/PhoneGapアプリ開発に対応したソリューションとしては、私たちが開発しているMonacaだけでなく、最近ではVisual StudioやSenchaなどの製品でもサポートが開始されました。

MonacaはCordova/PhoneGapに対応した開発環境で、クラウドを活用したプラットフォームとなっています。好きなエディタやIDEと組み合わせてローカルで開発することもできますが、ブラウザーベースのIDEを備えていたり、開発中のアプリをすぐに実機でデバッグできるMonacaデバッガー等の仕組みを用意しています。また、ビルド機能が組み込まれているため、SDK等をインストールしなくてもiOSやAndroid、Windows 8向けの配布パッケージを作ることができます。

開発環境の整備だけでなく、開発ノウハウを蓄積する場所、いわゆるナレッジベースも必要です。同じHTMLと言えども、Webサイトとモバイルアプリでは、情報設計の観点や実装上のポイントが大きく異なります。そのために、HTML5ハイブリッドアプリに特化したフレームワークの活用が推奨されます。Onsen UIやjQuery Mobileなどが候補となるでしょう。これらの製品は、モバイルアプリとしてHTML5を活用するためのノウハウが詰め込まれており、ユーザーインターフェースの開発負担を大幅に減らすことができます。

さて、エンタープライズモバイルではフロントエンドだけでなく、バックエンド方式も非常に重要な観点です。セキュアな通信は当然として、どのように社内のシステムと連携するのか、ソリューション選定のポイントは何なのか、開発後の運用基盤をどう整えるのか、などのトピックについて、次回に説明したいと思います。

スマートフォンやタブレットが普及する中で、エンタープライズ分野でのモバイル活用が注目を集めています。特にモバイルファーストという掛け声のもと、B2E（Business to Employee）やB2B（Business to Business）において、スマートデバイスを活用する動きが広まっています。

私としても「多くの企業ではモバイルを活用するのかしないのか」という議論から、「いつモバイルを始めるのか？」「どのように実装するのか？」という内容に論点が移っていることを実感しています。

もう一つの大きな特徴は、事業部門がモバイル化を先導している一方、情報システム部や総務部はセキュリティリスクやBYOD等の対処を迫られていることです。企業モバイル先進国であるアメリカでは、モバイル化を前提として業務の見直しを進めながら、上手くアプリを活用している事例が多く見受けられます。

企業のモバイル活用はカスタムアプリへ

モバイル化を進める上で重要なことは、モバイルでの業務範囲を見定め、その範囲に最適化したアプリを設計することです。モバイル活用レベルに応じて課題も変わってきますが、下記の3フェーズに分けて考えるとイメージしやすいと思います。

エンタープライズのモバイル化における3フェーズ

それぞれの段階によって、必要となる基盤が異なります。フェーズ1や2では、MDMやVPN、セキュアブラウザーといったセキュリティ対策や管理用ツールがその中心的な存在となります。実際に、現状では話題の多くがこの状況を反映しているのではないでしょうか。

今後、モバイル化がさらに推進され、業務をよりモバイルに最適化していく中で、カスタムで開発するアプリの重要性が一層高まっていきます。その中でHTML5が重要な技術として位置づけられ、フロントエンドに採用されていくことでしょう。また、その場合のバックエンド技術についても検討が必要です。

まずは技術的な側面から、エンタープライズモバイルの特徴を紹介したいと思います。

エンタープライズ分野におけるモバイルアプリの技術要件

大きくフロントエンドとバックエンドに分けて、エンタープライズモバイルの技術的な課題について紹介します。

クロスプラットフォーム

App Store等で配信するアプリでは、通常iOSやAndroidといった特定のプラットフォームに向けて開発されるネイティブアプリが主流です。ユーザーエクスペリエンスを高め、ユーザーから高い評価を得ることが最優先されるためです。

一方で、エンタープライズアプリはクロスプラットフォームが選択の中心となります。その背景として、従業員が自分のプライベート端末を業務でも使用する、BYOD（Bring Your Own Device）が挙げられます。企業がBYODを選択すると、マルチプラットフォームでアプリをサポートすることは必須要件になるためです。

また、業務システムは5年～10年という、一般のコンシューマーアプリと比較しても長いライフスパンで使うことが前提となります。そのため、現時点で採用されたプラットフォームに限定したシステムは、メンテナンスのリスクが伴います。移植性がより重要視されるわけです。

開発効率

技術選定の際には、評価軸としてアプリの実行速度よりも開発効率が重要になります。特に、モバイルアプリ開発エンジニアの確保と育成のしやすさ、Webやサーバーサイドといったテクノロジーとの親和性も重要なポイントです。

UIの作りやすさ

モバイル開発全般に当てはまりますが、アプリはビジネスロジックが比較的少ない一方で、ユーザーインターフェースの品質が使い心地に直結します。そのため、ワイヤーフレームやモックアップという形でプロトタイプを作りながら、ユーザーの視点で使い勝手を評価していく開発スタイルが好まれます。

業務アプリと言えども、ユーザーはB2Cアプリの使い心地に慣れているため、コンシューマー向けの開発フローを参考にすることが望まれます。ヌルヌル、キビキビ動く必要はありませんが、PC版の画面から表示項目数を落としてモバイルアプリ化するといった配慮が必要です。

メンテナンスコスト

端末の性能もさることながら、OSとその周辺環境は驚異的なペースで進化しています。その結果、WebやPC版のアプリと比較しても、TCO（Total Cost of Ownership）の中でメンテナンスの占めるウェイトが高く、リリースしてからの改修、改善をいかにスムーズに行っていくかが重要です。その中で機能改修や新バージョンへの対応のしやすさだけでなく、アプリのアップデートのしやすさも大きなポイントになります。

フロントエンド技術の本命はHTML5

さて、コンシューマー向けのアプリとは明らかに性格の異なる要件が連なっていますが、実際の開発技術には変わりがありません。ネイティブアプリやWebアプリなど様々な方式があり、どれも長所と短所を備えています。

その中で、エンタープライズモバイルの要件を満たす最有力候補となるのは、ネイティブアプリにもWebアプリにも対応できるHTML5です。では、なぜエンタープライズ向けフロントエンド技術の本命がHTML5なのか、次回に解説を進めていきたいと思います。

最近のシステム開発の現場では、HTML5やモバイル、JSフレームワークなどの新しい道具が次々と登場してきます。「そうした新しい道具ってエンタープライズではどうなの？」「現場として受け入れられているの？」といったぶっちゃけトークを行う座談会が、8月11日に美人で有名なおだんみつさんのいる21cafeで開催されました。1時間半にわたる長時間のトークから特に盛り上がった話を紹介します。

　▲パネラーたち（左から株式会社クレスコ・小川充さん、グロースエクスパートナーズ株式会社・酒巻瑞穂さん、NTTコムウェア株式会社・川田寛さん）

日本のエンタープライズが抱える悩ましい問題とは

川田：世の中は技術革新で勉強会に行くとワクワクするんですが、でも皆さん本当に使ってますか？
私はあるところで「勉強会で紹介される技術ってお花畑だよね」「俺たちそこまでアグレッシブじゃないよね」って聞いてショックを受けたんです(笑)。とは言え、イケてるものは世の中にいっぱい出てきていて、OSS由来のベンダー製品も、モバイルもたくさん出てきています。でも日本のエンタープライズだと、結構悩ましい問題を抱えているように思うのですよ。

　▲日本のエンタープライズは世界のスタンダードと離れすぎている

（スライドを示して）そもそもですけど、エンタープライズって、エンジニアを取り巻くエコシステムが欧米と日本とで全然違いますよね。SIerなんかがまさにそれで、ユーザ企業さんのシステム費を下げようとして頑張るんですが、システム費が下がると受注費が下がるし、エンジニアが評価されないしで、利害がうまく一致せず難しい状況。

そんな中で、ITで働き方をよくしようとか、エンジニアの技術で競争力アップに貢献していこうとか、そういう投資を提案していけるかんじにはなかなかなれず、海外とかと比べると日本はよくない方向に向かってる。エンタープライズは今とてもツラい状況に陥っているのではないでしょうか。そこで今日は前向きに企業のITをよくしていく方法を、フロントエンドという観点から、語り合えたらいいなと考えています。今日のアジェンダですがこの3つです。

• 古いシステムのツラいところ、例えばIE6/VB6とか
• これから結構使えそうなWeb技術
• どうやって新しい技術を入れるか、上司を説得するか

これらの課題を考えていく会にしたいと思います。早速パネラーに自己紹介してもらいましょう。

小川：エンタープライズ部の小川です。システム提案とか社内で利用するフレームワークの選定、エンジニアのトレーニングとかをやってます。

酒巻：同じくエンタープライズ部の酒巻です。前職ではHTML5関係の技術を仕事に取り入れてました。転職して直接HTML5関連は減ってるんですが、前職の経験からエッジの効いたエンタープライズっぽいところには関っている、という結構幸せな仕事をしてます(笑)。前職では小川さんと同じ社内標準の選定や、教育を含めてオープンソースの技術をどう使っていくのかという取り組みをやってました。

レガシーシステムとの付き合い方

川田：では、まず「古いシステムのツラいところ」から。

酒巻：自分の場合は、IE6やVB6でも苦しめられることがありますね。IE6ってXPと同時に死に絶えるかと思ったら、「サポート切れてるけど長期的に見て2年後にリプレース」みたいなところがあって。その資産とエッジの技術が今ぶつかってる。特に技術者が少ない部分、ActionScriptとかPrototypeJSとかに特有の癖などをよく知っている技術者が少ないんです。そういうニッチなことを知ってる人に負荷が集中してるのが、今よく見る状況ですね。VBも一緒だと思います。VBができるエンジニアって社内で貴重です。

川田：VB6知ってる人とか「神」扱いですよね。

酒巻：そういう人はたいていエッジなものも知ってるから、一人に対してよけいに負荷が集中してしまう。知らない人は定時で帰れるのに。

小川：私は今は幸いにIE6じゃなくIE8なんですけど、VBからIE6とJava EEに置き換わってという、まずはオープン系に置き換わって、その次のリプレースってのが多いですね。私は今日は話すほうよりも、皆さんからヒントをいただきたいので、いろいろ聞きたいんです。

──ここで川田さんが、会場にIEの案件をやっている人の挙手を募ったところ、意外と少ない結果に。さらにAndroid2.3標準ブラウザについても聞いてみると…

川田：Android2.3標準ブラウザだと、IE6とあまり変わらないくらいの存在ですね。IE8を使ってるということは、エンタープライズだとJavaなどが多いと思いますが、JSFあたりは拡張にいろいろと制約が出てきませんか？

小川：私の周りでは、そもそもJSFを使ってるケースがあまり例がありません。実際はまだJSPで作られているものが多くて、それを今のHTMLベースのアプリケーションに置き換える時に、BackboneなのかAngular.jsなのか、という議論です。

川田：JavaScriptフレームワークの活用に進んだのですね。小川さんは、ちなみにどっち派ですか？

小川：今はAngular推しなんですけど、どちらかというとSenchaのように、UIのコンポーネントを持っているもののほうがエンタープライズとしてはよいのではないかと思っています。

川田：エンタープライズの重要なポイントとしてサポートというのもあるけど、ちょっと安い案件はサポートなしでいこうかな、みたいなラインを狙ってるようですが、そのあたりどう思いますか？

小川：持続可能性を考えると、オープンソースだけタダだからって単体で使うのは、ちょっと違うなと思ってます。サポートがあるというのとは別に、いろんなものを組み合わせるとどこで不整合が起きるか分からないですし、ライセンスの問題もありますし、結構難しいんですね。そう考えるといろんなオープンソースを組み合わせて、一個のプロダクトにしているものの方がよいと思います。

川田：なるほど。話は変わりますけど、「古いIE向けのシステムはIE8や9でDocumentModeを使って動かせる」という神話があるんですが、実際に中身にはJavaアプレットがあったり、もう一つはFlash/Flexだったりするわけですね。そういうのを入れ替えたり、維持したりというのはありますか。

酒巻：2年くらい前の話なんですけど、その時に自分はネイティブを選んじゃったんです。2年くらい前だとFlashでやれることがHTMLではまだつらかった時期で、しかもIE7までサポートという条件があって。技術的にはできるんですよ、技術的には。ただ投資効果が…リプレース案件だったのでお金が出ないんですよ。それで一番安く上げる方法は…ってなるとFlashになっちゃう。自分はこれはHTMLでやったら面白そうだなとは思ってたんですが…。

──会場からJavaで画像を操作するところをFlashを使おうとしたが、許可が下りなかった話が投げかけられた。ソースや設計書もなかったが、動いたのだという。

川田：JavaアプレットとかFlashを置き換える案件、いい方法はありますか？

小川：作り変えた方がいいと思います。作られた当時のビジネス要件と今のビジネス要件では、状況が違いますから。お客さんにとっては、システム更改はグローバル化に代表される様々な変化と戦うための、新しいシステムを手に入れるチャンス。我々エンジニアとしてはそこに新しい技術を入れていく方法を考えていくべきかと。

酒巻：部分置き換えって長期的に見てコストがよろしくないケースのほうが多くて、会社レベルで業務計画の一環として古い資産を置き換えていくべきってのは、常に意識してます。

川田：この世界には、「三割改修は全入れ替えと変わらない」の法則がありますからね。

エンタープライズでも注目の最新Web技術

川田：これから先、ビジネスになりそうな技術を探っていこうかなと思うんですが、「この辺の技術要素はアツいぜ」ってのはありますか。

酒巻：鉄板ですが、Web ComponentsとServiceWorkerがすごく「来る」と思ってます。Web ComponentsのビジネスモデルとServiceWorkerのオフラインアプリケーションというのが、今の微妙に足りないHTML5プラットフォームにぴったり当てはまりそうな気がしてるんです。

小川：私の会社はWebだけでなく組込みやクラウドもやっていますが、その中で考えていくと、WebSocketですね。いろいろなデバイスがありますし、今後は薬の中にもセンサーが入るような時代になっていく。そうするとそれらのデータをどうやってWebやクラウドに上げて分析をしていくかが重要になっていて、今「何か」と「何か」をつなぐインフラとしてWebが一番適しているんですよ。そこで今注目している通信技術としてはWebSocketですね。

川田：私はやっぱり業界全体の流れに全力に乗っかろうということで、モバイルに期待していたりします。私はこれからは「モバイルファースト」じゃなく「モビリティファースト」になる説を推しています。実はブログ記事でも上げてるんですが。

小川：見ました。同感ですね。

川田：従来はデスクトップコンピューターに縛られたシステムだけです。それが今変わってきて、安価で汎用的なデバイスの中から、取捨選択しながらシステムを作っていく時代になると思うんです。デスクトップだけで完結したシステムを作るんではなく、いろいろなデバイスの中から適切なものを選んで、システムで業務フローを実現するような時代になっていくのではないかと。

酒巻：タブレットは結構もてはやされていましたが、仕事で要件とかワークフローを作っていくと専用機の方が優秀になることが多いんです。ワコムのペンタブレットとか、専用のUSBを挿すだけで動くような端末とかで。それがさっき小川さんが言ったWebSocketで通信する、API互換、Web標準でそういったマシンが繋がることがシステム開発の土台となってくれたら、すごい嬉しいなと思います。


　▲当日の会場は、テーブルには川田さんのおごりのビールが最初から並べられました

エンタープライズにUXって必要？

川田：モバイル絡みの話になりますが、エンタープライズにUX（への配慮）って必要だと思いますか？

──会場からの挙手はUXいらないと思う人、いると思う人が半々という結果に

（参加者）：ミスを少なくするというような観点で、誤解が少ないラベリングや紛らわしくないアイコンといったものは絶対必要。そういう理由で僕はUXは必要だと思います。

（参加者）：スマートフォンのOSを乗り換えるということがあるけど、たいていの人はすぐに使いこなせる。それはなぜかというと、UXがものすごく考えられていて分かりやすいから。でもエンタープライズの技術では新しいのになると「使わない」「使えない」って言われるのは、UXを考えてないからなんじゃないか。なので新しい技術で日々革新してことになったら、UXの部分だけは一本筋を通してあげないとダメではないかと…。

小川：UI/UXはお金にならないと言われる機会が多いです。例えば非常に使いにくいUIを変えたとき、現場の反応を見ると最初は大変評判が悪い。でも半年くらい経つと「使いやすい」と言われるようになる。その半年間の業務効率低下のコストと、そこで得たUI/UXが本当に等価だったのか自分は結構悩んでいて、WebとかであればUI/UXのベストプラクティスってあるんでしょうけど、企業システムの閉じた世界だと一般論では語れない何かがあるんではないかなと思ってます。

川田：私はUXは暫定的には儲からないんですけど、これから先は必要になると思ってます。エンタープライズとWebで公開されているサービスの大きな違いって評価軸で、Web系のサービスはたくさん利用してもらうことに価値がある。でも業務システムは嫌でも毎日使う。

ところが業務ってシステム化されているはずなのに案外現場に見にいってみると「使いにくい」あるいは「現場に合ってない」と思われるところをアナログに戻してるんです。そういう意味で今まであったものを置き換えるとなった時に、UXは重要なポイントになる。エンタープライズでは、モバイルとUXはセットだと考えているんです。

酒巻：UXじゃなくて、UIの話題の方がまだエンタープライズでは多いんですね。まだUIが出そろっていない「こういう時にこうする」っていうベストな選択肢が、まだ分かってない部分が多いんじゃないかなあと。

川田：エンタープライズは「ベストプラクティス」が好きですよね。

酒巻：むしろその言葉に安心して、みんな次の一歩へ進みたいっていうのがあるんじゃないかな。

小川：「モビリティ」の考え方は非常にありだと思っていて、例えば日本だとどんどん人口が減ってきていて、出産後の女性の活用、オフィスに縛られない働き方の中ではデバイスだったりノートPCが必要だけど、それは今までの業務システムの業務フローにないんです。そこで新しく再設計した上で、全部最適化されたら素晴らしい未来があると思ってますが、なかなかピンときてくれないんですね。ただ今後そういう企業や事例などが増えて、日本でもそういう働き方が普通になってくると思うので、そういうのを実現するための新しいテクノロジーはありだと思うんです。

酒巻：それは自分も夢に見ることがあるんですけど、そうなるために企業が何をするかっていうと「一部改修」「部分改修」で何とかしようって考えが多くて、それでコストが大きくなって結局取りやめようってケースが多かったんです。

小川：そこで相手側のステークホルダーを考え、「経営者の方に話すときは企業としての将来計画、ビジョンといったものをきちっと立てる」ことが必要だと思ってます。

オープンソースのフレームワークはどう？

川田：別の新しい技術の話も取り上げてみましょう。「オープンソースのフレームワークってぶっちゃけどうよ？」に何か意見はありますか？

酒巻：現在のエンタープライズで一番注目株といえば、Cordovaですね。お客様からのご要望で、ネイティブのファイルAPI、ローカルファイルにアクセスしたいっていう話が結構あるんです。「ActiveXなどで使えたのが同じWebなのに何で使えないの」って話が出てくるんですよ。そのための逃げ道として、Cordovaなどが出てきているんじゃないかと。ただ将来的に、Cordovaだけでやっていくのは怖いなって自分は思ってます。

小川：あれはまだ「闇」ですね(笑)。私もHTMLだけ作ればネイティブできますよっていうCordovaの甘い誘惑に誘われていったら、なぜかAndroidのネイティブ部分を触ることもあるという(笑)。技術の選択肢としてはありだと思いますけど、選定する側としてはメリット/デメリットをちゃんと把握した上できちんと利用するべきで、そのために一番大事なのは「味見」ですよね。

川田：弊社にはオープンソースの匠みたいな人がゴロゴロといるんですが、彼らが言うには「ここ最近の技術革新は早すぎる」。ここ10年くらいはゆっくり動いていたのに、滅茶苦茶早くなってしまった。そんな中で戦うために必要なのは、やはり「味見」だと思います。

酒巻：ブログや記事で紹介されている「光」の面だけ見て理解した気になり、とりあえず仕事に取り入れてみよう、というスタートはデスマのサイクルに陥る一因。その間に自分で味見やプロトタイプを作り、評価をするって課程が今後必要になってきますね、オープンソースをしっかり使う上では。

川田：「味見部」は何かやります？そこに html5j味見部部長の金井健一さんもいらっしゃるので…

金井：基本的に新しい技術が出たら味見をしています。なので「人柱」です。新技術がたくさん出てきても当たりなんて1割あるかどうか、本当にひと握りです。


　▲html5j Web先端技術味見部部長　AngularJS Japan User Group 管理人の金井健一さん

川田：エンタープライズのエンジニアがみんなユーザー企業にいるなら、システム費を下げればそれは直接自分たちの成績になるけど、日本では中間にSIerがいますからね。そこで新しい技術でできることとしてまず考えられるのは、「入れ替えの技術」。まず、「VB6とかFlashを使ってきたことを入れ替える技術は何だ」ってところからスタートして、その後モバイルでどうするのかを考えていくべきかと。

エンタープライズを「モダン」にするための技術

川田：最後にどうやって新しい技術を入れていくか、ぶっちゃけ「どうやって上司を説得するか」という話になります。酒巻さんはフレームワークを導入した時、どういう説得をしました？

酒巻：Angularを実際のそれなりの規模のあるシステムに取り入れました。何が大変だったかというと、エンジニアの下からの反発と、それで本当に見積り出せるのかという上からの反発ですね。

川田：見積りなんですか、上からは。

酒巻：これは何万円でできて、ウチに何万円の利益が出るかを最初にかなり正確に出したがるんです。フレームワークは前例がない。それに比べて、JSPで作ったらものすごく具体的に数値ができるんです。そこをいかに「最初に（見積もりを）作りあげるか」でしたね。

川田：Angularを入れるメリットは説明したんですか？

酒巻：はい。説明資料もかなり作りました。自分もBackboneとかEmberとかの当時エッジなJSフレームワークを味見して、最初にいけると思った唯一のフルスタックがAngularだったんですよ。

川田：一つで完結できるってことですか。

酒巻：テストとCIまでが、Angularのページに「こうすればいい」と載っています。Angularの基礎の部分を一回理解すると、それをそのまま設計に転用できるというのがすごく大きい。特にバックエンドのノウハウをそのまま使ったクラスコード、モジュール設計をできたのは上司を説得する上での説得材料になりました。

それをもとに実際に部下たちにAngular.jsを触らせて、実際できたら「できるじゃん」というノリですよね。言いかたが悪いですけどサラリーマンプログラマの人たちは安定した技術、昨日やっていたことを今日もやりたいと思う人が多いんで、それをどう切り替えさせるのか、「ほら簡単だよ」「やったらできるでしょ」さらに「こんなに楽になるよ」というのを教えてあげる、体験させてあげるっていうのが重要かなと思います。

小川：同感です。その点、Angular.jsはいいフレームワーク。後はUIフレームワークですね。SenchaやKendoUIなども検討してみてもいいと思います。

あとマイクロソフトのWinJS、これが正式にリリースされたら結構インパクト大きいと思います。企業システムのHTML5化をする上で一番ネックなのが、バックエンドの既存システムをどうやってWebAPIにするかという点です。バックエンドの話で言うと、マイクロソフトの.NETの技術はかなり素晴らしいですね。そことペアになる、マイクロソフトのサポートがあるUIフレームワークが出てきたら、乗っかってもいいかなと思っています。

川田：最近のエンタープライズでは、OSSよりベンダー製品の方が明らかに尖ってきていますよね。新製品の選定をOSSで縛ると、できないことが多すぎて困ってしまうのですが。

酒巻：自分は、Angularは入れましたけど、実際にガンガンやっていくんであれば、SenchaとかEasyUIの方が安心はできますよね。



川田：ほかにこの辺りが来るんじゃないってのはありますか？

金井： Angular.jsユーザー会会長だからAngularを推しているわけじゃないんですけど、Build 2014というマイクロソフトの技術者カンファレンスでも「.NET系とAngularの相性がすごくいい」とめちゃくちゃ盛り上がってました。マイクロソフト系列のKnockoutの話が全然出てこなかったんですよ。

小川：ちなみにJavaOne TokyoでもAngularが取り上げられていたそうです。エンタープライズJavaとの組み合わせでも、Angularは注目されているのかもしれない。

金井：たぶん、JavaScriptを書きたくないんですよね。Angularを使えば、JavaScriptの記述量をかなり減らせるから。

川田：私も「みんなJavaScriptなんか書きたくないんじゃないか」と思ってるんですよ。jQueryは「jQuery」っていう言語で、JavaScriptとは言いがたいじゃないですか。ひょっとするとここにいる皆さんも、本当はJavaScriptが嫌いなんじゃないんですか！？

(会場から) え～(笑)

川田：で、新しい技術をどう入れていくかの一歩前に戻るんですけど、フロントエンドってJavaScriptを書かない方向に行くんじゃないですか？

金井：JavaScriptにWeb Componentsが実装されると、苦手な人はわざわざJavaScript書かなくていいよっていうふうに、未来はなってます。

小川：コンポーネントが安定的に提供されて、JavaScriptに慣れないエンジニアでも大規模なものが作れるようになればいいなあと思いますね。

川田：思ったよりモバイルとフレームワークの話に行きましたよね。モバイルとフレームワークは非常に関心が高いのだと思います。モバイルに関しては「適用方法はいくらでもあるけど、提案する方法が見つからない」なのですが、フレームワークの場合は「良さは分かっているけど、お客さんにその良さを伝えられないというのが苦しい」のだと全体的に感じました。

ということで、90分にわたりいろいろ議論していただいてありがとうございました。最後にもう一度乾杯で締めましょう。乾杯！

現在エンタープライズシステムの開発現場では、シングルページアプリケーション（SPA: 単一のWebページで構成されているWebアプリケーションのこと）アーキテクチャの採用が模索されるなど、根本的な開発パラダイムにおいて大きな変化が起きようとしています（全体的にどのような変化があるかはエキスパートNo59の佐川夫美雄さんの書かれた「JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例」によくまとまっています）。

こうした変化の一部を支えているのが、JavaScriptによるMVCフレームワークです。数あるフレームワークの中で、実際にどのフレームワークを採用するかというのは、開発コストだけではなく学習・運用コストにも関わる、非常に大きな問題です。

この記事では、普段エンタープライズ開発に携わる筆者が、実際にJavaScriptフレームワークを選定するにあたって考慮したこと、そして実際の開発・運用から得た学びを具体的にお伝えします。エンタープライズ開発に従事する、読者の皆さんの開発作業に役立てていただければ幸いです。

フレームワークの選定に必要な考慮事項

一口にJavaScript MVCフレームワークといっても、よくWebで名前を見かけるものだけで、Sencha、KendoUI、Backbone.js、AngularJS、Ember.js、knockout.jsなどが挙げられ、最近などはVueJSというものも注目を浴びています。そのような数多くのJavaScriptMVCフレームワークの中から、やみくもに試して選定を行うのは、現実的ではありません。

そこで私は、ベンターサポートの有無やブラウザのサポート状況、ドキュメントの情報量や書籍の有無などを元に、まずはフレームワークを以下の3つまで絞り込みました。

• Backbone.js
• AngularJS
• Sencha

そこからさらに、以下のような基準を設けてプロトタイピングを行うことで、実際に使用するフレームワークの選定にあたりました。

機能から見る、フレームワークの責任とコスト

• 学習コスト ── 元バックエンドエンジニアたちにかかる学習コストはどの程度なのか？
• 開発の容易性 ── 実際にフレームワークを適用した際、どれくらい開発コストを低減してくれるか？
• コードの統一感 ── 開発・運用ルール通りの品質に、コード全般をフレームワークの機能でどれだけ統一することが可能なのか？
• ロックイン ── 「そのフレームワークを使い続けなければならない」というリスクを回避・低減することが可能か？
• （フレームワーク固有の）運用コスト ── 運用にかかるコストやリスクの担保はどこでどのように行うのか？

ただし、ロックインや運用コストは、フレームワークを導入する上ではある意味避けられない点です。また、技術の移り変わりが激しい現在の状況を鑑みると、一つのフレームワークへの依存度を強めることは、長期的に見ればリスクだと考えられます。そこで私は、プロジェクトごとにその時点で最適なフレームワークを選択することにしました。

これからのエンタープライズ開発では、どんなフレームワークを選択したかに依存しない社内標準ルールや設計資産を残し、開発や運用のコストなどはそちらで担保することのほうが重要となるのではないかと私は考えています。

フレームワークを比較する

では実際に、上記の観点から私がフレームワークを比較してみた結果を、以下に挙げます。先程申し上げたように、プロトタイピングまで行って比較したフレームワークはBackbone.js、AngularJS、Senchaの3つになります。

Backbone.js

Webアプリケーションに構造化された仕組みを取り入れることができる、とてもコンパクトなフレームワークです。 ライセンスはMITです。

• 学習コスト ── 既にjQueryなどを用いた開発経験のあるチームが社内にある場合は、ほぼその経験を引き継いで開発ができるため、学習コストが低くなります。
• 開発の容易性 ── Backbone単体はそれほど多くの機能を持っていません。そのため複雑、高度なことを低コストで行おうとした場合は様々なJavaScriptライブラリと組み合わせる必要があります。
• コードの統一感 ── Backbone単体で使うことは少ないため、様々なライブラリと併用することになるでしょう。そのため、何も対策をせずに開発を行うとプロジェクト全体での統一感がなくなってしまうことが多いため、注意が必要です。
• ロックイン ── 数あるJavaScript MVCフレームワークの中でも、最もロックインの度合いが低いと感じました。しかしながら、高度なことを低コストでやるためのフレームワーク（Marionette.jsなど）を組み合わせはじめた場合、ロックインの度合いは、ほかのフレームワークとそれほど変わらないかもしれません。
• 運用コスト ── ベンダーサポートは今のところありません。

Backbone.jsは歴史も長く、適用事例も数多いため、経験のある要員の調達という点においては、ほかのフレームワークよりも頭一つ秀でています。

開発補助ツールとしては、FirebugのプラグインBackbone-Eyeがあり、技術的な面での運用コストを下げてくれるでしょう。

まとめ

• ライブラリの組み合わせにより、どのように作成するかを含め、様々な手段がとれます。
• 他のフル機能なフレームワークと違い、不要な機能を極力除外した、最適化されたアーキテクチャを構築することができます。
• また、アーキテクチャごとのGood Practicesも多く蓄積されています。

基本的に選定したライブラリ群＋チーム内で策定したガイドラインでプロジェクトを運用する、コンパクトなWebアプリケーションを作成したいケースで多く使用しています。

AngularJS

独自のHTML構文を使うことで、静的なHTMLと動的なアプリケーション部の不整合の解決図った、多彩な機能を持つフレームワークです。ライセンスはMITです。

• 学習コスト ── すべてを学習しようとした場合はJavaScript MVCフレームワークの中でも、最も高いものとなります。また、学習した内容は完全にAngularJSに限定されたものになります。
• 開発の容易性 ── JavaScriptの記述量はとても少なくなり、開発工数の大幅な削減が可能です。
• コードの統一感 ── テンプレートエンジンからバックエンドとの通信部分まで、フレームワークがカバーする範囲が非常に大きいので、ルールを設けて制作することでプロジェクトを横断したコードの統一感を生み出します。しかし気をつけなければならないのは、ビューに関するロジックをコントローラー内でも記述可能な柔軟性を有していることです。そのため、ルールを作らず複数人で実装した場合は、他のJavaScript MVCフレームワーク以上の混沌としたコードとなるリスクも秘めています。
• ロックイン ── 設計から自動テストまで、ほぼAngularJSにロックインされます。
• 運用コスト ── ベンダーサポートは今のところありません。経験のある要員調達については、現状はかなり難しい印象を受けます、そのため要員の調整や追加の際は教育コストを考慮したほうがよいと考えます。しかし、最近になり適用事例が増えているため、今後は要員においても困ることがなくなってくるのではと考えます。開発補助ツールとして、Chromeの拡張機能であるAngularJS Batarangがあり、技術的な面での運用コストを下げてくれるでしょう。

まとめ

• 「Module」や「Provider」、「Dependency Injection」といった豊富なAngularの機能に合わせてガイドラインを作ることで、素早く強固なプロジェクトルールが作成できます。
• 複雑さや共通部分をAngularJSの標準機能である「Directive」、「Module」に梱包することが可能です。
• 個人的には、Yeomanのgenerator-angularと、generator-angular-fullstackをベースとして開発を行っています。

非常に多機能であることの裏返しとして、プロジェクトによっては不要となる機能も多く持ち合わせています。そのような場合には無理をして使わず、Backbone.jsと様々なフレームワークを組み合わせることで、最適化したアーキテクチャを構築する方針を採用しています。

Sencha

SenchaはJavaScriptフレームワークの一つというものではなく、アプリケーションフレームワークです。デスクトップはExt JS、モバイルはSencha Touchのように個別のFrameworkが用意されており、豊富なUIウィジェットと、その組み合わせによる開発で複雑さをの解決を図っています。ライセンスはGPLv3と商用、商用OEMが存在します。

• 学習コスト ── 環境構築、開発からリリースに至るまでフレームワークが機能としてサポートしています。その反面、フレームワークの学習コストはとても高くなります。
• 開発の容易性 ── HTMLやJavaScriptの記述は最低限で、画面の制作が可能です。
• 複雑さはSenchaフレームワークがほぼ吸収してくれるため、他のフレームワークほど高度なJavaScriptに関する知識が必要ありません。
• コードの統一感 ── Sencha特有の拘束力でコードの統一感はとても高いものとなっています。
• ロックイン ── 開発環境からリリースまでのほぼすべてがロックインされます。
• 運用コスト ── ベンダーサポートがあります。私の経験したプロジェクトでは、Sencha要員の確保が難しく、外部からメンバーを揃えることができませんでした。そのため、要員調達よりも教育コストをかけてSenchaができるメンバーを内部で用意するという方法をとっています。幸い、Senchaはベンダーによるトレーニングもあるため教育コストの見通しが立てやすいというメリットもあります。開発補助ツール等は、有料ですが様々な製品があります。

まとめ

• フレームワークによる拘束力が非常に高いです。Senchaで書かれた場合は、意識せずともコードや開発ルールが統一されるでしょう。
• 複雑さはSenchaフレームワークがほぼ吸収してくれるため、他のフレームワークほど高度なJavaScriptに関する知識が必要ありません。
• しかしながら、環境構築、開発からリリースまでフルスタック、強固な拘束力と言う特徴故に学習コストはとても高いです。
• 個人的な経験として、Senchaフレームワークの提供してくれる機能の枠を越えようとした場合には、他のフレームワーク以上の複雑さが必要となる印象を受けます。
• 使いこなす上では、Senchaフレームワークの枠に収まるか、収まらないか見極めが重要と私は考えます。
• トレーニング、高度な機能がSenchaで欲しい場合、適用できるかの見極めなどは、Senchaをサポートしているベンダーがあるため、そういったベンダーへ相談を行うという手もあります。

Webシステムを開発する必要があるが、HTML5系の技術要員調達や教育が難しい場合に選択しています。

事例: AngularJSの導入と開発

ここからは、私が業務システム開発において、実際にJavaScript MVCフレームワークを導入した事例として、AngularJSを採用した事例を紹介します。

実は、フレームワークを選定するにあたって、AngularJSの評価は当初低いものでした。

AngularJSは独特の書き方が多いため、ロックインの色が強く見え、多くのメンバーが難色を示したためです。また、ドキュメントの量が膨大なため、学習コストが高そうに思えたことも低評価の原因でした。

しかし、フレームワークがカバーする範囲が大きいため、設計から開発、そしてテストまでを同一の思想で統一することができそうなのは魅力的でした。

また、実際にプロトタイプを作って評価してみたところ、一見膨大な機能も、その大半は使わなくとも簡単なシングル・ページ・アプリケーションなら組み上げることが可能だとわかりました。jQueryも共存可能であるため、実質「制作だけするならば、学習コストはそこまで多くもないのではないか」という見通しを立て、AngularJSを選定しました。

元バックエンドエンジニア達にとっての学習コスト

フロントエンドエンジニアの調達に困っていた私のプロジェクトにおいて、既存の技術者にとっての学習コストはとても重要でした。

この課題に対して、AngularJSが持つ機能をフル活用して、既存のスキルに応じた分業を行うことで、学習曲線をゆるやかにするという方針を取ることにしました。具体的には、以下の様なチームに分けて分業を行いました。

• UIテンプレートチーム（デザイナー、フロントエンジニアが担当）
• Directiveチーム（フロントエンジニアが担当）
• ビジネスロジックチーム（フロントエンジニア、バックエンドエンジニアが担当）
• Moduleチーム（フロントエンジニア、バックエンドエンジニアが担当）

上記のように分業することで、元々バックエンドしか担当したことのなかった技術者にも、少しずつJavaScriptやDOM操作に慣れていってもらい、だんだんとフロントエンドの実装を任せることができるようになりました。

このような経験から、私はバックエンドエンジニアにフロントに関わってもらう際にははまず、サーバに近く、ロジカルなJavaScript部分で、フロントエンドエンジニアとペアプログラミングを行って、フロントエンドのプログラミングに慣れてもらうようにしています。あとは実践を踏まえて少しずつできることを増やしていく…という流れです。

開発者の開発環境は統一すべきか？

ただ、ペアプログラミングを行うにあたって、大きな問題となったのが開発環境の問題です。フロントエンドエンジニアとバックエンドエンジニアは、それぞれ慣れ親しんだ開発環境が異なります。

当初は、Visual StudioかEclipseで開発環境を統一しようとしていましたが、それらに慣れていないエンジニアにとっては、非常に高い学習コストが必要とされます。

最終的に私は、開発環境については「あえて揃えない」という選択を行いました。その選択を後押ししてくれたのがYeomanの存在です。

Yeomanは、タスクの自動化を行うGruntや、Webアプリ向けのパッケージマネージャーであるBowerと連携しながら、Webアプリのコード生成を自動化してくれるツールです。Yeomanには数多くのサブジェネレーターが存在し、様々なアーキテクチャに基づいたWebアプリケーションを迅速に構築することが可能です。

プロジェクトの骨格づくりにYeomanを利用することで、アーキテクチャ部分については統一しつつも、その後の開発においてはエンジニアがそれぞれ慣れ親しんだ開発環境を使えばよい…という形にすることで、開発や学習に余分なコストをかけることなく、堅牢なアプリケーションを迅速に開発できたと自負しています。

また、既に現在のWeb開発では数多くのフレームワークやライブラリを組み合わせる必要があることや、今後Web Components（HTMLフロントエンドのコンポーネント化を促進するための標準仕様）などの大変革が予想できるフロントエンド開発において、Yeomanのようなコードジェネレータの重要性は今後も高まっていくと予想しています。

開発コストの大幅な低減になるだけではなく、様々なアーキテクチャを気軽に試せますし、ベストプラクティスを世界中で共有することにもなります。実際私の経験でも、generator-angularのサブジェネレータに沿った形で開発を行うことで、かなりの開発コストを削減することができました。

おわりに

これまでは私の実務経験からのJavaScriptフレームワーク選定における経験をお話しました。

さらに個人的には、Web標準の今後を見据えて技術を選定することが、アーキテクトには求められているように感じています。

Web標準とJavaScriptフレームワーク

現在も、Web標準は絶え間なく進化を続けています。1年前選択した正しいアーキテクチャが、今も正しいと言い切れない、そんな状況である中、我々は約1年か、それ以上の期間をかけてシステムを構築する必要があります。

この進化スピードの中で、1年後も安定した技術を選ぶためには、枯れて進歩が止まったような技術を選ぶしかないのでしょうか？

私は、そうではなくWeb標準に適合していくライブラリやフレームワークこそが、その答えの一つではないかと考えています。

AngularJSは早くからWeb Componentsの考えを取り入れていました。そして、2.0ではPolymerへの対応を予定しています。Knockout.jsやVue.jsも同じく、Web ComponentなどのWeb標準への対応がなされています。

また、TypeScriptのようなaltJSと呼ばれる様々な言語においても、ECMAScript 6で採用される機能（クラスやモジュールなど）との親和性が重要なファクターとして認識されつつあります。

エンタープライズ開発でも、このようなWeb標準技術の実用的なラインを見極めて、Web標準に則った社内標準ルールや、開発インフラを整えていく必要があるのではないかと考えます。

先に述べたAngularJSを導入したプロジェクトでも、将来的な置換えの可能性も考えて、Web Componentsを意識したコーディングを心がけていました。

Web標準と共にシステムが成長し、手術後の縫合糸のように、フレームワークが自然とWeb標準へ吸収される。そしてその流れを阻害しない、そのようなアーキテクチャが、今後のエンタープライズシステムにおけるフロントエンド開発の理想だと私は考えます。

HTML5の時代となり、フロントエンドの重要性が増してきています。業務システムにおいても、HTML5を本格的に適用する事例が増えてきました。このような環境において、バックエンドを含めた次世代アーキテクチャのベストプラクティスを模索するというのが本記事の趣旨です。

本記事では、HTML5時代におけるアーキテクチャの概要を提示した上で、アーキテクチャ実装の具体例として、「OData＋UIフレームワーク」を採用した事例を紹介します。その上で、このアーキテクチャを採用した場合のメリットと、今後の課題について記述していきます。

HTML5時代における業務システムアーキテクチャのポイントとは

業務システムにおけるHTML5化の流れについては、「JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例」にて、エキスパートの佐川夫美雄さんが語っているように、HTML5時代において「JavaScriptフレームワークを用いたWebアプリケーション」が主流となることは、私自身も間違いないと感じています。

佐川さんが記事の中で語っているように、従来はブラウザで表示するためのHTMLをバックエンドが作成していましたが、今後はデータのみを返して、フロントエンドでHTMLを組み立てる方法が、今後は主流となっていくことでしょう。
その上で、どのようなアーキテクチャになるのかを考えてみると、フロントエンドとバックエンドを切り離した俯瞰図を描けるかどうかが、大きなポイントとなります。

こちらにアーキテクチャ俯瞰図を記載します。

では、大きな3つの構成要素について見ていきましょう。

1.フロントエンド

フロントエンドはAjaxの普及以降、大規模・複雑化が進んでいます。最近では、「Backbone.js」「AngularJS」に代表される「クライアントMV*フレームワーク(※)」と呼ばれるライブラリをベースに構築されることがほとんどです。その場合、UIは「Bootstrap」など「CSSフレームワーク」と呼ばれるUIのみの特化したライブラリを組み合わせることが主流です。また、「Sencha」に代表される、UIコンポーネントと呼ばれるUI部分を含んだオールインワンタイプの「UIフレームワーク」を利用するケースもあります。

(※)クライアント側フレームワークはMVC、MVVM、MVWなど複数の考え方が存在しているため、それらをまとめて「MV*」と表現しています。

2.バックエンド

HTML5時代のバックエンドは機能特化型で進化してきました。フロントエンドに対してWeb APIを公開し、主に、永続化やトランザクション・認証管理・サーバーサイドキャッシュなどの用途で利用されます。また、セキュリティ上の理由でフロントエンドに配置できないビジネスロジックを配置します。そのため、従来のオンプレミス環境にとどまらず、クラウド上に構築されたり、BaaS、（モバイルに特化した）mBaaSなど、クラウドサービスを利用するケースもあります。

フロントエンドから見たバックエンドは、「JavaEE7（JAX-RS）」「Node.js」「Ruby on Rails」など、どんな言語やフレームワークで実装されているかは、あまり重要な違いではありません。重要なことはバックエンドがどのようなWeb APIを公開しているかということです。

3.通信

通信は主に軽量で、JavaScriptでの扱いが容易なJSONが主流となっています。ただし、システム間連携といったユースケースに代表されるような、厳密にデータ型を指定したい状況ではXMLの使用も一考に値します。

業務システムアーキテクチャのポイント

このように、HTML5時代における業務システムアーキテクチャのポイントとは、バックエンドとフロントエンドを切り離し、Web APIを経由してデータアクセスしていることです。そして、特に重要なことはWeb APIのインターフェースをどのように設計するかです。

バックエンドとフロントエンドを分割するアーキテクチャを採用した場合のメリットは、並行開発ができるということがあります。そして重要なことは、両者を紐づける制約がWeb APIのインターフェースであるため、インターフェースさえ守って入れば、片方に影響を与えることもなく、もう片方を作り替えることができるということです。例えば、オンプレミス上で構築してある古いバックエンドを、クラウド上に他の言語で再構築するようなことも可能です。

バックンドのWeb API化は、ビジネス変化の激しい今日において、業務システムが安全に変化し続けるための最重要要件だと考えています。

業務システムにおいてWebAPI設計を難しくする3つのポイント

HTML5時代の業務システムは、WebAPIを介した疎結合なアーキテクチャに移行していくのがトレンドであることは先ほど述べた通りです。フロントエンドとバックエンドの並行開発を成功させるためには、正しいWebAPIを早期に設計することが重要です。

WebAPI自体は、Web2.0時代にブームがあったように古い歴史のある技術であり、ノウハウが蓄積されている部分もありますが、ここでは業務システムにおいてWebAPI設計を難しくする3つのポイントについて提示した上で、WebAPI設計をどのようなスタンスで進めて行くべきか記述します。

1. データアクセス条件の多様性

売上データのWebAPIを例に説明すると、業務システムでは同じ売上データを取得する際に、様々な条件を与えます。これは、業務システムを利用するユーザーに多様性があるためです。例えば、拠点・店舗・地域・売上日・担当者・品目などの項目が挙げられます。さらに画面ごと、ユーザのロールごとに細かく条件が異なる場合も存在し、多様性を考慮した設計が必要です。これらの条件はWebAPIのURLパラメータとして定義される項目です。

URLパラメータを設計した後に並行開発していくのですが、当初から正しいURLパラメータを設計することは難しく、必ず後の工程に変更が入ります。

2. データアクセス時のエンティティ間の関連

データアクセス先が、複数のマスタデータ（エンティティ）を結合したデータを返すことも特徴です。これは、業務システムが扱うデータが、複数のエンティティに正規化された上で保持されているためです。売上データに対する店舗などのマスターデータをイメージしていただければ、分かりやすいかと思います。

こちらも実際に実装してみると過不足が多く見つかるポイントです。

3. トランザクション処理

WebAPIはステートレスの前提で作られているため、WebAPIをまたがるトランザクション処理は苦手です。特にロールバック処理を行いたい場合は、WebAPI単独で処理が完結してしまうため、以前の処理を打ち消すWebAPI呼び出しを行う必要があります。

そのためトランザクション処理を行う場合は、WebAPIとバックエンドの処理の間にトランザクション処理を担うレイアーを作成するような工夫が必要で、業務のトランザクションを考慮したWebAPI設計が必要です。

WebAPI設計にて取るべきスタンスとは

業務システムにおいてWebAPI設計を難しくするポイントについて説明しました。フロントエンドとバックエンドを繋ぐWebAPIは両者の影響を受けやすく、将来を見越して設計することが難しいこと、理解していただけたかと思います。そのため、WebAPIの設計は「最初に設計を固める」より「作りながら育てる」というスタンスで取り組むべきだと考えます。

次は、HTML5時代のアーキテクチャを実現する具体例として、「OData＋UIフレームワーク」の組み合わせを紹介します。

作りながら育てるWebAPI設計を実践するための1つの選択肢「OData」

WebAPI設計は「作りながら育てる」と提示しましたが、終わらないタスクほど嫌われるものはありません。実際の業務システムの開発においては、将来の変更も見越した網羅性のあるWebAPI設計を行って、後の変更の影響を最小限に止める方が現実的です。

最初に網羅性のある設計ができ、変更にも柔軟という、そんな都合の良いものが果たしてこの世の中に存在するのでしょうか？　そこで、注目したものがODataです。

ODataとは 「Webアプリケーションにおける、データアクセス方法を標準化したプロトコル」です。Microsoft、IBM、SAP、Citrix社など中心となりデータアクセスプロトコルの業界標準となるよう動いています。WebAPI版のODBCやO/Rマッパーのようなものと言えばイメージしやすいと思います。

ODataはHTTPをベースにしているため、一つ一つのデータアクセスは通常のHTTPでのWebAPIとなんら変わりませんが、次に代表されるようなデータアクセスに関する様々な指定をURLパラメータとして標準で定義しています。

• 順序指定：$orderby
• ページング：$skip(開始位置）$top(取得件数)
• フィルタ：$filter
• 部分取得：$select
• 関連エンティティ取得：$expand

URLパラメータの詳細はこちらを参照ください。

このように、URLパラメータでデータアクセス方法を柔軟に変更できるため、従来は大掛かりな変更が必要であったWebAPIの変更が、URLパラメータで吸収できることが多くなります。従来のWebAPI設計が変化に弱い硬直的なものだとすると、ODataを利用したWebAPI設計は変化に強く柔軟なものです。

しかし、OData特有のURLパラメータを生成することが非常に面倒であるため、今日まであまり普及しなかったことも事実です。最近ではdata.js、Breeze.jsなどOData対応のJavascriptライブラリが登場し、UIフレームワークのOpenUI5と融合することで状況が変わったと考えています。

ODataとUIフレームワークの融合がもたらすメリットとは

ODataとUIフレームワークが融合することの最大のメリットは、データアクセスからUIへの結果反映まで、難易度が高く繊細な部分をUIフレームワークで隠蔽できることです。

UIコンポーネントに対してODataとのマッピングを施すことで、UIフレームワーク側でユーザの操作(ページングやフィルタ処理など)があった際、自動的にバックエンドへデータアクセスするためのURLを生成します。さらに、バックエンドから取得したデータはUIフレームワークが自動でUIコンポーネント側へ変更を反映します。

私が携わったシステムでは、UIフレームワークとODataを組み合わせることによって、データアクセスとUIへの結果反映の部分のコード量を、大幅に削減することができました。こちらが、ODataとUIフレームワークを適用した場合のアーキテクチャの概要図です。

（※）ODataを利用するためにはOData仕様に準拠しているWeb APIを実装しているバックエンドが必要です。これをODataServiceと呼んでいます。

ODataとOpenUI5を利用した実装例とチュートリアルについては、私が作成したOpenUI5とODataを使ってWebアプリケーションを作るに一通り記載したものがあります。参照していただければ雰囲気がつかめると思います。

上の紫の部分がODataとUIフレームワークを組み合わせることによって隠蔽される部分です。フロントエンドが得意なエンジニアが少ない、業務システム開発の現場にてこれだけ実装する範囲を隠蔽できるのであれば、現実味のある選択肢の1つではないでしょうか？

そんなに甘くないぞ！バックエンドのOData化。救うのは.NET系エンジニア

一見、幸せになれそうに見える「OData+UIフレームワーク」アーキテクチャですが、最大の課題はバックエンドのOData化です。私の携わったシステムでは「SAP Netweaver Gateway」というSAP社の製品を導入することでバックエンドのOData化を実現しています。

現在、もっとオープンかつ手軽な方法でOData化が実現出来ないか模索しています。中でもMicrosoftの「ASP.NET Web API 2.2」は少ないコード量でODataを生成することができ、今最も注目しているOData化の方法です。 今後は、「.NET」系のノウハウとコラボレーションしていき、より簡単にバックエンドのOData化が実現できるようしていきたいと考えています。

さいごに

今回は、いくつか有効性を検証しているアーキテクチャの中で、「OData＋UIフレームワーク」という、一般的にあまり知られていないアーキテクチャを紹介しました。今後、様々なUIフレームワークがODataを標準でサポートし、より選択肢が増えることになれば、一気に業務システムのHTML5化におけるデファクトになる可能性があると感じています。

また、業務システムを切り口にした場合、一般的なWeb開発では注目されないテクノロジーに注目することも、なかなか興味深いです。

HTML5時代の業務システムにおいて有効なアーキテクチャはいくつも存在すると思います。これを機に、このような議論が業界内で進むことを期待しています。そして、日本のエンタープライズITをより良いものにしましょう！

こんにちは、川田です。今日からHTML5 Experts.jpでは「エンタープライズ開発特集」を始めます。第一弾の今回は、HTML5とエンタープライズITについてのオーバービューを語ります。サーバサイドのお話はわりとよく見ますが、フロントエンドにフォーカスしているというのは珍しいようにも思えますね。

IT自体が幅広い分野のビジネスや製品に変わりつつある昨今、「エンタープライズITの話をするぞ！」と言うと、いろんな方面の人からこう問われます。

「そもそも、エンタープライズって何？」

エンタープライズ、正式には「エンタープライズシステム」になりますが、直訳すれば「企業向けシステム」。一言で言うなら「企業のビジネスを支えるための仕組み」を意味します。企業の業務の効率化を進めたり、経営戦略や問題解決を進めるためのワークプロセス(仕事の進め方)と道具(アプリやインフラ)のことです。

エンタープライズのエンジニアの仕事は、技術的な観点から、経営を良くする方法を提案したり、業務の進め方を設計したり、そのために必要な道具(アプリやインフラ)も調達したり、なければ自分たちで開発したり。サーバからクライアントまで、必要なら机の配置の一つまでデザインする(ネットワークも！)。ぶっちゃけ、ITじゃない方が合理的なら、IT化しないなんてのも提案する。スーパーのレジだって「効率化とかどうでもいいから最安値で作って」と言われたら、ソロバンを薦めてしまうという。それが私たちの仕事です。「SCM」とか「CRM」というキーワードで検索すると、そのニュアンスが伝わるかもしれません。

さて、ここで定義したエンタープライズ（システム）において常に関心が高いテーマとしては、「1.システムの運用」「2.業務の効率化」「3.アーキテクチャ」が挙げられると思います。これらの観点から、「HTML5」という技術要素が、これから先の企業のITをどのように良くしていけるのかをみてみましょう。

1. 「システムの運用」はどう変わるのか？

古今東西、エンタープライズは、システムをできる限りいじらずに、長く運用させることがビジネスとして成立する市場です。欧米においても、古いものは企業と政府に最後まで残り続ける傾向にあるというのが、共通の認識になっています。日本ではInternet Explorer（以下、IE）が高い影響力を持っており、多くの企業がIEの特定のバージョンをサポート期間ギリギリまで使い倒すという方法に走りがちです。しかし、今それが変わることを求められています。

マイクロソフトのサポートは基本は最低10年というルールですが、IEにおいてはもはやそのルールは全く通用しません。昨年、Windows8.1発売時にWindows 8版IE10のサポート期間が短縮化され、そして今年の7月にはとうとう、2016年1月12日以降、最新のバージョン以外はサポート対象外とするというアナウンスを行いました。これは、Google Chromeと同じアップデートのポリシーで、システムはこれからIEの最新バージョンがリリースされる都度、IEのバージョンを上げ続けることが求められています。現時点では、約1.5年周期ぐらいになりそうです。

マイクロソフトは、エンタープライズもコンシューマーも、どちらであってもIEが常に最新のバージョンで運用されるよう改善を進めてきています。その成果として、現在の最新のIEはHTML5に準拠し、高い相互運用性を確保しました。これはつまり、バージョン間の動作の違いが非常に小さいということを意味します。彼らとしては、ブラウザの「バージョンアップ」が、従来の「サービスパック適用」や「セキュリティアップデート」程度のものとして扱われればという狙いがあるようです。

Windows XPのSP2は、元々Vistaになる予定の全く別ものなOSと言われていたのですが、それが運用の中でうまく適用できたというのであれば、これはほんの些細な問題なのかもしれません。運用の進め方さえうまく定着すれば、業務システムのクライアント部分は、OSやミドル、ハードウェアのライフサイクルから開放され、セキュリティ・信頼性・パフォーマンスが最適化された状態で、長期に渡り利用することが可能となります。これはエンタープライズITにとって、HTML5がもたらす大きな価値の一つと言えるでしょう。

最新のIEへの移行、HTML5化を進めるには、以下の機能・ツールが有用です。欧米ではユーザー企業だけで音頭を取って進めていけるため、そのモチベーションは非常にシンプルです。しかし、日本はSIerがシステム開発の中心にいるため、調整にはかなり苦戦するかもしれません。2016年1月までと非常に期間は短いのですが、ユーザー企業・SIerの両方が一丸となりこの取り組みを進め、ユーザー企業のシステム費用の最適化と成長に貢献できればよいですね。

• modern.IE：IEのマルチバージョンテストや、問題点を検出するツール。無償のものが多い。何千台も端末がある場合、段階的に最新バージョンのIEへ移行を進めていくにあたり、このツールが有用になる。
• Enterprise Mode：IE11以上で、暫定的にIE7/8の動作をエミュレートさせる機能。最新のIEに移行した後も、古いIE特化のアプリを動かすことができる。
• Compat Inspector：IE8以下の依存性の高い作り込みを検出するツール。Enterprise Modeも長くはサポートされる保証がないため、最新のIEへ移行した後、このツールを活用して改修を進め、Enterprise Modeをなくしていくことが求められる。

2. 「業務の効率化」はどう変わるのか？

近年、デスクトップPC以外のコンピュータのポテンシャルが注目を集めています。ノートPCにタブレット、スマートフォンにウェアラブルと、デスクトップPCにはない機能、ワークフローのモデルを持ったコンピューターを活用することで、従来の業務をより効率的に変えていこうという考え方が、欧米で広がりをみせています。最近のアンケート結果を見ていると、日本でもモバイルの業務活用に抵抗感がなくなりつつあるようですので、恐らくこれから広がっていくことでしょう。

例えば、ホワイトカラーの場合、マネージャーの決裁をリアルタイム化させるという用途が有名です。スマートフォンに決裁イベントの発生を通知させ、内容を表示し、タッチで完了させるというワークフローを実現させるというものです。部下にも使えるものだと、スケジューラとの連携です。これからミーティングが始まるということを、移動時間も含めて計算し、事前に通知するという仕組みです。このような、様々な種類のデバイスを連動させた業務の設計方法を「モビリティ」と呼びます。

モビリティは、単純にWebアプリをタブレットやスマートフォンで見えるようにするだけでは意味がありません。コンピューターが持つ特性に合わせて、設計することが求められます。例えば、先ほどの決裁のシステムにおいて、「通知」という機能がなかったらどうなるでしょうか？タッチ操作に最適化されていなかったらどうなるでしょうか？

使いにくくて、結局デスクトップ型やノートPC型のコンピュータを使うようになるのがオチです。UXへの理解がないことには、導入がうまくいかないのがモビリティなので、モバイルの活用とUXは、多くの場合セットとして扱われているはずです。業務系のUXは、Webのサービスのようにリピーターを増やすためのものではなく、毎日使う道具を効率化させることに意味があり、このあたりの評価軸の違いにも注目すべきでしょう。

また、スマートフォンやタブレットといった道具側にも工夫が必要です。企業向けとして利用する場合、セキュリティの考え方、開発効率にも意識しなくてはいけません。セキュリティについては「MEAP(Mobile Enterprise Application Platform)」が、「IBM Worklight」「SAP Mobile Platform」「Oracle ADF Mobile」などなど、数えきれない程の製品によって、実用化もコモディティ化も進んでいます。一方で開発効率については、HTML5によるハイブリッドアプリケーション開発が注目を集め、これを実装するための「Apache Cordova」がMEAP製品の間でも独占的シェアを得ています。HTML5自体、そもそもモバイルから注目を集め出したわけで、そこまで想像に難くないはずです。

3. 「アーキテクチャ」はどう変わるのか？

最後に、統合化を目指したアーキテクチャについてです。ここでのアーキテクチャとは、個別のシステムにおけるものではなく、全体最適化の観点におけるアーキテクチャです。一つの業務をこなすのに、いくつものログインを繰り返す煩わしさ、複数のシステムに同じ情報を投入しなくてはいけない状況など、連携できていない状況の改善という意味です。

以下3つのポイントが、これからのアーキテクチャを決定付けているように思えます。

• 業務ロジックがAPIを持ち始めている：出足はやや遅れましたが、私の感覚として日本の企業でもパッケージの活用が進んでいるように見えます。パッケージ製品は、SAP NetWeaverやSalesforce APIsといったAPIを持つのがもはや当たり前で、標準としてはODataが広がっています。インフラもAWSのAPIがデファクト標準化しつつあり、認証基盤ですらもSAMLやOAuth(OpenID Connect)のような標準のAPIへとシフトしています。OneAPIやBONDIみたいなモバイル向けアプリ開発の世界観も気になるところです。スクラッチ開発においても、ライブラリ/フレームワークも豊富になり、REST(like)を中心としてAPIの実装コストも落ちていくことでしょう。
• APIを活用する製品が増えている：IBM CognosやOracle BIなどのBIツールや、Apache Camelのようなルーティングエンジン、Backbone.jsやAngularJSといったJavaScriptフレームワークでさえもREST(like)に対応するのが当たり前という状況です。サーバでAPIを繋げるApigeeや、クライアントでAPIを繋げるIFTTTなんかも面白い傾向です。例えスクラッチ開発であっても、アプリは標準的なAPIで繋げた方が、長期的に見てできる事の幅が広がっている時代に突入しています。
• 開発ツールがモバイルファースト化している：モバイルはネットワーク環境が不安定であることが前提であり、サーバサイドとは疎結合にしてクライアントで処理をすることが求められています。こうした中、マイクロソフトの「Mobile-first, Cloud-first Development」、IBMの「Mobile First」と、各製品ベンダの開発ツールがどんどんモバイルファースト前提に変わっています。個人的には、Oracle BI Mobileみたいな、完成された製品でさえもモバイル前提なことに、未来を感じさせられます。

このような状況を鑑みると、世の中のアプリケーションはC/Sモデルへと回帰しているように見えます。クライアントは多くの場合、やはりHTML5のエコシステムの恩恵を受けたくなるはずです。本メディアでも過去に取り上げたような、佐川夫美雄氏の考えるWebベースのリッチアプリケーション開発もその一つと言えます。現在はまだ、APIの集約はBIツールなどを活用してサーバサイドで行うのが一般的なようですが、これから先は、徐々にクライアント側へと移っていくことも想像に難くないはずです。

「あの企業みたいに、こういう経営情報を可視化したい！」「こういうコスト削減を目指したい！」となった時に、「世の中の道具が全く何も使えない！」なんてことにならないためにも、少しずつでよいので世の中の流れに乗っていけるといいですね。素直に新しいベンダ製品を活用していたら、勝手にこんな作りになるわけですが、いかんせんOSSによるコスト最適化、マルチベンダ化、大量のレガシー資産などの要因が邪魔して、そうも簡単にいかないというのが厄介なところでしょう。

さてさて、今回「UX」に「MEAP/ハイブリッドアプリ開発」に「業界標準フォーマット」に「ツール/フレームワーク」と、フロントエンドに関わるいろんなキーワードが出てきましたが、これらをより深堀りしたものが、本メディアにて「エンタープライズ特集」として取り上げられます。企業のビジネスを技術面から良くする、ヒントを与えてくれるに違いありません。

どうぞ、お楽しみに！