先日予告したSNBinderのオープンソース化、GitHubに簡単なREADME付きでアップロードしたのでご覧いただきたい。 https://github.com/snakajima/SNBinder SNBinderは、ひと言で言えば「ブラウザー上でView(テンプレート)とData（JSON）を結合して HTML を生成するテンプレートエンジン」である。 ９０年の半ばから急速に広まったインターネット。サーバー側でダイナミックに生成したHTMLページをブラウザーで閲覧するだけ、というシンプルでエレガントなアーキテクチャゆえの成功だ。しかし、ブラウザーの高機能化に伴い、JavaScriptを駆使して使いやすさを向上しようという試みが色々なウェブサイトで行われている。GMail、Google Docs、Facebookなどは良い例だ。 その方向性を究極にまで突き詰めると、サーバー側は（MVC

今回の訪日中に、ソニーの（音楽・ゲームなどの）エンターテイメント・ビジネスの生みの親でもある丸山茂雄氏とお会いする機会があった。私もつい最近まで知らなかったのだが、丸山氏の父親は「丸山ワクチン」の生みの親である故丸山千里博士。「私自身も丸山ワクチンで癌と戦っている」という丸山氏の言葉に刺激され、丸山ワクチンに関して調査してみたのでここにまとめてみる。 「丸山ワクチンの効果」に関しては、専門家の意見でも意見が分かれている、というのが現状である。そのため、事実と意見が混在した形でネット上に存在しており、単にググっただけでは玉石混淆の情報に悩まされるだけ。そこで、一歩踏み込んで、新聞・専門書・学術ペーパーなどを読んで事実確認をしながら、まずは確実に事実と言える部分を洗い出してみた。 事実１：丸山ワクチンは、丸山千里博士がもともとは皮膚結核の治療薬として開発したもの（１９４４年誕生） 事実２：丸山

つい先日、興味深い話を聞いた。ある大学の授業で「デジタル・コンテンツ・ビジネス」というテーマで小論文を宿題として書かせたところ、同じような内容の小論文ばかりが集まったという。その原因を調べたところ、「デジタル コンテンツ ビジネス」のキーワードでググると上位に来る私の過去のエントリーの内容がほぼ丸写しにされていたという。 日本の学生の勉強に対する態度なんてそんなものなのかも知れないが（それはそれで憂うべき話だがその話は別の機会に）、少し心配になるのがどんな気持ちでその手の「コピペ」をしているのか、という点である。確信犯的に「徹底的に手を抜きたいからコピペしているだけ」ならまだ許せる。私が問題視するのは「自分で考える前にまずググる」習慣であり、「ググれば答えが見つかるにちがいない」という錯覚である。 暗黒時代とも呼ばれる中世ヨーロッパで科学の進歩があんなにも長い間低迷した原因の一つは、あの時

この業界で仕事をしていると、しばしば迫られるのが「どのプラットフォームに向けて商品開発をして行くのか」という決断。会社としての経営判断の場合もあれば、個人のスキルアップやキャリアパスのための判断の場合もあるが、いずれにしろ限られたリソース・時間をいかに有効に使うか、という点ではとても大切。 パソコン用のソフトウェアであれば、「Windows向けに作るのかMac向けに作るのか」というOSレベルでの選択肢もあるし、「Windows Vista独自の機能を使って差別化を図るのか、それともWindows XPでもちゃんと動くように作ってまずは大きな市場をとりに行くのか」というOSのバージョンレベルでの選択肢もある。もちろん「そもそも特定のOS向けのアプリを作るべきか、それとも、すべてウェブ・アプリケーションとして作るか」というアーキテクチャ・レベルでの選択肢もある。 「少なくともここ数ヶ月はiPh

