ワシントン大学で受講しているMBAもあと１ヶ月を残すところまで来たが、最後の期に受けている授業の一つが "International Finance" という外国為替に関する集中講座。今までいろいろと疑問に思ってきたことが一気に解消されたので大好きな授業の一つだ。 その授業の中で、金利の低い外貨で借金をして家を買った結果巨額の借金を抱えることになってしまった人たちがアイスランドにたくさんいる話だとか、リスクを十分に理解せずに為替リスクを１００％負って金利の高い外貨預金に走る日本の主婦たちなのど話が出たので、日本の事情に関して少し調べてみた。

９０年代にIBM、Microsoft、Apple各社が巨額の開発費を投じて作っていた「戦略的OS」がすべて失敗してしまったことを皆さんはご存知だろうか？ IBMが作っていたのはOS/2。元々はMicrosoftとの共同開発だったが、途中で仲違いをしてしまい、最後はIBMだけが細々とサポートしていたことすら覚えていない人が多いとは思うが、Windows95の成功であっというまに市場から消えてしまったのがOS/2。具体的な数値は公開されていないので分からないが、両社が数百人体制で数年間開発していたので、少なく見積もっても日本円で数百億円は投じられたことは間違いない。 Cairoの方は私自身が初期のころにいたこともあるし、最終的には「Chicago(Windows95のプロジェクト名) vs. Cairo」の戦いの最前線にいた私としては知りすぎている点も多いのだが、一つだけ確かなのは、プロジェク

こちら（北米）で仕事をする場合、一番の褒め言葉は「あいつはAccountableだ」という言葉。辞書には、Accountableには「責任のある」などの訳語が乗っているが、仕事の場面で使う場合は「安心して仕事をまかせておける」という意味。 プログラミングにしろ他の仕事にしろ、何をしていてもさまざまな「予想外の問題」が生じるもの。そういう問題への対処も含めた上で、「あの人に仕事をまかせておけば安心」と思ってもらうには、さまざまなところに予防線を張り、常に「地に足をつけた」状態で、着実に仕事を進めて行くことが何よりも大切。

今回Googleが発表したウェブ・ブラウザー、Google Chromeは、ひと言で言えば、「安定度・安全度を高めるために、それぞれのタブを別プロセスで走らせるタブ・ブラウザー」である。 ９５年にIE3.0を設計した時には、タブのコンセプトも存在せず、セキュリティの問題もそれほど強く意識していなかったので、ウィンドウごとに１スレッドを割り当てたマルチ・スレッドを選択した訳だが、ここまでウェブ・アプリケーションが重要になってくると、マルチ・プロセスに移行するのは当然。特定のページ上でのJavaScriptの挙動がおかしくなったからと言って、ブラウザーすべてが落ちてしまう今までの設計が異常。 一つのウィンドウ下で管理させるそれぞれのタブにプロセスを割り当てる、一般的に一つのウィンドウに一つのプロセスやスレッドを割り当てる通常のGUIアプリケーションとは異なるが、ユーザー・モデルとリソース管理は

とりあえず右クリックすれば操作するべきメニューが出てて来るというのは意外と便利なんだけどね。コンテキストメニューがよくできてるというのはWindowsの美点のひとつだと思う。【いまどきWindowsなんぞを使うメリットはなにか - 狐の王国より引用】 ここのところApple製品のことばかり褒めているが、上のエントリーを読んで思い出したのが、Windows95のユーザーインターフェイスを設計していたころの話。「マウスのボタンは一つ」に必要以上にこだわるアップルに対して、二つあるマウスのボタンを最大に生かしたユーザーインターフェイスの一環として徹底的にこだわって作ったのが、このコンテキストメニュー。 今やいろいろな理由でぐだぐだになってしまったが、当時は「シングルクリックは選択」「ダブルクリックはデフォールト動作の実行」「右クリックはコンテキストメニュー」という大原則をOSだけでなく、Offi

ちょっとしたチャートとかグラフを作る時にはやはりExcelが便利だが、作ったチャートをブログに貼付ける方法を知らない人が多いことを発見したので、私が採用している方法をここで披露。 1. Excelでチャートを作る 2. 作ったチャートを選択し、編集→コピー 3. Wordで新しい文書を作成 4. その文書に編集→ペースト 5. その文書に適当な名前（例えばdocument1）を付けてウェブページとして保存 こうすると、Excelで作ったチャートが、ブログに貼付けることができるPNGというファイル形式で新しいフォルダー内（上の例だとdocument1_files内）に作られるので、それをブログに貼付ける。 例えば、私のブログに訪れる人のOSを月ごとにグラフにしたのがこれ。 私が使っているのは、Microsoft Office 2008 for Macだが、他のバージョンのオフィスでも基本的に

