[37signals] チェックリストで作業内容を確認せよ

(原文: Verify your work with checklists)

先日、手術時の安全に関するチェックリストに病院が従えば手術における死亡者は３分の１まで減るとWHO（世界保健機構）が発表した。チェックリストという手法そのものは極めてローテクなやり方だ。患者の本人確認が適切に行われているか、適切な器具が利用可能になっているか、今どういった処置が行われているかをみんなが把握しているか、といったような質問事項がチェックリストに含まれている。

チェックリストがシンプルであればあるほど多くの命を救えるならば、チェックリスト作成技術というものもこれと同様に、私たちの得る成果を確実に向上させてくれると思う。というわけで、この研究発表と彼らのチェックリストを目にした後、37signalsにおける共通作業手順の全てに関するチェックリスト作りに取り組んでいる。

現在私たちは Backpack で、フィーチャが完成しているかを確認するためのチェックリスト、フィーチャを現地に配備する際の準備および配備実施のためのチェックリスト、フィーチャが現地で想定通りに動いているかを最終確認するためのチェックリストを利用している。



これらはみんなわかりきった事ではあるが、ちょっと気を抜くと忘れてしまうものばかりだ。過去において経験したミスを振り返ってみると、チェックリストを利用していれば未然に防げたりミスを犯す前に気付くことが出来たはずのものが多くある。

顧客の生命に関わると言ったものではないにせよ、少なくとも顧客のデータやサーバの安定稼働を確保するためにはどういったチェックリストが役立つのかを考えてみることだ。

[programming] 実験中

リハビリを兼ねて Google App Engine を利用したサービス構築に取り組んでいます。

userChrome.js からDictionary.app を呼び出す（macaw 氏の lookupindictionary.uc.js を参考にしてます）際に、引いた単語に関する情報を GAE で作成した dlustat というサービスに POST して Datastore に格納、あとはその情報をもとに辞書を引いた履歴やそれぞれの単語について引いた回数を見られるようにしてます。

これにより「何回も辞書を引いている単語＝弱点となっている単語」といったことが見えてくるかも、ということでまずは自分用にざくざく作ってます。

GAE 自体はミニ Django という感じですが、インストールやデプロイの面で遥かに取っ付き易くなってますね。Datastore は GROUP BY 等が使えない訳ですが、名前の通りだと考えれば、即ちあくまでもデータストアでありデータベースではないと考えればいいわけで、クエリの貧弱さについてはアプリ側（ミドルウェア）で set 使うなりして何とかしてね、という姿勢が窺えます。これはこれで正しいと思います。関係代数オワタとか JOIN（笑）とか言うのは早計かもしれませんけどね。

[Dion Almaer] Googleの「20%ルール」の背後にある英知；時間の問題じゃないのだ

(原文: The genius behind the Google 20% time; It isn’t the time)

Paul Buchheitの「コードはトークより強し」という趣旨で書かれた実に素晴らしい投稿の一節に私は共感した：

もしイノベーションをもたらそうと思ったら、評価され難いアイディアや大抵の人に馬鹿にされるようなアイディアにも取り組めるようにするということが重要だ。20%ルールの真価は時間を割くということではなく、「重要でない事」にも堂々と取り組める点にある。（私もそのうち、投稿は20%タイムを使ってするようになるかもしれないね）

これは私が20%タイムについて感じていた事と全く一致している。時間の問題じゃないのだ。実際のところ、多くの人がこの時間を利用しているということを私は知らなかった。20%ルールの真価は、以下のような効果をもたらすという点にある：

• 20%ルールをうまく機能させる為に、成果物を皆が見れるようにする
• 実際問題として、もしみんなに「ただ働き」してほしいのであれば、プロジェクトを宣伝するとともに、人々が気兼ねなくプロジェクトの品質や生産性の向上に貢献出来るようなやり方でもってコードを書く必要がある（結果として、より良いコードがもたらされる）

結論として言えるのは「文化というものは本当にオープンなものであり続けなければならぬ」ということだ。私の見るところ、エンジニアリングにおいてGoogleが実に上手くやってのけている主な理由は、現在取り組まれているプロジェクトを見る事が出来、そのプロジェクトのコードを見ることが出来、そのプロジェクトのプレゼンや設計資料を見る事が出来るという点にある。

