[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（研ぎ澄ませ）