ユーレカ！ハッカーズチャンプルー 2015 #hcmpl での発表資料です
less is more - naoyaの寿司ブログ
機能は少なく、シンプルな方が良いというのが近頃のスタンダードな考え方だろうけど、それがなぜ良いかについて少し斜め上からの考察。ユーザーから見た場合は、迷いなく使える、そのソフトウェアが提供する機能が限定される。人間は選択肢を与えられるとストレスを感じる生き物なので、選択肢がそれしかない、という状況は快適。少し文脈外れるけど、Readability でページから余計な情報を削いだら集中して読めたりとか、iPhone/iPad のダブルタップで文章にフォーカスしたら同じような状態になるのも、「他に意識を取られるものがなくなる」という心理効果が大きいのだと思う。と、ここまではユーザー視点。一方で、個人的にはこちらも大事だと思うのがサービスの作り手視点。機能をシンプルに、また数も少なく留めておくと、ユーザーがそのサービスをどういう風に使っているかということに対して、自分達の想像とユーザーの実際の行
自覚 - naoyaの寿司ブログ
きれいなコードを書こうぜ、といってるのに対して製品の善し悪しに綺麗なコードがいいかどうかなんて関係ない、みたいな話とか 仕様書とかぜんぜん読まないから仕様書なんて全く必要ない、さっさとコード書けとかコードだけで語れ、とか TDD されてないからリファクタリングできないんだ、だからカバレッジ100%にするんだ、ぜんぶテスト書け、とか エンジニアは技術から出発して需要を考えない、だから問題から入れ、技術なんて関係ない、とか 企画屋は技術のことがわかってないから、夢物語りばっかり語るんだ、エンジニアがサービス作るべき、とか そういう、何かを反面教師に反対の考え方を支持するみたいなのは注目浴びやすいけど、視座をもうすこし中立にして考えると、だいたいおかしい。かくいうぼくもそんな風に煽ってる時期がありました、若さって怖いです ─ 中庸って知ってるか。伝統や、むかしから習慣として良しとされてきているこ
面倒な仕事その2 - naoyaの寿司ブログ
面倒な仕事その2http://naoya.hatenablog.com/entry/2012/01/20/121736に面倒な仕事、ということを書いた。「大きな問題を引き受けるほど、利益は大きい」みたいな話は、まあそれはそうだよねという話でしかなくて、あのポール・グレアムのコラムでぼくが大事だなと思ったところはそこではない。(それに、問題は大きくとらえて解決しろみたいなのはやりたい人はそうすればいい、別に解こうとする問題は必ずしもそんなに大きな問題じゃなくてもいいんじゃないの? 自分たちの解きたいサイズの問題であればそれでいいんじゃないか、と思ったりすることもままあるし。)コラムの中で、大事だなと思ったのは "。無意識に、面倒で嫌な仕事が伴うアイデアが浮かばなくなってしまう。" の「無意識」というところだ。面倒な仕事だって分かってて避けてしまうんだったら、それにちゃんと向き合いましょうね、
面倒な仕事 - naoyaの寿司ブログ
ポール・グレアム「面倒な仕事の無視」 http://blog.livedoor.jp/lionfan/archives/53580166.html いちばん危険なのは、面倒な仕事を嫌がる気持ちの多くが無意識であることだ。無意識に、面倒で嫌な仕事が伴うアイデアが浮かばなくなってしまう。これが「面倒な仕事の無視」だ。 The most dangerous thing about our dislike of schleps is that much of it is unconscious. Your unconscious won't even let you see ideas that involve painful schleps. That's schlep blindness. このコラムには本当に大切なことが書かれている。近年ずっと感じてきた違和感が、文章になっている。面倒な仕
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
