NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
反面教師としての三木谷発言
kobo touch の初期不良問題に対する三木谷氏の発言にはあまりにも学ぶことが多かったのでひと言。ソースは、日経ビジネス Digital の「細かいことで騒いでいるのは少数派ですよ」という記事。 特に問題なのは冒頭の、 ――色々トラブルが起きましたが現状は。 三木谷：いや、いいですよ。初期設定の問題で細かいトラブルはあったけど、2日以内に解消できたし、コールセンターも24時間対応にしたし。アクティベーション（利用できる状況にセットアップすること）した人が購入者全体の95％を超えていますからね。そして、何よりコンテンツが売れまくっている。出版社の人に聞いてみたほうがいいですよ。僕は出版社の驚きように驚いている状況です（笑）。 販売台数は10万台弱程度で、年内目標は100万台。だいたいそこまでいけそうです。やはりユーザーインタフェースがいいんですよね。直感的にできるし、変なボタンもないし
Android OS のアップデート問題に関してひと言
最近、再びAndroid OSのアップデート問題が話題になっているようだが（参照）、OSの開発の関わったことのある開発者としてひと言言わせてもらう。 OSの開発というのはただでさえ簡単な仕事ではないが、特に難しいのは過去のアプリとの互換性を保ちながらOSそのものを進化させて行くという仕事。Windows95の開発の際も、一番苦労したのは、スタートメニューだとかデスクトップなどの新機能の追加ではなく、Windows 3.1との互換性を保つ部分。その当時のエピソードは、少し前の「Windows95と地上の星」というエントリーに書いたので一読いただきたい。 今回の話は、さらに厳しい要求だ。iPhoneのように一社がデバイスの仕様すべてとリリースタイミングをコントロールしているならいざしらず、Androidのように複数のメーカーが、それぞれの仕様でばらばらのタイミングでデバイスをリリースしている世
「３強１弱、あと番外」の方向に向かうスマートフォン市場
スマートフォンの動向に関して良い記事が GeekWire に出ていたので紹介する。 As profits fall at HTC, Samsung becomes the smartphone king with record net income 興味深いのは、この記事で紹介されている各社のスマートフォンの出荷数。Appleが iPhone 4S のリリースの遅れにより第三四半期の出荷数を落としたのに対し（３ヶ月強の遅れだが、９末のリリースも逃したために実質的には２四半期分の遅れとなった）、Samsung が飛ぶ鳥を落とす勢いで出荷数を伸ばしているのが良く分かる。 今後のことで言えば、一番の注目株はNokia。本来ならばスマートフォンとは呼べない Symbian 端末をスマートフォンとして数えているからこの数があるわけで、実質的にはゼロと考えた方が良い。Microsoft との提携はその
福島第一にはメルトダウンした核燃料よりももっと危険なものがある
菅政権の内閣官房参与で、福島第一原発事故対策や原子力政策のアドバイザーだった田坂広志・多摩大学大学院教授が原発事故の教訓や今後の課題について語った講演「パンドラの箱」が公開されているので下に貼付けておく。 原子力発電を利用するというのは、その国全体にとって何を意味するのかをとても的確に表しているので、原発に賛成の人も反対の人もぜひとも見ていただきたい。特に使用済み核燃料の問題が技術的な問題ではなく社会的な問題であること、そして福島第一でもっとも危険な存在は実はメルトダウンしてしまった１〜３号機の核燃料ではなく、４号機のプールにあって取り出す事もままならない大量の使用済み核燃料であること、などが専門家の立場から的確に語られている（ビデオの40:00〜45:00あたり）。万が一４号機のプールがこれから起こる地震で壊れたりしたら、関東にも人が住めなくなるのだ。 １時間強と少し長いので、忙しい人は
勇気を持って、自分の心と直感が指し示す方向に進め
ぜひとも原文で彼の言葉を味わって欲しい。 “Your time is limited, so don't waste it living someone else's life…have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.” by Steve Jobs 注１："Your time" とは、「あなたが地球上に存在する時間」という意味。 注２："someone else's life" とは、日本語で言えば「敷かれたレール」のような意味。 注３：ここで言う "They" とは、"your heart and intuition" を指す。 注４："Everythi
Nokia+Microsoftパートナーシップは、「３強３OS時代」の幕開けか
おおかたの予想通り、NokiaはGoogleではなくMicrosoftをパートナーとして選んだ（参照）。簡単に解説すると、 NokiaはWindows Phone7をNokiaのスマートフォンの唯一無二のプラットフォームとして選択する NokiaはMicrosoftのBingサーチエンジンとadCenterを全面的に採用する 低価格端末にはSymbianを使いつづけるが、これ以上のSymbianへの開発投資は行わない 開発中のMeeGoベースの機種は一応は出すが、これはWindows Phone7への「中継ぎ」でしかない 携帯電話、スマートデバイスを作っている部門を別々のビネスユニットとする（スピンアウトではなし） ソフトウェア（Symbian + MeeGo）の開発部門を大幅にカットする NokiaはMicrosoftにソフトウェアのライセンスフィーを払うことになるため粗利益率は下がる
JavaScript HTMLテンプレートエンジン SNBinder 公開
先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC
ピュアAJAXアーキテクチャのススメ
先日、ここで発表したFacebookユーザーむけグループウェア「Fruence.com」。今年のトレンドになるであろう「ソシアル・アプリ」の実例という意味もあったが、私自身の中で少し前から形になりつつあった「AJAXを最大限に活用した新しい形にウェブ・アプリケーション」のアーキテクチャの実践という意味合いも大きい。 このアーキテクチャの特徴は以下の３つである。 サーバー側は、JSON over HTTPのAPIとHTML/CSS（およびそのテンプレート）をスタティックな形でのみ提供する（サーバー側では、ダイナミックなHTMLの生成はしない） クライアント側では、JavaScriptを使ってサーバーから取得したJSONとHTMLのテンプレートを組み合わせて（データ・バインドして）表示する。 ウェブサイトはあたかも独立したアプリのように動き、操作中はURLは一切変化しない もともとは、HTML
「ガラパゴス問題」に対する少し前向きな一考察
昨日の「日本のケータイが『ガラパゴス化』した本当の理由」には沢山のコメントをいただいたが、その中には、「じゃあ、日本はこれからどうすれば良いのか」という質問があったので、私の考えを少し書いてみる。 まず、ケータイやテレビのように消費者向けのデバイスを作るのであれば、世界規模でビジネスをすること以外は考えない方が良い。先のエントリーで書いた通り、日本の携帯メーカーは、単に「ソフトウェアの開発能力・デザイン・おもてなし」で負けているだけでなく、ビジネスの規模の違いから、部品の調達コスト・製造コストでAppleに大きく引きはなされているのだ。「悪かろう高かろう」では勝てるわけがない。 もし、日本のメーカーがAppleやSamsungと本気で戦おうとするのであれば、（１）コスト面での徹底的な合理化をはかり（役員のお抱え運転手を廃止する、年功序列で給料だけが高くなってしまった人たちに辞めてもらう、系
日本のケータイが「ガラパゴス化」した本当の理由
「ガラパゴス」という言葉が今年の流行語大賞の候補に選ばれたということを聞いていたので、密かに受賞しないかと期待していたのだが、残念ながら大賞は逃したようだ（もし大賞に選ばれていたら、私が受賞することになったのかどうかの疑問はこれで解けずに終わってしまった）。しかし、この言葉をずいぶん前から使っている私としては、この言葉が一人歩きしているようでなんとも言えない気持ちなのでひと言。 まず最初に断っておくと、私が２００１年のCTIA（米国の携帯電話業界で一番大きなカンファレンス）のスピーチでこの言葉を使った時は、単に日本という「単一民族で、国民の大半の生活レベルが同じで、家電とか携帯電話のようなガジェットに流れるお金が比較的多い」という特殊な環境で、iモードを中心に「ケータイ・ライフスタイル」が異常なスピードで進化をとげていることを表して、「ガラパゴス現象」と呼んだだけのこと。決してネガティブな
プラットフォームとして台頭して来た Facebook
週末はクリスマス休暇でロスに住む長男が遊びに来ていたのだが、金曜日の朝になって面白そうなFacebookユーザー向けのサービス案を提案して来たので、さっそく作ってみた。２４日にはクリスマスパーティもあったし、テニスも毎朝していたので、正味プログラミングをしていた時間は３０時間ぐらいしかなかったのだが、発案からわずか３日でサービスがローンチできてしまうとは（Google App EngineとFacebook APIのおかげ）、ずいぶんと便利な時代になったものだ。 日本ではまだまだだが、米国では人口の７割以上がアカウントを持つと言われるFacebook。Twitterでの不特定多数向けの「つぶやき」よりも、友達・知り合い間での「プライベートなコミュニケーション」向けのFacebookは、どちらかと言えばmixiに似ている。mixiとの根本的な違いは「大人も使っている」点。 特に最近は、「プラ
言語対決：JavaScript 対 Objective-C
ここのところ、サーバー側（Google App Engine）のコードはPythonで書き、クライアント側のコードはiPhone/iPad 向けはObjective-Cで、ブラウザー向けはJavaScriptで書く、という毎日が続いている私である。 それぞれの言語は難しくないのだが、さすがにこの３つを頻繁に行き来していると、pythonのコードに間違ってセミコロンを付けてしまったり、PythonとJavaScriptのどっちがTrueでどっちがtrueだか混乱したりする。 ちょうど昨日は、以前JavaScriptで書いたコード（写真をアップロードするコード）をObjective-Cに移植する機会があったのだが、とても分かりやすい結果が出たので、ここで比較してみる。 まずは元の JavaScript のコード。 SNBinder.get("/blob/create_upload", {},
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
Oracleの「Android訴訟」についてひと言
今日のこちら（米国西海岸）でのもっぱらの話題は、Oracleの「Android訴訟（詳細）」だが、これに関しては、私も含めて「やはり来たか」と見ている専門家は多い。 そもそも、スマートフォン以前の携帯電話用のJavaがプラットフォームとして成功しなかった理由の一つは、J2MEが根っこのところで、NTTドコモ独自のDoJaとモトローラ主導のMIDPに分岐してしまったことにあるし、同じJ2ME間でも実装の差異が大きく "write once, run everywhere" が机上の空論になってしまったことにある。Sunがちゃんとリーダーシップを発揮できなかったためである。 その意味では、J2ME/MIDPとコンパチビリティがなく、Sunから正式にJavaをライセンスしていないAndroidはけしからん、というのは（今はOracleの一部になった）Sunから見れば当然のこと。 「J2MEの時に
iPadのインパクト：電子書籍のビジネスモデル
Tech Waveの「iPadに期待する米出版業界、期待すれば裏切り者扱いされる日本の業界【湯川】」という記事を読んでから色々と気になったことがあったので日本における書籍の流通の仕組みについて調べてみた。 とても参考になったのが、少し古いが「書籍の価格構成比をめぐる小考」というブログ記事。流通マージン等に関して、具体的な数字が列挙されているのがうれしい。 紙代：6％ 製版・写植代：12％ 印刷・製本代：7％ 編集コスト：3％ 版元粗利：32％ 著者への印税：10％ 取次マージン：8％ 書店マージン：22％ この数字（特に写植代と取次マージン）がそもそも電子写植・大規模店舗・オンライン店舗・チェーン店の時代に適切かどうか、という話はひとまずおいておいて、電子書籍の時代にどうなるかを考えてみる。 紙代：0％ (不要） 製版・写植代：?％ （はるかに低コスト） 印刷・製本代：0％（不要） 編集コ
今、日本に必要なのは企業の新陳代謝と優秀な人材の有効な活用
先日の「とある家電メーカーでの会話：クラウドテレビ編」と「もし日本のメーカーがiPhoneを発売していたら」、ユーザー不在・カタログスペック重視のもの作りの問題点を浮き彫りにしてみたつもりだ。「こんな場面につい最近も出くわした」という意見から、「こんなにはひどくない」というフィードバックまでいただけたが、多かれ少なかれ、これに近い状況が現場で起こっており、それが日本のメーカーの国際競争力を奪う原因の一つになっていると私は見ている。 日本の家電・半導体メーカーが米国のメーカーと激しい貿易摩擦を起こしていた８０年代、日本の企業の強さはまさにこの「スペック重視のもの作り」にあったことは事実である。日本人の勤勉な気質と日本流の経営スタイルがちょうど良い案配に働き、より集積度の高い半導体、より画質のきれいなテレビ、よりハイスペックな家電を欧米よりもはるかに低コストで効率良く作ることにより、日本が一気
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
で、実際のところHTML5でどのくらいのアプリが実装できるのか実験してみた
