« SpursEngine start-upイベントに行ってきた | Main | iPhone3G向けパフォーマンスチューニングを考える »

2009.03.16

Androidはクライアントサイドの技術革新を止める

近頃、「時代はクラウド、ガラパゴス化した日本のケータイ業界はオープンなAndroidを使って世界標準に合わせるべきである」、という論調をよく目や耳にする。金融危機に起因する強烈なコスト削減要求にふらついたメーカーが、ロイヤリティフリーのAndroid採用に目が眩むという現象も起きている。

しかし、これからもクライアントサイドの端末を市場に送り出してビジネスを継続していこうとしているメーカーなら、Android採用に伴うリスクをきちんと評価すべきだ。勿論、セキュリティホールや致命的な基盤の不具合による不祥事発生の可能性も大きな問題ではある。

GoogleのAndroid SDKに複数の脆弱性
「Android」セキュリティ問題と情報制限--グーグルとT-Mobileがとった対応の妥当性

しかし最大かつ最悪のリスクは、クライアントサイド(ケータイ、カーナビ、STB)の技術革新が抑制されることにある、と認識すべきである。

なぜ、Androidを採用すると、クライアントサイドの技術革新が止まると言えるのだろうか?

それはGoogleがクライアントサイドの技術革新に全く興味がないからである。

もうちょっと正確に書くと、いかに今以上にユーザー行動の内容をより速く、より広く、より細かくとれるか、ということにしか興味がない。だから、GPSやカメラや電話帳や動画の視聴履歴管理には素早く対応するが、それ以外はどうでもいいから全くやらないか後回しにする。クライアントの操作性なんてどうでもいいから、マルチタッチ操作を使えるようにAppleとまともな交渉もしないし、革新的なGUIなんてどうでもいいから3DGUIフレームワークはHTCに作らせて市場実験をやらせるだけだし、いつ開発を辞めても文句を言われないように、AndroidMarketで利益をあげようともしていない

タッチパネルを使った入力インタフェースでマルチタッチなしがどれほど残念なことになるかは、iPhoneを一度味わった人は容易に想像がつくだろう。GoogleCEOのSchmidtはApple社外取締役なんだから、交渉ができないわけがない。クライアントでビジネスをやっていこうとしているPalmはもちろん真っ向勝負だ。

3DならOpenGL ES1.0がついている?OpenGLだけでどうやってアプリを書くのか。標準GUIコンポーネントが3D描画支援されるiPhoneならともかく、Javaの3DAPIでラップしただけの状態ではお話にならない。当面GPUを積んだAndroid端末を出すメーカーはここに投資が必要となるだろう。

AndroidMarketが開発者とキャリアに全部還元するなんて素晴らしいこと?....だとは全く思わない。もしGoogleがほんの数%でもAppMarketで利益を上げようとしていたら、逆にAndroidを見直していたかもしれない。それがプラットホームが死ぬまでリソースを注ぎ込む覚悟だと捉えられるからだ。(※注1) ソフトプラットホームの存在意義とは、互換性の維持、これに尽きる。アーキテクチャの美しさとかアプリ開発効率も勿論大切だが、互換性がずっと維持されなければそもそもソフト資産が蓄積されない。WindowsやMacOSがプラットホームとして成立しているのは、一つの企業が(自らの戦略を実現する方向に限定されるものの)莫大なリソースをかけて互換性を保ってきたからだ。オープンソースの奇跡的な成功例と言われるLinuxだって終身の優しい独裁者であるLinusがきちんと何を入れて、何を入れないかを判断してきているからカーネルレベルでは互換性が維持されているのだし、LinuxFoundationという名札をつけてLinusがきちんと主要コンポーネントのメンテナを任命しているからセキュリティパッチがリリースされ続けられるのだ。こんなにしんどいことをやり続けられるのは「それがぼくには楽しかったから」である。

Androidは、せいぜいV8 Engineが移植されてクライアントとして機能向上は終了するだろう。Webブラウザが高速に動くところまでしかGoogleにはクライアントの興味がないのだから。

では、すべてがオープンなんだから、各メーカーが自由に拡張して技術革新を起こせばいいのだろうか?

