Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
私からの提案：おかえりなさいテレビ
若干誤解してしまった人も少しいたようだが、私が「もし日本のメーカーがiPhoneを発売したら...」で指摘したかったのは、「広告一つでこんなにインパクトが違うのか」という単純な話ではなく、「どこに重きを置いてもの作りをするか」というもっともっと根本的な問題。 カタログスペック重視のもの作りは、確かに社内の稟議を通しやすいし、作る過程でも目標設定が簡単だ。量販店で横並びにされた時にも他社の製品に負けない。しかし、これがそろそろ通じなくなっていることは、日本のどのメーカーもひしひしと感じているはずだ。 確かに「ユーザー・エクスペリエンス（おもてなし）」とか「ライフスタイルへのインパクト」重視のもの作りは、定量化ができなし、大失敗の可能性もあるので、「出る杭は打たれる」型の日本の会社では難しいのかも知れないが、そろそろ意識を切り替えないと手遅れになる。「ユーザーにどんな体験をしてほしいか」をまず
もし日本のメーカーが iPhone を発売していたら..
iPhoneは会社から支給されて使っていますが、非常に使い勝手がいいです。 ただ、これでは、いまほど欲しくならないことはたしかですね。 他の機種と同じ土俵の上に上がってしまっているので、「なんかいろいろ機能がごてごて付いてる中の携帯の一つ」というところでしょう。 つまり、「売れるモノも売れなくなる」、「売り方次第」ということを今更ながら思い知らされました。
まず70点でも80点の出来でいいから全体を仕上げてみることの重要性
６月１日発売の拙著『なぜ、あなたの仕事は終わらないのか スピードは最強の武器である』からの引用です。 ◇ ◇ ◇ スマホアプリが アップデートを繰り返す理由 「仕事のスピードを追求したら質が落ちてしまう。それじゃダメだ」 そう思われている方もいると思います。たしかに速さを求めると質は落ちます。大抵の仕事がそうであるように、スピードと質はトレードオフ（片方を取るともう一方は取れない）です。質の悪いものを出さないようにじっくり時間をかけて、ときには徹夜で頑張る人もいるでしょう。 けれども質を追求した結果、締め切りに間に合わないような仕事の仕方をしていては本末転倒です。締め切りに間に合うことが明らかな状況であれば、質を高めるために時間を使うのは間違っていません。問題なのは、まだ仕事が終わる見通しが立ってもいないのに、質を高めるためにあれこれ工夫を凝らそうとすることです。 みなさんが普段使っている
パナソニック経営陣への５つの提言
日本の家電メーカーのソフトウェアの作り方や、人材の活用方法の問題点関しては、このブログでもメルマガでも何度も指摘したが、その問題を浮き彫りにするブログエントリーを見つけたので紹介する。 パナソニックを退社しました ...私の部署では、絵に描いたような昔ながらのソフトウェア開発が行われていました。 単価計算は人月とステップ数。仕様書を書く上流工程が重要で、コーディングは単純作業という価値観のもとでの開発です。当然正社員はなかなかコーディングに携わることができませんでした。 また、単純作業とみなされがちなコーディングを効率化しようとするモチベーションが少なかったのか、いくつか作業環境で疑問に思うところもありました。例えば、メモリ 1GB ぐらいの遅いマシンでビルドしている、ディスプレイが17インチ、きちんとしたソース管理がない、などです。PCスペックやディスプレイなどは入社の時期によってはそこ
Life is beautiful: 恋の連立方程式、「パートナー探し」の最適化アルゴリズムに関する一考察
「自分にできるだけ相応（ふさわ）しいパートナー」を見つけることは、我々人間にとって、人生の最も重要なのテーマの一つでもある。しかし、そのプロセスである「恋愛」や「お見合い」に関して、なぜか今までシステマティックな考察がされて来なかったように思える。そこで、今回はその「パートナー探し」のプロセスをモデル化・数値化することにより、最適なアルゴリズムを見つけようと思う。 まずは、「自分にできるだけ相応しいパートナーを探す」というあいまいな問題を、もう少し明確にモデル化された問題に単純化する。もちろん、単純化するとはいえ、あまり現実とかけ離れていては役に立たないので、現実味を壊さない程度の単純化を行う。 ［モデル化された問題］ 結婚適齢期の女性が、これから１０人の男性と順番にお見合いをして、その中から結婚相手を見つけることにしたとする。相手の意思は無視して良く、「この人と結婚したい」と宣言した時点
なぜ日本では「市民運動」が格好ワルイいのか？
原発事故以来、色々なことを考えているのだが、その一つが「なぜ日本では民意がなかなか反映されないのだろう」ということ。泊原発の再稼働容認が典型的な例。これだけ多くの人が反対しているのにも関らず（参照、参照）、必要だったはずのストレステストもなく、原子力安全委員会の形だけの二重チェック（参照）で北海道知事の再稼働容認となった。 「政治家が票集めで忙しくて実際に国を運営しているのは官僚」「官僚の業界への天下りが官民の癒着を生み出している」「マスコミはスポンサーに不利になることは報じない」などの政府やマスコミにも大きな問題があるが、国民側にも若干問題があると思う。うまく表現するのは難しいのだが、 政府は「お上」であり、市民運動とは「お上にたてつくこと」に相当する という江戸時代から続いているメンタリティが根っこのどこかにあるのではないかと思う。それが「市民運動＝左翼活動」というイメージを固定化させ
ホリエモンを有罪にしておきながら、この東電の粉飾決算を見逃すことは許されない
毎日新聞に「福島第１原発：東電が政府側に渡した文書の全文」という記事が載っているが、それを読んで少し驚いた。まさに東電と保安院がどんな形で、情報の隠蔽（正確には「原発事故の意図的な過小評価」）をしてきたかが良くわかる確固たる証拠だ（こんな文章が表に出る様になっただけ、日本も捨てたものではない）。 とくに驚愕なのは、以下の部分。 （１）地下水の遮へい対策は、馬淵補佐官のご指導の下、『中長期対策チーム』にて検討を進めてきているが、「地下バウンダリ（発電所の周りに壁を構築し遮水するもの)」は現在、最も有力な対策と位置づけ。ただし、対策費用は現状不確定であるものの、今後の設計次第では１０００億円レベルとなる可能性もある。 （２）今回の検討の過程で、政府側から国プロジェクト化の示唆(当初は国交省予算）があり、その前提で、設計着手と工事着工の前倒し案が浮上。ただし、現状では、担当府省がどこになるかも含
Cloud Computing考：Amazon ec2とGoogle App Engineの違いを私なりにまとめてみた
Cloud Computing の話が注目されるようになってしばらく経つが、商用での本格応用という意味ではまだまだ未熟な市場である。PhotoShareは去年の７月サービス開始時から Amazon の ec2＋S3 という組み合わせで運営しており、私から見れば当然の選択だったわけだが、あのタイミングで商用サービスへの採用に踏み切った会社も少なかったのか、何件かインタビューの申し込みが来たりして少し驚いている（参照）。 すぐに陳腐化するハードウェアの資産はできるだけ持ちたくないし、自分でデータセンターにラックを借りるなんてことはコスト的に見合わない。かといって、通常のレンタルサーバーは初期費用がばかにならない（今は少しは改善されているのかも知れないが、去年の段階では「それじゃあハードが自分で買えるじゃん」と言わせるぐらいの初期費用を請求する企業がほとんどであった）。それに加えて、どのくらいの
Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
Life is beautiful: 「時間に余裕があるときにこそ全力疾走で仕事し，締め切りが近づいたら流す」という働き方
かれこれ３０年以上もこの業界でプログラムを毎日のように書いて来た私。当然、自分なりの働き方のノウハウみたいなものも会得して来たつもりだ。以前ここに「私のとっておきのプログラミングスタイル」というエントリーを書いたので、まだ読んでいないプログラマーの方にはぜひとも読んでいただきたい。 ちなみに、そんな中でも後輩とか部下に教えるのが一番難しいのが、「スタートダッシュでできるだけはやくめどをつける」という仕事スタイル。どのエンジニアも、ちゃんと説明すればこの働き方の効用は理解してもらえるのだが、実際の現場でちゃんと実行できる人は１００人に１人もいない。 「人はみな怠惰だから、締め切りに迫られなければがんばれないんだ」と言ってしまえばそれまでだが、「まがりなりにもプロとして仕事をする限りは、ペース配分ぐらいはちゃんと考えて仕事をすべき」というのが私の主張。トップクラスのマラソンランナーでペース配分
iPad上でHTML5 Widgetを走らせて遊ぼう
昨日の「HTML5: W3C Widget とその応用を考える会」は参加者も多く、私自身とても良い勉強になったが、そこでも予告した通り、iPad発売を記念してWidgetのサンプルをいくつか用意したので、ぜひともお試しいただきたい。 手順は以下の通り。 ステップ１. iPadにCloudReadersをインストールする（iTunes ストアへのリンク） ステップ２. 以下のWidgetをダウンロードする Download 3dClock.wgt (2.5K) ー CSS3を使った３D時計 Download TimeTrial25.wgt (7.8K) ー タイムトライアルゲーム Download JSCalc.wgt (3.4K) ー 電卓 Download QuadraBench.wgt (2.5K) ー Canvas のベンチマークプログラム ステップ３. iPadをPC/Macに繋げ
電子出版に関する一考察：コンテンツのガラパゴス化の危機
今日は日経BPのセミナー（参照）で、iPadと電子出版の未来について講演をしてきた。私の講演の内容に関しては、一両日中にネットに上がると思うのでここには書かないが、この講演およびその準備段階を通して学んだとても大切なことを一つ書こうと思う。それは日本の出版社に迫る「コンテンツのガラパゴス化の危機」である。 午後の部でヤッパの伊藤氏の講演を聞いていて少し疑問に思ったので、フォーマットのオープン化に関する質問をした私だが、彼の「まだコンテンツの数が少ないのでオープン化を考慮する必要はない」という返答でヤッパの狙いが明らかになった。セルシスと同じく「クローズドなフォーマットによるコンテンツの抱え込み」である。 ここまでフォーマットのオープン化（すなわち誰でもビューアーをライセンス・フリーで作れること）の大切さが叫ばれている今、時代に全く逆行するビジネスモデルだが、漠然とした危機感を抱いてはいるが
iPadに最適化したPDFファイルの作り方
iPad向けにPDF/マンガリーダーCloudReadersを発表してから、いままで直に付き合いがなかった出版業界の人たちからちょくちょくコンタクトをいただくようになった。その中で良くある質問の一つが、「iPad向けに最適化したPDFファイルの作り方」。そこで今日は、そのあたりのノウハウをまとめて書いてみる。 まもなく日本でも発売されようとしているiPadは色々な意味で画期的なデバイスだが、あくまで位置づけはモバイル・コンピューターであり、パソコンではない。画面も大きく、CPUも高速になったとは言え、搭載するメモリ（RAM）の量はiPhone 3GSと同じだ。 そのため、メモリがふんだんにあるパソコン用に作ったPDFファイルを読もうとすると、メモリ不足でアプリが落ちたり、極端に遅くなったりしてしまう。アプリを作る側もいろいろと対応はしてはいるが（参照）、やはり快適にiPad上でPDFファル
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
共著「Google Chrome OS」出版のお知らせ
先日のセミナーでも少し触れた、「Googleのコモディティ戦略」。インプレスからこのたび出版される「Google Chrome OSー最新技術と戦略を完全ガイド」の「戦略」の部分に共著者の一人として寄稿したのでここで紹介させていただく。 Chrome OSにせよAndroidにせよ、OSをGoogleが無料で提供するには深い意味があるのだから、それをちゃんと理解した上で、自社のデバイスに採用するかしないかを「経営判断」として決めるべき。「他のメーカーも載せはじめたから」とか「自分だけ乗り遅れたくないから」ぐらいな安易な気持ちで始めると、「実際やってみたら得をしたのはGoogleだけ」という結末になりかねないので慎重にすすめるべき。 ２年ほどiPhone向けのアプリを作って来た結果、最近強く思うのは、テレビなどの据え置きがたの家電にアプリをダウンロードして走らせる、という発想自体が根本的に間
Google App Engine入門：実践編
今週に入って、Tiny Message に続く二つ目の Google App Engine ベースのサービスをリリースした。３日ぐらいで試験的に作った Tiny Message とは異なり、今回のものは、丸二ヶ月間寝る間も惜しんで作った力作である。 米国向けのサービスな上に招待制のSNSなので、ここではサービスそのものは公開しないが、いくつかこだわって作った部分があるので、それについて語ってみようかと思う。 1. 対象となるユーザーの絞り込み FacebookやTwitterのような巨人が存在している中で、それにまっこうから対抗するようなソシアル・ネットワーク・サービスを作ったところで無謀なだけである。そこで、逆に対象にするユーザー層を究極にまで絞り込んで、彼らのライススタイルに徹底的にマッチしたサービスを作ることにより差別化をはかる、という戦略を選択。対象は「LAに住む２０〜３０代の社交
「Flash vs. HTML5」という構図がはっきりと見え始めたぞ、と
業界関係者（特にスマートフォン関係の仕事をしている人たち）少し前からすでに気がついていた話だが、今回のAdobeからの一連のアナウンスメントで明らかになってきた「HTML5対Flash」という構図。とてもワクワクする戦いだ。 ウェブ上のリッチコンテンツという分野でリーダーシップ・ポジションを取りながらも、「無料Flashゲーム」と「ウェブサイトの見栄えをちょっと良くするアイ・キャンディ」というニッチなポジションに一度は追いやられるように見えたFlash（数年前の話）。しかし、動画フォーマットがReal Networks、Microsoft、Appleの三強いの間で中に浮く隙間を付いた戦略で、見事に「ウェブ上のマルチメディアのデファクト・スタンダード」のポジションをがっちりつかんだかに見えるFlash（現在）。しかし、その地位も安泰ではない。 Adobeにとって一番頭の痛い問題はiPhone
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