Appleのような、社屋の反対側に座っている奴が何をしているか見当もつかない企業と比較してみてほしい。そいつのプロジェクトに関して言うならば、もし君にゲームの流れを変えるような素晴らしい知恵があったとしても、そんなことは起こり得ないということなのだ。

英知の閃きとでも言うべきものがひょっこり降臨する、それが20%タイムというものだ。もし君がこれを真似しようと言うのなら、時間に関する側面は無視して、オープンな文化という側面を採用する事だ。

私はGoogleでこっそりと進められているプロジェクトを目にするたびにいらいらさせられる。これではプロジェクトに何も起こらないじゃないか。パーティに参加せずにほっつき歩いているようなものだ。

[scobleizer] トレードショーはもう死んでいる？ 私の解答にみんな驚くだろうな

(原文: Are trade shows dead? My answer might surprise you)

元PC World編集長のHarry MacCrackenが、CESは縮小しつつあると言ってる。今年は22%の縮小だった。

来年はもっと縮小するだろうと予言しておくよ。何故かって？ 私は技術系大企業のマーケティング担当者に知り合いが多いんだけど、彼らが来年はブースを縮小する予定だと言っているからね。

その一方で、ショーへの投資は見返りが多かったので今後は投資を増やす、もしくは今回と同程度の投資する、という発言も相当数あった。

というわけで、CESは死に瀕しているという私の発言は間違いだったね。CESが死ぬなんて、はっきり言ってありえない。

もうひとつの方はどうかって？ MacWorldは死に至る悪循環の真只中にある。この先２年間のうちにAppleがMacWorldに復帰すると期待している人は、私の知る範囲では誰もいない。IDGはiPhone Worldと言う名でイメチェンして開催するかもしれない。瀕死のMacWorldを救うためにね。今すぐそれが実現したらどうだろうって？ 私としてはこれが救いになるかどうかについて確信は持てないね。IDGはよろこんで私と連絡を付け、すごいショーになるよと、その訳を説明してくれるだろうが、Appleや主要ベンダーの撤退により、MacWorldの死は確実なものに見える。

CESでBroadcomのブースを歩き回っていたときにも教訓を得る事が出来た。CESは原点に、すなわち技術系企業とバイヤーとのやりとりの場という原点に返りつつあるんだ。これこそがトレードショーならではのこと、すなわち企業上層部のもとに足を運ぶだけでは味わえないことなんだ。

というわけで、トレードショーがなくなるなんてことはない。明らかな規模縮小が当面は続くとしてもね。ちなみにべガスで乗ったタクシーの運ちゃんは、今年はどのトレードショーも例年に比べて客が減ってると言ってた。べガスは不況に打ちのめされてる（日曜日の空港はガラガラだった。私が始めて足を踏み入れた１９８０年以降というもの、こんな状況は目にした事が無い）

これはBroadcomのブースで収録した、来年出る次世代携帯電話に使われる予定のチップを紹介しているビデオだよ。見てね。

[37signals] 他社は瀕死状態なのに Cook's Illustrated が繁盛している理由

