NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
Tesla の Autopilot と Netflix でオレゴンまで皆既日食を観に行った話
昨日から今日にかけて（米国時間８月１９日〜２０日）、皆既日食を観るためにオレゴンまでドライブして来たので、時系列で書いて「週刊 Life is beautiful」の特別号として配信することにしました。 一ヶ月前 かなり前から、「せっかくの機会なので是非とも行かねば」とは思っていたのですが、具体的な計画を立て始めたのは、１ヶ月前ほどです。Tesla の自動運転をたっぷりと試すにも絶好の機会です。 シアトルからだと、車で４時間ほどのところなので、日帰りも可能かも知れませんが、かなりの渋滞が予想されるので、朝の１０時までに現地に着くためには、夜中に出発しなければいけません。そこで、前日に一泊だけポートランドに泊まることにしました。 幸いなことにホテルの部屋はその時点では少しは空いており、予約は出来ましたが、料金は通常の倍の５００ドル超です。AirBnB も一応調べましたが、予約率は９７％で、泊
米マイクロソフト本社で目の当たりにしたビル・ゲイツの決断力
６月１日発売の『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』には、いくつかマイクロソフト時代のエピソードが書かれていますが、これもその一つです。この「シカゴ対カイロ」の社内抗争はマイクロソフト時代の思い出の中でも、筆頭のものです。 ◇ ◇ ◇ ビル・ゲイツの意思決定は光速 ビル・ゲイツが仕事で重要視していたのは、＂光速＂と言っても過言ではない迅速な意思決定です。これについては、どのくらい迅速だったかを象徴するエピソードを紹介します。 あれは忘れもしない1995年1月、シアトルの冬らしい小雨の降る昼下がりのことでした。米マイクロソフト本社内にはＯＳの開発に関する派閥争いがありました（ＯＳとはマイクロソフトで言うWindows Vistaだったり、アップルでいうところのOS Xなどのパソコンやスマホを動かすための基本ソフトのこと）。＂カイロ＂というグループと＂シカゴ＂という
「締め切りは絶対に守るもの」と考えると世界が変わる
2011年にインプレスジャパンから「エンジニアとしての生き方」という本を出版して以来、書籍よりは「メルマガ（週刊 Life is Beautiful）」の執筆を優先して来た私ですが、この度、とある編集者に説得されて「時間術」の本を出版することになりました。 『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』（文響社） 「時間術」とは言っても、巷に良くある「どうやって時間を効率よく使うか」という話ではなく、実際の仕事の現場において「常に締め切り通りに仕事を終える人」になるための、私なりの「仕事に対する取り組み方」を解説した仕事術の本です。 「いつも締め切りに追われている」「締め切り間際にならないと本気で仕事ができない」という悩みを抱える人たちには是非とも読んでいただきたい本です。締め切りを守れるかどうかは、締め切り間際のラストスパートで決まるのではなく、もっと前の段階での、「
米国人にとっての捕鯨・イルカ漁
ケネディ大使のイルカ漁に体する発言を「内政干渉」と大騒ぎをしている人がいるが、彼女の発言を理解するには、イルカ漁やクジラ漁が米国人にとって、どんな意味があり、何を象徴するか、を理解する必要がある。 マウイの Whalers Villege ショッピング・センターには、捕鯨博物館があり、そこには捕鯨の歴史が淡々と綴られている。鯨油や鯨蝋（げいろう）が石油の代わりを果たし、鯨ひげがプラスチックの代わりを果たした時代に、その商業的価値のために、大量の鯨を虐殺して来たこと、ラハイナの待ちが捕鯨で発展して来たことなどを、歴史の一コマとして描いている。 捕鯨博物館の出口には小さな映画館があり、鯨がダイナミックに泳いだりジャンプしたりするさまを映し、鯨の生体や、ハワイの観光産業にとっての価値を説明している。 そこにあるのは、捕鯨という「過去」と、観光資源・人類の宝としての鯨の「現在」の対比だ。 つまり、
Life is beautiful: リーダーシップについて思い出したこと
アメリカの人口の１２％が「貧困層」であり、そう言った人たちは日々の食事も満足に食べることの出来ない生活をしている、などの報道は、米国に住んでいると新聞やニュースでは良く見かける。しかし、中流以上の生活をしている我々にとってみれば、生活圏がほとんど重ならない彼らの生活の実態は、なかなか実感として捉えられず、単なる「統計データ」としてしか頭に入って来ない、というのが正直な所である。 しかし、今回のハリケーンで、彼らの生活の基盤がいかにもろいものか、そして、その数がものすごいものであることを、映像を通して目の当たりに見させられることになったことにショックを受けている人はとても多いはずだ。 今回のハリケーンの被害は、政府からの非難命令にも関わらず、逃げるための交通手段も持たず、逃げたところで避難先のホテル代も払うことが出来ない人達が「予想に反して」１０万人も市内に残ってしまったために大きくなってし
日本の大学生はなぜ勉強しないのか
今週号のメルマガ「週刊 Life is Beautiful」に向けて、「日本の大学生はなぜ勉強しないのか」という文章を書いたのだが、特に冒頭の部分はぜひとも多くの人に読んで欲しいので、引用する。 NHKニュースで「日本の大学生が予習復習のために費やす勉強時間は一日平均３９分」というデータが発表されていました。まさに「ぬるま湯大学」です。私が大学（早稲田大学）に通っていた時も似たような状況でしたがが、これが日本の国際競争力をなくしている原因の一つであることをより多くの人が強く認識すべきだとつくづく思います。 私は米国の大学（University Washington）でも勉強した経験がありますが、日本の大学とは全く異なっていました。まず第一に、予習をしていかなければ全く授業について行けません。授業にもよりますが、９０分の授業の準備に１〜３時間の予習が必要です。 例えばビジネス戦略の授業の場合
丸投げ「エンジニアもどき」はGitHubの夢を見るか？
Facebook のタイムラインに、Wireless Wire News に「海外で食べて行けるエンジニア、食べられないエンジニア」という記事が流れて来た。 簡単に言うと、外でも食べて行ける人は「自分で手を動かして何かできる人」です。 コーディングできる、設計できる、管理の仕組みを考えられる、コストカットした機材の調達の仕組みを考えられる、人員管理がうまい、プロジェクト管理できる、監査の仕組みやドキュメントを作れる、戦略を作って実行できる、という様な「自分で何かができる」人です。 反対に、「これは食べて行けない」という典型例。それは、日本国内の大手ベンダやユーザー企業勤務で、下請けや孫請けへの「丸投げ」しかできない「エンジニアもどき」や「SEというなんだか良くわからない仕事をやっている人」「仕事が部長や課長」という人々です。 基本的には、私が以前、「ソフトウェアの仕様書は料理のレシピに似て
たかが電気、されど電気
メルマガ「週刊 Life is Beautiful」で「なぜ日本は原発を止められないのか」という連載を始めた。通信業界の東京電力に相当するNTTで働いていた経験を活かし、霞ヶ関や東電のエリートが何を考えてあんな行動に走るのかを解説する。ちょうど良いタイミングで先日の「さようなら原発１０万人集会」での坂本龍一氏の「たかが電気のためになんで命をさらさなければいけないんでしょうか」という発言が注目を集めているので、このブログでもひと言書いておく。 「たかが電気」という発言に対して「電気を止めたら死んでしまう病人がいる」「真夏にクーラーがかけられなければ、熱中症で死ぬ人がいる」と噛み付いている人がいるが、これらの指摘は大間違いである。日本は、原発を止めたぐらいで、病人の生命維持装置が止まってしまったり、熱中症で死ぬ人が増えたりする国ではない。 本当の理由は別のところにある。日本経済が重度な「原発依
「空気に支配される大人」にはならないで欲しい
「孫正義ソフトバンク社長が、経団連の理事会に出席し、経団連が一致して決議しようとした原発再稼働への賛成・推進に対して、反対し、執行部の姿勢を強く批判した」と報道されている（参照）。いかにも孫さんらしい行動だが、問題視すべきなのは、３００社以上の出席者からは、孫社長の意見に対する反論も同調する意見もなかったという点。 経団連を牛耳る原発推進派の企業により「満場一致で原発再稼働に賛成する」という空気が作られるなか、その「空気作り」が許せなかった孫社長が真っ向から反対したが、残りの「空気が読める、空気に支配される大人たち」は黙ってしまったのである。 この状況は、学校で「いじめ」が起こった時に、一部のいじめっ子たちにより「あの子はいじめて良い」という空気が作られた時に他の生徒が黙認してしまう（そして、結果としていじめる側に回ってしまう）状況に似ている。そんな空気の中で「こんないじめは良くないよ」と
そしてスティーブ・ジョブズは伝説の人となった
CNetにGuy Kawasakiの "What I learned from Steve Jobs" という文章が出ているので一読をおすすめする。１２項目のメッセージを簡単に解説するとこうなる。 評論家と呼ばれる人たちは実は何も分かっていない。彼らに耳を傾ける必要はあるが、振り回されてはいけない 顧客に何が欲しいかをたずねても答えは見つからない 不連続な変化を起こせ 難しいことにチャレンジするからこそすばらしい仕事ができる デザインへの徹底的なこだわりが違いを生み出す プレゼンの時には大きなフォントと大きな画像を使え 間違いに気がついたら恥じらいもなく方向転換をしろ 「価値」は「価格」とは違う 優秀な人材は自分より優秀な人材を雇いたがる。だめな人材はもっとだめな人材を雇いたがる 本当のCEOは、自分自身で商品のデモをする 会社に必要なのは「研究者」ではなく「エンジニア」だ 「個性的」でか
エンジニアの役割
技術評論社の WEB+DB PRESS に連載中のコラムが新しくウェブで公開されたので、ぜひとも読んでいただきたい。 エンジニアの魔法の手〜面白いプロジェクトの関るには このコラムで一番注目していただきたい部分は、以下の一節。 自分が関わっているプロジェクトの方向性がおかしいと思ったら，自分がどんな立場にいようと強く主張すべきだ。会社はそんなエンジニアを必要としているし，本当に会社のためになるのであれば必ず耳を傾けてもらえるはずだ。「そうは言っても，難しいんだよ」などと逃げを決める上司は怒鳴りつけてやればよい。 会社にとって最悪なのは，「こんなものを作っても誰も使わないんじゃないか，会社の価値を上げることにつながらないんじゃないか」と思いながらも黙々と仕事をするエンジニアだ。そんなエンジニアばかり集まっている会社は絶対に市場で成功しない。プロジェクトに関わるエンジニア全員が，「自分たちがど
菅首相はなぜ色々と重要なことをとうとつに発表するのか？
ここのところ、浜岡原発の停止要請、ストレステスト、脱原発宣言、と色々と重要なことをとうとつに発表する菅首相。「党内の意思の統一ができていない」「政権維持のための人気取り」「思いつきで記者会見をしている」などの批判の声が多く聞かれるが、これに関しては、先日のテレビで古賀茂明氏（国民の負担を最小限にする東電の破綻処理の方法を提案した結果、退職勧告を受けてしまった経済産業省の人）がとても納得の出来る説明をしていたので（参照、参照）、私なりの解説をしてみる。 分かりやすく言えば、菅首相は東電（＝原発推進派）相手のオセロゲームをしているのである。脱原発の菅首相が白、あくまで原発推進の東電が黒。オセロ盤の外にいる国民の多くは白（つまり脱原発）を応援しているが、選挙の時以外は盤面の外にいるので何もできない。盤面の上には、電力会社と政治家はもちろんのこと、経産省の官僚、原子力関係の学者、経団連に属する大企
ホリエモンを有罪にしておきながら、この東電の粉飾決算を見逃すことは許されない
毎日新聞に「福島第１原発：東電が政府側に渡した文書の全文」という記事が載っているが、それを読んで少し驚いた。まさに東電と保安院がどんな形で、情報の隠蔽（正確には「原発事故の意図的な過小評価」）をしてきたかが良くわかる確固たる証拠だ（こんな文章が表に出る様になっただけ、日本も捨てたものではない）。 とくに驚愕なのは、以下の部分。 （１）地下水の遮へい対策は、馬淵補佐官のご指導の下、『中長期対策チーム』にて検討を進めてきているが、「地下バウンダリ（発電所の周りに壁を構築し遮水するもの)」は現在、最も有力な対策と位置づけ。ただし、対策費用は現状不確定であるものの、今後の設計次第では１０００億円レベルとなる可能性もある。 （２）今回の検討の過程で、政府側から国プロジェクト化の示唆(当初は国交省予算）があり、その前提で、設計着手と工事着工の前倒し案が浮上。ただし、現状では、担当府省がどこになるかも含
ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
東京電力を破産させられないような国ではベンチャー企業は育たない
ウォールストリート・ジャーナルは、「自由主義経済の国であれば、東電は破産させた上で被害者を救済するのが当然なのに、東電という会社を救済しようとしている日本はやはり社会主義」と痛烈に批判している（参照）。 私自身、昔から「日本は自由主義経済の衣をかぶった社会主義」だとは思って来たが、この何かというと「大企業や既得権者を守る」姿勢が、「大企業の正社員とそれ以外」という社会の二重構造を生み、経営陣の「逃げ切りメンタリティ」を助長し、本来ならば国の発展の原動力となるべき「ベンチャー企業」の活躍を阻止していることは注目に値する。 日本政府は、ときどき思い出した様に形だけの「ベンチャー支援」のようなものをするが、ベンチャー・ビジネスを活性化するのに最も大切なものは、国からの支援なんかではなく、「自由競争」である。日本では、既得権者が官僚と癒着して、さまざな規制や免許制度で市場への参入障壁を高くしてベン
これであなたも原子力安全・保安院
放射線量や被曝量がドラゴンボールのスカウターの数値のように一桁づつ大きくなるにも関らず、「健康には影響がない」と言い続ける原子力安全・保安院。何度も聞いているうちに、あるパターンがあることに気がついた。「被曝量を記者会見で話す時にはこうやって説明する」という虎の巻のようなものがあるに違いない。そこで、その虎の巻を彼らの過去の発言からリバース・エンジニアリングしてみた。 １μSv （マイクロシーベルト） 胸部X線検診１回に受ける放射線量（５０μSv）の５０分の１。健康には全く影響がない。 １０μSv（マイクロシーベルト） 胃のX線検診１回に受ける放射線量（６００μSv）の６０分の１。健康には全く影響がない。 １００μSv（マイクロシーベルト） 胸部X線CTスキャン１回に受ける放射線量（６.７mSv）の約７０分の１。健康には全く影響がない。 １mSv （ミリシーベルト） 放射線業務に従事する人
Life is beautiful: Androidタブレットはヨドバシカメラの「Androidタブレットコーナー」に横並びにされた時点で負けだ
今年のCESについてだが、すでに「感心した商品」と「自分も関係していてうれしかった発表」に関しては書いたので、今回は「これはだめかな」と思ったもの。 まずその筆頭は「３Dテレビ」。これ以上大きくすることも薄くすることも解像度を高くすることもできなくなってしまった「成熟しきった」デバイスであるテレビに何とか付加価値を付けようという気持ちも分からないでもないが、正直言ってこれはいらない。CESに出品されている最新の３Dテレビを見てもあまり感動しないし、そもそも目が疲れる。今年の末あたりになって、「結局３Dテレビって何だったの？」という話になると私は見ている。 二番目は「Android」。前にも書いたが、これから家電やスマートフォンの市場に新規参入しようというアジアのメーカーにとっては、Androidを活用して短い開発期間と低コストで「安かろう悪かろう」のデバイスを薄利多売で売りまくるという戦略
google appengine に関してひと言
ここ数日、Twitter上で appengine に関する発言をたくさん目にする。それを見る限り、「注目をされてはいるが、手を出しかねている人が多い」というのが現状だろう。そこで、私からもひと言。 App Engine は純粋なソフトウェア・エンジニアにとっての天国 私自身、色々な開発環境を試して来たが、私のようにプログラミングが大好きで、新しい言語や環境を学ぶのが楽しくて仕方が無いエンジニアにとっては、「App Engineは天国」というのが正直な感想。SQLやRailsのように一見開発効率を良くしてはくれるが、直感的に実行効率とかが把握できない「補助輪付きプログラミング」と違い、App Engine上でのプログラミングは、ちょっと手を抜くとすぐに実行効率の悪さとして跳ね返ってくる「一輪車プログラミング」。 新しい言語を学ぶのが苦ならApp Engineは避けた方が良い 現時点で、Pyt
Google App Engine入門：Entity Groupとトランザクション処理
今週に入ってから、ようやく少し本気でGoogle App Engineでプログラムを書き始めている私だが、ようやく Entity Group の使い方が分かって来たので簡単に解説してみる。 Entity Groupとは、一口で言えば「トランザクションを使ったアトミックな読み書きの対象となるEntity（＝データベース上のオブジェクト）の集まり」である。 イメージとしては、まず「一つのハノイの塔を三人で同時に遊んでいる姿」を思い浮かべると分かりやすいかも知れない。全くのルールなしで皆で同時に遊ぼうとすると、腕が交錯してぐちゃぐちゃになってしまう。 そこで、「ある時点でハノイの塔ボード（三つの棒を支えている水平に置かれた板）に触ることが出来る人は常に一人。一度ボードに触った人はすべての円盤をいずれかの棒の位置に置いた状態にしてからしか手を離してはいけない。もし自分がハノイの塔に触りたい時に、す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
