米マイクロソフト本社で目の当たりにしたビル・ゲイツの決断力
６月１日発売の『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』には、いくつかマイクロソフト時代のエピソードが書かれていますが、これもその一つです。この「シカゴ対カイロ」の社内抗争はマイクロソフト時代の思い出の中でも、筆頭のものです。 ◇ ◇ ◇ ビル・ゲイツの意思決定は光速 ビル・ゲイツが仕事で重要視していたのは、＂光速＂と言っても過言ではない迅速な意思決定です。これについては、どのくらい迅速だったかを象徴するエピソードを紹介します。 あれは忘れもしない1995年1月、シアトルの冬らしい小雨の降る昼下がりのことでした。米マイクロソフト本社内にはＯＳの開発に関する派閥争いがありました（ＯＳとはマイクロソフトで言うWindows Vistaだったり、アップルでいうところのOS Xなどのパソコンやスマホを動かすための基本ソフトのこと）。＂カイロ＂というグループと＂シカゴ＂という
iOS8が加速する家電メーカーの新陳代謝
メルマガの読者に向けて、今回のAppleによるWWDCでの発表に関する解説を執筆中ですが、それを書きながら強く認識したのが、２００７年に登場したiPhoneが携帯電話機メーカーの勢力図を大きく変えたのと同じ様な大変化が、今度は家電メーカー全体に起ころうとしている、という事実です。 iPhone が証明したのは、ハードウェアの世界においても勝負の鍵となるのはソフトウェアであり、世界最高のプログラマー集団を抱えた企業しか、この業界では利益を上げられない、勝ち残れない、ということです。 日本のメーカーは、NTTドコモによる iモードで、世界で最初にインターネットに繋がる携帯電話を作っておきながら、iPhone の登場とともに市場から淘汰されてしまいました。 これに関しては、「日本は独自企画にこだわったから負けた」と思っている人が多いのですが、それは誤解です（日本の携帯電話市場のことを最初に「ガラ
誰も言いたがらない「Sony が Apple になれなかった本当の理由」
Sony や Panasonic が家電のコモディティ化で大赤字を出して苦しむ一方で、今や株価総額が日本の大手家電メーカー８社の株価総額の３倍以上にもなった Apple（参照）。 この差に関しては、私も含めて、リーダーシップの欠如だとか、ゼネコン型のソフトウェア開発スタイルが悪いとか、ソフトウェアの重要性を理解しない経営者、などのさまざまな考察がされているが、その根底にあるのは、「大企業は一度正社員になった人は会社が倒産の危機にでもさらされない限り解雇してはいけない」という日本特有の雇用スタイル。 家電業界の成り立ちは、日本の家電メーカーが業績をのばしていた高度経済成長期とは大きく変わってしまった。ソフトウェアがものすごく重要になったのはもちろんのこと、ハードウェアに関しても、中国を含む東南アジアが「世界の工場」となった今、「何を自分で作り何をアウトソースするか」がコスト削減の上でも差別化
福島第一にはメルトダウンした核燃料よりももっと危険なものがある
菅政権の内閣官房参与で、福島第一原発事故対策や原子力政策のアドバイザーだった田坂広志・多摩大学大学院教授が原発事故の教訓や今後の課題について語った講演「パンドラの箱」が公開されているので下に貼付けておく。 原子力発電を利用するというのは、その国全体にとって何を意味するのかをとても的確に表しているので、原発に賛成の人も反対の人もぜひとも見ていただきたい。特に使用済み核燃料の問題が技術的な問題ではなく社会的な問題であること、そして福島第一でもっとも危険な存在は実はメルトダウンしてしまった１〜３号機の核燃料ではなく、４号機のプールにあって取り出す事もままならない大量の使用済み核燃料であること、などが専門家の立場から的確に語られている（ビデオの40:00〜45:00あたり）。万が一４号機のプールがこれから起こる地震で壊れたりしたら、関東にも人が住めなくなるのだ。 １時間強と少し長いので、忙しい人は
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
東京電力を破産させられないような国ではベンチャー企業は育たない
ウォールストリート・ジャーナルは、「自由主義経済の国であれば、東電は破産させた上で被害者を救済するのが当然なのに、東電という会社を救済しようとしている日本はやはり社会主義」と痛烈に批判している（参照）。 私自身、昔から「日本は自由主義経済の衣をかぶった社会主義」だとは思って来たが、この何かというと「大企業や既得権者を守る」姿勢が、「大企業の正社員とそれ以外」という社会の二重構造を生み、経営陣の「逃げ切りメンタリティ」を助長し、本来ならば国の発展の原動力となるべき「ベンチャー企業」の活躍を阻止していることは注目に値する。 日本政府は、ときどき思い出した様に形だけの「ベンチャー支援」のようなものをするが、ベンチャー・ビジネスを活性化するのに最も大切なものは、国からの支援なんかではなく、「自由競争」である。日本では、既得権者が官僚と癒着して、さまざな規制や免許制度で市場への参入障壁を高くしてベン
日本のケータイが「ガラパゴス化」した本当の理由
「ガラパゴス」という言葉が今年の流行語大賞の候補に選ばれたということを聞いていたので、密かに受賞しないかと期待していたのだが、残念ながら大賞は逃したようだ（もし大賞に選ばれていたら、私が受賞することになったのかどうかの疑問はこれで解けずに終わってしまった）。しかし、この言葉をずいぶん前から使っている私としては、この言葉が一人歩きしているようでなんとも言えない気持ちなのでひと言。 まず最初に断っておくと、私が２００１年のCTIA（米国の携帯電話業界で一番大きなカンファレンス）のスピーチでこの言葉を使った時は、単に日本という「単一民族で、国民の大半の生活レベルが同じで、家電とか携帯電話のようなガジェットに流れるお金が比較的多い」という特殊な環境で、iモードを中心に「ケータイ・ライフスタイル」が異常なスピードで進化をとげていることを表して、「ガラパゴス現象」と呼んだだけのこと。決してネガティブな
HTML5時代の「運営しやすいアーキテクチャ」の話
増井君と二人でPhotoShareというサービスを立ち上げてもう１５ヶ月になるが、いろいろと学んだことがある。その中でもつくづく思うのは、サービスを作り上げる段階よりも、運営のことを考えた設計が大切なこと。つまり、メンテナンスしやすい、テストしやすい、多少のミスをしても大丈夫、こまめなアップデートがしやすい、作業分担がしやすい、などなどである。 そんななかで強く感じるのは、「AJAXを見た目や使いやすさの面だけに利用するだけでなく、『運営しやすいサービス』を作るのに利用できないか」ということである。 私のイメージするアーキテクチャを図にするとこんな感じになる。 まず一番の特徴は、テンプレート等を利用したHTMLのダイナミックな生成をすべてやめて、データ（JSONもしくはXML)だけをダイナミックに生成するようにし、HTMLはスタティック・ファイルをサーバー側に置いておく（上の図で、CSS,
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
「ブログのエントリーは多い方がページビューが稼げる」という説を統計学的に検証してみた
ここのところ統計学を少しまじめに勉強しているのだが、そこで身につけたばかりのregression analysis（回帰分析）の手法を使って、「ブログのエントリーは多い方がページビューが稼げる」という説が本当かどうかを検証してみることにした。 まずは、このブログの過去２４週間の週ごとのエントリーの数とページビューの数を調べ、エントリーの数をX軸に、ページビューの数をY軸においてプロットしてみる。それだけでもなんとなく傾向があることが分かるのだが、これを最小二乗法を使って、直線で近似してみるとこんな感じになる。 直線の方程式は、Y = 44109 + 3405*X （Y:ページビュー、X:エントリー数）。つまり、このブログの場合、エントリーを書こうが書くまいが、週あたり約４４０００のページビューがあり、エントリーを一つ書くごとに約３４００ページビューづつ増えて行くということになる。 もちろん
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
GoogleはなぜAndroidやChrome OSを無料で配布するのか？
先週「Androidと家電」というタイトルで講演をさせていただいた私だが、そのプレゼンのキーポイントは、「なぜGoogleはAndroidを無料で配布するのか？」。それを私なりに説明するための資料として作ったスライドが以下の二枚。 まずこれは、MicrosoftとIntelがパソコン・ビジネスを育てるためにした「コモディティ戦略」を図式化したもの。IntelとMicrosoftで協力してCPUとOSを部品化・規格化することにより、誰でもパソコンを作れる様にしたのがそれ。これにより、パソコン・ビジネスへの参入障壁が減り、パソコン・メーカーが乱立。差別化がしにくい部分（つまりIntelとMicrosoftがほぼ独占的に提供するCPUとOS以外の部分）で激しいコスト競争が起こり、パソコンのコモディティ化が一気に進んだのは皆さんの記憶にも新しいはず。 特筆すべきなのは、MicrosoftもInte
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
