タグ

ブックマーク / satoshi.blogs.com (18)

  • NTTの株価総額が世界一だった時に、Microsoftに転職した理由

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

    cubed-l
    cubed-l 2018/11/27
  • アウトプットに遠慮や忖度が必要ない理由

    9月22日発売の「結局、人生アウトプットで決まる 自分の価値を最大化する武器としての勉強術」からの引用です。 ◉自分では気づかない「好きなこと」の見つけ方(73ページ) これまで、「好きなこと」を追求すべきということをお伝えしてきました。すでに好きなことが見つかっているのであれば、さっそくアウトプットを始めてみましょう。 しかし、実際のところ「そうはいっても、好きなことが見つからないんだよなぁ」と思っている方も多いのではないでしょうか。「趣味と言える趣味がない」「『休みの日は何しているの?』と聞かれてもマンガを読んで、べて、寝て終わり」などなど……。 また、親や先生から「勉強しろ」と言われとりあえず勉強して、いい大学に入って、就職の人気ランキング上位の会社や流行りの業界には入ったものの、当は何が好きなのか未だにわからない、という人は少なくないはずです。 私は幸運なことに、好きなことを

    cubed-l
    cubed-l 2018/09/24
  • 橋下発言は女性と軍人に対する大いなる侮辱だけでなく、日本人全員の顔に泥を塗る行為だ

    氏の慰安婦容認発言は、海外でも取り上げられている。特にBBC の記事は非常にストレートだ。冒頭の部分を直訳するとこうなる。 橋下曰く「日の従軍慰安婦は必要であった」 日で注目を集めている政治家が、第二次世界大戦中に女性達を強制的に売春婦にしたシステムのことを「必要だった」と表現した。 大阪府知事である橋下徹氏によると、従軍慰安婦は命をかけて戦う兵士たちに「安らぎ」を与えていたそうだ。彼は、その女性達が「自分たちの意思に反して」その仕事をしていたことも認めている。 BBC: Japan WWII 'comfort women' were 'necessary' - Hashimoto これは致命的だ。今まで日政治家はさまざまな失言を繰り返して来たが、ここまで他国の人々の心を逆なでするものは始めてだ。女性はもちろん、軍人に対する大いなる侮辱だ。 日韓関係を悪化させるだけでなく、これ

    cubed-l
    cubed-l 2013/05/15
  • 政治家も国民も信用できないから憲法がある

    橋下さんが、憲法の96条改正について「政治家からの発議の敷居を下げるべき」「国民をもっと信頼すべき」と理論を展開しているが(参照)、そもそも憲法が他の法律の上位に位置づけられており簡単には変更できなくなっている根の理由をちゃんと考えてみれば、この理論は少しおかしい。私はこれまで橋下さんを支持して来たが、この件に関しては正直言ってがっかりだ。次の選挙では投票すべき別の政党を見つけなければならない。 憲法がこれほどまでに変更しにくくしてあるのは、人間はそもそも弱い生き物で、どうしても私利私欲に走ったり、目先の利益を優先して大きな問題を先送りしたり、マスコミの報道することを頭から信じてしまったり、調子の良いことを言う政治家に騙されてしまったり、その場の勢いに流されて思考停止をしてしまったりするからだ。つまり、政治家も国民も「信用」などできないのだ。 憲法を「アメリカから押し付けられた憲法」と呼

    cubed-l
    cubed-l 2013/05/07
    自国民を信じているから96条改正の必要がないんだよ。憲法に修正が必要なのであれば2/3の議員と国民の過半数の賛同くらい簡単に得られるでしょ
  • Life is beautiful: Windows95と地上の星

    Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。 Shell(デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス)の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。 David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。 「このままだと、95年中にリリースすることはできない」 深刻な問題である。既に当初の予定より1年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリ

  • エンジニアから見た原発

    典型的な「理科系少年」として育った私にとっては、原子力発電は宇宙旅行人工知能とならぶ「人類の英知を集めた科学技術の結晶」であり、あこがれでもあった。ブルーバックスの相対性理論に関するはすべて読んだし、アインシュタインの書いた e=mc2 という式は私にとってはまさに「人類の英知」を象徴するシンボルであった。高校時代の前半までは、自分は物理学者になると確信していたぐらいだ。ひょんなきっかけからコンピューターの世界に足を踏み入れ、ソフトウェア・エンジニアとしての道を歩むことになったが、科学技術全般に対する情熱は今でも持っている。 そんな私なので、今までは当然のように「原子力発電」の支持者であった。資源の乏しい日にとって「石油が不要で、二酸化炭素を放出しないクリーンな原子力発電」こそ日にふさわしい発電方法であると信じていたし、自動車・エレクトロニクスに続く輸出産業としての原子力に期待もし

  • これであなたも原子力安全・保安院

    放射線量や被曝量がドラゴンボールのスカウターの数値のように一桁づつ大きくなるにも関らず、「健康には影響がない」と言い続ける原子力安全・保安院。何度も聞いているうちに、あるパターンがあることに気がついた。「被曝量を記者会見で話す時にはこうやって説明する」という虎の巻のようなものがあるに違いない。そこで、その虎の巻を彼らの過去の発言からリバース・エンジニアリングしてみた。 1μSv (マイクロシーベルト) 胸部X線検診1回に受ける放射線量(50μSv)の50分の1。健康には全く影響がない。 10μSv(マイクロシーベルト) 胃のX線検診1回に受ける放射線量(600μSv)の60分の1。健康には全く影響がない。 100μSv(マイクロシーベルト) 胸部X線CTスキャン1回に受ける放射線量(6.7mSv)の約70分の1。健康には全く影響がない。 1mSv (ミリシーベルト) 放射線業務に従事する人

    cubed-l
    cubed-l 2011/04/01
  • O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」

    昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、来のMVC(そしてオブジェクト指向そのもの)のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている(ここが根的な問題) ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的(これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない) ↓ ・O/Rマッピ

  • Ruby on Railsの「えせMVC」の弊害

    先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避

  • Life is beautiful: プレゼン初心者が覚えておくべき3つのポイント

    プレゼンの初心者にありがちな失敗は、 ・自分の未熟なプレゼンのテクニックを気にしすぎてあがってしまう ・情報は多い方が良いと勘違いして、スライドをたくさんの文字で埋め尽くしてしまう ・その結果、観客に話しかけるのではなく、観客に背中を見せてスライドを読んでしまう ・結局何が言いたいのか全く伝わって来ない など。今日はそんな人に覚えてほしい三つのポイント。 1. 観客は「未熟なプレゼン」には寛大だが、「何を伝えたいのか分からないプレゼン」には厳しい 「自分はプレゼンが不得意」と思い込んでいる(もしくは悩んでいる)人はたくさんいると思うが、そんな人がまず覚えておくべきことは、観客が「未熟なプレゼン」にはけっこう寛大であること。小中学生ならいざしらず、社会に出てから「プレゼンターの未熟さ」笑う人はまずいないので、心配しなくても良い。逆に、観客が許してくれないのは「何を伝えたいのかが分からないプレ

    cubed-l
    cubed-l 2007/10/02
    2^9乗り遅れ記念。全くだ。書いてあることを読むだけなら個々人で読むほうが早い
  • ネットの時代には「知識量・記憶力」よりは「適応力・応用力」の方がずっと大切

    先日の「習作UI: 縁日の金魚を再現してみた」というエントリー。特に深い意味もなく作ったのだが、ソフトウェア・エンジニアを目指す学生さんのためにひとこと付け加えておきたいのは、この業界で気で成功しようと思ったら、この程度のプログラムは、シミュレーションの専門家でなくともサクッと作れるように自分を鍛えておかなければいけない、ということ。 この業界で働きはじめると、担当した仕事によって、データ解析・Java・3D・シミュレーションなどのある特定の分野のプログラミングの経験を積むことになる。そういった経験を通して特定の分野を深堀りしてエキスパートになるのはおおいに結構なのだが、往々にして落ち込んでしまうのが「ボクはJavaのエキスパートだからRubyではプログラムは書かない」、「シミュレーションのことならそれに詳しいエンジニアがいるんだからその人に頼んで」、「今からFlashを勉強している時間

    cubed-l
    cubed-l 2007/05/29
    「心にブックマーク」これを記憶とか知識と呼びます
  • いったい何年たったら、従軍慰安婦問題や南京大虐殺などの過去の亡霊から日本は開放されるのだろう。

    いったい何年たったら、従軍慰安婦問題や南京大虐殺などの過去の亡霊から日は開放されるのだろう。60年以上も前の政治家や軍人が犯した「あやまち」のために、あいかわらず日が他の国とまともに外交が出来ていないというのは、何ともふがいない。 それにしても、「慰安婦連行の強制性を裏付ける証拠がない」なんて発言を現役の首相としてすることに何のメリットがあると思っているのか、私にはまったく理解できない。こんな発言をすれば、この亡霊をさらに長生きさせるだけなことぐらい分かる頭脳は持っているはずだ。多少右よりの発想を持っているぐらいはかまわないと思っていたが、こうやってわざわざ日の国を外交の場で不利にするような発言をするとはちょっと…。これじゃあ、支持率が下がってもしかたがない。

    cubed-l
    cubed-l 2007/03/13
    コメント欄を見る限り当分開放されないんじゃないかな
  • なぜ日本企業による米国企業の買収がしばしば失敗に終わるのか

    で「会社は100%株主のもの」と言い切ってしまうと、「従業員はどうするんだ?」「社会的責任は?」という話になるが、それとこれとは話が別、というのが多くのアメリカ人の考え方である。「会社は100%株主のもの」と割り切った上で、それぞれが「自分の時間」と「会社の与えてくれるもの」を天秤にかけて、「今の会社に残るべきか、別の会社に移るべきか」を毎年とは言わずとも少なくとも2~3年に一回は真剣に考える、というのは彼らにとってごく当たり前のことである。優秀であればあるほどこの傾向が強い。 アメリカで会社を経営する時に一番難しいのは、そんな環境でどうやって優秀な人たちを会社に雇い、かつ、会社のために一生懸命働いてもらうか、である。給料をたくさん払って繋ぎ止めるというのももちろん一つの方法だが、よほど儲かっている会社でなければそんな方法では経営が成り立たないし、へたをすると仕事もしない単なる給料泥棒

  • 優秀な主婦はイベント・ドリブン(event-driven)方式でパンを焼く

    昨日のエントリーで、「人は一つの仕事を処理するときには、それを小さな仕事に分割して、順番に処理する」と書いたが、「パンを焼く」という仕事を例に取れば、こんな風になる。 1.イーストを30℃のお湯と一つまみの砂糖とまぜて15分間予備発酵させる 2.ボールに強力粉、予備発酵させたイースト、砂糖、塩を入れて良く混ぜる 3.こね板の上で生地をこねる 4.ボールにラップをして室温で1時間発酵させる(一次発酵) 5.適当な大きさに生地を分割し、丸めて形を作る 6.オーブンに入れ、30分発酵させる(二次発酵) 7.オーブンの温度を200度にして18分焼く これは、ソフトウェアで言えば「手続き型のプログラム」であり、人間が一連の作業を把握するのに最も適した記述の仕方である(その証拠に、実際のどのレシピブックを見ても、レシピは必ず「手続き型」で書かれている)。 興味深いのは、このレシピにおける、「15分予備

    cubed-l
    cubed-l 2007/01/19
  • Life is beautiful: 悪徳マルチ商法の被害者をインタビューしてみた

    先日、ひょんなことから悪徳マルチ商法の被害者(24才、男性、四大卒、現在ニート)をインタビューする機会があった。社会人になりたての若者を餌にする巧みにしくまれたワナ。表面上は合法的なマルチ商法を装っているが、その実質はねずみ講だ。この手の悪徳商法は決して今に始まったものではないが、これだけ教育が充実し、ネットに情報があふれる時代になったにも関わらず被害者が続出するのを放置しておくのは、このブログで常日頃から発言をしている身としては許せない。そこで、今日は、そんな被害者を一人でも少なくするための私なりの試み。 その青年と話して何よりも驚いたのが、彼自身が被害者だということにまったく気付いていないこと。現在ニート生活中の彼いわく、「自分が当にやりたいと思う仕事をするためには、生活の基盤が必要。その基盤作りのためにこのネットワークに参加した。もう少し傘下の会員を増やすことができれば、何もしな

    cubed-l
    cubed-l 2006/12/22
  • YouTubeを使ったテレビ番組の「一部引用」の合法性に関する意見募集

    CNetのブログに、「YouTubeを使ったテレビ番組の『引用』の合法性に関する一考察」というエントリーを書いたので、まずはそれを読んでいただきたい。ここ数週間ばかり、私なりに「なぜSequoiaのような一流どころのVCがYouTubeに資金を提供したのだろうか」、「一見お金を垂れ流しているようにしか見えないYouTubeの当の狙いはどこにあるのだろうか」と考えて来た結果、やっと少し「著作権法との関係の落としどころ」のようなものが見えて来たような気がするので、それを自分なりにまとめて書いてみたのだ。 結局のところ、「テレビ番組の一部を『個人的体験の共有』のためにアップロードすることぐらい許容範囲」と多くの人が思うようになるのか(もしくは、既になりつつあるのか)が鍵である。CNetのエントリーに書いたように、人々の常識や良識が変化した時には、法律の方を変更すべきだ、というのが私の考え方であ

  • デジタルデバイドとユーザーエクスペリエンス

    CNetのブログに「ユーザー・エクスペリエンスとパーベイシブ・アプリケーションの世界」というエントリーを書きつつ考えたことがあるので、今日はそれに関するエントリー。テーマはデジタルデバイドである。 デジタルデバイドとは、さまざまなデジタルデバイスやネットワークの恩恵を受けられる人と受けられない人の間に大きなギャップが生まれることを指す(参照)。ギャップが生まれる原因には、所得、地域、年齢、教育の違いなどさまざまなものがある。「所得・地域格差」に関しては、私のようなエンジニアに何が出来るわけでもないので口を挟むつもりはないが、「年齢・教育」に関しては言いたいことが山ほどある。 この手の議論の際に「デジタルデバイドを解消するために人々の情報リタラシーを高めよう」などという発言を聞くことがあるが、私はこの「○○リタラシー」という言葉が大嫌いだ。もともと「リタラシーがない」とは「文盲である」という

    cubed-l
    cubed-l 2006/04/05
    人間の方が適応力が高い以上、人間が合わせた方が早い。それに安住してはならないと言う真っ当な意見
  • 「Software is service」の心構え

    社員向けの英語ブログの3番目のエントリーは、「Software is service: Why is it so hard for software engineers to fully internalize it?」というタイトル。私の会社には、MicrosoftApple、PalmなどでOSとかIDEなどの開発経験のある優秀なエンジニアが集まっているのだが、伝統的なソフトウェア作りでの成功経験があるからこそなかなか理解してもらえないのが、「Software is Service」の心構えだ。今回のエントリーは、そんな彼らのためのメッセージ。 少し前までのソフトウェア作りのプロセスは、(1)マーケットやテクノロジーのことが分かっている賢い人たちを集め、(2)彼らに作るべきプロダクトをデザインさせ、(3)必要な人員を集めて作り込み、(4)ある程度できたところでベータ版としてリリースし、

  • 1