Life is beautiful

最近、UIEvolutionのビジネスが、単なる「テクノロジーのライセンス・ビジネス」から、「プロトタイプの構築」や「おもてなし設計」ビジネスにシフトしている。一昔前は、「UIEngineのJavaに対する優位性を説明して欲しい」などの技術的な問い合わせばかりが多かったが、最近は「○○向けのデバイスを作っているんだけど、おもてなしの設計の段階から手伝ってくれないか」という話が増えているのだ。「おもてなし設計」の重要性が業界でようやく理解されて来た兆候だと解釈している。

そこで今日は、そんな傾向をさらに押し進めるために、スマートフォン・タブレット・家電などの組み込みデバイスの開発における「おもてなし設計」の重要性の話。

ここのところ「Androidタブレットはヨドバシカメラの「Androidタブレットコーナー」に横並びにされた時点で負けだ」「なぜ横並びで展示されるAndroidタブレットを作ってもだめな」などのエントリーで、横並びのAndroidタブレット戦略を批判している私だが、決して「だから日本のメーカーはタブレットなど作っても仕方がない」と思っているわけではない。

私が批判しているのは「うちもメーカーとしてタブレットを出さざるを得ない」「他のメーカーもAndroidを採用しているのだからうちも乗り遅れるわけにはいけない」などの消極的な発想でのもの作り。そんな考えでは、アップルに勝つどころか、「その他大勢」の一員として生き残ることすら難しい。その点に関しては、「とある家電メーカーでの会話：クラウドテレビ編」「もし日本のメーカーが iPhone を発売していたら..」を読んでいただければ伝わると思う。

ちなみに、後者の「もし日本のメーカーが iPhone を発売していたら..」は、アップルと日本のメーカーの「売り方・マーケティングの仕方」の違いを指摘したものではなく、もっと根本的な「もの作りの姿勢」の違いを指摘したものである点に注目して欲しい。「ユーザーにどんな体験をして欲しいか」「人々のライフスタイルにどんなインパクトを与えたいか」をまず最初に考えた上で、そのための手段としてカメラやGPSやタッチセンサーを搭載して来るアップルの製品と、「ヨドバシカメラで横並びにされた時に、機能比較表で他社の商品に負けたくないから」「社内の稟議を通しやすいから」と機能をてんこ盛りにしただけの製品では、最終的な製品の「ユーザーに与える価値や満足度」で大きな差がつくのは当然。

では、いったいどうやったらアップル製品のような「おもてなし」を提供できるのだろうか？簡単な話ではないが、ここで具体的な提案をしてみたいと思う。

1. まず一番最初に考えるべきなのは「ユーザー」

まず最初に認識すべきなのが、「世界最高のAndroidタブレットを作ろう」とか「iPadキラーを作ろう」という姿勢や考え方そのものが根本的に間違っているということ。そんな風に業界内部やライバル会社ばかり見ていたのでは決して良いものは作れない。一番に考慮すべきなのはユーザーである。「どんな風に人々のライフスタイルを変えたいか」、「どんな価値を人々に提供したいか」、それをまず最初に考える必要がある。

私の好きなゴルフに例えるのであれば、「iPadキラーを作ろう」という姿勢は、「タイガーウッズよりも良いスコアで回ろう」とタイガーウッズのショットやスコアばかり意識してゴルフトーナメントに挑む事と同じである。「世界最高のAndroidタブレットを作ろう」という姿勢は、「いま流行のハイブリッド・チタン・ドライバーでドライバーを誰よりも遠くまで飛ばそう」という姿勢に相当する。

そんな姿勢では、決してトーナメントに勝つ事はできない。優勝を目指すゴルファーが一番注目すべきは、ライバルでもクラブでもない、ゴルフコースである。コース・レイアウトに応じた戦略を立て、グリーンを読んで、コースを克服して良いスコアを出してこそ、優勝の栄誉は与えられる。

最新のクラブや距離の長いショットは良いスコアを出すための「道具」「手段」でしかなく、タイガーウッズより良いスコアを出す事は、コースを克服した上で得られる「結果」でしかない。

デバイスの開発に関しても全く同じことが言える。「iPadキラー」を作ることばかり意識してはユーザー不在のもの作りになってしまう。「世界最高のAndroidタブレット」を作ることばかり考えてしまうと、本来は「道具」の一つでしかないAndroidやマルチコアCPUが「目的」にすり替わってしまう。

