[37signals] 世間が真っ直ぐに進むとき、TBSはその斜め上を行く

（原文: TBS zags when everyone else zigs）

時として、しきたりというものは単なる惰性である。みんながそうしているからというだけの理由で同様に処理されているだけなのだ。だからこそ「木目に逆らって」進む事でビジネスチャンスが産まれる。

TBS が番組の「集積物」（これについては、こちらの記事で言及されている）をうまく利用している、というのが良い例だ。何百ものケーブル放送チャンネルの中から TBS を突出させているのは、同じ番組をブロック単位で放送するというこのやり方なのだ。

例えば、TBS は月曜日の８時から１１時までのプライムタイム３時間ぶんを「ファミリー・ガイ」６話分の再放送で埋めている。火曜日は同じパターンを「ジ・オフィス」でやる。水曜日は、黒人に幅広い支持層を持つタイラー・ペリーの制作する３時間のオリジナルコメディ「タイラー・ペリー・ナイト」だ。

「私達はテレビのしきたりからちょっと飛び出してみたのさ」とクーニン氏は語る。「私達は水平思考の番組作り、つまりたれ流しを目的とした番組作りはしない。私達は番組の集積という垂直思考のもとで番組を作っているんだ」

賢いやり方だ。誰もが身に覚えのある事だろうが「ファミリー・ガイ」「マッド・メン」「ロスト」等の DVD を手に腰をおろし、 複数のエピソードをぶっ続けで見るのは、本放送とはまたひと味違う視聴体験が得られるものなのだ。「２４」の新シーズンの DVD が出ると週末に全然顔を出さなくなるヤツがいるというのは良くある話だ。

というわけで、他のネットワーク各社が「正しい」番組制作手法にとらわれている一方で、TBSはしきたりを破り、従来とは異なる視聴者層に食指を伸ばしたのだ。みんなと違う方向へ進む、の良い例だ。このやり方は上手くいっている。TBS は 18〜34歳の視聴者の間でナンバーワンのケーブルチャンネルなのだ。

[DARING FIREBALL] 偉いさんの戦争

（原文: Generals’ War）

先週の、エスカレートしつつある Apple - Google 間の争いに関する記事において、私はいくつかの微妙な点について言及するのを忘れていた。

ひとつは、私が議論しているのはあからさまな敵意についてであり、単なる競争についてではないということだ。Google と Apple は、特に Android 対 iPhone という観点から見て、そしてもうじきやってくる Chrome OS 対 iPad という観点から見て、ライバル同士なのか？という疑問があるということについてはこれまでも見てきたとおりだ。もちろん彼らは競合している。それは良いことであり、資本主義社会における企業の一般的なあり方である。私の言いたいのは、そういった競合とは違う何か、もっと悪意に満ちた何かが進行していると言うことなのだ。あからさまな敵意。「ライバル」と「敵対者」の違いだ。

もうひとつ、私が言及を怠っていたのは、これは重要だと私は思っているんだが、この事態は全て経営陣および管理職上層部レベルにおいてのみ発生しているという点だ。技術者たち（両社の）は戦の準備をしているわけでもないし戦を楽しんでいるわけでもない。私には情報提供者が両社に居て（Google より Apple の方が多く、当然のことながら、他社はさておき Apple のこととなると Google の方が多くなる）、そのほぼ全てが技術者であり非「経営陣」なんだが、状況を考察するにあたって「異様」という言葉がずっと私の頭に浮かび続けている。Apple で行われ Google が出席する会議、もしくはその逆、において経営者達が「喧嘩上等」という敵意と怒りに満ちた発言をするという異様な状況のことだ。

あからさまな敵意というのは両社の技術者においてはあてはまらない。これはあくまでも異様なのだ。両社には確固たる、そして明白な文化の違いというものがある。Apple の技術者達は Google の作るソフトウェは醜い（役に立つし、きちんとしてるんだが醜い）と考える傾向があるし、Google の「オマエのデータを全部よこせ」的戦略に疑念を抱いている。Google の技術者達は Apple はウェブを理解してない、少なくともウェブをプラットフォームと捉えていないと見なしており、そんなのは古いと考え、そして App Store における Apple の専制的な管理体制に腹を立てている。だが全般的に見れば、両社の技術者達は似たり寄ったりなのだ。Google のサービスを利用している Apple の技術者も、Apple のコンピュータを使う Google の技術者も大勢いる。

両社ともに、例の Microsoft 的な「全世界がオレの敵」という姿勢、すなわち手をつけたからには単に成功を収めるだけではなく競争そのものを根絶するまでとことんやるというあの姿勢を社風として培ってはいない。

これは偉いさんの戦争でしかないのだ。Apple と Google の一般社員は戦争を期待してなどいないし、予期すらしていない。

一方、Google は Apple ほど一枚岩な会社ではない。１月の iPad 発表の数日後に Apple で行われた「タウンホール」ミーティングで Steve Jobs が Google を視野に入れて発したコメントは多くの注目を集めることになった。John C. Abell が Wired でレポートした、又聞きに基づく言い換えなんかは特にそうだった。Abell がレポートし、他の情報路の大半が取り上げたものではこうなっていた：

Google について： 我々は検索事業に参入しなかった、と Jobs は語った。奴らは電話事業に参入した。勘違いするな、奴らは iPhone を潰したがっているのだ。そうはさせん、と彼は語る。

私が Wired にリンクを張った後、タウンホールミーティングに出席していたとある情報提供者が私にこう語った：

彼が実際に言ったのは「Google のチームが我々を潰そうとしている」だった。企業全体がそうなのだと思わせるような言い方を彼は決してしていない。おおかた Android チーム限定だろう。

先週の記事の後、Apple にいる情報提供者が私にメールを寄越して、タウンホールミーティングにおける Jobs の発言は、Google には iPhone を潰そうとしている「とあるチーム」が存在するということを誇張して言っただけのことであり、Google 全体のことを言ったわけじゃないと何度も繰り返して語った。そうなのだ、Jobs はこの件についてムカついているように見えるが、その矛先は Google 全体ではなくむしろ Android という特定のターゲットに向いているというのは明白なのだ。

まぁ、そういった発言自体が事態を醜悪なものにしているのかもしれんが。

---

訳者コメント： この記事のすぐ後に、Jobs と Schmidt が仲良く（？）コーヒーを飲んでいるツーショットを載せた GIZMODO の記事を取り上げて "How about that." と言うあたり、ぬかりないですなぁホント。まぁ「火事と喧嘩は IT の華」ですし「火のないところに煙を立てる」のは、メディアが紙であれビットであれ、あらゆるマスゴミの得意とするところであり飯のタネですから、しょうがないっちゃしょうがないんですけどね。

[37signals] 「〜の場合を考えてみろよ」には気をつけよう

（原文: Beware of "Imagine if..."）

我々はユーザ管理画面の設計を要件として含む幾つかの新しい案件に取り組んでいる。目下、ちょっとした研究開発プロジェクトが進行中といったところなんだが、さほど現実離れした代物でもない。

我々は UI を設計し、その見栄えと動作は好ましいものであったが、その時点で、我々は疑念を持ち始めた。こんなのが存在する理由は？こいつをこう動かす理由は？そうするよう誰かさんが望み欲する理由は？

ある特定のUI構成要素（こいつはデザインのキモだった）について疑念を持った時にその理由がわかった。「誰かがそう望んだ場合のことを考えてみろよ」というのがこいつを取り除く障害になっていたのだ。危険を知らせる赤旗は、この時すでに上がっていたわけだ。

「〜の場合を考えてみろよ」というのはいつだって危険信号だ。想像はその正しさを証明してくれるものなんかじゃないなどと言うつもりはない。いったんペースを落とし、距離をおいて考え、現実に立ち返れ、今すぐに、と言いたいのだ。

