NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
放送と通信の壁に穴を開けたパナソニック
パナソニックが「テレビ放送と同時にネットから取得した情報を画面には表示しない」という放送業界と家電業界との紳士協定を破ったとして、新型テレビのCM放送を拒否されているそうだ（参照）。 一見何気ないニュースだが、これは既得権益を守るためのルールでガチガチに固められてイノベーションが起こりにくくなっている日本としては、非常に画期的なことである。 日本のテレビ放送には、BML(Broadcasting Markup Language)という仕様で文字を送る仕組みがついているが、これをわざわざ HTML にしなかった理由は、放送と通信の間に人為的な垣根をもうけて放送局の既得権益を維持しようという試み以外の何物でもなかった。 今回問題となっている「テレビ放送と同時にネットから取得した情報を画面には表示しない」という紳士協定も、テレビ放送にネットから取得してきたTweetや広告を重ねて表示されては、付
たかが電気、されど電気
メルマガ「週刊 Life is Beautiful」で「なぜ日本は原発を止められないのか」という連載を始めた。通信業界の東京電力に相当するNTTで働いていた経験を活かし、霞ヶ関や東電のエリートが何を考えてあんな行動に走るのかを解説する。ちょうど良いタイミングで先日の「さようなら原発１０万人集会」での坂本龍一氏の「たかが電気のためになんで命をさらさなければいけないんでしょうか」という発言が注目を集めているので、このブログでもひと言書いておく。 「たかが電気」という発言に対して「電気を止めたら死んでしまう病人がいる」「真夏にクーラーがかけられなければ、熱中症で死ぬ人がいる」と噛み付いている人がいるが、これらの指摘は大間違いである。日本は、原発を止めたぐらいで、病人の生命維持装置が止まってしまったり、熱中症で死ぬ人が増えたりする国ではない。 本当の理由は別のところにある。日本経済が重度な「原発依
AppleとSonyの一番の違い part II
図の表現から直接的に呼び起こされる事はアップルは消費者が本当に欲しいものを言わないしマーケッターや詳しい専門家は正しく実行する事はできないと理解していて、マッケーターの言う通りにも消費者がいう通りにもしないで自ら考えて実行していて、ソニーは消費者が欲しいというものを素直に受け取りマーケッターの調査や専門家が言う事を正直に実行する。その結果として、ソニーが用意するメニューはアジアニズムになり、アップルのメニューはアッティシズムになります。 しかし、そのような前方参照的な事からこの結果がでてきたわけでなく、アップルは自らの起源としてのアメリカーヨーロッパの歴史からくる古典主義的な純粋さを尊重し、装飾しない事を美しいとしています。しかし、ソニーは歴史的にはアメリカヨーロッパに進出するため、その美意識を創業者は学びその純粋さから登り詰めましたが、その意味を理解できなかった他の経営幹部、あるいはその
AppleとSonyの一番の違い
私のメルマガ「週刊 Life is Beautiful」への質問にソニーの復活に関するものが多いので、来週あたりにまとめて答えようと思うが、それに関連して、興味深いブログエントリーを見つけたので紹介する。 ”coffee time: market share vs. profit" というもので、スマートフォンのマーケット・シェアではAndroidに大きく抜かれたAppleも、売り上げベースだと肩を並べるぐらいで、利益ベースだとAppleが圧倒的に強い、という話だ。 そこに出ている、AppleとSamsungの米国向けの携帯電話のラインナップの写真が、両社の違いを際立たせているので、下に貼付けておく。これはAppleとSonyにも共通する話で、これと同じ様に、Appleとソニーのコンシューマー・エレクトロニクス全商品のラインナップを並べたらものすごい違いになる。
Flashの終焉と、HTML5時代に向けたアーキテクチャと
Adobeがモバイルブラウザー向けのFlashプラグインの開発をストップすることをアナウンスした（参照）。パソコン向けのプラグインと、ネーティブ・アプリ向けにはまだ開発を続けるとは言っているが、モバイルブラウザーの重要さを考えれば、今からFlashコンテンツをブラウザー向けに開発する開発者はもういないだろう。 これから一気に進歩するのが、HTML5ブラウザー向けのさまざまな開発ツールやライブラリ。開発ツールを飯のタネとしているAdobeとしては、開発リソースを集中して、HTML5の時代にも Creative Suite がデファクト・スタンダードとして君臨すべく全力を尽くすだろうが、当然、MicrosoftやAppleが指をくわえて見ているわけがないし、ベンチャー企業にもまだまだチャンスはある。 私自身も、オープンソースとして提供している SNBinder （参照）とその回りのサポート・ラ
原発一機を一年間動かすとどのくらいの残土・劣化ウラン・放射性廃棄物が生じるかを計算してみた
iPad/iPhone向けに開発した計算アプリ neu.Calc。色々な使い方が可能だが、普通の電卓アプリにない機能の一つが、HTML Tableを生成する機能。計算をした後、アクション・メニューから "Mail" を選択すると、テーブルを生成してメーラーに渡す。 下のサンプルは、福島第一の２号機で一年間に燃やす核燃料（濃縮ウラン 78.4トン／年）を採掘・燃焼する過程で生じる、残土、劣化ウラン、高濃度放射性廃棄物などの量を計算したもの。neu.Calcに備わった "Solver" という機能を使って、総採掘量 66.3万トンを逆算してもとめている（差引というフォーミュラはこの"Solver"のために追加した）。 ちなみに、「地球にやさしい」はずの原子力発電が、実はちっともやさしくなんかないことがこの表を見ていただければ分かると思う。たった一基の原発を動かすために、６６万トンもの土を掘り返
UIE Japanの新オフィス紹介
UIE Japanが渋谷の新オフィスに移動した（参照）。ビジネスも順調に伸び、人も増えて来たのでこれまでの富ヶ谷のオフィスでは手狭になったのである。 UIE JapanはUIEvolutionがスクエニの子会社だった時に作った法人だが、当初はまともな売り上げもなく、親会社との「共同プロジェクト」を細々とこなすだけのなさけない組織であったが、今や日本法人単体だけできちんと採算が取れるところまで成長しており、とても頼もしい限りだ。 転機が訪れたのは２００７年のスクエニでの取締役会議。赤字続きの子会社であったUIEvolution/UIE Japanをスクエニの外部取締役であった成毛氏がするどく批判。それがきっかけとなり、私のスクエニからの辞任、MBOによるスピンアウト、大量レイオフ、と一時は存続が危ぶまれるまでに追いつめられたが、逆に独立したことが社員のインセンティブとなり、V字回復が実現した
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
もし日本のメーカーが iPhone を発売していたら..
iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。
丸山ワクチンの過去・現在・未来、自然免疫と癌治療
今回の訪日中に、ソニーの（音楽・ゲームなどの）エンターテイメント・ビジネスの生みの親でもある丸山茂雄氏とお会いする機会があった。私もつい最近まで知らなかったのだが、丸山氏の父親は「丸山ワクチン」の生みの親である故丸山千里博士。「私自身も丸山ワクチンで癌と戦っている」という丸山氏の言葉に刺激され、丸山ワクチンに関して調査してみたのでここにまとめてみる。 「丸山ワクチンの効果」に関しては、専門家の意見でも意見が分かれている、というのが現状である。そのため、事実と意見が混在した形でネット上に存在しており、単にググっただけでは玉石混淆の情報に悩まされるだけ。そこで、一歩踏み込んで、新聞・専門書・学術ペーパーなどを読んで事実確認をしながら、まずは確実に事実と言える部分を洗い出してみた。 事実１：丸山ワクチンは、丸山千里博士がもともとは皮膚結核の治療薬として開発したもの（１９４４年誕生） 事実２：丸山
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')
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
Google WaveがHTML5ブラウザーへのシフトを加速する
Internet Explorer 3.0/4.0 の開発に関わっていた人間として言うのも変な話だが、そろそろIEには主役の座を降りてもらった方が良いと思っている。いろいろな要因がからみあって今の状況があるわけで、その部分について今さらここであれこれ言うつもりはないが、実際のところ、 IEが他のブラウザー（Safari/Firefox/Chrome/Opera)と比べてHTML5やCSS3のサポートに関して大きく遅れている そもそもIEの進化のスピードが（というかMicrosoftから出る製品すべての進化のスピードが）遅すぎる にもかかわらずIEのシェアが大きいため、業界全体の足を引っ張っている という現状があることは誰にも否定できない。 HTML5やCSS3の新しい機能により可能になる新しいウェブアプリをどんどんと作って行きたいと考えているエンジニアは私だけではないわけで、その意味では「
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
jQBinder, ブラウザー側でのHTML templateを可能にするjQuery plug-in
一昨日はMVCの話で妙に盛り上がってしまったが、考えてみるとModel/View/Controller間の分離が不十分という話はサーバー側だけの話ではなく、クライアント側にも言える事。事実、私自身も div.innerHTML = "<span class='red'>" + message + "</span>"; みたいなHTMLが混ざったJavaScriptコードを書く事は良くある。特に、最近はJSONとして取得して来たデータセットをリストとして表示するケースが増えて来たが、そんな時に「サーバー側のようなHTMLテンプレートが使えたらいいな」と思う事は良くある。手っ取り早くとりあえず動くものを作るのにはHTML埋め込み型のJavaScriptで良いのかも知れないが、後々のメンテナンスを考えると少なくともModelとViewぐらいはキチンと切り話しておいた方が良い事は確か。 ということ
デザイン・パターンとは何か
先日のMVCの議論の際には、私自身いろいろと勉強させていただいたが、少し心配になったのは、「MVCの定義だって時代とともに変わる」「ウェブサービス用のMVCはSmalltalk時代のMVCとは異なるもの」「MVCなんか理解してなくてもアプリケーションが作れればいいじゃん」など、そもそも「MVCとは何か」どころか「デザイン・パターンとは何か」を理解していないんじゃないかと思われる発言が見られたこと。ということで、今日はデザイン・パターンについてひと言。 デザイン・パターンとは、（業界に蓄積されたノウハウに立脚した）何かを作る際の指針のこと。ソフトウェアに限らず、ものを作るときにはさまざまな（場合によってはお互いに矛盾する）要求条件や制約が課せられるわけだが、そんな時に過去にさまざまな事例を解決してきた先人の知恵を「パターン化」してノウハウとして身につけておけば、似たような事例に出会った時に効
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
HTML5入門：アニメーションの実装方法３種
HTML5・CSS3のような新しい技術の問題点は、HTML4やらFlashなどの枯れた技術と違ってノウハウ・ライブラリ・ツールとかがまだ十分にそろっていない事。普及のタイミングもまだはっきりとしていないこの段階で手を出せない・出しにくいと感じている人が多いのも良く理解できる。 私から見れば、逆に「こんな楽しい状況は滅多にない」わけで、商売になるかならないかは二の次にしていろいろと試したくなる。 今日作ったのは、HTML5+CSS3上で可能になる（ただし現在ではWebkit独自の拡張を含む）３つのアニメーション・テクニックの比較（左に貼付けたものがそれ、Safari/Chromiumだとすべて動く。Firefox/OperaだとDOMとCanvasのみ（ただし別ウィンドウで開かないとCanvasが動かないークロス・ドメインセキュリティのバグか？））。 詳しくはソース（参照）を見ていただければ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
