Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
NTTの株価総額が世界一だった時に、Microsoftに転職した理由
「6年勤めたNTTを退職しました」という記事が、注目を浴びているようですが、この筆者が NTT を辞めた理由が、私が３２年前（１９８６年）に NTT を辞めた理由とあまり変わらないのに、少々驚きました。 私が NTT を辞めた件に関しては、これまで色々なところで話しては来たのですが、まとまって文章にしたことがなかったので、これを機会に書くことにしました。普段ならメルマガ（週刊 Life is beautiful）の読者限定で書くところですが、今回だけは、出来るだけ多くの人に読んで欲しいので、ブログ記事として公開します。 当時、NTTは電電公社から民営化したばかりで、１９８５年に入社した私は、NTTとしては第１期生でした。大学は、早稲田の理工学部電子通信学科で、修士課程まで行きました（当時は、情報学科はまだ独立しておらず、電子通信学科がソフトウェアとハードウェアの両方をカバーしていました）。
まず70点でも80点の出来でいいから全体を仕上げてみることの重要性
６月１日発売の拙著『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』からの引用です。 ◇ ◇ ◇ スマホアプリが アップデートを繰り返す理由 「仕事のスピードを追求したら質が落ちてしまう。それじゃダメだ」 そう思われている方もいると思います。たしかに速さを求めると質は落ちます。大抵の仕事がそうであるように、スピードと質はトレードオフ（片方を取るともう一方は取れない）です。質の悪いものを出さないようにじっくり時間をかけて、ときには徹夜で頑張る人もいるでしょう。 けれども質を追求した結果、締め切りに間に合わないような仕事の仕方をしていては本末転倒です。締め切りに間に合うことが明らかな状況であれば、質を高めるために時間を使うのは間違っていません。問題なのは、まだ仕事が終わる見通しが立ってもいないのに、質を高めるためにあれこれ工夫を凝らそうとすることです。 みなさんが普段使っている
「いつまでも成績が上がらない人」に共通する残念なノートのとりかた
６月１日発売の拙著『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』からの引用です。 ◇ ◇ ◇ あなたの授業での仕事はノートを取ることではない 中学になって初めての定期試験で、私は試験の前日に慌てて勉強してしまいました。とはいえ、試験のために勉強するという行為自体が初めてだったので、たいした勉強はできなかったのですが。 結果は、あまりよくありませんでした。そんなにダメというわけではなかったのですが、小学校の時のように、すらすら解けなかった。これは1週間前からコツコツと勉強をしないと次からは失敗するぞ、と悟りました。 当時、クラスメイトのＦ君が「徹夜で勉強をしてきた」と、試験日に言っていました。彼は試験はまったくできず（ひょっとしたら私よりも点数が悪かったかもしれません）、私は詰込みの勉強法では試験に太刀打ちできない、ということを彼に学びました。 寝ないと頭が働かない。そう
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
テクノロジー・ベンチャーにはなぜソフトウェア・エンジニアが不可欠なのか？
WEB-DB PRESSに連載中のコラム、「第10回 アイデアを目に見える形にしてこそのエンジニア」が公開されたので、エンジニアの方たちにはぜひとも読んでいただきたい。 この文章で、私が一番強く訴えたかったメッセージは下の一節。 注目すべき点は，この「プロトタイプという叩き台を作って企画を煮詰めていく」というアプローチは，エンジニアにしかできないということだ。ソフトウェアのことがまったくわからない人から企画を丸投げされて閉口した経験は多くの人が持っていると思うが，そんな無駄なことを避けるためにも，企画の段階からリーダーシップを発揮するためにも，エンジニアはプロトタイプを作るべきだと私は考えている。 シリコンバレーでベンチャー投資家をしている Guy Kawasaki が、「私がアーリー・ステージのテクノロジー・ベンチャーに投資をする時は、ざっと見積もって、優秀なエンジニア一人あたり５０万ド
Life is beautiful: Windows95と地上の星
Windows95の開発の総責任者であるDavid Coleから開発の主要メンバーに緊急召集がかけられたのは、Windows95の開発も大詰めを迎えた1994年末のことである。 Shell（デスクトップ、エクスプローラ、スタートメニューなどのユーザーインターフェイス）の開発を担当していたSatoshiは、いままでの経験からこの手の緊急招集が良い知らせでないことはないことは知っていた。 David Coleが深刻な顔をして緊急招集の理由を説明し始める。Windows95そのものの開発は順調に進んでいるが、Windows3.1との互換性の維持が思うように進んでいないのである。 「このままだと、９５年中にリリースすることはできない」 深刻な問題である。既に当初の予定より１年以上遅れているWindows95のリリースをさらに遅らせて95年のクリスマスシーズンを逃すことはOffice95を同時にリリ
転職におけるプッシュとプルと
大手電機メーカーのSEとして就職して一年。うちの職場は、なんというか、生ぬるい。 ... きっと自分の成長の為には職を変えたほうがいいんじゃないかと思う。でも、自分の向学心の強さにはっきりとした自信が持てない。 ... 24年間優等生をやってきて、さらに新卒という切符を使って手に入った貴重な（？）大企業への就職を、簡単に手放してしまっていいのだろうか。 ... 【新卒で入社して一年より引用】 なんだか昔の自分を見るようで心を動かされてしまったので一言。 私自身、「せっかく理系の大学院をそれなりの成績で出ることができたのに（そうでない人が簡単には入れない）大企業へ行かないのはもったいない」というさもしい気持ちがあったからこそ、ベンチャー企業には行かずにNTTの研究所に入ったのは事実。「新卒という切符を使って手に入った貴重な（？）大企業への就職を、簡単に手放してしまっていいのだろうか」という気
スタートダッシュ型仕事術：実践編
昨日書いた「『時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す』という働き方」というエントリー、Twitterやハテブでたくさんのフィードバックをいただいたが、その中で気になったものの一つが、「そうは言っても仕様がころころ変更になるからスタートダッシュで仕事をしていたら時間が無駄になる」というもの。 まず最初に言っておくと、「仕様がころころ変更になる」のはソフトウェアの宿命。どんなに頭の良い人が設計しても、「作ってみなければ分からない」「使ってみなければ分からない」ことはどうしてもあるので、「アーキテクチャの大幅な変更」「ユーザーインターフェイスの大幅な変更」があるのはあたりまえ。 ぜひとも認識して欲しいのは、「だからこそスタートダッシュで肝となる部分を一気に作って、早めに（仕様変更が必用かどうかの）見極めをする必用がある」という点。特に「作って見なければ分からない」部
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
「なぜAppleはiPadにFlashを載せるべきではない」のか
気がついた人も多いと思うが、iPadのアナウンスメントであっさりと無視されたのがAdobeのFlash。私は意図的（＝「Flashなんか重要じゃない」というメッセージ）と読んだが、皆さんはどうだろうか。 iPhoneがFlashをサポートしていないことに対するAdobeを含めたさまざまな方面からの批判を考えれば、「the best way to experience the web （最高のウェブ環境）」を売り文句のiPadが、これだけ広く使われているFlashをサポートしないというのはおかしな話だ。 不思議に思う人も多いかもしれないが、自分をAppleの経営陣の立場に置いて良く考えてみれば答えは明確になる。 Appleという会社は、昔からさまざまなクリエーターたち（アーティスト、ミュージシャン、ウェブ・デザイナー、etc.）を魅力的で便利なパソコンやツールで味方につけ、彼らの作品を消費者
Twitterを使ったブクマを格段に簡単にするTiny Quote
興味深い記事やブログエントリーをネットに見つけた時に、それにひと言コメントを付けて投稿、というのはTwitterで良く見かける行動パターンの一つ。それも他の誰かのためにというよりは自分自身への備忘録という意図の場合もしばしばあるので、ある意味で「ソシアル・ブックマーク」的な使いかたに近づいてきているとも言える。 ただ、そんな時に１４０文字の中に記事中で気になった文章を引用しつつ自分の意見を述べてかつURLを詰め込む、というのはなかなか難しい。 そこで、先日の Tiny Message のバックエンドをこの問題の解決に使えないかと作ったのが、Tiny Quoteというブックマークレット。それなりに動き始めたのでここで公開する。 TinyQuote （←このリンクはクリックせずにブックマークバーにDrag&DropもしくはCopy&Pasteして登録してください） このブックマークレットをブラ
Twitterに140文字以上つぶやきたい時のためのサービス、Tiny Message
Google App Engineでプログラムを書き始めて１週間ほど経つが、ようやくDatastoreの基本が分かってきたので、サービス運営の経験値を積むためにもアプリを一つリリースしてみることにした。 サービス名は、Tiny Message。Tiny URLはTwitterに書くURLを短くしてくれるサービスだが、こちらはTwitterに書くメッセージそのものを短くするサービス。 使い方はいたって簡単。Tiny Messageのホームページ（http://tinymsg.appspot.com/）でメッセージを書き、"make my tweet"というボタンを押すとTwitter投稿用の要約（最初の１００文字）＋URLが表示されるので、それをコピペしてTwitterでつぶやけば良いという仕組みである（メッセージの全文を読みたい人にはURLをクリックしてもらう）。 こんなサービスがチャチャ
Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
O/Rマッピング技術の進化が皮肉にも助長している「えせMVC症候群」
昨日の「Ruby on Railsの『えせMVC』の弊害」というエントリー。若干「釣り」の要素が含まれたタイトルが功を奏したのか、たくさんのフィードバックがいただけた。そんな中で見えて来たのは、この問題はRailsに限った話ではなく、業務用アプリケーションで使われているJavaや.Netの世界でもよく見られる問題だということ。 その「問題」とは、ActiveRecordに代表されるO/Rマッピングの技術の進化が、本来のMVC（そしてオブジェクト指向そのもの）のメリットを無視した「えせMVC」な設計を助長している、という問題である。 ・MVCやオブジェクト指向を表面的にしか理解していないエンジニアが増えている（ここが根本的な問題） ↓ ・SQLを自分で記述しなくて良いO/Rマッピングはとても魅力的（これはこれで別の問題を含んでいるが、このエントリーではあえて突っ込まない） ↓ ・O/Rマッピ
DellのAndroidケータイが意味するもの
CNet/WSJにも書かれていたが（参照）、DellがAndroidを使ったスマートフォンのリリースに向けて着々と準備を進めているらしい。 Microsoft/Intel連合がOSとチップセットという組み合わせでパソコンビジネス（ハード）への参入障壁を極端に低くし、大量の新規参入組と自然淘汰により一気にパソコンの低価格化・コモディテぃ化が進んだことは記憶に新しいと思うが、それと同じような波がようやく携帯電話の世界に押し寄せて来ている。 ここに来てはっきりと見えて来たことがいくつかある。 Androidにより参入障壁が大幅にさがり、中国・台湾・韓国などからメーカーが大量に参入してくる そういったメーカーに製造をまかせ、自分はデザインとブランドだけで勝負する企業も参戦する（Dellはだぶんここに位置することになる） スマートフォンとそれ以外の境があいまいになり、フルブラウザーを搭載するのがあた
Twitterの有効な使い方、その１
ブログに関しては、Early Adaptorとして早くから有効に使わせていただいている私だが（このブログを始めたのは２００４年、その前にも一つ別のところにブログを書いていた）、Twitterに関しては「どうもいまいちピンと来ない」というのが正直な感想。 今年に入ってからメディアに異常なほどにもてはやされていたTwitterも、「Twitter is a Fad - Business Week」、「セカンドライフとTwitter」など、「Twitterは一時的な熱狂にすぎない。セカンドライフと同じ道をたどるんじゃないか」という冷めた意見も多く見られるようになった。 私自身もPhotoShareからの連携で写真へのリンクを自動投稿する以外はほとんどアクセスしなくなってしまっていたのだが、今回、開発者向けのあるウェブサービスをリリースすることになり、Twitterが有効に使えるケースがあることに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Windows Mobileに「全力投球」を決めたMicrosoftの厳しい戦い