「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。

発見された、Intel製のCPUの脆弱性（Meltrown と Spectre）について、「八百屋の看板娘の年齢をどうやって探り出すか」という問題に置き換えて説明してみました。エンジニアでない人でも分かるようにしたつもりなので、是非ともご覧ください。 少し前に、Intel の CPU に脆弱性が見つかり、大騒ぎになりました。脆弱性と言うと、なんだか難しそうな言葉ですが、わかりやすく言えば、セキュリティ上の弱点、のことです。 Intel はバグではない、と言っていますが、脆弱性があったことは事実で、Microsoft や Apple が慌てて OS に修正を加えました。さらに、その修正のために、パソコンの速度が遅くなる、という問題も生じ、何が起こっているのか不思議に感じている人も多いと思います。 そこで、今回は、その脆弱性とはどんなものだったのかを簡単に説明しましょう。 ここにちょっと変わっ

ジャンプ、マガジン、サンデーに代表される週刊漫画雑誌の売り上げが激減しています。 ２０年前には６５０万部を売り上げた週刊少年ジャンプ すら、毎年のように１０％を超える売り上げ減に見舞われ、今や２００万部を切ろうとしています（データソース：日本雑誌協会）。 新聞社も週刊誌も売り上げの激減に悩まされています。特に、駅売りに頼っていたスポーツ新聞ビジネスは、どこも破綻状態で、数年後には、「スポーツ新聞」というジャンルそのものがなくなってしまうと言われています。 理由は明確です。人々のライフスタイルが大きく変わったからです。 ２０年前、通勤・通学する人々の多くは、漫画・雑誌・スポーツ紙を読んでいました。駅のホームには必ずキオスクがあり、そこで雑誌や新聞を売っていました。朝、通学途中に読んだ漫画を友達と回し読み、それがごく普通の高校生・大学生の姿でした。 今はそんな人たちはほとんど見かけません。誰も

６月１日発売の拙著『なぜ、あなたの仕事は終わらないのか　スピードは最強の武器である』からの引用です。 ◇　◇　◇ スマホアプリが アップデートを繰り返す理由 「仕事のスピードを追求したら質が落ちてしまう。それじゃダメだ」 そう思われている方もいると思います。たしかに速さを求めると質は落ちます。大抵の仕事がそうであるように、スピードと質はトレードオフ（片方を取るともう一方は取れない）です。質の悪いものを出さないようにじっくり時間をかけて、ときには徹夜で頑張る人もいるでしょう。 けれども質を追求した結果、締め切りに間に合わないような仕事の仕方をしていては本末転倒です。締め切りに間に合うことが明らかな状況であれば、質を高めるために時間を使うのは間違っていません。問題なのは、まだ仕事が終わる見通しが立ってもいないのに、質を高めるためにあれこれ工夫を凝らそうとすることです。 みなさんが普段使っている

６月１日に発売したばかりの『なぜ、あなたの仕事は終わらないのか　スピードは最強の武器である』ですが、こうやって編集者の指示通りに書籍の内容を少しづつ紹介するブログの記事を書いているだけですが、順調にアマゾンでの順位が上がっています。初日はベストセラーランキングで２０位、２日目は７位、現在（３日目の朝）は３位です。 今は広告の時代ではなく、ソーシャルマーケティングの時代だということは理解していたつもりですが、これほどまでに効果的というのは少し驚きです。ちなみに、今日から新聞広告も始まるそうですが、そちらは効果測定が難しいのが難点です。 以下は、本日の抜粋です。 ◇　◇　◇ 「出勤前の服選び」で疲れてどうする 効率化といえば、「世界の偉人はいつも同じ服を着ている」ということが一部で知られています。たとえばフェイスブックのマーク・ザッカーバーグはいつもグレーのＴシャツにジーンズをはいています。ア

先日「Kindle ダイレクト・パブリシングを試してみた」というエントリーに書いた通り、私としては初のKindle 向けの電子書籍を発売したのだが、いきなり失敗をしてしまった。 出版したのは、下の二冊。 週刊 Life is Beautiful 創刊号（２０１１年８月分） 週刊 Life is Beautiful Vol.2（２０１１年９月分） メルマガの読者の協力も得て、Kindle、iPad版 Kindle、Android版 Kindle のそれぞれで読めることを確認した上で出版し、ブログでアナウンスをした。滑り出しは上々で、出版して２時間もしないうちに、創刊号がヒット商品の１位になり、続いて Vol.2 が２位に。全体のランキングでも創刊号が９８位に食い込む。 「この調子ならば全体のランキングでも上位を狙える！」と思ったとたんに問題が起こった。 購入した読者の１人から「購入した電子書