(原文: How Cook's Illustrated thrives while others are dying)

全ての出版物が財政的に臨死状態にあるという訳ではない。

Cook's Illustrated は広告に頼ることなく、有料で料理レシピをオンラインで提供している。NYT の "Let's Invent an iTunes for News" という記事によれば、印刷された紙面の定期購読数は９０万部（および店頭販売が１０万部）、年間 $35 での購読となるデジタル版紙面は２６万部と、2008年に30%にまで拡大したほどの繁盛ぶりだ。

多くの企業はこう考えるだろう「オンライン版のレシピに課金するなんてありえない。そんなものWeb上でタダで手に入るじゃないか！」と。そこを上手くやるにはCI（訳注: Corporate Identity）をどうやって構築していけばいいのだろう？ "the Consumer Reports of food" に書かれている通りだ。Cook's Illustrated では台所用品の目隠しテスト結果や、細かい部分に至るまで徹底して配慮が行き届くよう何回となく推敲された料理レシピが提供されている。

“Why Cook’s Illustrated is different than other cooking magazines（Cook's Illustrated が他の料理雑誌と違っている理由）” でも、その完璧主義が大々的に謳われている「これ以上信頼出来る料理雑誌はありません。Cook's Illustrated が味を保証するチーズケーキを紹介するのは、編集スタッフが４５点以上を付けた時だけなのです」。サイト利用者の半数が印刷物の方も購読しているということからも窺えるように、オンラインでレシピが見れるというのは重要なことである。

Cook's Illustrated の CI は、得意な分野に焦点を絞り、他の雑誌が触れている流行の料理といったものには手を出さないことで成功を収めている。Cook's Illustrated 編集長の Jack Bishop はこう語る

私たちの雑誌は多くの点において、時代にとらわれないものだ。最新の最も素晴らしいトレンドについて紙面で触れることは無いし、取材旅行に行く事も無いし、ロサンジェルスの最先端シェフに関する特集記事なんてものも無い。私たちが扱うのはおいしい家庭料理につながる技術や器具や素材に関するものであり、そういったものは月や年といった程度の単位では大きく変わらないものだ。

それだけではなく、この会社は他の今風な料理雑誌を敵に回してすらいる。創立者であり編集者である Christopher Kimball はこう書いている

見た目だけは立派な料理雑誌とは違い、私たちの雑誌は料理の記事が詰まっているし、編集者達はフードスタイリストなんかじゃない。

この会社はまた、料理の本やTV番組や雑誌や Web サイトといった複数のプラットフォーム上で自社コンテンツを活用する事により、あらゆる潜在的な収入源から上手いこと利益を得ている。この Web サイトには、他のサイトには無い、図解やビデオという切り札もある。G.L.Mazetta 社の料理研究家である Shea Rosen は、何故こういった図解やビデオが有益なのかという点についてこう語っている

ビデオや図解を提供するのは、どうやればきちんと出来るのかを人々に示す良い方法です。他のサイトでは鳥の骨の取り方を説明してくれるかもしれませんが、写真や図解やビデオはそれよりもはるかに判りやすい。もし野菜をきちんとさいの目に切る方法を知りたいというのなら、コックさんがどのように包丁を握っているかを見たくなるでしょうしね。

いかにも Cook's Illustrated らしい図解の一例　

Rosen は、他の月並みな料理サイトに比べて深く探求を行っている Cook's Illustrated の CI がお気に入りだ

料理研究には大量の情報が含まれています。卵白を泡立てる時にクリームタータ（訳注: 酒石酸水素カリウム。メレンゲの泡を保つ働きがある）を使う理由は？と言った感じのものです。レシピには「クリームタータを入れましょう」と書いてありますが、何故入れるのか不思議に思うことでしょう。彼らはこういった質問に答えてくれます。どうしてローストしたものは調理後、食卓に出すまで寝かせておく方が良いのだろうというのもあります。理由を知ると楽しいですよ。

というわけで、製品に課金する事は不可能だと考えているならば、成功へと通ずる CI というものについて考えてみることだ。競合他社よりも完璧に徹する、流行廃りに関係ないものを提供する、他のメディアでも上手く運ぶよう企画し直す、ビデオ（もしくはその他のテクノロジ）を利用して刷新を行う、より得意分野に特化する、といったことが可能だろう。こうすることによって、他社が課金することをあきらめているようなことであっても君なら課金を実施出来るような道が開けるのだ。

[メモ] 少子化に関するネタ

少子化問題は最終的に一夫一婦制の禁止により解決されることになるが、その前に少子化問題自体が問題視されなくなる可能性も高い。どちらにせよ文明の黄昏が来ることに変わりはない。

[37signals] 考えるよりも行動？

(原文: Leap before you look?)

Crate & BarrelのCEOであるGordon Segalは、分別が無かったからこそ事業を軌道に乗せる事が出来たのだ、と語っている。

「小売業に関する知識なんてまるでなかった」とSegalは当時を振り返る。「私はレストラン業務を通じて育ったので、サービス業に関しては知っていたけれど、小売業については知らなかった。値下げ額の動向を通じて価格の相場を把握するという事も知らなかった。輸入業務についても知らなかった。実際のところ、２３歳という若さと分別の無さのおかげでここまで来れたのだ。前進に必要なのは情熱だけなのだし、深く考え込まずに猪突猛進することだね」とSegalは述べた。

「私たちのやったことはまさに1960年代のカウンターカルチャーの物語そのものだったんだ」とSegalは語った。「私たちは文字通り梱包をひっぺがし、商品を積み上げて商売したんだ。やり方が変だとは全く思わなかった。そりゃもちろん、みんな店に入って驚いてたよ、若僧二人でこんな商売を始めたということと、フランスの陶器やスウェーデンのガラス器具やデンマークの食器類を私たちが見つけ出してきてオールドタウンというシカゴの狭い通りにある店に持ち込んだことにね。今振り返ってみれば、店舗面積わずか1,700平方フィート（訳注: 約158平米）の小さな店に商品を入れることが出来ると思っていたんだから、全く、正気の沙汰じゃなかったよ」

君はこう思うだろう「業界ルールを知らなかったからこそ成功した、世間が考えているようなやり方を理解していなかったからこそ成功した、なんていう例が他にいくつあるだろう？」

私たちはずっと「転ばぬ先の杖」と教えられてきたが、この世にはSegalのような「考えるよりも行動」で成功を勝ち取った人もいるのだということを耳にすると興味深いものがある。

それじゃあ分別は成功への道ではないとでも言いたいのか？ いやいや、もちろん大概の場合は分別こそが成功への道だ。だが、時によっては分別を欠いたものこそが勝利するのだ。NFLのクオーターバック達がいい例だ。月並みな話だが、最も賢いものが最も良いとは限らないのだ。

プロフットボールのドラフト選考にかけられるクオーターバック達はワンダリック人事考査テストという知能テストを受ける必要がある。1999年のドラフト一次選考を受けた５人のうちで唯だ一人殿堂入りを果たしているDonovan McNabbのワンダリック人事考査テストの点数は５人のうちで最も悪かった。他にMcNabbと同じくらい点数が悪かったのは誰がいたのだろう？ Dan MarinoとTerry Bradshawが同じくらい点数が悪かった。二人とも素晴らしいクオーターバックだ。

こういったクオーターバック達は、ある意味、高い知能指数を持ち合わせていなかったからこそ成功を収めたのだろう。物事について深く考える知性ではなく根性で切り抜けてきたのだろう。

まぁ、無教育バンザイとか言いたいわけじゃないんだ。考えるよりも行動せよというのが他国を侵略する際の一番良いやり方ではないんだよなぁ。でももし君たちが、起業とかがそうなんだが、何かちょっとしたリスクを伴うような事をする際には、反対者達、つまり計画を立てたりリサーチしたりテストをしたり勉強したり競争について学んだりといったことに莫大な時間と金を要するなどと主張して君に反対する人たちの事は無視するのが賢明だ。時によっては、自分が無知であることを気にしない事や、案ずるより産むが易しで世に何かを送り出す事こそが真に重要な事になるのだ。

---

訳者コメント:
最後の段落の "Leaping before you look isn't the best way to, say, invade a foreign country." の say に「なぁ、イスラエルさんよぉ」というコンテキストというか空気を感じたんですが、どうなんでしょうね実際のところ。

それはさておき、松岡正剛先生がこのタイミングで老子を千夜千冊してくださった事にシンクロニシティめいたものを感じましたよ。「聖を絶ち智を棄つれば、民の利は百倍す」という老子のパラドクシカルな一節と、現今の混迷を乗り切るメソッドとして37signalsが提示してくれたこのエントリ。同じ通奏低音が響いています。

[37signals] Moore氏はシャーディングを蹴飛ばす

(原文: Mr. Moore gets to punt on sharding)

シャーディングは大規模データベースをより小さなものに分割するデータベース構築手法だ。でかい鉄のかたまりのような１台のマシンに１００万人ぶん格納する代わりに、より小さな個別の１０台のマシンに１０万人ぶんづつ格納する。

この手法については一般に、必要に迫られるまで手を出すな、と言われている。Martin Fowler（訳注: リファクタリングでおなじみ）が分散オブジェクト設計の第一法則として「オブジェクトを分散させるな」と言っているのと似たようなものだ。シャーディングはいまだに他の手法と比べて難しいし、支援ツールは貧弱だし、あきらかにセットアップ作業が複雑化する。

まぁ、選択の余地がなくなる日が来るのは避けられないのだということは常に意識してはいる。上方向への拡大（訳注: マシンのパフォーマンス向上などのことか）について打つ手がもうないからという理由で、素直にシャーディングしなければならなくなるかもしれない。でも、その日がくるのは遠い未来のことに思える。

キャッシュをでかくすれば読み込み性能も上がる

今やみんなが256GBのRAMが載ったマシンを入手出来るようになったという現状のおかげで、ある面、読み込み性能の問題は片付いた。私たちはちょっと前にBasecampデータベースサーバのRAMを32GBから128GBに拡張したが、これ以上拡張するつもりはない。

マシンはメモリスロット上限までRAMを積んでいたし、当時128GB以上のRAMはアホほど高くついた。だが今や256GBのRAMはお手頃価格だし、そのうち512GBのマシンも手に入りやすくなると考えている。

そういうわけで、ムーアの法則に従ってこんな風にマシン性能を飛躍的に向上させることが出来るうちは作業内容を全てメモリに置いておく事が出来るし、この先もうまくいくだろう。たとえ頭打ちになったとしても、シャーディングに手を出す前に能動的な読み込み専用スレーブマシン（訳注: レプリケーションなどに代表される負荷分散手法）を使うという手がある。

書き込みの方がより難問だ

もともと、読み込み性能が原因でシャーディングせざるを得なくなるということはない。書き込み性能が原因なのだ。私たちのアプリケーションでは未だに読み書きの競合が深刻な問題で、他の問題はそれほどでもないのだ。

だが、Fusion-IO社の120k IOPS（訳注: Input Output Per Secondのこと。スループットではなく実際の読み/書き回数を示す）を実現するioDriveのようなSSDが出てきた事により、シャーディングせざるを得なくなる状況に追い込まれるまでは、技術の進歩のおかげで今回もまた救われそうだ。

シャーディングを蹴飛ばせ

そういうわけで、シャーディングする理由なんてどこにあるんだ？ 私たちに関して言うならば、ここ数年というもの状況は変わっていない。複雑税（訳注: 複雑性の増大に伴うツケ）とは無縁なのだ。シャーディングには万策尽きた時は素直に採用するしか無いという程度の利便性しか無い、というのは言い過ぎだが、その見返りはまだ充分とは言えない。

現実面で私たちが本当に困っているのは、MySQLで構築した巨大なテーブルからデータベーススキーマを掘り起こす（訳注: いわゆるマイグレーション。データベース移行・変換に伴う作業）のにとてつもなく時間がかかってしまうという点だ。巨大なテーブルに対する項目の追加・リネーム・削除を行うのを避けるするために手の施しようがないほど肥大化した、大企業にありがちなデータベーススキーマを避けて自社スキーマに移行しようとすると、直近の問題としてこれが出てくる。えんえんと「メンテナンス中」の表示を出しっ放しにするというのも避けたい。

私としてはMySQLに詳しいヤツがこの問題に関してうまい解決策を考えてくれることを心底望んでるんだけどね。こういった点に関してはPostgreSQLの方が遥かにいいよと聞いているので、出来れば比べてみたい。

明日出来る事は今するな

近い将来の技術的進歩が解決してくれるようなことを今すぐ片付けようとするのは無意味だ、というのが私の考えた結論だ。マシンはどんな時代であれ、より速くそしてより安くなるだろうが、プログラミングに関する人員や時間といった資源には相変わらず制限がつきまとうからだ。

将来を見越して早まった最適化を行うためにでなく、ユーザの懸念事項に取り組むための人員を追加することに資源を割く事が出来れば、その近い将来というものが遂にやってきた暁には、ビジネスにおいてチャンス到来ということになるわけだ。

---

訳者コメント:
UOプレイヤーには、アバタールがぶっ壊したモンディンの「不死の宝珠」のかけら、ということで馴染み深いシャードの概念ですが、分散データベース手法としてのシャード分割というのは、レプリケーションやマルチマスタによる負荷分散とは毛色が違って「アプリケーションレイヤでなんとかする」という発想が感じられて面白い。

ざっとみたところ手法は２つ。

1. ユーザAのデータはマシンAに、ユーザBのデータはマシンBに、といったユーザレベルでのシャード分割。UO的と言える。例はこちら。
2. テーブルAはマシンAに、テーブルBはマシンBに、といったテーブルレベルでのシャード分割。リレーション（というかJOIN）と何が違うんだ？という気もする。例はこちら。

まぁDHHの指摘通り、面白いというのと実際に現場で採用するというのは別ものであり、時期尚早じゃない？というのが正直なところでしょう。アプリケーションレイヤで頑張ってパフォーマンス改善するというのはプログラマとしてはうずうずして来るところではありますが、そこをこらえるのも技量のうちということですかね。もっと他にやることあるだろうと。

ちなみに、もしシャードが今年のバズワードになったら、2chのUO板のようにショエードとかシャドーとかシャドルーとか言うヤツが出てくるんじゃないかとか、マ板かUO板か区別つかなくなるな、とか思ってニヤニヤしたですよ。

[メモ] 恵山のこと

折口信夫『折口といふ名字』に、金田一京助のアイヌ語に関する記述が引用されていた。

るゑさん (ruwessan, ru-essan) 　道の出口（浜の大道へ出る口）の事なり。下り口の義なり。ruは道にて、essanのeは接頭語、sanは出る意味なり。要するに、後方の高い処より、前方（浜）の低い方への運動なり（雑誌あらゝぎ大正七年六月号）

これを見て恵山のことを思い出した。恵山はessanすなわち出口を意味するアイヌ語だったのかもしれないと思ったのだ。何の出口かというと、渡島半島の南東突き当たりで、ここから先は津軽海峡というその地理的状況が示す通り、海への出口といったところだろうと思ったのだ。そこで、情報を得る為に恵山のホームページを見てみたところ

恵山は「火を吹き溶岩が流れ落ちる」という意味のアイヌ語「イエサン」

との記述があった。イエサンは恵山を示す固有名詞ではなく動詞もしくは形容詞であるということらしい。それにしてもイエサンの一語で、えらく豪快な形容をしてみせたものだ。ヌイ（炎）のエサン（出口）つまり火口が転訛したのかもと妄想したり、楽しみは尽きない。

併せて思い出したのがガンコウランのこと。恵山のツツジは前掲のホームページにも見られる通り、かなりポピュラーになっているようだが同じツツジ目のガンコウランについては言及が無かった。遠足の折などに摘んで食べた記憶、袋一杯に摘んだものを母が煮てジャムにした記憶、そのジャムがいちごやりんごと違いさらさらなままだった記憶。花よりも食い気の方が餓鬼の時分には重要だったようで、ツツジの花の記憶よりもそういった記憶の方が鮮明だ。その記憶の中のガンコウランの味が、決して美味とはいえないものだったとしても。

[scobleizer] Ballmerの正念場

(原文: Ballmer’s big moment)

Steve Jobs が今週行われるCESでセンターステージに立つ事は無い。かってAppleに勤務していたChuq von Rospachは、このことがAppleの世界でどう受け止められているかについてまとめている。

だが来週はもう一つ忘れちゃならない初モノがある。Bill Gatesがステージに立たない最初のCESなのだ。

Ballmerにとっては正念場だ。Steve Jobsがステージに立たないと決意してくれたおかげで、全てのスポットライトがBallmerに集中することだろう。

さて、今週お送りしていたenterprise videoを見てほしい（今朝もう一本、Jive SoftwareのCMOのビデオをアップしたとこなんだ）。わかったかな？これはBallmerにとっての正念場なんだよ。業界のみんながMicrosoftに注目してる。Ballmerにとって「ウチの庭から出ていけ」とみんなに言い渡すいい機会なんだ。

彼のすべき事は何だろう？

1. Windows 7 を披露し、Vistaよりも遥かに良いと思わせる事。もちろん難しい事ではないけど、これで聴衆を釘付けにしなきゃならない。彼の今年一番の仕事はこれ。
2. パートナー達に、2009年になってもみんながPCや携帯電話を買ってくれるのだと言って安心させる事。来週はBestBuyの偉いさん達を調査して、Steve（訳注: Steve Ballmer）の発言が彼らに反響を呼んでいるかどうか確かめるつもりだ。BestBuyその他の小売店達は今や不景気で苦しんでいる真最中だ。Ballmerは彼らに希望を持たせる事が出来るかな？
3. Microsoftがどのようにして新規市場へ進出するかを明確にする事。たとえば切り札として、噂になっている自動車向けSyncの新しいバージョンを出すとかだ。
4. 何故Microsft Officeは、いまだに、そして2010年になっても必須ツールであるのかという道理をきちんと説明する事。この一年で業界の生態系全体が、Googleが、Salesforceが、その他もろもろの会社が、Microsoftに銃口を向ける事になる（AdobeもCiscoも数年のうちにオフィスワーカー向け声明を発表する事になるだろうと予想されている）。Microsoftには価格面でも機能面でもプレッシャーがかかっているのだ。Office 14は反響を呼ぶだろうか？ それはBallmer次第だ。
5. いかにしてMicrosoftがリビングルームでお役に立ち続けるかをきちんと説明する事。昨年のIFA（ベルリンで行われる欧州の家電製品発表会）で私はPanasonicのプレス向けカンファレンスに出席したが、そこでは50インチテレビでYouTubeが動いている様子をGoogleが披露していた。リビングルームでもサービスを提供したいと願っているMicrosoftにとって、これは目の上のたんこぶだ。
6. Microsoftがモバイル業界リーダーの一員であり続けるための施策を説明する事。彼らは今まさに、新参者であるGoogle用のスペース確保のため、AppleやRIMやNokiaによって土俵際へと追い込まれている。Ballmerが来週に発言する内容と披露するもの次第で、Microsoftが相応の地位を獲得するか、過去の人になってしまうかが決まる。
7. 開発者達をわくわくさせる事。1993年当時からVisual Basicで開発しているユーザに限らずだ。開発者達の視線をFacebookやiPhoneやwebからMicrosoft製品へと向けさせる必要があるのだ。Ballmerはやってのけることが出来るだろうか？「開発者達よ、開発者達よ、開発者達よ」とわめきながら舞台で踊りまくるのとはワケが違うのだ。

Ballmerはやってのける事が出来るだろうか？ 私はこのオッサンに賭けるつもりは無いけどね。

[37signals] Getting Real とデザイン

(原文: Getting Real and Design)

デザインプロジェクトに取り組む際の方法論として私が知っているのは一つだけだ。そこから多くのバリエーションが生じるが、本質的には、Discover（発見・問題の洗い出し）・Plan（計画立案）・Design/Develop（デザインやプログラムの実装作業）・Deployment（作業成果物の配備）という４つの段階に分けられる。受注開発であろうと社内開発であろうとこのステップを踏むことに変わりはなく、そのことを疑問に思うこともなかった。

その後37signalsからGetting Realが出版され、私はこっちの方がプロジェクトに取り組むにあたってより良いやり方なのではないかと思うようになった。私が過去に取り組んだ、あのときGetting Realがあればよかったのになぁと思うデザインプロジェクトをいくつか、みなさんに紹介したい。これらのプロセスが37signalsではどのように機能しているかについての所見もあわせて紹介しよう。

問題の洗い出しとブランドの洗礼

９０年代の終わりころ、私はOrganicというインタラクティブ分野の受注開発会社に勤務していた。そこで私は才能あふれるデザイナーやプログラマー達と共に、商用サイトの再デザインに関する作業を行っていた。プロジェクトの開始早々、我々は「発見フェーズ」と呼ばれるものを放棄する事にした。３週間というもの、店舗サイトを訪れ、雑誌の切り抜きが散乱する戦略会議室を作り、ベン図とブランドに関する○×表を作った。

アートディレクターは素晴らしいクリエイティブ・ブリーフ（訳注:広告の目的・広告のターゲット・商品の特徴などで構成された、広告指針をまとめた書類）を作り、ミネアポリスにいるクライアントの上層部に向けてプレゼンを行った。プレゼンの結果は惨憺たるものだった。その理由は、我々の出した結論や調査結果が的外れだったからではない。実際に目に見えるWebページデザインを提示しなかったからなのだ。３週間と予算の15%をつぎ込んで我々がやってのけたことは、顧客がとうの昔に知り尽くしていた事を馬鹿面下げて語ったということだけだったのだ。

発見フェーズが必要になることもあり、受注開発の場合は特にそうだ。しかしこれは切り捨てることも可能だ。クライアントの上層部に現状認識をするチームがいればいいのだ。最初のプレゼンで現状のデザインに関する処置を盛り込めるよう、彼らと共同で作業するというのはどうだい？ そうすればこのステップは省けるし、予算も節約出来るし、より速やかに作業成果をクライアントに提供出来る。クリエイティブ・ブリーフも結構だが、実際のデザインはさらに結構なのだ。

ワイヤフレームとスタイルガイド

Crate & Barrel（訳注:家具や台所用品の会社）でも、発見フェーズを省略してすぐにワイヤフレーム（訳注:骨組みだけのデザイン）にとりかかるという点以外は、同じステップを踏んだ。ワイヤフレームでのプレゼンはあくびが出るほど退屈だ。販売責任者や部門長達にとって、ワイヤフレームを見ただけで正確に理解するのは困難だからだ。みんなと同様、彼らも「デザイン」が見たいのだ。プレゼンが現実に即したものになればなるほど、彼らからフィードバックや指示を得るのが容易になる。たとえそれがPhotoshopで描いた模造品であったとしても。

サイトの実働部分や機能を作るにあたって、設計担当者とデザイナーがプログラム開発者と一緒に作業を行うと考えてみてほしい。ワイヤフレーム作りは作業プロセスのひとつではあるが、プレゼンで見せるようなものではない。プレゼンが現実に即したものであればあるほど、よりよいフィードバックが得られるのだ。

ワイヤフレームはUIデザインにおける拘束になることすらある。「ワイヤフレームでそうなっているからデザインもそうしなければならない」「ワイヤフレームに無いからデザインでもそれがあってはならない」といった具合にだ。ワイヤフレームにがんじがらめにされてデザイン変更がままならないというハメに陥るのが常だ。スタイルガイド（訳注:デザイン様式に関するガイドライン・指針）についても同じような事が言える。スタイルガイドに則って、ビジュアル面において何が許可され何が許可されていないかを明らかにする為に時間を費やし、あげくのはてに自らのデザイン指針を破棄せざるをえなくなるというのがオチだ。

Crate & Barrelで最初に聞いたのが、従うべきスタイルガイドがあるかどうかだった。クリエイティブ・ディレクターのAlessandro（私の知る限り、最高に頭が切れる人のうちの一人）はこう言った、そんなものは無いし必要ない、と。スタイルガイドがあると今だけでなく将来にわたってグラフィックデザインが硬直化してしまうのだ。この考え方は実に賢いと思った。スタイルガイドなぞ無くても、存在感のあるグラフィックデザインを持った素晴らしい定番ブランドが厳然と存在している。

オープンソースデザイン

人生において最も困難な事の一つが、他人に公開・共有するということを学ぶ事だ。私はこの意味において37signalsのプログラマー達を深く尊敬している。彼らはみな、作業成果を公開するのが自明となっているオープンソースの世界からやって来ている。デザイナーというものは生まれつき公開することを嫌うものだ。少なくとも私はそうだ。私の作品が私の手を離れて自分自身の道を歩むのを見るのはつらい。実際のところ、私はそれがいやで受注開発をやめたのだ。一年後には見る影も無くぼろぼろになった自分の作品を見るはめになるというのが嫌でたまらない、というだけの理由で私は自分の作品を手放そうとしなかった。

37signalsではデザインというものは全て公開が求められる。JasonもRyanも私もシカゴ在住だが、別々の場所で作業を行う事がひんぱんにある。Highriseのマーケティングサイトを作る際に、デザインに関してレビューや方針の指示をしてもらう為にBasecampとCampfireを利用した。このプロセスは、これまでのものよりも迅速にHTMLファイルが実際に使えるレベルのものに仕上がるようになったという点で、他に類を見ないものだった。これらのHTMLファイルはみんながアクセス出来るGitのレポジトリ（訳注:Gitとは分散型のバージョン管理システムで、レポジトリとはGitの管理するプロジェクト毎に作られるファイル置き場）に置かれた。これによりJasonが私の作ったグラフィックのコピーに手を加えている間であっても、私の方でグラフィックに手を加える事が可能になった。結果として私たちは、あたかも共同でサイトを彫刻しているような気分になった。PSD（訳注:PhotoShopの画像フォーマット）ファイルを投げつけ合うことなしでだ。HTMLファイルを更新するだけでページの実物をそのまま目にすることが出来るのだ。

サイト立ち上げの時点から細かな調整も行ってきた。実際、当初からその予定だったし今なお調整は続いている。これまで取り組んだプロジェクトのうち、これは最もイテレーティブ（訳注:大きな変更をどかんと行うのではなく、細かな変更を何度も繰り返し積み重ねていくというやり方）なプロジェクトだった。このプロジェクトは商用サイトの再デザインに比べれば規模という点においては小さいけれど、こういったイテレーティブな開発手法を他でも採用しない理由は全く無い。ブランド調査やワイヤフレーム作りにかまけているから、こういったイテレーティブな手法を採れないのだ。こういった短時間で結果の出せるイテレーティブな手法は継続的なサイト改善に大いに役立つ。

Getting Realなやり方は仕事をするにあたって大いに役立つが、反面、手を出すにはちょっと怖いところもある。開発を進める上で誤りを犯したり苦渋の決断を迫られることもあるかもしれないが、結果として得られるものは諸君をよりハッピーにしてくれるだろう。どんな場合であっても、うまくいかない場合はやり方を変えればいいのだということを忘れないでほしい。諸行無常なのだから！