昨日のエントリーに引き続き、今日もブログのページビューの統計解析。今日は、一週間あたりのブックマーク数とページビューの相関関係をプロットしてみた。 これもしっかりと相関関係が出ている（一つだけ例外的に４８０近くもブックマークを集めたにも関わらずページビューが極端に低い週があるが、これは年末で例外的にトラフィックが低かった週のデータ）。 最小二乗法で求めた直線の方程式は、Y＝53595+45X（Y:ページビュー、X:ブックマーク数）。Coefficient Determination（R^2）は３７％。相関関係はエントリー数よりも強い。"45X"の項目は、ブックマークが一つ増えるとページビューが４５増えることを示しており、ページビューを稼ぐためにはブックマーカーに受ける記事を書くことが一番の近道だ、ということを表す。 ◇　◇　◇ さて、ここまで読んでいただいて、あなたはどう感じただろうか？「

私の書物「おもてなしの経営学」についてのさまざまなフィードバックはポジティブなものもネガティブなものもとても良い勉強になるので全部読ませていただいているつもりだが、以下の二つに関しては、少し誤解があるようなので一言書いておこうと思う。 何故SONYの経営はiPodを創れなかったか - 雑種路線でいこう 「おもてなしの経営学」：ソニーのエンジニアの名誉のために一言 ([の] のまのしわざ) 私の本のごく一部、それも梅田氏とのの対談における「ギークとスーツ」の話題の前フリとして「ギークとスーツのすれちがい」「技術と経営の両方が分かる人が少ない」ことの例として語った言葉だけを取り上げて、あたかも私が「ソニーにiPod+iTunes+iTunes storeが作れなかったのはエンジニアが悪い」と決めつけているかのように誤解をされてしまっているのが私としてはとても残念。 せっかく私の本を読んでいただ

一年ほど前に、「女の子が『お父さん臭い』と思うのは、自分と遺伝子の形が似ている異性のにおいを不快に感じるという近親相姦を避けるために自然が生み出した仕組みの結果」ということが実験で証明された、というニュースを読んだのを覚えているが（参照）、今回CBSの朝のニュースで報道されたのは、それをビジネスのネタにした、「サイエンティフィック・マッチ」というベンチャー企業の話。ひとことで言えば「科学的相性占いビジネス」。 表面上は「還元水」と同じく「エセ科学」っぽいところもあるが、この相性占いの元になっている「においで本能的に近親相姦を避ける仕組み」にはそれなりの説得力があり、少なくとも「星占い」よりは信頼性が高く思える。 ちなみに、この会社によると、DNAが異なるカップルほど、 相手の自然な体臭が心地よく感じられる可能性が高い より満足度の高いセックスライフを持つことができる可能性が高い 女性がオル

Javascriptを使い始めたばかりの太郎君に、上司の花子さんから「スタイルシート用のスタイル名をDOMからアクセス可能なプロパティ名に変更するJavascriptのライブラリを作って欲しい」という課題が与えられました。何のことか分からずにポカンとしている太郎君に、花子さんは「"font-style" を"fontStyle"に変更する関数を作ればいいのよ」と言い残して立ち去ってしまいます。 O'ReillyのJavascript本としばらく格闘した太郎君は、やっとライブラリを完成させます。 function capitalize(str) { return str.charAt(1).toUpperCase(); } function style2prop(str) { return str.replace(/-[a-z]/g, capitalize); } "font-style"が

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

今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち

CNetでも報道された通り、Sunが独自のスクリプト言語JavaFX Scriptを発表した。テクノロジーの優劣だけで決まるものではないので、この試みがうまく行くかどうかは何とも予測しがたいが、とりあえず言語仕様が公開されたので目を通してみた。 私なりに興味深いと思った点は以下の５つ（ただし、私なりの拡大解釈が多少入っている可能性もあるので要注意）。 １．宣言型のUIをサポートしていること 宣言型大好き人間の私としては、この方向性は大賛成（ちなみに、UJMLも宣言型のUI言語^^）。"押してね！"というラベルがついたボタンを表示するには、こう書けば良い。 Frame { content: Button { text: "押してね！" action: operation() { System.out.println("押してくれて、ありがとう"); } } visible: true } ２