どんなシナリオだって想像の上では成り立つ。考えようとすればどんな突飛なユースケースだって考えつく。でも、それは大多数の人々が「本当に」必要とするものなのか？そのフィーチャーを支えているのは堅固な基盤か、それともふわふわ浮かぶおとぎの国か？

こうした障害物にぶつかった場合、我々は大概「やめとこう」という決定で終わる。もしそれが現実の問題になったとしても、そのフィーチャーは後で追加出来るんだし、その時が来るまでは、我々は想像を弄んでいるに過ぎないということになるからね。取っ掛かりの時点では少しでも身軽にしといた方が良い。本当に必要なものだったら、後々湧いて出てくるものだよ。

---

訳者コメント：
いわゆる feature creep ですな。気を利かすというのも善し悪しで、そのお陰でてんこもりになった実装アイテムリストを前にして途方に暮れるというのはよくある話です。書かんでも良い UML 書いたりとかね。

JavaScript が Java や c++ に比べて書きやすいというのは、Java や c++ がクラス設計という「気を利かす」フェーズを重視せざるを得ないのに対し、JavaScript は後付でインスタンスなり prototype なりをにょきにょきと伸ばしていけるという点が理由の一つとしてあるのでしょう。完先の Java、アリアリの JavaScript といったところでしょうか。実際に必要になるまでは手を付けるなというルールは作業量削減の第一歩ですからね。

[37signals] アイディアを出すだけの奴なんていらない

（原文: There's no room for The Idea Guy）

スタートアップ企業に必要なのは有能で、現実の仕事をこなす意欲を持った人間だ。必要なのはプログラマ・デザイナであり、そのうちマーケティング・サポート業務といった人たちも必要になる。とはいえ不要な人間も居るわけで、それは、単なるアイディアマンになってしまいそうな奴らだ。

どんな奴らかは諸君も先刻承知であろう。「こいつはFacebookとFlickrをかけ合わせたようなものになるわけだけど『犬用』ってのがひと味違うんだ！ ネット上にいる犬好きどもの市場のたった１％でも得られさえすりゃ、俺たちウハウハだぜ！」といった口上をまくしたてる奴らだ。アイディアが全てで、たいがいは一文無しで、自分のしょーもないアイディアをカタチにして起業するための実務的技能をほとんど持ち合わせていない奴らだ。

明らかなことだし実際そうなんだが、アイディアマンに堕するのは容易い。彼は諸君にはした金程度もしくはタダで働いてくれと要求するくせに、その見返りと来たら彼の取り分より少ないというのがとどのつまりだ。こんなひどい話はめったにないことではあるけど、それでも彼等の大いなるエネルギーと大いなる夢は、ヤバイくらいに諸君を魅了するものたりえるのだ。うん、私も一度ならずハマった。

実際のところ、大概の人は多くのアイディアを持っているものであり、それは素晴らしいビジネスへとつながりうるものだ。なのに現実にそうならないのは何故かと言うと、それがアイディアどまりで適切な実務がなされていないからである。すなわち何が何でも為すべきことを為すという姿勢が無いからであり、適切なタイミングで事を起こしていないからなのだが、こういったことは前もって予想するなんてことがまず出来ないことである。非の打ち所の無いアイディアなどというものに大した価値はない、というのが本当のところなのだ。

壮大なアイディアやあふれんばかりの熱意なんてものは無用だと言いたいわけじゃない。もし諸君がそういう輩だったとしたら、諸君は既に素晴らしいスタートを切っているんだと言いたいのだ。さっさと実務スキルを持った人間を引っ張り込み、諸君の御大層なアイディアをカタチにする助けとせよ、というわけだ。

---

訳者コメント：
もし先日頂いたタレコミが本当だとすれば、例の本の関係者の中に、まさにここに書かれているような人物が居るということですな。早川さんに限ってそんなことは有りえないと信じたいんですけどね。そんなことしたら岩波さんにもフネっちにも絶交されるでしょうし。

（2010/03/04 追記）うわぁ、すみません。とんだ言いがかりでした。どうぞお許しくださいー！

[37sugnals] 見積りとは約束ではなく推測なのである

（原文: It's not a promise, it's a guess）

「いつカタが付くんだ？」というのは理に適った問いであり、我々ソフトウェア開発者としては、経験と分析に基づいた最良の答えをひねり出すよう努めるべきだ。だが、人々にその答えを厳正なる約束とみなされるのは避けるべきだ。

諸君が見積もりというものを推測ではなく約束だとみなしてしまうと、諸君は自らをその仕事に縛り付けることになる。もし諸君が締め切りを守れなかった場合、諸君は落伍者となる。誰も落伍者などにはなりたくないからそれを避けるため、徹夜仕事といったリスキーな行動に走るのもやむをえないと考えるようになったり、ボロボロもしくはきちんとテストしていない粗悪なコードをリポジトリにチェックインするといった行動をとるようになってしまう。

一度や二度ならば、がむしゃらに頑張って見積書に書いた約束を守るという事も出来ようが、結局のところ長続きしない。ソフトウェア開発と言うものは本質的に予測不可能なものなのだ。あまりにも多変量的であり、氷山の一角しか見えないものなのだ。

だが、もし諸君が見積もりというものを「仕事に取り掛かる前に知り得た限られた情報をもとにした最良の推測」と考えることが出来れば、諸君は組織変更によって事に対処したり、締切という苦役の輪廻を打破することが出来るようになる。作業は共同作業となり、新たなる発見についても関係者間で情報共有出来るようになる。

新規に設計されたフィーチャーがあって、盛り込むにはある種の根本的なインフラ変更が必要で、そのためには見積もりでは一日で済んでいたものに更に二日を要すると後に判明したら諸君はどうする？ 多分、考えるまでもないことなのだ。関係者にこう聞けば良い、一日で済むはずが三日になるけどそれでもそのフィーチャーにこだわりたいの？と。インフラ変更なしで済むように単純化する方法はないもんかね？と聞くという手もある。

これこそが見積もりというものの持つ真の価値である。すなわち、妥協点を探るための対話の場を設けざるをえないという状況を作り出してくれるのだ。自縄自縛するためのものではない。

---

訳者コメント： DHH の徹夜嫌いは筋金入りなようで、過去にも関連記事として
[37signals] これは問題だと認めることから始めよう
というのがあったりする。仕事中毒が結局はリスクとなるというのは誰もが認めるところだけど「誰も落伍者になどなりたくない」という DHH の言葉通り、開発者の大半はボロボロになりながらも歯を食いしばって前進（足踏み？）する。このマゾ的輪廻を断ち切るのに私は１８年を要した。我ながら頭悪過ぎである。

[37signals] 迷いを感じてもタイムボックスの時間枠内で済ませよう

（原文: When in doubt, timebox it.）

新プロジェクトに取り組んだ際、そのプロジェクトで利用したいプラグインに互換性問題が出てきた。世間で良く知られている解決法はあったし、どうしてもそのプラグインでなければならないというわけではなかったが、多少の追加作業でそのプラグインを動かせるようならば、そのプラグインを使うことには相応の価値があった。イテレーション形の新しい勤務形態になったので我々に与えられた時間は限られており、時間が逼迫しているというプレッシャーを感じてはいるが、実はきちんとした判断を下せるだけの情報はまだない。

ここで即断するよりも、あと３０分だけ時間をかけてこのプラグインを動かすことが可能かどうか見極めたいと Jeff は判断した。３０分で互換性問題が解決出来れば、それは素晴らしき勝利であり、我々が利用したいプラグインを使い続けることが出来る。ぶっちゃけ、良く知られた解決法という保険もあった。たとえプラグインに関する問題が解決出来なかったとしても、たかだか３０分を無駄にするだけのことであり、修正可能かどうかを見極めるためにちょっとだけ時間を割くというのは充分な価値がある。

