HTML5の機能をどこまで活かせるか--新日鉄住金ソリューションズの「hifive」で実現できること

「hifiveで実現するエンタープライズ　HTML5 Webアプリケーション開発」

下田修氏（以下、下田）：それでは、「hifiveで実現するエンタープライズ　HTML5 Webアプリケーション開発」と題して、下田が発表させていただきます。よろしくお願いいたします。

簡単に自己紹介をさせていただきます。私はシステム研究開発センターという、弊社の研究開発部門に所属しています。入社以来ずっと、サーバーサイドも含めて、Webアプリケーション技術の研究開発をしてきています。

私は2011年の開発当初から、今日お話しさせていただく「hifive」というHTML5活用のための開発プラットフォームのアーキテクチャ設計や開発全体のリードをしています。

またIoTといったところにも少し手を広げながら、システムアーキテクチャの研究開発をさせていただいています。

簡単に弊社のシステム開発研究センターについてお話しさせていただきます。弊社が会社として発足したのは2001年になります。

それより前は、新日本製鐵の情報通信事業部と、新日鉄情報通信システム（ENICOM）という会社があり、両者がくっついてできた会社ですけれども、システム研究開発の部隊もその当時から存在した部隊になります。それがそのまま継承されて、現在のシステム開発研究センターにいたるというかたちになっています。

組織的には3つの研究部からなっています。1つは、いわゆるインフラ、ネットワークとか、あるいは最近でいうとセキュリティとか、そういったシステム基盤を研究する研究部。

それからもう1つ、データ分析というところで横断的に串を通して、データ分析技術であるとか、そのためのいろいろなインフラ基盤、データウェアハウスやBI等といったところを研究開発している部隊があります。

私が所属しているのは、（スライド）一番上のイノベーティブアプリケーション研究部というところです。

現在では、アプリケーション開発全般、いわゆるシステム開発とソフトウェア開発のプロセスやUI・UX、最適化問題などを研究するアプリケーション全体の研究部でございます。

「Webの進化の今」“Living Standard”

では、「Webの進化の今」というところで本題に入っていきたいと思います。

おさらいすると、今から約10年前、iPhone 3Gが日本で出たのが2008年です。そのときに、いわゆるHTML5という仕様ということで、最初の草案ができました。

そこから2014年にHTML5ということで正式に仕様が勧告されるなかで、互換性が向上する、その仕様にブラウザベンダーがみんな寄っていったというところとか、表現力や通信関係の機能、パフォーマンスが向上するといったことがありました。

もちろん今でも新しい高機能も含めて、Webの世界はどんどん広がっているわけですけれども、開発、とくに業務システム向けの機能というところで考えてみると、けっこう多くのシステムを作るための基本的な表現力やパフォーマンスというところは備わってきたと感じています。

では、業務システム、企業システムの開発というところで、個人的に最近どういうところに興味があるかと考えますと、一言でまとめると「モジュール化技術」と言えるかと思います。

やっぱりいろんなことができる、アプリケーションが複雑化してきたというところで、フレームワークやいろんなライブラリが揃ってきてはいるものの、ブラウザ自身の仕様として、もうちょっと大規模な開発に対応したり、JavaScriptの言語自体もいろいろ変わりつつありますし、「Web Components」みたいな仕様をご存知の方もいらっしゃると思いますけれども。

そういった仕様群として、部品化をブラウザのネイティブの機能としてより推し進めるような機能というのを、今まさに各ブラウザベンダーが競うように実装しているところだと思います。

これはブラウザのバージョンアップを簡単に並べたものです。

2000年とか2005年ぐらいのところというのは、長いスパンでブラウザのバージョンが1個2個上がるという世界だったのが、今では6週間に1回、バージョンが1個上がる。「バージョン」という概念は本当にスナップショット的な意味合いしかなくて、基本的には継続的に変わっていくという世界が当たり前になったということが言えるかと思います。

