アップルの３０年ロードマップ
昨日、日経BP主催のAndroidに関するセミナーで講演＋パネルディスカッションをしたのだが、パネルディスカッションを一緒にさせていただいた、日本通信の福田尚久氏との話（特に、楽屋に戻ってからの非公開の話）が興味深かった。 福田氏は、スティーブ・ジョブズがAppleに戻り、Microsoftからの資金調達、iPodのリリース、アップル直営店の展開、という今のAppleの成功の基盤となる「奇跡の復活」を遂げた時期にジョブズの側近として活躍した人。 彼に言わせると、今のAppleのビジネス戦略は、倒産寸前だった９７年当時に作った「３０年ロードマップ」に書かれた通りのシナリオを描いているという。 もちろん、具体的な内容は企業秘密でもあるので直接聞き出すことはできなかったが、ここ１２年の間にアップルが出して来たもの（iPod, iTunes, iPhone, Apple TV, Safari, O
組み込み機器向けandroidに関してのつぶやき
もともとは携帯電話向けに提供されていたGoogleのandroidが、それ以外の組み込み機器向けのOSとして注目されている。私なりの見解もそれなりにあるのだが、勘違いしている部分もあるかも知れないので、確認のためにも私の見方をぽろぽろとTwitterでつぶやいてみたので、ぜひともフィードバックをいただきたい（Twitter、このブログのコメント欄やトラックバック、はてぶ、のいずれでも結構）。以下がつぶやきの内容。 androidが携帯だけでなく組み込み機器一般で注目されている背景には、「要求される機能が肥大化し開発費が膨大になり、機種ごとにOSから組み上げるのがコスト的に見合わなって来た」というのがある（リンク）。 それに加えて、GUIやマルチタスクなどの要求に対し、従来の組み込みOS（μiTron・VxWorksなど）が答えられなかったという状況もある（リンク）。 その答えの一つとして浮
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
AT&Tがモトローラ製のAndroid携帯を「時代遅れ」と拒否
今日、米国の携帯業界関係者の間で話題に上ったのが「AT&T rejects Motorola's Android smartphones」という記事。AT&Tから正式に発表された訳ではないが、たぶん真実に近いだろうことは容易に想像できる。 AppleがハードからソフトまですべてコントロールするiPhoneと比べ、GoogleはOSを提供するだけで、最終的な製品の仕上がりはハードメーカーまかせのAndroid携帯は「ソウル（魂）のない」中途半端なデバイスになりがち。 このあたりの事情はMicrosoftのOSを使ったWindows Mobile端末も同じで、「個別の機能を見る限りiPhoneに負けてはいないのになぜか魅力的でない」デバイスができてしまうのは、ソフトからハードまで一貫して責任を持って作り上げることが不可能だから。 この業界の歴史を見ると、古くはMicrosoftが旗ふり役だった
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
マーケティングともの作りの話
「マーケティング」という言葉を聞くと「商品に関する情報を顧客に向けて発信する」だけと考える人が多いが、マーケティング部門の役割として同時に重要なのは、顧客のニーズをきちんと探り出して「何を作るべきか」という部分に反映させること。 ちょうど今読んでいるHarard Buisness Reviewにとても良い例が出ていたのでその紹介。 米国のペンキ会社が、競争相手に安売り競争を仕掛けてられ、「利益を削ってでもマーケットシェアを維持すべきか」という厳しい選択に迫られていた。その時にその会社のマーケティング部門が調べ出したのが、主な顧客である塗装業者が何にお金を使っているかというデータ。 そのデータによると、ペンキそのものは経費の１５％にすぎず、大半は人件費だという。それも、ほとんどのケースで、一度塗ったペンキを十分に乾かすために、次の日にもう一度現場に足を運んで二度塗りをしているためによけいな人
Life is beautiful: Google Chromeに関してひとこと
今回Googleが発表したウェブ・ブラウザー、Google Chromeは、ひと言で言えば、「安定度・安全度を高めるために、それぞれのタブを別プロセスで走らせるタブ・ブラウザー」である。 ９５年にIE3.0を設計した時には、タブのコンセプトも存在せず、セキュリティの問題もそれほど強く意識していなかったので、ウィンドウごとに１スレッドを割り当てたマルチ・スレッドを選択した訳だが、ここまでウェブ・アプリケーションが重要になってくると、マルチ・プロセスに移行するのは当然。特定のページ上でのJavaScriptの挙動がおかしくなったからと言って、ブラウザーすべてが落ちてしまう今までの設計が異常。 一つのウィンドウ下で管理させるそれぞれのタブにプロセスを割り当てる、一般的に一つのウィンドウに一つのプロセスやスレッドを割り当てる通常のGUIアプリケーションとは異なるが、ユーザー・モデルとリソース管理は
iPhoneアプリを作る際に注意すべき５つのポイント
毎日のように「iPhoneアプリでApple Design Awardを取るぞ！」と騒いでいるので、知り合いに「それって（現実が分かっていない）大学生のノリですよ」と指摘されてしまった私だが、マイクロソフトを２０００年に退社してからは、ひたすらモバイル・組み込みの世界で仕事をしてきた私としては「俺が取らなくて誰が取る？」という気分。その超楽天的な態度が彼が言うところの「大学生のノリ」なのだろう。 市場に受け入れられるアプリを作るためには、もちろん「誰にどんな価値を提供するのか」が一番大切。しかし、そこには残念ながら成功の一般方程式はないので、今日は比較的に一般化しやすい「どう作るか」という部分に関して、まとめることにした。 1. ユーザーの利用シーン・使用パターンを良く考えて作る パソコンやゲームコンソール向けのソフトと大きく違うのが、ユーザーの使用パターン。iPhoneに限らず、携帯電話
iPhone SDK、第一印象
iPhone 用のネーティブ・アプリケーションの開発が可能になるSDKがリリースされたので、早速ダウンロードしてみた。そもそもMac OS XのAPIも一切知らず、Objective Cでプログラムを一行も書いたことの無い私には目新しいことばかりだが、私がこれだけ気に入って使っているiPhone向けにアプリケーションを作れるというのに試してみないわけには行かない。 iPhone SDKをインストールして、サンプルアプリをエミュレータ上で走らせるところまでは簡単にできたのは良いが、読まなければいけないドキュメントが大量にあってちょっと困っている。まずは、Objective Cを理解し、それからOS Xのコア（Cocoa Foundation）を理解しなければならない。それからやっと本題のUIKit（iPhone用のUIフレームワーク、上の図参照）に取りかかれる。 しかし、ツールにしてもドキュ
優秀な主婦はイベント・ドリブン（event-driven）方式でパンを焼く
昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。 １．イーストを３０℃のお湯と一つまみの砂糖とまぜて１５分間予備発酵させる ２．ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる ３．こね板の上で生地をこねる ４．ボールにラップをして室温で１時間発酵させる（一次発酵） ５．適当な大きさに生地を分割し、丸めて形を作る ６．オーブンに入れ、３０分発酵させる（二次発酵） ７．オーブンの温度を２００度にして１８分焼く これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である（その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている）。 興味深いのは、このレシピにおける、「１５分予備
gPhone雑感：「モバイル・プラットフォーム戦国時代」の幕開けだ
今朝になって、話題のgPhoneがアナウンスされた（参照１）訳だが、大方の予想を裏切ってそれはデバイスではなくてソフトウェア、それも2005年にGoogleが買収したandroidという会社の作っていたLinuxベースのマイクロ・カーネルと、バーチャル・マシン。androidの買収とともにGoogleに入ったAndy Rubinがandroidの前に作ったSidekick (Danger Inc.)の中身を良く知る私としては、「これってDanger OSとどこがちがうんねん？」という感じ。 ほぼ同じ時期に会社をスタートしたこともあり、Dangerの連中とはスタートアップ当時から一緒に仕事をし、サードパーティとしてSidekick向けのソフトウェアを作った数少ない会社の一つがうちの会社UIEvolution Inc.だ（資料２）。 Javaに似てはいるが微妙に異なるバーチャル・マシンを持ち、
Life is beautiful: オブジェクトを次々に渡す「Ruby Filter」ってどうだろう
Rubyに慣れようと、コマンドライン・ツールなどを作ってみることにしたのだが、すでにUnixに存在しているgrepなどを作っても仕方がない。そこで、指定したブログのURLからHTMLページをHTTP GETで取得し、それをパースしてATOMやRSSフィードのURLを見つけて、それをさらにHTTP GETで取得してタイトルだけ表示する、というツールを作ってみることにした。 できるだけRubyらしい作り方をしようと思いついたのが「Ruby Filter」。Unixのフィルターのようにそれぞれは単一の機能を持ったプログラムをパイプでつなげて複雑なことをさせる。ただし、フィルターからフィルターに渡すものは単なるテキストではなく、オブジェクトのテキスト表現だ（次のフィルターはそのテキストをevalしてから入力として利用する）。 上のブログのURLからRSSフィードを取り出すケースだと、 parseU
AJAX vs. Flash、fladdictブログより
昨日のエントリーで、深津氏のブログに「Flash使いから見たAJAX」のことが書かれていて読んで勉強になった話を書いたのに、それらのエントリーへのリンクを張るのを忘れていたので、今日はそのリンク集。 以下のエントリーは、AJAXが騒がれ始めた2005年３月から２００６年１月の間に書かれたものだが、この「閉じたFlash」vs.「オープンなAJAX」という構図は相変わらずである。特に、FlashはActionScript3.0で大幅に言語として整備されたにも関わらず、AJAXに押されぎみなのはなんとも微妙である。 それで思い出したのが、GoogleにUIEngineの説明に行った時の会話。「もっとオープンにしてくれ」という彼らに、「Flashはどうなんだ」と答えると、「Macromediaの連中にもオープンにしろと言いつづけている」と言う。GoogleもYoutubeなど一部のサービスではF
ユーザー参加型コンテンツビジネスのまとめ
最近CGM（Consumer Generated Media）関連の質問をされることが多いので、一度頭の中にあるものを整理する意味でも、箇条書きにしておく。 従来のWeb1.0的なコンテンツビジネスと比べた時の利点 ・常に新鮮なコンテンツをコストをかけずに提供できる点 ・バイラルマーケティング効果（コンテンツを作ったユーザーが他の人に宣伝してくれる） ・根本的にコミュニケーションツールであること（人がオンラインになるのは、他の人と繋がるため） ・ユーザーの数が増えれば増えるほどサービスの価値が上がる点 ・長く使えば使うほど、そのユーザー自身の財産が形成され、サービスから離れにくくなる点 意識しておくべき点 ・自社コンテンツを持っていない企業が新規参入できる点 ・ユーザーは予想もしない使い方をすることがあること ・コミュニティの作られ方しだいでサービスの質が大きく左右されること ・積極的に参
AJAXアプリは客のわがままを聞いてくれるレストラン
UIEngineの説明をする際に、「通常のウェブ・アプリケーションと異なり、非同期通信を使ってクライアント側でデータ・バインディングをするので、ストレスの少ないユーザー・エクスペリエンスを提供できます」と言ってきた私だが、「データ・バインディングとは何か」を知らない人が意外に多いことに気がついたので、ここで解説しておく。 得意の食べ物にたとえれば、データ・バインディングは「調理」に相当する。定食屋のように全ての食材（データ）をキッチンで調理をしてしまってから一度に持ってくるのが「サーバー・サイドでのデータ・バインディング」で、紅花レストランのように食材をテーブルまで持って来て目の前で調理してくれるのが「クライアント・サイドでのデータ・バインディング」である。 食材を一度にはテーブルに運ばず、客が一つ目の料理を食べている間に二つ目の料理の食材を運んで料理をしておき、一つ目の料理を食べ終わった
「ラボ」サーバー設置
今年に入ってからレンタルサーバーを使って色々と遊んでいる私だが、そんな私を見て、社内からもそういった「遊び」の部分を会社として正式にサポートする仕組みを作るべきでは、という声が上がってきた。やっと分かってもらえたようだ。 そこでさっそくサーバーを「ラボ」用に一台立ち上げてもらい、その上で前から作りたいと思っていたアプリを作ってみた。携帯電話用の「シアトル近郊の交通情報表示アプリ」である。シアトル近郊の交通情報は、ワシントン州の交通局のウェブサイトに無料で公開されているのだが、携帯電話から見られるようには作られていないのだ。 そのサイトに表示されている画像をこちらのサーバー側で一度取り込み、細切れにスライスした上でディスク上にキャッシュし、それを携帯電話にダウンロードしたUIEngine上に表示してGoogle Mapのように自由にスクロールできるようにする、というアプリを前から作りたかった
マップアプリのソース公開
昨日のエントリーで書いた「シアトル近郊の交通情報表示アプリ」、コメント欄で励まされたこともあり、全ソースを公開することにした。ただし、会社のサーバーで公式に遊ぶことになったので、発表の際にはまず英語で解説を書かねばならなくなってしまった。とりあえず、これが解説ページである。 King Country Traffic Map たいしたことが書いてあるわけではないので、全部を日本語に訳すこともないとは思うが、肝となる How it works （どうやって動いているか）だけは日本語での解説が必要そうだ。そこだけ抜き出して意訳すると、 このアプリは、三つのUJMLファイル（クライアント側でマップを表示して、ユーザーとのやり取りをするもの）と、二つのPHPファイル（サーバー側で元画像を細かくスライスしてキャッシュするもの）から出来ている。 Main.ujbc（Main.ujmlをコンパイルしたもの
Livedoor の「テレビ番組RSSフィード」で遊んでみた
「新しいテレビの楽しみ方」にやたらと興味がある私としては、Livedoorが番組表のRSS配信サービスを始めて以来何か作りたくてしかたがなかったのだが、やっとプロトタイプを作る時間を見つけることができた。まずはその作品の発表から。 「テレビ番組ガイド」（Javaのランタイムが必要） 工夫した点は以下の４つ １．上下左右キーだけで操作が可能 ２．マニュアルを見なくとも使えるぐらい使い方が自明 ３．非同期通信中でも操作が続行できる ４．携帯電話のように少ないメモリでもサクサク動く もちろんUIEngineを使っているので、携帯電話だけでなくさまざまなデバイスで動かすことが可能だ。 ちなみに、サーバー側はPHP。Livedoorのサーバーから取得したRSSをXMLParserでパースし、PHP版のミニコンパイラでバイナリのレコードセットに変更してデバイスに返す、という仕組みだ。 XMLParse
Live Page-View Counter, Comet server and JSON-push
Overview A "page-view counter" or "hit counter" is a mechanism that displays the number of page-views on an HTML page. It uses a server side of script that counts the page-views, dynamically generates an HTML page on the server side, and returns it back to the browser. Although it accurately displays the number of page-views at the point when the HTTP request was made to fetch the HTML page, it wi
「足あとライブ！」
昨日公開した、リアル・タイム・ページビューカウンター（RPV Counter）に関して、さっそくLingrの開発者の江島健太郎さんから「Webで読者が自分以外の人の存在の『気配』みたいなものが感じられるというのは面白いですよね。」というコメントをいただいた。それにに刺激されて今朝作ったのが「足あとライブ！」。自分の「気配」をもっと明示的に他の人に知らせる仕組みだ。 このブログの右上のページビュー・カウンターの下にある「足あとアイコン」は、クリックすると色を変えることができるのだが、その情報がCometサーバーを伝わって、同時にこのブログを見ている他の人のアイコンにも反映されるようになっているのだ。 ちなみに、Lingrとは、この「足あとライブ！」と同じく、CometサーバーによるPUSHの仕組みを使った「ブラウザ上で動くチャット」である。RPV Counterのデバッグ中に、クライアントか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