２. ターゲットを絞る

漠然と「ユーザー」と言っても狙いが定まらないので、「どんなユーザー」に「どんなシナリオ」で「どんな価値」を提供したいか、絞り込んで考える。具体的であれば具体的である程良い。たとえば、

• 「学校の先生」が「授業をする時」に「一人一人の生徒の理解度に応じた教えた方ができる」ようにしたい
• 「医者」が「患者の診察をする際」に「効率良く過去のデータにアクセスしつつ、必要に応じて患者に分かりやすくチャートや画像で説明できる」ようにしたい
• 「飛行機の整備士」が「限られた時間で飛行機の点検をする際」に「分厚いマニュアルを抱えずに、どんな姿勢でも簡単に効率良く整備ができる」ようにしたい

などである。

まずはこんな風にユーザー・シナリオをいくつか考えた上で、それぞれのシナリオに対して、「そのマーケットがどのくらいの大きさか」「その価値に対してユーザーは対価を払うかどうか」「そのマーケットにはiPadのような汎用デバイスと、そこに最適化した専用デバイスのどちらが適しているか」「そのマーケットで勝負する上でなにか自分だけが持っている有利なものはあるか」を考えつつ、戦略を絞り込んで行く。

３. プロトタイプを作る

ターゲットを絞ることができたら、次にするべきことは（製品化に必要な予算を確保するための稟議を通すのではなく）プロトタイプ作りである。今は、「どう作るか」よりも、「何を作るか」「どんな価値を提供するか」の方がはるかに難しく重要な時代である。そのためには、できるだけ短期間でプロトタイプを作り、ターゲットユーザーに使ってもらって「その商品に価値を見いだしてもらえるか」を試しつつ「おもてなし設計」をすることが大切だ。本格的な開発に必要な予算の申請は、プロトタイプを作る過程で「十分な価値が提供できる」と確信できてからするべきだ。

この段階では、当然だが「OSを何にするか」とか「CPUは何にするか」は全く重要ではない。大切なことはユーザーが対価を払うぐらいの価値がある「おもてなし」を生み出すすることだ。この「おもてなし設計」にかける時間と労力と信念こそが、アップルをポータブル・ミュージック・プレーヤー、スマートフォン、タブレット、ノートパソコンの４つの市場で他社を大きく引き離すブランド力と収益力を持つ会社にしていることを忘れてはならない。

別の言い方をすれば、この段階でユーザーにとっての新しい価値を生み出すおもてなし作りが出来るかかどうかが、商品が市場で成功できるかどうかの最も重要な役割を担っているのだ。それができなければ、どんなに開発費をかけようと、どんな高速なCPUを載せようと、どんなに部品を安く買いたたいて製造原価を安くしても、ヨドバシカメラで横並びにされてスペック競争と価格競争の消耗戦に巻き込まれるだけだ。

ちなみに、トヨタによる採用が決まったUIEngineも、もともとは「組み込み機器向けのプロトタイプをサクッと作りたい」という発想の上に作った開発環境である。組み込み機器・家電の場合、プロジェクトスタート時にはハードウェアが存在しないのが当たり前。そんな状況で、ハード→ドライバー→OS→アプリ、という順番に悠長に作っていては、一番大切な「おもてなし設計」に時間を裂く事ができない。そこで、CPUやOSに依存しない形で並行してユーザーインターフェイスの設計・構築できる環境を用意し、そこで十二分に「おもてなし設計」に時間をかければより良いものが作れる、というのがその設計思想の根底にある。

少し長くなってしまったが、日本のメーカーもそろそろ「横並びスペック競争」から脱却して、本気で「おもてなし」重視のも作りにシフトするタイミングが来ていると思う。どうせ出しても儲からない「横並び汎用Androidタブレット」は低価格を売り物にしたアジアのメーカーに任せて、付加価値の高い商品作りでと「おもてなし」で勝負すべきだ。

先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。

    https://github.com/snakajima/SNBinder

SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。

９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。

その方向性を究極にまで突き詰めると、サーバー側は（MVCのModelとして）JSON over HTTPのAPIだけを提供し、ユーザーとのやりとりはJavaScriptが（Controllerとして）１００％担当する "ピュアAJAXアーキテクチャ" （参照）になる。

このアーキテクチャは、利点としては、

• サーバー側とクライアント側がAPIで明確に分離された疎結合になる
• ブラウザーとモバイルアプリ（例えばiPhoneアプリ）でAPIを共有できる
• デスクトップ・アプリのような使い勝手（おもてなし）を実現することが可能になる