大手電機メーカーのSEとして就職して一年。うちの職場は、なんというか、生ぬるい。 ... きっと自分の成長の為には職を変えたほうがいいんじゃないかと思う。でも、自分の向学心の強さにはっきりとした自信が持てない。 ... 24年間優等生をやってきて、さらに新卒という切符を使って手に入った貴重な（？）大企業への就職を、簡単に手放してしまっていいのだろうか。 ... 【新卒で入社して一年より引用】 なんだか昔の自分を見るようで心を動かされてしまったので一言。 私自身、「せっかく理系の大学院をそれなりの成績で出ることができたのに（そうでない人が簡単には入れない）大企業へ行かないのはもったいない」というさもしい気持ちがあったからこそ、ベンチャー企業には行かずにNTTの研究所に入ったのは事実。「新卒という切符を使って手に入った貴重な（？）大企業への就職を、簡単に手放してしまっていいのだろうか」という気

へんな会社を貫くために、普通の会社のやり方をよく理解しておくというのは必要なんじゃないか、とこれははてなに限らず思う次第。【Kousyoublog | はてな移転で中の人が言うべきことと言ってはいけないことより引用】 この手の発言こそが、まさに「出るクギを打とうとする」行動。近藤さんに関してはそんな心配をする必要は全くないが、他の若い人たちが「やっぱり『普通の会社のやり方』をちゃんと勉強しなきゃ」などと誤解してはいけないと思い一言。 上場している企業と違い、はてなのように、ごく少数の株主が所有している会社の場合、株主・取締役の了解さえ取れれば、大幅な経営方針の変更は自由にしてかまわない。それが非上場であることの大きな利点だ。 今回の場合、「米国からは一時撤退し、多少会社の規模が小さくなっても良いから、京都にもどって落ち着いた環境でもう一度もの作りに専念する会社としてやりなおす」という決定は

民主党は18歳未満の若年者が犯罪に巻き込まれるのを防ぐため、インターネット上の違法・有害サイトの削除をプロバイダーなどに義務付ける法案の国会提出に向け、党内調整を始めた。自殺勧誘や、児童買春の温床とされる出会い系や児童ポルノなどに簡単にアクセスできないようにする狙い。与党との共同提出も視野に入れており、今月召集の通常国会での成立を目指す。　検討中の法案では、サイト開設者やプロバイダーは違法情報を発見し次第、削除しなくてはならないと規定。違法かどうか明確でなくとも、有害な恐れがある場合は児童が閲覧できなくなるような措置を講じるよう義務付ける。罰則を設けることも視野に入れる。 【NIKKEI NET（日経ネット）：主要ニュース−各分野の重要ニュースを掲載より引用】 弾さんも指摘していたが、この民主党の発言は先進国の政党としては許しがたい発言。イギリスやアメリカなら法案どころか、それを臭わす発言

アップルがiPod+iTunes+iTunes Storeというハード・ソフト・サービスを巧みに組み合わせてネット時代にふさわしいコンシューマ・エレクトロニクス・ビジネスモデルを見せてくれたことに関しては、ここでもさんざん書いて来たが、反面教師として注目すべきなのは、ソニーになぜそれができなかったのか？ということ。 自分自身がメディア産業を持ち、ウォークマンというブランドを持ち、ネットビジネスに抜群のセンスを持つ出井氏を社長に据えたソニーはアップルよりははるかに良い立場にいたはずだが、なぜこんなことになってしまったのだろうか。 メディア産業を持つことが逆に足かせになった、ソフトウェア開発力の差、たまたまラッキーだっただけ、天才スティーブジョブズがいたから、イノベーションのジレンマ、などのそれぞれの側面から考察を加えることは可能だが、あの時代のソニーに特有の問題として特に注目すべきなのは、あ

