5月24日、25日の二日間にわたり開催されたMicrosoftの技術者向けイベント「de:code 2016」で、日本マイクロソフト赤間信幸氏の「エンプラ系 業務Webアプリ開発に効く！実践的SPA型モダンWebアプリ開発の選択手法」というセッションを聴講しましたので、そのレポートをお届けします。

ただタイトルにもある通り、筆者的にはちょっともやもやする内容でもあったので、HTML5 Experts.jpコントリビューターの酒巻瑞穂さんと、講演の内容をベースとした軽い対談も行いました（後日、エンタープライズWebアプリのあるべきかたちについて、もっと掘り下げた内容の記事も作る予定です。乞うご期待）。

セッションレポート

SPA(Single Page Application)とは

今、Single Page Application(以降、SPAと記載する）が業務アプリケーションでも利用できないかということが話題になっています。復習になりますが、SPAとは以下の様な特徴を持つアプリケーションです。

• 単一ページで機能を提供するWebアプリケーション
  • ページをリロードせずにJavaScriptでWebAPIと通信
  • JavaScript、CSS、HTMLを組み合わせて画面を更新
  • これにより応答性が高く、使い勝手の良いWebアプリケーションを実現する
• Web上では割とSPAは一般的だが、業務アプリケーションでもSPA型の開発ニーズが高まっている

従来型のWebアプリケーションはサーバサイドが中心でした。そのほとんどの処理をWebサーバで行い、クライアントは受け取ったHTML、CSSを使ってレンダリングを行い、若干のJavaScriptを動かすというものでした。SPA型のWebアプリケーションでは、サーバはクライアントの指示に応じてデータを返し、UIの更新等はすべてクライアントで行います

SPA型Webアプリケーション開発の難しさ

このようなSPA型アプリケーション開発は相当のスキルが必要であり時にとてもむずかしいものになります。特に、SPA型Webアプリケーション開発に関するネット上の情報は、低水準からスクラッチで開発するためのものが多い。OSSなどをフル活用して作りこむ、いわばC++開発のような「職人技」の世界であり、ハードルが高いのが現実です。

エンタープライズ系業務Web開発の場合、こうした「職人的開発」はあまり向いていないように思います。

ここでエンタープライズ系開発とオープン系開発のギャップを確認してみましょう。

このような比較から、.NETのような高水準言語での開発に慣れ親しんだ開発者が、SPA開発に取り組むのはハードルが高いといえます。まとめると次の問題が挙げられます。

• 低水準開発の必要性：HTML, CSS, JavaScriptでの開発はC#, .NETでの開発に比べて低水準
• 高すぎる開発自由度：「どう作るか」は自分でゼロから決める必要がある
• ライブラリの選択の難しさ：膨大なライブラリからどれを選べばよいか分からない

そしてSPA型開発では、利用するフロントエンドライブラリによって作り方が大きく変わります。同じ「HTML5」の開発といえど、コードの互換性はほとんどありません。このためライブラリの選択には特に慎重を期す必要があるといえます。

そこで、自分のプロジェクトに合わせた適切なライブラリの選択が必要になるのですが、実際の現場ではこれが非常に難しい。Microsoftからは、クライアントライブラリは（ほぼ）提供されていませんが、世の中にライブラリは星の数ほどあります。

ライブラリを選ぶ際に考慮すべき事項

言語拡張

ここで、ライブラリを選択する際の私なりのやり方をご紹介します。ライブラリの選択では、基本言語仕様、DOM操作、通信処理、CSSに分けて考えてみます。そうすると、DOM操作・通信部分はほぼ必須になるので、jQueryを利用すればいい。基本言語仕様とCSSに関しては、スクラッチの作り込み型Webアプリケーションでは非常に重要ですが、業務Webアプリケーション開発の場合はケースバイケースです。より具体的に言うと、CSSではLess、SASS、StylusなどのCSSプリプロセッサーの選択、altJSでは、TypeScript、CoffeeScriptの選択などが挙げられます。

UIライブラリ

UIライブラリに関しては、低水準UI部品郡と高水準UI部品郡に分けて考えます。低水準UIライブラリには無償のものが多く、高水準UIライブラリは高機能ではあるが、ほとんどの場合有償製品となっています。

設計・実装方法論、フレームワーク

進化が激しくトレンドも頻繁に変わるため、注意が必要です。フレームワークを利用すれば、ロックインも発生します。特にWebフロントエンドの世界では数年と経たずにトレンドが変化します。このため頻繁に手を入れる見込みがない場合には、むやみにフレームワークに依存させるのは危険だと考えます。

各種ツール、ユーティリティ

どのような各種ツール、ユーティリティを利用するかというような考えは、初めてSPA型開発に取り組む場合には、後回しにするとよい。より高い生産性を目指す際には欠かせないツール郡ではあるが、ここまで述べてきた、言語拡張、UIライブラリ、設計・実装方法論、フレームワークなど覚えるべき要素、考えるべき要素が山ほどあります。最初はなくてもなんとかなりますので、必要性を感じたところから段階的に導入していくことをお勧めします。

ライブラリの組み合わせに関する注意

ライブラリは安易に組み合わせないように注意しましょう。ライブラリには必ず寿命がある上、複雑に依存しあっていることも多い。古いライブラリが他のライブラリのバージョンアップの足かせになることがあります。

長期的な保守が重要になる業務Webアプリケーションでは安易にライブラリを組み合わせるべきではないと考えています。

SPAフレームワークライブラリ

商用の高水準UI部品ライブラリは高価ですが、多くはオールインワンパッケージ（=SPAフレームワーク）になっていて、ライブラリの組み合わせ方で悩む必要が少なくなります。

このため、業務Webアプリケーション開発におけるクライアントライブラリの選択は、高水準UI部品の要否で大きく方針が変わります。

OSSライブラリの組み合わせ型開発では、利用できる高水準UI部品が少なめなので、メジャーなライブラリを中心に必要最小限の組み合わせを行います。。SPAフレームワークライブラリ依存型開発では、高水準UI部品が数多く利用できるので、シェア、情報量、日本語サポート、ライセンス費用などを元に選択するとよいでしょう。

サーバ側のページ構築

個人的には完全なSPA型ではなく、うまくサーバ技術を併用した方がSPA型の業務Webアプリケーションは作りやすい。特に.NET開発者の場合、複雑な業務ロジックはサーバ側でC#を使って記述した方が作りやすいことも多いでしょう。実際のSPA型アプリケーション開発では、サーバ側で組み立てなどにASP.NET MVCを併用するといいのではないでしょうか。UI処理の中心はあくまでもクライアントだが、上手に併用しましょう。

編集後記: 講演の内容について対談してみました。

レポートは以上になります。ただ、講演の結論が結局のところ「完全なSPA型じゃないほうがいい」と言っているように思え、少し違和感が残ったのも事実。そこで、同じくセッションを聴講していたコントリビュータの酒巻瑞穂さんと、疑問に感じたところを少し話し合ってみました。私も酒巻さんも、現役でエンタープライズWebに取り組んでいるエンジニアとして、これを機にエンタープライズ×SPAについて整理しておきたいと考えたからです。以下、その対談の内容を編集後記として掲載します。

SPAはつらい？

佐川：講演を聞いて、どんな感想を持ちました？

酒巻：正直、ちょっと違和感残る内容でしたね。

佐川：結論が結局、本格的なSPAは難しいからやめとこう、と言っているようにも聞こえました。

酒巻：私も、メリットが見えないものはがっつりSPAにする必要はない。何もかもSPAにすべきとは思いません。ただ例えば、モバイルの事を考えると、SPAにしていくメリットは大きいですよね。クライアントサイドでのオフライン処理を求められることも多いので、そうなるとSPAで作るほうが自然だったりする。

SPAはセッションをクライアント上で維持できるので、Server Push型のイベントが必要なアプリケーションを作る必要がある場合にも有効ですね。

佐川：SPA開発は職人技という話がありましたけど、ここはどうですか？

酒巻：職人技…かどうかはわかりませんが、開発の自由度は確かに高いですよね。アプリケーションの品質が、プログラマ個人の力量に左右される部分はまだ大きいですね。

佐川：フレームワークがそういう問題解決を担えるはずなんですが、そのフレームワークが多すぎるという(笑) 。講演でも「ライブラリ選択が多すぎる」という問題提起をしていらっしゃいましたね。

酒巻：確かにそれは同意できます。でも、「開発時の選択肢がない」というのは言い換えると「衰退する技術」のようにも思えるので、個人的にはむしろ今の状況は歓迎しています。業務エンジニアとしては社内ルールなどを作って統制する方がいいんじゃないかと。

佐川：それにライブラリの選択も、Yeomanなどのジェネレータやいろんなスターターキットを使えば、かなりの部分楽できますよね。

SPAの設計は悩ましい

酒巻：ただ、講演でも取り上げられていましたが、設計の方法論などについては確かに難しいです。ここはまだ結論がないと言うか、個人的にも難しいところですね。というのもWebの進化がまだ当分先を見てるので「今」の最善はあっても来年の最善はもう判らない。

佐川：設計方法論は、採用するフレームワークによっても大きく変わってくるところですしね。ただ、今のトレンドとしてはUIのコンポーネント化というのは間違いない方向性なので、そこからスタイルを決めていける。ただ、設計方法論を語った書物はあまり見られないのも事実で、これはWebの進化が早すぎるためではないかと。

しかしSPA設計の話って、「サーバでやるか、クライアントでやるか」って話になりがちですよね。ただ、MVC的なものをどちらかに寄せなければならないという話ではない。基本的には、UIを更新する処理はクライアントに寄せるというほうが筋が良いと思います。

この話はSPAをどうするかという話ではなく、もう少し広くWebアプリケーションをどうやって作るかの話です。SPAでもMPAでも議論としては同じで、SPAにすべきかそうすべきではないということになる。 そういう意味でも、SPAを採用すべき勘所とか、Webアプリケーション全体の中のSPAの位置付けについて、先ほどの講演でもっと聞きたかった。

酒巻：個人的には、ちょっと古い内容でしたね。「DOM操作はjQuery」と言っていたが、個人的にもうあまりやりたくない(笑)。

佐川：そうそう、個人的には4年くらい前の感覚に思えました。その頃とはWebアプリケーション開発のやり方そのものが変わっている。もちろん（Webアプリケーションではなく）Webサイトを作るときにわざわざReact.jsとかAngularを利用しなくてもいい。そういう時はjQueryでもいいと思います。こういうものは当たり前ですが、適材適所で考える必要があって、それこそマネージャやアーキテクトの腕の見せどころなのではないでしょうか。

最後に

ここのところ、確かにエンタープライズでSPAの導入が多くなってきました。 一方でまだまだ事例が少ないこと、開発経験のあるエンジニアが少ないため導入しようとしてもなかなかプロジェクトとして進められないという現状もあります。この記事が、エンタープライズWebアプリの開発に少しでも寄与できたなら幸いです。

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

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 Experts.jpが誇るエキスパートたちに、「UX」というテーマでインタビューするシリーズ第五弾です。

ぼくも昔はSIerの孫請けとして、エンタープライズ業界の片隅で働いていたので、エンタープライズというキーワードにはつい反応してしまいます。とはいえ、今のエンタープライズ業界がどういう状況かはよく知らないのですが、UXに関する特集を行うにあたっては、「エンタープライズとUX」というテーマで必ず誰かに話を聞きたいと考えていました。

そこで株式会社セカンドファクトリーの新谷剛史さんに、このテーマをぶつけてみたところ、取締役副社長 シニアUXストラテジストの齋藤善寛さんも参戦し、めちゃくちゃテンションが高くて密度の濃いインタビューになりました。 今回、「(笑)」が多いのは（主に齋藤さんの）テンションの高さの表れだと思ってください。

エンタープライズとUXについて、ここまで濃くてぶっちゃけ気味のトークはなかなかないんじゃないかな、と自負しております。では皆さんどうぞ、今回もお楽しみください！

　　▲左から、株式会社セカンドファクトリー 新谷剛史さん、同・取締役副社長 シニアUXストラテジスト 齋藤善寛さん

エンタープライズシステムはネガティブな宿命を背負っている？

白石: では、本日はよろしくお願いします。まず最初にお聞きしたいんですが、「エンタープライズ」という言葉をどのように捉えていらっしゃいますか？

　　▲インタビュアーHTML5 Experts.jp 白石俊平編集長

齋藤: エンタープライズというと、一般的には業務用アプリってことなんでしょうけど、私たちの会社としてはあんまりそこをハッキリ定義してはいないですね。というのも、私たちはエンタープライズに特化した企業というわけではないんです。システムと人間が接するところに新たな価値を生み出せないか、そういうことをずっとやっている。

新谷: 私たちはデザインとエンジニアリングの両輪を回しつつ、ビジネス的な価値を創造することにはすごくこだわってる会社です。それが、私たちが「エンタープライズ系企業」と見なされがちな理由かもしれません。

齋藤: 確かにFlashの仕事を中心にしていた頃から、「エンタープライズ」と呼ばれる領域の仕事はやってきていますね。出退勤のシステムや、社内のアラートシステムをFlashで構築したり。それらの経験を踏まえつつ、あえてエンタープライズとは何かと言えば、「働く」という環境において利用されるものということでしょうね。「働く」という環境においては、人を働かそう、動かそうとするエネルギーがある。
それに対して、時には「動きたくない」と反発するエネルギーもあったり…って、こんなんで伝わります？(笑)。

白石: はい、大丈夫です、伝わってます(笑)。

齋藤: ってことで、業務で使用するアプリって、どうしても「（会社から）使わされる」という感覚が付きものだと思うんです。勤怠管理システムとかは、使わざるを得ないでしょ。それに、企業は何かと「管理したい」という欲望を抱いてしまいがちですが、それを形として表したものが業務アプリだったりもするわけです。つまりエンタープライズシステムっていうのは、最初からユーザーである従業員からネガティブな印象を持たれがちなもの、そういう宿命を背負っているシステムなんですよ(笑)。

白石: なるほど(笑)。ではお二人は、そのネガティブさをどうにか乗り越えて、価値を生み出すよう改善していく…っていうお仕事をされているってわけですね。それがエンタープライズにおけるUXを改善していくってところに繋がりそうですね。

エンタープライズアプリにUXが必要な理由

齋藤: 先程も申し上げたように、ぼくらは「エンタープライズかどうか」というところにはあまりこだわってはいないつもりです。ただ、UXには非常にこだわっている。例えば「エンターテインメント」であっても、「働く」ということであっても、人と情報が交錯する地点というのは必ずあり、そこにはUXが存在します。

白石: 「働く」という行為についてもUXがあるというわけですね。言われてみると当たり前ですが、気づいてませんでした。

齋藤: その通りです。だから、エンタープライズアプリのUXについて考えることは、「オフィスの椅子や机をどうするか」と言った、オフィスデザインを考えるのと本質的には変わらないわけです。

白石: なるほど。そういう捉え方は新鮮です。じゃ、オフィスデザインに真剣に取り組むような企業は、「働く」ということのUXを真剣に捉えていると言ってもいいわけですね。

齋藤: そうそう。そういう企業は、「働く」という体験を改善することにすごく前向きです。ならば当然、日々使うアプリとかも改善の対象になりますよね。職場のUXが改善されることで、職場がエネルギッシュになったりコラボレーティブになったりするなら、素晴らしいことじゃないですか。ちなみに私たちも、オフィスデザインには相当こだわってますよ。

白石: そうした、自社内のUX改善に投資する企業というのは増えてきてますか？

齋藤: 増えてきてる、と言っていいと思います。例えばBYOD（Bring Your Own Device: 個人デバイスの職場利用）なんかも、UX改善の文脈から語ることができます。使い慣れない／使いにくい端末を会社が押し付けるんじゃなくて、従業員が普段から使って慣れ親しんでいるスマートフォンやタブレットをそのまま業務用端末として使おう、という流れですね。

新谷: そういう流れの中で、エンタープライズの世界もモバイル中心になりつつありますね。今の若い人なんて、「PC持ってないけどスマホ・タブレットなら持っている」という人はザラにいるわけですから。いまだに「PC向けのWebアプリをスマホやタブレットに対応させる」という発想でシステム開発している場合がありますが、その発想はもう古いと言っていいと思います。「スマホ・タブレットで使えるものが、たまたまPCでも使える」という感覚に変えていかないと。

白石: モバイルファーストとか、今じゃモバイルオンリーなんて言葉も出てきてますもんね。

齋藤: こうしてBYODが進んでいくことで、個人のデバイスが「業務用端末」にもなっちゃうわけです。いわば業務時間はどんどん広がってきていると言ってもいいですよね。

そう、そして触れる時間が長ければ長いほど、UXも重要。だから、UXが磨かれたコンシューマー向けアプリを仕事に使うシーンもどんどん増えているんだと思います。FacebookやLINEで仕事のやりとりをするのとかも、珍しいことではなくなりました。こういう消費者向け製品を業務用に使うという流れのことを、コンシューマライゼーション(Consumerization of IT)と言ったりしますね。

今や、消費者向け製品のほうが進化が速いんですよね。以前は「企業が使っているものが安くなって、そのうち一般消費者が使うようになる」って感じだったのに、今はそれが逆になっちゃっている。例えばKinectみたいなものも今は1万数千円で買えるけど、昔ぼくらがああいうのを使ってアプリを作っていた頃は100万円くらいしていたんです。コンシューマー向け製品を使って企業が安価にモノを作る。そういう時代ですね。ここでも、発想を逆にしないといけない。

「エンタープライズアプリにUXは必要ない。だって『慣れる』から」という考えについて

白石: エンタープライズとUXというテーマで以前新谷さんとお話した時、「慣れる」というキーワードがありましたね。「最初は使いにくくても、使っているうちに慣れるから大丈夫」という考えがエンタープライズには根強い…というお話だったかと思いますが。

齋藤: その意見については、「何をおっしゃる！」…って感じですね(笑)。「慣れ」を考慮してUXの設計をするのと、「慣れ」を逃げ道にしてUXの設計を怠るのは、似ているようで全然違います。前者は熟練者への配慮。「初心者にやさしい」は、熟練者にとってはまだるっこしかったりしますからね。でも、後者はただの怠慢。ユーザの慣れを理由にして、UX改善の努力を放棄してはいけません！

「慣れ」を逃げの理由にしてはならない理由の一つに、まずは大きな話として、働き方の変化があると思います。派遣の方に来ていただいたり、いろんな企業を渡り歩いたりっていう働き方が普通になってきていて、一つの会社に腰を落ち着けて業務アプリにじっくり慣れる…っていう状況じゃなくなってきてるんですよ。

齋藤: それに、使うこと自体に「慣れる」ことはできるかもしれないけど、だからといって気持ちよく使えるようになるわけじゃないですよね。最初に触って「嫌だ」と思ってしまったら、その印象はずっとついて回るし、それが毎日のことになるとなると、働くモチベーションにも影響するでしょう。毎日アプリの使い勝手にイライラしつつ、出退勤の申請業務とかに時間取られちゃうっていうのは、バカにならないコストだと思いませんか？

白石: なるほど、言われてみればその通りです。それでも「慣れ」の話が付いて回るのは、結局のところUXへの姿勢の違いが現れる部分なのかもしれませんね。例えば、「リモートデスクトップをモバイル機器から使えるようにしとけばとりあえず事足りるだろう」みたいな。

新谷: ああ、そういう企業いっぱいありますね(笑) 。従業員にiPad渡したと言いつつ、従業員の皆さんはiPadでWindows XPの画面見てるとか。おっと、XPって言っちゃ怒られちゃうか…(笑)。

齋藤: ただですね、企業がとにかく何かしようとしている。そのことについては、肯定的に捉えるべきだと思うんです。「iPadでPCの画面を見る」のだって、機能は満たしている。ただそこに「UXがなかった」ということです。

なぜエンタープライズのUXはコンシューマー向けに比べて遅れているのだろう

白石: コンシューマー向けのWebサイトやアプリのUXは、この数年で本当に良くなってきましたよね。それは、言ってしまえばUXがサービスの売上に少なからず影響を与える…という意識が根付いたからだと思うんです。エンタープライズにおいては、そういう意識の変化は出てきていますか？例えば、「UXが業務の生産性を上げる」とか。

新谷: エンタープライズだと、UXの改善がもたらす影響についてのわかりやすい指標があまりないので、どうしても投資の優先度が落ちちゃうんですよね。UXの改善が、わかりやすく結果に結びつくといいんですけど。「オフィスデザインにこだわったらメディアに取り上げられた」みたいな、「褒められた」という経験でもいい。

齋藤: UX改善の結果がわかりやすいっていう話でいうと、パソナさんの事例があります。これ事例として紹介してくれていいと言われてるんですけど、システムに対して年間3,000件の問い合わせがあったのが、ぼくらが手を入れたあとはゼロになったんです。

白石: それはすごい！そのことによって削減される問い合わせコストもバカにならなそう。

齋藤: そうでしょう？何をしたかっていうと、よくある問い合わせを全部UIに仕込んじゃったんです(笑)。

白石: それはわかりやすい話ですね(笑)。

齋藤: 問い合わせの結果を分析して、「次に何をしたらいいかをわかりやすく記述する」とか、「エラーメッセージをわかりやすくする」とか、そういう努力を積み重ねた感じですね。

「UX的にイケてる」エンタープライズアプリって、どんな感じ？

白石: 具体的に「優れたUXを持つエンタープライズシステム」の例ってありますか？

齋藤: そうですね、二つ挙げられるんじゃないかな。

どちらも社内システムの話ですが、一つは従業員自らがUXの改善を行っていくという事例。もう一つは、その企業のコアコンピタンスを突き詰めるため、社内システムのUXを徹底的に改善したという先進的な事例です。

新谷: では、一つ目の事例は私の方からお話しましょう。

とある大きなメーカーの社内システムの構築を任されたのですが、そこの社員の方々にヒアリングすればするほど、どんどん要件が収集つかなくなっていくんです。ユーザーとなる従業員の数が多すぎて、ニーズがまとまりきらないんですね。一言で「社内システム」とは言うけれども、ユーザーそれぞれに話を聞いていくと、欲しがっているシステムが部門ごとに全く別ものだったりする。

そこで結局、MicrosoftのSharePointをプラットフォームとして導入することにしました。SharePointは非常に柔軟なシステムで、ユーザ自らがシステムに手を入れていくことができる。いわば、自分たちでUX改善を継続的に行っていけるようなものです。

齋藤: 私たちの会社だと、サイボウズのkintoneを使って、人事や総務の人たちが自らUIをこしらえたりしてます。こうした「フレキシビリティ」は、今後のエンタープライズシステムにおいてはとても重要になってくるでしょうね。

新谷: また、これらのサービスはクライアント技術としてHTML5が使われているというのも非常に重要です。HTMLやAjaxの知識があるなら、UIは自在に作っていける。データは一箇所に集約したまま、です。

齋藤: 二つ目の事例は、「ドモホルンリンクル」で有名な再春館製薬所さんのコールセンターシステムです。

コールセンターというのは、「同じ時間内で、どれだけ多くの問い合わせを捌くことができたか」が重視されるのが普通です。しかし再春館製薬所さんは、「お客様とどれだけ密なコミュニケーションをとれたか」が会社にとっての価値だと考えている。例えばコールセンターのオペレーターが、「最近お肌のトラブルはありませんか？」とか「お孫さんの誕生日もうすぐですね」とか、そういう話をお客様に向かってするわけです。 お客様としては、「あなたとお話したことないのに、なんでそんなことわかるの？」「私のことをどれだけ知ってくれているの？」という驚き、そして感動に繋がりますよね。

お客様にこういう体験を提供するために、コールセンターの画面 ― 再春館製薬所さんは「お客様」画面と呼んでいますが ― がどれだけ情報ポータルとして洗練されているか、その人自身を感じられるか、というところが彼らの課題だったのです。 かつ、オペレーションはミスなく、素早くこなせる必要がある。

そのために私たちは検討を重ねた結果、スクリーンを複数に分割した形のUIを採用しました。複数のお客様の情報を同時に表示して一覧性を確保しつつ、どれか一つの分割ビューにタッチすると素早く拡大表示される。再春館製薬所さんは「パネルウィンドウシステム」と呼んでいらっしゃいますが、私たちなりにカッコよく言うと、エキスパンド（拡大）型の「コックピットUI」です(笑)。

　　▲再春館製薬所コールセンターの画面「お客様画面」※写真提供：再春館製薬所

白石: ちょっと感動的なくらいの事例ですね。その話を伺って、以前エキスパートの竹洞さんにインタビューをした際に、「『自社が提供するサービスのユニークな価値とは何か？』という問いに対する答えを持たなければ、真のUX改善は望めない」とお聞きしたのを思い出しました。

再春館製薬所さんにとっては、お客様との密なコミュニケーションこそが会社の中核的な価値であり、そこを突き詰めた結果が、そうしたコールセンターのUI構築につながったんですね。あらゆる企業が自社のコアコンピタンスを自覚して、それを元に業務アプリのUXを改善していく…というのが理想なんでしょうね。

齋藤: その通りです。ただ、これは業務アプリとしては相当レベルの高い例ですよね。残念ながら世の中には、UXへの配慮が足りていない業務アプリも沢山ある。まずは、そうしたアプリを「普通」のレベルに持っていくのが大事かな、と。

白石: それは、「地に足のついた議論」って感じでいいですね(笑)。

齋藤: まずは「普通」を目指さないと。「事故がないオフィス」とか「事故がない厨房」とか、言うまでもなくあたりまえじゃないですか(笑)。それと一緒ですよ。

新谷: そうそう。まずは普通を達成して、その後初めて、CI (Corporate Identity) に基いてUXを向上…とかって話になるんですよね。

まとめのひとこと

白石: いやー、まだ聞き足りないことがたくさんあるんですが、お時間がきてしまいました。特に、「UXがエンタープライズ開発をどう変えるか」とかは、お聞きしたかった…。

齋藤: ぼくらだって、全然話し足りないですよ！
今回は、全5回のうちの1回目ってところじゃないですか(笑)。

白石: ぜひまたお話を伺いに来たいです！では最後に、今回のテーマである「エンタープライズとUX」について、一言いただけますでしょうか。

齋藤: 「エンタープライズアプリにUXは必要か？」なんて、ぼくから言わせると「何をいまさら」って感じです。むしろ、エンタープライズだからこそUXでしょ？と。企業は人材こそ命でしょ？従業員あってこその企業でしょ？

従業員に建付けの悪い椅子とかあてがってたら、みんな腰痛で会社来なくなっちゃうよ、と(笑)。いい椅子買おうよ、と。エンタープライズアプリのUXに配慮するというのは、そういうことです。ぼくは、業務システムのUX改善は、福利厚生の一つだとすら考えてますから。

新谷: 私は、エンタープライズのUXがなかなか改善されないのは、UXという言葉や技術に対して「食わず嫌い」する姿勢も原因の一つだと思ってるんですよね。難しく考え過ぎているところがあるんじゃないかと思うんです。

特に最近はSharePointやkintoneなど、ものすごく手軽にUIを修正したり構築したりする環境が整ってきているのに、結局それを外のSIerに発注したりしてしまう。すると、せっかくUXを自分たちで改善していける環境があり、流れも来ているのに、台なしになってしまう。難しく考えずに、自分たちの使っているアプリがどうやったらもう少し使いやすいかを考えて、実際に自分たちで改善していく。そういう流れを作っていけたらなあ…と思っています。

白石: おふたりともお忙しい中、インタビューにお時間を割いてくださって、本当にありがとうございました！とても楽しくてためになる時間でした。

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

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

どうぞ、お楽しみに！