というわけで、先ほどのお話とも繰り返しになりますけれども、Webの世界というのは継続的に変わる。少しずつ変わっていくというのが、仕様という意味でもそうですし、ブラウザの実装という意味でも、やはり常識になってきている。

そうすると、やはり使う側、開発する側という立場から考えると、継続的な変化に対応し続ける仕組みを考えなければいけなくなってくると思います。

（今までは）「ブラウザはIE8限定、画面サイズもXGA（1024×768）で固定」のような世界観のほうがいろいろ都合がよかったのが、やはりそうもいかなくなってきていると。

いろいろなブラウザに対応したり、とくにスマートデバイスに対応したりというところを含めると、ちゃんとHTML5の仕様に則って作るほうがよいという世界に変わってきていると思います。

業務システムの開発とクライアントのリッチ化

もう少し「業務システムの開発とクライアントのリッチ化」というところにフォーカスをしてみます。

業務システム開発の一般的な特徴を簡単に並べています。IT戦略全体というところから、よくある保守や維持のための費用から、なるべく攻めのための投資に転換したいというのは、ずっと言われていることです。

開発のプロセスや体制というところで考えますと、当然多人数で開発する、あるいは分散・分担で開発する。いわゆるオフショアを活用した開発ということも、今は非常に当たり前になってきているかと思います。

かつ、スマデバ（スマートデバイス）向けのアプリですと、スモールスタートとか、アジャイル的な開発スタイルをとるところもどんどん増えてきていると思います。

どれぐらいの効果があるのかは見えにくいけれども、やっぱり手は出していきたいというときに、一度に大きなシステムを作るよりは、必要なところから対応していくというスタイルが最近増えてきていると思います。

もう1つは運用・保守という観点です。やはり業務の変更によってずっと改造されていく。そもそも業務システムは使われてなんぼということですけれども、それが長い間、数年とか、ものによっては10年以上くらいのスパンで使われるというのが、業務システム開発という意味では一般的な話かと思います。

クライアントのリッチ化と実装要素の増加

（スライド）下が、Webアプリを記述するための言語、CSS（スタイルシート）とHTMLとJavaScriptです。このスライドは、クライアントがリッチになってくると、それによってどういう要素を書くのか、というのをマップしたものになります。

本当の業務ロジックは通常サーバーサイドにあるのがほとんどだと思いますので、これはオフラインで動作するときに一部、という感じですけれども。

昔はJavaScriptで入力値チェックとか、そういうバリデーション程度のことをやっていたときは、本当にクライアントサイドで表現するのはビジュアルなデザインとか、せいぜい少しボタンを押したときになにか色をつけるとか、バリデーションで少しチェックのエラーのメッセージを出すとか、そういった程度だったのが、もう少し業務に近いような、ロジックとか画面遷移のフローの制御とか、そういったものもどんどん入ってくると。

HTML5の表現力を使うというのは、結局、クライアントサイドで実装するものがいろいろ増えるということになるので、ライブラリやフレームワークを使って自分で実装する量を最小化するというのはもちろんありますけれども、全体としては、やはりこのJavaScriptの量は増えると。かつ、内容的にも「なにを書くか」という実装する要素・役割が増えていくというのがあるかと思います。

なので、よくそこでフレームワークによって問題を分割する、つまり、どういったところにどういった処理内容を書くかをルール化していくわけです。

データを扱う部分と画面を構築する部分をきちんと分けておいてメンテナンス性を向上させるとか、そういったところが必要になって、さまざまなフレームワークが生まれてきたという経緯があるかと思います。

今度はシステム開発におけるさまざまな課題を開発のフェーズごとに並べ直したものになります。もっとも、これらはクライアントサイドだから、今これらの問題が初めて現れてきたわけではもちろんなくて、従来からあったものです。

