Ask 37signals がおもしろすぎる件

最近 37signals が Blog で読者からの質問に答えています。Ask 37signals で始まるエントリーがそれ。
これがおもしろすぎる。Jason をはじめ、僕は元々 37signals のファンなのですが、このシリーズでより一層彼らの考え方に惹かれています。
主張している内容はいつもと変わりませんが、でもそれが読者とのやりとりの中で見られるのがおもしろい。新しい発見なんかもあったりして。
特におもしろかったエントリーを、その中で気になった箇所の引用と共にご紹介します。手抜きなので、引用が長い上に特に訳とかも用意していません 😛
興味のある方はリンク先をどうぞ。
1つ目。Jason が Simple なソフトウェアの重要性を説明しているエントリー。引用長すぎですがご了承ください。
Ask 37signals: Is it really the number of features that matter? – (37signals)

What matters is the editing. Software needs an editor like a writer needs an editor or a museum needs a curator. Someone with a critical eye and the ability to say “No, that doesn’t belong” or “There’s a better way to say this.” Physical constraints create natural limits for books and museums. Books have pages and museums have wall space. Software, on the other hand, is virtual, boundless. Anything is possible. When anything is possible someone inevitably tries to make something do everything. And the more something does the harder it becomes to understand, grasp, and use. So the key is deciding what makes it and what doesn’t. This applies both globally (the entire inventory of features) and locally (what someone can do on the current screen they’re looking at).

小さなチームで開発を行う時、特に注意が必要なことです。当事者はこういった視点をついつい持てずに突っ走ってしまいがちです。改めて、意識的に No と言える視点を持とうと思いました。
2つ目。ビジネスモデルの変遷について、DHH のエントリー。
Ask 37signals: How to go from clients to products? – (37signals)

With constrained resources, you realize the value of the marginal hour very quickly. You can’t just goof around with science projects, open-ended explorations, and play time with new whiz-bang technology. Instead, you have to deliver real value, real soon.

real value, real soon. 体に刻んでおくべき言葉です。
3つ目。DHH が、Ruby on Rails 誕生の背景を次のように語っています。
Ask 37signals: The genesis and benefits of Rails – (37signals)

In the beginning, there was no Rails, there was only Basecamp. After working on Basecamp for a while, though, I eyed the option of giving all the generic pieces a life of their own. But even then, I continued to work on Basecamp first. Which meant that all the functionality of Rails came as extractions of a real application, not of a “what somebody might need some day” fantasy, so prevalent in framework design.

