[37signals] 顧問など要らぬ

(原文: Who needs a board of advisors?)

「でも私はビジネスを始めるには____が必要だと聞いているよ」____には顧問役・ビジネスプラン・その他といった、君と君自身の構築するビジネスの間に立ちはだかる障害物を入れてみよう。一般的に見られるこういった「ねばならぬ」という考え方は、実は助言という皮をかぶった言い訳でしかないということに気付いているだろうか？これらは無為を正当化する時の理由でしかない。こういった考え方は、君と君の為すべき事との間に layer（訳注: 分離層）あるいはlawyer（訳注: 弁護士）を配置する。

顧問役は頼りになる。ビジネスを始めるにあたっては顧問役が必要だと考える人もいる。だが実際のところ、これもまた物事に着手しない時に使う言い訳の一つなのだ。君のビジネスについて君よりも上手く切り回せる奴がいると考える方がおかしいと思わないか？ 君は充分知っているし、今はまだ知らない事も、この先、学ぶ事になる。もちろん、まわりの人に助言を求め彼らの経験に学ぶというのも良いかもしれないが、型にはまったようにそうする必要など無い。

起業に当たってはこういったものが必要だよと言って君をビビらせるようなやり口を世間に広め、君に大枚はたいて顧問弁護士を雇わせるような試練を強いている奴らが誰なのか、思い起こすが良い。奴らの自作自演なのだ。ビジネス書やビジネス雑誌を出版・執筆する連中や弁護士といった奴らは、君に「正しいやり方」なるものを提示することであぶく銭をかせいでいるというわけだ。また同時に忘れてはならないのは、ベンチャー投資家や既存ビジネスの連中が、とにかくやってみろとか何々をすべきだとか言うのは、自らの商売のために言っているのだということだ。

今度「君にはこれが必要だ」とか「君にはあれが必要だ」といった事をビジネス立ち上げの時に耳にする事があったら、疑ってかかることだ。自分に問いかけてみよう「本当に必要か？当面は無しでいけるんじゃないか？」と。

[Dion Almaer] 遂にブラウザが時代に追いついた。もう「Webページの未来」なんかじゃないよね

(原文: Browsers are finally catching up; It isn’t the Future of Web Pages is it)

Benと私は、風光明媚なマイアミで行われている Future of Web Apps （訳注: 原文ではリンク先が自分自身へ張られていたので変えてあります）で講演している。中西部に住んでいるという事もあり、陽気のいい土地に出かけるのは大歓迎だ。先日のロンドンでの講演は本当に楽しかった。その時は Gears について話した。 今回 Ben と私は Web の現状について話しているのだが、Web の現状は間違いなく私達にとって刺激に満ちたものになっている。タイミングもばっちりだ。先日公開した、私達が最先端の技術に触れあう場である Bespin プロジェクトの舞台裏について話せるからね。私達はもう古いブラウザというしがらみに縛られてはいないけれども、以前とは全く異なるこの現状も、さほど驚くほどのものじゃなくなった。こういったしがらみは私達を石器時代に留まらせるものだし、もし私達がそれを受け入れて共存してしまったら、プラットフォームは、革新を経たプラットフォームに比べて見劣りのするものになってしまうだろう。

2009年になってもまだ私達の大半は『Web ページを見る為に作られたブラウザ』という世界の中で作業しなきゃならない。こんなのは『Web ページの未来』とは呼べないよね！

革新的且つ忌々しい作業を通じて、開発者コミュニティは遂に Ajax という進化をもたらした。見た目こんな感じだった：


やっつけ仕事とひねり過ぎなやり口ばかりだった。正直つらかった。でも初期の飛行機がそうだったように、やり方なんてどうでも良かった。現にケモノだってフツーに飛んでるじゃん！ この急場しのぎの技術集積は、アプリケーション開発を可能にするという形で、私達に飛行能力をもたらした。XMLHttpRequest 等が私達にもたらした小さな革新は、たとえオープン Web であっても、やろうと思えばインタラクティブなユーザエクスペリエンスが作り出せるのだということに他ならなかった。

そして遂にブラウザは変革の時を迎えた。「ブラウザ開発者達はデスクトップアプリケーションレベルの Web アプリケーションを作れるプラットフォームを構想しているんだな」という事を如実に示すテクノロジ群を伴って、新たな成果物が出現している。Chrome の漫画にはそういったネタがいっぱい詰まっている。そんなテクノロジのいくつかに光をあててみよう：

• 超高速なJavaScript　他のプラットフォームはスマートな JIT VM を搭載しており、この点については Chrome でも変わりはない。ブラウザに組み込まれた最新の VM により桁外れの実行性能向上がもたらされている。これは 速度の向上のみならず、Web アプリ開発というゲームが全く違う次元に移行したということであり、これまで出来なかった事が出来るようになるということを意味している。
• プロセスの分離　高速な JavaScript 処理自体は素晴らしいものだが、旧式なシングルスレッド型ブラウザには依然としてボトルネックが残る。Web ワーカは、処理の分離を行うための実に良く出来た API（スレッド API ではない！）を提供している。多分私達は「もっと色々な事が出来るんじゃないか」と考えるだろうから（だって JavaScript の処理が高速になるわけだからね）気がつくとコード量は増えているわけで、目先のコードを実行する一方、そうやって増えたコードについてはブラウザにやらせる必要がある。
• マルチプロセス　高速な JavaScript 処理と Web ワーカがあったとしても、境界というものは保たれる必要がある。もし GMail・カレンダー・Bespin・その他３つの Web アプリが動いていて、それらが全て情報更新等のためにポーリングを行うとしたら、CPU への同時要求によりコリジョン（要求のぶつかり合い）が容易く発生する。新たなマルチプロセス型のアーキテクチャならばこの問題を回避出来る。Bespin に取り組んでいる今、この機能については可能なかぎりうまく実装されてほしいものだと願っている。
• リッチな描画表現　私達はテキストとボックスと画像を組み合わせるのに慣れている。でもこれじゃちょっとね！ こんな単純な構成要素だけでやってきたのかと思うと驚くんじゃないかな？ canvas・SVG・新しい CSS プリミティブ（border radius, CSS animation, CSS transition, CSS shadows 等）があれば、これまでのボックスにとらわれない発想がもたらされる。
• デスクトップサービス　私達はもっと手を延ばす必要がある。実際のアプリケーションはクリップボードとやりとりし、位置情報を取得し、住所録にアクセスすると言ったことを行う必要がある。「〜をするにはネイティブアプリ のフレームワークを使う必要がある」とみんなが口にする現状を乗り越えるためには、この問題を解決しなければならない。私達に必要なのは使い物になるトラストモデル（訳注: 実行許可のポリシー設定など、アプリケーション間通信における信用の確保に必要なモデル）であり、その API をブラウザに組み込むことだ。