クライアントがリッチ化してきたことで、従来はクライアント、とくにWebアプリケーションの場合は、HTMLの描画とCSSみたいな簡単な装飾のところぐらいだったのが、本格的にアーキテクチャみたいなものを考えないといけないようになってきたと。

フレームワークだったり規約だったり、そういったものの必要性が出てきたということが言えると思います。

「hifive（ハイファイブ）」の概要

そういった背景がありまして、弊社では「hifive」という開発プラットフォームを2012年から提供しています。

「hifiveとは？」というのをひと言で言いますと、次世代Web標準、もはや次世代という単語が取れつつありますけれども、今のWeb標準を活用した、企業Webシステム開発のためのプラットフォームとなっています。

2012年の4月というのは、本当にこういったフレームワークが出てきたなかでは、実はかなり早いほうです。それ以来、我々も実際に案件のなかに入って開発をしたりしながら、いろいろなバージョンアップを重ねてきています。

このhifiveというのは、弊社では初めて自社開発のもので、オープンソースとして提供したものになっています。Apache License Version 2.0で、商用システムにもお使いいただきやすいライセンスで提供しています。

やはり業務システム開発するときは、いろいろなライブラリを使ったり、組み合わせて開発する、あるいはWebの仕様や今のブラウザの進化のスピードに対して、「どうしても運用期間・保守の期間を考えると、少し落ち着いたスピードで進化していってほしい」とか、「そうはいっても、それなりに古いバージョンのサポートを考えてほしい」とか、そういった業務システム的な都合やニーズがあるもので、我々なりにその辺を考えて取組みをしているところであります。

hifiveといったときに、「フレームワーク」と言わずに、よく「プラットフォーム」という言い方をさせていただいているのは、いわゆる本当の骨格に対応するようなフレームワークだけではなくて、その上に、とくに業務向けでよく必要になるようなライブラリ群のようなもの、あるいは、そういった部品を作るためのベースになるようなライブラリを一緒に提供しているのが特徴になります。

もう1つは、支援ツールとか、今日は（会場の）後ろに本が置いてありますけれども、ガイド／ドキュメントあるいは書籍とか、日経BPさんのITproに少し連載をさせていただいたりというかたちで、情報公開をさせていただいています。

こういったものをひとまとめにして提供しているのが、「hifiveはプラットフォームです」という言い方をさせていただいている意図でございます。

コアフレームワーク概要

今日はフレームワークの概要・内容についてはほとんど省略させていただいて、「実際にどれぐらいのことができるのか」というのを主題に、残りの時間を使いたいと思います。

コアのフレームワークの部分は、ブラウザ上で動作するJavaScriptのコードの構造化をサポートするようなものになっています。

非常に薄い仕組みにしておりまして、言語のネイティブの機能などで解決できることはなるべくそちら側に任せようという考え方にしています。

あとは、バージョンアップのスピードや互換性維持にはかなり配慮をしています。古いバージョンのライブラリとの組み合わせを自動テスト、CI（継続的インテグレーション）のような仕組みを回してテストをしています。

あとは、（スライドに）「ほかのライブラリの併用をできるだけ妨げない」と書いているのは、「DOMの操作はこのhifiveのAPI経由じゃないとできません」とか、そういうことはしないようにしています。

イベントのバブリングのようなものは、そのままほかのライブラリからも取れるし、ほかのライブラリが普通のDOMの仕組みに則ってくれていれば、hifive側でもそのイベントをハンドリングできるとか、そういった、なるべくWebの標準仕様に則ったかたちで機能を実装するようにしています。

これはもちろん一長一短な部分はありまして、その代わりに「ブラウザのバージョンによって」という、互換性の部分でトレードオフな部分がないわけではないんですけれども、やはりそこはバランスを取りながらではありますけれども、なるべくネイティブの機能を使いながらやる、薄い仕組みにしておくことを考えています。

高機能UIに注力したライブラリを開発・提供