---

訳者コメント：
５年くらい前になるのだろうか。アジャイル開発が現在のように地に足の着いた開発手法として成熟・定着する以前、アジャイルがあたかも銀の弾丸のようにもてはやされていた頃に耳にしたのがタイムボックスという考え方だった。

要は、仕事に時間を合わせるのではなく、タイムボックスと言う時間枠を設けて、時間に仕事を合わせるという考え方なのだが、当時アホほど残業・休日出勤（それも管理職扱いでｗ）せざるを得なかった私にとっては「馬鹿言ってんじゃねーよ」以外の何ものでもなかった。

IT小作から足を洗って一年ほど経った今、ようやくタイムボックスという考え方が理解出来るようになった。ごめんなさい。私がアホでした。

[37signals] 「２０１０年は製品作りの年」そして「新しい勤務形態」

（原文: 2010: The year of the products + a new way of working）

２０１０年は製品作りの年

37signals にとって２００９年は明らかにインフラ整備の年だった。我々は舞台裏で、ハードウェア・ソフトウェア・セキュリティ機構の改善に多大な作業を注ぎ込んだ。これまでで最大のインフラ整備プロジェクトである 37signals ID も始動した。これは、大計画のうちの最低一つはものにしたというだけのことであり、インフラ整備は決して完了したわけではないのだが、２００９年はインフラ整備の最前線における大いなる進展の年となった。

２０１０年は製品作りの年になるだろう。いくつかある大規模なインフラ整備プロジェクトを裏でこなしつつ、我々はエネルギーを製品改善へとさらに集中することが出来る。我々には新機能・機能統合・UI 設計／再設計・通常業務フローの簡素化に関する素晴らしいアイディアがすでにいくつかある。新製品に関するアイディアもいくつかあり、それに関する調査を進めることにも支障はなくなった。

新しい勤務形態

製品作りにおけるルネサンスの核心とも言えるのが新しい勤務形態だ。過去に於いて、37signals の各員はかなりバラバラ状態だった。みなが自分自身のプロジェクトにかなりの時間を割いていた。いくつかの点に於いて業務の重複がみられ、時には小さなチームとして共同して大物に取り組むこともあったが、業務の大半は自分自身のために時間が割かれていた。

我々にはまた、ちぐはぐな業務指示により人を朝令暮改状態に引きずり込むという傾向があった。ある人に作業Ａを依頼した数日後に作業Bへの協力を依頼したり、その後またCというバグの修正を依頼するといった具合だ。これでは集中出来ない。

２０１０年はこの現状を変えるつもりだ。こんな感じで：

チーム

我々はチーム形式での勤務を開始する予定だ。

チームはデザイナー１名とプログラマー２名の合計３名から成る。必要に応じてシスアドがアシストを行う。

開始にあたって、２つの専任チームと１つの遊撃チームを結成した。遊撃チームは他のチームを支援したり、不測不可避な事態が起きた場合には追加人員を迎えることが可能である。３月には第３専任チームの結成を見込んでいる。

我々はさらに、バグ修正と処理最適化に関して顧客サポートチームと共同作業を行う専任プログラマを１名迎える予定だ。この人物はチームの再編成（これについては後で述べる）ごとに入れ替わることになるだろう。

時間

各チームは２ヶ月間（１ターム）まとまって作業を行う。２ヶ月経過後、チームは解散し別の人員により再結成される。これにより、各人員はこれまでと違う人員と作業を行うことになる。

２ヶ月の期間内に於いて、４回のイテレーションがある。１イテレーションは２週間となる。１イテレーション期間内は、一つのフィーチャーに取り組んだり、小規模フィーチャーをいくつか並行して取り組んだり、完成に数イテレーションを要する大規模フィーチャーの一部として取り組むことが可能である。

各チームは１イテレーション期間を通じ、同一製品について作業することが求められる。よって、チームAが１イテレーション期間を Basecamp に関する作業に従事するよう選択した場合、その２週間は Basecamp に専念することになる。２つのチームが同じ製品に同時に従事することは不可とされている。

もし２週間で作業が完了しなかった場合、そのネタはボツとなる。そういったネタは、別のチームが今後のイテレーションのネタとして拾い上げるか、さもなくばそのまま死に絶えることになる。これにより、１イテレーションの完了にあたって何か新たな売りになるものが出来たかどうか確認するよう、チームが促されることになる。年間を通じて２週間に一度、何か新しいものを顧客に売り込めるようにするというのが目的なのだ。

プロジェクト

チームは、彼ら自身のプロジェクトや我々が常にメッセンジャーで発信している現行プロジェクトのリストに載っているプロジェクトに取り組むことが可能だ。そういったリストを我々は Backpack で保守している。リスト内のアイテムは顧客要求に基づくものもあれば我々自身から出たアイディアだったりもする。プロジェクトには「Highrise のカスタムフィールド」といった未完のアイディアどまりのものもあれば、すぐに実装が始められそうな基本 UI まで揃っていて構想が具体化されているプロジェクトもある。我々は Backpack のコメント機能を使ってアイディアをめぐる議論を行い、リスト内のアイテムにファイルを添付するようにしている。

プロジェクトには一回の施行に付き１イテレーション期間が選ばれる。その選択はイテレーション期間の初日に行われる。イテレーション期間終了後、チームは次のイテレーションで従事するプロジェクトを選ぶことになる。２ヶ月のタームが終了すると一旦チームは解散・再編成され次のイテレーション期間で従事するプロジェクトを選択することになる。あとは繰り返しだ。

プロジェクト管理は Basecamp で行われる。１チームあたり１プロジェクトの割り振りにした。１イテレーション期間ごとにTO DOリストとマイルストーンが設けられる。各チームが考慮すべきは現行イテレーションについてのみなので、よって１イテレーションが終了し次のプロジェクトを選ぶ段になったら、チームは新たにTO DOリストとマイルストーンを作製することになる。２ヶ月タームの終には Basecamp 単体プロジェクトチーム用のイテレーションが全て出揃うことになるだろう。

実験

この勤務方式がどの程度うまく行くか、我々はわくわくしながら結果確認の日を待っている。我々は今まさに最初のイテレーション期間の１週目にあるが、喜ばしい現状を目にしている。アルファチームは Highrise に関する一連の改善に従事する一方で、ブラボーチームは全く新しいプロジェクトに取り組んでいる。遊撃チームは、あるものは Highrise に、またあるものは 37signals ID Launchpad にといった感じで色々なことに取り組んでおり、また Basecamp と Campfire 向けの新しいネタの幾つかについて考えを巡らしている。

何タームか経過した暁にはまた状況を報告したい。では２０１０年も諸君に成功のもたらされんことを。

（以上のアイディアは Meetup の Scott Heiferman によりインスパイアされたものである）

[37signals] "It Might Get Loud" と、なりたく「ない」自分を知ることの重要性について

（原文: "It Might Get Loud" and the importance of knowing what you don't want to be）

Getting Real 所収の "Have an Enemy"（敵を作れ）というエッセイからの引用

喧嘩を売れ
時々あることだが、諸君のアプリケーションがどうあるべきかを知る最善の方法は、それがどうあるべきで「ない」かを知ることである。諸君のアプリにとっての敵について考えることが諸君の進むべき道に光を当てることになる。

Led Zeppelinのジミー・ペイジ、U2のジ・エッジ、White Stripesのジャック・ホワイトによるジャムセッションと討論をまとめた "It Might Get Loud（音でかくならんかなぁ）" という実に良くできたドキュメンタリーを見ながら、このことを思い出していた。このドキュメンタリーでは、彼らがそれぞれのギター演奏スタイルをどう発達させてきたかが明らかにされている。