Rails の持つ魅力にまた心を動かされています・・・。そろそろ触ってみようかな。いや、それより先にやることが山ほど(ry
他にもいっぱいあります。それらもぜひご覧ください。
Signal vs. Noise
ちなみに、僕の Blog のデザインが、DHH の Blog のデザインに大きく影響を受けていることもここで発表しておきます。
次回の messa.tv は 37signals のプロダクトを取り扱います。実はもう撮影済みなのです。お楽しみに。

バリバリバリュー

今日はいつもお世話になっているあの人が出演する日です。楽しみ。
・・・でもいまから打ち合わせのために外出です。録画してもらって見よう。
僕はテレビを録画するための装置を持っていないのです。放送中のガンダムですら GyaO で見れる時代に、もはや録画する装置は必要ありません。と言いたいところですが、今日のはすぐに見たかったな・・・。
そういえば、番組のタイトルを「メッサバリュー」に変えてきてもらうのを忘れた。

Digg グッズゲット!

日本国内では入手できない Digg グッズ!ゲットしちゃいました!
Digg T-shirt 01
Tシャツとキャップです。
Digg T-shirt 02
Tシャツのアップ。ロゴがいいかんじ。
Digg T-shirt 03
この組み合わせにうっとり。
Digg T-shirt 04
キャップもかっこいい。
Digg T-shirt 05
次回の messa.tv はこれで出演決定。
これでも一応、mixi 内 Diggnation コミュニティーの副管理人なんです。Revision3 のみなさん、そして maki さん、Thank you so much!

last.fm が間違った情報を Scrobble

最近、last.fm のクライアントがおかしい。勝手にこんな情報を Scrobble する。
last.fm scrobble wrong data
ちょwww ツッコミどころ満載www
原因や再現性がわからず放置状態でしたが、さっきようやく本腰を入れて検証してみました。するとどうやら、last.fm のデータベースに無いタイトルの曲やアーティストの曲を再生すると、写真のような情報を送信してしまうようです。
それにしても、なぜこんな間違った情報を送るのだろうか・・・。このままだと、再生ランキングが圧倒的に変な結果で埋まってしまいます。
そして、last.fm でプロフィールを見られた場合、「なんというアツイやつだ」という勘違いをされてしまいそうです。
再インストールしても解決しないので、しばらくは Scrobble しないことにします。last.fm にはバグレポートを送信済みなので、何らかの対応があればいいのですが。

Continue reading “last.fm が間違った情報を Scrobble”

初音ミク全盛の時代に

なんだ、これが原因かw
タレントの初音ミクさんが失踪─「キモオタに疲れた」とこぼす : bogusnews

この曲は泣ける。ニコニコ動画が見れる人はどうぞ。

いや、僕は全然知らない時代の話なんだけど、これはいい。
初音ミクの方は、検索業界でおかしなことになってるみたいですが。
「初音ミク」画像がネットから“消えた”? – ITmedia News
この件については、23氏が結論を出しています。
痛いニュース(ノ∀`):「初音ミク」画像がネットから“消えた”?

Continue reading “初音ミク全盛の時代に”

スター戦略

ちょっと調べ物をしているときに、こんなものを見つけました。
saku-saku-wave: スター戦略下書き用PDF
もっと早く見つけてればよかった。ずっと自分で作ろうと思っていたのですが、やっぱり探せばあるものですね。すばらしい。さくまけんじさん、ありがとうございます。
なんだこれという人はスルーしてください・・・と言わずに解説したいのですが、ちょっと詳しく書いている時間がないもので・・・。
間単に言うと、戦略構築のステップを体系化した以下の本に出てくる図です。これを使って、戦略構築を行います。

こうなると、データの入力からレポートの出力までをサポートしてくれるアプリケーションがほしいなとか思ってみるテスト。

Feed 修正

この Blog の Feed がおかしいことになってたのに気づきました。ちゃんと反映されていなかったようです。
登録していただいていた方、失礼しました。
原因は Feedburner との連携の際に設定ミスがあったことです。こちらのサーバー側の問題です。
現在は期待通りに反映されるようになっています。今後ともよろしくお願いします。

CrowdChess でみんなでチェス

2〜3日前から、チェスがうまくなりたいなとか思ってました。そしたらいまさっき、こんなのを発見。
Does Chess Need to be Crowdsourced?
TechCrunch のエントリー。
CrowdChess
これがそのサイト。

CrowdChess is a radically new chess concept where thousands of people from across the globe, play together against each other, creating the ultimate “wisdom of the crowds” battlefield.

要するに、みんなで次の一手を考えようというもの。
まだ誕生したばっかりなのでどう発展していくのかは未知数ですが、コンセプトはおもしろそうです。
将軍が何人もいたら意志決定がスムーズに行かないだろうし、このやり方でほんとうに勝利出来るのだろうかと、興味がわきます。まぁ、お互いにチームで戦うわけだからどちらかが勝つわけですが。
僕は単純に、みんなの思考パターンをのぞけるというところに興味が湧きました。それぞれがそれぞれの経験により導き出した自分なりの戦略論を持ち込み、議論を行うのです。最終的にはチーム内での多数決によって「手」が選ばれるのですが、その過程に参加することにより、いろんな思考を体験することができます。
“wisdom of the crowds” の新たな可能性となるのでしょうか。
早くやってみたい。登録したんだけどまだ完了のメールが来ない。

遊び Wiki のすすめ

先月末に、友人とキャンプに行ってきました。その時のことも書きたいのですが、最近始めた遊び Wiki のすばらしさについて、今日は書きます。
Sunset behind us
夕日をバックに。
今回のメンバーでキャンプに行くのは2回目。いつも適当に計画を立てるため、前回の反省点を活かせずに同じような失敗をしていることに気づきました。
これではいかんと、キャンプから帰ってすぐに、メンバーが共有する Wiki を立ち上げました。取りあげている内容は、次のようなもの。

  • 遊びの計画
  • 遊びのログ
  • メンバー間の連絡
  • オリジナル遊びのアイデア
  • トランプ等のマイナールール共有

遊びの計画では、日程の調節や持ち物の確認を行います。最も重要なのが遊びのログ。遊びのログでは次のような内容を取りあげています。

  • 詳細な会計報告
  • 日程や時間の記録
  • やったことリスト
  • できなかったことリスト
  • よかった点
  • 反省点
  • 次回気をつけるべきチェックリスト

これだけでも、次回以降の遊びの効率は向上します。忙しいメンバーが集まるので、限られた時間を最大限に使って全力で遊ぶことが求められます。そのためにも、失敗という貴重な情報を大切に扱うことには大きな意味があります。
Wiki にまとめるのにはそれなりに時間がかかりましたが、それ以上の収穫がありました。前回の反省点と今回の反省点を比較しているうちに、僕個人の重大な反省点に気づいたのです。それはまさに自分の最大の欠点であり、それに気づけたことは非常に大きいです。それが何かをここで晒す勇気はありませんが、その改善のための行動を10月から始めています。
ただの遊びも、本気でやれば見えてくるものがあるということを改めて実感しています。
ちなみに、現在遊び用に利用している Wiki はこれ。
pbwiki
社内の情報共有には MediaWiki を使っていますが、今回は手軽に用意できる pbwiki にしました。おすすめです。

Design Matters で考えた Webサイト制作のプロセス

先週、久しぶりに Design Matters に参加してきました。ここ数回、自分のセミナーと日が重なって参加できていませんでした。
Garr さん、いつもありがとうございます。
今回のスピーカーは Ian Cheung さん。テーマは次の通り。
“How to improve your website in 30 mins using Information Architecture”
すばらしい内容でした。さっそく自分たちの Webサイト制作プロセスに、今回学んだ事を取り込んでいます。いっぱいメモって来たので、まとめて社内の Wiki にアップしよう。
特に印象に残っているのは、コンテンツの重要性に関する意見。強引に短くまとめてみると次のようになります。

  • Content is King なのは事実だけど、そのコンテンツを活かすためには、Goal や Audience を見極める必要がある。
  • その Goal に関しても、情報発信側の Goal と情報を受け取る側の Goal がマッチしなければ意図しない結果を招く。

このあたり、プレゼンテーション内で登場した例も非常におもしろかったです。見入っていて、今回は写真を撮り忘れてしまいました。
The Nine Lives – Ian Cheung, Information Architect in Osaka, Japan » Thoughts on my presentation on Information Architecture
プレゼンテーション終了後、いつもはしばらく Appleストアに残っておしゃべりをしています。そして、その後 Nijikai へと移動するわけです。ところが、ちょっとトイレに行きたかった僕たちは、先に Garr さんに店と予約名を聞いて、店でみんなを待つことにしました。
Nijikai へ移動する前、Garr さんが「Nijikai の会場の窓からは Apple のロゴが見える。これは重要なことだよね。」みたいなことを言っててウケましたが、店に行ってみるとほんとにいい位置にロゴが見えましたw
Waiting for everyone
待ってるときの写真。ちょっと人が増えて、これでも足りませんでした。
Great view
ほんとにロゴが見える。絶景かな。Appleファンの心境は、「満月が見える!」みたいな感じです。
English Menu at Izakaya
居酒屋で英語のメニューとかはじめて見たw
Domestic Grown Organic Tofu だったかな、もう何のことかわからなかった。ちなみに、フライドチキンと唐揚げは同じ。
Nijikai も盛り上がったし、ほんと Design Matters っていいなと思いました。今回もまたいい人たちに出会えたし、いくつか英語の Tips も教えてもらったし。
スピーカーの Ian さんとは、イングランドサッカーの話題で熱くなりました。なんてこった。ついに一緒に Champions League で Liverpool を応援する人ができたよ。嬉しすぎる。
ちなみに、彼のやっている Oboeyasui.com もいい!ぜひ使ってみてください。
Thanks, Ian!
次回の Design Matters も楽しみです。
AirMac Extrame
ちなみに今回 Appleストアに行ったついでに、AirMac Extreme を購入しました。それがすばらしいという話は、また改めて。