私達のたどりつく先はこんな感じになる。喩えるならば最初の飛行機からジェット機への進化だ：


私がオープン Web のための新しい開発ツールを使って仕事をすることにいつも胸躍らしている理由はこれなのだ。コミュニティがもたらしてくれるものに私は元気付けられている。ブラウザ開発者・Web 開発者とともに大きな変革をもたらすことが出来るのだ。

確かに Kool-Aid（訳注: Kraft Foods 社の生産している粉末ジュース）を切らした日にゃいつだって、プラットフォームの抱える問題が気に障るようになる。道のりは遠いし、旧いブラウザを無視する訳にもいかない。でもまぁ、やってりゃそのうち良い事あるさ。

[Google] GMail 鯖落？

気付いたのはPM８時過ぎ。IMAP/POP3でのアクセスはいけるらしい。

• Gmail down ? I'm getting "Server Error The server encountered a temporary error and could not complete your request. Please try again in 30 seconds. " (Paris, France, Feb 24th 2009, 11.25AM local time)
• Google's Gmail experiencing web outage
• Gmail Servers Down? 24/02/2009
• Gmail Down, Is It The End?
  

Update: 上から２つめの記事のアップデートによると、GMailサポートページに公示が出たとのこと。

2/24/2009

We're aware of a problem with Gmail affecting a number of users. This problem occurred at approximately 1.30AM Pacific Time. We're working hard to resolve this problem and will post updates as we have them. We apologize for any inconvenience that this has caused.

01:30[PST]頃に障害発生とのことなので日本では18:30頃からということになる。

Update: 21:28[JST] 復帰を確認。

[Greasemonkey] SICPページャ

オンライン版のSICPをぽつぽつ読んでるんですが、next/previousリンクをクリックするのがダルいのでキーボードだけで読み進めるためのGreasemonkeyスクリプトを書きました。こういうのをちゃっちゃと作れるのがFirefoxのいいとこですな。GitHubに置いてありますので人柱上等な方はどうぞ sicp_pager.user.js

[Dion Almaer] 教育と政治がおかしくなっていることを示す好例『入力 vs. 出力』

(原文: Exactly what is wrong with education and government; Input vs. Output)

セクハラ関連法に関する教習を受けるのは良い事だ。私もその趣旨を理解し賛同してる。でも実際行われている教習と来たらあまりにもひどくて、ひとこと言わずにはいられない。

法律では２時間の受講を要するとの指定がある。これって変だと思わない？

私がオンラインで受講した際、第１課を終えた時（質問には全問正解したよ）にこんな画面が出てきた：

あなたは現在、２時間の受講義務を満たすペースより速く進んでいます。次の課目に進めるようになるまでの待ち時間は下の方に示されています。

これまで学んだ事についてじっくり考えてみましょう。興味があれば、公正雇用機会委員会 (EEOC) で記録されている、セクハラに関する課徴金の動向を示す統計を御覧になれます。

セクハラに関する統計はこちら

次の課目に進めるようになるまでの待ち時間： 03:55

「予定より速く進んでいる」のに「追いつく」ために何分も座って待ってろと来た。

「２時間ばかり座ってなさい...待っている間にマリオカートで遊べそうなもんだけど、理由があってそれは駄目なのです」とただ単に言うのではなく「米セクハラ関連法について理解出来そう」であることを証明するための試験をする方が良いんじゃないか？

もう、頼むから、入力でなく出力を尺度にするようにしようよ。３分以内に全問正解したらそれでいいじゃん。理解してるってことなんだから。

[37signals] マルチタスクは凡人への近道

(原文: Multitasking is the fastest way to mediocrity)

最近、仕事に忙殺されている。何が原因かは見当もつかないが、この１０日間ほどというもの、３つの案件をこなしている。書類作りに管理業務に設計業務に見積業務に執筆業務に雑務。

散らかし放題の机。アイコンでいっぱいになったデスクトップ画面。あふれ返った電子メール受信箱。連絡をつけなければならない人の一覧。１００件はありそうな決断事項。

愚痴を言ってるわけじゃない、事実を認識しているだけだ。こういった状況を鑑みてわかったのは、マルチタスクは凡人への近道だということ。物事というものは、全力を注ぎ込まないと駄目になる。

最近こなしている業務には、全神経が研ぎすまされるあのスリル感が無い。