一つ前のエントリーに対して、アップルの増井さんから「もうちょっとシンプルな『メタ言語』で良いんじゃないでしょうか。YAMLみたいなのとか。」という良いアイデアをいただいたので、早速実装。先のサンプルが、ページ内にこんな感じで直接記述できる。 ==iAnime.js: Benefits *Small footprint (<6KB compressed) *Lightweight (runs fine on iPhone) *Works well with jQuery.js and prototype.js *Free (MIT license) ==iAnime.js: Power *Easy to use (only three methods) *Powerful JSON-based animation language *Extensivle ("effects" and "pl

メインマシンをMacBookに変えてから、プレゼン資料を作るためにいちいちParallelsからPowerpointを立ち上げるという作業がうっとうしくなって来た今日この頃である。もちろん、Keynoteを使うという方法もあるがファイルの互換性の問題があるし、Google Docsでは見栄えが悪い。 「誰かがすでに作っているだろうな」と思いつつHTML+CSS+JavaScriptで作ってみたのがこれ（クリックすると次のスライドに進む）。 手持ちのバージョンのSafari、Opera、Firefox、IEでは動作確認済み。iPhoneでももちろんちゃんと動く。フォントの大きさはダイナミックに計算しているので、全画面でブラウズしてもそれなりに動く。 まだまだ機能的に不足している部分はたくさんあるが、こんな形で作っておけば、ブログでの公開も簡単だし、見た目はCSSしだいでなんとでもできる。ある

（このエントリーは「Javascriptクイズ：無名関数と実行効率の話」の続編。） 「？？？」と頭をかしげる太郎に、「じゃあ、これだったらどうかな？」と三郎はコードを書き始めます。 function code2name(code) { var mapping = { 'us': 'United States', 'ja': 'Japan', 'ko': 'Korea', 'ru': 'Russa', 'uk': 'United Kingdom', 'fr': 'France', 'cc': 'China', 'gw': 'Germany' }; return mapping[code] || '(unknown)'; } 「カントリーコードを国名に変換しているんですね。」と太郎。 「どこが問題だか分かる？」 「うーん、マッピングのためのオブジェクトを毎回作り直しているところかな。」 「そう

「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ

ちまたで問題になっているIPAフォーラム2007に参加した学生がエントリーを書いているのだが、それが半端じゃないぐらいのエンターテイメント。 ...IT産業というよりSIerの人気がないことについて語りたいだけなんじゃないかという顔ぶれだったし... ...はてなブックマークのコメントを見ている限りでは、パネリストの方々は相当現実の見えていない発言をしているようだ。... ...ITを専攻している学生達からは、「就職時にITスキルが問われないのだとしたら、大学でやっていることには何の意味があるのか」という質問が出ていたのだけど、明確な回答はなかったと思う。その人たちは、ちょっとショックを受けていたような気がする。... ...その流れで、「入社時にITのスキルを問わないというのは、Googleのような企業の方針とは反対であるが、それですばらしいサービスを作ることができるのか」という質問が出

ネゴシエーション（交渉）に関するテクニックにはさまざまなものがあるが、その多くが「いかに自分の欲する条件に近いものを勝ち取るか」をゴールとしたもの。それはそれで役に立つのかも知れないが、私としてはどちらかというと、今読んでいる「Getting to YES（日本語訳：ハーバード流交渉術）」という本に書いてあるアプローチの方がしっくりと来る。 この本の筆者（Roger FisherとWilliam Ury）は、一般に良く使われる「交渉は勝つか負けるか」「相手に手の内を見せない」「自分はできるだけ譲らずに相手に譲らせる」などのテクニックは交渉を長引かせるだけだし、その過程で相手との信頼関係を損ねかねないと警告する。 この本にはいくつかの有効な提言が含まれているので何回かに分けて紹介したいと思うが、まず最初に紹介したいのは、交渉の場にのぞむ前に自分がしておくべき心の準備の話。 多くの場合、人は交

@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ

University Washington で Executive MBA のコースを受けることにした理由の一つは、成功する企業とそうでない企業を分ける要因を私なりにちゃんと理解したかったからである。 Microsoft 時代に Bill Gates の下で働くことにより、業界の流れを読んだり、それに基づいた企業戦略を立てることに関しては、それほど不自由を感じなくなった。しかし、いざ自分で起業をしてみて強く感じたのは、企業戦略を立てることは「初めの一歩」でしかなく、その戦略に基づいてちゃんと利益を生み出す組織を作りあげる方がその何倍も何十倍も難しいということ。 色々と反省する点はあるのだが、あえて一番反省している部分を上げるのであれば、会社のカルチャー作りに十分な注意を払って来なかったこと。戦略に関わる mission statement や vision に関しては常にはっきりと語り続け

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

404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で