もう1つは、業務システム向けのライブラリというところで、我々は高機能なUI部品に注力して開発・提供しています。

どういうところが業務システム向けかとお話ししますと、やはり大量のデータを扱う、そのなかでもパフォーマンスが落ちないように表示・表現してくれるところがポイントです。

言ってしまえば、IE11は今となってはかなりパフォーマンスが遅いブラウザになっていますけれども、それでもそれなりに動いてくれるぐらいの、いろいろ内部的なチューニングをして、部品として使えるようなものを提供しています。

もう1つは、開発を効率化させるツールの提供というところで、実装やランタイム時、デバッグ時にそれを効率化するツールを提供しています。

では実際に、HTML5の機能を使って、どんな業務システムが実現できるのか、そのために内部ではどういった工夫をしているのか、というところを少しご紹介したいと思います。

私の講演では、とくに機能的なところ、それをパフォーマンスよく実現するために工夫していることをお話しさせていただきたいと思います。今日は大きく分けて3つのパターンをご紹介したいと思います。

1つ目は、フォーム入力・帳票的な画面に対する取組み。

2つ目は、モバイルの活用というところで、現場作業報告（モバイル活用）。

3点目は、計画系・データ視覚化。我々は勝手に「計画系」と呼んでいるんですけど、例えば販売計画や製造の計画など、そういったものを作っていくような画面のUIに関する部分、あるいは、データの視覚化に関する画面の例をお話ししたいと思います。

事例1 フォーム入力・帳票

1つ目は、フォーム入力・帳票的な画面についてです。

これはHTML5になって初めてできるようになったというわけではないんですけど、やはりいろいろな機能に対するニーズが高いところであると思います。

よく「タブの遷移の順序をうまく制御してほしい」とか、「特定の入力値だった場合にはこっちに遷移してほしい」とか、「なるべく入力の手数を少なくするように、ユーザーがストレスなく実装できる仕組みにしてほしい」とか、お聞きになることが多いかと思います。

単純な入力値のバリデーションやエラー表示は当然ですし、入力値をいくつか入れたらオートコンプリートで候補を出してくれるとか、あるいはファンクションキーのショートカットの対応ですとか、そういったことをいろいろと整理する必要があるかと思います。

これについては、hifiveとしてもライブラリというかたちでフォームの制御機能を提供しております。

例えば、このようなフォームの画面があった場合、この入力値をまとめて取り出してきて、今だとバリデーションや値のチェックを簡単にかけたのちに、Ajaxでサーバーに投げるということをよくやると思います。

そういった値をまとめて取ってきてオブジェクト化するとか、いろいろな種類のトリガー、イベントにもとづいて、バリデーションとか、タブの遷移制御とかを発動させるような仕組みを提供しています。

それからもう1つ、帳票的な画面ですけれども。データグリッドと言い直してもいいかもしれませんが、これについてはかなり要望の高いところです。我々もお客さんと話をしていると、究極的にはエクセルのような画面・操作性を求められたりします。

そういった表に対して、例えば、複雑な結合やソートをかけているとか、一部分だけをスクロールするとか、ヘッダを固定するとか、あるいは下のところには別のデータ項目として、集計行を出してほしいといったものがあると思います。

あるいは、この画面はサンプルですけど、特定の一部の行だけを表示／非表示にしてほしいとか、行を開いたり閉じたりしてほしいとかいう例もよくあります。

また、これはまさにエクセルのセル的な動きになりますけれども、こういったかたちでキー入力でセル移動や文字入力をするとか、一部分は選択項目としてほしいとか。あるいは一部分は固定した状態で、一部分だけスクロールしてほしいということがよくあると思います。

機能的な観点で、今みたいなものが実現できるようなデータグリッドの部品を提供しているんですけれども、こういった機能性のほかに、行数が増えた場合にもパフォーマンスを可能なかぎり維持できるようにしているというのがhifiveのデータグリッド部品の1つの特徴になります。