などがあるが、一方では、

• サーチエンジンがアプリ内の個別ページを見つける事が出来ない
• ページへのパーマリンクを張ることが出来ない

という性質（用途によっては欠点）がある。つまり、先に挙げたGMail、Google Docs、Facebookのような、個別ページをサーチエンジンでクロールされる必要のない（もしくはして欲しくない）、ユーザーごとに異なるデータを表示したいアプリ（パーソナルアプリ、ソシアルアプリ、グループウェア、業務アプリなど）に適している。

そんなアーキテクチャのアプリを実現するには、上に書いた通りブラウザー上で View（HTMLテンプレート）とData（サーバーから取得したJSONオブジェクト）の結合をする必要があるが、それを担うのがこの SNBinder である。

詳しい使い方は、READMEを読んでもらうのが一番だが、簡単に解説すると、

    var template = "<p>Hello, $(.name)!</p>";
    var user = { "name":"Leonardo da Vinci" };
    $('.body').htm(SNBinder.bind(template, user));

とすることにより、"<p>Hello, Leonardo da Vinci!</p>"というHTMLを生成する、というのがSNBinderの役目。実際のアプリではテンプレートもJSONオブジェクトもサーバーから取得するので、

    SNBinder.load_named_template("/static/templates.htm", function(templates) {
        SNBinder.get("/user/info", nil, true, function(user) {
            $('.body').htm(SNBinder.bind(templates("main", user));
        });
    });

のように書く事になる。

SNBinderを使った具体例としては、Facebookユーザー向けのグループウェア Fruence が公開済みなので、興味のある方はそちらのソースも参照していただきたい。

ライセンスはMITライセンスで、私のコピーライト表示を含んだヘーダーを維持したままであれば再配布も変更も自由にしていただいてかまわない。

【追記】試していただいた方から２、３の不具合がレポートされていたので（参照）、修正したものをGitHubにあげておいた（バージョンナンバーは同じ）。変更点は、

• 一カ所、IEで不具合を起こすtrailing commaがあったのでこれを削除
• JSONを自動的にパースするjQueryの最新版（1.4.4）でも動く様に修正
• グローバル空間を汚していた debug という変数を封じ込めた
• READMEのタイポを修正

の４つである。最初のうちはIEでもテストを繰り返していたのだが、最近はすっかり安心して Safari/Firefox/Chrome上でのテストで十分と甘く見ていたのがいけなかった。あと、jQueryは1.3.2以来アップデートしていなかったので、ある時点で$.ajaxがJSONを自動パースするように変更されていたとは知らなかった。

ちなみに言い忘れていたが、ローカルな環境（localhost://8xxx）で走らせると意図的に通信の部分に200msの遅延を挿入している。ローカルならサクサク動くのに、サーバーにアップロードしたとたんに使い勝手が悪くなった、ということを避けるためのものだ。

今年の「書き初め」として作ったFacebookユーザー向けのグループウェアFruence、いくつか細かな機能アップしたので報告しておく。

• 他のユーザーによりプロジェクトに変更が加えられたるとプロジェクトのタイトルを太字で表示
• プロジェクトごとに掲示板をもうけた（プロジェクト内の"Active Threads"）

他にも色々と追加したい機能は沢山あるが、シンプルさを優先して機能を絞るという意味でも、ユーザーの声を聞きながら少しずつ改良して行きたいと思う（リクエストはこのブログのコメントとしていただけるとありがたい）。

ちなみに、クライアント側でHTMLを生成する仕組み（SNBinder）のオープンソース化の準備は着々と進んでいる。今までは Array として扱っていたためにインデックスの扱いが面倒だった部分を、Dictionary に変更したため、テンプレートの変更がとても楽になった。

オープンソース化が待てずに解析を進めている人もいるようだが、最初に見て欲しいのはFruenceで使っているテンプレートファイル。ソースを見ると、

{%}side_bar{%}
<div style='float:left;margin-right:5px'>
    <img src="http://graph.facebook.com/$(.fid)/picture" />
</div>
<div style='float:left'>
    <ul>
        <a id='my_profile' href='#'>
            <li style='font-size:14px;font-weight:bold'>$(.name)</li>
        </a>
    </ul>
</div>
<div style='clear:both'></div>

のようなセクションがいくつか含まれていることが分かると思うが、{%}...{%}で囲まれた部分が各セクションの名前、それ以下の部分がテンプレートである。テンプレート内の"$(.fid)"や"$(.name)"は、その部分を結合するJSONのプロパティで置き換えるべき場所だ。

このテンプレートファイルを前もって読み込んでおき、

$('div#sidebar').html(SNBinder.bind(s_parts['side_bar'], s_myself, 0));

のようにして、サーバーから取得したJSON（この場合は、s_myself）と結合（バインド）させてHTMLを生成して表示する。

少しまえに、技術評論社のWEB+DB PRESSに「独自フォーマット戦略の終焉」というコラムを書いたのだが、それがウェブ上で公開されたので、ここにリンクを張っておく。

言いたい事は一通り書いておいたので、それに関してはそちらを読んでいただくとして、このコラムを書いた後に二つの新たな動きがあったので補足しておく

シャープが海外では ePub をサポートすることに決めたこと

これは当然と言えば当然だが、相変わらず日本国内では独自フォーマットのXMDFという戦略には私は賛成できない。「コンテンツを囲い込みたい」という気持ちも分かるが、コンテンツ・プロバイダーも賢くなっている今の時代、結局は自分の首を絞める事になると思う。それよりも、シャープという会社として、ePubなりHTML5のオープンなスタンダードに日本語特有の機能を実装して行くための人的資源を提供してそこでリーダーシップを取るという戦略の方が、業界全体のためにもなるし、シャープの業界での地位も上がるし、とても良い戦略だと思うのだがいかがだろうか？

前にも書いたが、この業界は「実装したもの勝ち」である。「アメリカ人にいくら縦書きの必要性を訴えても理解してもらえない」と愚痴をこぼしていても一向に改善しない、ePubやHTML5を実装する側に人を送り込んでどんどん実装して既成事実化するのが一番だ。

参考：XMDFの不幸

GoogleがH.264のサポートをストップすることを宣言したこと

Googleは「今の段階で H.264 をHTML5のビデオタグの標準として固めてしまうとイノベーションがストップしてしまう」という理由で H.264 をChromeブラウザーから外すことを宣言したが、これに関しては私も少し首を傾げている。せっかくMicrosoftもHTML5をサポートすることに決めたのだから、まずは H.264 をすべてのブラウザーでサポートして HTML5を（ビデオコーデックも含めて）広めること（ブラウザーの普及率を高める、HTML5を利用したコンテンツを増やすなど）が最優先だと思う。特にビデオコーデックに関しては、ハードウェア・アクセラレータの話もあるので、ユーザーのことを考えればまずは H.264 で手を打っておくべきに思えるのだが。

ただ、深読みすれば、H.264のパテントを持っているグループに対する「ごたごた言わずにパテントを完全にパブリックドメインにしちゃえよ」というプレッシャーを与えているブラフとも受け取れ、それはそれで面白い試みである（ちなみに私は「ソフトウェアパテント廃止」論者である）。しかし、このごたごたでHTML5のビデオタグが広く使われるようになるまでの期間が伸びるのはよろしくないと思うしだいである。

米国では、VerizionがCDMA版のiPhoneを出すということで大騒ぎになっている。今までiPhoneが買えずに我慢していたVerizonのユーザーからの注文が殺到することは目に見えており、しばらくは品薄の状態が続くだろう。Verizonが今年Appleに払う販売奨励金だけで$5billion（日本円で４千億円）にのぼるとの予想も出ているぐらいだ（参照）。

それよりもっと注目に値するのは今までiPhoneを独占してきたAT&T。２６％の現iPhoneユーザーがVerizonに切り替える予定だと答えたというアンケート結果も出ている（参照）ぐらいのインパクトのある話だ。たった一つの端末が、通信事業社の業績に大きく影響を与えるというのもすごい話だ。

ちなみに、Verizonはau(KDDI)と同じ通信方式（CDMA）を使っており、Verizon向けのCDMA版 iPhoneを日本に持って来てauが売るということが技術的には可能になった。Appleとソフトバンクと間に特に排他的契約はないので（参照）、残るはAppleの要求する一端末あたり400ドル（日本円にして３万円超）の販売奨励金を払ってでもauがiPhoneを欲しがるかどうかにかかっている。

ちまたには、すでに「Chinaテレコム（中国）、SKテレコム（韓国）、KDDI（日本）からCDMA版のiPhoneが出るらしい」との噂も流れており（参照）、まさに「第二次iPhone旋風」がアジアに吹き荒れそうな雰囲気がひしひしと伝わって来る。

ちなみに、neuアプリのダウンロードを国別に見ると、１・２番に日本とアメリカが肩を並べており、それに中国、台湾、ドイツ、韓国が続く。特に中国に関して言うと、１２月に入ってからのダウンロード数が急激に伸びており、Appleの中国進出が順調に成功していることが手に取る様に分かる。

今後CDMA iPhoneが韓国や中国で売り出されるとなると、Appleにとっての（そして私のようなiPhone/iPadアプリ開発者にとっての）日本を含めたアジア市場というのがますます重要になってくるんだな、と思う今日この頃である。

先日のエントリー「Androidタブレットはヨドバシカメラの『Androidタブレットコーナー』に横並びにされた時点で負けだ」には、例によって賛否両論のさまざまなフィードバックがよせられたが、否定的な意見の大部分は以下のようなもの。

• 何故負けなのかがあまりイメージ出来ないなあ。描かれている様子はAndroidが盛況を博しているものにしか見えない。
• PCメーカーが「何のためにWintel」と考えてるとは思えないし、スマホやタブレットで「何のためのAndroid」って問いに意味があるとも思わない。
• すでにそんな現状の Windows PC でも一定の利益は出ているのだから、Android タブレットも負けではあるまい。
• 歴史に学ぶとするなら、iPhone/iPad が Machintosh だとすれば、Android機はPC/AT互換機なんだと思う。ただ、「Windowsなのでどれも使い勝手は同じです」 の中であっても、DELL のように成功した会社もあるわけで。
• そうかな？それを嫌ってガラパゴス機能を載せて付加価値をつけようとして開発スケジュールの遅延、アップデートコストの増大を招くぐらいなら、バニラのまま大量生産・低コスト・高品質化を狙ったほうがいいかもよ？
• なんだかなぁ。パソコン見てApple社は機種がMacProとかしかなくて、Windowsは「WindowsなのでOSは同じです」って言ってるのと何か違うの？
• VAIOやDynabookがノートパソコンコーナーにあるのを見て、それらがが負けているとは思いません。

つまり、「今のiPhone vs. Androidという構図は、９０年代前半の Macintosh vs. Windowsの構図と同じ。iOSを他社にライセンスしないというAppleの戦略は間違いで、最終的にはAndroidが勝つ」という意見だ。

実際のところ、Androidをサポートすることを決めたメーカーはたくさんあるし、Android携帯の出荷数もトータルではiPhoneを凌駕しつつある。単に「数が多い＝勝ち」という意味で言えば、Androidは「勝ちつつある」のかも知れない。その意味では、十把一絡げにされてもかまわないから、とにかくAndroid携帯・Androidタブレットを出しておくというのもある意味では「正しい」戦略なのかも知れない。

しかし、どのメーカーも営利企業として存在するのだから、単に数や売り上げを追い求めるのではなく、最終的には株主価値を高める「利益をあげつづけることのできるビジネス」を作り出さなければならない。

そこで、将来のタブレット市場を占う意味でも、「Windowsが勝った」パソコンビジネスにおいて、どの企業が「利益をあげるビジネス」を作る事ができたか、を見てみよう。

これは Business Insider の去年の記事（参照）から引用したもの。世界のPCメーカートップ１０社の２００９年の売り上げと利益のシェアをグラフにしたものだ（ドイツ銀行の調査によるもので、各社のパソコン・ビジネスだけを抜き出して計算したもの）。

売り上げ（青いバー）だけを見ると、トップのHPが１７％、二位のDellが１３％。Appleはわずか７％のシェアにとどまっている。これだけを見ても「寡占化」が進んでいることが良く分かると思うが、もっと興味深いのは利益の方だ（赤いバー）。

売り上げでわずか７％のシェアしか持たないAppleが、トップ１０社の生み出す利益の合計の３５％を持って行ってしまっているのだ。

つまり、９０年代のMacintosh対Windowsの戦いではWindows陣営の圧勝ではあったが、そこで「利益の生み出せるパソコン・ビジネス」を作ることが出来たのはDellやHPなどのごく一部のメーカーだけ、現時点で、パソコン・ビジネスからもっとも大きな利益を出し続けているのは、負けたはずのApple、という皮肉な状況になっている。

もちろん、Appleは一度は倒産寸前まで追い込まれたし、iPod/iPhoneの成功により奇跡的によみがえったからこそ今のMacビジネスがあるとも言えるのだが、それにしてもこの状況は驚異的。付加価値の高い「尖った」商品作りの重要さを良く表している。

今もヨドバシカメラに行くと、「各社Windowsパソコン」が横並びに展示されているが、実はHP/Dell/Acer以外のメーカーはほとんど利益をあげることが出来ていないというのが実情だ。IBMや日立やSharpに続いてさらに何社かがパソコン業界から撤退したり事業売却をしてもおかしくないタイミングだ。

たとえば、東芝の経営陣は最近「選択と集中」という言葉を良く使うが、そこにパソコン事業が選択すべき事業の候補一つとして名を連ねた事は私の知る限り一度もない。まだトップ１０にかろうじて入っている今年あたりが売り時と経営陣も考えているのではないだろうか。

ちなみに、携帯電話市場に関してもすでに同じようなデータが出ているのでここに貼付けておく。

これはGigaomの"theAppleBlog"からの引用だが（参照）、パソコン市場と同じ様に、台数だけを見ると（このグラフには出ていない）Nokia+Samsung+Motorola+ソニエリの上位4社が大半のシェアを持っているが、２０１０年の利益（上のグラフ）を見ると、台数ベースでは３％以下（スマートフォンだけでなく、すべての携帯電話を含むと微々たるものである）のAppleが４８％ものシェアを持っているという状況になっている。

ここまで具体的な数字を示せば伝わるとは思うが、今のままの状況（＝Apple以外のメーカーがレミングスのように足並みを揃えて似たようなAndroidタブレットを作っている状況）でタブレット市場が立ち上がると、Androidタブレットは数ではiPadに「勝つ」だろうけれど、最終的にはパソコン市場や携帯市場と同じような状況（３〜４社による寡占状態、ただし大半の利益はAppleへ）になるのは明白だ。

「逃げ切りメンタリティ」に犯された日本のメーカーの経営陣にとっては、余計な冒険などせずに足並みをそろえて「横並びAndroidタブレット」を出す方が無難で分かりやすい（つまり「稟議（りんぎ）が通りやすい」）戦略なのだろうが、それでは通用しない（＝「利益をあげつづけることのできるビジネス」を作る事はできない）ことはすでに歴史が証明している。

ヨドバシカメラに横並びに展示される十把一絡げの「Androidタブレット」を作るのではなく、ターゲットユーザーを絞った付加価値の高いもの作りで「利益の生み出せるビジネス」を作ることを本気で目指すべきだと思うのだがいかがだろうか。

今年のCESについてだが、すでに「感心した商品」と「自分も関係していてうれしかった発表」に関しては書いたので、今回は「これはだめかな」と思ったもの。

まずその筆頭は「３Dテレビ」。これ以上大きくすることも薄くすることも解像度を高くすることもできなくなってしまった「成熟しきった」デバイスであるテレビに何とか付加価値を付けようという気持ちも分からないでもないが、正直言ってこれはいらない。CESに出品されている最新の３Dテレビを見てもあまり感動しないし、そもそも目が疲れる。今年の末あたりになって、「結局３Dテレビって何だったの？」という話になると私は見ている。

二番目は「Android」。前にも書いたが、これから家電やスマートフォンの市場に新規参入しようというアジアのメーカーにとっては、Androidを活用して短い開発期間と低コストで「安かろう悪かろう」のデバイスを薄利多売で売りまくるという戦略は利にかなっている。問題は、既存の家電メーカーや携帯電話メーカーの「何のためにAndroidを使っているのかが全く見えて来ないデバイス」だ。

確かに、OSを自社開発していたのでは時代に取り残される。マイクロソフトは足踏み状態であてにならない。残る選択肢としてはAndroidを選ぶしかないのかも知れないが、じゃあそのデバイスでどんな価値を提供しようとしているのか、どこで差別化しようとしているのかが見えて来ないデバイスばかりだ。まさに「とある家電メーカーでの会話」に書いてあるような経緯で出て来たんじゃないかと思えるものばかりだ。

「他のメーカーもAndroidを採用したから」「Androidにすれば開発者がアプリを作ってくれるから」「うちとしても、タブレットを出さないわけには行かないから」などの甘い気持ちでタブレットを出してもまず成功しないと思う。

まずはAndroidや第三者のAndroidアプリのことは忘れて、（１）どんな人たちに売りたいのか、（２）どんな価値を提供したいのか、（３）どうやってiPadと差別化するのか、（４）どうやって他のAndroidタブレットの中で埋没せずに目立たせるのか、を徹底的に考えた上で商品作りをすべきである。

ヨドバシカメラの「Androidタブレットコーナー」に置かれて、「機能一覧」だけで横並びに評価されて、「A社のタブレットは、B社のと比べてカメラの解像度が1.5倍でメモリも2倍です。その分、１万円ほど高くなりますが。ちなみに、Androidなのでどれも使い勝手は同じです」と売られるようでは負けだ。

参考文献：もし日本のメーカーがiPhoneを発売していたら

去年の６月にneu.NotesをiPad向けにリリースして以来、neu.KidsDraw、neu.Draw、neu.Annotate と立て続けにリリースして来た "neu" シリーズ。今年こそは有料オプションをリリースして、ちゃんとしたビジネスにしたいのだが、より多くの人たちに使い続けてもらうには、こまめなアップデートも必要。そのあたりのバランスが難しいのだが、今年の第一弾は、neu.Annotate のアップデート。

１. プロジェクター・サポート（「手書きプレゼン」機能）

これは私自身がぜひとも欲しかった機能。これに関しては、当初は「手書きプレゼン」専用のアプリをリリースすることも考えていたのだが、あまりアプリの数を多くしても、ユーザーにとっても不便だろうということで、neu.Annotateに集約することにした。使い方は以下の通り：

• プレゼンの資料（パワポのスライド）を前もってPDFにしておくneu.Annotateに渡しておく
• VGAコネクターなどを入手して、iPadをプロジェクターもしくは外部モニターに接続
• neu.Annotateを起動して、先のPDFファイルを開く
• iPadは横向きにしておく
• ページめくりをしながらプレゼンをし、必要に応じて手書きでメモ等を書き込む
• プレゼンが終わったら、メモ書きを含んだPDFを作成してメールで出席者に配布

授業や会社のプレゼンに使っていただければ幸いである。

２. 白紙の挿入（Insert Blank Page）

これは、何人かのユーザーからのリクエストに答えて追加したもの。PDFファイルを閲覧中に、右上のアクションアイコンをタップして、メニューから "Insert Blank Page" を選ぶと何も書いていないページをPDFに追加するので、そこにメモ書きなりをしていただければ良い。

３. ペンとマーカーの色の変更

1.0 はペンとマーカー（各３本づつ）の色を固定してリリースしたのだが、たくさんのユーザーから「ペンの色を変更したい」 とのリクエストが来たので、追加した。使い方は、neu.Notesと似ており、色を変更したいペン（もしくはマーカー）を選択したのち、３本のマーカーの右のカラーボックス（をタップして色を変更する）。

４. 日付の挿入

これも私は思いもよらなかった機能だが、「その日の日付を簡単に書き込める機能が欲しい」というリクエストがいくつか来たので、追加した。右上のテキストアイコンをタップして、テキストメニューから選ぶだけだ。

５. 同じようなテキストの繰り返し入力

これもリクエストに応じてのもの。テキストメニューからテキストを入力すると、それを覚えているので、次に同じものを入力したい場合は、タップするだけで良い。ちなみに、テキストの色は最後に選択したペン（もしくはマーカー）と同じものになる。

６. "Open In..." のサポート

これを使うと、添削済みのものをGoodReaderやCloudReadersに渡してそちらで読む、みたいなことが簡単にできる。

日本ではまだまだ普及率は低いが、今年中にも１０億人ユーザーに達すると予想されるFacebook。今年の夏前には、「Facebookの使い方」のたぐいの本が日本の本屋さんに平積みになっている様子が目に浮かぶ。

単純な「Facebookウェブサイト使い方」は、その手のガイドブックに任せるとして、私がどんな風に使っているかを実例を使って説明しよう。

先日書いた、「ピュアAJAXアーキテクチャのススメ」というエントリーに対して、「BigPipeに似ている」というコメントをTwitter経由でいただいた。そこで調べてみると、「BigPipe: Pipelining web pages for high performance」という論文が見つかった（Facebook内のNoteという仕組みを使って書かれており、誰でもアクセスできる設定になっている）。

読んでみると、私のアプローチとは少し異なるが、その根底にある考え方は共感できるので、早速その著者（Facebookのエンジニアの一人）に簡単なメモをそえてFriend Requestを送ってみた。

すぐに承認されたので、今度はその人向けの「Pure-AJAX Web Application Arthitecture」というメモを書き（同じくFacebook上のNote、やはり誰でもアクセスできる設定になっている）、リンクを送った。

すると、こんな返事が返って来た。

Satoshi, thanks for sharing the note with me. It looks great. I totally agree with your points, and I think template based client side render will be future for a lot of html5 base web apps. There is also a lot of interests inside Facebook for doing something similar to your approach. Please keep up your great work, look forward to your open sourcing it.

メモを書く時間も含めて２時間ほどの間のやり取りだが、このわずかな労力で、Facebook内のエンジニアと知り合いになり、ウェブサイトのアーキテクチャに関する意見を交換することができた。この関係が今後どう発展するか分からないが、こんな人的ネットワークを築いて置く事は何よりもの財産だと私は考えている。

メールほど格式張っておらず、かつ、ブログなんかよりは（実名である分）安心してこんなコミュニケーションが取れて、人とのネットワーク作りが出来る、それがFacebookである。

 
今回のCESではいくつもの発表があったが、その中でも私として一番うれしかったのが、Toyotaが発表したEntune。米国のトヨタ純正カーナビには、bing（検索）、Pandra（インターネットラジオ）、MovieTickets.com（映画情報）、OpenTable（レストラン予約）などの「アプリ」が走るのだが、そのアプリとアプリのローンチ画面のUIを担当するのがUIEngineなのである。

UIEvolutionは、私が２０００年に「これからはいろいろなデバイスがネットに繋がり、その結果、さまざまなプラットフォームが乱立する戦国時代に突入する。その問題を一気に解決するのがUIEngine。携帯電話から、テレビ・自動車・冷蔵庫までいろんなデバイスにUIEngineを載せて組み込み機器のUIの開発を大幅に簡単にする」というビジョンを掲げて起業した会社だが、１０年たってようやく自動車に到達。携帯電話はもちろん、テレビにはIPTVのセットトップボックスという形で採用が進んでいるので、残るは冷蔵庫だけだ。

ちなみに、このCESでの発表に間に合わせるために、エンジニアたちは文字通り「寝る間を惜しんで」がんばってくれたのだが、すべてのUIをUIEngineの上で作っているために、副産物として、同じアプリがSamsungのGalaxy Tablet（Android)の上でも、VerizonのBREW端末の上でも、ドコモのJava端末の上でも動いてしまっているのが何とも楽しい。

