今、日本の家電メーカーに一番必要なもの
今週はラスベガスでCESが開かれているが、CESの時期になるとトラフィックが増えるエントリーが二つある。 とある家電メーカーでの会話：クラウドテレビ編 もし日本のメーカーが iPhone を発売していたら.. どちらも２０１０年のCESに参加した後に感じたことを率直に書いただけだが、その状況は２０１２年になってもあまり変わりがないようである。 日本の家電メーカーや携帯電話メーカーの本質的な問題がどこにあるかを理解したければ、Simon Sinek の "How great leaders inspire action" というビデオを見るのが一番良い。アップルにあって、日本のメーカーに欠けているのは、作り手と消費者の間の「目的意識の共有」である。 戦後の高度成長経済には、「家電三種の神器」と呼ばれたテレビ・冷蔵庫・洗濯機に代表される「もの」を持つことにより生活を向上させることが人々の夢だっ
２０１１年はソシアル・アプリ元年か？Facebookユーザー向けグループウェアFruence
１１〜１２月にかけて、３本連続してGoogle App Engine上のアプリを作ったので、かなりDatastoreにも慣れて来たし、ライブラリも充実してきた。これならば、小さなアプリなら２〜３日で開発＋リリースする事も十分に可能だ。ということで、正月休みの間に「書き初め」として何か自分の日々の仕事の役に立つものを作ろうと思い立ったのが１日の夜。 そこでまず候補として思いついたのが、オンラインの「to-do リスト」サービス。ここのところ、本の執筆、雑誌のコラム、CloudReaders、neu.Notes、neu.Draw、neu.Annotate、neu.Journal と複数のプロジェクトに同時に関っているため、記憶やメモに頼って作業するのは不可能になって来た。そこで、どのデバイスからでも簡単にアクセスできる「オンライン to-do リスト」が欲しいと思ったのだ。 ただ、単なる「オン
日本のケータイが「ガラパゴス化」した本当の理由
「ガラパゴス」という言葉が今年の流行語大賞の候補に選ばれたということを聞いていたので、密かに受賞しないかと期待していたのだが、残念ながら大賞は逃したようだ（もし大賞に選ばれていたら、私が受賞することになったのかどうかの疑問はこれで解けずに終わってしまった）。しかし、この言葉をずいぶん前から使っている私としては、この言葉が一人歩きしているようでなんとも言えない気持ちなのでひと言。 まず最初に断っておくと、私が２００１年のCTIA（米国の携帯電話業界で一番大きなカンファレンス）のスピーチでこの言葉を使った時は、単に日本という「単一民族で、国民の大半の生活レベルが同じで、家電とか携帯電話のようなガジェットに流れるお金が比較的多い」という特殊な環境で、iモードを中心に「ケータイ・ライフスタイル」が異常なスピードで進化をとげていることを表して、「ガラパゴス現象」と呼んだだけのこと。決してネガティブな
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
勝てば官軍、負ければガラパゴス
私が数年前からこのブログで使っている「ガラパゴス化」という言葉、今やテレビや雑誌でまで見る様になり、何だかうれしいような悲しいような、複雑な気持ちである。 私が最初に公の場でこの言葉を使ったのは、２００１年のCTIA（米国最大の携帯通信業界のカンファレンス）でのこと。UIEvolutionというベンチャー企業を立ち上げたばかりでもあり、この業界でなんとか注目を集めようと、「NTTドコモのiモードのことなら詳しいので、日本の若い人たちのライフスタイルがiモードでどう変わったからなら解説できるよ」と会議の主催者に連絡すると、いきなり２０００人も収容できる会場を割り当てられたのだ。 私がNTTドコモから来た人間だと勘違いした人もいたようで、会場は超満員。冒頭でドワンゴの「釣りバカ気分」の面白さを手振り身振りで伝えたところそれが大受けで、日本のギャルの生態系の解説も交えながら、日本の「ケータイ文化
HTML5 Widget入門：あなたにも作れるiPad用Widget
今朝の「iPadでHTML5 Widgetを走らせて遊ぼう」に対して、「もう少しWidgetについて知りたい」との声が聞こえてきたので、「Widget入門編」を書いてみようかと思う。 Widgetとは何か？ 先のエントリーで書いたが、ひとことで言えば「パッケージ化されたウェブアプリケーションである」。通常のウェブアプリは、特定のURLにアクセスすることにより走らせるが、Widgetの場合は、.wgt のエクステンションを持つWidgetファイルをダウンロード＋インストールした上で、それを起動する。 Widgetファイルの中身は、HTML+CSS+JS+メディア・ファイルで構成されており、それをZIP圧縮して、エクステンションを.wgtに変更しただけのものである。 なぜそんなことをするかと言えば、（１）オフラインで動かしたい、（２）通常のデスクトップアプリの感覚で起動したい、（３）パッケージ
電子出版に関する一考察：コンテンツのガラパゴス化の危機
今日は日経BPのセミナー（参照）で、iPadと電子出版の未来について講演をしてきた。私の講演の内容に関しては、一両日中にネットに上がると思うのでここには書かないが、この講演およびその準備段階を通して学んだとても大切なことを一つ書こうと思う。それは日本の出版社に迫る「コンテンツのガラパゴス化の危機」である。 午後の部でヤッパの伊藤氏の講演を聞いていて少し疑問に思ったので、フォーマットのオープン化に関する質問をした私だが、彼の「まだコンテンツの数が少ないのでオープン化を考慮する必要はない」という返答でヤッパの狙いが明らかになった。セルシスと同じく「クローズドなフォーマットによるコンテンツの抱え込み」である。 ここまでフォーマットのオープン化（すなわち誰でもビューアーをライセンス・フリーで作れること）の大切さが叫ばれている今、時代に全く逆行するビジネスモデルだが、漠然とした危機感を抱いてはいるが
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
もし日本のメーカーが iPhone を発売していたら..
iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。
Life is beautiful: とある家電メーカーでの会話：クラウドテレビ編
ある日本の家電メーカーでの会話。まずは副社長室での会話から。 技術部長：副社長、来年度の予算の件はどうなりましたか 副社長：大丈夫だと言っただろう。台湾・中国からの追い上げは相変わらず激しいが、テレビは家電ビジネスの要だ、経営陣としてもここだけは手を抜けない。来年も君たちにがんばってもらわなければならない。 技術部長：もちろんです。そのあたりは現場のエンジニアたちも強く感じてると思います。ちなみに、メールに書いてあった「戦略の変更」って何ですか？ 副社長：そのことなんだが、経営会議でも持ち上がったんだが、台湾勢と戦うには、我が社にしかできない「差別化要因」が必要だ。価格競争では彼らにかなわない、消費者にとって目に見える価値を提供して、台湾製品よりも３割・４割増の値段でも喜んで買ってもらえるテレビを作らなければならない。私は、キーワードは「クラウド」だと思っている。 技術部長：え？「ク、クラ
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
「リニアにスケールするように作れる」からこそのGoogle App Engine
Google App Engineを使った最初の作品 Tiny Message （http://tinymsg.appspot.com）をリリースしてまだ２０時間経っていないが、設計の過程でいろいろと学べたことがある。 その中でも一番収穫として大きいのは、「Google App Engineを使えば、リニアにスケールするサービスを作ることが可能」だということが実感できたこと。 もちろん、Google App Engine上に作ったからと言ってすべてのアプリがリニアにスケールするわけではなし、どんなアプリでもそう作れるわけではない。Entity Groupの構成を間違えればそこがボトルネックになるし、Queryの二重ループなんかを書いたら、すぐにタイムアウトしてしまう。 リニアなスケーラビリティを持つDatastoreの上で作るとは言え、やはりDatastoreの仕組みをちゃんと理解してデー
Google App Engine入門：Datastore上で「ユニーク制限」を実現する方法
Google App Engine のDatastoreには、通常のリレーショナルデータベースと比べた時にいくつかの制限があるが、その一つが「このプロパティの値は常にユニークでなければならない」という指定（ユニーク制限）ができないことである。 Invoice IDのように自動生成するものであれば、アプリケーション側でなんとかすることも簡単だが、メールアドレスやハンドル名など、ユーザーが入力するものになると、ユニークであることをきちんと判定した上でEntityを作ることが必要になる。 もちろん、単純に「有無をチェックして、なければ作る」というプログラムではスレッド間の競合に対応できないので、そこはトランザクションを使ってアトミックに処理をする必要がある。 App Engine上でトランザクションを実現するには、エンティティグループという仕組みを使って行うが、気をつけなければいけないのは、エン
Google App Engine入門：Entity Groupとトランザクション処理
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
Python Hack : 噛めば噛むほどおいしくなるクロージャの話
最近 JavaScript を書く機会が増えているが、それに従って自分のコーディングスタイルが少しづつだが変化してきているのが分かる。もともと「コードの読みやすさ」や「実行効率」にとことんこだわるタイプだが、（JavaやC++になくて）JavaScriptやRubyにあるクロージャや無名関数が私のコーディングスタイルにとてもマッチしているからだと思う。 簡単な例を紹介しよう。Pythonで書かれた config.py というモジュール。config.yamlという設定ファイルを読み込んで Dictionary として返す config.get() という関数。普通に実装すると、以下のような感じになる。 import yaml _config = None def get(): global _config if not _config: data = open('config.yaml')
Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
プレゼン資料：iPhone Phenomenon
今週は火曜日からノルウェーのオスロに飛んで、ワイアレス関係の会議でプレゼン。ようやく話の流れも決まって来たので、頭を整理する意味でも、ここにプレゼン資料を貼付けてみる。 最初の二枚は基本的に自己紹介。まずは、2000年に起業したUIEvolutionのビジネスを簡単に説明して、私とワイアレス業界の関わりを理解してもらう。 スライド３と４は、私の得意な「技術革新」と「人々のライフスタイル」のギャップの話。技術は日進月歩で進んでも、人々のライフスタイルの変化はすぐには訪れない。ライフスタイルの変革には必ずキーとなる役割を果たす製品やサービスが必要で、そこにこそ開発者としての面白みがあるしビジネスチャンスがある、という話。 ５枚目のスライドが、今回のプレゼンの主要なテーマでもある、この「人々のライフスタイル革新」プロセスにおけるiPhoneの役割。携帯用のJavaやブラウザは一部の人々のライフス
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
で、実際のところHTML5でどのくらいのアプリが実装できるのか実験してみた
