ふろしき.js

エンタープライズITを支える、Web技術とモバイルの今を追う専門ブログ!

モビリティは今、どのように進化しているのか?

デスクトップPCだけじゃなく、モバイルやタブレット、ウェアラブルデバイスの特徴を活かして、仕事を良くしよう。それが「モビリティ」という考え方です。ただ、実際の所はデスクトップとモバイルを隔てる壁が大きかったりします。モバイルのセキュリティを高める程度の議論で止まってて、モバイルでできることの限界みたいなのにぶち当たっていたように見えます。しかし、クラウドの地盤が固まったことで、ようやく次の世界へと進みつつあるようです。

これからのモビリティとは!?

イマドキのモビリティとはどういうものなのか、そのイメージを掴んでみましょう。どの製品ベンダも提案している内容はそっくりなのですが、個人的にはマイクロソフトのPV「A Day in the Life of a CVP」が、結構ポイントを掴んでいて一番わかりやすかったです。

マイクロソフトも、WindowsのXP(体験:Experience)はとっくにサポート終了していたはずですが、体験を売ろうという姿勢は未だにサポート終了していないようですね。せっかくですので、一つの例として、ご紹介してみます。(※静止画だとわかりにくいので、想像で字幕を入れてお届けします)

やや緊張ぎみな雰囲気で車に乗り込む彼女。これから移動でしょうか?
f:id:furoshiki0223:20140809232107p:plain
モバイルが電話会議ツールに早変わり。メンバと情報を入念に交換を始める
f:id:furoshiki0223:20140809232144p:plain
お客様のビルへ到着し、タブレットでShare Pointサーバ上の資料を探しているように見えます
f:id:furoshiki0223:20140810081437p:plain
会議室に入りました、いよいよ本番のようです。
f:id:furoshiki0223:20140810081857p:plain
直前の作業はノートPCで。こっちのほうが、入力が楽ですしね。
f:id:furoshiki0223:20140809232218p:plain
プレゼン中はタブレットに変化。手前のディスプレイにも表示
f:id:furoshiki0223:20140809232249p:plain
おや?お客様から何やら意見が出てきたようです。
f:id:furoshiki0223:20140810082659p:plain
焦燥する彼女。やばい、どうにかしないと!
f:id:furoshiki0223:20140810062501p:plain
すぐにペンを取り出し、タブレットにそのままメモをとる
f:id:furoshiki0223:20140809232338p:plain
終わったので帰りますよと、部下にスマートフォンでメールします。
f:id:furoshiki0223:20140810083440p:plain
別の会議室では、スクリーンの予定表にタッチ。TV会議のセッティング
f:id:furoshiki0223:20140810083631p:plain
お?会議室に人が入ってきました。彼女です!彼女が帰ってきました!
f:id:furoshiki0223:20140810083853p:plain
真剣な眼差しで、スクリーンに色々書き込みながら客先訪問の内容を語る彼女
f:id:furoshiki0223:20140810084111p:plain
部下たちも真剣です。というか、なんか凄くがっかりしてますね。あと国外でも、客先に行かない人は私服なんですね。そこは日本と一緒?
f:id:furoshiki0223:20140810084432p:plain
会議が終わり、仕事も閉めに入ってます。そこはノートPCみたいです。
f:id:furoshiki0223:20140810084624p:plain

モビリティ自体に馴染みがない人には、いやいやこれはぶっ飛び過ぎだろう、SFの世界ですか?といったところでしょう。ただ、従来の「モバイルだけ」「デスクトップだけ」に閉じていた状態でモビリティを体験していた人にとっては、痒い所に手が届き始めたなぁなんて印象を受けるに違いありません。このあたり、各ベンダは「流動的」とか「シームレス」という言葉で表現していることが多いようです。

モビリティ適用の入り口として、まずよく聞くのがマネージャの決裁業務のリアルタイム化です。通知させて、タッチで決裁を完了させる。またどこまで進んでいるのかを確認することを、デスクトップPC&メール通知という形式では到底敵わないようなエクスペリエンスとして提供するのです。これがメンバーレベルになると、予定表との連動。例えば、マイクロソフトのオフィスとかだと、ミーティングの前には通知のバイブ音が一気にブーブー鳴り出して、ミーティングルームに向かい始めるみたいです。彼らに言わせれば、こんなのはまだモビリティの入り口みたいなものなのでしょうが、モビリティを体験したことがない人には直感的で分かりやすい事例に思えます。

IBMでエバンジェリストをやっている佐々木 志門氏は、もはや研究家という域に達するほどのモビリティ人でして、腕にウェアラブル・デバイスを巻きつけ、Chrome OSやらAndroidやら、色んなノートPCとモバイル山ほど持ち歩いて何kgあるねんとツッコミたくなるようなかばんを持ち歩き、いろいろと活用の可能性を探っています。彼は腕についてるデバイスが、通知が来る都度スルーしたり反応してみたりと、モビリティやってますなぁという感じが見て取れます。その精神、すばらしい。ぜひとも勉強会にスーツケースを持ってくるようなキャラクターであってほしい。そんな感じで、彼らの様子見ている限り、モビリティはディスプレイの前に座っていることを前提とすることからの脱却というよりも、「通知」をどう扱うかが取っ掛かりとしてわかりやすいようですね。

これに加えて、スマートフォンはカメラもついているし、明るさも取得できるし、場所の取得もどんどん精度を上げてきているしで、できることの可能性がどんどん広がっています。近くの駅をアプリに探させて、タッチで入力すれば出張申請が完結できるような時代は、少なくとも10年後には当たり前になっているはずです。通知だけが全てでないし、これからも色んなモバイルの形が出てくるはずなので、そこにどんなアイデアを生み出すかがエンジニアの価値に変わるようにも思えます。

どうやって実現するのか?

こういうものを実現する仕組みは、MEAPだったりMaaSだったりで、結構色んな方法が出てきています。だいたい共通しているのは、持ち運べるようなコンピューターにはMDMやアクセス管理機能などのセキュリティ機能が入った箱庭を構築しており、大抵はクラウド(オンプレミスなものもある)との連携が大前提になっています。

f:id:furoshiki0223:20140810002736p:plain

まだまだ先端という感じが否めず、業界標準に相当するものは見当たりません。OSSだけだと、まだまだ問題があって辛かったりもするので、私はベンダ製品もOSSも両方しっかり見るようにしています。

OSSの動向としては、まず、Mozillaは「FirefoxOS」に力を入れているので、あとは進化が停滞気味のOSSのメーラー「Thunderbird」のプロジェクトさえ本気を出してくれたら、いい感じにオープンなモビリティが始まるのだろうと感じています。そして、モビリティでは要となるオフィススイーツでは、オープンソースの「LibreOffice」がブラウザ上で動作させる「LibreOffice in a Web Browser」プロジェクトを立ち上げているので、このあたりが突破口になってくれないかと期待しています。

なので、Mozilla FoundationはそろそろLibreOffice開発チームとエコシステムを作って、「FirefoxOS + Thunderbird + LibreOffice」で、オープン・エンタープライズ・モビリティ的なことをやって欲しいなぁという淡い期待を抱いています。FirefoxOS前提だと微妙かもですが、クロスプラットフォームでこれをやろうとしたなら、マイクロソフトとIBMはほぼ間違いなくコミッターを出すし、そのうちGoogleからも出てくる。あとはエコシステムの調整さえしっかりすれば、世の中のモビリティの進化と普及は爆発的に進むでしょう。一応、OpenmobilityというOSSのプロジェクトは出てきているのですが、本記事でとりあげる「エンタープライズ・モビリティ」とは若干違う感が否めず、製品ベンダが動くような雰囲気には達していないように思えます。

一方で、ベンダ製品側はどうなっているのか。具体的なものを紹介しますと、マイクロソフトはWindows 8系やPhoneがそういう仕組みのOSになっていたりしてて、少しばかりのパッケージを追加すれば運用面のリスクを潰せるので、「Windows + Office 365」の組み合わせで、ちょっとしたモビリティを体験できるようになっています。彼らはWindowsに縛るつもりはなく「Visual Studio 2013(Multi-Device Hybrid Apps)」をリリースしていたりと、これからもっと色々幅を広げてきそうです。IBMといえばApple製品なので、「Apple製品+MaaS 360」という組み合わせになります。これに加え、業務アプリの開発は「Worklight」を活用して、不足を埋めていくイメージのようです。この2社、結構色んなものがぶつかっています。

オフィス製品抜きのビジネスソフト周りだと、サーバサイドやパッケージを売るベンダ。MEAPと呼ばれるものが中心です。SAPは割と強かなので、同社の強みを活かしたMEAP製品「Mobile Platform」を「BYOD」と謳い売り込んでいます。ただ、実際のところは私用端末を活用(BYOD)するより、企業で配布する形がベストですよという提案をしているようです。日本だとそのほうがいいよと、他の製品ベンダからも聞こえてきますので、国内だとモビリティの鉄板の進め方になるように思えます。オラクルも「ADF Mobile」が、今年の8月2日にようやくデバイス管理系の機能性を満足させてきたので、モビリティというムーブメントへ自然に乗っかってきている感触があります。オラクルはJavaとの親和性がいい感じで開発の道具が揃っているので、Java好きな人には楽しめるかもしれません。

【連載:モビリティとは何か?】
  1. モビリティとは何か?企業にモバイルが求められる理由
  2. モビリティは今、どのように進化しているのか?
  3. モバイルファーストじゃダメな理由、モビリティファーストに求められること(8/14)
  4. モビリティの価値を大きく変える、5つのキーワード(8/15)

モビリティとは何か?企業にモバイルが求められる理由

「企業向けのシステムって、これからはモバイルファーストになるんですよね?」

「モバイルファースト?うーん、いや、少し違いますね。『モビリティ』の方を、私としては薦めたいのですけどね。うちは、体験を売りたいんですよ。」

「モビリティ!?」

そう答えるのは、日本マイクロソフトの大西 彰氏。これは、先日私は翔泳社主催のイベントにて、パネルディスカッションの司会を担当した際に起きた一コマです。私は事前に彼らの情報をチェックしていたものですから、どんな反応が返ってくるか完璧にシミュレート済みで、ストーリーもしっかりと準備していたわけです。そこに、大西氏は私の予想を大きく外れたこんな答えを突っ込んできました。モビリティ!?まさか、そんな展開になるとは…

その6日後、私は青山で開催されたオラクルのエンタープライズ・モバイル・サミットに参加しました。それはもう「企業向けモバイル」がテーマなのだから、参加者は色んなメーカーのタブレットやガジェットを使ってくるに違いない。私は他の企業がどんなものを使っているかが凄く気になる体質なので、公開スパイができるとワクワクしていました。目を瞑れば、管理端末シールが貼られた色とりどりのデバイスがテーブルを埋め、虹色に染まった会場なんかが目に浮かんでいたわけです。

ところが、会場の中、数名を除くほとんどの参加者が、紙のノートを広げ始めます。見栄を張って色々持ってきた私が、なにか不道徳なことをやっているような感覚に陥るくらいに、見渡す限り紙のノートばかり。あまりにもショックで、それはもう世界のITから日本が取り残されているような疎外感なんかも感じたりして、混乱した私は丸3日間も拡散が止まないようなツイートまでこぼし始めます。

まさかここまで日本企業にモビリティが広がっていないとは。こりゃ確かに、モバイルファーストどころじゃない。こんなことは全くもって想像していなかったので、当然、私のカバンには紙切れ一つ入っていません。

「なんか私の机、スクリーンが光ってて恥ずかしい感じになってる。間違っちゃったなぁ。すごく、帰りたい。けど、仕事だしマズいよなぁ・・・。」

下がり続けるテンション。そんなムードの中、来日していたビル・パタキ氏のセッションが開始されます。そして彼は、始まって早々、穏やかな口調でこのように主張します。

「企業の『モビリティ』は、挑戦が求められているのだ!」

私「(この会場、モビリティを挑戦させる以前に、始まってすらいない?)」

そういえば、今年の7月。IBMとAppleがコンビを組んでエンタープライズ・モバイルで提携することをアナウンスしましたが、彼らのモバイル製品のサイトの一際目立つ所にもこんなキャッチコピーが書かれています。

f:id:furoshiki0223:20140807195110p:plain
"企業の『モビリティ』の次の段階、それは、どこにいてもデータがその役割を果たせることだ"

「みなさん、もうすでにモビリティはやっていますよね!?」といった感じのノリばかり。それどころか、どのキャッチコピーも「そろそろ御社のモビリティも、次に行く頃ですよね?」ってな具合で、欧米ではもはや普通と言った感じ。うーん、これはどうしたものか。なんとなくですが、日本ではモビリティという言葉すらも知らない方が大半にも思えるのですが・・・どうでしょう。

「モビリティ」とは何か、みなさんはご存知でしょうか?

モビリティ = モバイル時代のワークスタイル

モビリティという響きだけ聞くと、なんとなくモバイル・ファーストという言葉と同じ意味のように感じてしまいます。しかし、マイクロソフト、オラクル、IBMやSAP、どの製品ベンダも、これを明確に違うものとして扱っています。

「モバイル・ファースト」とは、アプリケーションをどのように実装するのかという、開発の指針を表す言葉です。デスクトップ版よりも先にモバイル版を出そうとか、同時に作ってしまおうとか、そういう開発の戦略を意味します。

対して「モビリティ」とは、モバイルを活用した場合の仕事のやり方、ワークスタイルを表す言葉です。デスクトップ型のみの世界に、持ち運べるようなノートPC、これに加えてモバイルやタブレットのような新しいコンピューターが入ってきたことで、仕事のやりかたを変えることができるようになった。見方によっては、変えざる得ないという状況になった。だからその実現方法に、「モビリティ」という名前を与えたわけです。

エンタープライズ・モビリティとは?

「ホワイトカラーの働き方」を例に挙げ、モビリティとは何かについて考えてみましょう。一般的には「エンタープライズ・モビリティ」と呼ばれているものです。

ホワイトカラーはこれまで、デスクトップ型のコンピューターを使って仕事をしていたので、デスクトップ型コンピューターでしかできない範囲の中で仕事を動かしてきました。キーボードにマウス、ディスプレイがついているコンピューターにできることの中でだけで、コンピューターと接触してきたわけですね。そこに、モバイルが加わり、タブレットが加わり、ウェアラブルデバイスが加わり、これらを活用した時にできることは今までより広がったので、仕事のやりかたに対する可能性も大きく広がりました。

例えば、ホワイトカラーが仕事をする時、メールやチケット管理ツールにスケジューラーなど、何かしらの作業を始めるきっかけに色んなツールを活用します。デスクトップ型のコンピューターを利用している場合、作業者は常にディスプレイの前に座り、作業者側から能動的に情報をチェックし、作業を進めていることが多いはずです。その作業があまりにも多い場合は、秘書を雇う人もいるでしょう。

