よく「日本の携帯キャリア構造を垂直統合と言われるがAppleこそ垂直統合ではないか」「Appleは日本のケータイ業界を参考に垂直統合戦略を組み立てた」などという人がいる。
しかし個人的には果たして日本のキャリア構造とAppleの戦略を同一視し、更にはそれを理由に日本のキャリア構造について肯定的に捉える(または言い訳に使う)論法には反対だ。
また更にはそれをして「勝てば官軍、負ければガラパゴス」とまで拡大解釈する向きもあるようだ。
ここではその「Appleこそ垂直統合・ガラパゴス」主張について反論をしてみようと思う。
IS01がAndroid1.6からバージョンアップされないことになってちょっとしたお祭りになった。
そもそも0円端末/8円運用が注目されていた矢先の発表で余計に注目を集めることになったことだろう。
しかし0円で買った人はともかく、発売直後にそれなりの価格で買った人も大勢いたはずで、2.1への移行に期待していたとしたらそちらの方がよほどショックなことだっただろう。
OSバージョンアップが出来ない、という残念な決定は別に国内メーカーに限らず、HTCでもMotorolaでも実は海外勢でもあることだ。ソニエリのXperiaが1.6から2.1へのアップグレードに半年ほどかかりユーザーをヤキモキさせたのも記憶に新しいところだろう。
こうした理由は単純に新しい今後のOSの求める性能や機能などが原因でそのハードウェアでは対応できないという理由が大半だとは思うが、一方で日本メーカーには今後更なる足枷となる原因が潜んでいるとも思う。それが「ガラケー機能」の搭載だ。
一般にこれまでキャリア各社は「始めにハードありき」のサービス展開を目指してきたと言える。着うたもそうだし、また「ガラケースマートフォン」の標準機能となりつつある、おサイフケータイ・ワンセグ・赤外線通信も当然そうだ。
しかしその前提はスマートフォンの登場と浸透で徐々に崩れ去ろうとしている。
OSと開発環境はGoogleが準備し、Android端末における基本的なハードウェアスペックの範疇のようなものも国際的に熟成されつつありこれを外れる調達と製造のコストは馬鹿にならなくなるだろう。
その上上記のような「最新OSへの対応速度」というものが端末やメーカー/キャリアの魅力に付加されるようにもなってきた。
当然特殊なハードウェアを国内機に限って使い続ける限り国際調達力はつかないし、ハードウェアと最新OSに合わせたドライバー・アプリ開発は製品開発サイクルの冗長化つまり競争力の阻害を招くだろう。
ルールは変わった。ならば対応もそれに応じて変わらなければならない。
そこで僕の考えはこうだ。ガラケー機能は今後如何にハードウェアから脱却できるかが今後も生き残れるかどうかの鍵となる。
例えばおサイフケータイ。既報の通り、海外勢では同等の機能を目指してNFCにより近接無線通信を行うことになるだろう。またハードウェア的にも日本のように端末内部にFeliCaのようなハードを仕込むのではなく、SIMカードに内蔵させる方向であるらしい。Androidではすでに次期バーションでの採用が決定しており、またiPhoneでも同様の対応がされると聞く。
おサイフケータイの機種変更時の煩わしさは誰もが経験して評判も悪いところだが、それは端末本体に機密情報を格納するという方法を取っているからだ。これがSIMカードに変われば理論上は単にSIMを入れ替えるだけでおサイフケータイ機能も含めた機種変更が行える。よくよく考えるまでもなくこちらの方がメーカーにとってもユーザーにとっても合理的だし日本では何故その方法が取られなかったのか非常に不思議だ(というか、恐らく単純にFeliCaを売りたかった都合なのだろう)。
この場合端末にとってはSIMカードとのインターフェースさえ定義されていればいい。そしてそれは恐らくOSが吸収することになるだろう。機種ごとのドライバーなどは必要なく、あとはおサイフケータイを利用するアプリのみが開発され続ければよい。
もちろんNFCをベースとしたビジネスモデルがどうなるのか、どのような普及をするのかはこれからの課題だ。
しかし例えば一例を挙げれば、海外ではすでにこのようなサービスも登場しつつある。
簡単に言えばこれはおサイフ機能をローカルからアプリそしてネット側へ移行しようという発想だ。そしてこれらのビジネスモデルが世界を席巻し始めた時、iDやEdy、Suicaなどが如何に日本で普及していようと果たしてそれに抗い続けることは可能だろうか。
日本のおサイフケータイはほとんどがローカル機器での通信にて取引を完結させる発想を持っている。もちろんよい面もある(プライバシー保護など)が逆に言えばそれをすべてクラウドで完結させるサービスが登場すればそれほどの競争力を保ち得ないのではないかと思う。
オフィス製品や大規模なERP製品が今まさに徐々にクラウドサービスに吸収されつつあるように同じことが起こりえるのではないか。
その足かせとなるのがやはりハードウェア依存ということだ。ここから如何に脱却しネットワークへ主軸を移し端末依存を止めキャリアやメーカーの壁を脱却しない限り、そもそもおサイフケータイの各サービスは生き残れるかどうかの瀬戸際に立たされることだろう。
ワンセグについて、実は理論的には最も対応は簡単だ。ワンセグ放送のIP再送信を認めればよいだけだ。そしてそれを再生できるアプリを搭載する(マーケットから自由にダウンロードできる)だけだ。
そもそもワンセグ放送は携帯キャリアというよりは総務省と放送業界の強力な後押しで始まったに過ぎない。そしてデジタル放送始めIP再送信を阻んでいるのは通信と放送の分離政策および著作権行政だ。(放送法上一部の免許では特定地域にしか放送できない、などの制約がありボーダーレスなIP通信と馴染んでいない)
この問題はいつも多数の受益権者が絡みなかなか進展しないが、例えば既に海外のテレビ局が次々と行っているようにオン・デマンド放送を、しかも海外拠点から日本向けに行う企業が出てきたら果たしてどうなるだろう。インターネットには国境は無くまた日本の電波法・放送法を盾に海外の企業へ影響力を及ぼすのは国際司法上かなり無理があるだろう。
とは言え必ずしも悲観すべき状態ではなく各種実証実験なども細々とではあるが行われているようだが、大きな判断を速く下さなくてはこの分野さえ海外勢との競争に苦しむ事態に陥ることだろう。
赤外線機能に関して、逆説的だが果たして「赤外線機能が欲しい」と考えるユーザーは果たしてどれだけいるのだろうか。そう、ポイントはそこではない。ユーザーは赤外線機能ではなく、「アドレスの交換機能」が欲しいだけだ。
特別なハードウェアからの脱却という意味では、赤外線センサーを使用する必要性は全くない。例えばBluetoothなどを用いてアドレス交換を行うアプリも広く知られており、QRコード読み取りというのも一つの方法だろう。
従来のガラケーとの互換性という意味では最近のガラケーでもBluetoothは一般化しつつあり、逆にガラケーにそうしたアプリを搭載するのも一つだろう。
そしてまたAndroidやiPhoneもそうであるようにそもそものアドレス帳機能はローカルに隔離されているよりもクラウドで管理され複数の機器で共用できる方がよっぽど便利だ。この分野も単に赤外線機能などに止まらず、いかにクラウド対応を推し進められるかがポイントとなっていくだろう。そしてやはりまたそれはガラケー自身においても同様である。
何故このような極端に見える(かも知れない)サービスの再編が必要なのか。ハードウェア依存が「悪」なのか。それはスマートフォン、そもそもモバイル機器が宿命づけられている「ネットワーク親和性」故だ。
これまでキャリアがすべてのサービスを決める「牧歌的な」時代であればサービスがハードに依存していようとアプリだろうとクラウドだろうと関係なかった。しかしそうしたコントロールが行えなくなることは端末一体の訴求力をサービスやクラウド連携と言ったネットワーク指向性の高いサービスへ移行せざるを得ないことになる。でなければ既に述べたようにハードが足枷になり競争力の低下とサービス品質の低下を招くだけだ。
「日本発」のこれら「特異な」サービスは遠からず市場からの撤退を迫られることだろう。実際、例えば着うた/着うたフルはスマートフォンの浸透に伴い徐々にそのプレゼンスを無くしていくことだろう。それを見越してかLISMOなどのサービスはアプリとして再編されだしているように思うが、それがAndroidマーケットでの楽曲販売やAmazonのDRMフリーサービスあるいはiTunesStoreなどとどこまで同じ土俵で戦えるかはまだ未知数だ。何しろLISMOなどはそのキャリアでしか使えないのだから。
それを防ぎたいのであるなら、如何にこれまでの端末・回線・サービスの不可分一体サービスをクラウドへのみに移行していけるかにすべてはかかっているのだと思う。
だが果たしてこれまでの既得権を守りたいだけのキャリアや業界がそれを理解できるか。成功体験に浸りすぎた業界が「イノベーションのジレンマ」を自力で克服できるだろうか。
もしかするとようやく理解できた時には、既に日本としてのメリットは何もないサービスばかりが日本国内を席巻した後かも知れない。
実はしばらく前にTwitterのTLで流れてたのを見て触りだしてからはまっていたので、最近の盛り上がりは嬉しく思います。なんたって一時期は日本でTi mobile使ってるのは数人ぐらいしかいないんじゃないかとか思ってたぐらいなので。
へえまだアルファブロガーっているんだぁと思った次第。
実は既にそれなりにまともなiPhoneとAndroidアプリをTi mobileで作ってそれぞれAppStoreとAndroidマーケットで公開していたりします(本名で出してるからここでは紹介しない)。
ということで僕も別にそんな経験あるわけではないけど使っていて感じたこととかつらつらと書いてみますよ。
因みにTi mobileの日本での先駆者と言えばまとめサイトも作られてるdonayamaさんとかyuichi_katahiraさんとかですかね。また Yuichiro MASUIさんはAdMob用など幾つかiPhoneモジュールを公開されていらっしゃいます。
僕の経験で言うと一週間でiPhoneアプリは出来てしまったんですがそこからAndroidに対応させるのに二週間かかりました。原因はAndroidでのバグ？らしき挙動とiPhone版さの差異のためです。
iPhone版は非常に優秀でJavaScript好きの人ならさらさらと簡単にアプリを作れてしまうと思います。ただそれと同じつもりでAndroid版に拡張し始めると要領があまりに違っていてかなりはまりました。
例を挙げると、何故かiPhoneでは当たり前に取得できるresponseXMLがAndroidではRSSフィードによっては文字化けしたり(結局最後まで原因はわからず、responseDataを使ってパースした)、windowのxIndexがwindowのlayout指定によって順序が異なったり、WebViewで取得したHTMLは外部からは取得できなかったり、windowのblur/focusイベントは動作しなかったり･･などなど。
「iPhoneとAndroidでは画面サイズとかが異なるからコードを分けないといけなくなる」程度の話が流れていますがそれどころではないです。僕はかろうじて同一レポジトリに閉じ込められましたが、現時点ではコードの規模によっては別々に開発することも考えた方がいいこともあるでしょう。
Titanium Developer製品(Ti mobileはその一環)はOSSで開発が進められているのですが、チケットを見てもAndroidのissueは多いように見えます。
まだまだ開発途上の製品なのでそれにうまく付き合えるかどうかがポイントになります。
恐らく先のAppleによる「AppStoreからの開発ツールの締め出し」騒動に関係していると思われますがiPhone版ではコンパイル時にネイティブコードに変換します。対してAndroidではJSエンジン(恐らくGoogleのV8？)でリアルタイムにインタープリターもしくはJITで実行しているようです。つまり解釈されるエンジンが異なるのです。これが前項の原因でもあり、また両者での違いを経験から読み取っていく必要があるでしょう。
僕もTi mobileを一番気に入っているのはメモリ管理を気にしなくて良いと言うこと。特にiPhoneでは顕著ですよね。しかし一方ではそれはメモリリークなどの管理をできないということも意味します。
開発元のAppceleratorでは「メモリリークはうまく回避しているよ」と言い切っていますが 実際に試してみると細かなメモリリークは発生し得るようです(特にネットワーク周り)。
あまり問題にはならないレベルとは思うのですが、JavaScriptに書き慣れていないとGCを意識できずオブジェクトを残し続けてしまいがちです。ブラウザでもよく話題にはなるのですがかなり巨大なコードにならないとあまり気にしない部分かと思います。しかしTi mobileではGCを意識した変数設計をしておかないと簡単にメモリを食い潰すアプリができてしまいます。
こういう時は逆にGCに頼るのではなく自由にメモリ管理も出来る仕組みがあるといいですね。
これはAppceleratorが基本的にはOSSで無償で提供しつつビジネスとしてサポートを有償にしていることと関係していると思うのですが、ドキュメントがあまりに杜撰です。
そもそも返値とパラメータが全く異なっていたり(多分コピーミスなど)、ドキュメントだけではちょっと複雑な仕様を実装しようとすると悩むことが多いかも知れません。
他の方もおっしゃっているように、APIドキュメントよりもサンプルアプリであるKitchenSinkを最大限利用しましょう。特にiPhoneとAndroidの実機に実際インストールして動作を確認することをお勧めします。
またドキュメントはあまり参考になりませんが、ディスカッションフォーラムは割と参考になることが多いです。凄く盛り上がっているとは言えないけど みんな同じ事で悩んでいるのです。
Ti mobileでもiPhoneとAndroidのすべての機能に対応しているわけではありません。また世には様々な便利なライブラリが公開されていますが、当然それらはObjecive-CやJavaで書かれています。Ti mobileにはそれらネイティブコードを取り込むための「モジュール」という仕組みが用意されているのですがそのためにはObjective-CやJavaでもコードを書けなければなりません。更に言えばiPhoneやAndroidでどのようにアプリを開発するかの知識が必要です。
因みに僕は広告を掲載したかったのですが当然Objective-CやJavaのライブラリやサンプルしか提供されていないので、独自にiPhoneとAndroid用にモジュールを作成しました。広告程度なら表示するだけなのでそんなに難しくないです。但しiPhoneやAndroidの経験がないとかなり難しいと感じることでしょう。
なのでTi mobile自体は単に「Objective-CやJavaを知らなくてもJavaScriptを知っていればiPhone/Androidアプリを作れる」ツールなのではなくて、まずはやはりiPhoneやAndroid開発をある程度経験してからの方が相応しいツールなのではないかなぁと思います。
先に述べたようにTi mobileはOSSとしてすべてのコードが公開されています。実際現時点でのコードをgithubから取得して自分でコンパイルして使うことも出来ます(Androidの拡張モジュールはそのようにして開発します)。
なのでどうしてもバグなのか仕様なのか回避のしようがなかったら最後はコードを読んでみることをオススメします。
個人的な例では、どうしてもAndroidの実機で位置情報が取得できない問題がクリアできなかったのですが、コードを読んでみるとgetLastKnownLocation()のみで取得していることが分かりました。これは時々ディスカッションでも話題になっていますが初回には位置情報は取れないのです。
ということでプロバイダーをNETWORKにして回避したのですが(これはこれでどうかと思いますが)、こういう部分もOSSとして提供されている利点であり、活用しない手もないでしょう。
といったところでしょうか。
何やら文句と愚痴が多くなった気もしますが(笑)、個人的には大変気に入っています。特にJavaScript好きには堪らないツールとなることでしょう。
一方で「初心者でも簡単にiPhone/Androidアプリが作れる」風のイメージには疑問を感じていて、どちらかと言えば現時点でiPhone/Android開発をバリバリされてらっしゃる方にこそ効率を上げるためにぜひオススメしたいツールです。
まずは使ってもらって、少しでも日本で広まるといいなぁ。
Kogan Agoraが互換性の問題のために発売を無期延期だそうです。
オーストラリアのAndroid携帯「Kogan Agora」、発売が無期延期に
初めての3G Androidだったのに、残念ですね。。
特に日本人では楽しみにしていた人も多かったのでは。
発売まであと数日というタイミングでは、Kogan社も苦渋の選択だったことでしょう。
問題の詳細はよくわかりませんが、スペックが標準に合っていなかったみたいですね。
Mobile Gazetteでは実質的にキャンセルだろうと伝えています。
SIMフリーのAndroidスマートフォンとか、T-Mobile G1がSIMフリーになって開発者向けに日本でも購入可能になったりとか、徐々に日本でもAndroidが話題に上がることが多くなってきましたが、海の向こうではAndroidとWindows Mobileのダブル対応スマートフォンだそうですよ。
QiGi i6 – Windows Mobile and Google Android in one phone (via 英国だったじぃ)
残念ながらGSMオンリーだそうですが、プロセッサーは624MHz動作、256M ROM + 128M RAM、GPS搭載とまあまあのスペック。
まあ、面白い以外のメリットは見えにくいですが(笑)、さくっとこんな携帯が出てくるところは、Androidはコモディティ化も早いんでしょうね。
知らなかったんですが、HTC Touch HDでもAndroidは動作可能だそうです。
どうも現行のWindows Mobile機とは相性もいいみたい。
Androidがまず目指すマーケットはWindows Mobileになりそうですね。