アップルが１月の１９日に何やら「教育関係」のアナウンスメントをするという話が報道されていたが（参照）、これを見て思い出したのが、私が少し前から漠然と考えている「教科書革命」。 教育はどの国にとってもとても重要だが、今の教科書の在り方は色々な意味で時代遅れである。 まず第一に、教科書はすべてデジタルで配布されるべきである。特に成長期の小中学生に重いカバンを持たせることは、背骨の発育上とても良くない。すべてデジタル化し、子供たちはタブレット一枚を持って、もしくは手ぶらで（タブレットは家と学校に一枚づつ持っておき、ネット経由で同期すれば可能）学校に通うという時代を実現すべき。 ここまでならば多くの人が既に考えているだろうが、同時に私が実現したいのは、義務教育機関中の教科書すべてのパブリック・ドメイン化である。パブリック・ドメインであれば、子供たちが無料で手に入れることができるだけでなく、教育者自

子供のころはテレビで放送されていることは１００％正しいと信じていたが、大人になるにしたがい、（１）専門家の中でも意見の食い違いがあること、（２）マスコミは勉強不足でしばしば間違える事、（３）危機の際に政府とか企業は悪いニュースをオブラートにつつんで伝える傾向があること、などを学んだ。 そこで問題となるのが、今回の原発災害のような時に、「誰をどこまで信じて良いのか」ということである。（a）日本政府は３０キロ圏内が危険地域であると言い、（b）米国政府は８０キロ圏内に米国人は立ち入っては行けないという。原発から北西方向にある飯舘村などは、３０キロメートル以上離れていても、空間の放射線量も土壌の放射線汚染度も高いが、（a）日本政府は「ただちに健康に影響はない」と言い続けているが、（b）IEAE (International Atomic Energy Agency)は住民を避難させるべきと言う（こ

ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt

今日は日経BPのセミナー（参照）で、iPadと電子出版の未来について講演をしてきた。私の講演の内容に関しては、一両日中にネットに上がると思うのでここには書かないが、この講演およびその準備段階を通して学んだとても大切なことを一つ書こうと思う。それは日本の出版社に迫る「コンテンツのガラパゴス化の危機」である。 午後の部でヤッパの伊藤氏の講演を聞いていて少し疑問に思ったので、フォーマットのオープン化に関する質問をした私だが、彼の「まだコンテンツの数が少ないのでオープン化を考慮する必要はない」という返答でヤッパの狙いが明らかになった。セルシスと同じく「クローズドなフォーマットによるコンテンツの抱え込み」である。 ここまでフォーマットのオープン化（すなわち誰でもビューアーをライセンス・フリーで作れること）の大切さが叫ばれている今、時代に全く逆行するビジネスモデルだが、漠然とした危機感を抱いてはいるが

先日のセミナーでも少し触れた、「Googleのコモディティ戦略」。インプレスからこのたび出版される「Google Chrome OSー最新技術と戦略を完全ガイド」の「戦略」の部分に共著者の一人として寄稿したのでここで紹介させていただく。 Chrome OSにせよAndroidにせよ、OSをGoogleが無料で提供するには深い意味があるのだから、それをちゃんと理解した上で、自社のデバイスに採用するかしないかを「経営判断」として決めるべき。「他のメーカーも載せはじめたから」とか「自分だけ乗り遅れたくないから」ぐらいな安易な気持ちで始めると、「実際やってみたら得をしたのはGoogleだけ」という結末になりかねないので慎重にすすめるべき。 ２年ほどiPhone向けのアプリを作って来た結果、最近強く思うのは、テレビなどの据え置きがたの家電にアプリをダウンロードして走らせる、という発想自体が根本的に間