敵を作ることから始めよ
彼らがそれぞれ自分のトレードマークとなったサウンドにどうやって辿りついたのかを語り進めるにつれて明確になってきたのは、彼らはどう聞こえて欲しく「ない」かを明確にすることから始めたのだという点だ。敵を作ることから始めたのだ。

ジミー・ペイジは自分のレコードではなく他人のレコード向けに演奏するセッションミュージシャンだったが、この仕事にはうんざりしていた。全てがあまりにもガチガチで自由がなかった。テンポも厳密に決められていた。ダイナミクス（訳注: 音量の大小）も皆無だった。画一的サウンドが全てだった。音楽とは呼べないような、たどたどしいオマケ的音楽だった。

だから彼はLed Zeppelinを結成した。彼は陰と陽の両方を使えるバンドが欲しかった。曲の中盤で速度や音量を上げたり出来るようにしたかった。曲を長く引き伸ばしたかった。バイオリンの弓で弾いたりとんでもない奏法をしてみたかった。

U2結成時にジ・エッジは、当時幅をきかせていた頭でっかちで自己満足的なプログレバンドとは正反対の存在になろうとした。彼は必要最低限の演奏を目指した。力仕事（訳注: 音の厚みを出すこと）の大半はエコー・エフェクターで済ませた。出来るだけ少ない音数でコードを弾く方法を考え出した。

White Stripesは「テクノロジーは創造性の敵だ」というジャック・ホワイトの考えから生まれた。ずらっと並んだエフェクターペダル、新品のギター、何tもの機材を積んだトラックといったものを彼は使おうとしなかった。生のままな、一期一会なものを目指した。

まず最初にどんな音を出したく「ない」かを明確にした彼らはそれぞれ、独自でソウルフルなサウンドを作り出すのに成功した。進むべき道を彼らに教えたのは彼らの敵なのだ。

諸君がうんざりしているものは何か？
以上全ての話に含まれていることが、ここかしこにはびこる流行というものが如何に成立したかを思い起こさせてくれる。服装についてだけでなく、音楽やビジネスやその他ゴマンとある事柄についても言えることだ。人々はトレンディなものならばそれが何であれ群がり集まる。そしてこれは、皆が同じものを求めている場合は違った方向に向かうことが好機をもたらすということを意味する。

世間が今まさにしていることで、諸君がくだらないと思っていることは何か？諸君の携わる分野における流行で、諸君が馬鹿げていると思っていることは何か？脚光を浴びることになっても諸君の思想は変わらずにいられるか？もしそうならば始めたまえ、自分は世間と逆なのだと明白にすることを。

[37signals] 「使えない：使える」比とは何か？

（原文: What's the suckage to usage ratio?）

送料が決まらないうちは製品はまだ完成とは言えない（訳注:極端に言えばということ）。製品に万全を期すると、いつまでたっても製品が完成しないということになるだろう。幸いなことに、諸君はどちらのフィーチャーを選べばより完璧に近づけるのかを判断することが出来るし、ちょっと手を抜けるのはどっちなのかを判断することも出来る。Kindle DXがこのことに関する好例だ。Kindleで本を読みページをめくるのは素晴らしい体験をもたらしてくれる。だが一方、キーボードを使うのはしんどい。キーを押すのに苦労する。モディファイアキー（訳注:シフトキーやコントロールキーなど、他のキーと併用するキーのこと）には混乱させられる。しょっちゅう打ち間違えるし、カーソル移動はもたつくし、修正もしづらい。でも、こういった全ての問題にも関わらず、私は未だにこの電子機器が好きだ。

不具合のあるフィーチャーがあってもUX全体としてはユーザを納得させる良い方法として「使えない：使える」比がある。どんなフィーチャーであれ、それを「使えない」と槍玉に挙げることは可能だが、製品全体という観点からすれば、そのフィーチャーをどの程度頻繁に利用するかを計算に入れないことには何の意味も無い。科学的とはお世辞にも言えない表なのだが、これをご覧頂きたい



Kindleで本を読むという点については何の問題も無くて（５段階の０）、文字入力は全然使えなくて（５段階の５）、読む本の切り替えはちょっと使えない（５段階の１）だと仮定しよう。私がこの機器に費やす時間の90%がただ単に読むことだけであることを考慮すれば「使えない度」の重みは５段階のうちのわずか0.22ということになる。裏を返せば「使える度」は4.78と、ほぼ五つ星なのである。

Kindleのデザイナーにしてみれば、全てのフィーチャーを盛り込むには時間がかかりすぎるしその時間もわずかという状況下では、キーボードに関して手を抜くと言うのは合理的帰結である。キーボード入力がもっと重要になってきそうな第３世代や第４世代のKindleではキーボードの変更がなされるかもしれない。どこに重点が置かれるかはそのうち変わるものだが、今のところは公正な処置と言って良い。

製品の一部についてあえて標準的な仕様に従わないという姿勢を受け入れるのは、理屈の上では容易い。だが実際には、刀を捨てるのは辛い。改善の余地があることを知りながらそのフィーチャーを世に出そうなんて誰も思わないのだ。だからこういった状況に直面したら、完璧に仕上げることがそれに見合った価値を持つかどうかを見極めるため、方程式に利用頻度という要素を付け加えてみることだ。

[37signals] 具体例がプレゼンを作り上げる

（原文: Examples make the presentation）

ここ数年で私が知ったのは、講演や研修会では具体例を話し始めるとみんなのアンテナがピンと立つということだ。出来るだけ前置きを省略して単刀直入に具体例の話に入ると言うのが私の個人的目標になっているのだが、その理由は、そうすることでムードががらっと変わるからなのだ。具体例をおざなりにすると言うのは「出し惜しみ」というものだ。たしかに諸君の言いたいことを学説然とした形で話すことは可能だが、その学説を確かなものとして人々に印象づけるよう諸君を促してくれるのが具体例というものなのだ。具体例は諸君の言っていることが正しいかどうかを聴衆に見極めさせる。なにより良いのは、具体例と言うものが抽象的概念から混乱と色彩に満ちた現実世界へと視点を切り替えてくれる点にある。

カントの『美的判断力批判』（訳注: 『判断力批判』第一部）をアメコミの画像だけで説明しているこのワールウィンド・トーク（訳注: ワールウィンドつまり旋風のようにしゃべりまくるトーク形式）を目にした際、私は具体例の持つ力というものについて考え込まずにはいられなかった。



カントをこんなにも面白く語れるなんて思いもしなかっただろ？

(ネタ元: Schmüdde)

[Dion Almaer] クローム拡張機能とwebOSアプリはすごく似ている

（原文: Chrome Extensions and webOS Applications look quite similar）

ちらっと見ただけでわかるけど、クローム拡張機能とwebOSアプリはすごく似ている
― 賢明なる友人談

webOS（訳注: Palmのモバイル向けOS）アプリとクローム拡張機能を書いてみてわかったんだが、そのそっくりさ加減と、書こうと思えばそっくりに書けるんだと言う事実に衝撃を受けた。

ブラウザ拡張機能の仕組みとモバイルアプリのランタイムライブラリの相似性というのは一見奇妙に思えるかも知れないが、良く見ると実は上位層において以下のような多くの共通点がある

サンドボックスからの脱獄

両者ともにブラウザのサンドボックス型実行環境という壁を打ち破る必要がある。拡張機能（訳注: Firefox拡張機能のこと?）はこういった制約をもともと受けないし、クローム拡張機能においても（訳注: タブ毎のサンドボックスという制約があるクローム拡張機能においても）ブラウザのUI構成要素に関する各種APIにより、より広範なアクセスが実現されている。

webOSにおいても全く同様な問題がある。ネイティブアプリを構築する場合はこういった制約が無いのだが、Webアプリでは制約を受けることになるので新たにAPI・UIウィジェット・サービスAPIが追加された。