データグリッドのライブラリは世の中にたくさんありますが、データ行が少ないときはそれなりに動いてるんだけれども、データ数が増えてきたときに遅くなってしまうとか。行方向に増えるときにはパフォーマンスがよくできるんだけれども、列方向に増えていったときにパフォーマンスが劣化するとかいう制約があったり。

あるいは「結合と〇〇の機能は同時に使えない」という制約があることもありますけれども、hifiveのデータグリッドの部品ではそういったことをそれなりに考慮しています。

実際に、別の部品で同じような画面を実装していた例で、最初の開発期にあまりデータ数を多くしていない状態だと問題なさそうだったんですけど、実際のデータ量になって1,000行のデータを表示させるとなったときに、スクロールを動かすとブラウザが固まるとか。

そういう状態になっていたものに対して、hifiveを取り入れてこのデータグリッドの部品を適用するということをやった案件がありました。

そのときは本当に、スピード的には100倍以上。その部品はもう完全に動かなくなっていたので、「何倍」とも言えないぐらいの高速化になりました。

そういったかたちで、ほかのライブラリでデータとして扱えないような量のデータをうまく扱える部品を提供しています。

事例2 現場作業報告（モバイル活用）

2つ目、現場作業報告（モバイル活用）に移ります。これは、タブレットが持つカメラなどの端末機能も今ならWebでかなり活用できます、というご紹介になります。

今、iPadの画面をディスプレイしています。上にタイトルが書いてありますけれども、店舗巡回指示という業務のデモアプリケーションになります。

デモの意図としては、いろいろなお店とか現場を回って作業をして、その報告をタブレットを使って行うというワークフローを模したものになっています。

今、ここに地図が表示されていますけれども、これは実際に今、HTML5のGeolocationというAPIを使って、GPSの位置を取ってきて表示してるものになります。こういったかたちで地図に現在位置を表示させることができます。

スマートデバイスの活用というと、よく写真や動画を撮るということがありますけれども（カメラ機能を起動）、ちょっとここで、この場かぎりで写真を撮らせていただきます。（撮影した写真をタブレットに表示して）こういったかたちでスマートデバイスの写真機能もWebから使うことができます。

単に写真を撮るだけではなくて、動画も撮ることができます。さらに、単純に写真を撮るだけではなくて（撮影した）画像にアイコンを乗せてマーキングしたりすることもできます。

こういったかたちで、作業した場所にアイコンを置いて、「どこで何をした」みたいなものを手書きすることも、Webの技術の範疇でできるようになっています。

今PC側に画面を戻しましたけれども、今タブレットで撮った写真や動画をサーバに送信して、PC上でこの画像を見たり、動画を再生してみることができる、という仕組みです。

同じように、位置情報をサーバーに送信して、Google Mapを使って表示するといったこともできるようになっています。

ちなみに、IE11でもこのように動画を表示したりはできます。IE11を推奨するとか、よくないという話ではなく、どうしても業務システムで「IE11だから……」と諦める部分をよくお聞きしますが、こういった表示系の部分に関して、モバイルから報告を送って、それをPC側で見るといったようなことであればIE11でも実現できる、ということがおわかりいただけるかと思います。

事例3 計画系・データ視覚化

それから3点目、計画系・データ視覚化です。データ視覚化というと、代表的にはグラフ、折れ線グラフとか円グラフといったグラフ表示があります。

また、（スライドの）一番左の図に乗せていますけれども、ノードとエッジからなるグラフ構造の可視化、あるいはデータグリッドの一種の視覚化、大量のデータを扱うという意味では、その一部かと思います。

hifiveとしては、ここに対して高速な描画をサポートするライブラリを提供することで、業務システムのデータを可視化したいというときに、それをサポートできるような仕組みを作っています。

