ユーザーに尋ねても必ずしも正しい答えは返ってこない
今日はたまたま「ユーザーからのフィードバックを集めることの難しさ」が話題になったので、それに関連するエントリー。 もの作りにおいて、「ユーザーが何を必要としているか」を知ることは大切だが、だからと言ってユーザーに尋ねれば正しい答えが返ってくる訳ではないところが難しいところ。具体的な例としては、こんなものがある。 1. サイレント・マジョリティの声は聞こえてこない これはMicrosoftで実際にあったことだが、Outlookのチームではユーザーから寄せられる機能追加のリクエストに従って色々な機能を足していた時期があったが、その結果不必要な機能ばかり増えて、単純な作業が逆にやりにくくなってしまった（たとえばカスタム・フォームが良い例）。このケースでは、ごく一部のヘビー・ユーザーばかりが声がでかく、「今の機能で十分、これ以上複雑にしないで欲しい」というユーザーは何も言ってこない（こういう人たち
Google App Engine入門：実行効率を犠牲にせずに開発効率だけを上げるテクニック
一つ前の富豪プログラミングのエントリーともつながる話だが、Google App Engineは「ちゃんとスケーラビリティを考慮してアプリケーションを作るには何に気をつけなければならないか」を勉強するには絶好の環境だ。そこで今回は、その「ケチな大富豪的なプログラミング」の実践編。 Google App Engine上のアプリをいくつか書いているうちに、必要に迫られて自然発生的にできてきたのが、gdispatchという数十行のコードからなる小さなモジュール（ソースコードはgithubに置いてある）。これをGoogle App Engineに標準で付いて来るwebappと組み合わせてフレームワークとして使っている。 gdispatchを設計する上で重視したのは、 （１）Google App Engine上でのアプリの開発を効率化する上で「明らかにこれがあると開発効率が格段に向上する」というもの以
Life is beautiful: 優秀なナースがいるとシステムがなかなか改善されないという話
「Why hospitals don't learn from failures（なぜ病院は失敗から学ばないのか）」という論文を読んでなるほどと思う部分があったので、ここにメモ代わりに書いておく。 この論文の筆者（TuckerとEdmondson）は、医療ミスがなかなか減らない原因を探るために、全米の１０の病院を長期間に渡って調査・研究したのだが、その結果判明したのは、「システムの改善」という観点からは、ナースの優秀さと勤勉さが逆効果になっているという皮肉な話。 「優秀なナース」の定義はどこでも同じで、「目の前の患者が必要としているものを、あらゆる障害を乗り越えていち早く提供する」こと。取り替えるべきシーツが不足していれば別の階に走って行って調達してくるし、新米のナースのミスにはいちいち噛み付くこともなくそのミスを取り繕う。そんなナースたちにとっては、その手の「不具合」や「障害」は避けられ
Life is beautiful: RailsがRubyで作られた本当の理由
弾：最初の質問です。なぜRubyを選んだのですか？ DHH：極端なことを言うと，Rubyが一番美しく自分のコードが書けるからです。 【小飼弾のアルファギークに逢いたい♥：#2 Ruby on Rails作者 David Heinemeier Hansson（前編） RubyでRailsを書いたわけ｜gihyo.jpより引用】 この記事を既に読んだ方も多いと思うが、この「Rubyが一番美しく自分のコードが書ける」というセリフは非常に重要である。「イテレータに片思い」というエントリーで書いた通り、Rubyには生みの親の「コードは読みやすくあるべき」という魂がしっかりと込められており、それが「コードの美しさ」に繋がっているのである。 私がRubyを触り始めて一番強く感じたことは、Smalltalkとの類似点である。私自身、９０年に数ヶ月間Smalltalkにどっぷりと使っていた時期があるが（マイ
２１世紀の錬金術：Web2.0バブルで一儲けする方法
【材料】 ・小さな学生ベンチャー。東大・京大などの有名校の理学部・工学部の卒業生が集まって作った１０人程度の企業。売り上げどころかビジネスプランすらちゃんと描けていないが、そこそこの技術力とハングリー精神だけはある、というタイプがベスト。資本金は少ない方が良く、ＶＣからの資金調達前でなければならない。 ・３～４億円程度の資金 ・欲の皮のつっぱった証券会社へのコネ 【レシピ】 １．まずは、顧客としてこのベンチャー企業にアプローチする。ビジネスプランもろくに持たないベンチャー企業の場合、とりあえずは「開発の下請け」でも何でもやって売り上げを立てなければならないので、その弱みを突く。Web2.0っぽいものならブログでもＳＮＳでも何でも良いので、とりあえずシステム構築を発注する。この段階での発注額は二～三千万円ぐらいに抑えておくが、それでもこの会社にとっては「最大の顧客」となるはず。 ２．その会社
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