この問題はwebOS・クローム拡張機能という２つの世界を越えて存在するものであり、近い将来、Webアプリ向ランタイムライブラリが受難することになる最も大きな試練のうちの一つである。私は、ランタイムライブラリでより多くのことが出来るようになり、データアクセスに関しても、サードパーティが運営しているサーバが提供するサービスを通じたデータアクセスだけではなくローカルマシンでも可能になってほしいと期待している。こういった願望は、以下に述べるような問題へと我々を誘う…

パーミッション

Webはパーミッション指定によるアクセス制御モデルになっている。サンドボックス環境では実行権限が制限されているし、世間の人々は何かと言うとすぐに（最重要課題である）セキュリティ云々について言及するけれど、もしWeb経由では実行不可能なことなどが生じてきたら、そんなセキュリティのことなんて忘れてしまう。exeファイルをローカルPCにダウンロードし、それが一体何をしでかすかを全く知りもせずに、ほいほい実行してしまうと言うのは良くある話だ。

Vistaの二の舞にならず、かつ、おバカさんなユーザを上手く導けるような実行モデルを作り出すと言うのは、我々にとって大いなるチャレンジだ。ユーザに対して今何が起こっているのかを確認させる一方で、馬鹿の一つ覚えのようにユーザに確認をとるのは避けたいという要望もバランスよく取り入れる必要がある。少なくともパワーユーザにとっては、何が行われているかを表示する方が良いと私は思う。たとえアプリケーションに対してより大きな実行権限を与えている場合であっても、いつ何が行われているかを見ることが出来れば色々と助かるだろうから。もちろんAPIレベルでアクセス制限が行われていれば言う事なしだ。社会的信用にかかわる部分を切り分けて、技術的に実現したセキュリティの上に配置させるような段階まで進んだ場合においては特にそうだ。Mozillaチームはまさにこのことについて多く言及しており、私はより多くのアイディアと実装が彼らから出てくるのを心待ちにしている。

（こちらの例ではChromeにおけるクロスサイトXMLHttpRequestのパーミッションをどうやって設定するかを見ることが出来る）

アプリケーションバンドル情報

パーミッション情報およびその他のメタデータがどこかに保持されている必要がある。webOSの場合、アプリケーションに関して宣言した情報が入っているappinfo.jsonというファイルがある。Chromeではmanifesto.jsonがそうだ。

Webでは本来こういったものは存在しない。URLを入力してそこを起点とするだけだ。たしかにHTML5のマニフェストではキャッシュその他のスコープ（訳注: 適用範囲のこと。HTML5では何をどこにキャッシュするかをマニフェストで指定出来る）をブラウザに通知するが、それ以上のことはしない。webOSアプリとクローム拡張機能ではより多くのことをシステムに通知出来る。id・バージョン情報・アップデート情報の所在・アイコン・main関数の有無なんかがそうだ。

顔の無いニワトリ

諸君は顔の無いWebアプリ（訳注: UIを持たないWebアプリ）というものを思いうかべることはあまり無いだろう。一方、顔の無いwebOSアプリやクローム拡張機能というのは思い当たるところがあるだろう。UIを持たないサービスが諸君のPC上で今いくつ実行されているかご存知？ webOSではnoWindowフラグ付きで実行することが可能だが、そういったウィンドウを持たない各種サービスが提供する価値ある情報を、リッチでバリエーションに富んだ通知用UIを通じてユーザに提供することが可能である。バックグラウンド実行型アプリケーションが上手くサポートされているのだ。

クローム拡張機能ではバックグラウンドページという概念により、長い実行ライフサイクルを持つタイプのアプリケーションを管理している。バックグランドページは以下に示すようなシングルトン（訳注: デザインパターンでお馴染み）になっている

バックグラウンドページを持つクローム拡張機能の典型的なもの、例えばブラウザアクションやページ・オプションページアクションは、ダムビュー（訳注: 口のきけないビュー、すなわちビュー自身は表示機能を持たないということ）の形で実装される。ビューが何らかのステータス通知表示を必要とする場合は、ビューがバックグラウンドページに対してリクエストを発行することでステータスを取得する。バックグラウンドページがステータス変化を感知した場合、バックグラウンドページはビューに対し、ステータス表示を更新するよう要求する。

webOSとMojoフレームワークには、シンプルなモデル・ビュー・コントローラ定義だけでなく、アプリケーションのライフサイクルに関する詳細も盛り込まれたリッチなMVCシステムがある。

道のりは続く

この２つの世界やその他の世界（Jetpackとか）を見れば見るほど、これらがひとつに統合されてほしいと願う気持ちがつのる。要求される事は似通っているし、クローム拡張機能の側からクロームOSを眺めてみれば、進む道さえ間違えなければまだまだ前進の余地があるのだということが理解出来るだろう。

---

訳者コメント：INIT/cdev時代を知る人にとっては「拡張」機能じゃなくて機能「拡張」のほうが馴染み深いと思うんですが、どうなんでしょう？ ググったところでは

拡張機能 の検索結果 約 8,200,000 件
機能拡張 の検索結果 約 7,700,000 件

ということで「拡張」機能が若干優勢。

[37signals] 広い意味での「管理」というもの

（原文: Control in its wider sense）

多くの企業が従業員管理というものを追求している。管理手引書や管理方針といったものを完備し、電子メールを監視し、容認事項と禁止事項に関するルールを作製している。

だが「管理」というものは一筋縄ではいかないものだ。手綱を引き締めれば引き締めるほど、会社に対する不信感を生み出すことになる。「これは俺達と奴等の戦いなのだ」という心理が定着してしまう。この瞬間、管理システムを無駄に弄ぶというゲームが始まることになる。

だからこそ職場管理に携わる人々には、鈴木俊隆師が Zen Mind, Beginner’s Mind（邦題『禅へのいざない』）で以下のように述べていることについて、じっくりと考えてみてほしい。

人々を管理するための最善手は、彼らに「管理なんて糞食らえ」という姿勢を奨励することである。こうすることで彼らは広い意味での「管理」下に入ることになる。羊や牛を管理したいならば、広大な牧草地を与えることだ。人とて同じこと。まずは、やりたいようにやらせて様子を見守る。この方針が一番だ。見て見ぬ振りはよろしくない。見て見ぬふりは最悪の方針であるからだ。次いで最悪なのは、彼らを管理しようとすることだ。最善は見守ること。管理しようとするのではなく、ただひたすら見守ることだ。

管理手引書にはただ一言「我々は諸君を信頼している。管理なんてイラネ」とあるだけ。そんな状況を思い浮かべてみてほしい。

---

訳者コメント：自生的秩序というのはこういった背景のもとで生まれるわけです。秩序を求めるならばまずは混沌を、というのは言い過ぎかも知れませんが、世をつらつら見るに、どうみてもこの逆は真ぽいので、結構うまく行くんじゃないでしょうか。こういった混沌と秩序の相補性という観点は、未だに「東洋の智慧」みたいな感じで西洋においては魅力的に映るようです。ちょっと不思議なところではあります。まぁ確かに合理主義の半面がもたらす害毒に、ここ数百年というもの、地上は蝕まれ続けてきたわけで、それは我々日本人にも及んでいるわけで、結局のところ我々日本人にとっても忘れられた智慧になりつつあるわけですがね。

それにしても、大拙師といい俊隆師といい、禅宗のお坊さんはプレゼンが上手いです。マーケットの選択もバッチリですしね。「新鮮味を感じさせる」という観点からすれば東洋より西洋の方がニーズをより多く喚起出来るわけですから。

たしかに宗教と言うマーケットでは昔から「説法即プレゼン」なわけで、釈尊のカリスマ性も、土台としてのプレゼンの上手さがその構成要素のひとつとしてあるようです。説く法の魅力だけでなく、説き方の魅力（方便などのメソッド）や説く人の魅力（イケメンかつ王子様w）もトータルでプレゼンが構成されているというわけですな。