対してモバイルは、コンピューター側から能動的にイベントの発生を作業者に伝え、そこから作業を進めていくというスタイルに向いているコンピューターです。作業者側から大量の情報をチェックしにいったり、ましてや表計算ソフトに大量の情報を入力するような作業には向いていません。

具体的には、電話がかかってきたことを知るために、ディスプレイを眺めて待機するようなような使い方を作業者はしません。電話は鳴ってから取るものです。電話が鳴っているということを、コンピューター側から作業者に対して、別の作業から割り込むような形で伝え、電話するという作業がスタートするというワークフローが自然です。このように、受動的な仕事の動かし方をしていけることが、モビリティの特徴の一つと言えるでしょう。モバイルは言わば、ホワイトカラーの秘書としての役割を担ってくれるわけです。

モビリティは何が良いのか?

モバイルの特性を活かした仕事のやり方をすれば、生産性も上がるし、ミスだって減るでしょ?というのが、多くの場合モビリティのメリットとして挙げられます。向いていることを向いているツールとコンピューターにさせることで、ユーザ体験を上げるのがモビリティというわけです。

実際に、メールを能動的にチェックさせて作業を発生させるより、モバイルのイベントとして通知させたほうが見落としのリスクが減る、なんていう統計結果も出ていたりします。私も、目的が雑多に並んでいるメールが毎日何百通も飛んでくると、一通一通を真面目に見ている暇がなく、見落とすことが結構あったりします。

例えば、私は以前、マイクロソフトの大西さんからのメールを広告MLと勘違いし、スルーしてしまったことがあります。「Microsoft」というキーワードがタイトルに出てきたので、私の脳が勝手にフィルターしてしまったのです。しかし、大西さんのFacebookメッセンジャー越しでの「返事はよして!」コールには、すぐに気がつくことができました。私は、目的がはっきりしているFacebookメッセンジャーのイベントの見落としは滅多にしませんし、スルーする時も割と意識的にできていたりするので「やっちまった!」という経験はあまりありません。

f:id:furoshiki0223:20140809220925p:plain

モビリティな人たちからすると「メールの見落としが起きている時点で、もうそれはもうおかしいでしょ。目的に合ったツールやコンピューターに手段を分散していかないと仕事やりにくいでしょ。メールというツールに、不向きなことをやらせ過ぎているから、こういうことになったんじゃないかな。」と。

それを聞いて私も「ああなるほど。そういう考えでみると、私は結構モビリティができそうな気がする。Facebookには即反応していたし!そもそも、日本人は割と早い時期からモバイルを使ってきたのだから、モビリティのワークスタイルに馴染める人は結構多いんじゃないのか?」なんてことを思ったわけです。

日本の場合、私用の携帯を会社の仕事用途で利用するBYODっぽい使い方を、実は多くの人が既にやってるんじゃないでしょうか。出張の時なんかは、朝は携帯で会社に電話して、ちょっとした報告は簡単なメモとしてメールで送るなんてことを、日常的に行なっている人も少なくないはずです。こういうツールの使い分けを、さらにより高度に行えるようにしようという取り組みにモビリティがあったりします。

モビリティで改善するセキュリティリスクとモラル

BYODっぽい使い方を無意識にうちにやっているのではないか?というお話をしましたけど、よくよく考えてみてください。実はそれって、大きなリスクを孕んではいないでしょうか。仕事用途だと、メールの中に大切なお客様情報が気づかぬうちに入ってしまうリスクがあったりします。これを企業側の管理対象に入れないというのは、それはそれで危険なはずです。

BYODを考える上であまり見られないのが、紙のノートの存在です。恐らく多くの人が、自腹なり備品なりでノートを使っているのでしょうが、これは見方によっては紙媒体による非管理の端末と見なせます。客先でノートを広げて色々情報を書き込んでいますけど、本当にそのノート、危険な情報が無いと言い切れるでしょうか。私は電車でカバンを拾ったことがあるのですが、駅員に渡した時に聞いてみたんです。彼らいわく「カバンの中をチェックしてて、数冊の紙のノートやスケジュール帳が出てきて、持ち主の真正性情報を探そうとペラペラめくったり・・・(おお、それ以上言わないで下さい!!)」とこんな感じで。

冒頭のオラクルのモバイルイベントでも、「この会場には、暗号化されていない、リモート削除(リモートワイプ)の機能もついていない、何十、何百冊の情報が並んでいる!」とは言わず、あくまで「モビリティに挑戦が求められている」という言い方をしているのは、ある種の米国的優しさなのかもしれません。ただ、今でもモビリティな人から「日本は紙が多い」「紙は本当にもう危険だからやめようよ」が口癖になっていて、企業のペーパーレス化はどこもうまく進んでいないようです。

天災なんかで電車が動かない時も、電車の中で慌てて電話している人をよく見かけます。こういうモラル的に良くない行動を社員にさせてしまうことも、モビリティがうまくマネジメントできていない企業の良くない一面と言えるでしょう。(お客様が相手だとどうしようもないかもしれませんが・・・)

モバイル依存な業務が現場レベルでは根付きやすい状況であるにも関わらず「企業でモバイル活用なんて認めない!」と強制力を働かせてリスクから目を背けてしまうよりも、仕事のやり方にあったセキュアなツールとコンピューターの提供、リテラシーを上げるための教育、セキュリティ面でのルール化を進めたほうが安全だろうという見方があります。こうした、IT運用の健全性をコントロールしやすいというのも、モビリティのメリットの一つだったりします。

【連載:モビリティとは何か?】
  1. モビリティとは何か?企業にモバイルが求められる理由
  2. モビリティは今、どのように進化しているのか?
  3. モバイルファーストじゃダメな理由、モビリティファーストに求められること(8/14)
  4. モビリティの価値を大きく変える、5つのキーワード(8/15)

「2014年4月」はIEの歴史を動かした。そこから何が読み取れるのか?

マイクロソフトが提供しているブラウザ「Internet Explorer」の脆弱性問題がTVで大きく取り上げられ、Webの利用者へ混乱をもたらした事件から、約3ヶ月が経過しました。また、IEの重要な機能追加の発表があったマイクロソフト主催カンファレンス「Build 2014」からも3ヶ月です。長きに渡って人々から愛されたIE6のEOLからも3ヶ月。今思えば、2014年の4月は、IEの歴史を大きく左右する重大な事件の連続でした。

割と冷静さを取り戻してきたこのタイミングで、もう一度一連の事件の振り返るとともに、マイクロソフトがとった対応から、IEが一体どういうポリシーでこれからのWebを維持していくのか、その考えを読み取ってみましょう。

脆弱性問題を冷静にみつめてみると?