最近の梅田さんのエントリーを読んでいて、何やら言いたくなったことがあるので、ここに書いておく。それは、 「自分がやりたいこと」と「会社にとって必要なこと」のベクトルを合わせることができた時に大きな力が出る という私自身の仕事に対するプリンシプル。 私自身のキャリアを振り返ってみると、会社と私のベクトルをシンクロさせることができたアスキー出版やマイクソロソフトでは、好き勝手なことをやっていて会社の成長に貢献することができたが、どうしてもシンクロさせることができなかったNTTの研究所は長続きしなかった。楽しければ徹夜も苦ではないが、楽しくなければ一日８時間会社にいることすら辛くなる。 別の言い方をすれば、「楽しんで、かつ、会社の業績に貢献する」ために自分が何をしなければならないかを常に意識していて働いた方が良いということ。今やっている仕事が会社にとって何の役に立つのかが理解できなかったり、やっ

たくさんの方たちからさまざまな回答をいただいた「ビルゲイツの面接試験－ジャンケン編」。気が付いた人も多いようだが、この問題の面白さは、単なる数学の問題ではない点にある。中途半端な「ゲーム理論」の知識が逆にじゃまになったり、「数式を使って解けるはず」だとか「正解は一つだけあるにちがいない」などといった思い込みが答えの幅を狭くする。 「ゲーム理論」に基づいて解いて「グーとパーを５０％ずつの割合でランダムに出すのが良い」という答えにたどり付いた人が何人かいたが、この方法は最適解とは言いがたい。その戦略で得られる期待値、１２５０００円よりも多くの賞金が期待できる戦略が他にもあるし（後述）、相手がこちらがその手法を取っていることに気が付いて全部パーを出して来たときにどうしようもなくなる。 注目すべきなのは、これがゼロサムゲームではなく、二人で結託してパーとグーを交互に出し合って２５００００円ずつを得

大槻ケンヂの「グミ・チョコ」を読んでいて思いついたのが、今日のクイズ。単なる数学の問題ではないので良く考えてみて欲しい。 あなた（＝Aさん）とBさんにジャンケンを連続で１０００回してもらいます。あなたもBさんも、パーで勝つたびに５００円、チョキで勝つたびに２００円の賞金を主催者からもらえます。グーで勝ったり、アイコになった場合には一円ももらえません。この条件で、あなたの賞金を最大化するために、どんな戦略を採りますか？ただし、Bさんと前もって相談することはできないし、試合中はしゃべったり身振りで合図を送ってはいけません。表情も見えないように、ミラーガラスのヘルメットを被ってもらいます。試合中に見えるのは相手が何を出したかだけです。 回答は、コメント・トラックバック・ブクマコメントなどで送っていただきたい。 ちなみに、この問題には面白いパラドックスが隠されている。普通に考えると、グーを出しても

ものごとをポジティブに考えるか、ネガティブに考えるかという議論をするときに、「半分だけ水が入ったコップをどう見るか」という話が良く引き合いに出される。それを「半分も水が入っている！ラッキー」と考えるか、「どうして半分しか水が入っていないんだろう？残りの半分は誰かが飲んでしまったのだろうか」と考えるか、で人生が大きく変わってくるという話である。 ポジティブに考えた方が人間幸せになれるし、そんな人の方が成功する可能性が実際に高くなる、という話は大昔から言われ続けてきたことだが、そうは分かっていても、「入ってない方の半分」が気になってしまうのが人間の弱さである。 これと関連する話で、先日読んだ心理学の本に、ちょっとした工夫で皆が得をした気分になる（つまりポジティブに考える）テクニックが書いてあったので、ここで紹介する。 VHSテープ全盛の時代の米国のレンタルビデオ店での話。「見終わったあとはテー