[37signals] これは問題だと認めることから始めよう

（原文: Step one is admitting you have a problem）

スタートアップ企業の世界は仕事中毒な人々で満ちている。仕事中毒は、友達がいなくなったり人間関係が悪化したり体調不良になったりといった、諸君の利益を損なう結果をしばしば代償としてもたらす。仕事にうちこんで来月の売上高を過去最高にすることしか頭の中に無い。来月の取引・中間目標達成・資本金の調達のことしか頭に無いのだ。

もし諸君がコカイン中毒やアルコール中毒にも似たこの仕事中毒に罹患しているのであれば、本来ならば周りの人々は諸君を病気とみなし医者に相談することを薦めるというのが普通だろう。しかしスタートアップの世界においては、仕事中毒は多くの人々によって賞賛されている。人生の瑣事を放棄してロイヤルストレートフラッシュをものにするチャンスに全てを賭けたヒーローという扱いになるのだ。

さらにまずいのは仕事中毒患者の大半が、１日に１４時間以上がりがりと仕事をすると言うのが実はさほど効率的なやり方ではない、ということを頭の中では理解しているという点にある。時間をかければかけるほど良い仕事が出来るということにはならないのだ。Jason CohenはこのことをSacrifice your health for your startup（スタートアップをやるなら健康を犠牲にしろ）という記事で説いている。彼は、睡眠を削って仕事をしても何の助けにもならないということは重々承知の上で、睡眠不足こそは仕事中毒患者にとっての名誉勲章なのだと考えている。残業時間がそのまま製品のクォリティに反映されるなんてことはおそらく無いにせよ、残業もしないようじゃ話にならない、とも。

彼は理屈を述べるにとどまらず、仕事中毒を地で行っている。「お前に必要なのは山ほどの肩書きなんだろ、それなら仕事以外には目もくれるな。何故取り憑かれたように仕事にのめりこむ必要があるのかといえば、金銭面における自由という涅槃の境地は、本当にハイになれる数少ないもののうちの一つだからなんだ」という彼の生き方を正当化してくれるものを探し出すことに必死になっている。

仕事中毒と言うのはコカイン中毒に比べれば少しはマシだが、コカイン中毒と同様な悪弊と現実逃避へとつながる。さらに重要なのは、仕事中毒は成功を収めるために必要なものなんかでは無いということだ。スタートアップ企業をやっていくにあたって、仕事中毒になる必要などない。情熱を持ち、仕事に取り憑かれるのは結構だが、人生を浪費する言い訳にはしないことだ。

[Dion Almaer] ES5がECMA標準入り

（原文: ES5 is an ECMA standard）

ES5がECMA標準入りしたよ。

今風なWebクライアントを実際に書けるような言語になるにはまだまだ多くのものが必要だというのが現状だとしても、この前進には声援を送ろうじゃないか。

IEEEほにゃらら点ほにゃららに異常にこだわって足を引っ張りまくったIBM（僕はIBMにはずっとイヤな目に合わされてきたからね、ECMAでもJCPでも・・・）と、標準化作業の最中に居眠りしてたクセに「この標準が知財面に与える影響を調査するには時間が足りない」などとぬかしたIntelには盛大なブーイングをしてやろうぜ。

Intel氏んでくれねぇかな？ おっと待った、ちゃうちゃう。ECMAなんだからあくまでも金で解決しないとねｗ

（憎まれ口になっちゃって申し訳ない。でも、Webデベロッパ達とその作り上げている世界を、もうちょっとでいいからきちんと評価してくれんもんかね）

---

訳者コメント：Dionに栄光あれ！

[37signals] 非効率こそが諸君を特別なものにする

（原文：Inefficiencies are what make you special）

ビジネスにおいて昔からあるアドバイスに「非効率性の排除」というのがある。だが実際は、非効率というレッテルを貼られたものこそが、諸君の製品を他の有象無象達から引き離してくれるものなのだ。効率に寄与しないものを全部切り捨ててしまうと、他と似たり寄ったりになってしまうハメに陥る。

私は別に、諸君のビジネスを行きあたりばったりな非効率性の詰まった謎々に仕立て上げろなどと言いたいわけではない。明確な意図のもと敢えて残しておくべきものがあるということなのだ。諸君の将来にとって意味のあるものは何なのかを判断せよということであり、たとえあぶく銭程度の節約になるとしても、そういった「あえて残しておくべきもの」について安易に省いてしまうことは拒絶せよということなのだ。

「El Bulliのメニューはお客様の声を反映させたりなんかしてません」[この記事はJohn Kottkeの記事で知った]では、ハーバードビジネススクールが、Ferran Adriàの経営するEl Bulli（世界一にランクされているレストラン）についての観察を行っている。

従業員数を減らせ・材料費を切り詰めろ・サプライチェーンを改善せよ・営業時間を延長せよといったような、MBA連中が即座に指摘するであろう非効率がこのレストランには多く存在した。しかしEl Bulliにそんな「修繕」をほどこせば他のレストランと変りないものになってしまう、とNorton（ハーバードビジネススクールの助教授であるMichael Norton）は語る。「この非効率こそが人々に価値をもたらす要素になっているのだ」

ただ単に非効率的だからと言う理由で何かを切り捨てる前に、別の視点からすればこれは価値を付与してくれるものなのではないかと自問してみることだ。綺麗な包装に費用を注ぎ込む・素材の鮮度を上げる・縫製をさらにしっかりしたものにする・手書きのお礼状を添えるといったようなことが、誰かがまわりに諸君のことを吹聴してくれる理由になる。一見「間違っている」ように見える選択が、諸君を他に抜きん出たものとし、商品を他に例を見ないものにしてくれるということがしばしばある。それは君の調理した一品を特別なものにしてくれるスパイスなのだ。

この記事でNortonは、Adriàの「顧客を理解することと顧客に耳を傾けることの区別をはっきり付ける」という手法を引用している。

諸君がもし顧客の声に耳を傾けたとしても、顧客がこうしてほしいと諸君に話すようなことは顧客それぞれの経験に基づいたものしか出てこないものだ、というのがAdriàの考えだ。もし私が脂身の少ないステーキが好きだと言えば、彼はそういうステーキを出し、私はそれを美味しくいただくことになる。だがこれでは一期一会の経験とはなりえない。一期一会の経験を創りだすには顧客の声に耳を傾けてはならないという方が近いのだ。Adriàは顧客の声に耳を傾けないと言う。彼の顧客は世界一満足しているにも関わらずだ。これは一考に値する興味深い謎である。

関連記事：More Signal vs. Noise posts about chefs

---

訳者コメント：
効率厨ｗというのは何もネトゲ界隈だけで見られる現象じゃないということです。日本語の複雑さ、つまり、表記と読みが全単射になってないとか、表記のバリエーション・ゆらぎとか、表記の歴史的変遷とかを非効率として排除してしまうとえらくつまんない言語ゾンビが出来上がっちゃうよということです。豊穣なる日本語を支えているのは、こういった非効率性に他なりません。私なんかは、これこそが日本の武器だと思っています。

そういう意味において、Googleが日本語入力に関して採った戦略は正解だったと言えるでしょう。効率性という人為的・恣意的尺度を切り捨て、あるがままのコンテンツをもとに機械的・最尤法的処理を行うという姿勢がうかがえるからです。「意味」を破棄することで逆説的に「意味」を浮き上がらせたのだとも言えるでしょう。

[37signals] 「いいとこどり」は物事の核心を損なう

（原文：Cherry picking is the enemy of soul）

“A Talking Head Dreams of a Perfect City,” という記事でデビッド・バーンは、異国の街に対する愛着をこう記している