右側に3D的な表現の例を出しています。3D表現についてはまだいろいろと取組みを推進しているところで、なかなか綺麗なサンプルとしてお見せするのは難しいんですけれども、最近はブラウザでも3Dの表現をすることができるようになってきていますので、そういったところにも最近は力を入れています。

あとは、業務系のシステムですと、やはりいろんな状況で「画面を目一杯使いたい」「文字もギリギリ最小限に詰めて必要な情報を1画面に出したい」というニーズがありますけれども、それに対して、自由にパネルを開いたり閉じたり、自分でサイズを変えたりできるようなレイアウトの部品も少し提供しています。

それから、これは内部で動く機能なのでちょっとデモ的にお見せするのが難しいんですけど、データのフィルタリングをするような仕組みも用意しています。

特定のデータのオブジェクトがあるなかで、条件を与えるだけで、指定された条件にマッチするデータのオブジェクトを取ってくる。かつ、その取ってきたデータのオブジェクトを書き換えたときには、ちゃんと元のデータに対して更新データを走らせるということができます。

hifiveが高パフォーマンスを実現できる理由

最後に、hifiveとして今までパフォーマンスに注力してUIの部品を提供しているというお話をしてきましたけれども、それをどのように実現しているかというお話をご紹介したいと思います。

1つは、このたくさんのデータを描画するときに、当然データに紐付いて画面にオブジェクトが描画されるわけですけれども、それをなるべくJavaScriptのエンジンのなかに閉じて行うということをしています。

これは先ほど（のセッションで）少し出た、Reactとか、Virtual DOMと呼ばれるようなものと考え方にはちょっと似たような部分があります。

HTMLのDOMのレンダリングエンジンをJavaScriptから何度も触ると、けっこうなパフォーマンスのロスになってきますけれども、なるべくそれを抑えることで、大量のデータを表示しなきゃいけないときでも、どの位置にどういうオブジェクトを表示すべきかみたいなものは、なるべくDOMのほうではなくて、JavaScriptのエンジンに閉じてやるということをしています。

それだけだと、Virtual DOMやReactとあまり変わらないわけですけれども、イベントハンドラを最適化するとか、（スライドに）少し模式的な図を載せていますけれども、実際に見えている範囲だけを描画するという仕組みをかなりチューニングして実装しています。

なので、実際にデータとして存在する範囲、このグラフ構造全体としては、外側の範囲を描画しなければいけないんですけど、ブラウザに実際に見えているのが緑色の範囲であれば、画面上に本当に描画するのはここだけにするということをやって、必要最小限の描画量で済むようにしています。

もちろんこのグラフ全体をどうしても1画面に表示したいとなると、パフォーマンス的にはほとんど変わらなくはなります。あるいは余計な計算をする分、ちょっと遅くなるぐらいなんですけれども、現実的には一度に表示する量、人間が見て有用である量には上限がありますので、今のブラウザのパフォーマンスであれば、だいたいの場合は必要な描画オブジェクトの数をさばくことができます。

画面に同時に出さなければ、データ量が増えても処理時間はリニアに伸びていかないので、データ量が増えても大量のデータを扱うことができるという仕掛けになっています。

こういうことをやるにあたって、いろんなパフォーマンスのベンチマークみたいなものを取っていますけれども、単純な矩形の描画やテキストの描画をするときにもいくつか方式がありまして、そのなかでなるべく一番早いやり方を取るようにしています。

その分内部の計算量、JavaScriptとして位置計算をするものは増えるんですけれども、そことのトレードオフを見つつ、速い方式で描画する仕掛けを内部的に持っています。

ということで、業務システムでありがちな例を踏まえながら、フォームの入力や帳票的な画面、それから現場作業報告（モバイルの活用）、最後にデータ視覚化とか、データをいろんなかたちで見ながら行う計画的な業務に関して、hifiveとして機能面とパフォーマンスに注力して部品を提供しているというところをご紹介してきました。

私の講演は以上となります。ありがとうございました。

（会場拍手）