先日の「とある家電メーカーでの会話：クラウドテレビ編」と「もし日本のメーカーがiPhoneを発売していたら」、ユーザー不在・カタログスペック重視のもの作りの問題点を浮き彫りにしてみたつもりだ。「こんな場面につい最近も出くわした」という意見から、「こんなにはひどくない」というフィードバックまでいただけたが、多かれ少なかれ、これに近い状況が現場で起こっており、それが日本のメーカーの国際競争力を奪う原因の一つになっていると私は見ている。 日本の家電・半導体メーカーが米国のメーカーと激しい貿易摩擦を起こしていた８０年代、日本の企業の強さはまさにこの「スペック重視のもの作り」にあったことは事実である。日本人の勤勉な気質と日本流の経営スタイルがちょうど良い案配に働き、より集積度の高い半導体、より画質のきれいなテレビ、よりハイスペックな家電を欧米よりもはるかに低コストで効率良く作ることにより、日本が一気

Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En

気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者

ここの所、「クラウド」という言葉が一人歩きしているようなので、言葉の定義を明確にして業界関係者間のコミュニケーションをスムーズにすることを試みてみたい。 クラウド・コンピューティング もともとは、すべての計算をクライアント側で行う「デスクトップ・コンピューティング」に対して、（しばしば雲の形で図式化される）ネット上のサーバー側で計算してしまうことを表すために生まれた言葉。しかし、後述の「クラウド・サービス」の普及とともに狭義・広義・誤用・バズワード化が進み、今や「ユビキタス」と同じぐらい使っている人によって意味が異なる言葉になりつつあるので要注意。 クラウド・サービス アマゾンのec2、GoogleのApp Engineのようにサーバーの能力を従量課金方式で提供するサービスのこと。自社サーバーやレンタルサーバーと比べて、初期投資の面でもスケーラビリティの面でも優れていることが特徴。 クラウ

一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以

Ruby on Railsに代表されるDRY（Don't Repeat Yourself）スタイルのフレームワークは、手っ取り早くサイトを立ち上げるのにはとても便利だ。特にRailsのActive Recordの様に、ランタイムにダイナミックにコードや設定ファイル（もしくはそれに相当するもの）を生成してくれる仕組みは、情報を一カ所のみに記述することによりミスを減らすという意味でもアジャイルな開発という意味でも重要である。 ただ、この手のフレームワークを使う場合に一つ気をつけなければならないのは、それがスケーラビリティの面で商用に耐えられるものか、という点である。特に、その手のダイナミックなコードや設定ファイルの生成（Railsの場合だとデータベース上のテーブルのスキーマに基づいたActive Recordクラスのダイナミックな生成）が、最初にサイトにアクセスが来た時に一度だけ実行されるもの

題名だけで私が何を伝えたいかはほぼ理解していただけると思うが、私としては、高速道路の全面無料化には、 今後の日本経済にとってプラスになるとは思えない 環境に優しくない さらなる渋滞をまねく その財源がどこにあるのか不透明 という理由で反対。どうせやるのであれば「エコカーとして国から認定された車のみ無料」とすべきだと思う。これにより、 日本の消費者の間でエコカーの人気が上がる →日本の自動車メーカーのエコカーへの開発投資意欲が上がる →日本にエコカー関連の知的財産が蓄積する →日本の自動車メーカーの海外での競争力が増す →日本の景気が良くなる という相乗効果を狙う。財源はガソリン税および無料対象外の車の高速道路使用料金を当てる。 さらに、エコカーの基準を毎年厳しくすることにより、「日本で自動車メーカーを経営しようとしたら、毎年厳しくなる環境基準をクリアする車を作りつづけない限りやっていけない

Google App Engine向けのアプリを作る際に最初に悩んだのはフレームワークの選択。Google App Engineにはwebappという最低限の機能を持ったフレームワークが付いて来るが、Python使いの人たちの間では、DJangoというフレームワークが広く使われているらしいし。かといって、あまり大きなフレームワークを使うと、パフォーマンスのチューニングとかもしにくくなるし、フレームワークそのもののバグや制限に悩ませられる可能性もある。 そんな中で増井君が見つけてくれてまず試したのが、Junoというフレームワーク。DJangoと比べると遥かに小さく、WebappよりもURLのルーティングのメカニズムとかが充実している。 そこで一旦はアプリをJunoの上で作り始めたのだが、Junoのソースコードを見ているうちにいろいろと気に入らないところが出て来た。不必要にオプションが多いし、