シェフがイタリア人でエンジニアがドイツ人という国があったらそこは天国だ、という古いジョークがある。逆だったら地獄というのもね。試しに、完璧な街ってどんなものなのかと考えてみたところ、それぞれの街の最も良質なところを混ぜ合わせたような場所、というのを思い付いた。組み合わせは無限だ。私なら多分、夜遊びはニューヨークなんだけど場所的にはシドニーで、そこにはバルセロナにあるようなバーや、メキシコシティにあるような屋外のレストランでシンガポール風の料理を楽しむ、ということになる。京都における人々のもてなしと上品さを基盤に、スペインにおけるユーモアのセンスという層を重ねるというのもありかもしれない。もちろん現実には、こんないいとこどりなんてありえない。街の持つクオリティというものは街の持つコンテキストすなわち背景や状況なしには発展し得ないものなのだから、というのがその大きな理由だ。その土地の料理・建築・言語というものは何らかの要因により相互に絡み合っており分かち難いものだ。だがそれでも、人はそんな街を夢みる。

バーンの記事は実に魅力的だが、最初に彼が警告している通り、個々の要素をばらばらにして取り出す「いいとこどり」という考えは夢物語にすぎない。クオリティはコンテキスト無しには発展し得ない。全てのものは相互に絡み合っているのだ。

人参の核心にあるもの

これに関連した事例として（Michael Pollanにより広められた）"the soul of carrot（人参の核心にあるもの）" がある。科学者達は人参から健康に有益な成分を分離抽出する試みを続けている。彼らは人参に含まれる１５のカロチンを識別したが、カロチン錠剤では実際に人参を食べることでもたらされる健康上の有効性は得られないという結果に終わっている。Pollan は、食物科学者達の還元主義のどこに問題があるかをこう述べている：

私達は人参が体に良いと知ってます、そうでしょ？ 長いこと食べて来ましたし、癌予防に役立つ成分はベータカロチンだという仮説も立てられるに至りました。人参がオレンジ色に見えるのはベータカロチンのせいです。私達はそこで、ベータカロチンを抽出してサプリメント錠剤を作って人々に投与したところ、うーんと頭をひねることになりました。一定数の人について、より多くのサプリを飲んだ人の方が病状が悪化したのではないかとかベータカロチンによって癌の発症率が上がったのではないかと思わせる結果が出て、この結果に頭を掻きむしる科学者を見るに至ったのです。解釈としては２通りあります。どっちが正しいかはわかりません。でも、ベータカロチンが癌予防のための主成分では無いというのは、解釈の一つとして間違いなくあります。人参には他に５０種類ものカロチンが含まれているというのは御存知の通りです。

食べ物というのは非常に複雑なものです。それは、えーとですね、未開の荒野のようなものであり、私達は人参の核心部分の奥底で一体何が起こっているのかを理解していないのです。そして私達は、そんなものは化学物質というものに単純化出来るなんていう考えによって、我々自身を欺くべきではないのです。それはまた、異なる物の間に起こる何らかのシナジー（訳注: 相異なる物が協同して起こる作用）なのかもしれません。ベータカロチンは葉緑素との複合体という形でも見つかっており、健康に寄与するのはこの組み合わせなのかもしれません。重要なのは、人参を食べる者としての視点からすれば、人参の効能をもたらすものは何か？を知る必要なんて無いのだ、ということなのです。私達は人参を食べる事が出来、それは美味しくて体に良い。それだけの事です。

健康に有効な成分を分離するというのは思った以上に困難だ。未だ明らかになっていない組み合わせによりもたらされる効能があるのだ。我々がまだ完全に理解出来ていない核心がそこにはある。

全体というものは部分の総和よりも大きくなる事がしばしばある

こんにちの、ばらばらにしてからカット＆ペーストするというのが主流の世界では、物事の一番良い部分だけを選り抜こうという考えになりがちだ。クライアントにデザイン提示する際の "show three comps（見本を３つ提示せよ）" （訳注：comp とは comprehensive layout のことで、広告・印刷業界ではカンプと呼ばれる。製作物の仕上がりを具体的に顧客へ提示する為の見本のこと）という手法について考えて見てほしい。同じ様な事がこの場合でも間違いなく起こる。顧客がデザイン#1からいくつかデザイン要素を抜き出し、デザイン#2からは２つ抜き出し、デザイン#3から数個抜き出す。そしてデザイナーはこれらの部品からフランケンシュタインでも作るように継ぎ接ぎして「完璧な」合成物を作り上げようとするのだが、その結果は完璧にはほど遠いものになってしまう。「いいとこどり」が全体のまとまりをぶちこわしにしてしまうというのはそういうことなのだ。出来上がった製品は、統一感を欠いた寄せ集めのコラージュのように見えてしまう。

いいとこどりをするという事は、対象の完全無欠生を損なうという事にほかならない。対象を偉大なものたらしめている目に見えない側面を失ってしまう事になるのだ。全体をつなぎ止めている目に見えない糸を切ってしまう事になるのだ。魂のこもった物ではなく雑多な寄せ集めを手にするハメになってしまう。

改良する・洗練する・アイディアを組み合わせるといった努力をすべきではないなどと言うつもりは無い。仕事を進めるにあたって出費に見合う見返りがあるかどうか考えてみる、という事だけ心に留めておいてほしいのだ。

[37signals] 私は仕立て屋さんです

（原文: I'm a tailor）

あなたは一日中何をしているのと人に聞かれると、私は自分の言いたい事をまとめるのに苦労する。設計したり、編集したり、考えたり、検証したり、助言したり、教えたり。私が台無しにしてしまうものもあれば、私がうまくまとめるものもある。

でも私が一日の大半を費やすのは、生地のふちを落としたり、裾を折り込んだり、アイロンをかけたり、切ったり、プレスしたり、ぴったり合わせたり、といった作業だ。私はソフトウェア仕立て屋さんなのだ。

そして私は、これこそ私の天職なのだと思うようになった。私のチームは素晴らしい。これをしろなどと彼らに言う必要は無い。もしソフトウェア版ファンタジーリーグ（訳注: 自分の思い通りの選手を選んで野球やフットボールのチームを作るシミュレーションゲーム）があったとしても、私のチームは誰も入れ替えるつもりはない。

だが開発・設計を進める中では、作ったものが思ったほどしっくり来ない時もある。その文は短くならんかなとか、その造形要素は切り詰められないかなとか、その処理ではこのステップを省略出来ないかなとか、アイロンをかけて頑固なしわを伸ばすようにUX全般にアイロンをかけてこまごまとした問題を解決できんかな、と言った感じで。

仕立て屋さんはテーラーメードの服をあつらえることも出来るのだが、それよりも他の仕立て屋さんが作った服をお客さんに合うように仕立て直す方に大半の時間を費やしている。これはまさに私が大半の時間を費やしている事、すなわち私のチームが作ったソフトをお客さんに合わせて仕立て直すのと同じ事だ。

こういった作業の事を「編集」と呼ぶ人もいるが、私は「仕立」のほうが近いと思う。ということで、これから私は自分の仕事についてこう説明することにする。

私はソフトウェア仕立て屋さんです。

---

訳者コメント：
ソフトウェアのコモディティ化というのは、こういった姿勢から産まれてくるんじゃないかと思うわけです。確かに仕立てというのは生地によるエンジニアリングですしね。

そういう観点からすれば、書というのは平安時代においては最も重要なエンジニアリング対象だったと言えるでしょう。書き順の最適化や省略記法といった、日本流の書というシステムにおける基本ライブラリが空海から行成にいたるエースプログラマ達によって開発されたわけです。

[37signals] ユニコーンと経済予測

（原文: Unicorns and projections）

"Off the Chart" は、最近の失業率が予測と大きくかけ離れている事が判明したと述べている。理由はこうだ「現実が現実に即した値を提示したのだ」