これは打開策ではなく注意書きのようなものだ。もし大きな仕事を為そうというのであれば、一つの事に集中することだ。一つの事を終えてから次に取りかかるのだ。これはすなわち、まわりの人が期待するほど物事を手早く片付けられなくなるということだ。まわりの人が、一つの事にかかり切りになるなと口出ししてくるということだ。だが、山積みになった業務をやっつけ仕事や浅はかな決断でこなしたところで何の値打ちも無い。

[scobleizer] Facebook におけるデータ所有権、まぁどうでも良いんだけど

(原文: User data ownership on Facebook and why it doesn’t matter)

げげ、週明け早々みんなが腹を立てているよ、Facebookの新しい利用規約に。

ぶっちゃけ、そんな事はどうでも良いんだけどね。

もし君がコンテンツをアップしたりオンラインで議論に参加したりしているのであれば、君は多くの権利をサービス提供者側に譲渡しているわけで、なんというか、実際のところそのコンテンツに関する支配権は君には無いんだ。

サービス提供会社は倒産により君のコンテンツをチャラにすることが可能だ。君のアカウントを削除することも可能だ。君の提供したコンテンツで金儲けすることも可能だ。利用規約には多分こういったむちゃくちゃなことが全て盛り込まれてる。

Flickr にもこの事が当てはまる。YouTube も。Twitter も。Facebook も。みんな当てはまる。

私はこの一年、Facebook が顧客をどう扱っているかについて声を大にして喚き立ててきた。Facebook は既にアカウント削除という手段により、顧客に対する姿勢を明らかにしている。支配権はFacebookにあり、お前達は無力なのだと。

まぁ上手くやることだね！ え、私はどうしてるかって？ 私は Flickr に投稿する写真は全て著作権を放棄するようにしているよ。

私はこういった問題に関しては Fast Company（訳注：Scobleの所属している企業）の自社サーバにコンテンツを置く事で対処している。TubeMogul（訳注：動画共有サービス）にアップするのに比べるとえらく時間がかかるというのが痛いところではあるんだけど、これによりコンテンツの支配権を確保出来るし、どのタイミングで広告がコンテンツの頭に挿入されるかを把握出来たりするわけだ。

ということで、肩の力を抜いて楽しむ事だね。Facebook が君にサービスを提供するのではなく、君が Facebook に奉仕する立場にあるんだと考えればいいのさ。別の類似サービスが身近にあるとは限らないしね。

[BB Gadgets] アメリカの作家協会がテキスト読み上げソフトを違法だと主張