何かの「ユーザー・インターフェイス」を決める時に大切なことは、自分なりのはっきりとした「デザイン・ポリシー」を持って、誰が何と言おうと最後までそれをしっかりと押し通すこと。そういう「柱」をしっかりと持たないで作ったものは、往々にして「妥協の産物」になってしまう。 私が常に心がけていること（つまり、私のデザイン・ポリシー）は、「ユーザー・シナリオを８０：２０ルールで切り分け、常に８０の方（つまり多くの人が使うだろう機能）を最優先にした設計にし、２０の方（あった方が良いかもしれない機能、一部の人が必要とするかもしれない機能）は思い切って犠牲にする」こと。 典型的な良い例が、Youtubeを見るためのサービス、Rimo と oreseg。 機能的には、カテゴリー分けはしてくれているし、サムネールから自分で見たいものを選べるし、oresegの方が上である。しかし、「ただだらしなく面白そうなビデオを

息子の大学で授業参観をする機会があったので聴講したのが「Corporate Finance」の授業。わずか７０分の授業であったが、とても分かりやすかったので復習の意味も兼ねてここに解説してみる。 まず、会社として採用することを考慮している二つのプロジェクト、「S」と「L」があったとする。プロジェクト「S」は、一年目に５０万ドル、二年目に４０万ドル、三年目に３０万ドル、四年目に１０万ドルのキャッシュフロー（＝会社に入ってくるお金）を生み出すが、プロジェクト「L」は、一年目に１０万ドル、二年目に２０万ドル、三年目に３０万ドル、４年目に６０万ドルのキャッシュフローを生み出す。 それぞれのプロジェクトに１００万ドルの資金が必要で、調達した資金には１０％の利息がかかると仮定したとき、会社としてはどちらのプロジェクトを選ぶべきか、というのが今回の課題である。 「投資した資金を回収するのにどのくらいの期

子供のころは、分からない言葉があると素直に質問できるのだが、大人になるにつれて色々な言葉をテレビや新聞で毎日のように見ているうちに「漠然としたイメージ」が頭の中にできてしまうと、分かったような気になってそれで満足してしまうことがしばしばある。ある程度歳をとってくると、「いまさら、こんなこと恥ずかしくて質問できない」状態になってしまうから始末が悪い。 私自身が大人になって分かったことだが、えらそうにしている大人の知識とか常識なんてものは、以外にこの程度のものだったりするのだ。だから子供に「街宣車って何？あの人たち何やってるの？」などと突っ込んだ質問をされると困ってしまう。 私自身も、こと政治やイデオロギーに関しては、あいまいな知識の上に別のあいまいな知識を重ねて来た結果、さまざまな疑問を抱えたまま大人になってしまったタイプだ。 「右翼の街宣車っていったい何をやっているんだろう？」 「過激派っ

IT-Plusの『「在学歴」を学歴とする風土が生み出す必修科目逃れ』は、まさに私が前々から指摘したかった日本の教育システムの問題点を的確に表す良いコラム。しかし私は、この日本の「在学歴を学歴とする風土」の悪影響は、単なる必修科目逃れにとどまる話ではなく、日本の企業の国際競争力、しいては日本の国力そのものを奪うことになっている、と常々思っている。 この「大学受験」という一発勝負で、その人の一生が大きく左右されてしまうという状況が作り出しているのが、受験地獄とその後の人生の二極化。 小学生低学年のころから塾に通わされて、自分が本当に好きなこと得意なことは何なのかを発見できず、人生の楽しみ方とか自分なりの価値観とかを学ばずに大人になっていく子供たち。親の言うままに一生懸命勉強して、一流大学に入学し、それを「一流企業へのパスポート」として一番大切な時期に勉強もせずに遊びほうける大学生。自分のキャリ

今週号のFortuneの特集記事（原文へのリンク）は、"Chaos by Design"というGoogleのマネージメントスタイルに関する記事。GoogleのBusiness Operationの上級副社長は、Shona Brownという元マッキンゼーの女性。1998年にCompeting on the Edge: Strategy as Structured Chaosという本を書き、イノベーションを起こすには、会社を「カオス状態」と「きちんと構造化された状態」の間の "structured chaos"(構造化されたカオス)と呼ぶ状態に置くのが一番良いと説いたのだが、Googleが今ある状態はまさにそれ、というのがこの記事の論点だ。 今考えてみると、Microsoftも、９０年代の前半から中盤の、Windows95、IE3.0、IE4.0を出した時期は、まさに"Structured C