経済予測がはらむ問題はここにある。現実とは、やっかいな相棒のようなものだ。諸君がいかに現実とうまくやっていこうとしても、現実というやつは自らの考えを押し通すだけなのだ。現実というやつは諸君の言う事に耳を傾ける気など無い。

もうひとつの理由として、ドゥームセイヤー（訳注: 不吉な予言をする人のこと）になるよりはチアリーダーになるほうが楽だからだ、というのがある。予測の結末が諸君に特権をもたらしてくれるような場合は、特にそうだ。人々がお花畑のような明るい未来像に騙される理由はここにある。「このプランは上手く行かないでしょう」と言いながら投資家にビジネスプランを提案するような奴にはこれまで一度もお目にかかったことが無い。

今度諸君が、予測に基づいて作成されたビジネスプランやチャートを持参してきた奴と会う事になったら、そこにはユニコーンとドラゴンが内包されているんだと考える事だね。同様のことが言えるのだから。

[37signals] Rodrigo and Gabriela は Getting Real の音楽版

（原文: Getting Real (the musical way) with Rodrigo and Gabriela）

Signal vs. Noise の読者であり JobChoy の創立者でもある Mark Meeus の投稿：

Rodrigo and Gabriela と彼らに関する逸話について諸君が御存知かどうかは私にはわからないが、もし御存知であればこれ以上は読まなくても良いよ ;-)

私が彼らについて諸君にかいつまんで説明したいというそのワケは、彼らが、WEBアプリケーション以外でもあてはまる Getting Real の良い例だからだ。

Rodrigo and Gabriela はメキシコシティでヘビメタバンドのギタリストとして活動を始めた。音楽だけで生計を立てるというのが彼らの人生における目標だったのだがそれは上手く行かなかった。二人ともメキシコシティ音楽院の入試は不合格となり、バンドも思ったほど伸びなかった。

そこで彼らはアコースティックギターのみを手元に残し、残りの機材全てを売り払うことにした。彼らはダブリンに移り、そこでバー・ストリート・地下鉄の駅での演奏を始めた。

最初のうちは Metallica のカバー曲を演っていたが間もなくして物足りなさを感じるようになり自らの曲も演るようになった。

彼らはお金を稼ぐ必要があったので、音楽を「最適化」しなければならなかった。曲を書いたら、それがどの程度の稼ぎになるかを見極めるためにライブでテスト演奏し、ちょっと書き換えてそれがどの程度の稼ぎになるかを見極め、さらにちょっと書き換えて・・・（これって A/Bテストの音楽版だね）（訳注: A/BテストはSEM業界などで知られている手法で、既存のものをA、修正を加えたものをBとして比較テストするという手法）

しばらくして、彼らはお金をやりくりして他の街にも行くようになり、それにつれて、より多くの聴衆と名声を訪れた先々で得るようになった。

2006年にアルバム『Rodrigo y Gabriela』をリリースし、アイルランドのヒットチャートを席巻したが、これはインストバンドとしてはかって例を見ないものだった。

さて、この話のどの辺りが 'Getting Real' なのだろう？

彼らは「ギター２本だけなんて無茶」と説く連中の言葉には一切耳を傾けなかった。

• チーム構成員は２人だけ！
• 外部からの出資は一切なし（今となっては珍しくもないが、彼らは2000年以前にこれをやってのけた）
• ギター２本だけの構成なのでメンバー間の意地の張り合いが普通のバンドよりも抑えられる
• 情熱
• お金もギター以外の楽器も一切無い、という制約
• 彼らの音楽にふさわしい聴衆を集め、聴衆の求める音楽に的を絞った
• 「自分の音楽」というものへのこだわり
• 曲を書いたらすぐにストリートで演奏するという、無茶苦茶といえば無茶苦茶な、テストドリブンな曲作りを武器に出世競争に臨んだ

こういったことを抜きにしても彼らの音楽は本当に素晴らしいんだけど、このことを頭の隅に入れておけば、またひと味違ってくるんじゃない？

---

訳者コメント：
バカテクなのに全然バカテク臭くない。豪快なのに濁りが無いのはミュートが完璧だからですね。エレアコ２本でこれだけシンフォニックな響きを出すには、必要なノイズを積極的に取り込む姿勢が要るわけですが、逆に不要なノイズは極力排除しなければならないわけで、その結果、この完璧なミュートが自然と身に付いたんでしょうね。呼吸するように、当たり前のように精進している人々の好例です。


シメがスペインってのがこれまた。

[37signals] Chipotle や Pinkberry といった会社が「的を絞る」ことで大成功を収めたワケ

（原文: How Chipotle, Pinkberry, and others win big by doing just a few things well）

シンプル性というやつには「簡単そうで実は難しい」という隠し事がある。たいがいの人が複雑怪奇な製品を作り出してしまう原因はここにある。大多数の企業に欠けている深慮遠謀・規律・忍耐といったものが、シンプル性の実現においては求められる。諸君が付け入る隙はここにある。競合他社よりシンプル性において勝ることが、多くの顧客を勝ち取る事になる。

Chipotle のメニューにはブリトー・タコス・サラダという、たった３つの主要品目しか載っていない。Chipotle’s Secret Salsa という記事で、創業者兼CEOの Steve Ells 氏は「的を絞り、他の誰よりもそれをうまくこなす」 というひとことで Chipotle のビジネスモデルを要約している。

Chipotle のメニューにはデザートが見当たらない。レストラン経営アナリストは、クッキー等のデザートを食後に出せばすぐに売り上げが１０％以上のびるのに、と言っている。でも Ells 氏は歯牙にかけない。「ウチはこの１０年、連続して二桁台の成長を遂げている、クッキーなしでね」と彼は言う。「なんで今更？ クッキーをメニューに追加することで生じるマイナス面しか思い付かないんですけどね」

ヨーグルトのチェーン店である Pinkberry は、オリジナルとグリーンティーという、たった２つのフレーバーだけで商売を始めた。これには、商品の種類を多くする事で在庫表・製造機器・レシピといったものがややこしくなってしまうのは避けたい、という意味合いがあった。同社は今や何ダースものチェーン店と、同社のヨーグルトを "Crackberry"（訳注: crack すなわち麻薬のように中毒性があるという褒め言葉）と呼ぶ熱烈なファンを抱えている（自分の製品名の頭にcrackを付けるとどんな感じがするか、ってことを考えた事ある？）

こういった話はレストランだけにあてはまるわけではない。Nintendo は他社よりもスペックを絞り込むことで大成功を収めた。Flip（訳注: Flip Video 社）も機能を絞り込むことで家庭用ビデオカメラ市場において大きなシェアを得た。固定ギアの自転車（訳注: ピストバイクとも呼ばれる。ニューヨークのメッセンジャー達がノーブレーキのトラックレーサーを使い始めたのが皮切り。ストリートカルチャーの一環として日本でも2000年代半ばあたりから見かけるようになった）も、そのシンプルでメンテナンスが容易なデザインにより人気を上げてきている。

諸君が、ありとあらゆるものを顧客に提供するという「機能てんこもり競争」に手を出すことは、確かに不可能なことではない。それが嫌なら、少数の事に的を絞り、それを上手くやってのけ、諸君のそういった姿勢を心から愛しその結果諸君の製品に愛着を持ってくれるような顧客を獲得する事だ。小規模事業者にとっては、これが賢明な道というものだ。

この道を選ぶことで諸君は明解さというものを手にする事になる。万事がシンプルになる。製品説明も、人々に製品を理解してもらうのもシンプルな言葉で済む。変更を加える際も、メンテナンスをする際も。人々が製品を利用し始める場合もシンプルで面倒が無い。原材料・包装・サポート・マニュアルもシンプルになる。見積もりもだ。そして最も重要なこととして、成功への道がシンプルになるのだ。

---

訳者コメント:
Crackberry って‥‥ブラックカレーみたいなもんか？