(原文: Author's Guild claims text-to-speech software is illegal)

Kindle 2 の目玉であるテキスト読み上げ機能は、既にデスクトップPCやスティーブン・ホーキング博士が使用している事で知られるボイスボックスに組み込まれているソフトウェアと同じ手法で実現されている。この機能が「動揺」を引き起こしている。作家協会事務長である Paul Aiken は WSJ 紙上で、読者にはテキスト読み上げ機能を利用する権利は無いと述べたのだ。それでは無料のオーディオブックになってしまうじゃないか、というわけだ。

「読者に本を音声で読み上げる権利は無い」と作家協会事務長のPaul Aiken は語った。「それは著作権管理下にある二次著作物であるオーディオの利用権にあたるからだ」

Amazonのスポークスマンは、読み上げ機能はテキストの音声化技術に依存しているので、聞く人がオーディオブックと混同することは無いだろうと述べた。オーディオブック大手である Audible はAmazon の傘下にある。

テキストの音声化は既存作品のコピーには当たらないという点についてはひとまず置いておこう。人工的に音声合成されたテキストの読み上げと生身の人間によるニュアンスや感情の込められた読み上げが同じ物であるという馬鹿げた考え方についてもひとまず置いておこう。問題は作家協会が、声に出して読むという行為すらも違法コピーであり公衆送信権の侵害であると主張しているという点にある。

機械が声を出して本を読むのが二次著作にあたるのだとしたら、人間が声を出して本を読む事はなぜそれに該当しないというのだろう？

考え方というものは自身の意図に基づいて器を満たすべく成長するが、悪しき考え方のもたらす問題は、その器に漏れがあり歪んでいるという点にある。たとえ諸君が広範なる著作権法にゆるぎない信頼を置いているとしても、知財という考え方は、己の哲学を正当化するために法という装置を作り直すという理由から、悪しき考え方なのだ。この、功利主義に始まり不磨の大典へと至る道のりは、途方も無いモンスターを産む。このモンスターは複製行為を管理するのみならず、あらゆる表現や文化の持つ意義を管理するモンスターにならざるを得ないのだ。

---

訳者コメント:
Daring Fireball でこの件を知ったんだけど、ネタとしか思えん。エイプリルフールにはまだちょっと早いんじゃね？

まぁ「知財」なるものがフィクションでしかないというのはもう誰の目にも明らかなのだから、こういったネタを投下して炎上を早めようと言う意図が作家協会側にはあるのかもしれぬ。

んなわけねーw

[37signals] 大企業において、はみ出し者になるということ（Best Buy 風に）

(原文: Going rogue inside a big company (a la Best Buy))

どうすれば大企業において Getting Real 的なアイディアを実施出来るのだろう？ はみ出し者になる、というのが良い案だ。何か良いネタを見つけ出し、こっそりと実行するのだ。普通なら数ヶ月掛かるものを数週間で作り上げるのだ。現状より上手いやり方で何かをやってのけるのだ（上手く行くという証拠を示す、というのでも可）。そうすれば、くどくどと誰かを説得する必要は無い。結果が全てを語ってくれるのだから。

先日のアクセル・ローズ vs. フランク・シナトラ（訳注: 訳はこちら）に続き、今回も音楽を例に挙げよう。君がバンドのドラマーだと仮定してみてほしい。もし君がバンドリーダーに、これまでと違ったことをする許可を求めたとしても、君の全身全霊をこめた説得が口喧嘩に終わるか、アイディアが却下されるというオチになるだろう。だが、最も良いと君が思った事をそのまま実行してみたらどうなるだろう？ コーラスの最中にライドシンバルに切り替えたり、スティックでなくブラシで叩くようにしたらどうなるだろう？ もしそれが良く聴こえたら、それが良いのだ。みんなが納得してくれるだろう。

君の目指す方向に物事を進めたいならば、これが近道だ。理屈を脱して実行に移すことだ。打つ手や代案があるならば、議論に時間を費やすことはない。

Best Buy の Blue Shirt Nation

家電小売業の巨人である Best Buy は、私の知る限りで最も革新的な職場のうちの一つを実現した。この革新をもたらした主因は、そこに勤務する大胆不敵なる従業員が、はみ出し者になるという決意をしたことにある。

Best Buy 従業員向けのオンラインコミュニティとして大きな成功を収めている Blue Shirt nation (BSN) を立ち上げた Steve Bendt と Gary Koelling が例として挙げられる。サイト構築後一年もしないうちに、２万人の従業員（全従業員数は１５万人）が登録した。従業員達はそこで顔を合わせ、知識・ベストプラクティス・店舗の売り上げを伸ばす為のアイディアといったものを共有した。

そして、こういったことを Bendt と Koeller はこっそりと行った。自分たちのやっている事を売り込んだりはしなかったのだ。上司に許可を求めるようなことはしなかった。サイトを構築しただけだ。Steve Bendt はこう説明している：

私達から見てもスポンサーが付くとはとても思えないアイディアをもとに、BSNはスタートした。サイトが動き始めた2006年６月、Gary は全てを BSN に注ぎ込んだ、内緒でね。ドメイン取得と１年間のホスティング料で１００ドルかかった。サイト構築の為のソフトは全てフリーソフトウェアにした。ユーザは一人だけ。サイト管理者だ。

モデレーション（訳注: サイト運営者が投稿内容をチェックし、チェックを通ったものだけを掲載する事）はコミュニティ自らが行った。モデレーションの必要性自体ほとんど生じなかったからというのもあったんだがね。開始早々のうちは、バックアップに保存された投稿数がトータルで３件というありさまだった。Bendt が怖れたのは、上の連中が従業員に対して BSN のことを大っぴらに口にするよう仕向けるのではないかということだったが、そうはならなかったと語る：

上層部の多くが公開フォーラムを作ることを考えているように私には思えて不安だったんだが、Blue Shirt Nation はそんなことにはならなかった。私達はコミュニティの運営について責任を感じ、こう言ったんだ「みんな聞いてくれ、馬鹿な事（訳注: BSN を必要以上にオープンにするような事か？）をしないよう、お互い気をつけようじゃないか」

「みんな聞いてくれ、馬鹿な事をしないよう、お互い気をつけようじゃないか」とはまさに金言だ。ああ、従業員にこのような考えを持つ事を奨励する企業がもっと増えてくれればなあ。

ゲリラ戦法により実現した成果主義

Best Buy 従業員が、はみ出し者になることで革新をもたらした事例は Blue Shirt Nation だけではない。企業の方針を成果主義へと押し進めるために秘密裡に実践活動を行った二人の従業員のおかげで、企業カルチャー全体に変化がもたらされた。

何年も前の事になるが、Best Buy は「でかくて堅苦しい」企業の典型だった。職員は朝早く出勤し、夜遅くまで勤務しなければならなかった。時には昼食時でさえ外出簿に署名を求められることもあり、レストランの場所と帰社予定時刻も併せて記入する必要があった。１５分間隔で従業員の勤務状況を調査する職務というのもあった。従業員達は、死ぬ程長い勤務時間・自分の生活というものの欠如・耐え難いストレスの中でやっていくことについて不平を漏らした。

人事部に所属していた Jody Thompson と Cali Ressler の二人は、状況が芳しくないことに気付き、実験を行う事にした。二人はプライベートで会合を持ち、勤務時間によってではなく産み出した成果によって従業員の考課を行うという成果主義のアイディアを思いついた。その後、二人は秘密裡の先行実験を、ゆっくりと少しづつ行った。

勤務時間の基準を撤廃し、日程表を撤廃し、会議の出席義務を撤廃した。当初、こういった試みが少数の部署にて始められた。この秘密裡のゲリラ戦はあっという間にウィルスのように拡散し、企業に革命をもたらした。

トップダウンで承認されるのを待っていたら、こんなことは決して起こり得なかった。実際、CEO の Brad Anderson が全貌を把握したのは、この変革が企業を変え始めてから２年後のことであった。

Best Buy の従業員達はいかにして「そんなことしたら生産性が落ちるんじゃないか？」という、企業上層部に昔から根強く見られる懸念を打ち破ったのだろう？ 結果で示したのだ。オンライン受注業務の監督を担当している Chap Achen は、彼のチームの人員が一時間あたりに何件の受注処理をこなすことが出来るかを勤務場所を変えて測定するという業務効率測定法を思い付いた。１ヶ月もたたないうちに、Achen はこの変革が上手く行っていることを証明する事が出来た。勤務地に常駐している職員に比べ、常駐しない職員の方が13〜18%多く受注処理をこなしていた。時が経つにつれ、実験は一層大きな成果をもたらすであろうということが誰の目にも明らかになった。部署における職務満足度と職員定着率が、これまでで最良の数字を示したのだ。この事実を前に、誰が敢て実験に文句を付けようとするだろう？

実験がもたらした結果は、全社を通じて同じものとなった。離職率は劇的に低下した。成果主義へと方針を変えた部署では、平均して35%の生産性向上がみられた。従業員の職務満足度も同様に向上した。

二人のはみ出し従業員がもたらした変化には驚くべきものがある。彼らが Best Buy のような大企業においてもやってのけたのだから、諸君の職場においてもやれる事はあるんじゃないか？

[一言居士] たわごと

自然言語って実は全然「自然」でない。その理由も大体見当は付く。人間もしくは人為というものが、本質的に、不自然であることから逃れ得ないからだ。

自然においてあまりにも弱々しい人間達に与えられた不思議なハード・ソフト複合体。それが生成文法というものだったんだろう。

その林檎の代償として、人は不自然を大量生産し、貪り食う存在になった。生きたければ血まみれになれという自然の摂理は、臭い自然に蓋ということで隠蔽されたが、不自然から逃れ得ないのと同様に自然からも逃れ得ない以上、それは人間につきまとい、不自然という殻のなかで脈打っている。とあるクリエイターがこのコンセプトに原罪という名前を付けたのだが、フォロワーによって未だに書き散らされているシナリオにより、その公演は超ロングランとなっている。

老荘の始点（即ち終点）もまた、自然と不自然のせめぎあいを見つめるところにあった。その言説はなんという壮大にして豊饒なる、言語の無駄使いであったことか。言語の限界を示す為だけにあれだけの言語を尽くしたのだ。でも、それで良いのだろう。おそらくそれが人為の限界なのだから。「人知に即き、人知を捨てる」という円環の中で延々と暇潰しを続ける。我ら死すべき人の身に出来る事といえばそれだけなのだ。

[Dion Almaer] 本物の WebKit さん、御起立願います

(原文: Will the real WebKit please standup)



最近、パロアルトでこんなやりとりを耳にした：

• 男A: WebKit で試してみた？
• 男B: どの WebKit？

これは以前にも耳にした事がある。私は今まさにこの問題の渦中に足を突っ込みつつある。私のチームが取り組んでいる案件では、最先端の Web 標準を利用しているものがいくつかあり、つい最近も WebKit の nightly ビルド（訳注: 毎晩のように更新される最新の開発版）に何点かの追加実装があった。不幸な事にこの追加実装は、Chrome・ AIR・ モバイル版 Safari（この件についてはこれも該当するのだ）・その他の（Nokia から Titanium に至る）WebKit 派生品を利用している人々にとって等しく実装されているということを意味しているわけではない。

だがその一方で、 WebKit を採用していれば企業はお互いの成果物による梃子の作用を大いに享受出来る。派生は、殊に皆が目的達成に向かって出来るだけの支援を惜しまない状況であれば、必ずしも悪とはならない。WebKit 開発チームは CSS アニメーションを実装しており、これが将来においてあらゆる WebKit ベースブラウザ群で利用出来るようになる事を皆が望んでいる。この先数年、多くの大企業とやりとりしている WebKit コミュニティをウォッチするのは実に興味深いものになるだろう。幸いにもコア・チームは切れ者ぞろいであり、コミュニティを前進させ続けることだろう。

[37signals] アクセル・ローズ vs. フランク・シナトラ：時間を掛けりゃ良いってもんじゃない

(原文: Axl vs. Frank: More time doesn't mean a better product)

よくある考え方で「時間を掛けければかける程、出来は良くなるものだ」というのがある。これはおそらく、ある程度ならば正しい。だがしばらくすると、というかすぐにかもしれないが、みんなこの考え方に必要以上にこだわってしまうことになる。

物事にはみな、頃合いというものがある。切り上げ時というやつだ。結局のところ、いじり回したいが為だけに、えんえんと時間をかけていじっているにすぎない、ということなのだ。いじり回しているうちに駄目にしてしまう事すらありうる。製品リリースの３ヶ月後にいじることで凄く良い結果をもたらすというのも時にはあるが、更に６ヶ月（あるいはそれ以上）たってからいじるとなると、製品はごちゃごちゃと複雑に入り組んだゴミの山に成り果てる。

"Chinese Democracy" が良い例だ。アクセル・ローズが１０年以上にわたり、少なくとも３つのスタジオと４人のプロデューサを注ぎ込んだガンズ・アンド・ローゼズのアルバムだ。これ以上時間をかけても良くはならないというのはみんなわかっていた。実際、音楽業界では良くネタにされた。いつまでもおもちゃを手放そうとしない仕切りたがり屋のガキが砂遊びをするにはうってつけだった、というだけのことなのだ。

一方でフランク・シナトラは「一発録り」で知られている。スタジオに入り、フルバンドをバックに生で歌い、歌い終えると踵を返して出て行く。クインシー・ジョーンズが以前、シナトラをプロデュースし、アルバムのレコーディングについて書き綴っている：

彼は午後２時にやって来たんだが、リハーサルは２時間もかからなかったよ、キーや演出を変えて１０曲ぶんもあるというのにね...フランクは１テイクだけ、それでオシマイ。バンドがまだ仕上っていなかった時、彼はバンドを放置して出て行ったよ...彼は７時に戻って来て、なんとアンタ、８時２０分にはみんな家路についたんだ。製作に３ヶ月も掛けるなんて無意味なんだよ。

U2のボノも昔からシナトラのそんな姿勢を尊敬している：

勝負は一瞬で決まるということ、キャンバスはまっさらだということ、手を加えすぎないこと、これが本質なんだよ。アルバムを作るのに私とバンド連中が費やす時間について、シナトラだったらどう思うだろうかと考えるよ、ディレクターやプロデューサーに対して、まぁ実際は誰に対してであろうとそうだったんだけど、シナトラは気が短くて良く口論していたというのはみんなよく知っているからね。私は彼のやり方は正しいと確信してる。収録の一瞬に全てを注ぎ込む事で、レコードは永遠のものになるんだ。

シナトラの一発録りというスタイルが、今や古典とも言うべき作品群を産み出した。アクセルの優柔不断はゴミの山を産み出した。この点に、我々が学び取れる何かがある。意味の無い粗捜しという罠にはまるのは容易い。そんなことをするかわりに、今やっている事の本質に焦点を絞ることだ。収録し、けりを付け、発表することだ。（作っているものが、リリース後にさらなる改善作業を要するようなものである場合、今述べたような事は一層真実味をおびてくる）

[37signals] パクリはするべきでない

(原文: Why you shouldn't copy us or anyone else)

今日 OnStartups.com で議論を呼んだ記事が Why Your Startup Shouldn’t Copy 37signals or Fog Creek （スタートアップ企業が37signalsやFog Creekのパクリをすべきでない理由）だ。

その通りだと思う。Joel Spolskyも同意してくれるに違いない。Hacker News のコメントもこの記事に注目しているようだ。

パクリには問題がある。理解するというステップをすっとばしてしまうのだ。理解は成長の源だ。何故上手く行くのか、何故そうなっているのかを理解する必要があるのだ。パクリではこれが身に付かない。水面下に潜むものを理解せずに、上っ面を再利用しているにすぎない。

記事ではアイディアやビジネスモデルについての言及となっているが、ユーザインタフェースデザインの方が人々にとってさらに関連の深い事例になると思う。諸君は、明らかにパクリなユーザインタフェースを目にした事が無いだろうか？ パクったユーザインタフェースは往々にして深みや細部へのこだわりを欠いている。スペースの取り方・表示比率・オブジェクトやボタンやリンクと色の関連付けといったものを欠いているのだ。見た目については大抵の場合はかなりそっくりなのだが、何かしっくりこないものがある。

何故だろう？ 作るよりはパクった方が簡単じゃね？ 他の人がもう作ってくれてるんだよ、そうだろ？ 問題は、オリジナルの作成時に行われた作業というものが我々の目には見えないという点にある。パクった者は、何がオリジナルの見た目やフィーリングや読みやすさというものを成り立たせているかを知らない。パクったユーザインタフェースはフォーフィニッシュ（訳注: 人造の大理石や木材により、本物そっくりの模様を描く方法）なのだ。

パクったユーザインタフェースに手を加えるうちにすぐ崩壊し始めてしまうというのは、こういった理由があるのだ。オリジナルにおける作業意図を理解していないが故に、パクった者は次にどこに手をつけるべきかを理解し得ない。オリジナル制作者が打つ手を知らないので、次に打つべき手を知り得ないのだ。

あからさまに他人のUIをパクったUIをよく見れば、そこに一貫性の無い部分やイタい部分を多く見出すことだろう。それが追加部分だ。

ユーザインタフェースを例として用いてきたが、元記事ではビジネスモデルについてより深く論じている。その場合も同様に、パクリは理解の欠如を招くと私は思う。多くのものを見聞し・考え・理解する事で感化されるのが良い。パクリは何ももたらさない。

結論は「パクリは諸君を駄目にする」ということだ。良いものを作るのに必要な何かを取り逃がしてしまうのだ。パクるのではなく、さまざまな視野や考え方に触れるよう努めること。それが何であれ、自分の目で見出した有用なもののみを取り込み、他は放っておくこと。自分自身の考えとのギャップはきちんと埋めておくこと。それが結局は、自分自身のやり方で前進することにつながるのだ。

[37signals] クラス 対 モジュール

(原文: Models vs. Modules)

アプリケーションが生き物のように成長していくにつれて、機能というものは汚れた斜面を転げ落ちる雪だるまのように膨れあがる。開発を進める際のちょっとした気遣いを忘れさえしなければ、これは良い事（実際、この雪だるまというやつは人の手であちらこちらへと方向を変えられるのを喜ぶものだからね）なのだが、時として膨張をストップし・考え直し・若干のリファクタリングを行う必要が出てくる。当社の製品全般に関してもそうだった（それこそ何度もね）

つい最近のことなんだが、人物のアバターと企業のロゴに関わるBasecamp のコードについてクリーンナップおよび最適化に取り組んでいた。この進化する雪だるま（少なくともアバター機能に関してはそんな感じだった）は以下のような経緯で大きくなった

• 当初、人物のアバターは無かった
• 後日、その機能を追加した。Person クラスに avatar?・avatar_path・attach_avatar といったようなメソッドを追加する事でアバター機能を提示するというものだった。最終的に７つ程の追加メソッドがPerson クラスに追加された。
• その後、David が来て、こういった新しいメソッドを Person クラスから抜き出してモジュールにまとめた。彼は実にいい仕事してくれた。というのも、本来の Person クラス定義を Avatar 機能で汚さずに済むようになったし、Avatar 関連のコードも分離出来たからだ。

こういった経緯で今日までやってきた。メソッドはモジュールに移し、機能が必要になった時はベースクラスにモジュールをインクルードするだけで済むようにするというパターンに従って来たので、コードは今でも実にクリーンかつ包括的だ。

とは言うものの、このアプローチには２つ問題がある。第１に、クラスに多くのモジュールをインクルード（我々のうちにもそうしているのが数人いる）すると、個々のメソッドがどのモジュールで定義されているかを調べるのが困難になり、あげくの果てにはどのメソッドが定義済なのかを調べることすら困難になる。メソッド定義部分を探す際に混乱を招くし（さらに悪い事に）同一名称のメソッドを二重あるいはそれ以上に重複定義出来てしまうので、これはよろしくない。複数モジュールをインクルードする際に、同一名称のメソッドがあっても警告は出ないので、あるメソッドを同一名称を持つ他のメソッドで上書きすることでバグが発生、といったことが容易く起こる。名前の衝突を避ける為に、メソッドの名前空間を重複（Avatar モジュールのメソッド名には avatar_ と接頭辞を付けるといったような）しなければならなくなるというハメに陥るのだ。

（誤解無きよう。モジュールは素晴らしい。私たちは山のようにモジュールを使っているし、愛着もある。ここでは、モジュールにも弱点はあるのだということを知る手助けになれば、という観点から論じている）

モジュールによるアプローチでは更に厄介な事がある。違う種類のアバター（個人のアバターに対する、グループのアバターとか企業のアバターが例としてあげられる）が出てきたとしたらどうする？ Ruby ではモジュールからサブクラスを派生させる事は出来ないので別の手（モジュールにモジュールをインクルードするといったような）を捜し出さねばならなくなるのがオチだ。それに、異なるアバターをそれぞれ異なるエンティティ（実体）として参照する手段が存在しないので、代替手段として、アバターを取り扱うコントローラはアバターが所属するエンティティを取り扱う形にする必要がある。

こういった問題について打つ手はあるのか？ 結局のところ、アバターは人に関する属性定義表である Person クラスの一部分であることを免れ得ない。どうにかしてアバター関連のコードを分離することが出来ないか？

出来る。Avatarを独自のクラスにし（モジュールのインクルードやクラス継承によってでなく）ActiveRecordのアグリゲーションによってPersonクラスに取り込む。例を挙げよう。

class Avatar
  attr_reader :master

  def initialize(master)
    @master = master
  end

  def exists?
    master.has_avatar?
  end

  def create(file)
    master.update_attribute :has_avatar, true
    # thumbnail and install the given avatar
  end

  def destroy
    master.update_attribute :has_avatar, false
    # delete avatar file
  end

  # etc.
end

class Person < ActiveRecord::Base
  # ...

  def avatar
    @avatar ||= Avatar.new(self)
  end
end

こうすることで得られる利点は何か？ 私見ではあるがいくつか挙げてみよう:

• "person.avatar.exists?" や "person.avatar.create(io)" といった書き方が出来るようになる
• 異なる種類のアバターをサポートするために Avatar クラスを継承・拡張出来る
• Person クラスから独立した形で Avatar クラスのテストが行える
• Avatar クラスのメソッドが Person クラスのメソッドを隠蔽することについて気にかけずに済む
• "person.avatar.destroy" という記述において、"destroy" メソッドの定義がどこにあるかがより明確になる

さらに言うならば、avatar そのものについても person から分離・移転することが可能だ。

class AvatarsController < ApplicationController
  before_filter :find_avatar

  def create
    @avatar.create(params[:avatar])
  end

  def destroy
    @avatar.destroy
  end

  protected

    def find_avatar
      person = Person.find(params[:id])
      @avatar = person.avatar
    end
end

モジュールの利用を止めてこのパターンを絶対に使えと勧めるつもりはない。上で述べたように、モジュールは実に手軽であり、私達もあいかわらず広範にわたって利用している。だがもし諸君がある特定の事例においてモジュールの持つ制限事項にぶち当たっていると気付いた場合は、問題になっているモジュールをクラスに抜き出すと、事が実に有利に運ぶということもあるのだ。

---

訳者コメント:
model == class として訳出しています。文脈から見て model == data model であり、結局のところ class Person(models.Model): なのだから意味は通ると思われましたし、「ベースモデル」「派生モデル」で通じるのか？という疑問もありまして。

Ruby のモジュールに関しては、インスタンス化しなくても使えるメソッドという点から、Python の import みたいなもんかという程度の理解しかしていなかったのですが、こういったクラス継承におけるセマンティクスとファンクションの不整合を解決する際に有効なのだなと、Ruby素人である私は認識しました。

ちなみに私は「アバター」という表記に抵抗を感じる者の一人であります。「アバタールだろ！」派であります。MOOGはいまだに「ムーグ」と読んでおり、年がばれるというものです。今回は変節してアバターとしましたが、これではバカタール師に顔向けが出来ません。イエスの事を知らぬと言ったペテロの悔悟を身にしみて感じる私でありましたw

[37signals] 「失敗から学べ」は過大評価されている

(原文: Learning from failure is overrated)

「失敗から学べ」と耳にタコが出来る程聞かされてきたことだろう。「失敗するなら早いうちが良い、どんどん失敗しろ」かもしれない。失敗に関しては、人口に膾炙した引用が沢山ある。その大半は、賢さを感じさせるちょっとしたひねりがオチになっており、それがその引用をいかにも名言だと思わせる。だよね？

私にとって理解し難いのは、失敗こそが人々の学ぶべき大いなる教訓の源になっている、という考え方がみんなの心を捉えているという点だ。失敗から何かを学びとることが出来た、なんていう前例が諸君にあるか？ 失敗から学んだのは何が上手く行かなかったかということだけだ。これでもう再度同じ間違いを犯すことはないのだが、今度は前回と違う間違いを前回と同様に犯す。せめて何が上手く行かないかを知ることが出来ればよいものを、相変わらず何が上手く行くかについてはさっぱりだ。これでは教訓と呼ぶに値しない。

そこで、こういうのはどうだろう。失敗から学ぶ代わりに、成功事例を検証することに力の大半を注ぎ込むのだ。正しかったのは何か？ 上手くいったのは何か？ 上手くいった理由は？ 今後も上手くやるには？ 重箱の隅を突つくより、良いものをより良くすることに目を向けたらどうだ？ いつまで俯いてるんだ。もっと胸を張れよ。

「次もこれでいける」というのと「これはもう２度とやらん」というのでは、月とスッポンの差がある。前者の方が後者より良いのだ。

確かに「山川草木、是我師也」ではある。良きにつけ悪しきにつけ、そこから学べる事はある。だが、学ぶ事全てが等しく価値を持つというわけではない。過ぎた事について考えを巡らせる際は、失ったものではなく得たものに焦点を当てよ、というのが私の見出した真実だ。成功から得られる教訓は、成功を今後の成功へと繋げる、より良いチャンスをもたらしてくれる。

[37signals] 刃を研ぐことを忘れずに

(原文: Remember the strop)

昨夜、彫刻の時間を設けた。去年の１０月からこのかた、彫刻に時間を割く機会に乏しく、手を付けられず終いだった。彫刻とは自分の手・数本の鑿・角材さえあれば取り組むことが出来る、究極の瞑想法だ。

良い道具は間違いなく作業の助けになるということで、私は奮発して何本か丸鑿を入手した。素晴らしい切れ味で、手に持ったときのバランスも良く、長時間にわたって鑿を振るっていても快適だ。「素晴らしい切れ味」の刃先がおそらく最も重要なのだというのは言を待たないことだが、良く切れる刃先が木を易々と彫り進む様は目を瞠るものがある。わずかな力を加えるだけで鑿は静かにシャッシャッと木の削れる音を立て、刃先からくるくると巻き出る削り屑は死んだフリをした団子虫のようだ。

それでも時折、木目が詰まっていたり均質性に欠けたりして堅くなった部分にぶち当たることがある。木目に逆らって彫る必要が生じる事もあり、その際は少しばかり余計に力を（大した力では無いが）入れて鑿を突く必要がある。少し余計に力を入れると、刃先は滑らかな動きとともに以前と同様の魔法のような切れ味を見せてくれる。突・彫・突・彫・突・彫・・・まるで催眠術の世界。まさに瞑想の境地だ。

私はほとんど無意識のうちに木目の方向や密度の変化に順応しているので、研いだ直後の鑿がいかに素晴らしい切れ味で木を彫り進んでいたかを容易く忘れてしまう。私は「まだかなり良く切れるから、あと数分粘って、それから研ごう」と自分が思っている事に気が付いた。いつも、あと数分粘ってから、なのだ。あともうひと彫りだけ。この部分を彫り終えなきゃ...

私はそれからようやく座り込んで刃先を革砥に当てるが、研ぎ上げるには数回当てるだけで良い。作業中断時間は、皮砥に４・５回当てるのに要する約３０秒程度だ。だが、この僅かな作業中断がもたらす切れ味の変化たるや吃驚仰天である。こんな風に皮砥に４・５回当てるだけで刃先は元の切れ味を取り戻し、いつもながら私は、研ぐ前に比べて彫り進めるのが容易くなったことに吃驚仰天する。まだ良く切れると思い込んでいたこの私がだ。もとの切れ味も、研ぐとどれだけ切れ味が良くなるかもすっかり忘れていたのだ。

さて、４年前に遡ってみよう。４年前（ほぼ丁度４年前なんだな！実際は２００５年の１月２７日のことだからね）Jason と David が、Basecamp の製作を行っているシアトルの社屋に来ないかと私を誘った。当時、私は BYU に勤務していたのだが、Jason と David は私にとってより良い道を提示すべく尽力してくれた。

BYU は居心地の良い所だった。職責もあった。技術上の決断事項についても参画していた。私は有能だった。出世と言う木の根を延ばしていくにあたって、さしたる障害もなかった。そう考えていたのだ。

にもかかわらずその時、私は Basecamp の製作に参加した。Jason と David が Getting Real について語るのを部屋で聴いたのは、比較的短い、僅か数時間のことだった。彼らがそこで私に話さなければならなかった事というのは、これまで Basecamp の製作や Getting Real のワークショップに参加したものならば誰でも確信出来そうなシンプルな事だった。私にとってこれは革砥に刃先を数回当てることに等しかった。私の一側面の切れ味は増し、リニューアルされた。私は単にプログラマとして出世するだけでは物足りなかった。私は、私がもともと抱いていたソフトウェアを書く情熱と喜びを思い出したのだ。

（BYU を辞して 37signals で働き始めたのは僅か１ヶ月後の事だ）

こういった概念は別に目新しいものではない（Stephen Covey はこれを、著書の Seven Habits で「のこぎりを良く切れるようにしておくこと」と呼んでいる）しかし、これは今も金言である。刃先が真新しい時にもたらしてくれたわくわく感を忘れ、人生や出世において波風を立てることに抵抗を感じるようになると、私たちは往々にして轍にはまることになる。費やすのは、目先の事から離れて刃を研ぐことを思い出すのに必要な、わずかな時間だけだ。そしてその費やした時間はそれ以上の長きにわたって見返りをもたらしてくれる。

---

訳者コメント:
Stephen Covey についてはトンデモという説もありますが、その言は７つの習慣に見られる通り至極真当なもので「鰻と梅干のシナジー」とか言ったアホな応用をしない限り、多方面にわたって有用かと存じます。まぁ占いと同じで「当り障りの無い事を言ってるだけ」と言えない事もないですし「銀の弾丸なんて無ぇんだよ！」を信条とする者にとりましては７つの習慣（笑）でしかないわけですが。

1. Be Proactive!（主体的になれ）
2. Begin with the End In Mind!（ゴールを明確に）
3. Put First Things First!（優先順位をつけろ）
4. Think Win/Win（Win-Winであれ）
5. Seek First to Understand, Then to be Understood.（まず相手を理解せよ。話はそれからだ）
6. Synergize（相乗効果）
7. Sharpen the saw（研ぎ澄ませ）