さようならHTML5…。
アメリカ人と日本人の標準化に差を感じる
http://engineer.typemag.jp/article/fukuyuki-html5
HTML5は巨神兵。
「……腐ってやがる。早過ぎたんだ」
今さら、「これからはHTML5だ！」と言っている人はもう、カッコ悪いかもしれません。
「ロングブレスダイエット」全盛の今に、「朝バナナダイエット」の素晴らしさを語るくらいカッコ悪いです。
FacebookのザッカーバーグCEO、「HTML5に賭けたのは失敗」
http://www.itmedia.co.jp/news/articles/1209/12/news032.html
ついにザッカーバーグがHTML5をdisり始めました。
iOSのfacebookをHTML5ベースからネイティブに書き直してリリースしたのは、皆さんご存知の通りです。
Android版も今後、ネイティブに書き直されるようです。
HTML5は長期的には正しいが、ミスだったと認めているとのことでした。
今のスペックではHTML5はクソ遅い上に、Androidは整理されてない上にバージョンがバラバラなので、今ではまだまだ端末互換性も低いです。
つまり、HTML5は巨神兵なんです。
「……腐ってやがる。早過ぎたんだ」
先日も、同じようなことを聞きました。
Android系の方々を中心としたHTML5の勉強会でHTML5賛美のプレゼンが聞けると思いきや、スピーカーの多くが、次々に「HTML5は言うほど素晴らしくも、桃源郷でも、銀の弾丸でもない」というプレゼンを発表し、HTML5の勉強会がHTML5をdisる会になってしまいました。
もう、笑うしかありませんでした。
個人的な意見で言いますと、少なくとも「今の」HTML5は限定的には素晴らしいですが、「HTML5だけで、世間のネイティブ並みのユーザーインターフェイスを実装するには厳しい」と思ってます。
むしろ、どこまでネイティブで作って、どこまでWebViewとHTML5で作り込むかの切り分けをするとスムーズなのか、割り切れるスキルが必要になっていると思います。
ぶっちゃけ互換性がアホ過ぎます。
僕は、多くのHTML5ベースのソリューション（PhoneGap/jQuery Mobile/enchant.jsなど）でテスト的にいろいろ作ってみて今の市場では実用は難しいかなと判断しました。
いろんなものの実装があいまいですし、動いたり、動かなかったりで、動作がもっさりしてしまうケースもあります。
特にAndroidのブラウザの互換性はバラバラの上に、今後、Android4.1以降はChromeベースの新しいブラウザが搭載されていくので、HTML5は検証の工数は増えていくように見えます。
Googleさまはわれわれにカオスを与え続けることが大好きなようです。
今後、Windows Phone 8が出てきてサポートを求められると、地獄絵図と化すのが目に見えています。
乱立するオレオレHTML5
「HTML5で開発できる」という触れ込みで注目されていたWindows Phone 8も、「フタを開けてみると標準化とはかけ離れたものだった」（村上氏）
Windows Phone 8やTizenやFirefox OSといった今後、新しく登場するスマートフォンのアプリケーションがHTML5ベースで開発できるという話が出ました。
その話だけで、多くのアプリクリエイターはHTML5を賛美したのはご存知の通りです。
「これからのスマートフォンはすべてHTML5で開発だ!! HTML5だけやっていれば良いんだ！」
皆さん、そう思ったに違いありません。もちろん、僕もそう思いました。
しかし、フタを開けてみると、Windows Phone 8もTizenもHTML5も独自仕様で、標準のHTML5とはかけ離れたものでした。ワンソース・マルチデバイスの夢はあっという間に叩き潰されました。先日、マイクロソフトさまからWindows Phone 8の開発セミナーを受けたのですが、マイクロソフトの講師の方が言われたフレーズが頭から抜けません。
「標準なんか考えなくて良いんです！動けば良いのです！」
先日、アメリカのGoogle I/OでGoogleさまに最新のNexus 7上の最新のChromeでぐりぐり動くゲームのデモや3Dゲームのデモを見せていただきました。
「このChromeのHTML5のデモはすごいですね！ iOSでも動くのですか？」と説明員の方に聞くと、
「いつか動くようになるよ！」とシリコンバレー流ポジティブスマイルで返されました。
僕は、関西エンジニア流ネガティブ愛想笑いで応酬するしかありませんでした。
AppleはAppleで、最初はSafariで使われているWebkitというHTML5のWebレンダリングソフトウエアを作っていたのですが、その後、オープンソースのコミュニティでGoogleさまがWebKitにコントリビュートし始めた結果、逆にSafariよりもChromeの方が先に、どんどんいろんなものを実装し始めました。
おかげで、HTML5のデモアプリの多くがChromeでしか動かなくなり始めました。
何より、HTML5のイニシアチブを取っているApple、Googleの2社が、”例の別件”で殴り合いのケンカをしていて、ついには、iPhone5の地図アプリが残念な結果になるというとばっちりを受けているのは、皆さんもご存知の通りです。
オープンソースのコミュニティなので”例の別件”と切り離されているとはいえ、HTML5の実装に波及しないか心配です。
そんなわけで、HTML5がアメリカ人どものエゴでカオスな戦場になりつつあります。
もちろん、今後、HTML5がメジャーになる可能性も高いです。
むしろ、実装工数が低いので、HTML5がメジャーになってほしいです。
あれほど楽で実装コストが低い開発環境は、今のところ地球上に存在しないと思っていますが、どうにもこうにもさまざまな方々が新しい技術を主張して、互換性に危険な匂いがしています。
GoogleもAppleもMicrosoftもケンカしてないで、仲良くできないのかと思います。
だいたい、動画や音声などの基本的なメディアのフォーマットすら大人の都合で統一されてないって、どんな標準規格なんだと問い詰めたい。小一時間、問い詰めたい。
リリース前に誰も突っ込まなかったのだろうか？
アメリカ人たちのエゴを一般ユーザーに押し付けるのもどうなんだと思ってます。
個人的な偏見に満ちた考えですが、アメリカ人だけが集まって標準化をしようとすると、変に個性とエゴを発揮してグダグダになるように思います。
一方、同じ白人でもドイツ人やイギリス人、そして日本人に発言力があった時代は、まだ協調して足並みをそろえて作っていたように思います。
アメリカ人のステークホルダーだけがよってたかって作ると、トップダウン的になるか、カオスになるかのどちらかに見えます。
W3Cがものすごく頑張っていた時もステークホルダーと足並みが合っていなくて、ネットスケープ時代から、JavaScriptがすでにカオスでした。
しかし、まだ船頭がいたのでマシでした。
しかし、 HTML5においては、WHATWGが「実装しながら考える」方式で標準規格を構築しているため、カオスになりやすい上、W3Cそっちのけで動いている上に、ステークホルダーが複雑化し、船頭多くして何とやらで、明日は、どっちにいくのか分からない状況です。
互換性と横並びの構造作りは日本人の方がすごかった
アメリカ人が集まって業界で標準規格を作ると、ハイスペックで個性と拡張性を重視する一方、互換性ウンコでカオスになりがちに見えます。
一方、ヨーロッパ人や日本人が標準化をすると低スペックですが、足並みと横並び互換性重視で整然とするように見えます。
もちろん、HTML5とエレクトロニクスの標準規格を比べるのはナンセンスであるということは理解してますが、それを差し引いても、アメリカ人のやり方には、理解できないことがあります。
前回の記事で日本メーカーのサラリーマン横並び思想をさんざんけなしましたが、この点は日本メーカーはよくできていたように思います。
日本お得意の「横並び思想」。
その実力は、標準規格を作る際にいかんなく発揮される
日本が元気よくて、エレクトロニクスの世界標準規格を日本人だけでジャイアンのように決めていた時代、他社との互換性を気を配って、徹底的に足並みをそろえて、お客さまにご迷惑をお掛けしないことに異常に命を懸けていたように思います。
ソニー以外は。
VHSにしても、CDにしても、MDにしても、デジカメにしても、iモード規格にしても、SDカードにしても、DVDにしても、日本人の手法で標準を作ると、互換性がすさまじく、世に出すまで、徹底的に横並び体制の構築を頑張っていたように思います。
だから、エレクトロニクス業界はカオスにならなかったのだと思います。よく言えば、互換性重視。悪く言えば、護送船団方式です。
ご存知のように、ブルーレイなどは、コンテンツホルダーであるハリウッドと、日本を中心にした家電メーカーで足並みをそろえて、膨大なプロファイルと複雑なランタイムが搭載されているのにもかかわらず、互換性を重視し、プロファイルを厳格化し、日本メーカーと米国だけで、決めちゃいました的な世界標準です。
こういう徹底的な根回しと足並みをそろえるのは日本人らしいなと思いました。
例えば、MPEGという規格そのものは日本人がベースで作ったものです。
MPEG-1あたりは、互換性を大事にして、デバイス系プレイヤーで画角とFPSがまともなら、再生できないなどのトラブルがあまりなかったのですが、MPEG-2を経て、MPEG-4になった時には、アメリカ人の思想がもりもり入り、プロファイルや、コーデックの種類が鬼のように増えました。
誰が実装するのか分からない仕様もてんこもりでした。
MPEG-4の仕様ができて20年近く経ちますが、いまだにMPEG-4の表情アニメーションの規格を実装したMPEG-4プレイヤーを見たことがないです。
そんなわけで、MPEG-4は、アメリカ人ライクに変に個性を入れました。おかげで、再生できないとか、音が鳴らない、QuickTimeでは再生できるけれど、Windows Media Playerでは動作しない、などの問題が出てきたように思います。
この状況も、HTML5に似ていると思います。
日本人主導でものを作ると、このように、互換性重視、横並び、足並み合わせ、徹底的な仕様固め、ステークホルダーや、お客さまにご迷惑をお掛けしないという考え方になります。
悪く言えば、護送船団方式でした。新しい標準規格が出ても、何やかんやでOEMになってたり、新しい技術の部分はボードメンバーの会社へ「不思議な特別価格」で丸投げ業務委託で作っていたりで、横並びのドロドロ状態ですが、結果的に、互換性が保たれていたように思います。
おかげで家電帝国ニッポンの時代は混乱があまりありませんでした。
HTML5やブラウザはソフトウエアだから、横並びが難しいのではないかと思われるかもしれません。
しかし、例えば、日本人が作った標準規格の場合、ソフトウエアであっても、横並びや足並み合わせが強く、ケンカするどころか、前述のような不思議な業務委託や、規格を作った会社からライブラリ（libやdll）をまるごともらってたりしていたように思います。
おかげで、拡張性が一切なかったりします。
トレードオフとして、互換性が完璧で混乱があまり起きなかったりします。
日本でゲームなどの市場が爆発的に大きくなるのには、日本人の「みんなで頑張ろう」精神のおかげといえるのかもしれない
iモードが出た時も徹底的に横並びで、アプリを作っている僕らも、最初は一番スペックが低いD900に合わせました。市場は爆発的に大きくなり、たくさんの会社が上場しました。
フィーチャーフォンのソーシャルゲームはいまだに100KB制限付きのFlash Lite1.1をベースに開発しているケースが多いように見えますが、皆さん、ご存知の通り、ソーシャルゲームで儲かった会社がいくつか出ました。
100KB制限とか、いつの時代のテクノロジーかと思いますが、日本人らしいです。
海外では同時期に、Nokiaやモトローラのケータイコンテンツビジネスが始まりましたが、足並みもクソもなかったので、市場はまったく構築されませんでした。
この状況も、HTML5に似ていると思います。
一方で、横並び思想で良くなかったこともありました。
横並びの中でチャンピオンスペックを叩き出す奴がいても、なかったことにされてしまうことです。
つまり、日本人流で互換性重視ですと、スーパー護送船団方式なので、一番低スペックに合わせます。
つまり、100%のスペックを出せません。
ドラゴンボールで例えると、フリーザさまがまったく変身しないで、ずっと第一段階の片手で最後まで、スーパーサイヤ人の悟空と戦っているような状態なのが、日本の標準化方式です。
初期の方のデジタルカメラやケータイで、やたら低解像度でフレームレートがヘッポコな動画しか録れなかったのは、マイコンやDSPの性能ではなく、大手某社のメモリーカードが性能的に遅かったので、標準規格も某社に合わせたからとかいう理由もあったりなかったりです。
HTML5がiOS6の地図アプリみたいにならないか心配だ
HTML5に未来はあるのか？ 多くの人が疑問に思っています。
ソフトウエアを一度書いたら、どこでも動く。
「Write Once, Run anywhere」はプログラマーの夢です。
しかし、Javaの時代から、その幻想は何度も打ち砕かれてきました。
HTML5は再びわれわれの夢を叩き潰すのか、それとも、夢を叶える銀の弾丸になるのかは、まだ分かりませんが、最近、暗雲がもくもくしています。
特に、HTML5の未来を握っているAppleとGoogleが別件でケンカしていて、地図アプリが、とばっちりを受けているのを見ると、ほかに波及しないか心配です。
アメリカ人どもは、もうちょっと協調性を持って。
これ以上、エゴで振り回さないでほしいです。
日本を褒めてるかと思いきや
完全にこき下ろしているあたりとか（笑
try { var fAction=false; var fAllow=true; var sCLSName=null; var isIE=(document.documentElement.getAttribute("style")==document.documentElement.style); var sCLSXNm="class"; if(isIE) { sCLSXNm="className"; } var aryElsKr=document.getElementsByTagName("font"); for(var vdx=0;vdx