脆弱性の問題は、マイクロソフトに限らず多くの製品ベンダがよく起こしている問題です。ソフトウェアのバグや脆弱性が存在しないということは証明できないといわれ、これを「悪魔の証明」と呼び、防ぎようのないこととして扱われます。技術的な違いこそありますが、IEは今回の起こした脆弱性問題(#222929)の前にも、似たようなリスクを持つ脆弱性問題を何度か抱えたことがあり、近いものだと2012年(#480095)に起こしています。割とありきたりな事象です。絶対に起こさないを目指すと製品を世の中に出せなくなるので、リスクコントロールで調整していくものと言えるでしょう。

ところが、Windows XPのサポート終了直後だったこと、政治・経済が比較的静かなゴールデンウィーク中に起きたこと、あるいは、IE自体の知名度が高かったことが要因なのか、そのありきたりな事象が、TVで取り上げられる「事件」へと発展しました。彼らは、注目を集めることがビジネスであり、正しい情報を伝えることは必ずしも彼らにとっての利益とはなりえません。モラルの話はさておき、これはもうビジネスなので仕方がないでしょう。セキュリティ問題と同様、いつ起きてもおかしくないリスク、いわば事故のようなものです。

そして残念なことに、情報の本質が元のソースとはやや異なるものに歪められたその報道は、技術に詳しくない人の注目を集めるには十分だったようです。

元の情報:提示する対策ができないなら、Internet Explorerを使うべきではない
↓
TVでの報道:Internet Explorerを使ってはいけない

「使ってはいけない」これは確かに、強烈なインパクトですね。

マイクロソフトは、世の中的に騒がれた要因を少しでも取り除こうと、Windows Vistaや7、8.1だけでなく、既にサポートが終了してまったく面倒をみる必要のないWindows XPへも、無償でセキュリティパッチを提供しました。普通の製品ではあまり考えられない、異例の対応と言えます。例えるなら、貸しビルのオーナーが、耐用年数が過ぎたビルに家賃も払わずに住んでいる人のため、わざわざペンキを塗り替えてあげるようなものです。

あれから3ヶ月、IEはどうなったのか?

StatCounter Global Statsの統計情報を確認すると、4月の脆弱性問題は、国内でのIEのシェアが一時的にChromeに抜かれるという歴史的な事件に発展したようです。しかし今は、ペンキの効果があったのか、なんとか立て直してトップの座を奪い返しています。

f:id:furoshiki0223:20140720210031p:plain

一方で、グローバルな視点では、Chromeの影響力が高く、IE、Firefox、共に苦戦しているようです。短期的な問題は去ったかのように見えますが、長期的にはまだまだ難ありという状況にみえます。

f:id:furoshiki0223:20140720210043p:plain

世界的にはモバイル/タブレットがシェアを高めているため、高い影響力を持つAndroid版ChromeやiOS版Safariと、どう勝負していくかも求められています。コンシュマライゼーション(消費者向けの製品が企業で活用されるエンタープライズの一種の心理)が進む中、エンタープライズIT側への影響も無視できない重要な動向です。

f:id:furoshiki0223:20140720220711p:plain

一方で、Build 2014ではこんな動きが

2014年4月サンフランシスコにて、マイクロソフトはグローバル・カンファレンス「Build 2014」を開催しました。この中で、Josh Holmes氏が行なった講演「Internet Explorer as a Web Application Platform」で、興味深い発表がされました。

ここからは、彼の講演のダイジェストをお届けします。

"IE6カウントダウンというサイトの、2014年の2月の段階でのスナップショットを見てもらいたい。

世界的には、4.4%のユーザが未だにIE6を使っているという状況だ。しかし、アメリカでは0.2%であり、そこまで多くない。ほとんどが政府と企業だ。ノルウェイはなんと0.0%と小さく、もはや何の影響力も持たない。しかし、中国は今でも22.2%もあるため、中国を市場ターゲットとする場合は、IE6対応が求められるだろう。

f:id:furoshiki0223:20140720232143p:plain

一般的に、コンシューマー向けでは、1つのサイトに何百もの開発者が関わる。しかしエンタープライズの場合は、一般的に、千を超えるようなアプリに対して、少しのプールされた開発者が関わるなんてことがある。この会場にも、辛いと感じている人はいるよね?より良いパフォーマンス、より良いセキュリティ、より良い可用性を与えたいが、古いIT資産が足を引っ張る。

f:id:furoshiki0223:20140720232158p:plain

そこでエンタープライズモード(EMIE)だ。この機能を使うと、今あるIT投資資産を、タイムカプセルのように包み込み維持できる。そして新しいIT投資資産については、IEの持つ最新の機能を使うことができる。エンタープライズモードは、企業標準ブラウザのアップグレードの機会を与えるんだ。"

f:id:furoshiki0223:20140720232220p:plain

この2つのことから、何が読み取れるのか?

エンタープライズ・モードの登場で、なんだほら、古いIE向けシステム、まだまだ延命できるじゃないか!なんてほっとしたのが世間的な評価でしょう。ただ、私としてはそこに注目して欲しくありません。よくよく考えてください、IE6の次はIE8?いえいえ違います、IE7もまだ延長サポート期間であり、決して無視はできません。素直に考えるなら、IE7の保護を考えるべきなのに、彼らは明確に「IE8を暫定的に守る」と言っています。

つまりどういうことか?表向きはN+1サポートとか言っていた彼らですが、Josh Holmes氏の講演では明確に「みんながIE8を使っているみたいだから、IE8向けシステム守ろう」と主張しています。脆弱性騒動もそうだったはずです。「世の中が気にしているから、例外的にWindows XPも守ります」という姿勢でした。実はマイクロソフトという会社は、昔から世の中の評判というのを非常に気にする体質の企業で、そこに過剰なほどにエネルギーを注ぎます。世間の評価を気にするのは、企業として普通のアクションなわけですが、このあたり興味深い動きに思えます。

彼らはサポート期間云々よりも、まずIEのユーザがどういう状況に陥っているのか、そこを大切にするのです。エンタープライズのマーケットにIE8が高いシェアを獲得している間は、彼らはきっとIE8特化のレガシーな資産を丁重にあつかってくれることでしょう。しかしご存知の通り、グローバルな視点では既にIEの影響力は日に日に弱くなっていて、そのことがどう作用するか油断できないという状況であることも認識すべきでしょう。

逆の見方をすれば、良い所もあります。WebRTCとかWebComponentsとか、マイクロソフトのエコシステム的に手を出しにくいWeb技術はいっぱいあるのですが、案外世の中が「欲しい欲しい」と強く主張すれば、なんとかなるのかもしれません。Windows 7世代(主に2020年まで)は、IEに限らず色んな技術が揉まれて不安定なので、世の中の動向を慎重に見たり、自分たちのビジネスにとってどんな価値が求められるのかを強く主張することは、割とインパクトがあるのかもしれませんね。

余談ですが、「マイクロソフトよ、企業向けだとこれを実装してくれると凄く助かるんだが・・・」と伝える場所は、あるにはあるので試してみてはどうでしょう。Web標準とかでなく、単純に「あれ欲しい!すごく重要!」みたいな直感的なノリでも、「俺たちチャレンジャー企業に戻ってしまった!まじ◯oogleさんに負けてられんほど、Webを変えていくよ!!」的な感じで語る今のマイクロソフトなら、割と真摯に聞きそうな気がしています。(日本語で書いたら、誰かが気を使って英語に訳してくれるはず。MS日本チームさんが!)

Google Chromeの開発者が語るこれからのWebに必要なこと、ちょっとした懸念点とか

ーーーー HTML5はネタが出尽くした。あとは、IE8やAndroid2.X標準ブラウザのような、レガシーブラウザがいなくなればいいだけではないか?

私は最近、そんな言葉を耳にすることがあるのです。しかし、ブラウザ開発者たちは未だに、そんなことを微塵も感じさせないほど働いています。まだまだ進化の速度を、落とすわけにはいかないようです。2014年06月14日に開催された「HTML5 Night」にて、Google Chromeの開発者である及川卓也氏の口から、これからのChrome開発について語られました。

f:id:furoshiki0223:20140720004159p:plain

本記事では、及川氏の講演のダイジェストをお届けします。

今のChromeには何が不足しているのか?

Chromeは2013年の4月に大事な出来事がありました。Appleと一緒に開発していた、「WebKit」をフォークしました。それが、Chroniumと同様なオープンソースのレンダリングエンジンである、「Blink」です。Blinkは、HTML5などのWebプラットフォーム機能を実現しています。

Blinkプロジェクトでは、2014年冒頭に、今年は何をしようかということを話し合いました。Blinkはオープンソースのプロジェクトなので、話し合いは全て「blink-dev」という、メーリングリストで行われます。これがメールスレッドになるのですが、書かれていることはだいたいこんな感じです。

f:id:furoshiki0223:20140720035837p:plain

ざっくり言いますと、「モバイル」が大事ということです。

ご存知の通り、モバイルの方がデスクトップより売れているし使われています。そういう状況ですが、モバイルのアプリを開発する立場からすると、残念ですが、Webよりもネイティブアプリの方が良いと言われています。

そこでとある機関が、モバイル開発者になぜHTML5を使わないのかという、アンケートをとりました。こちらがその結果です。

f:id:furoshiki0223:20140720035855p:plain

不満は主に、パフォーマンスが悪い、APIが足りない、ツールが整っていない、ということです。

最大の問題であるパフォーマンス、「速いことは正義」です。これについては色々とやってはいますが、HTML5はあまり関係ないので、Blink Contributorsが集まった時の資料「Blink On 2: Mobile@60 FPS」を御覧ください。


Blinkは「API不足」をどう改善しているのか?

ハードウェアアクセスが大切ですし、痒い所に手が届くオフライン制御も大切です。Blinkでもいま取り組んでいます。ServiceWorker、WebMIDI、WebAudio。全ては紹介しきれないので、ServiceWorkerについて触りだけお話します。

ServiceWorkerで何が出来るのかというと、より高度なオフライン機能、ネイティブアプリに追いつく、AppCacheからの学びを活かすような設計となっています。オフラインと言っても、完全にオフラインという場合だけではなく、ネットワークが不安定であったり、しょっちゅう切れたりなど、今はそのような異なる状況に対応したWebアプリを書くのがとても難しかったりします。

f:id:furoshiki0223:20140720040015p:plain

仕組みとしては、WebサイトからインストールされたJavaScriptが、独立したWorkerスレッドで動作し、Webサイトからのイベントハンドリングを実現する、というものです。つまり、頭の良い、In-browserなHTTPプロキシです。これが、インターネット上のページとキャッシュの、両方を制御できるということです。

詳しくは、こちらをご確認下さい。


Blinkは「ツールの不足」をどう改善しているのか?

HTML5は、様々な要素の統合が難しい、最新のUI/UXが作りにくい、成熟したフレームワークが不足しているというのが、アンケートの結果から得られました。これらについても、Blinkでいままさに取り組んでいます。WebComponents、Polymer、WebAnimation。こちらも全ては紹介できないので、WebComponentsとPolymerについて。

WebComponentsとPolymerは、Webにコンポーネント技術を取り込むためのものです。例えば、Google Chart APIの場合、グラフを表示するための情報を、JavaScript上に書き込まなくてはいけませんでした。

f:id:furoshiki0223:20140720040044p:plainf:id:furoshiki0223:20140720040103p:plain

WebComponentsを採用すると、グラフを意味するgoogle-chart要素の属性に、グラフの表示に必要な情報書き込むだけです。

f:id:furoshiki0223:20140720040119p:plain

Googleのサービスを利用するためのWebComponentsが、GitHub上にもたくさん用意されています。

https://github.com/googlewebcomponents
f:id:furoshiki0223:20140720041302p:plain

以上です。応援宜しくお願いします、ご清聴ありがとうございました。

Googleが力を入れているのは?

この講演はGoogle I/O 2014が開催される前に行なわれたものですが、一貫して「Service Worker」「WebComponents」を推しているようですね。オフラインの機能でネイティブの上を行こうとService Workerに取り組みつつ、ツールの不足をWebComponentsを活用することでGoogleのサービスを提供していくことで解決しようという方向性のようです。先日の「第49回HTML5とか勉強会」でも、一貫して同じことに触れていました。

どちらも彼らのビジネスと上手く協調できているし、実に理にかなっています。ただ、Microsoftさん的には納得いかないところもあり、エコシステム的にまだまだ問題もあるようです。このあたり、Microsoftさんは結構後手に回ってしまうので「なんだよまたIEが遅れているのかよ」「本当にIEだけ機能が全然実装されねぇよな」という空気感が出てしまうのが目に浮かびます。ただ、最近IEが実装できない機能って、「技術的な理由でできない」というより「政治的な理由でできない」が中心なんですよね。

開発者たる我々からすれば、そんなことは本当にどうでもいいことなので、Microsoftさんには社内の他の製品との利害関係を整理してしがらみを捨てて、一緒にWeb標準を育てていけるよう頑張って欲しいところです。彼らは最近自分たちのことを「俺たちはもうトップの企業じゃない。そこらのチャレンジャー企業と何にも変わらなくなった」と言ってて、社内的にもそんな空気感がただよい始めているみたいなので、変な形で既存利益に拘るようなことはしないだろう、と信じています。

ただ、一点。Google的にパフォーマンスは、Web標準(WebPerf-WG)の「◯◯ Timing」系APIで解決しようという意思はあまり感じられません。あくまで、彼らの提供している独自のサービス「PageSpeed Insights」を推していたりします。ただ、このツール、彼ら自身もまだまだ機能が十分に足りていないという認識を持っているようです。Google I/O 2014でPaul Lewis氏のセッションでも、途中からこのツール使わず、他で提供しているサービスを利用してパフォーマンス計測の一連の流れをデモしていました。。「検索に0.02秒かかりました」とか出してきて「聞いてねー(笑)」と思うほど、パフォーマンスが良かったアピールしてくるGoogleさんの、らしくない意外な一面ですね。

アプリケーションプラットフォームと呼ぶには、まだまだ色んな問題が残っているんですね、、、Webって。これからが楽しみです。

HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」はどのように課題を克服し、進化するのか?

本記事は「HTML5ハイブリッドアプリ開発を支えるOSS『Cordova』シリーズ」の続編です。前回に引き続き、2014年6月10日に開催された「第1回Apache Cordovaスーパー勉強会」にて、アシアル株式会社の田中正裕氏が行なった講演のダイジェストをお届けします。

まだまだ進化を止めないApache Cordova

ハイブリッドアプリも日々進化しています。3年前はPhoneGapもようやく1.0という状況でしたが、それも今ではCordova3.5ということで、ここに来るまで相当な進化があったんです。

f:id:furoshiki0223:20140719180113p:plain

3年前に、僕が初めてPhoneGapを触った時、iOSも4.2で、CSSもまったく充実していませんでした。Androidも当時は2.2だったのですが、あれからAndroid自体のパフォーマンスが改善されてきました。

Cordovaもプロジェクトが大きくなって、やれることも増えてきました。ここで、最近どういう動向があったのかをご紹介します。

ハイブリッドアプリの新たな姿「WebView内包アプリ」とその進化

f:id:furoshiki0223:20140719180132p:plain

従来のハイブリッド開発は、OS付属のWebViewを活用するというものでした。最近はそうではなく、自前のWebViewを内包して開発しようというアイデアがあります。その内包するためのWebViewとして、僕がいま注目しているいくつかのプロジェクトがあります。これらは、今のハイブリッドアプリの制約を改善する可能性を秘めていると考えています。

ChromeのエンジンであるBlinkは、パフォーマンスが高くてキビキビ動きます。これをCordovaへ取り込もうということで、IntelがCrosswalkというプロジェクトを進めています。そしてその取り組みが、今、最もポピュラーになってきています。ChromeのOSSプロジェクトであるChromiumをフォークすることで、彼ら独自のブラウザエンジンとして、Cordovaと互換性のあるものを作っています。Intelらしく、Tizenに対応しているのが強みです。OSSなので、サイトに行けばダウンロードして使うことができます。

ゲームという分野だと、LudeiというCocoonJSを開発しているアメリカのゲーム会社があります。彼らも同じ考えを持っており、WebView+というAndroid用のブラウザエンジンを作っています。Crosswalkと違うところは、WebGLという3DをレンダリングするためのAPIを有効にできるという点です。HTML5だと、どうしても苦手と言われているような3Dを改善しています。彼らのデモを見てみると、グリグリと動いていて面白いですよ。こちらはクローズドソースで、彼らの公開しているサーバ上でビルドすることで、使うことができます。

もうひとつはAmazonです。彼らもHTML5に対する動きはすごく活発で、Amazon Silkという、Blinkベースのレンダリングエンジンを開発しています。これは、Kindle Fireという彼らの製品の中に組み込まれています。使い方は、CrosswalkやWebView+とも違っています。Cordovaで作ったアプリをAmazonで販売する場合に申請して、ソースコードをアップロードすると、Amazon Silkでビルドされリリースされるという仕組みになります。

「WebView内包アプリ」にはどのようなメリットがあるか?

f:id:furoshiki0223:20140719180145p:plain

彼らの取り組みには、色んな利点があります。

HTML5を使えば一つの知識でいけるなんて言われますけど、環境によっては対応しているCSSのプロパティが全然違っていたり、JavaScriptの構文にもAndroidのバージョンによって差があったりします。そういうものを、ブラウザエンジンを内包して一つのアプリとして提供できるようになれば、フラグメントという問題もAndroidにおいては無くなります。

iOSについては、アップグレードが浸透しており、iOS7が今の時点でもう既に90%以上の方に使われています。そのアダプションを考えると、今のウィークなポイントは、Androidの2.3とか4.0が未だに多くのユーザに使われているというところです。正直、Chromeのブラウザエンジンを内包するという方式は、Androidの4.0以上でないと対応できないためネックになっています。ただ、Androidの2系が無視できるような状況になると、4.0以上がシェアを占めるため、一気にハイブリッドアプリを作る環境が改善されると考えています。

もう一つの利点としては、Chromeのエンジンを内包できることで、Chrome Dev Toolsが利用できるという点です。従来のCordovaだと、デバッグにはやや特殊な方法が必要だったりします。しかしChromeのエンジン、もしくはそれに類するものを内包できると、Chrome Dev Toolsが利用できるので、AndroidをUSBで繋いで、Cordovaのアプリをデバッグできるようになります。この方式が普及すると、ネイティブにあったような端末の依存性問題も、ディスプレイのサイズやリゾリューション程度になるので、モバイルアプリ開発はかなり改善されるのではないかと期待しています。

また、Chromeは昔とくらべてかなりパフォーマンスがよくなったので、このエンジンを内包することで、パフォーマンスの向上がかなり期待できます。また、Chromeのエンジンは最新のCSSに対応していたりとか、高速なJavaScriptエンジンが使えるというのもメリットとして大きいでしょう。

デメリットとしては、先ほどもご説明した通り、Android 2.Xに対応していないというのがあります。また、ファイルサイズが大きいという点も大きいでしょう。8MBから十数MBぐらい増えてしまいますので、これでは起動時間が長くなってしまいます。しかし、みなさんがもしChromeアプリを使っていて、それでストレスを感じないというのであれば、やっていることはあまり変わらないので、大丈夫ということになります。これはそんなに問題ではないのかもしれません。

f:id:furoshiki0223:20140719180237p:plain

iOS8で、新しいWebViewがでます。これまで、iOSはUI WebViewというブラウザエンジンを提供しており、AppleはSafari以外それを使うことしか許していませんでした。そしてそのWebViewが、iOS8からはWKWebViewに変わります。名前から察しがつくかもしれませんが、WKはWebKitの略です。

私たちが評価してて、このWKWebViewはすごく良いと感じています。例えば、WebGLが標準で使えるようになっていたり、あとIndexDBというクライアント上で扱えるデータベースの機能が、なぜかWKWebViewだけ使えるようになっていたりします。一番面白いのが、今までSafariにしか許してくれなかったJITの実行エンジンを、Appleが開放してくれたことです。sunspiderという有名なベンチマークで動かすと、UI WebViewだとだいたい4秒ぐらいかかるのですけど、WKWebViewだと1秒切るんです。iOS側もハイブリッド開発がどんどん改善が進んでいます。

「JavaScript UIフレームワーク」の進化

次に、ユーザインタフェースを作るためのフレームワークについてです。

f:id:furoshiki0223:20140719180305p:plain

jQuery Mobile」なんかは使われている方は多いのでしょうけど、アメリカだともう使われていなかったりします。最近は、新しいUIフレームワークがかなり台頭しています。

筆頭しているのが、Driftyという会社が作っているAngularJSベースのフレームワーク「Ionic Framework」です。結構スムーズに動くんです。弊社でもやっている「Onsen UI」も同じコンセプトでして、アメリカでもかなりウケがいいです。AngularJSベースのWebComponents、ディレクティブというんですが、そういうものを使ってタグだけで画面のコンポーネントを作って、ビジネスロジックは全部AngularJSのコントローラーで作るようになっています。

3つめが異色ですけど、「Famo.us」というフレームワークがあります。彼らは少しアプローチが違っていて、CSSのGPUが使えるマトリクスとかを駆使して、できるだけ高速にレンダリングできるようにするという、そいういうフレームワークです。

jQuery MobileはjQueryブランドの安心感があるのですけど、PhoneGap1.0が出るよりも前という、CSSも全然無いような時代に作られたフレームワークです。スクリーンのトランジションの遅さとか、ウィジェットのレスポンスなんかが、やっぱり前世代的な感じなんですね。なので、こういったものも、一度評価に入れてみてはいかがでしょうか。

f:id:furoshiki0223:20140719183948p:plainf:id:furoshiki0223:20140719184005p:plain

Cordovaのアーキテクチャの進化

デバイスAPI/ネイティブの機能。3つめのトレンドとして、Cordova Plugin Registryです。

f:id:furoshiki0223:20140719180333p:plain

実は、Cordova 3.4から、かなり大きな仕様変更がありました。Cordovaにはコアの部分と、カメラとか電話帳とかネイティブの機能にアクセスするモジュールの部分に分かれています。従来そのモジュールの部分は、Cordovaの中に含まれてました。それが3.4から、Plugin Registryに分離されました。

これには2つの狙いがあります。一つは、プラグインに分離させてしまうことで、プラグインだけで独自に進化することを促せるということ。もうひとつは、プロジェクトを進めていくと、いらないObjective-Cなどのコードが増えていくので、本当に必要なものだけを取り込めるようにすることです。

結構色んなプラグインが登録されています。

f:id:furoshiki0223:20140719183929p:plain

最後に、我々はCordovaを盛り上げようと思っているのです。しかし、我々だけではやはり弱い所がありますので、是非、一緒に盛り上げていきましょう!今日はどうも、ありがとうございました。

本連載の最後に ーーーー

3回の連載にわけてみましたが、いかがでしたでしょうか。Cordovaを愛し知り尽くした彼は、Cordovaの開発を楽にできるようにと、「Monaca」というツールを開発しています。これを使えば、彼は来年以降もっといいメシが食べれて、Cordovaにコミットするモチベーションが上って、みんながハッピーになれるわけですね!

本記事のソース「Apache Cordovaスーパー勉強会」は割と評判が良かったため、第二回を開催する予定です。よさ気なネタがありましたら、TwitterなどのSNSで、気軽に私に話しかけて下さい。お待ちしております。

(※写真がボケてしまいましたが・・・、左上が田中正裕氏、左下が筆者)
f:id:furoshiki0223:20140719184253j:plain

HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」のこれまでの進化、そして課題とは?

本記事は「HTML5ハイブリッドアプリ開発を支えるOSS『Cordova』シリーズ」の2本目です。前回に引き続き、2014年6月10日に開催された「第1回Apache Cordovaスーパー勉強会」にて、アシアル株式会社の田中正裕氏が行なった講演のダイジェストをお届けします。

Cordova派生の製品がいくつも登場、どのように差別化が進められてきたのか?

元々は、PhoneGapという製品を中心に色んなエコシステムがあったのですが、Cordovaというオープンソースに変わったことで、そこから派生して色んなプロジェクトが各社によって作られています。

f:id:furoshiki0223:20140719035336p:plain

例えば、IBMのWorklight Projectも、Cordovaから派生したディストリビューションです。GoogleのChrome AppsというPC上でアプリを動かすプラットフォームがあるのですが、それのモバイル版「Google Chrome Apps Mobile」もCordovaがベースです。Chrome Appsで作ったアプリはCordovaで動かせるんですけど、そのままじゃ動きません。Chrome Apps用のAPIというのがありまして、例えば、GoogleにログインするためのAPIとか、WebSocketサーバになるような機能とか、そういう拡張をGoogleはCordovaプラグインとして作っています。

最近ではMicrosoftのVisual Studioが、Cordovaに対応しました。Visual Studioで、HTML5を使った、iOSアプリが作れるのです。凄い時代ですね。あと、最近日本でも火がつきつつあるIonicフレームワーク、HTML5を使ってヌルヌルに動くネイティブアプリを作るためのこういうツールも、内部ではビルドエンジンとしてCordovaが使われています。弊社が作っているMonacaとかOnsen UIみたいなツールもあるんですけれど、これもCordovaに準拠しています。

これらのツール/フレームワークは、何が違って何が同じかと言われると、最終的に作られるアプリは全て同じで、何の違いもありません。ただ、各社独自のアドインを開発し入れているという点で、大きく異なります。エンタープライズ向けの製品だと、エンタープライズニーズにあった各種プラグインを作っていたり、Google Chrome Appsだと、先ほど説明したようなプラグインを作っていたりします。弊社のMonacaでも、ネイティブの機能を扱えるようなプラグインを提供しています。

モバイルWebとハイブリッドアプリの違いは何か?

HTML5を解釈するブラウザエンジンについて、モバイルブラウザとCordovaとでは微妙に異なります。

f:id:furoshiki0223:20140719035714p:plain

モバイルブラウザでURLを打ち込んで表示するWebアプリは、iOSだと、Safariと、Safari以外に分かれます。例えば、Safariと、iOS上で動くChromeは、異なるブラウザエンジンで動いていたりします。Appleはモバイルで扱うブラウザエンジンに、特殊なフラグをつけているのです。iOSでは、Cordovaを含むサードパーティベンダの場合、内部的にはWebViewを使ってWebアプリを表示します。SafariはJITなどの機能によって、JavaScriptを高速化させるような仕組み(Nitro)が入っているのですが、iOSのWebViewはそれが無効化されています。

Androidも、微妙にややこしいです。AndroidにもiOSのような標準ブラウザが入っているのですが、Android版のFirefoxやChromeでは、内部的でそれを使っていません。では、iOSと同じようにWebViewを使っているのかといえばそうでもなく、FirefoxはFirefoxの独自のエンジン、ChromeはChromeの独自のエンジンで動いていたりします。そしてCordovaは、FirefoxやChromeが使っていない、Android標準のWebViewを使っています。WebViewはAndroidのバージョンに依存していて、例えば、Androidの4.1、4.2、4.3と、バージョンごとに対応している機能に違いが表れます。対してChromeは、Androidのバージョンに関係なく、Chromeのバージョンに機能の違いがでます。

こうした背景から、Cordovaの対応している機能は、Cordovaのバージョンに関係なく、動作させているOSのバージョン、WebViewの機能に依存します。Cordovaだから対応機能が少ないとか、そういうことはありません。ただ、Cordovaがモバイルブラウザと大きく違うところがあります。それは、JavaScript APIが拡張できること、Same-origin Policyのルールが異なることです。

ブラウザは、JavaScript APIの拡張ができません。しかしCordovaは、自分たちで好きな機能を持ったJavaScript APIのプラグインを作ることで、ネイティブの機能を利用することができます。Same-origin Policy、セキュリティについても、ブラウザの場合はブラウザのルール、HTTPヘッダで指定されたルールが適用されます。対してCordovaは、基本的に自由でどこにでもアクセスし放題です。制限を加えたい場合、config.xmlにて、どの外部URLを許可するかを、ホワイトリスト形式で設定できるようになっています。

結論を言えば、APIレベルではモバイルWebとハイブリッドアプリは同じです。よって「Webアプリ≒ハイブリッドアプリ」ということになります。ではなぜ「ハイブリッドアプリは違う!」と言われているのか。それは「HTML5アプリとネイティブアプリの違い」ここに全てが始終します。

これまで、ハイブリッドアプリが抱えてきた課題は何か?

HTML5ハイブリッドアプリは、これまで説明してきました通り、ブラウザエンジンの上で動くことになります。一方で、ネイティブアプリにはそんなものはなく、OSが直接アプリを動かします。このため、アプリの作りから動作の仕組みまで、全く違っていたりします。

f:id:furoshiki0223:20140719035953p:plain

HTML5アプリを、ネイティブアプリの感覚で作ると問題になります。世界が違うのです。ユーザインタフェース、これが一番よく言われます。HTML5でどうやってネイティブアプリのようなスムーズなUIを作るのか、これが一番私が受けることの多い質問です。そもそも、どうつくればいいのかわからない、これが一番多い悩みではないかと思います。

そして2つ目。やっていてジワジワと感じてくるのが、実行するパフォーマンスが違うという点です。例えばネイティブアプリの開発をした人なら、ビューなんかを10個ぐらい重ねてとか、トランジションでスクリーンを動かしてとか、アクティビティを作ってとか、ネイティブの要領で、頭のなかでやることがイメージできて実装ができるでしょう。しかしこれがHTML5なので、ビューもトランジションもアクティビティも無くて、そもそも世界が違うので、従来のパフォーマンス改善のノウハウが全く使えなかったりします。結果として、画面がもっさりとして、ストレスを感じるということになるのです。

3つ目が、セキュリティです。ここについては、大分改善されています。Webアプリと同じなので、JavaScriptが読めてしまうという問題ですが、難読化の技術がでてきていますね。ただそもそも、ネイティブも別に意図的に難読化をしているというわけではないので、例えばAndroidのclassなんかも、逆コンパイルすれば解読できますよね。

最後に、デバイスのAPIとか、ネイティブのAPIを呼びたいという点です。これについては、さきほども紹介しましたが、JavaScript APIを作って、その中からネイティブのAPIを呼ぶということができます。パフォーマンスも、悪くありません。ただ、AndroidなどのネイティブのAPIを、全てJavaScriptのAPIに紐づけて作るということはしないので、これが悩みに繋がったりします。ビジネスロジックには依存しない、端末に依存する処理だけを、JavaScript APIの呼び出し先でネイティブのコードとして作らなくてはいけないため、このあたりの作り方に、慣れが求められます。

>>【次回(最終回)】HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」はどのように課題を克服し、進化するのか?

HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」はなぜアツいのか?PhoneGapとの違いは何か?

ハイブリッドアプリとは何か?なぜ今、Cordovaがアツいのか?

iPhoneにAndroid、WindowsPhoneと、モバイルデバイスは混沌としており、「ネイティブアプリ」の開発には高いコストが必要とされます。一方で、ブラウザを活用した「Webアプリ」は、パフォーマンスやデバイス制御に大きな制約がつきまといます。このような、ネイティブアプリとWebアプリの互いが持つ問題点を補う手段として、「ハイブリッドアプリ」と呼ばれる開発方法が注目を集めています。

f:id:furoshiki0223:20140718220658p:plain

ハイブリッドアプリの実現手段には、OSSの開発ツール/フレームワークである「Cordova」が有名です。HTML5の活用することで、ひとつのソースコードからiOSやAndroidなどの複数のモバイルOSに対応させることができ、またネイティブアプリが持っているポテンシャルを活かしたアプリ開発ができます。その起源は、2011年にAdobeがNitobi社を買収し、同社が開発していた「PhoneGap」を、Apache Foundationへ寄贈したことから始まります。ApacheではCordovaというブランド名が与えられ、現在はGoogleなどの他社のエンジニアも一緒になって、改善が進められています。

ハイブリッドアプリが騒がれだした初期の頃は、Appcelerator社の「Titanium Mobile」が有名でした。エンジニアの間でも、ちょっとした熱気のようなものがそこにはありました。しかし、AdobeがNitobiを買収し、PhoneGapをOSS化した2011年以降、瞬く間にCordovaへと流れが移っていきました。最近では、OracleやIBM、SAPにMicrosoftと、様々な大手製品ベンダが提供するモバイル開発ツールで採用されています。事実上、エンタープライズ・モバイルのWebプラットフォーム市場では、デファクトスタンダードと呼べるほどの存在感を持っています。

「Apache Cordovaとは何か?」「Apacheへ寄贈後も、Adobe側で未だに維持し続けているPhoneGapとは何が違うのか?」そのことについて、古くからCordovaと繋がりを持つアシアル株式会社の田中正裕氏が、2014年6月10日に開催された「第1回Apache Cordovaスーパー勉強会」にて行なった講演が非常に参考になります。

f:id:furoshiki0223:20140718212755p:plain

本記事では、その講演のダイジェストをお届けします。

Cordovaはどのようにして生まれたのか?

Cordovaとは、カナダのバンクーバーに実在する、ストリートの名前です。そしてそのCordova通りには、Nitobiという会社がありまして、PhoneGapというハイブリッドアプリ製品を作っていました。

f:id:furoshiki0223:20140718213501p:plain

PhoneGapは、Adobeさんに買収されたタイミングで、Apacheに寄贈されることになりました。その際、旧Nitobiの開発チームは、そのOSSに自分たちとゆかりのある名前を付けたいという想いを持ち、Nitobi社があるストリート名「Cordova」の名前を与えました。元々AdobeにはCallbackというプロジェクトがあったのですが、1〜2ヶ月ぐらいでCordovaという名前に変わってしまいました。

僕はエンタープライズの受託開発を行なっているシステム開発会社の人間でして、ハイブリッドアプリは僕たちのようなエンタープライズのエンジニアをハッピーにしてくれると思っています。僕自身も、Nitobi社のPhoneGapの時代から付き合いがあり、OSSとなったCorodovaには積極的にコミットしています。日本の端末ベンダさんとの調整なんかも大変なのですが、自分たちが扱っているうちにバグが見つかりますので、その修正を行なったりして、一緒にCordovaを育てています。

OSSとして開発が進められているCordovaと、買収後にAdobeから提供されるようになったPhoneGapの違いは、とても些細なものです。まずは、その違いについてご紹介します。

Cordovaの「コマンド」にどんな違いがあるのか?

f:id:furoshiki0223:20140718222044p:plain

Cordovaで開発をする場合は「cordova」というコマンドを使います。対して、PhoneGapで開発をする場合は「phonegap」というコマンドを使います。どちらも「node.js」で動作するアプリケーションで、どちらも「cordova libs」というライブラリに依存しています。要するに、どちらのコマンドも、cordova libsというコマンド集を叩いているだけのラッパーです。ただ、phonegapにはそこに+αの機能を追加しています。phonegapコマンドは内部的に、cordovaコマンドを使っていると考えて良いでしょう。

f:id:furoshiki0223:20140718222059p:plain

コマンドの違いを、参考程度にまとめてみました。phonegapコマンドは、「PhoneGap Build」というAdobeさんのビルドシステムを持っており、そことのインテグレーションがされています。具体的に言うと、remoteというコマンドがついてまして、例えば、"phonegap remote build"みたいな感じでコマンドを使うと、Adobeさんの提供しているサーバへソースコードを送り、ビルドされて返ってきます。だから、ローカルにビルドできる開発環境を持っている場合は、CordovaとPhoneGap、どちらでも良かったりします。結果的に出来るアプリは、どちらを使っても同じです。

コマンドの使い方について。ハイブリッドアプリは少しややこしかったりします。ハイブリッドアプリでは、HTML5で作ったソースコードを、シェルと呼ばれる、AndroidやiOSなどの各OS専用のソースコードの中に埋め込み(=prepare)、各OSごとのツールでコンパイルして(=compile)、各OS専用のインストールイメージを作ります。このprepareとcompileをくっつけたのが、buildです。buildできたインストールイメージを、デバッグするためにエミュレーター上で動かしたり(=emulate)、デバイスにインストールして利用したり(=install)、という使い方になります。

Cordovaの「定義ファイル(設定)」にどんな違いがあるのか?

「config.xml」という、アプリケーションの定義ファイルがあります。W3CにはWidgetというスペックがあり、ハイブリッドアプリの標準仕様として定義されています。CordovaやPhongapの、独自の仕様ではありません。

f:id:furoshiki0223:20140718222901p:plain

Cordovaのconfig.xmlには、W3Cで定義しているような設定しかありません。対してPhoneGapのconfig.xmlについては、Adobeさんでネームスペースまで作って、大量の設定情報が追加されています。PhoneGapはCordovaと違って、PhoneGap Buildによるリモートでビルドを行う仕組みがあるのが原因です。リモートだと、iOSやAndroidなどの固有のソースコード(シェル)に一切手をいれることができないので、config.xml側で細かいカスタマイズの指定が行えるようになっているのです。

その他、どんな違いがあるのか?

f:id:furoshiki0223:20140718223203p:plain

CordovaコマンドとPhoneGapコマンドで、バージョンが同期していなかったりします。例えば今の時点では、Cordovaは3.5が使えるんですが、PhoneGapはまだ3.4しか使えません。理由は、PhoneGap Build側が対応していないからです。

ネイティブコードの書ける範囲も異なっていまして、PhoneGap Buildはサーバ上でビルドを実行することになるため、シェルに手を加える事ができません。CordovaだとCordova WebViewというのを使って、iOSやAndroidなどの固有のネイティブのコードを埋め込めるのですが、PhoneGapの場合は、PhoneGapプラグイン・Cordovaプラグインを通じてでないと、ネイティブのコードが埋め込めません。

今の説明は、どちらかと言えばCordovaとPhoneGap Buildです。CordovaとPhoneGapの違いというものではありません。PhoneGapの場合は、「PhoneGap Enterprise」や「PhoneGap Developer App」と呼ばれる開発ツールをAdobeさんが提供していたりするので、そういうのが使えたりします。

>>【次回】HTML5ハイブリッドアプリ開発を支えるOSS「Cordova」のこれまでの進化、そして課題とは?

企業にモバイルを適用する方法「MEAP」の全貌を掴む(4) - IBM Worklight編

企業にモバイルを適用するにはどうすればよいのか?そのための答えの一つに、MEAPが力を持ち始めています。

もちろん、MEAPが解決方法の全てというわけではありません。MEAPはベンダ色が強く出るため、毛嫌いする人も少なくないようです。マイクロソフトやアップルのようなプラットフォームを持つベンダも、そのメリットを活かした戦略をいくつか打ち出してはいるものの、やはり、ベンダに強く依存してしまうことに変わりないようです。このあたり、W3Cでも全く動きが無いというわけでもなく、技術革新の途中であるため、オープンな仕様が作りにくいというのが実情にも思えます。

MEAPと呼ばれている製品の本質的な価値はなんなのか?一体企業のどこを変えるのか?そのことを追い求めて、Sencha Space→SAP Mobile Platformとベンダを横並びにして評価してきました。しかしそれも今回で最終回です。今回味見するのは「IBM Worklight」です。

前回の紹介したMobile Platformは、買収を繰り返し色んな製品をくっつけてきたという歴史的経緯からか、モバイルの抱える課題に対する分類学的なものが比較的進んでいました。Mobile Platformというのは製品の集合体に対して与えられた呼び名みたいなもので、いわば「Microsoft Office」みたいなイメージです。UIを作るならSAP UI5を使えだとか、プラットフォームにSAP AppBuilderを使えとか、色んな製品が目的ごとに別れており、しかもこれらの独立性はやや高めだったりもします。(→Wireless Platform2の時代はそうだったので、今もそうなっているだろうという想像ですが。)

ところが、IBM Worklightは、一言で言えば「モノリシック」という印象です。IBMは2012年2月、Worklightと呼ばれるモバイルソリューションのベンダを買収し、その延長線上に今があります。複数の製品を繋げていないからか、Worklightはそれだけで一つの製品として収まっている感じになっています。SAP Mobile Platformに感じるような「製品群」という印象がありません。

f:id:furoshiki0223:20140718131058p:plain(参考:日本アイ・ビー・エム佐々木志門「IBM Worklight@html5j Enterprise Night Seminar」)

IBMは、機能を網羅的に埋め、企業向けクライアント全般の統合を進めようという方針なのか?

IBMのモバイルに関しては「網羅的に攻めている」という感触を得ています。あくまでこれは筆者の愚考としてですが、IBM Worklightは特徴の無いというのが特徴、ある意味「王道感」のようなものを感じています。世の中にはMEAP製品は星の数ほど溢れていて、実装している機能もマチマチです。A製品にはあるのにB製品には無い、またその逆もしかり。そんな状況の中、IBM Worklightは一通り一般的な機能を取り揃えている感じがします。

またIBMは、MEAPに限らず、エンタープライズモバイル市場全体で見ても、その動きには「網羅性」に対する意識が読み取れます。この2014年の夏は、各製品ベンダがエンタープライズモバイルで覇権を握ろうと特に大きな動きをみせているのですが、IBMはその動きが特に派手です。例えば・・・

日本アイ・ビー・エムは6月末に、「MaaS360」と呼ばれるエンタープライズモバイルの管理基盤の提供を開始しました。他社だとSencha Spaceも管理基盤を、クラウドサービスとしてこの秋に出そうという動きがあるようですが、IBMがまさに先手を打ったという次第です。私が思うに、今後このMaaSの機能は、コモディティ化が進み一般的になるのではないかと睨んでいます。当然ですが、日本企業が欲しがるようなオンプレミス版も提供されています。

また、IBMは7月に入り、今度はIBMとAppleでのエンタープライズモバイル分野での提携をアナウンスしました。実はここ最近Appleも、Swiftで世の中を騒がせている裏で、密かにビジネス向けアプリへの進出を始めていました。知らない人が多いというのが実情で、実際に彼らもそこまで大声でPRしてはいなかったように思えます。そんな彼らが、エンタープライズモバイルに全力で、しかも網羅的に攻めよう、どんな切り口でも行ってやろうという感じのIBMと組むのは、世の中が感じているほど不思議なものには思えません。AppleはIBMの持つエンタープライズ製品を活用し、新たな分野の開拓を狙っているようです。

そしてトドメに。彼らはMEAP製品のことを何と呼んでいるか?「エンタープライズ・アプリケーション・プラットフォーム」です。モバイルというキーワードはありません。彼らはモバイルとデスクトップの壁すらも取り払い、企業システムはモバイルファーストな、デバイスの壁の無い世界に進むものと捉えているようなのです。

「企業にモバイルが入るなんてありえない」なんてことが日本の企業の殆どの現場の意見なのかもしれません。しかし、Windows8然り、多くの製品がモバイル前提の作りに変わりつつあります。ブラウザもまた、今ではモバイルにとっての最適となることに注力しています。デスクトップに対する関心は、殆どと言ってよいほど失われています。そうなると、HTML5を含めWeb標準の担うべき役割は、今までネイティブが主役だった領域すらも巻き込み、今まで以上に重たいものになるのではないでしょうか。

f:id:furoshiki0223:20140718131112p:plain(参考:日本アイ・ビー・エム佐々木志門「IBM Worklight@html5j Enterprise Night Seminar」)

開発時は柔軟に、幅広いプラットフォームを扱える方針

もう少し、Worklightについて気になったポイントを語ってみます。MEAPとしての機能は、実際のところSAPなどが出しているのとほぼ横並びで、切り口だけが異なるといった状況です。ただ、彼らはやはりモバイルという前提自体を取り払おうとしているからなのか、WindowsのストアアプリやWebアプリを含めるなど、他のMEAPと比較して、動作対象のプラットフォームは比較的幅広く持たせてあるという印象です。

MEAP製品の多くは、HTML5を活用したハイブリッドアプリが前提のものが多かったりします。しかし、IBM WorklightやSAP Mobile Platformは、ネイティブアプリの開発もできます。ハイブリッドはどうしてもパフォーマンスに課題を抱えがちなので、こうした問題に対する逃げ道を作っているわけです。もちろん、ハイブリッドアプリだからこそできるような、ワンソースでAndroidからiOS、Windows Phoneまで、一通りのネイティブアプリが作れてしまうという大きなメリットは失われてしまいます。企業向けシステムを、わざわざネイティブで作る必要性は年々失われつつあるように思えますが。

f:id:furoshiki0223:20140718134431p:plain(参考:日本アイ・ビー・エム佐々木志門「iOS/Android/Windowsストア・アプリのハイブリッド開発における限界と可能性 」)

あと、とても地味な情報ですが

始めるだけなら、もの凄く楽です。が

f:id:furoshiki0223:20140718132417p:plain

f:id:furoshiki0223:20140718132444p:plain

EclipseのMarketplaceで「Worklight」と検索すれば出てくるし、プロジェクトもこんなんでいいのか?というほどにさくっとできてしまいます。Eclipseってもっと、面倒なことがいっぱいあるという印象しかなかったので、私的は結構目からうろこでした。

f:id:furoshiki0223:20140718132749p:plain

ビルドするだけなら特に説明を読まなくてもサクサクっといけるという印象です。気持ち悪いぐらいに、手軽な感じがします。UXの求められる時代に、説明書なんてついてくる製品がまだ存在するのか?というツッコミはさておき。Eclipseはセットアップに時間がかかるという問題があり、最近はVisual StudioやIntelliJにシェアが奪われつつあるようですが、流石は開発元のIBMだけあって、このあたりは頑張っているという印象です。

ただ、MEAP、・・・というよりHTML5によるハイブリッドアプリ開発全般の問題点なんですが、デバッグが困難という問題はまだまだ改善を待たなくてはけないようですね。今後多くの業務系開発者が関わる可能性が高い分野なので、技術進化が待ち遠しいところです。

最後に

5ヶ月にも渡り続いたMEAP特集も、これで終わりです。実は、この記事の連載中にも日本国内の色んなところでMEAP製品が出てきています。私の感覚では、30製品ぐらいゴロゴロと転がっているという印象です。というか、私の所属している会社もMEAPっぽい何かを売っていたりするので、大手ベンダだとどこでも何かしら持っているような印象があります。世はまさに、モバイル戦国時代といったところでしょう。

モバイルで企業向けシステムはこれからどう進化していくのか、そのことを探っていくため、翔泳社のDevelopers Summit 2014 Summerにて、パネルディスカッションを開くことにしました。Oracle、Microsoft、SAP、IBMと、モバイル製品にガンガン投資し、これからの企業向けシステムの進化を促そうとしている製品ベンダを揃えています。面白いトークができるのではないかと思っていまして、今から私もワクワクしています。ご参加下さい。

企業にモバイルを適用する方法「MEAP」の全貌を掴む(3) - SAP Mobile Platform編

企業にモバイルを導入するにはどうすればよいか?・・・その答えとして、2012年ごろから注目を集めているのが、「MEAP(Mobile Enterprise Application Platform)」と呼ばれるモバイルファーストな製品群です。

本連載は、IBMやSAP、Senchaなど、複数の企業が提供しているMEAP製品を少しずつ味見して、MEAPとは一体何なのか、企業のシステムの何を変えようとしているのか、その全体像を掴んでみようという企画として始めてみました。第3回の今回、そろそろ本質みたいなのが見えてきてもいい頃でしょう。

さて、今回探りを入れるのは、製品ベンダ「SAP」です。彼らが、MEAPに対してどのようなアプローチを試みているのか、探ってみましょう。前回紹介したSenchaはいわゆる、フロントエンドのリッチ化、HTML5によるSPA(Single-page Application)のテクノロジーで高い価値を提供している製品ベンダでした。彼らは言うまでもなく、フロントエンドに閉じた表現力、ポテンシャルの向上で勝負に出ていました。

しかしSAPは、いわゆるビジネスパッケージの製品ベンダ、彼らのビジネスはサーバ側での価値提供にあります。全く真逆を行くわけで、同じMEAPという枠の中でどういう面白さを追求しているのかが気になるところです。

SAPのMEAP製品が実現したいこと、彼らが企業向けシステムで実現したいことは何か?

少し歴史を振り返ってみましょう。SAPは2010年5月にSybaseを買収し、その2年後の2012年6月にはSycloを買収し、企業向けモバイルのノウハウを得ています。2010年の買収は、他の大手ベンダに比べると比較的早い段階です。ガンガンと買収を繰り返し製品を繋ぎ合わせ、「Mobile Platform」と呼ばれるMEAP製品をリリースするに至っています。そして2013年の秋に、彼らはMobile Platformのバージョン3.0をアナウンスしました。

しかし、その中身を覗くと、これまで出していたものとはまるで別物かのように姿を変えていました。エンタープライズモバイルは、今まさに技術革新の真っ最中ということもあり、かなり混沌としています。当然、SAPのMobile Platformも例外でなくまさに進化の真っ最中で、マニュアルの日本語化もなかなか追い付いていないことから、中の人的にもフルパワーで走っているのだろうということが想像できます。

繰り返しますが、IBMにせよOracleにせよ、企業向けモバイルソリューションは、大雑把に似たような機能を持っています。良い機能はみんな互いにマネしあって、コモディティ化が進んでるわけです。MDM(モバイルデバイス管理)やHTML5(ハイブリッド開発)、アクセス管理などが代表的でしょう。ただ、同じような機能なのにも関わらず、どの製品ベンダもMEAPという表現をあまり好んで使いません。そこには、製品の良さ・差別化されている点を強調したいという狙いがあるようです。

Oracleは「モバイル開発フレームワーク」なんて呼び方をします。対して、IBMは「エンタープライズ・アプリケーション・プラットフォーム」という表現を使っていたりします。MEAPをこれからどのように発展させて行きたいのかが、なんとなく理解できる呼び名になっていますね。

では、SAPはMEAPを何と呼んでいるでしょうか?彼らはMEAPを、「BYODソリューション」と呼んでいます。BYOD、すなわち、私用端末の企業内利用という面でのメリットを強く強調しているのです。欧米だとBYODはそれなりに浸透しており、私用で使っているようなモバイル上でも、社内システムにアクセスするだけのセキュリティ保護機能を必要としていたりします。SAPの製品は、こうしたニーズを狙ったものと言えるでしょう。

しかし、日本の場合、セキュリティ的に厳しく、BYODをそのまま実現できないことも多いようです。個人のモバイルを活用するというよりも、企業側が個人にモバイルデバイスの貸出を行うという流れに進んだようです。となると、BYODという言葉は、「プライベートな場に持ち出すような端末でも、安全に使えるほどにセキュリティを堅牢にできる」という意味合いで、使われるのが妥当に思えます。

f:id:furoshiki0223:20140716201742p:plain(SAPジャパン 井口 和弘「企業におけるHTML5を用いたスマートデバイス向けアプリ開発」より)

止まない、オープン技術の侵食

Webアプリのフロントエンド、HTML5やJavaScriptライブラリにはオープンソースの文化が根付き、ベンダロックインを激しく嫌う傾向にあります。JSライブラリあたりは特に、基本はOSSであることを望む傾向にあるようです。仮に有償の製品であっても、jQueryなどのOSSとの親和性が高いことを望む傾向にあります。

また、MEAPが目的とするところの「モバイル対応」についても、企業はあまりそこに予算をかけられないという課題があります。それこそ、新しくビジネスを作り、そのためのシステムを作ろうというのであれば予算がつくかもしれません。しかし、既に動いていて、ビジネス的に安定の時期に入っているようなシステムに追加予算を出すのは難しいというのが、多くの現場にとっての悩みなったようです。こうした背景から、営業力を高める上で「既存資産の流用」を望む声に答えるのが、重要な命題となりました。つまり、極力はHTML5に準拠したブラウザのような、オープンプラットフォームであることを追求するようになったのです。

SAPのMobile Platformはこのあたりの世の中のニーズを吸収してきた歴史が、はっきりと表れている製品だったりします。実はほんの少し前まで、UI周りをゴリゴリのベンダロックインさせ、プラットフォームも既存のWebシステムをそのまま流用させることを想定できていませんでした。しかしここ最近、特にMobile Platform 3.0からは「オープン化」を重要なテーマと捉え、様々な方向からオープンな技術との融合を狙っています。

例えば、Mobile Platformの一部をOSSとして公開したり、プロトコルにODATAを採用したり、既存のWebアプリをそのまま移植できるようにコンテナの汎用性を高めるなど、着々とオープン化を進めています。SAPと言えば、コテコテのベンダロックインな製品という印象が強かったりしますが、MEAPに関して言えば、出来る限りそうならないよう最善の努力を行なっているように見えます。

SAPからみると、オープン系の色が強い今のWebのフロントエンドはそれだけ異質に見えるのかもしれません。しかし、昨今のマイクロソフトもそうですが、OSSの普及で無償であることが前提のソフトウェア製品でどう儲けるかという、OSS前提のビジネスモデルの検討も進めていかなくてはいけません。そのことに、彼らは苦戦しているようにも見えます。

f:id:furoshiki0223:20140716201819p:plain(SAPジャパン 井口 和弘「企業におけるHTML5を用いたスマートデバイス向けアプリ開発」より)

統合化されたツール

急激に買収を重ね、強化を重ねたモバイル向け製品は、問題を抱えることになります。彼らは、Sybaseの持つ「Unwired Platform」「Mobiliser」、Sycloの「Agentry」へ、SAPの「NetWeaver Gateway」と、3つの異なる企業の製品を短期間のうちに統合することが求められたため、ツールにややツギハギ感が出てしまいました。しかしそれも、進化の中で改善されたようです。

SAPの製品は、UI開発のツールからプラットフォーム、バックエンドまでトータルな開発が支援できるという特徴を持っています。これはIBMのWorklightでもできることではあるのですが、筆者の所感として、全体的なバランス感覚、バックエンドとの接続周りには比較的強いという印象を持っています。インフラジスティックスのIgniteUIもそうですが、汎用的な製品とエンタープライズ製品の間で差別化を図る際、この手のデータ変換系を充実化させるベンダ製品が多いように思えます。フォームや表の出力を主とする企業向けシステム固有の特徴に、合わせて行った結果そうなったということでしょう。

f:id:furoshiki0223:20140716202016p:plain(SAPジャパン 井口 和弘「企業におけるHTML5を用いたスマートデバイス向けアプリ開発」より)

さて、SAPはこのくらいにしておき、最後にIBM Worklightについて取り上げてみましょう。

▼ 目次

  1. そもそもMEAPとは?
  2. Sencha Space
  3. SAP Mobile Platform
  4. IBM Worklight

▼関連
モバイルで企業システムをどう変えようとしているのか、ベンダ4社を集めその価値を問います。夏サミ2014、私はモデレーターとして参加します。

企業にモバイルを適用する方法「MEAP」の全貌を掴む(2) - Sencha Space編

Senchaはこれまで、SPA(Single-page Application : 単一ページアプリケーション)を実装するためのフレームワークやツールを提供し、プラグインに頼らないリッチアプリケーションの開発手段を提供してきました。モバイル向けには「Touch」、ノンプログラマー向けには「Architect」と、多数のフロントエンド開発の製品をリリースし、Web標準技術には高いノウハウを持っています。

その彼らが、2月7日のブログにて、「Space」の製品版リリースをアナウンスしました。この製品が、企業のスマートデバイス向けのアプリが抱える課題とリスクに対し、Senchaが出した答えのようです。本記事では、SenchaがリリースしたMEAP(Mobile Enterprise Application Platform)の製品、Space ver.1.0の中身を追ってみます。

★ Spaceのアーキテクチャ

Spaceは、前章で述べた、HTML5世代のモダンなMEAPアーキテクチャモデルをベースに採用しています。SpaceはモバイルデバイスのOSからアプリを隔離する環境であり、セキュリティやアクセス制御が行える箱の中でアプリを動作させることで、企業向けシステムに必要な要件をクリアさせます。

f:id:furoshiki0223:20140216072211p:plain

開発したアプリは、モバイル上では専用のアプリ「Space」上から起動します。

f:id:furoshiki0223:20140216071953p:plain

Spaceの特色

★ Space固有の特徴

Spaceの特色としては、Space内で動作させるアプリ同士で通信させるための独自機能「Invoke API」を提供していることでしょう。Invoke APIは、Space内の限定されたアプリ同士を、フォワグラウンド・バッググラウンドを通じ通信させることができます。

Senchaは、彼らのコアコンピタンスであるフロントエンドのリッチ化技術を活かし、サーバに依存しないデータ通信の仕組みを強みにしようとしているようですね。彼らはサーバ製品を持たないため、フロントエンド側で高いポテンシャルを得ることに、熱心なようです。

f:id:furoshiki0223:20140218003601p:plain

★ アクセス制御と集中管理の考え方

Spaceは他の類似製品と同様に、Management Concoleを通じて、グループベース・ユーザベースによるアプリの有効・無効を制御することができます。これは非常に一般的な機能であるため、別の機会に解説を行います。
f:id:furoshiki0223:20140218003931p:plain

★ セキュアなデータの記録

Space上のWebアプリケーションは、一般的なブラウザ上で扱うものよりも強固なセキュリティでデータを扱えるよう、専用のAPIを提供しています。ファイルの操作であれば「Secure File API」、KVS形式のデータ操作であれば「Secure Local Storage」を利用することになります。

★ 開発のワークフロー

開発は、Senchaの開発ツールであるSencha cmdを利用します。SenchaはExtJSなどのフレームワークをベースにアプリケーションを作りますが、Space固有の機能追加のため、フレームワークへSpaceのプラグインを追加して利用することになります。

開発プロセスとオープン性に適用の価値を求める

以前は単なるUIコンポーネントだったSenchaも、MVV*なフレームワークへ進化。独特のフレームワークゆえにそれなりの学習が求められるものの、開発のワークフローにしっかりと踏み込み、設計からテストフェーズまで一貫した思想に沿って開発させることで、エンタープライズでの活用に道を広げようとしています。他の製品には無い、彼らのアイデンティティでしょう。

また、Spaceに関して言えば、比較的オープンという特徴を持ちます。勿論、Spaceというプラットフォームにアプリを縛ってしまうという制約を持ちますが、MEAPの製品のいくつかは、サーバサイドの技術にまで影響を及ぼし、ベンダ製品に縛るものもあります。こうした中、Senchaという箱でしっかりとカプセル化し、サーバ側は比較的制約は緩くRESTライクな機能があれば動くのはメリットとして大きいように思えます。

Spaceは現在、10ユーザまでは無償で利用できる試用版を提供しています。日本語化はまだまだ甘いと噂されますが、Xenophyが解説ビデオにまで字幕を入れるなど、翻訳そのものの動きは活発のようです。

このビデオ、本記事のテーマである、企業システム向けに求められる隔離環境「MEAP」のメリットついて、非常に的確な解説を行っているためここで紹介しておきます。

Introducing Sencha Space - 日本語字幕付き from Xenophy Japan on Vimeo.

SenchaのSpaceについては、これで以上です。

次章はSAPについて取り上げます。SybaseやSycloといった企業を買収し、モバイル向けソリューションへの拡大に意欲を見せる彼らが、どのようなプラットフォームを提供しようとしているのか。その中身に、触れてみましょう。

企業にモバイルを適用する方法「MEAP」の全貌を掴む(1) - そもそもMEAPとは?

企業でのモバイル活用は関心の高いテーマです。昨年は、BYODという言葉が持て囃され、こちらもそれなりには関心が持たれました。

しかし、実態を見てみるとどうでしょう。InformationWeekが1月17日に公開した「5 Big Business Intelligence Trends For 2014」の主張からは、国外でもモバイルは企業内へ上手く浸透出来ていないという印象を受けます。万国共通して、モバイルの適用は一筋縄ではいかないようですね。

様々な異論が飛び交う「モバイル」と「BYOD」の2つのムーブメントですが、そのソリューションは高度化が進んでいます。企業向けシステムの構築方法、ITアーキテクチャの設計方法に変化を齎すような新しい流れが生じつつあり、企業向けモバイルアプリに一つの市場を作ったようです。

MEAP(Mobile Enterprise Application Platform)。言葉は2008年と歴史こそ古いですが、技術としての安定化が進み、またHTML5の登場で新たな進化の道が見つけられつつあります。このプラットフォームについて、これから4回の連載に渡り、その可能性を追ってみます。

モバイルではアプリを「隔離」させる

業務系のWebアプリについて、従来のデスクトップ型デバイスでは、セキュアな環境下でクライアントを動作させることを保証することで、セキュリティリスクを最適化させてきました。ブラウザの仕組みにせよ人的な脆弱性にせよ、「場所」に対して一定のセキュリティを確保することで対策してきました。

統合管理によるアクセス管理についても、Windowsが普及していたことから、Active Directroyの活用に改善が進められてきました。パフォーマンスも、前世代的なWebアプリは、主としてサーバサイドにフォーカスされていました。

ところが近年、モバイルの活用が求められ、企業システムは従来のデスクトップ型には無い独特の課題に悩まされ始めました。代表的なものとしては、以下が挙げられるでしょう。

パフォーマンス モバイルデバイスのハードウェアリソース不足。不安定な通信回線。
セキュリティ 持ち出し運び可能なハードウェア。平文では扱えない記録・通信データ。
マルチOS iOS、Android、Windows RTなどの複数のOSの混在。
アクセスコントロール グループベース・ユーザベースによる、アプリ・データへのアクセス権限付与の難しさ。

これらの問題に対して、BYODという切り口から解決方法が探られたようです。そして結果として、エンタープライズ向けのアプリは、モバイル上で扱う場合、「隔離された環境」の上で動作させてしまおうというアイデアが広がりを見せました。この仕組みは、どの製品もかなり類似した機能性を持つ傾向にあります。

共通点としては、以下のイメージです。

f:id:furoshiki0223:20140216045930p:plain

モバイルに隔離環境専用のアプリをインストールし、その上で業務で使うようなアプリを動作させる仕組みになります。アプリは、ワンソースでクロスプラットフォームに動作させることを目的として「ハイブリットアプリ開発」を活用します。従来のブラウザでは不足していた企業向けシステムに必要な機能、例えばセキュリティ・アクセス管理なども、OSから隔離されたこの環境に実装されます。

どのように開発するのか?

HTMLやJS/CSSのコーディングを行い、コンパイル(パッケージングとも呼んだりもする)という手続きを踏み、エミュレート環境や実端末上にインストールされます。デバッグは、この上で行うことになります。

フロントエンドは文化として、開発にはIDEに限定されず、オーサリングツールやエディタ+タスクランナーなどの多様なツールにより開発されます。隔離を行う環境は、独自のプラットフォーム上でアプリを動かす必要があるため、利用ツールやライブラリに多少の縛りを受ける傾向にあるようです。

f:id:furoshiki0223:20140216060636p:plain

どのように運用するのか?

企業向けの場合、IT管理者による業務アプリの管理・監視が必要とされるでしょう。これを実現するため、管理コンソール側から各隔離環境内のアプリの制御を行う機能を提供します。

f:id:furoshiki0223:20140216061159p:plain

どんな製品があるのか?

さて、一通りの概念的な部分の説明が終わったところで、ここからは具体的なソリューションに目を向けます。探せば色々出てくるのでしょうが、今回は以下3つの製品を探ってみましょう。

次回は早速ですが、Sencha Spaceをテーマとし、中身について触れていきます。

▼ 目次

  1. そもそもMEAPとは?
  2. Sencha Space
  3. SAP Mobile Platform
  4. IBM Worklight

日本のシステムの泥臭さにどこまで付き合ってくれるのか?グレープシティのWijmoを3分で把握する

wijmo日本のシステムは、ガラパゴスと言って過言ではないほど強い癖を持っているのは、もはや暗黙知というレベルでしょう。

この他国を寄せ付けない固有の文化は、日本のSIがコストメリットの大きい国外のパッケージベンダから身を守れた理由とも言われています。ただ、これがフロントエンドUIになると、日本だからこそ欲しいと思える機能を真面目に作りこめば、それはそれで泥臭い作りこみが求められます。時には、メンテナビリティに問題を作ることも少なくないはずです。

こういう難しさに対して、正面からぶつかり取り組むのが、グレープシティの製品の特徴です。グレープシティはこれまで「Wijmo(ウィジモ)」という製品を持っていましたが、そのバージョン3が1月30日にリリースされました。Wijmo自体は海外の製品ですが、グレープシティの日本法人が仕込む日本向け対応がきめ細やかで、今年夏に発売される「forguncy」と同様、日本の文化への適用に対する意気込みを感じます。

既にメディアではいくつか掲載されているようですが、本記事ではもう少し選定者の視点に寄せて、Wijmoについて評価してみます。

1. Wijmoとは何か?

Wijmoは、Webアプリケーションのフロントエンド側で活用する、UIコンポーネントのライブラリです。

競合製品であるSencha系とは真反対で、jQueryベースのライトな使い勝手を重視することで、効率的なUI開発とクロスブラウザ対策を助けてくれます。jQueryが使えるエンジニアも多いため教育コストは低く、また既に現場でも活用されているOSSなどのjQueryプラグインを継続して活用できる、というメリットが期待できるようです。

同社は2012年に米ComponentOneを買収し、米国トップ5に入るUIコンポーネントのベンダーの実績とノウハウを社内へ取り込んでいます。Wijmoは、グレープシティの一部門となったComponentOneのリソースを活用し、Webアプリという分野でも、同ソリューションが求められる場へ縦展開を狙った製品であると考えられます。こうした背景もあり、同社は現在も製品群に「ComponentOne」というブランドを継続して利用しています。

Wijmoは海外製のUI制作製品ですが、Wijmoの日本版「2013J v3」は、グレープシティ日本法人がその仕様策定に加わることで改善を加えています。そのままで販売するのでなく、いわゆる「日本らしいシステム」作り、先ほどにも述べた「泥臭い部分」を、ケアした状態で提供しているのです。

2. どんなことができるのか?

Wijmoは多くの機能を持ちますが、ここでは3つのケーススタディにフォーカスします。

★ ExcelっぽいUIをWebで実現する方法

日本で愛されるExcelライクなUIですが、これをWeb上で実現するライブラリに、SpreadJSを提供しています。ExcelっぽいUIや、.NETのUIでは定番なスプレットシートの埋め込みを実現できます。

jQueryだと「tablesorter」が有名ですが、それを凌駕する機能性をjQueryベースで実現します。

f:id:furoshiki0223:20140209204810p:plain

★ グラフ出力をjQueryのインタフェースで

SVGのアンチエイリアスがかかったグラフ出力を、jQueryのインタフェースで実現します。

ただ、グラフ出力JSライブラリは結構競争が激しく、OSSだとゴマンとあります。こうした中で、ベンダサポートが受けられ、jQueryの延長として活用でき、SVGの美しいビジュアルが提供され、コンスタントに求められるところを満足してくるあたり、やるところはちゃんとやるという印象を受けます。

f:id:furoshiki0223:20140209210452p:plain

★ 日本語最適化したフォームを作る方法

殆どの業務系システムだと、フォームの日本語対応は恐らく一番要になるところでしょう。Wijmoは、いかにして日本語を効率的に入力させるか、というところにはかなり力を入れているようです。

よくあるのが、.NETなどの開発で使う画面項目仕様書をそのまま流用してしまうケースでしょう。サーバサイドに問い合わせるまでバリデーションの結果がわからない作りであるため、Web化したことによりユーザビリティが激しく低下してしまった、なんてことがあります。JavaScriptをガッツリ使い対策するにしても、複数のjQueryの組み合わせたことにより、設計書との整合が実装から読み取りにくくなったり、複数のjQueryプラグインがイベントを引っ切り無しに取り合い実動作が見えにくいコードを生まれる、なんてことがしばしばあります。

より具体的に言えば、Web標準的オンリーでいくなら、タグ上での入力の長さ指定や、非常に雲行きが怪しい「CSS3-UI」に含まれているIME制御用CSSが、IE4時代から実装された現実的手段です。それだけでも少し怪しいわけですが、ここへさらにjQueryを加えれば、「jquery.validation」「jQuery Alphanum」「jquery UI」からdatepickerを引っ張り出したりと、プラグインを大量に読み込ませ、定義の位置も表記も揃わない、泥臭いソースコードが生み出されます。

Wijmoは、こうした画面設計書作成で定義したルールを、一つの整合されたライブラリで、画面設計側との整合を持たせた実装に落とし込めるようになります。このページが参考になるでしょう。

f:id:furoshiki0223:20140209212410p:plain

ID系だと表意コードも、特に対策を考えずWebアプリでガチガチにやると泥臭い記述が求められることが多々ありますが、こうした部分にもきめ細やかに設定できるのも魅力の一つです。オープンソースだと貧弱な日本語周りの対応も充実しており、日本語に対するカナ入力もオプションひとつで実装できていしまいます。

f:id:furoshiki0223:20140209214719p:plain

3. プロジェクト内でどうやって扱うか?

Wijmoの技術的なところをお話した後に、今度はプロジェクトというレベルでどう扱うかについて踏み込みます。

注目すべき点としては、ライセンス体系のライトさが挙げられるでしょう。WijmoはGPL版と製品版の2種類を持ちます。両者、含まれているライブラリなどの内容に違いはなく、どちらであっても同じことができます。

Wijmoは基本的には、オープンソースライセンスに従う範囲では無償です。Wijmoを使いサービスを作った際に、ソースコードを全て改変可能として開示できるのであれば、ライセンス費用は一切発生しません。そうでない場合、例えばイントラネットのようなクローズドな環境下でサービスとして動かす場合、製品版のライセンスを購入する必要が生じます。

グレープシティはWijmoをCDN(Content Delivery Network:コンテンツ配信ネットワーク)で提供しているため、インターネット上のサーバからライブラリを手元の環境へ読み込み、実現したいことができるか確認する、といったことができます。

さて、これらの点を踏まえ実プロジェクトではどうなるか考えてみましょう。

f:id:furoshiki0223:20140209221624p:plain

まず、プロジェクトの序盤、製品のポテンシャルを調査したい段階、ここではグレープシティへの事務手続きはおろか、問い合わせは一切不要です。CDN上のライブラリを引っ張ってきてサンプルを作れます。非エンジニアには難しいですが、jQuery慣れしたエンジニアならモックアップ程度はさくっと作れてしまうでしょう。

実際に使う段階になると、ライセンスはVisual Studio的な、基本「人」に紐付くシステムです。契約を結んだ開発者は、どんな開発端末上で活用しても良いし、それをクローズドなWebシステムとして提供しても良いというルールです。このため、フロントエンドとサーバサイドで分業した開発では、フロントエンドの開発要員がライセンス契約を結ぶことになります。

期間ライセンスなので、プロジェクトの開発期間だけ契約し、運用期間は数を絞るなり、改善が求められた際にスポットで契約するなりという方法になると想定できます。ライセンス有効時は、当然ですが、グレープシティが問い合わせを受け付けることができます。

もう少し知りたい?

そもそもですが、画面にそこまで細かい作り込みはいらない。グラフも単なる表でいいし、入力だってサーバで作りこんじゃえばOK、ユーザビリティはそこまで重要じゃないという案件では基本的に「不要」なライブラリです。2014年の今でも、そんなのが当たり前な業務システムは山ほどありますが、10年以上前の付加価値も効率面も変わらないやり方をそのまんま続けるべきか、これはもう企画段階の考えによるところでしょう。

カンファレンス今回紹介したWijmoですが、2月28日に開催される、「Enterprise x HTML5 Web Application Conference 2014」にて紹介されます。

このカンファレンスは中立的な運営なので、偏りを気にせず、他の製品と比較してそのメリット・デメリットを評価できます。他の競合製品と横並びにするには持ってこいなイベントになります。

興味があれば、是非ご参加下さい。

HTML5は脱バズワードできるのか?エンタープライズ特化のHTML5カンファレンスを開催する

conference2013年、HTML5というキーワードは大声で散々語られ、メディア側もそれを極力注目されるように報道してきました。そのことが、多くのエンジニアへありがちなバズワードという認識を刷り込み、不安な印象を植えつけたことも少なく無かったようです。

ただこれは、Web標準という非常にプレイヤーが多様な技術にも関わらず、コンテキストの異なる意見が横並びにされ、それが結果として混乱を誘う結果に繋がったとも受け取れます。ブラウザの中でグリグリ動き回る動画なんかを見ていると、確かに凄いんだけれども、それって自分たちの相手にしているユーザ企業のどんな価値に変わるんだ?と。通信手段が進化して、それでどうなるんだ?なんて、そこにある種の不信感を抱いた人も少なくないはずです。

テクノロジーの価値は本来、業界・環境に合った視点から語られるべきです。エンタープライズにとっての価値とは、ゲーム業界や電子書籍業界のそれとは、異なって当たり前でしょう。

流れを変えるべく、私は一つの企画を立ち上げました。
それが「Enterprise x HTML5 Web Application Conference 2014」です。

本記事では、この企画の「拘ったポイント」をご紹介します。

1:プラットフォームだけにフォーカスしない

これまでHTML5と言えば、専らブラウザなどのWebプラットフォームの機能にフォーカスされました。ポテンシャル向上は確かに有益ですが、SIでそれを扱うには、満足できない多くの課題を持ちます。

SIでの開発では、規模が大きいプロジェクトで安定して品質・進捗を把握したり、要員のスキルが安定しないといった特性へ、アプローチすることを求められるマネージャも多いでしょう。営業であれば「HTML5だから」なんて言葉では、その価値を十分に訴えられない。テクノロジーとして、ユーザの価値に直結するアイデアが求められるでしょう。

本カンファレンスは、こうしたプラットフォームのポテンシャル以外の部分にも注目し、開発プロセスでどう取り組むべきか、提案としてどういうものがあるか、といった、より高いレイヤーで語るセッションを含めています。恐らくそれは、ベンダー系のセッションに多く含められているはずですが、サーバの内側にいない、ユーザに見える場所のモノ作りを商品としている彼らから、何かエッセンスを得られるのではないかと期待しています。

ここ数年、営業ポジションがモックアップを作りユーザに見せるためのツールが増えました。ジャスミンソフトの「Wagby R7」に、Senchaは「Architect」、グレープシティは「Forguncy」と、これらはインタフェースこそ異なりますが、明らかに非エンジニアを意識したツールです。今後は、こうしたツールを活用し、ユーザのイメージとの乖離を小さくしていく取り組みが、ユーザ満足度向上の要になることが予想されます。

また、ビジュアルデザインについてはUI/UXが注目され、国外はユーザビリティエンジニアという職種が力を持ちます。オープンな技術であるWeb標準が表現力を獲得したことから、こうした考えも、コスト競争下に置かれた環境で影響力を持つことになるかもしれません。

本カンファレンスは、これらWeb標準技術を取り巻く変化から、何かしらのアイデアが得られる場になればと考えています。

2:テーマを被らせない

セッション内容を被らせない、本カンファレンスはここに重きを置きました。

今回のベンダ、実は私が直々に声をかけた企業だけが参加しています。本カンファレンスはお金を取ることは考えておらず、運営はボランティア主体、スポンサー費の余りは全て、懇親会と決済代行を行っている株式会社びぎねっと様へ還元します。こうした環境が、コンテンツの選定から制約を取り除くことに一役買いました。大前提は、テーマを被らせないこと。それぞれがコアコンピタンスを持ち、彼らのカラーを武器に製品の良さを語れると、聴講者に持ち帰るものは大きいと考えたからです。

これを言うとスポンサーに怒られそうですが、テーマとして扱う製品については「使うか使わないか」は考えなくていいと思っています。従来には無い概念も多いため、まずは、今のフロントエンドの製品のポテンシャルに触れて欲しいというのが私の率直な考えです。それも、「エンタープライズ」というターゲットにフォーカスされたものにです。

オープン系についても全面にプッシュしています。コミュニティセッションの殆どが、ユーザグループの代表ばかりが揃い、本の著者まで出てきてその製品の良さを語ります。彼らの目から、Web標準技術へのアイデア、技術的な価値について存分に語られることでしょう。

エンタープライズ向けのWeb標準特化型カンファレンスとしては、この国内では未だかつて無いほど濃い時間が過ごせるよう、調整に調整を重ねました。

3:今の延長で語る

Web標準技術を活用したシステムは、かなり普及しています。2000年以降、PHPやJavaの普及がその勢いを後押ししてきました。

米調査会社のガートナーは今から1年前、エンタープライズ領域において、2016年にはハイブリットアプリケーションの50%以上がHTML5を活用すると予測しました。ただ、この1年ですっかり状況は変化し、ハイブリット以外にもそのノウハウが求められるようになりました。

マイクロソフトがWindows 8系以上のOSで、レガシーIE資産を捨てて、HTML5世代のWeb標準に準拠することを強制し始めたこと。彼らは、OSというレイヤーに多くの競合が出現し、今やビジネスモデルそのものにメスを入れ始めています。CEOは変わりましたが、彼らが彼らのビジネスを守る姿勢はこれまで以上に変わらないはずです。ますます、コモディティ化されたクライアントプラットフォームとしての、Web標準が重要視されることでしょう。

こうした背景の中、本カンファレンスはまず、今のWeb開発プロジェクトに慣れた人が、今の延長で現状の問題の解決方法を発見して欲しい、という想いがあります。今のスキルセットの延長に新しい道を見つけれられないか、と考えています。

質の良し悪しはありますが、それでもHTMLを書いてきた人は世の中に確実に大勢いるわけで、そういう場に直接的に持ち帰るものがあるのは素晴らしいことです。当然、今の現場を変えることに抵抗がある方は多いでしょうが、同じことの繰り返しが結果を生み出せなくなったケース、FlexやSilverlightのような技術の代替が求められているケース、スマートデバイス向けに対策を行わなくては行けないケースと、待ったなしで課題は生じ、リスクばかりを取っていられない現場もあるでしょう。

奇抜でなく着実な選択ができる、我々のコミュニティはそういう技術を追い求めてきました。そして本カンファレンスも、例外なくその方針を貫いています。探ってみて下さい。何かが見つかるはずです。

最後に

エンタープライズという枠で語るのだから、本来であればより広い視点で語るべきかもしれません。しかし、今回はひとまず「SI」にフォーカスさせて頂きます。まずSIが幸せになる道を、模索してみようかと思います。

私を含め、コミュニティのスタッフ全員の様々な想いをのせたカンファレンスが、まもなく開催されます。どうぞご参加下さい。

元W3Cの中の人と、エンタープライズのビジネスチャンスについて語った話

変化を好まないSIですが、HTML5が開発方法に変化することを求めている。

昨年、私はメディアやカンファレンスなど様々な場所で、その意義について発信してきましたが、「HTML5を使えば"今まで以上"のことができるのだろう」「それなら、あまり関係ない話なのかも」なんて油断していたエンジニアにとっては、「今も変えろ」というのは衝撃的な事件だったに違いありません。

そんな混乱を、W3Cという異なる立ち位置にある組織に所属しながら、ビジネスにできるのではないかと考えた人がいます。

彼と出会ったのは、オープンソースカンファレンス2013/Fall。あまり人前に出たがらないキャラクターなので、名前は伏せておきます。

イベントで会った彼は、凄い熱意でW3Cのイベントに誘ってくるもだから、私の脳はしっかりと彼の顔と名前を刻み込みました。しかし、OSC.Enterprise 2013で再開した時、彼は私のことなどすっかり忘れていました。私も人と会うタイプなので、何度かやらかした経験がります。全く責める気になれません。

2枚目の名刺を渡された時に、彼は一言
「この名刺、前職のものだから渡すべきか悩むんですけどね」

★ W3Cをやめて、エンタープライズ業界に入った

つい2ヶ月前に、あれだけW3Cイベントをゴリ押ししていた彼は、数年務めたW3Cを辞めていました。その名刺は、名前の部分以外は機能していません。

彼は以前より、Web標準技術とアカデミックな場で繋がるのでなく、ビジネスとして繋がりたいという想いを持っていたそうです。知人の誘いを受けて、エンタープライズの世界へやってきたとのこと。中国に依存しない新しいオフショアを支援する、ベンチャー企業に入っていました。

W3Cにいて何を感じたのか

彼は少し前まで勤めていた、W3Cについて語ってくれました。

★ エンタープライズとWeb標準

私はW3Cの議席に、GoogleやMicrosoftなどがちがちのビジネスプレイヤーがいるので、組織の内部はかなりビジネス色の強い場だと思っていました。しかし彼いわく、W3Cは非常にアカデミックな場だそうです。

言われてみれば、UNIXから始まったLinuxの文化、オープンソースの起源は、非常にアカデミックなものだったと本で読んだことがあります。NTT出版の「Linuxはいかにしてビジネスになったか―コミュニティ・アライアンス戦略」だったと思います。5年以上も前に読んだのではっきりは覚えていませんが、オープンテクノロジーは、そういう性質を持ちやすいという特性を持っている。

ただ、Web標準はコモディティ化された技術でありつつも、プラットフォームを取り巻くエコシステムに方向性が左右されるという状況に置かれています。ブラウザなどのプラットフォームを作っているベンダと、共に手を取りビジネスを作っていこうという団体/企業側に、技術進化が最適化されていくという環境に置かれています。

こうした背景もあるのでしょう。彼は「日本のエンタープライズのプレイヤーはもっとWeb標準に関わるべきだ」と語っていました。昔はそいういう企業が多く関わっていたのに、今は殆どいなくなったそうです。日本のSI所属する私の目から見ても、エンジニアたちはブラウザを単なる無料のクライアントプラットフォームと考え、今までもこれまでもずっとこのままだと信じて疑わない雰囲気が感じられます。システムがこれだけWeb標準技術が依存しているのに、進化の動きを制御できない状況にあるのは、果たして安定して長く使えるプラットフォームと言えるのか。

しかし、これも時間の問題だと私は考えています。

今のSIは、Web標準に直接的に関わるメリットがあるようには見えません。ブラウザなどのプラットフォームを開発する側が、エンタープライズに新しい価値を運んでくるのではないかと睨んでいます。なんだかんだで、事件が起こる直前あたりに何かしらのソリューションが生まれて、SIが二次的にWeb標準へ関与するようなモデルになると予想しています。IT業界におけるSIというデカい市場を、無視できないでしょう。

本来オープンテクノロジーはフリーのソフトウェアなんかではなく、オープンなコミュニティとの関わり、貢献によってビジネスが成立させるモデルだったはずです。どこかのタイミングで、何かしらの形で、正常な姿に戻らざる得なくなると考えています。

★ WebStorageがW3C勧告になっていた件について

少し話が変わって、標準化の話に。WebStorageは、IE8から実装されている少し歴史のあるWeb標準ですが、2013年の夏、突如としてW3C勧告化し、私は驚きを隠せませんでした。標準化の動きを追っていれば、突然というわけでもなく、ごくごく普通に正式なプロセスを踏んでいるのは確かです。

ただ、この件について「あまりにも静かだから、若干驚いた。いや、自分の中では結構ニュースだったかも」と彼に伝えた所、「いや、ニュースだと思うよ。あれはW3C側から見ても。」とのこと。

HTML5も2014年にW3C勧告になると、一時期すごく騒がれていました。しかし、これだけエコシステムが発達し、HTML5に強く依存したビジネスを数多く見ていると、W3C勧告化はメディアで目立つこと無く、いつの間にか終わってそうな気がします。

なんとなくそんな空気感を察した私は、技術評論社のSoftware Design 2014年2月号にて「目利きによる業界予測、2014年IT業界はどうなるのか?」という記事を執筆させて頂いた際、「2014年はHTML5が、W3C勧告!W3C勧告!」だなんて派手に騒いだりはしませんでした。一言触れる程度で、ささっと終わらせました。むしろ、そのことに触れなくてもいいんじゃないだろうかとさえ思いました。

「そもそも、今回のHTML5のW3C勧告化って、かなり限定的ですよね・・・」なんて事を彼が言っているのを側で聞いていると、標準化のプロセスより、エコシステム側の動きを追う方が理にかなっているように思えました。きっとこれからは、そういう時代なのでしょう。

★ オープンテクノロジーとMicrosoftの意外な関係

彼は「Microsoftはオープンテクノロジーに対して、下手したら一番ぐらいに貢献しているのではないか」と語っていました。Linuxに多額の出資を行い、オープンソースの発展に大きく関与していたのは、実はMicrosoftだったと。その真偽はわかりませんが、確かにフロントエンドの世界では、jQuery FoundationにSilverlightの開発者をフルタイムで関わらせるなど、Microsoftはその進化に強く関与しています。Web標準も同様にです。Microsoftがいなかったら、Web標準技術の進化は今とは異なる状況だったに違いありません。

ただ、巨人は時間を経ると嫌われる、批判の対象になるというのは、人間の遺伝子に刻まれたものだから仕方がないでしょう。私自身、オープンテクノロジーに関わる者として、不平を言いたくもなります。こうあって欲しいんだけどなぁ、なんてことを思ったりもします。これは別に私だけが特別というものでもなく、ベンダ製品サイドであるMicrosoftと対極に位置してしまっている、オープン技術サイドの思想の課題に思えます。

「あそこまで貢献しているのに、オープン系の世界では嫌われ者になってしまっているMicrosoftは不憫でならない」と、話題の最後に彼はこう締めくくりました。

これは私の主観ですが、サーバサイド側とフロントエンド側とでは、その嫌われ方が少し違うと感じています。フロントエンドは、「ベンダロックインだから嫌い!」と言うよりも、「IE6〜8が技術的に問題を抱えているから嫌い!」という状況に見えます。IE8以下は、Netscape戦争の延長上にある時代のブラウザですから。そんな古い思想のブラウザを、仕事として扱わなくてはいけない人たちからすると不満しか無いでしょう。まぁ実際の所、IE8はMicrosoft自身も暗に厄介者扱いしているように見えますが。

理由はなんであれ、最終的に「不憫」になるあたり、巨人の悩みは永遠に尽きないのでしょう。IEって業務系だと、結構重要な機能を持っているんですが。特にWindows 7系だと、気がつかないうちにその恩恵を受けているケースも多いでしょう。

HTML5が生み出した新しいビジネス価値

嫌われ者で不憫なIEですが、現場的視点からビジネス視点に見方を変えると、結構ポジティブだったりします。

★ やはり、IE11のリリースは大きい

Web標準側の人間だった当時の彼の目から見て「IE11のリリースは衝撃的だった」と語っていました。まさか、W3Cのような全く異なる立ち位置の人間から、そんな言葉が出てくるとは思いもしませんでした。「何が衝撃的だったのだのか?」と私が問うと、まるで答え合わせのように「ドキュメントモードの非推奨」と返ってきます。

「あれはもはや、一つの市場を作ってもおかしくないんじゃないか?」と。まさに昨年末、私がしつこいというレベルで言い続けていたことを、目の前で再現するように説明され、度肝を抜かれました。

今、企業のイントラネットには、Quirksモード/ドキュメントモードに依存したWebシステムが大量に動いてます。Windows 7へのアップグレードで、更に深く依存してしまっているという状況です。それが、Windows 7のアップグレード先のOSでは、サポートされなくなるという状況に陥っています。日本は韓国ほどActiveX依存していませんが、何かしらインパクトがあることは間違いないでしょう。

「Windows 7のEOLの、だいたい1年前ぐらいが稼ぎ時かもですね。あと5年ですか。」なんてことを彼は言っていました。私の考えは少し違います。今の時代のステークホルダの傾向からして、「どのあたりのタイミングでメディアが騒ぐか」の方が重要と考えていたりします。

3年後か、それとも直前か。インターネットメディアの場合、今のところトリガを渡すのはそんなに難しいことでもないので、やはりここでもエコシステム側であるベンダの動きに着目するのが、有利な気がしています。ユーザ企業側がバズワードに反応することも少なくないので、何か新しく言葉を作るかもしれません。

★ スマートデバイスはどうなるのか?

スマートデバイスについて、彼は恐らくWeb標準側の考えだからなのでしょう、ユーザビリティの高い端末とそのデザインが武器になると睨んでいました。対して私は、IT管理者の制御下に置きやすい、セキュリティを制御しやすいことが、より直感的で解りやすいスマートデバイスが出てくると今よりもっと広まるのではないか、と主張しました。システム利用者でなく、ステークホルダ側が重視する点に多くの判断材料を与えることができれば、導入されやすいと考えているからです。ここは意見が割れました。

IE11からスマートデバイス最適化の道に進んだので、Active Directoryに完全対応が進むかもしれないWindows 8.2とか、IE12の進化、ChromeやFirefoxのエンタープライズ向けサービスの多様化に、私はかなり期待しています。今が黎明期なのは、間違いなと感じています。バズワードとしてのHTML5は2013年をピークに下がっていくのでしょうが、エンタープライズでのソリューションの多様化、ビジネス化は、これからと考えています。

★ オフショアの新しい道

本記事の序盤でも述べましたが、彼はベトナムの安い人件費を使って、新しいオフショアサービスを提供するベンチャー企業に勤めています。

カヤックのセブ島の話なんかを見ていると、世の中の流れ的には、もはや中国に道を見つけようという考えはどこにも残されていないという流れです。日本企業のことですから、大連のIT企業をすぐに切ったりはしないでしょうが、これから中国で新しく開拓しようというモチベーションはすっかり失われてしまいました。

つい数年前、オフショアは大連が当たり前で、それこそ発注直前にまで持っていった私にとっては驚きです。もはや脅威です。恐ろしく短い期間でビジネスモデルが崩壊していくのを目の当たりにして、「オフショアはエンタープライズに向いているのか?」なんていう、そもそも論を始めたくなりました。

ただ、日本は昔から海外のリソースに頼る文化があるので、オフショアをビジネスとして成立させれるのか、これからも真剣に取り組まなくてはいけないようにも感じています。彼はこの新しいリソースに、どのようなブランドを持たせていくか悩んでいるようです。今のフロントエンドの特殊性を合わせることで、アイデンティティをもたせようという戦略を、一つの選択として持っているようでした。日本の場合は事例が大切なので、「使ってもらうこと」からスタートしなくてはいけないのですが、きっと彼はあの熱意で、困難を乗り越えていくのでしょう。

彼を、私のコミュニティが運営するイベントに登壇させようという計画があったのですが、色々事情があって無くなってしまいました。当面、彼と会う予定はありません。2ヶ月もしたら、また顔を忘れられているかもしれませんが、それでもきっと旨い酒が飲めると思います。

そのうち、強引にでも登壇させよう!
・・・目立ちたくないって怒られそうですが。

日本人が開発したJavaScriptライブラリ、エンジニア別国内利用率ランキング

「エンジニアはGitHubにソースコードを上げると、転職で有利になる!」なんて言われている時代ですが、本当にそうなのでしょうか?多大な時間を割いて、ソースコードを管理し、マニュアルを作り、特設ページを作り、公開することに意味はあるのでしょうか?

昨年の11月、ふろしき.jsでは1,300の優秀と評価されたWebサイトを調査し、利用率の高いJSライブラリをランキング化しました。実はこの調査、一筋縄ではいかず、実際には1,800弱とデータサンプルとしてはそこそこな母数を確保し解析しています。

その調査の中で、わかったことがあります。

フロントエンドは、日本のエンジニアが個人で開発したようなOSSのJSライブラリが多く含まれ、重要な部品として活用されているのです。個人でも入り込める隙がある、そう思うと、フロントエンド界隈でGitHub上にソースコードを公開するモチベーションは、比較的高いのではないでしょうか。

国産OSSはフロントエンドで、どの程度の影響力を持つのか。日本のエンジニアに限定してランキング化し、彼らの素晴らしい働きに敬意を表してみましょう。なお、国内利用率が0.5%に満たないもの、開発者本人だけが使っていると思われるもの、法人により公開されているものについては、除外させて頂きます。

国内利用率「0.5〜1%」の部

200サイトを確認すると、1件程度は見つかるJSライブラリとその開発者です。主に、レイアウトを作りこむための用途に集中している印象があります。同じレイアウト系のライブラリであるTwitter Bootstrapの利用率が0.5%以下であることからも、かなりの健闘ぶりです。

順位 利用率 所属/開発者名 公開しているOSS
13位 約0.5%
bit part 合同会社
奥脇 知宏
jQuery AutoHeight
12位 約0.5%
STARRYWORKS inc.
木村 幸司
fixheight.js
11位 約0.7%
東芝ソリューション株式会社
竹中 隼人 (うりん)
jQuery Tile
10位 約0.7%
所属・実名共に不明
Xlune
jQuery vgrid

さすがはWeb標準技術、色んな業種のプレイヤーが揃っています。

Xlune氏の情報はネット上から見つけられなかったのですが、先日開かれたHTML5 Conference 2013のCodeIQのテストで満点を取っていたので、レベルの高いエンジニアであると考えられます。

国内利用率「1〜2%」の部

100サイト中1〜2件程度は見つかるJSライブラリとその開発者です。このあたりまで来ると、開発者本人以外の人も、メンテして利用しているように見えます。

順位 利用率 所属/開発者名 公開しているOSS
9位 約1.0%
フリーランス
帆秋 洋志
jQuery.rollover.js
8位 約1.1%
アイトランス株式会社 代表取締役
石井 栄徳
jQuery Socialbutton
7位 約1.2%
株式会社ラナデザインアソシエイツ
山本 圭助
slider.js
6位 約1.2%
株式会社ファーストインパクト
KAZUMiX
rollover2.js(約0.5%)
scrollsmoothly.js(約0.6%)
5位 約1.3%
株式会社ピクセルグリッド 代表取締役
中村 享介
yuga.js
4位 約1.8%
フリーランス
長谷川 広武 (はむ)
jQuery Opacity Rollover

このあたりにまで来ると、どのエンジニアも、本を執筆していたり、会社を起こしていたり、フリーランスで活動していたりと、一人でメシが食えることはもはや当たり前で、+αとして何かしらのアイデンティティを持って活動している人たちばかりが集まっています。

公開しているOSSも、スライダーやロールオーバーなどパーツ系ライブラリが集まっています。

国内利用率「2%以上」の部

ここまで来ると、もはや別の次元に入っている印象があります。

★ 第3位. コリス (約2.4%)

エディトリアルデザイナーを経て、ウェブ業界へ。Rainbow Japan Inc.、Business Architects Inc.を退職後、 現在フリーランスとして活動されているらしいです。(詳細はイマイチ調べきれていませんが)

公開しているJSライブラリ「jQuery Page Scroller」は、国内利用率が約2.4%と高い影響力を持っています。

★ 第2位. Cyokodog (約2.8%)

ネット上でのみ活動しているらしく、職業は社内SEとのこと。jQuery関連の記事を書かれているそうですが、ここまでの影響力を持っていたら、もっと色んなことができそうな気がします。

公開しているJSライブラリ「jQuery exFixed」は、国内利用率約2.8%の影響力を持ちます。

★ 第1位. 西畑 一馬 (約9.5%)

「株式会社まぼろし」所属のフロントエンドエンジニア。Web界隈の有名人の中でも、頭一つ抜けているスーパーエンジニアという印象があります。彼が公開しているライブラリは、日本国内のWebサイトであれば10中1件程度は見つかるほど広く利用されています。

有名なライブラリとしては、もはやデファクト標準と言えるほどの利用率を誇る「heightline.js(約8.5%)」「alphafilter.js(約0.8%)」「wordbreak.js(約0.1%)」が挙げられます。ここまで来たら、世界に行けてしまうようにも思えます。

おわりに

GitHubはエンジニアの転職に役立つのか?

「公開したライブラリのネームバリューを生かして、こんな就職をしているみたいです!」なんて結果を期待しましたが、どれも役立てているかと言えば、正直なところよくわからないという結果になりました。転職におけるGitHubの意義は、ソースコードを見て貰うというところが目標になっているので、今回の調査、切り口がやや違っていたのかもしれません。とはいえ、ブログに貼り付けた程度のソースコードでもかなりの影響力を持ち、またその公開者が記事を書いたり会社を作ってたりと、その活躍ぶりからある程度の相関性のようなものが読み取れたかと思います。

今年の年末あたりにもう一度調査してみると、もっと面白いことが起こっていそうですね。楽しみです。