組み込み機器上でのアプリの開発さの難しさを知っている業界関係者は、今回のCES向けの開発が簡単ではなかったことを理解してねぎらいの言葉をかけてくれるのだが、「ちなみに、同じアプリがAndroid端末でもBREW端末でも動いてます」というと、誰もが「信じられない」という顔をする。常識から考えれば、ターゲット端末向けの開発でアップアップのはずなので、他の機種に移植する余裕などあるはずがないのだが、「試しに載せてみたらそのまま動いちゃったんですよ」とシレッとして言えるところがUIEngineの楽しさ。

ちなみに、せっかくの機会なので宣伝しておくと、UIEngineは、すでにAndroid、iPhone、Flash、Linux、Windows、Windows Mobile、BREW、Java（J2SE）、J2ME/MIDP、J2ME/DoJa、Symbian、などの各種プラットフォームの上に移植済み。UIEngineの上で作ったアプリはUIEngineさえ載っていれば、どんなデバイス上でも動いてしまう、とうのが特徴。Javaの "write once, run everywhere"が口先だけで終わってしまったのと違い、コンパチビリティはしっかりと作り込んである。もちろん、ビデオのコーデックだとか、I/Oの制御のようなドライバー部分はデバイスごとの作り込みが必要だが、少なくともUIの部分だけなら１００％のポータビリティを持つのが特徴だ。

組み込み機器上でのソフトウェアの開発プロジェクトでは、プロジェクト開始時点ではハードウェアがまだ存在しないケースがしばしば。そんな場合も、UIEngine上に作っておけば、ハードウェアのプロトタイプができてくるまではパソコン上のエミュレータや、手持ちのデバイス（たとえば、Samsung Glaxy タブレット）でUI部分の開発をしておき、実際のハードウェアが来てからは下回りのドライバーの開発に専念する、みたいな作り方ができるので、通常の組み込みプロジェクトと違って使い勝手のチューニングに十分な時間がかけられる。