Life is beautiful: 自分で考える前にググっていませんか？
つい先日、興味深い話を聞いた。ある大学の授業で「デジタル・コンテンツ・ビジネス」というテーマで小論文を宿題として書かせたところ、同じような内容の小論文ばかりが集まったという。その原因を調べたところ、「デジタル コンテンツ ビジネス」のキーワードでググると上位に来る私の過去のエントリーの内容がほぼ丸写しにされていたという。 日本の学生の勉強に対する態度なんてそんなものなのかも知れないが（それはそれで憂うべき話だがその話は別の機会に）、少し心配になるのがどんな気持ちでその手の「コピペ」をしているのか、という点である。確信犯的に「徹底的に手を抜きたいからコピペしているだけ」ならまだ許せる。私が問題視するのは「自分で考える前にまずググる」習慣であり、「ググれば答えが見つかるにちがいない」という錯覚である。 暗黒時代とも呼ばれる中世ヨーロッパで科学の進歩があんなにも長い間低迷した原因の一つは、あの時
Life is beautiful: 「へんな会社」と「出るクギを打つ」社会の話
へんな会社を貫くために、普通の会社のやり方をよく理解しておくというのは必要なんじゃないか、とこれははてなに限らず思う次第。【Kousyoublog | はてな移転で中の人が言うべきことと言ってはいけないことより引用】 この手の発言こそが、まさに「出るクギを打とうとする」行動。近藤さんに関してはそんな心配をする必要は全くないが、他の若い人たちが「やっぱり『普通の会社のやり方』をちゃんと勉強しなきゃ」などと誤解してはいけないと思い一言。 上場している企業と違い、はてなのように、ごく少数の株主が所有している会社の場合、株主・取締役の了解さえ取れれば、大幅な経営方針の変更は自由にしてかまわない。それが非上場であることの大きな利点だ。 今回の場合、「米国からは一時撤退し、多少会社の規模が小さくなっても良いから、京都にもどって落ち着いた環境でもう一度もの作りに専念する会社としてやりなおす」という決定は
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
「渡された仕様書を実装するサラリーマンプログラマ」の悲哀
@ITの「業務用途でRubyを使う上での課題 」を読んでなんだか悲しくなった。 チーム開発でRubyを使ったときに今後起こりえる問題として、サン・マイクロシステムズ システム技術統括本部 チーフテクノロジストの下道高志氏は、こう指摘する。「他人の書いたPHPコードのメンテナンスはできない。Rubyはどうかといえば、現状はいい。しかし今後“職業プログラマ”ではなく、渡された仕様書を実装する“サラリーマンプログラマ”が増えてくると、コードのスパゲッティ化は避けられないだろう」。 【業務用途でRubyを使う上での課題 − ＠ITより引用】 これは言語の問題ではなく、日本のソフトウェア産業全体が抱える問題。以前にも「ソフトウェアの仕様書は料理のレシピに似ている」というエントリーで書いたが、本来のソフトウェア作りとは、絵を描いたり、音楽を作ったり、建物をデザインするのと同じ「創作活動」である。ドラッ
Life is beautiful: ビルゲイツの面接試験―ジャンケン編 解説
たくさんの方たちからさまざまな回答をいただいた「ビルゲイツの面接試験－ジャンケン編」。気が付いた人も多いようだが、この問題の面白さは、単なる数学の問題ではない点にある。中途半端な「ゲーム理論」の知識が逆にじゃまになったり、「数式を使って解けるはず」だとか「正解は一つだけあるにちがいない」などといった思い込みが答えの幅を狭くする。 「ゲーム理論」に基づいて解いて「グーとパーを５０％ずつの割合でランダムに出すのが良い」という答えにたどり付いた人が何人かいたが、この方法は最適解とは言いがたい。その戦略で得られる期待値、１２５０００円よりも多くの賞金が期待できる戦略が他にもあるし（後述）、相手がこちらがその手法を取っていることに気が付いて全部パーを出して来たときにどうしようもなくなる。 注目すべきなのは、これがゼロサムゲームではなく、二人で結託してパーとグーを交互に出し合って２５００００円ずつを得
「Why?」と言えない日本
先日、たまたまティーンエージャー（13～19才）の子供を持つ親のための講習会に出る機会があったのだが、そこで『二つのWhy』という話を聞いた。日本語にも若干通じる部分があるので、今日はそれに関する英語うんちく。 その講師は、親はティーンエージャーの「Why」には二種類あるので注意すべき、と主張する。一つは単なる質問の「Why」で、この場合は普通に答えて良い。もう一つが、こどもが自分が何かを拒否したい気持ちを伝えたくて「Why」と言っている場合。この場合に、その気持ちを理解しておきながら、理屈だけで納得させようとすると泥沼にはまってしまう、と指摘するのだ。 良い例が登校拒否のこども。親が「学校に行きなさい」というと「なぜ学校にいかなければいけないの？」と言い返してくる。そこで親としてはつい「ちゃんと学校を卒業しなければ、ちゃんとした会社に就職できないんだよ」などと答えて説得を試みたくなるのだ
Google Map API で早速遊んでみた
つい昨日、『私自身、もしLonghornのベータ版で遊ぶか、Googleの新しいウェブ・サービスのベータ版で遊ぶかの選択肢を迫られたら、迷うことなく後者を選ぶ』と書いたばかりだが、偶然とは恐ろしいもので、ちょうど Google が Map API のベータ版をリリースしたことを発見した。そこで早速、遊んでみた。 会社の近所の地図を表示し、そのまわりの幾つかの場所にマーカーを付け、クリックすると説明が出るようにしたのだ。もちろん、マウスで地図をドラッグしてスクロールさせることも出来るし、Satelite ボタンを押して写真に切り替えることもできる。こんなウェブ・アプリケーションが３０分ぐらい遊んだだけで出来てしまうのだから、すばらしい時代が来たものだ。 ［追記］ 参考までにソースコードを添付。ただし、ソースコード中の "key=..." は、このブログのURL用に取得した専用の Maps A
Life is beautiful: あえて断定せずに説得力を増すテクニック
少し前のエントリーで紹介した、「The ten faces of innovation」。内容とは直接関係がないが、興味深い文章術が使われていたので、今日はそれに関するエントリー。 まずは、下の文章を読んでいただきたい。 一昔前まで、Cleaveland Indiansは「弱小球団」の代名詞であった。地区優勝をしたことが無いばかりか、勝率が５割を上回ることすらめったになかった。しかし、１９９４年にIndiansは大きく変わったのである。１９９４年はリーグで一番の勝率をかせぎ（ただしストライキのためにシーズンは途中で終了）、１９９５年には念願のリーグ優勝を果たした。 何が変わったのだろう。監督も同じ、選手もほぼ同じメンバーである。一つだけ変わったものは球場である。都心から離れた所にある収容人数８万人の巨大で古びた球場から、都心にある収容人数４万人の新しい球場に移ったのである。 つまり、Ind
言葉遊び： 「ゴーグル」と１０回言ってもらってから質問してみよう
一昔前に、「『ミリン』って１０回言って」とか「『ピザ』って１０回言って」から始める言葉遊びが流行ったが、それを今風にアレンジしたものを思いついた。 A 「『ゴーグル』って１０回言って」 B 「ゴーグル、ゴーグル、ゴーグル、ゴーグル、…」 A 「日本で一番使われている検索サービスは？」 B 「グ、グーグル」 A 「ひっかかったね。Yahoo!だよ」 ぜひともまわりの人たちに試していただきたい（参照：Yahoo!がGoogleより人気の日本、なぜと頭をひねる）。 ちなみに、なんでこんなことを思いついたかというと、昨日競泳用のゴーグルをスポーツクラブに置いてきてしまったからだ。今朝になってLost&Foundコーナー（＝忘れ物コーナー）に行って、忘れ物担当の人にそのことを尋ねたのだが、つい「グーグル」と言ってしまったのだ。するとその人（中国系の老人、英語はかなりあやしい）が、ツッコミもせずに、「
Life is beautiful: 図解、イノベーションのジレンマ
私がマイクロソフトをやめるキッカケを作ったのが、「イノベーションのジレンマ」という本だということは、以前にも書いた。IT業界でビジネスをしている限り、大きな会社にいようと、小さなベンチャー企業にいようと、この本に書いてあることを日々意識しながら仕事をするかどうかは大きな違いを生むはずだ。 このブログでも何度も引用しながら、一度もちゃんと解説を書いたことがなかったことに気が付いたので、今日のエントリーは、この本に書かれているコンセプトの解説。 そう思っていつもの様に書き始めたのだが、文字だけではとても伝えにくいコンセプトだ。しかし、図解と言えばパワポ、というのもありきたりすぎるので、会社の廊下にあるホワイトボードに手書きで描いた図を、携帯電話で撮影したものを使うことにした。通りがかった社員にも見てもらえるので、一石二鳥である。 上の図は、この本に書かれたコンセプトを一般化したもの。ブルーのラ
Life is beautiful: Amazon AffiliateがGoogle AdSenseに勝てる理由
今まで、このブログでも何回もGoogleとMicrosoftを比較して、Googleにばかり軍配を上げてきた私だが、Googleに弱点が全く無いと思っているかというと決してそんなことはない。そこで、今日はこのブログでも採用しているAmazon AffiliateとGoogle AdSenseとを比較した場合、どうして私が「長い目で見たらAmazon Affiliateの方が強いかも知れない」と思っているかを述べてみたい。 まずは、このブログでの過去数ヶ月の実データを元に、Amazon Affiliateの結果をまとめると以下のようになる。 ・測定単位： 10万ページビュー ・クリック数： 約2500クリック ・注文数： 約150点 ・アマゾンの売り上げ： 約25万円 ・紹介料： 約1万５千円 まあ妥当な数値である。クリック率は約2.5%。クリックから実際の注文へのコンバージョン率は約6%で
色や大きさを後から変更できる AQUA風ボタンの作り方
二日ほど前のブックマークの人気エントリーに入っていた、「AQUA風ボタンの作り方リンク集」を見てつくづく思ったのだが、Photoshopは奥が深く、同じような効果を作り出すのに何通りも方法があるのが興味深い。そこで、今日は、Photoshopにも関わらずあえて全てをベクターデータで書くという特殊な技法（知り合いのデザイナーから教わった技法）でAQUA風ボタンを描いてみた。 まず最初に、"Rounded Rectangle Tool"で適当な大きさの角の丸い四角を書く。角の丸みは、Radiusの値で変更できるが、この場合は16pxとした。 この時自動的に作られたレイヤーをダブルクリックして、レイヤースタイルのInner Glow属性をオンにする。Blend ModeはMultiplyで、Opacityは４０％程度が適切、色は黒にする（黒にしておくと、後でメインの色を変更したときにここを変更し
ユーザー参加型サービスの力
ブログのエントリーというものは、その性質上、どうしても古くなったものは読まれなくなってしまう。当然、コメントやトラックバックが付くのもエントリーを書いてから高々一週間ぐらいのものである。しかし、５ヶ月前に書いたにも関わらず、未だにコメントやトラックバックが付く、驚異的にロングランなエントリーがこのブログに一つだけある。 「コミュニティ型『今日のひとこと』」というエントリーである。 今年の１月に書いたエントリーにもかかわらず、先週だけでも、３つのコメントが寄せられた。どれも、「こちらのブログパーツをブログに貼らせていただきました」という内容である。つまり、今だにこのブログパーツはブログからブログへと増殖中なのである。コメントとトラックバックの数から判断するに、すでに１００近くのブログでこのブログパーツは採用されている計算になる（ことわざの数も既に３０００を越している）。 このブログパーツがど
ユーザー参加型コンテンツビジネスのまとめ
最近CGM（Consumer Generated Media）関連の質問をされることが多いので、一度頭の中にあるものを整理する意味でも、箇条書きにしておく。 従来のWeb1.0的なコンテンツビジネスと比べた時の利点 ・常に新鮮なコンテンツをコストをかけずに提供できる点 ・バイラルマーケティング効果（コンテンツを作ったユーザーが他の人に宣伝してくれる） ・根本的にコミュニケーションツールであること（人がオンラインになるのは、他の人と繋がるため） ・ユーザーの数が増えれば増えるほどサービスの価値が上がる点 ・長く使えば使うほど、そのユーザー自身の財産が形成され、サービスから離れにくくなる点 意識しておくべき点 ・自社コンテンツを持っていない企業が新規参入できる点 ・ユーザーは予想もしない使い方をすることがあること ・コミュニティの作られ方しだいでサービスの質が大きく左右されること ・積極的に参
「登録ユーザー数１００万人突破！」などという数字が素直に受け取れない私
先月日本に戻った時に小田急線内で見かけた自社広告。一見数字とグラフで説得力があるように書かれているのだが、この文章で使われている「混雑率」の定義： ※全体（８両編成）の混雑を１００％とした場合 の「混雑」の定義があいまいなのがものすごく気になる。 ８号車が２６％、１号車が６％となっている所を見ると、実際に乗っている人の数ではなさそうだ。立っている人の数にしてもおかしい。 たぶん、小田急線なりの「一両あたりの定員」が定義されており、それを超した人数を各車両で数えて、それを「混雑」と呼んでいるのだろうとは予想できるが、それならちゃんとそう書いて欲しい。 子供のころはこの手のものを見ると「きっと大人はみんな『混雑率』の定義を知っているんだろうな」など謙虚に世の中を見ていた私だが、大人になってまわりを見ると、結構世の中には定義があやふやなものがあふれているの。定義があいまいでも全然気にしないで使っ
Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている
先日、経済産業省向けの仕事をしている知り合いと食事をしたのだが、彼によると経済産業省の今の悩みは、「IT産業の階層化の弊害によっておこる下流のプログラマーの収入の低下」だそうである。「プライムベンダー」と呼ばれる「上流コンサルタント」たちがインドや中国にも仕事を発注できることを理由に、激しく値切り始めたために、今やわずか一人月３０万円というケースもあるという。 こんな話を聞くと本当に悲しくなる。まず第一に「プログラムを書く」という仕事は簡単な仕事ではない。数学的な頭を持っていないとかなり辛いし、基礎がしっかりと出来ていないとろくなソフトウェアは作れない。物価の安いインドや中国なら許せるが、米国よりも生活費の高い日本で一人月３０万円とはあまりにも低すぎる。 「彼らは下流のエンジニアで、詳細仕様書に従った通りのプログラムを書くだけの簡単な仕事をしているから給料が安い」という説明を聞いたことがあ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