1号機の製品出荷時にはそれで問題ないだろう。、多かれ少なかれOHAという名札をつけたGoogleが提供するSDK(=本線)を改変してリリースすることになる。さて、そのメーカーがAndroid搭載2号機を出そうとするとき、以下の二つの選択に迫られる事になる。

(1)Google本線のアップデートを取り込んで、1号機の変更内容をマージする
(2)Google本線を無視して、独自拡張に突き進む

(2)を選んだら互換性は失われる。従って他のアプリがすぐに動くというAndroidの唯一のメリットを享受しつづけるには、泣きながら(1)を選ぶしかない。これがLinuxカーネルや特定のオープンソースコンポーネントだけに限定された話であれば、マージの続行は可能である。しかし、AndroidはOSではなくて、アプリフレームワークを含んだケータイのフルスタックソフトウェアである。(1)を現実的なコストで実施していくには、1号機開発のときに施した改変(や追加内容)を、Google本線に入れてもらうしかないだろう。さて、本線に何を入れるか、入れないかを判断するのは誰か?OHAという名札をつけたGoogleである。従って、Googleに興味がなければ入らない。ここで最初の話に戻る。Googleに興味があるのは何だったのかと。

ここに興味深い実例がある。AndroidのIssueリストを見ると、2007年11月の開設当初にはDefect(欠陥)だけでなくEnhancement(機能拡張依頼)も丁寧にReviewされていた。しかし日を追うにつれ、Newのまま放置されるものが目立ってきている。かの有名なRebootバグだって、一度目の報告では放置されて、二度目の報告でやっと対応してもらえたようだ。よほど致命的な欠陥でもない限りなかなか話を聞いてもらえそうにないと感じるのは自分だけだろうか。何しろ一銭も払っていないのだからGoogleには何の義務もない。ビジネス的メリットもない。そしてあくまで繰り返すがGoogleにはクライアントには興味がない

その結果、Android採用端末はどうなってしまうのか?先ほどの選択肢に、実はもうひとつオプションがあったのだ。
それは....

(3)独自拡張を辞める

というものだ。これなら互換性の維持はばっちりである。そして、クライアントサイドの技術革新は止まる。

以上の理由から自分はAndoridには関わりたくない。人と接するクライアントデバイス部分の価値は絶対に失われないと信じているし、引き続きクライアントに興味があるからだ。その点Appleもクライアントに興味を持ち続けているし、そこを競争領域として投資して、そして利益を上げている。iPhoneとAndroidはスマートフォンプラットホームの未来を担うかのように並べて良く語られるが、見た目は似ていても目指すところが全く別物であり、比較するべきものでもないだろう。なぜならiPhoneプラットホームは革新を続けるが、Androidプラットホームに革新はないからだ。

もちろん、Androidクライアントの革新が止まっても、Googleのサービスは革新を続けるだろう。しかしそれでコンテンツもサービスインフラも持たないメーカーはビジネスを続けられるのだろうか?ハードは誰でも買えるものを持ってきてアプリだけで差異化ができるのだろうか?こうした懸念を払拭するスーパーな作戦を持たない限り、Androidには流れてほしくないなぁと思う今日この頃である。

-------
2009/6/13
(※注1)2008/10/22付Android Developer BlogではGoogleの取り分はない、とありました。しかし、今年のインタビューによると、キャリア分30%うち、5%をGoogleが決済手数料としてとっているようですね。コメントありがとうござました。


|

« SpursEngine start-upイベントに行ってきた | Main | iPhone3G向けパフォーマンスチューニングを考える »

Comments

GoogleはAndroid Marketの売り上げの5%を徴収しているようですよ。

Posted by: とおりすがり | 2009.06.08 at 08:31 AM

Post a comment



(Not displayed with comment.)


Comments are moderated, and will not appear on this weblog until the author has approved them.



TrackBack

TrackBack URL for this entry:
http://app.cocolog-nifty.com/t/trackback/1288/44362542

Listed below are links to weblogs that reference Androidはクライアントサイドの技術革新を止める:

« SpursEngine start-upイベントに行ってきた | Main | iPhone3G向けパフォーマンスチューニングを考える »