ＭＢＡで学べることより大切な、たった一つの人生の掟
6月1日に上梓した拙著『なぜ、あなたの仕事は終わらないのか？』（文響社）からの引用です。 ◇ ◇ ◇ 突然ですが、私はここでみなさんにお詫びをしなければいけないことがあります。 それは、ここまで長らく私の人生がトントン拍子にうまく進んできたかのように書いてきてしまったことです。 自慢話のようで鼻についた方もいたでしょう。そういう方にはお詫びを申し上げたいと思います。不快な思いをさせてしまったことと同時に、私の人生も決してうまくいったことばかりではなかったからです。 そういった話――すなわち、何かを成し遂げたり幸せな人生を手に入れたりするには、「好きなことに向き合い続けること以外に方法はない」という話――をこれからしていきたいのですが、私の人生の最大の試練は、初めてのスタートアップであるUIEvolutionを立ち上げた直後に訪れました。 起業直後から本当に失敗の連続でした。良いものを作って
Life is beautiful
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
日本の大学生はなぜ勉強しないのか
今週号のメルマガ「週刊 Life is Beautiful」に向けて、「日本の大学生はなぜ勉強しないのか」という文章を書いたのだが、特に冒頭の部分はぜひとも多くの人に読んで欲しいので、引用する。 NHKニュースで「日本の大学生が予習復習のために費やす勉強時間は一日平均３９分」というデータが発表されていました。まさに「ぬるま湯大学」です。私が大学（早稲田大学）に通っていた時も似たような状況でしたがが、これが日本の国際競争力をなくしている原因の一つであることをより多くの人が強く認識すべきだとつくづく思います。 私は米国の大学（University Washington）でも勉強した経験がありますが、日本の大学とは全く異なっていました。まず第一に、予習をしていかなければ全く授業について行けません。授業にもよりますが、９０分の授業の準備に１〜３時間の予習が必要です。 例えばビジネス戦略の授業の場合
反面教師としての三木谷発言
kobo touch の初期不良問題に対する三木谷氏の発言にはあまりにも学ぶことが多かったのでひと言。ソースは、日経ビジネス Digital の「細かいことで騒いでいるのは少数派ですよ」という記事。 特に問題なのは冒頭の、 ――色々トラブルが起きましたが現状は。 三木谷：いや、いいですよ。初期設定の問題で細かいトラブルはあったけど、2日以内に解消できたし、コールセンターも24時間対応にしたし。アクティベーション（利用できる状況にセットアップすること）した人が購入者全体の95％を超えていますからね。そして、何よりコンテンツが売れまくっている。出版社の人に聞いてみたほうがいいですよ。僕は出版社の驚きように驚いている状況です（笑）。 販売台数は10万台弱程度で、年内目標は100万台。だいたいそこまでいけそうです。やはりユーザーインタフェースがいいんですよね。直感的にできるし、変なボタンもないし
高速増殖炉「もんじゅ」に関するジャイアンとのび太の会話
米エネルギー副長官のポネマン氏が日本を訪問したそうである（参照）。このタイミングで来ることにはとても重要な意味がある。二国間の会話を、ジャイアンとのび太の間の会話に例えると、こんな感じになる。 ジャイアン：のび太、お前まさか、もんじゅを諦めようなんて考えていないよな。 のび太：そ、そんなことないよ。 ジャイアン：それならよし。もんじゅは、二国間の共同プロジェクトなんだから、勝手に辞めてもらってはこまるんだ。 のび太：分かってるよ。でも、福島の事故以来、みんな核アレルギーになっちゃって、もんじゅのことも、とても怖がっているんだ。 ジャイアン：そりゃそうだよ。今から高速増殖炉を米国内で作ろうとしたら猛反対を受けるさ。だからこそ、もんじゅが大切なんだよ。 のび太： でも、それって... ジャイアン：ずるいっていうのか。お前、誰が北朝鮮や中国からの脅威から守ってやっていると思っているんだ。 のび太
日本国の財政状況を家庭にたとえてみると
「米国の財政状況を一般家庭に例えてみると」というビデオが知り合いから回って来たので（下に貼付けてある）、参考までに同じ手法で、日本国の財政状況を一般家庭に例えてみた（参考文献）。 収入（年間）： ４６０万円 出費（年間）： ９０３万円（２１９万円が借金の返済、６８４万円が生活費） 借金（累積）：９０００万円 赤字国債にしろ、使用済み核燃料にしろ、先の世代にツケを回し過ぎである。
可視化された Android OS アップデート問題
先日、ここでも触れた Android OS のアップデート問題。Android 端末がどのくらいの勢いで「陳腐化（OSのアップデートから見放されること、セキュリティ・パッチの配布が止まること）」するかをとても分かりやすく表現しているブログ・エントリーを見つけたので紹介する。 Android Orphans: Visualizing a Sad History of Support iPhoneの場合（上から４つ）は、新機種が発売されてから３年間は陳腐化することはない（緑色）が、Android 端末の場合、大半がすぐに陳腐化（黄色から赤）してしまっていることが良く分かる。 特に問題なのは、発売当初から１〜２世代前のバージョンを搭載した「生まれた時から陳腐化」している端末。中でも Motorola Cliq XT が最悪で、発売された時から２世代遅れており、発売後３ヶ月で３世代遅れになり、その
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
Oracleの「Android訴訟」についてひと言
今日のこちら（米国西海岸）でのもっぱらの話題は、Oracleの「Android訴訟（詳細）」だが、これに関しては、私も含めて「やはり来たか」と見ている専門家は多い。 そもそも、スマートフォン以前の携帯電話用のJavaがプラットフォームとして成功しなかった理由の一つは、J2MEが根っこのところで、NTTドコモ独自のDoJaとモトローラ主導のMIDPに分岐してしまったことにあるし、同じJ2ME間でも実装の差異が大きく "write once, run everywhere" が机上の空論になってしまったことにある。Sunがちゃんとリーダーシップを発揮できなかったためである。 その意味では、J2ME/MIDPとコンパチビリティがなく、Sunから正式にJavaをライセンスしていないAndroidはけしからん、というのは（今はOracleの一部になった）Sunから見れば当然のこと。 「J2MEの時に
HTML5 Widget入門：あなたにも作れるiPad用Widget
今朝の「iPadでHTML5 Widgetを走らせて遊ぼう」に対して、「もう少しWidgetについて知りたい」との声が聞こえてきたので、「Widget入門編」を書いてみようかと思う。 Widgetとは何か？ 先のエントリーで書いたが、ひとことで言えば「パッケージ化されたウェブアプリケーションである」。通常のウェブアプリは、特定のURLにアクセスすることにより走らせるが、Widgetの場合は、.wgt のエクステンションを持つWidgetファイルをダウンロード＋インストールした上で、それを起動する。 Widgetファイルの中身は、HTML+CSS+JS+メディア・ファイルで構成されており、それをZIP圧縮して、エクステンションを.wgtに変更しただけのものである。 なぜそんなことをするかと言えば、（１）オフラインで動かしたい、（２）通常のデスクトップアプリの感覚で起動したい、（３）パッケージ
「金メダリストは『練習が楽しくてしかたがない』からこそ強くなれた」説
技術評論社の WEB+DB PRESS 向けに連載コラムを書きはじめたのだが、その最初のコラムがウェブで公開されたので、リンクを張っておく。 第一回 一生の仕事を選ぶということ 担当の人の「この業界で働く若手のエンジニア向けのメッセージ」を書いてほしいとのリクエストに答えるつもりで書いたのだが、「説教臭くなくて、ちゃんと伝わる」文章を書くのが難しくて結構苦労したので、ぜひとも読んでいただきたい。 この話の核となる部分は、私の「マラソンで金メダルを取る人たちって『過酷な練習に耐える精神力がある』から頂点に立てるんじゃなくて、『他の人たちにとっては苦痛でしかない練習が実は楽しくて仕方が無い』から頂点に立てるんじゃないか」というセオリーにもとづいている。高橋尚子が現役のころの話を聞いていて、つくづく「本当にこの人は走ることが好きなんだなあ。だからこそ誰よりもたくさんの練習をすることができて、その
Life is beautiful: とある家電メーカーでの会話：クラウドテレビ編
ある日本の家電メーカーでの会話。まずは副社長室での会話から。 技術部長：副社長、来年度の予算の件はどうなりましたか 副社長：大丈夫だと言っただろう。台湾・中国からの追い上げは相変わらず激しいが、テレビは家電ビジネスの要だ、経営陣としてもここだけは手を抜けない。来年も君たちにがんばってもらわなければならない。 技術部長：もちろんです。そのあたりは現場のエンジニアたちも強く感じてると思います。ちなみに、メールに書いてあった「戦略の変更」って何ですか？ 副社長：そのことなんだが、経営会議でも持ち上がったんだが、台湾勢と戦うには、我が社にしかできない「差別化要因」が必要だ。価格競争では彼らにかなわない、消費者にとって目に見える価値を提供して、台湾製品よりも３割・４割増の値段でも喜んで買ってもらえるテレビを作らなければならない。私は、キーワードは「クラウド」だと思っている。 技術部長：え？「ク、クラ
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
「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の発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
なぜ「iPhoneキラー」がことごとく失敗するのか
MBAの授業の一環で、"Marketing Myopia" (by Theodor Levitt) という１９６０年に書かれた論文を読む機会があったのだが、色々とうなずけるところがあったので、メモ代わりに。 家電メーカーのような技術系の会社は、どうしても技術系の人が経営者になりがち。技術系の人は（私も含めてだが）色々な問題を論理的に解決しようとする。技術的な問題を解決するためにはこのアプローチはとても有効だが、消費者心理のように曖昧で非論理的なものには適用できない。 技術系の経営者が陥りやすい失敗は、自分がコントロールできる分野、すなわち、技術的に難しい問題を解決することにばかりエネルギーをそそぎ、非論理的で簡単にはコントロールできない消費者の動向のようなものに十分な注意を払わないこと。 その結果、「消費者はどのみち論理的な行動なんてしないんだから、それに関して色々と戦略を立てたところで無
使い勝手の悪さはユーザーにとってのコストだという話
今読んでいる「Marketing Management」にこんな文章がある。 Customers buy benefits, not products. The benefits a customer receives from a firm's offering, less the costs he or she must bear to receive those benefits, determined the offer's value to the customer. 消費者が買うのは「商品」ではなく、「その商品を通して得られるもの」から「それを得るために払わなければならないさまざななコスト」を差し引いた「利益」である、という話。 ここで強く認識しておくべきなのは、その「コスト」とは単なる商品の購入のために支払うお金だけではなく、その商品を得るためにする労力（例：買い物に行く時間
そば屋の味はカレーライスを売り始めた時から下降線をたどる
今日もいくつかPhotoShareに関するブログエントリーを見つけたのだが、その中でもとてもうれしかったのがこれ。 あとはタイトルを付けて「完了」ボタンをタップするだけ。めちゃくちゃ簡単に投稿できます。【 iPhoneのキラーアプリになりそうな写真共有アプリ「Big Canvas PhotoShare」（もとまかApp Selection 第７回） - もとまかのiPhone・iPod touch戯れ日記より引用】 増井君と一緒にPhotoShareのアーキテクチャの設計した際に、もっとも力を入れたのが「どうやったらこれ以上簡単にすることは不可能なぐらいに簡単に写真を投稿できるようにできるか」という部分。その意味では、「めちゃめちゃ簡単」という言葉は最高の褒め言葉。 この手のアプリを作っていると陥りがちなのが「機能のてんこもり」。特に他のサービスと比較されることを意識し始めてしまうと、「敵
Life is beautiful: 「へんな会社」と「出るクギを打つ」社会の話
へんな会社を貫くために、普通の会社のやり方をよく理解しておくというのは必要なんじゃないか、とこれははてなに限らず思う次第。【Kousyoublog | はてな移転で中の人が言うべきことと言ってはいけないことより引用】 この手の発言こそが、まさに「出るクギを打とうとする」行動。近藤さんに関してはそんな心配をする必要は全くないが、他の若い人たちが「やっぱり『普通の会社のやり方』をちゃんと勉強しなきゃ」などと誤解してはいけないと思い一言。 上場している企業と違い、はてなのように、ごく少数の株主が所有している会社の場合、株主・取締役の了解さえ取れれば、大幅な経営方針の変更は自由にしてかまわない。それが非上場であることの大きな利点だ。 今回の場合、「米国からは一時撤退し、多少会社の規模が小さくなっても良いから、京都にもどって落ち着いた環境でもう一度もの作りに専念する会社としてやりなおす」という決定は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google+ はどこに行こうとしているのか？
