Project

General

Profile

Joel on Software

ストラテジーレターV

私はオープンソースソフトウェアに関する興味深いあることに気がついた。それが何かというと、オープンソースソフトウェア開発に多額の資金を使っている企業の多くは、それが彼らにとって良いビジネス戦略だからそうしているのであって、突然資本主義を信じるのをやめて、「言論の自由というときの自由(フリー)」に浮かれるようになったわけではないということだ。
市場のあらゆる製品にはそれを代替するものと補完するものがある。代替財は最初の製品が高すぎる場合にあなたが買う別の製品のことだ。鶏肉は牛肉の代替財である。あなたが鶏肉の生産者で牛肉の値段が上がっているとき、人々はより多くの鶏肉を求めるようになり、あなたの売り上げは増えることになる。
補完財というのはあなたが通常他の製品と一緒に買う製品のことだ。ガソリンと自動車は補完財だ。コンピュータハードウェアはオペレーティングシステムの補完財だ。
補完財の値段が下がるとき、その製品への需要は増える。たとえば、マイアミへの航空運賃が下がると、マイアミのホテルの客室の需要は増える--それはより多くの人がマイアミへ行くようになり、客室を必要とするからだ。コンピュータが安くなれば、より多くの人がそれを買うようになり、それにはオペレーティングシステムが必要なので、オペレーティングシステムに対する需要が増え、それはオペレーティングシステムの値段が上がるかもしれないことを意味する。
株主にとっての価値を最大化する責任があるはずの多くの大企業が、通常はオープンソースの作業をするプログラマの大きなチームに金を払うという形で、オープンソースソフトウェアのサポートに多額の投資を行っている。そしてこれは補完財の原理によって説明できるのだ。
一般に企業の戦略的な関心は、彼らの補完財の値段を可能な限り低くすることだ。持続しうる理論的な最低価格は「コモディティ価格」である--つまり、区別の付かない商品を提供するたくさんの競合がいる場合の価格だ。
したがって:スマートな企業は彼らの製品の補完財をコモディティ化しようとする。
もしそれができたなら、あなたの製品への需要は増え、あなたは価格を上げ、より多く売ることができる。
ヘッドライン:IBM、オープンソースソフトウェア開発に何百万ドルも使う
神話:彼らがそうしているのは、ルー・ガースナーがGNUマニフェストを読み、自分が実のところ資本主義が嫌いなことに気づいたからだ。
現実:彼らがそうしているのは、IBMがITコンサルティング企業になろうとしているからだ。ITコンサルティングというのはエンタープライズ・ソフトウェアの補完財だ。したがってIBMはエンタープライズ・ソフトウェアをコモディティ化する必要があり、そのための最良の方法はオープンソースを後押しすることなのだ。そして見よ、彼らのコンサルティング部門はこの戦略で大儲けしている。
ヘッドライン:Transmeta、Linuxをハックさせるためにリーナスを雇う。
神話:彼らは単にパブリシティのためにそうしたのだ。これがなければTransmetaについて知ることがあったろうか?
現実:TransmetaはCPU製造業者だ。CPUの自然な補完財はオペレーティングシステムである。TransmetaはOSをコモディティ化したいのだ。
ソフトウェアというのは交換可能ではないのだ。たとえその価格がゼロであっても、Microsoft Officeから切り替えるためのコストはゼロではない。切り替えにかかるコストがゼロになるまで、デスクトップオフィスソフトウェアが本当にコモディティ化されることはない。そしてたとえほんの小さな違いであっても、ソフトウェアパッケージの切り替えを苦痛なものにする。Mozillaが私に必要なすべての機能を備え、ポップアップ広告のもぐら叩きゲームを避けるだけのためにでもそれを使いたいと思っているにもかかわらず、私はAlt+Dでアドレスバーを選択するのにあまりに慣れきってしまっている。ほんの小さな違いでも、あなたはコモディティのステータスを失う。しかし私がIBMコンピュータからハードディスクを引っ張り出して、それをDellコンピュータに突っ込むと、ブーン、システムは完全に出来上がり、元のコンピュータの中にあったときと同じように機能する。

射撃しつつ前進

ときどき何もできないことがある。
確かにオフィスにやってきて、だらだらとし、emailを10秒ごとにチェックし、Webをながめ、アメックスの請求書を支払うというような頭を使わない作業をしたりもする。しかしコードを書くフローの状態に戻ろうとしても、それができない。
ひとたびフロー状態になると、それを維持するのは難しくない。私の一日の多くはこんな感じだ: (1) 仕事にとりかかる。(2) emailをチェックしたり、Webを見たり、そのほかのことをする。(3) 仕事に取りかかる前にランチを取ったほうがいいと判断する。(4) ランチから戻る。(5) emailをチェックしたり、Webを見たり、そのほかのことをする。(6) いい加減はじめたほうがいいと心を決める。(7) emailをチェックしたり、Webを見たり、そのほかのことをする。(8) 本当に始めなきゃいけないと、再び決心する。(9) くそエディタを立ち上げる。(10) ノンストップでコードを書いていると、いつのまにか午後7:30になっている。
ステップ8とステップ9の間のどこかにバグがあるようだ、私は必ずしもこの溝を飛び越えられないからだ。bike trip私にとっては、ただ始めることが唯一困難なことなのだ。静止状態にあるものは、そのまま静止状態に居続けようとする。私の頭の中にはとても重いものがあって、それを加速するのはとんでもなく難しいのだ。しかしひとたびフルスピードで回り始めたなら、それを動かし続けるのに努力は必要ない。
私がイスラエルの落下傘部隊にいたとき、将軍が戦略についての短いスピーチをするために私たちのところに立ち寄った。歩兵戦ではただひとつの戦略がある、と彼は言った: 射撃しつつ前進だ。銃を撃ちながら敵のほうへ進む。射撃によって相手は頭を引っ込めるので、あなたを撃つことができなくなる。
空中戦から海軍の大規模作戦行動までのあらゆる種類の軍事戦略が、この射撃しつつ前進のアイディアに基づいていることに私は気づいた。この射撃しつつ前進の原理が、人生でものごとを成し遂げるときのやり方でもあることに気づくには、さらに15年かかった。あなたは毎日少しずつ前へ進む必要がある。あなたのコードがまずくてバグだらけで誰もほしがらなくても問題じゃない。あなたが前へ進み続けるなら、コンスタントにコードを書き、バグを直し続けるなら、時があなたの味方となる。
ソフトウェア業界の状況をよく見てみるといい。うまくやっているのは大企業に依存するところが最小限で、キャッチアップだとか、再実装だとか、あるいはWindows XPでだけ現れるバグの修正だとかで彼らのすべてのサイクルを使わなくてすむ会社だ。つまずいているのはMicrosoftの将来の方向を占うために紅茶の葉を読むのにあまりに多くの時間を使っている会社だ。
HailstormやSOAPやRDFをサポートするつもり? あなたがそれをサポートしようとしているのは、顧客がそれを必要とするからなのか、それとも誰かがあなたを撃ってきていて、あなたは応戦しなきゃいけないと思っているからなのか?
昨日私にやれたことといえば、FogBUGZのカラースキームを改良することだけだった。それでOKだ。それは絶えず改善され続ける。毎日私たちのソフトウェアは良くなっていき、より多くの顧客を獲得する。それが重要なすべてだ。私たちがOracleサイズの会社になるまでは、私たちはグランドストラテジーについて考える必要はない。私たちがしなければならないのは、ただ毎朝やってきて、どうにかエディタを立ち上げるということだ。

下っ端でも何かを成し遂げる方法

このサイトではソフトウェアマネジメントを扱っている。しかしあなたは経営命令で組織を変える力を持ってないかもしれない。あなたが階級組織の最下層にいる下っ端のプログラマなら、人々にスケジュールやバグデータベースを作るように命令することができないのは明らかだ。そしてあなたがマネージャであったとしても、開発者を管理するのは牧猫するようなもので、違いはそんなに楽しくないことだとわかるだろう。「こうしろ」と言うだけではそうはならないのだ。
戦略 1 実行あるのみ
一人の人間がそれをするだけでプロジェクトをずっと改善できることがたくさんある。デイリービルドするサーバがないって? 作ればいい。あなた自身のマシンを使い、夜間にビルドを作って結果をメールで通知するジョブをスケジュールする。
戦略 2 バイラルマーケティングの力を活用する
ジョエルテストの戦略の多くは、非協力的なチームの中にいる一人の人間にも実行可能だ。そのうちのいくつかは、うまく機能すればチームのほかの人たちにも広まるだろう。
戦略 3 優れた人間を作り出す
改善し、できるようになりたいと思う人々を見つけ、彼らをあなたの味方につけるのだ。ひどいチームであっても、ただすばらしいコードを書いた経験がないだけで頭はいい人間を見つけられる可能性はある。
戦略 4 間抜けを無力化する
ただ彼らのコードに対するバグを報告し続ければいい。あなたがもはやバグを見つけられなくなるまでの数ヶ月間、彼らにはせっせとその作業を続ける以外に選択肢がない。その数ヵ月の間、彼らが他の場所にダメージを与えることはない。
戦略 5 邪魔を避ける
会議室を丸一日予約し、そこでコードを書く。そしてチェックイン攻勢によって、部屋に一人でいるときにあなたがいかに多くの仕事をしたか明らかにする。この次に危機が訪れ、あなたのマネージャが明日までにこれをやるには何が必要かと聞くときに、あなたは何と言えばよいかわかるだろう。
戦略 6 かけがえのないものになる
あなたが本当に優れた貢献者なのでないなら、これらの戦略のどれも機能しない。あなたが良いコードを、しかもたくさん書くのでないなら、あなたはコードを書いているべき時に、ただバグデータベースを怒っていじり回しているばかりだろう。あなたのキャリアにとって、何も達成しないでプロセスばかりにこだわっているという評判を受けることほど致命的なことはない。
私は良い第一印象を与えることが重要なこともわかっていた。それで私は期待されていた通りに、毎日はじめの7時間はコードを書くのに使った。開発チームの他の人からあなたが良く見えるようにするのに、怒濤のごときチェックインほど効果的なものはない。しかし私は家に帰る前のもう一時間を、プロセスの改善のために使った。
あなたは管理する立場にいなくとも、ものごとを改善することはできる。しかしあなたはシーザーの妻である必要がある: 疑惑を招いてはならない。そうでなければあなたは敵を作るだけだろう。

ストラテジーレターIV:ブロートウェアと80/20の神話

正確にはブロートウェアとは何だろうか?The Jargon Fileは悪意に満ちた定義をそれに与えている。「小さな機能に対し割の合わないほど多くのディスクスペースとメモリを要求するソフトウェアのこと。とくにアプリケーションやOSのアップグレードに対して使われる。この言葉とその現象は、Windows/NTの世界で非常に一般的である。」
私はこの人たちは単にWindowsを嫌っているのだと思う。私はWindows 386(1989年)が仮想メモリを備えるようになって以来10年以上、メモリを使い切ったということがない。そしてハードディスクスペースの値段はメガバイトあたり0.0071ドルにまで下落しており、そしてなおも、飛べるようになろうとして木から飛び降りる羊のように、急落し続けている。
そして今日の高性能、低価格なコンピュータが大きなプログラムをロードする時間が、ほんの5年前の小さなプログラムのロード時間より速いことを誰も否定しないと思う。では何が問題なのか?
レジストリの使われてない部分のクリーンアップに気を使うというのは少し強迫神経症気味に違いない。それで私はブロートウェアに心を悩ませているというのは、ソフトウェアの問題というよりは精神衛生の問題じゃないかと思い始めた。
多くのソフトウェア開発者は昔ながらの「80/20」ルールに魅了されている。80%の人々は20%の機能しか使わない、というのは大いに意味があるように見える。それであなたは20%の機能だけ実装すればよく、それでも80%は売れると思い込む。
残念ながら、それは決して同じ20%ではないのだ。みんな異なる機能セットを使っている。
あなたが「ライト版」の製品のマーケティングを始めて、「どうです、軽いでしょう。たった1MBだ。」と人々に言い、彼らはとても喜んで、それが彼らにとって必須の機能を持っているか聞くが、それがないと分かると彼らは買わない。
結論:あなたの戦略が「80/20」なら、あなたはソフトウェアを売るのに問題を抱えることになるだろう。それが現実なのだ。この戦略はソフトウェア業界自体と同じくらい古くからあり、そして単に報われないのだ。いかに多くの即席の会社の経営者たちがそれをうまく行きそうだと考えるかは驚くばかりだ。

ビッグマック 対 裸のシェフ

Fog Creek Softwareがどう成長すべきかについて思いをめぐらせた。私が見つけた最高の教訓はマクドナルドから得たものだった。そう、あのでかいハンバーガーチェーンのことだ。
ビッグマックの秘密は、それはそれほどうまくないのだが、どれもがちょうど同じようにうまくない、ということだ。もしあなたがそれほどうまくない人生を望むなら、あなたには絶対に驚かされることのないビッグマックがある。
ビッグマックのもうひとつの秘密は、あなたのIQは(専門用語で言うと)「大バカ」と「バカ」の間のどこかで十分だということで、それでもあなたは世界中の他のどのビッグマックとも正確に同じ非意外性でビッグマックを作ることができる。
マクドナルドの真の秘伝のソースは膨大な操作マニュアルで、それはすべてのフランチャイズがビックマックを作るときに従わなければならない正確な手順を、驚くほどの詳細さで記述している。
このシステムは、誰でも相当なミスをするものだという前提で作られているが、出てくるハンバーガーは、そのー、いつもと同じで、そしてあなたは毎度フライもいかがですかと聞かれる。
気晴らしに、一連のルールに正確に従っているだけで料理については何も知らないマクドナルドのコックと、キュートなイギリス人の裸のシェフ、ジェイミー・オリバーのような天才を比べてみよう。
裸のシェフは目障りな操作マニュアルなんかには従わない。彼は何も計量しない。彼は料理中に食べ物を乱暴に放り投げる。「ローズマリーをここでちょっと入れましょう、悪いことはないし、懐かしい感じが出ます。」と彼は言う。「これをつぶして。完璧。そこらじゅうにばらまくだけ。」(そう、彼は本当に、それをただそこらじゅうにばらまいているように見える。残念ながら、私がそこらじゅうにばらまこうとしてもうまくいかなかった。) 14秒ほどで、彼は基本的に即興で、ハーブを詰めて焼いたスズキのフィレのロースト、サルサ・ベルデ、ベークドマッシュルームポテト添えという完全なグルメ料理を作った。おいしそー。
あなたが超高収益のレストランを持っていた場合に、あなたはすぐあることに気づくだろう。たとえあなたが毎晩店をいっぱいにし、オードブルで$19、コカコーラで$3.95ふんだくったとしても、一人のシェフにはそんなに多くの料理は作れないので、あなたの収益は自然な限界に達するということだ。そこであなたは別なシェフを雇い、別な町にも支店をいくつかオープンするかもしれない。
スケールの問題を扱う一般的な方法は、何も知らない安いシェフを雇い、それぞれの料理の作り方について、失敗し得ないほど緻密なルールを彼らに与える、というものだ。そのルールに従ってさえいれば、すばらしいグルメ料理が作れる!
問題: それはあんまりうまく機能しない。良いシェフがすることは何百万とあり、それは即興で行われるものだ。
マクドナルドは特定の種類のポテトだけを使い、彼らはそれを世界中で栽培しており、品不足をやり過ごせるように膨大な量があらかじめ切って冷凍保存されている。あらかじめ切って冷凍されているので品質は落ちることになるが、それは確かに一定しており、シェフのスキルを必要としない。実際マクドナルドには一貫した品質で製品が作られるようにするための何百もの仕掛けがあり、その品質が「多少」低いにしても、キッチンにいるのがどんなバカでも差し支えないというほどになっている。
ルールや手続きというのは、何もまずいことがない場合にのみ機能する。様々な「データベース連動Webサイト」コンサルティング会社が過去2年間に急成長し、データベース連動Webサイトを作るための14ステップをアマチュアたちに教えて彼らの同類を増やした(ここにselect文があるね、さあ、Webサイトを作って)。しかし今やドットコムは崩壊し、突然ハイエンドGUIプログラミングとC++のスキルと真のコンピュータサイエンスが要求されるようになり、武器庫にselect文しかないちびっ子は、急すぎるラーニング・カーブに直面して、キャッチアップすることができない。
何がこの物語の教訓だろう? メソドロジーには気をつけろ。それは陰鬱だが誰をもまずまずのレベルのパフォーマンスに引き上げるすばらしい方法だ。しかし同時に、もっと才能のある人々はその制約にイライラする。才能あるシェフが、まさにそのルールが故に、マクドナルドでバーガーを作っていて楽しくないだろうことは、まったく明らかなことに思える。
Fog Creekにとっては何を意味するのだろう? 私たちが大きなコンサルティング会社になろうとしたことはない。私たちはコンサルティングもしているが、長期目標は常に高い収益を上げられるソフトウェア会社になることで、それを達成するために、私たちはソフトウェア収入をコンサルティング仕事で補っている。
重要なことは、最高の人間を雇うことへの執着だ・・・十分優秀な人間が見つけられないなら、小さいままで十分満足だ(1年につき6週間の休暇を使えば、人を見つけるのはそれほど難しくはない)。そして私たちは、すでに雇った人々が十分に学んで新しい人々の教師や指導者となるまでは、成長することを拒む。

ジョエル・テスト

SEMAについて聞いたことがある?かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った!そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。
ジョエル・テスト
1. ソース管理システムを使っているか?
2. 1オペレーションでビルドを行えるか?
3. 毎日ビルドを行うか?
4. 障害票データベースを持っているか?
5. 新しいコードを書くまえにバグを修正するか?
6. 更新可能なスケジュール表を持っているか?
7. 仕様書を持っているか?
8. プログラマは静かな労働環境にあるか?
9. 買える範囲で一番良い開発ツールを使っているか?
10. テスト担当者はいるか?
11. プログラマを採用するときにコードを書かせるか?
12. 「廊下での使い勝手テスト」を行っているか?
12点は完璧で、11点は許せる範囲だ。だが、10点以下だったら君は本当に深刻な問題を抱えていることになる。実際のところ、大半のソフトウェア開発組織は2点か3点の状態で仕事をしている。そして、彼らは本当に助けを必要としている。なぜなら、マイクロソフトのような会社は常に12点の状態でいるのだから。

ストラテジーレターⅢ:もとに戻してくれ!

あなたが人々を競合製品からあなたの製品に乗り換えさせようとするなら、あなたは参入障壁について理解する必要があり、それもあなたが思っているよりずっと良く理解している必要があり、そうでなければ人々は乗り換えず、あなたはテーブルが空くのをただ待ち続けることになるだろう。
Lotus 123という確立した競合がほとんど完全にスプレッドシートのマーケットを独占していた。確かに新しくコンピュータを買うユーザがExcelを使い始めるということもあったが、大部分については、もしMicrosoftがスプレッドシートを売りたければ、人々を乗り換えさせる必要があった。
あなたがその立場にいるとき、あなたのすべき最も重要なことはそれを認めるということだ。
あなたの製品が何らかの点でより優れているなら、あなたが人々を乗り換えさせられるチャンスは十分にある。しかしあなたはそのことについて戦略的に考える必要があり、そして戦略的に考えるというのは当たり前なことより一歩先を考えるということだ。
人々を乗り換えさせる唯一の戦略は、あなたの製品から障害を取り除くことだ。
乗り換えへの障害を取り除くことが、既存のマーケットに入っていくためにあなたがしなければならない最も重要なことだということであり、それはただ1つの障害を除くことがあなたの売り上げを2倍にするからだ。2つ目の障害を取り除けば、あなたは再び売り上げを2倍にする。Microsoftは障害物のリストを見て、そのすべてに取り組んだのだ。
古い独占から新しい独占への移行が起こるときにしばしば見受けられるのは、魔法の「ティッピングポイント」があるということだ:ある朝目を覚ますと、あなたの製品のマーケットシェアは20%ではなく80%になっている。この転換はとても短期間に起こる(VisiCalcから123をへてExcelへ、WordStarからWordPerfectをへてWordへ、Mosaicから NetscapeをへてInternet Explorerへ、dBaseからAccessへ、などなど)。それは通常最後の障害がなくなり、突然誰にとっても乗り換えが理にかなったものとなったために起きる。
Excel4.0のときに起きたティッピングポイントのことを思い起こさせる。そしてそれが起きた最大の理由は、Excel 4.0がLotusのスプレッドシートを保存できる最初のバージョンだったということだ。
そう、聞いたとおり。読めるだけでなく、書けるのだ。人々がExcelに乗り換えるのを妨げていたのは、彼らが一緒に働いている人々が依然としてLotus 123を使っていたことだと分かった。彼らは他の誰も読めないスプレッドシートを作る製品を欲しいとは思わなかったのだ。典型的な鶏と卵問題だ。あなたが会社のほかの人がみな123を使っている中にいる孤独なExcelファンであるなら、あなたがたとえExcelを愛していたとしても、123のエコロジーに参加できるようになるまでは、あなたは乗り換えることができない。
戦略に対する成熟したアプローチは、潜在的な顧客に何か強いるようなことはしないということだ。まだあなたの顧客ですらない人々をロックインしようとするのはいい考えではない。あなたが100%のマーケットシェアを手に入れたら、そのときロックインについて話をしよう。そうなるまでは、あなたが今彼らをロックインしようとするなら、それは早過ぎ、顧客の誰かがあなたのその行動に気づくと、結果的にあなたは彼らを締め出すことになる。誰も将来における自由を抹殺するような製品に乗り換えたいとは思わない。
もちろん、ビジネスマネージャは引き付けを起こすだろう。どうして顧客が我々のサービスをやめやすくする必要があるんだ?そう言うのは近視眼というものだ。彼らはまだあなたの顧客ではないのだ。彼らが顧客になる前にロックインしようとするのは、ただ彼らをロックアウトすることになるだけだ。しかし彼らが気に入らないときにサービスを簡単にやめられるようにすると率直に約束するなら、あなたは突然、さらにひとつの参入障壁を消したことになる。そして私たちが学んできたように、参入障壁をただ1つ消すことでさえ、切り替えに対して劇的な効果を及ぼしうる。そして、やがてはあなたが最後の参入障害を打ち倒したときに、人々はなだれ込み始め、しばらくは人生は素晴らしいものとなるだろう。あなたに対して誰かが同じことをするまでは

ストラテジーレターⅠ:ベン&ジェリー 対 アマゾン

会社を作っている?あなたがしなければならない非常に重要な決断がひとつあって、それはあなたのする他のすべてのことに影響する。あなたがどんなことをするにせよ、あなたは自分がどちらのキャンプに属しているのかを知り、あらゆることをそれに合わせて行う必要があり、そうしなければ災難に見舞われるだろう。
何の決断かって?ゆっくりと有機的に収益を上げながら成長するか、それとも非常に早い成長と大量の資金でビッグバンを起こすかだ。
アマゾンのように実質的には競合が存在しない場合、あなたは「土地収用」戦略によって、つまり、可能な限り早く多くの顧客をつかみ、後の競合たちが大きな参入障壁に直面するようにすることで成功する可能性がある。しかしあなたが確固とした競合がすでに存在する業界に参入しようとする場合は、この土地収用戦略のアイディアは意味を成さない。あなたは自分の顧客ベースを他の競合から乗り換えさせることによって獲得する必要がある。
自然なネットワーク効果とロックインのあるビジネスにあなたが参入しようとしているのなら、そしてそこに確立した競合がいないのであれば、あなたはアマゾンモデルを使ったほうが良く、そうしなければ他の誰かがそれをやり、あなたは足掛かりさえ得られないだろう。
アマゾン型の会社は実際には誰も使えないほどの早さで資金を調達する。それには理由がある。彼らは非常に急いでいるのだ。もし彼らに競合がおらず、ネットワーク効果のあるビジネスをしているのなら、超高速に成長すべきなのだ。一日一日という時間が重要なのだ。
年100%以上のスピードで成長しているとき、企業の価値観を新規採用者に伝授するのは不可能だ。プログラマがマネージャに昇進し、突然昨日採用されたばかりの人間を5人部下につけられたなら、あまり多くのことを教えることはできないだろう。
ある種の会社にはそれでもOKだ。別な会社にとっては企業文化は会社の存在理由の重要な部分である。ベン&ジェリーは創業者の価値観がゆえに存在し、彼らはその文化が広められるよりも早く成長することを拒むだろう。
早く大きくなるというのは、(実際にはそうでなくとも)成功しているという印象を与える。毎週30人が新規に採用されているのを見た先見の明がある従業員は、自分が何か大きなエキサイティングで成功しているものの一部であるように感じる。彼らは12人の従業員と一匹の犬からなる活気のない小さな会社には印象を受けないかもしれない。たとえその活気のない会社が収益を上げており、より良い長く続く会社を作っているのだとしても。
もしあなたがゆっくり有機的に成長するなら、大金があるのはずっと先だ。そのような場合には、その過程自体が報酬となるような仕事環境を作る以外に選択肢はない。それはてんてこ舞いの週80時間労働というわけにはいかないのだ。オフィスは折りたたみテーブルと硬い木の椅子でいっぱいのごちゃごちゃした騒がしい大きなロフトではありえない。あなたは人々にしかるべき休暇を与える必要がある。同僚はただの同僚ではなく、友人である必要がある。職場における社会学とコミュニティが問題となる。マネージャは物のわかった人間で人々の背中からは離れる必要があり、ディルバート的マイクロマネージャであってはならない。
ベン&ジェリー・モデルを使い、十分に賢明であるなら、あなたは成功するだろう。ちょっとしたゴタゴタがあり、いい年と悪い年があるかもしれないが、別な不況に見舞われなければ、あまり多くの金を失うことはないだろう。そもそもはじめからそんなにたくさんつぎ込んではいないからだ。
アマゾンモデルの問題は、みんなが考えるのがアマゾンのことだということだ。そしてアマゾンはたった一つしかないのだ。膨大なベンチャー資金を使いながら、彼らの製品を誰も欲しがらなかったために失敗した他の95%の会社のことを、あなたは考える必要がある。
たぶんあなたにできる最悪のことは、アマゾン型の会社にならなければと決め、それでいてベン&ジェリー型の会社のように行動することだ(常にそのことを否定しながら)。アマゾン型の会社は、それができるときにはいつでも時間を金で置き換えなければならない。
どちらのモデルも機能するが、あなたはどちらか一方を選んでそれを貫くのでなければ、ものごとが不思議とうまくいかなくなり、あなたにはその理由がわからないだろう。

ストラテジーレターⅡ:鶏と卵の問題

同じ労力でWindowsのような1億人のユーザがいるプラットフォームのためのソフトウェアを作れるというのに、BeOSのような一番いいときでも10万人のユーザしかいないプラットフォームのためのソフトウェアを、ほんのわずかでも常識をそなえたソフトウェア開発者が意識的に書くということは考えられない。
だからあなたのビジネスがプラットフォームを作ることであるなら、一般には鶏と卵の問題として知られているものによって苦しめられることになるだろう。その上で走る良いソフトウェアができるまでは誰もあなたのプラットフォームを買おうとはしない、そしてそれが大きなインストールベースを持つようになるまでは、誰もそのためのソフトウェアを書こうとはしない。
スティーブ・ジョブズは実際、鶏と卵の問題を理解せずに2度も出世したのだ。しかしジョブズのように現実歪曲フィールドを自由に操ることのできない私たちは、本気になって熱心に学ぶ必要がある。
Microsoftは個々の商店を訪問して話をする必要がある。「このシステムを使って顧客への請求を行ってください。」すると商店主は「OK!でコストは?」と聞き、Microsoftは「50セント!これは$1に比べればずっと安い!」と言う。それで商店主が「OK。他に何かありますか?」と聞くと、 Microsoftは「ええ、ソフトウェアをセットアップしてシステムを接続し、すべてが機能するようにするのに25万ドルかかります。」と答える。
若い人たちは、Microsoftがマーケティングの力か何かを使って小さいオペレーティングシステムに対するマーケットを支配したためだと考えるかもしれない。全然違う。Microsoftは当時小さな会社だったのだ。マーケティングの力を持っていた会社はDigital Researchのほうで、これは別のオペレーティングシステムを持っていた。ではなぜPC-DOSが3者の競争に勝ったのか?
DOSはバージョン1.0でさえCP/M後方互換モードが組み込みでデザインされていたということだ。それは筋金入りのプログラマたちにINT 21として知られている気の利いた独自の新しいプログラミングインタフェースを持っていただけでなく、CP/Mのプログラミングインタフェースをフルサポートしていた。
これはもう一度言うに値する。WordStarはコードの中の1つのバイトを変えることでDOSに移植された。十分に理解しよう。
ほら。
分かった?
DOSが人気があったのは、それがはじめからソフトウェアを持っていたからだ。そしてそれがソフトウェアを持っていたのは、ティム・パターソンがCP/M互換機能を含めることにしたからであり、それはこの暗黒時代に鶏と卵の問題を分かっている人がいたからなのだ。
驚くのは次のことだ:Windows 95のベータ版のテストでSimCityは動かなかった。Microsoftはそのバグを追いかけ、Windows 95にSimCityを検出するコードを追加した。それがSimCityが実行されているのを見つけると、それはメモリをすぐには開放しない特殊なモードでメモリアロケータを実行するのだ。この強迫的なまでの後方互換性が人々にWindows 95にアップグレードしたいと思わせたのだ。
あなたは鶏と卵の問題をどうやって破るかについて、アイディアをつかみ始めたに違いない:あなたが問題をどう見ているかに応じてトラックいっぱいの鶏か、あるいはトラックいっぱいの卵をもたらす後方互換モードを提供し、あとは座って金をかき集めるのだ。
あなたはどうやってこれを解けるか? Microsoftには見つけられなかった。PayMyBills.com(およびその他の半ダースほどのシリコンバレーの新興企業)は同時に答えを見つけた。後方互換モードを提供すればいいのだ:商店がこのシステムをサポートしないのであれば、その商店に紙の請求書をパロアルトのユニバーシティアベニューに送らせて、大勢の実際の人間がそれを開封してスキャンする。今やあなたはすべての請求書を彼らのWebサイトで見ることができる。
PayMyBills.comはMicrosoftとは違い、彼らのシステムを実際に使う顧客を獲得することができ、すぐに彼らは間抜けなVisa加盟銀行に行ってこう言うことができるからだ。「私は93,400人のお宅の顧客を持っています。私たちと直接ネットワーク接続して月に93,400ドル節約すると言うのはどうです?」 PayMyBills.comは突然とても高収益となり、一方Microsoftは依然として2番目の、たぶんジョージアあたりでサービスを行っている電気事業者から契約を取り付けようともがいている。
結論:あなたが鶏と卵の問題のあるマーケットにいるのなら、あなたはその問題を解く後方互換機能を持ったほうがよく、そうしなければ、うまくいくのに非常に長ーい(たぶん永遠の)時間がかかるだろう。
他にもたくさんの会社が鶏と卵の問題を認識し、立ち向かい、知的な仕方で克服している。

ゲリラ的雇用面接のすすめ

Fog Creek Softwareに採用されるような人材には以下の要素が求められる。
賢くて、
結果に結びつけられる。
これは非常に重要だ。ただこの点さえ思い出せてもらえれば良い。夜布団に入る前に毎晩暗誦して欲しい。我々の欲しているのは「 才能 」に溢れた逸材であり、特定のスキルを持つ技術者ではない。
面接で忘れてはいけない最も重要な点はここにある ―優良な候補者を誤ってはじいてしまう事は不良な候補者を誤採用するよりはずっとマシ― 不良候補者の不手際を修正するために、ゆくゆく多大なる優秀な人々の時間、ひいては会社のコストを犠牲にしなければならなくなる。少しでも不安要素があれば不採用だ。
2番目は候補者が直近で関わっていたプロジェクトについての質問である。
この質問で私が期待しているインプットはひとつ、「情熱」だ。
好意的な返答はこうだ。「そのとき私はチームのみんなを集めて提案書を書き上げて・・・」。対する悪い返答とは「私に出来る事など 何も 無かった。解決不可能な状況でした」といったところか。「 賢くて、結果に結びつけられる 」というキーワードを思い出して欲しい。誰かが 結果に結びつけられる 人かどうかを判断する為には、過去にその人が物事の解決を試みたかどうかを確認してみればいい。
3番目は 解答のない問題 だ。これは楽しめる。この質問ではわざと答えようの無い問題を出して、候補者がどのように対処するかを観察する。
あまり賢くない候補者はイライラしたり機嫌を悪くする。まるで君が火星人か何かのようなまなざしでにらみつけているだろうから、君は助け舟を出してやる必要がある。「たとえば君がロサンゼルスの規模程度の町を創るのであれば、いくつくらいのガソリンスタンドを設置する?」のように。もう少しヒントを与えて、「ガソリンを満タンにするには何分位かかるんだろう」としてもよいかも知れない。これだけ言ってもポカンと口を開けて更なる助け舟を待っているような、賢さのかけらも見受けられない候補者がいるだろう。この類の人達に問題解決能力は存在せず、我々も助けは期待していない。
7番目の「 挑戦的な質問 」につながる。これも楽しい。面接中、君は候補者が完全に100%疑いもなく正しい事を言う事を待つ。そうしたら君は「あれ?ちょっと待ってよ?」と言ってから2分ほど詭弁をふるって完全否定する。 彼らの言っている事が正しいとわかっている事 について議論を仕掛けるのだ。
強い候補者は君を説得する方法を見つけるだろう。カーネギー卿の全ての教えを駆使して君を打ち負かす。「もしかしたらあなたの言っている事を誤解しているのかもしれませんが、・・・」と控えめにアプローチしてくるだろうが、彼らの地盤は譲らない。 採用 だ。
私は常にいつだって必ず面接の最後に5分ほどFog Creekのことを売り込む。これは君が 候補者を採用する気が無かったとしてもとても大切な事だ。もし君が幸運にもすばらしい候補者に出会ったのだとしたら、この時点で君は全てを賭けて彼がFog Creekに入る事を確実にするだろう。だが、もしそれが悪い候補者だったとしても、Fog Creek Softwareについてエキサイトさせて、会社に対して好印象を抱いたまま帰路につかせるようにしたい。こう考えたらいい、彼らは従業員候補であるだけでなく、お客様であり、或いは外部採用担当者であると。もし彼らがFog Creekは仕事をするのに素晴らしい環境であると思えば、友達にも応募を勧めることだろう。
面接とは確固たる理屈に基づくものと言うよりむしろ、抽象的なアートであろう。しかし、もし君が「 賢くて結果に結びつけられる 」という基本を思い出すことが出来れば君の面接はきっとうまく行く。もしも機会があったら同僚に面接時にどんな質問をするのかだとか、期待する回答だとかを聞いてみるといい。レドモンドの16号ビルカフェテリアでは昼食時のこの話題がいつまでも皆のお気に入りだ。

二つの話

よく管理されたハイテク企業と惨憺たるハイテク企業との違いを典型的に示す二つの話を、私自身の経験から紹介したい。その違いはつまるところ、従業員を信頼して仕事を成し遂げさせるか、それともさまよいだして何もかもぶち壊しやしないかとたえず監視し、管理している必要のあるハンバーガー焼きか何かみたいに扱うかの違いだ。
「アプリケーションアーキテクチャ」グループと呼ばれる得体の知れない人たちがどこからか私の仕様について聞きつけ、自分たちはマクロ言語ストラテジーのようなものに責任があると何かの理由で思っていたため関心を持った彼らは、私に仕様を見せるようにと言ってきたのだった。
「あー、これは非常に興味深いね。で、次は?誰が君の仕様を承認するんだ?」
私は笑った。私はマイクロソフトに来てまだ2、3ヶ月にしかならなかったが、誰かが私の仕様を承認する、なんてことがないということはわかっていた。まったく、承認どころか、私の仕様を読む時間すら誰も持ち合わせていない。プログラマたちはコードを書くからもっと仕様をよこせと、毎日私を悩ませる。
一人が、Excelには下線と二重下線があるんだから、誰か三重下線を引くためのマクロを書きたいと思うかもしれない、と言った。ああ確かに。それ以降私は可能な限り外交的に、彼らを無視することにした。
ベン・ワルドマン(現マイクロソフト副社長)率いる私のプログラミングチームは、完全に私をバックアップしてくれており、実際それが必要なすべてだった。というのも、コードを書いていたのは、そしてものごとがどうなされるかについての最終決定権を持っていたのは、プログラミングチームだったからだ。
翌日、アプリケーションアーキテクチャグループが解体された、と言う噂が飛び込んできた。そればかりでなく、グループの各メンバはできる限り離れた別の部署に配属されたのだ。私は彼らから再び何か言われることはなかった。
もちろん私はぶったまげた。Microsoftでは、もしあなたがExcelマクロストラテジーの仕事をしているプログラムマネージャであるなら、たとえあなたが会社に来て6ヵ月に満たなかったとしても、そんなことは問題ではない。あなたはExcelマクロストラテジーの神であり、誰であれ、たとえナンバー6だろうと、あなたの邪魔をすることはできない—以上
これは非常に強いメッセージだ。ひとつには、誰もが自分の仕事により意識的になると言うことだ。彼らは「マネジメントが承認したから」という考えの陰に隠れることはできない、というのもマネジメントは仕様を実際にはよく見ないからだ。マネジメントのすることは、優秀な人材を雇い、何か彼らのする仕事を与えることにつきる。もうひとつは、それが働くのにきわめていい場所だということだ。彼の領分における王になりたくないと思う者がいるだろうか?ソフトウェアはその性質上、より小さなコンポーネントへと簡単に分割していくことができ、したがって責任を人々に分配し、彼らにある領域を所有させることがいつだって可能だ。これがたぶんソフトウェア屋がMicrosoftで働くのが好きな理由なのだ。
その何年か後、オンラインサービスとフリーメールサービスの事業者であるJunoで私は働いていた。このときの経験はMicrosoftの時とまったく逆であった。私には私の下で働くプログラマが二人いたが、私のマネージャは、時にはまったく断りもなしに、私の部下のところへ直接行って彼らに仕事を指示し、私の(限られた)権限をたえず侵害していた。
私のマネージャは、これは気に入らないということに決めた。彼にとってはエゴの問題であった。最初彼はこのページの作業をしていたデザイナのところで悲鳴を上げた(私に断ることもなく)。次に彼は私のところへ来てわめき立てた。そして彼は、私が彼の望むように何でも変更しなければならなかった日々を思い起こさせた。それから彼はこの会社のCEOにそれを見せ、CEOに私の新しいデザインを批判させるというビッグ・ショーを演出した。JunoではCEOでさえ、会社の最下層で行われる作業にも干渉することに非常に満足しており、事実それが標準的な作業手順なのだった。
私がJunoを去った理由だとは言わないが、しかしこれは私がJunoを去った理由を物語ってはいるだろう。それは、いかに熱心に働こうと、いかに頭が切れようと、何かについて責任を与えられていようといまいと、もっとも小さな問題に対してさえ権限がまったくないんだ、という思いだった。あなたのアイディア、トレーニング、頭脳、知性、そのために人々があなたに支払うところのものすべて、みんな無意味なのだ。そしてJunoでは、全従業員の1/4ほどにもなるたくさんのマネージャがいて、そのため彼らにはあらゆる決定に首をつっこむ時間があり、そうやって彼らはコントロールを握っていることを確認するのだ。あなたにものごとを成し遂げるための権限があることを明確にするため、副社長が第9ビルから追い出されたMicrosoftとの対比は際立っている。

ソフトウェアにおける高音域

「最高のプログラマ」を雇うということにそもそも意味があるのか、ということだ。最高のプログラマを求めることが重要な意味を持つほど、プログラマの能力の違いは大きいものなのだろうか?
彼は聖書を引用して言った。ダビデ王が1人いれば、あとは命令をただ実行する兵隊がいればよいのだと。彼の会社の株価はその後ほどなく20ドルから5ドルに下がったので、私たちが提案を受け入れなかったのは幸いだったが、彼らの失敗をダビデ王崇拝のせいにするわけにもいかないだろう。
私が使うデータは、イェール大学のスタンリー・アイゼンスタット教授からもらったものだ。彼は毎年プログラミングの授業CS 323を教えており、この授業ではそれぞれが2週間くらいを要する5つほどのプログラミング課題を行う。課題は大学の授業の題材としては相当本格的で、Unixのコマンドラインシェルを実装するとか、ZLWファイル圧縮ツールを作成するといったことだ。
ここには特に見るべきものはない。そしてそのことがポイントなのだ。仕事のクオリティと費やされた時間との間には相関がないのだ。
少数の優れたプログラマの代わりにたくさんの凡庸なプログラマを使うことの本当の問題は、いかに多くの時間をかけようとも、優れたプログラマが作り出すものが彼らには決して作れないということだ。
アントニオ・サリエリが5人いても、モーツァルトのレクイエムはできないのだ。決して。たとえ100年かけようとも。
凡庸な歌手は最高の歌手がいつでも出している高音域を決して出すことができない。モーツァルトの夜の女王のF6を出せるプリマはごくわずかしかいない。そしてあのF6が出せなければ、夜の女王を演じることはできないのだ。
芸術における高音域が、ソフトウェアでも問題になるのだろうか? 「場合によってはそうなのかもしれないが、私はただ医療廃棄物業界向け会計システムのユーザインタフェースを作っているだけだ」。それは結構。ここで議論しているのはパッケージソフトを作るソフトウェア会社のことであり、そこではコードのクオリティが直接、会社の成功失敗に結びつくのだ。
私たちはこの何年か、すばらしいソフトウェアを、本当の高音域の例をたくさん見てきた。それは凡庸なソフトウェア開発者には決して作ることのできないものだ。
「たいがいの部分はちゃんと動く!」というのにはみんな笑った。そして嬉しくなり、それでみんなWinampに夢中になり、それを使い、友達にも教え、Winampってすごいと思ったのだ。それというのも、連中が「たいがいの部分はちゃんと動く!」とWebサイトに書いたからだ。こういうのって、クールだと思わない?
余分なプログラマを山ほど投入して、Windows Media Playerは高音域が出せたのだろうか? 何千年かけてもだめだろうね。チームに人を追加するほど、「たいがいの部分はちゃんと動く!」とWebサイトに書いたりするのがプロらしくないと考えるうるさ型のいる可能性は高くなるのだ。
「Winamp 3: Winamp 2と同じくらいに新しい!」なんていうのはまず無理だろう。
そして私たちはWinampのそういうところが好きになったのだ。
悪いけど、iPodの話になると止められない。あのカチカチと音を立てる素敵なサムホイール…Appleは余分のお金をかけてiPodの中にスピーカーを入れたが、それはカチカチという音がサムホイールから聞こえるようにするためなのだ。彼らはカチカチという音をヘッドホンから聞こえるようにすることで、何セントか節約することだってできた…何セントか! しかし、あのサムホイールはユーザにコントロールしている感覚を与えてくれる。人々はコントロールしている感覚が好きなのだ。
これは「生産性が10倍」とかいうような話ではない。「平均的な」開発者がすごいソフトウェアを作り出す高音域に達することは決してないのだ。
あいにくとこれは非製品ソフトウェア開発には適用できない。インターナル、インハウスソフトウェアが、ロックスターを雇うのを正当化できるほど重要性を持つことは滅多にない。結婚式で歌ってもらうためにドリー・パートンを雇う人がいないのと同じことだ。だからソフトウェア開発者であれば最も満足できるキャリアはソフトウェア会社なのであって、どこかの銀行のIT部門ではない。
ナンバーツーであったり、製品が「十分に良い」ということではやっていけないかもしれない。際立って良い必要がある。すごく良い製品であるため人々の注意を引かずにはいないというくらいに。本当に才能あるソフトウェア開発者が、注意を引かずにはいない製品に到るための唯一の望みなのだ。

言語をめぐる論争

旧知の友人がメールで質問をしてきた。
「Webサーバ上に構築するエンタープライズアプリケーションを作るためのテクノロジーについて、基本的な疑問がある。君の考えを聞きたい・・・」
「君だったら、.NETとJ2EEで、どちらを選ぶ?」
「Webサーバは何を使うべきだろう(Apache、IIS、その他)? その理由は?」
議論は何年も続いていて、正しい答えを見つけられる見込みもない。これらのプラットフォームには長所やら短所やらがあまりにたくさんあって、それぞれのプラットフォームの支持者が議論に議論を重ねても全然真実に近づかないのだ。しかしその議論がものすごく楽しいだろうことは間違いない。
私が確かに言えることは2つある。
1. 世界中の人々が、.NET、Java、PHPを使ってひっきりなしにWebアプリケーションを作り続けている。彼らの誰も、テクノロジーの選択の故には失敗していない。
2. これらの環境は大きく複雑なものであり、あなたの選ぶ環境での開発を本格的にやった経験があるアーキテクトが少なくとも1人必要となる。そうでなければ間違ったやり方をすることになり、ぐちゃぐちゃになって作り直す羽目になるだろう。
結論としては、どれも同じくらい成功の見込みのあるプラットフォームが3個と半分あり(C#、Java、PHP、それにPythonが半分)、それからほぼ間違いなく大失敗して変更もままならなくなるプラットフォームが数限りなくあり(Lisp、Cで書くISAPI DLL、Perl)、そして陪審員がまだ現れていないのになぜ自分の職を危険にさらすリスクを負うのかわからないプラットフォームかいくつかある(Ruby on Rails)。
現時点では、寮の部屋で2人ではじめるスタートアップや卒論のプロジェクトをRubyに賭けることはできても、誰かが解雇されることになるエンタープライズプロジェクトには適さない。Pythonが半分OKだというのは境界線上にあるからで、「興味深い」選択肢から「安全な」選択肢へと移行しつつある。
C#、Java、PHP、Pythonの中のどれを選んだらいいのだろう? 本当にある違いというのは、あなたがより良く知っているのがどれかということだ。Javaでいくつもの大きなシステム構築に成功しているJavaのグルがあなたのチームにいるのなら、C#よりもJavaで成功する可能性がずっと高いが、それはJavaがより優れた言語だからではなく(Javaの方が劣るが、その違いは問題になるほど大きなものではない)、彼がより詳しいからなのだ。

開発者観察ガイド

あなたがしかるべき場所に広告を出し、素晴らしいインターンシッププログラムを持ち、採用したくなる人たちを面接することができたとしても、優れたプログラマたちの方であなたの所で働きたいと思わなかったとしたら、彼らが来てくれることもない。だから今回は一種の開発者観察ガイドを提供することにしよう。彼らが求めているものが何なのか、彼らが職場で好むこと、嫌うことが何なのか、そして最高の開発者に選ばれるためには何が必要なのかを見ていこう。
オフィスが快適で、明るく、近所の環境が良く、すべてが新しくてきれいなら、彼らは想像していて楽しく感じるだろう。オフィスがゴミゴミしていて、カーペットは貧相、壁にはペンキも塗られておらず、ボートを漕いでいるチームのポスターが張ってあって「チームワーク」と大きな字で書かれていたなら、彼らはディルバートを想像することだろう。
開発者に対して、最高のコンピュータと、少なくとも2台の大きな(21インチ)液晶ディスプレイ(あるいは1台の30インチディスプレイ)を与え、必要な技術書は何でも自由にAmazon.comで注文させるべきだ。これは明らかに生産性を上げるし、そして私たちの今の議論の上でより重要なことは、それが決定的なリクルートツールになるということだ。多くの会社がプログラマを交換可能な歯車、実質タイピストのように扱っており、「なんでそんな大きなモニタがいるんだ? 15インチCRTで十分だろう! 俺が若い頃なんか・・・」と考えているのであればなおさらだ。
組織内でプログラマはどのように扱われているのか?
エースか、それともタイピストか? 会社のマネジメントは似非エンジニアか、それとも元プログラマなのか?
同僚はどんな人たちか?
面接の日にプログラマが大きな注意を払うのは、そこでどんな人に会うかということだ。彼らはいい人だろうか? 彼らは頭がいいだろうか? 私はベル研究所のスピンオフであるBellcoreでサマーインターンをしたことがあるが、会う人会う人がみんな同じことを言っていた。「Bellcoreで働くのが素晴らしいのは、そこにいる人たちなんだ」
あなたが頭のいい人を雇おうとするなら、あなたは彼らがその能力を仕事に適用できるようにしてやる必要がある。マネージャはアドバイスできるし、自由にそうしてかまわないが、その「アドバイス」が命令と受け取られないよう、細心の注意を払う必要がある。それはどんなテクニカルな問題においても、マネジメントは現場の作業者ほどには問題を理解していないからで、優れた人を雇っている場合には特にそうなのだ。
開発者は自らの能力によって雇われ、専門家として遇され、その専門領域に関しては決断させてもらえることを望んでいる。
プログラマが「政治」について文句を言うとき、それが正確に意味していることは、技術面よりも個人的な考えが重視されているということだ。開発者があるプログラミング言語を、それが現在の作業のために最適なものだからではなく、ボスの好みだからという理由で使うように言われることほど、彼らを憤慨させることはない。人々が厳格に能力によって昇進するのでなく、コネによって昇進することほど、彼らを怒らせることはない。組織で彼らより上にいるか、より強いコネを持った人間が要求しているために、技術的に劣った方法でやらなければならないということほど、彼らをムカつかせることはない。
多くの開発者は、自分の働く会社の社会的な価値を気にかける。ソーシャルネットワーキング会社やブログ会社は人々が交流するのを助け、何かを汚染したりはしない(ように見える)ため、人気がある。一方軍需産業や倫理的に問題のある粉飾決算しているような会社はずっと人気がない。
プログラマには彼らが学びたいと思う新しいホットなプログラミング言語を使って基本的に何でも自由に書き直すことを認めるということだ。トレーディングアプリケーションを丸ごとLispで書き直したいって? 勝手にしろ。ただしチーズバーガーは買ってこいよ。
プログラミング言語に何を使うかぜんぜん気にかけていないプログラマもいるが、ほとんどのプログラマはエキサイティングな新しいテクノロジーを使って仕事するチャンスが得られことを望んでいる。今日ではそれはPythonとRuby on Railsだ。3年前はC#で、その前はJavaだった。
私は別に仕事に最高のツールを使うなと言っているわけではないし、2年ごとに「本日のホットな言語」で書き直したりするなと言っているわけでもない。もし開発者が新しい言語やフレームワークやテクノロジーに触れられる方法を見つけられたなら、彼らは楽しくなるということだ。別にビジネスの中心的なアプリケーションを書き直さなくとも、内部的に使われるツールや、あまりクリティカルでない新しいアプリケーションを、学習プロジェクトとして、エキサイティングな新しい言語で書かせることができないか考えてみよう。
多くのプログラマはツケを払うだけのために仕事を探しているわけではない。「デイ・ジョブ」は望んではいない。自分の仕事に意味を見出したいのだ。会社と一体化したいのだ。特に若いプログラマはイデオロギーのある会社に引かれるものだ。オープンソースやフリーソフト運動(この2つは同じものではない)と何らかのつながりを持つ会社は多いが、それは理想主義的な開発者には魅力的なものに映る。別な会社は社会的な目標を掲げたり、社会に貢献しているように受け取られる製品を作ったりしている。
世界中のコンピュータを買う人々は、単にコンピュータを買っているのではなく、その運動に加わっているように感じる。あなたがiPodを買うとき、もちろんあなたは英国の植民地主義に抵抗するガンジーをサポートしているのだ。MacBookの1台1台が、独裁主義と飢えに対する反対の意思表明となるのだ。

子犬だ!

Joel on Softwareが10周年を迎える3月18日をもって私はブログを書くのをやめることにした。
私たちに今必要なのは、「銀の弾丸はない」の主張を繰り返す18,000番目のエッセイではなくて、もっと客観的なものであるように思われる(単なる成功したプロジェクトと失敗したプロジェクトのお話のリストではなくて、測定できるような真実と虚偽に基づいたもの)。18世紀のパンフレットを単に電子的な媒体に焼き直したものではなく、「この2010年において、物を書くということはどのような意味を持つのか」ということに関する最も優れた洞察を反映するようなものが必要なのだ。

ユーザビリティがすべてではない

当時地上で最も人気のあったアプリケーションを例に出した。Napsterのメインウィンドウは、5つの画面を切り替えるのにボタンを使っていた。アフォーダンスと呼ばれるユーザビリティの原理に従えば、ここはボタンでなくタブを使うべきだというのが私の主張だった。
しかしそれでも、Napsterは地上でもっとも人気のあるソフトウェアアプリケーションだった。
私は実際、初期の原稿では「これでわかるのは、ユーザビリティはそれほど重要じゃないってことだ」みたいなことを書いていた。ユーザビリティの本にそんなことが書かれているのも少し妙な話だ。植字工にそのパラグラフを短くする必要があると言われたときにはほっとしたものだ。それで私はその文章をカットすることにした。
しかしそこには(少なくともUIのプロには)恐ろしい一片の真実があった: 人々が本当に欲する何か本当にすごいことをやるアプリケーションであれば、無惨なほど使いにくかったとしてもヒットしてしまうのだ。そして世界で最も簡単に使えるアプリケーションであっても、みんなが望むことを何もしないのであれば失敗することになる。
今日私が話そうと思っているのは、ソフトウェアデザインの問題の次の段階についてだ。UIを正しく作ったなら、次にやるべきことはソーシャルインタフェースのデザインだ。
人の間の仲介をするソフトウェアを書くときには、ユーザビリティをちゃんとさせた後、ソーシャルインタフェースをちゃんとさせる必要がある。そしてソーシャルインタフェースの方がより重要なのだ。世界最高のUIがあったとしても、まずいソーシャルインタフェースを持ったソフトウェアを救うことはできない。
ソーシャルインタフェースについて説明する一番いい方法は、成功例と失敗例をいくつか示すことだと思う。
テキストメッセージングは、ユーザインタフェースがぞっとするものであるにもかかわらず、若者たちの間で非常にポピュラーなものとなっている。ジョークみたいなのは、すべての携帯電話には人間間のコミュニケーションのためのはるかに優れたユーザインタフェースが組み込まれているということだ。そのスグレモノは「電話」と呼ばれている。最初に番号をダイヤルすると、その後はあなたの話すことをすべて相手は聞くことができ、相手の話すことをあなたも聞くことができる。すごくシンプルだ。しかしこれはある人々の間では、「君は素敵だ」と言うだけのために長い数字の列をタイプして指を痛めることになる使いにくいシステムほど人気がない。それはあの長い数字の列でデートができるようになるからであり、自分の発声器官を使って「君は素敵だ」と言う勇気を彼らは持ち合わせていないのだ。
ソーシャルソフトウェアのもたらす副作用というものがある。ソーシャルソフトウェアが振る舞う仕方が、その上にできあがるコミュニティのタイプのかなりの部分を決定づけるのだ。Usenetクライアントには大きなRコマンドがあり、これはエレガントな">"記号を左端につけてオリジナルのメッセージを引用して返信するのに使われる。初期のニュースリーダーではスレッド表示ができなかったので、誰かの議論に一貫したレスポンスをしたいと思ったら、この大きなRコマンドを使って元のメッセージを引用してやる必要があった。このことによって、Usenet特有の議論への応答スタイルが現れることになった。行単位でのあら探しだ。あら探しの好きな人には楽しいのだろうが、読むには値はしない。
ソフトウェアにある小さな違いが、そのソフトウェアの社会的な目的をどのように支え、あるいは支え損なうかというところに、大きな違いをもたらすことになる。ダナ・ボイドはソーシャルネットワークに関する優れた批評「自閉的なソーシャルソフトウェア」を書いており、その中で現在のソーシャルネットワークソフトウェアが人々に自閉症のように振る舞うことを強いていると喝破している。
ソーシャルソフトウェアにおいては、他の人たちの犠牲のもとに利益を得ようとソフトウェアを悪用する人たちが出てくるものだ。野放しにしておけば、経済学者たちが「共有地の悲劇」と呼ぶ状態になる。
ユーザインタフェースデザインの目的はユーザが成功するのを助けることにあるのだが、ソーシャルインタフェースデザインでは、ユーザの中に失敗する人が出ようとも、グループの成功を助けることが目的となるのだ。
FogBugzにはバグトラッキングが実際に行われるようにするためのたくさんの機能と、さらに多くの非機能的な要素がある。私たちは、以前のバグトラッキングソフトウェアが全然使われていなかったという話を顧客から何度も聞かされている。それらのソフトが人々の一緒に働く仕方に合っていなかったためだ。しかし彼らがFogBugzを導入すると、みんな使い始め、常用するようになり、彼らが一緒に働く仕方が変わったという。私はFogBugzが実際に使われていることを知っており、それは新しいバージョンを出したときのアップグレード率が非常に高いからだ。これはFogBugzが単なるシェルフウェアでないことを示している。ライセンスをすでにたくさん買っている顧客でさえ、追加のライセンスを求めて繰り返し戻ってくる。それはFogBugzが組織の中で広まり、実際に使われているためであり、これは私が本当に誇りに思っていることだ。チームで使われるソフトウェアというのは定着するのに失敗することが多い。それはチームのみんなが仕事の仕方を同時に変える必要があるためで、それがまずありそうにないということは、文化人類学者が教えてくれるだろう。その理由により、FogBugzでは多くのデザイン上の決定が、1人で使っても有用であるようになされている。そしてチームの他のメンバにもだんだんと広まっていくのを促すようにデザインされた機能がたくさん組込まれている。
ソーシャルインタフェースデザインというのはまだ発展の初期の段階にある。私はこのテーマについての本を見たことがないし、この分野について研究している人もごくわずかしかいない。そしてソーシャルインタフェースデザインに関する系統立った学問というのもできていない。ユーザビリティデザインの歴史の初期において、ソフトウェア会社はエルゴノミクスの専門家や人的要因に関する専門家を、使いやすい製品のデザインのために雇っていた。エルゴノミクスの専門家は机の適切な高さについては知っていたが、ファイルシステムのためのGUIをどうデザインしたらいいかは知らなかった。そして新しい分野が生まれた。ユーザインタフェースデザインの分野が独立した一個の分野として確立し、一貫性とか、アフォーダンスとか、フィードバックといった概念を解明していった。これらはUIデザインの科学の土台となっている。
次の10年には、ソフトウェア会社は文化人類学や民族誌を学んだ人々をソーシャルインタフェースデザインの仕事のために雇うようになると思う。ユーザビリティラボを作る代わりに、彼らが現場に出て行って民族誌を書くのだ。そしてソーシャルインタフェースデザインの新しい原理が見出されることを願っている。それはきっとすばらしいだろうと思う・・・1980年代におけるユーザインタフェースデザインのように、きっと楽しいものだろう・・・だから目を離さないでいよう!

ラクダとおもちゃのアヒル

あなたの次なる大きな疑問は、「このソフトの値段をいくらにしたらいいんだろう?」ということだ。専門家に聞いてみても、どうもわからないようだ。価格付けというのは暗くて深い謎なんだ、と彼らは言う。ソフトウェア会社が犯す最大の間違いは、あまりに安くして十分な収入が得られず、ビジネスから脱落するというものだ。それよりもさらに大きな間違いは、そう、最大の間違いよりももっと大きな間違いは、値段を高くしすぎて十分な数の顧客が得られず、ビジネスから脱落するというものだ。
これで50ドルと400ドルの間の任意の価格について、その価格でソフトウェアを買う人の数がわかるようになった。私たちが今手にしたのは、古典的な需要曲線で、需要曲線というのは常に右肩下がりになる。それは値段を高くすればするほど、そのソフトウェアを買おうと思う人は少なくなるからだ。
だめだめ。本数を最大化しようとするのではなく、収益を最大化するのだ。
収益を計算してみることにしよう。
これはほんとにクールだ。私たちはソフトウェア価格付け問題の解を、今まさに見出そうとしているところだ。すごく興奮するね!
私がこんなに興奮している理由は、価格に対する利益をプロットしていけば、真ん中に大きなこぶのある素敵な曲線が得られるからだ! そして私たちはそのこぶが何を意味しているのかわかっている! こぶは極大点を意味するのだ! あるいはラクダを意味することもある。でも今の場合は極大点だ!
399ドルと220ドルの差、つまり179ドルは消費者余剰と呼ばれている。これはお金持ちの消費者たちが購入によって余分に得る価値であり、彼らはそれがなくとも気にはしなかったのだ。
セグメント化というのは、顧客を払える金額によってグループ分けすることによって、それぞれの顧客から最大限の消費者余剰を引き出すことだ。聖なるセグメント、バットマンよ。もしそれぞれの顧客から支払える最大価格を教えてもらい、その値段で売ることができたなら、どれくらい儲けられるだろう?
ソフトウェアの世界では、「プロフェッショナル」版と呼ばれるバージョンを作り、別なバージョンは「ホーム」版と呼んで、取るに足らない違いをつけて売るという方法がある。「Windows XP Home Edition」を仕事で使うことなど考えられない企業の購買担当者(これもまた、自分の金を使っているのでない人々だ)がプロ版を買ってくれるのを当てにするのだ。仕事にホームエディションだって? パジャマで出社するみたいだ! オェッ!
難しい部分は、私が今言ったことはすべて、ある意味間違っているということだ。
このセグメント化のビジネスについて、私がやったことを逆から見てみるとどうだろう? 人のことをひどい扱いをしているってことだ。人々は公正な価格を支払っているのだと感じたいものだ。
セグメント化は「消費者余剰を掴む」ツールとして有用であるにしても、製品の長期的なイメージに対してはネガティブな結果をもたらすことになる。たくさんの小さなソフトウェアベンダが、クーポンやディスカウントや複数バージョンや階層を付けるのをやめたときに、収入が増加し、価格に文句を言う顧客が少なくなるのを経験している。
「人々がどれだけ払うつもりがあるかはどうしたらわかるんだ?」
その通り。
そこが問題なのだ。
あなたは需要曲線がどんなものになるのか本当に知ることはできないのだ。
需要曲線が右肩下がりであると仮定したのは、単に「フレディがあるスニーカーを130ドルで買うなら、彼は間違いなく同じスニーカーを20ドルでも買うだろう」というような議論によってだ。いいよね? ハッ! フレディがアメリカのティーンエージャーでなけりゃあね! アメリカのティーンエージャーは死んでも20ドルのスニーカーなんて履かない。それは言ってみれば、死刑宣告されるようなものだ。たった20ドルのスニーカーを履いているって? 学校でかい?

ダクトテーププログラマ

ジェイミー・ザウィンスキーは私が「ダクトテーププログラマ」と呼ぶ人間だ。私は大いなる敬意をもってそう呼んでいる。彼は未来を作るために熱心に働き、みんなの役に立つものを生み出す。ゴーカートを作る開発チームには是非欲しい人間だ。彼のお気に入りの道具はダクトテープとWE-40で、時速100キロで丘をガタガタ駆け下りている真っ最中にそれを見事に使いこなす。同じ頃他のプログラマたちはと言えば、まだスタートラインにいて、チタンにしようか、それともボーイング787ドリームライナーで使われている宇宙時代の超合金にしようかと議論している。
私がダクトテーププログラマを好きな理由を説明しよう。チームで仕事していると、忙しくコードを書いているときに、誰かがコーヒーマグ片手にやってくることがある。そしてマルチスレッドCOMアパートメントを使えばプログラムのキラメキ度が34%上がるみたいなことを言う。……なに、そんなに難しくはないよ、テンプレートをたくさん書いてあるので、平均で4個の引数を取るテンプレートを17個多重継承してやるだけでよく、関数の本体なんてほとんど書く必要もない。
ダクトテーププログラマであれば「多重継承は最低だ。変なもの使うな。やめとけ」と言うのを躊躇しない。
他の人たちは、多重継承やテンプレートやCOMやマルチスレッドなんかを動かすために必要なものを頭に入れておくことができないマヌケに見られるのを怖れて何も言えずにいる。それでアーキテクチャ宇宙飛行士たちが繰り出してくるイカレタ流行りものには何でもおとなしくつきあうことになる。
ザウィンスキーはNetscapeでのことをこう話している。「製品を予定通りにリリースすることを可能にしたのは、C++やマルチスレッドを使わないという決断だった」
それに対してザウィンスキーは答えている。「ああ、リリースできなきゃ意味がない! 後で書き直してコードをきれいにすりゃいいんだよ。3度目にはすっかりきれいになっているだろう。でもそれは肝心なところじゃない。我々がそこにいるのはコードを書くためではなく、製品を世に出すためなんだ」
彼は私のヒーローだ。
ダクトテーププログラマは現実的だ。ザウィンスキーはリチャード・ガブリエルの“Worse is Better”(悪い方がよい)という考えを世に広めた。みんなが手にしている50%の出来の解法は、ラボの中でいつまでも磨きをかけられていてみんなの手に届くことのない99%の出来の解法よりも、多くの問題を解き生き長らえることになる。実際にリリースされるということは機能なのだ。これは非常に重要な機能であり、あなたの製品はこの機能を備えている必要がある。
凡庸なプログラマがこのことで受け身なのは、その超込み入ったコードを書けないと言いたくないためで、チームのいじめっ子たちが邪悪なるC++テンプレートアーキテクチャをばらまくに任せているのだが、それはそうしないと、そのスポックならOKかもしれないプログラミングテクニックを使えるほど自分は頭が良くないことを認めなければならないからだ。ダクトテーププログラマであればどう思われるかなんてこれっぽっちも気にかけない。彼らは基本的でシンプルな簡単に使えるツールにこだわり、余った脳力はユーザにとって有用な機能をもっと作るために使う。
ひとつ注意しなければならないのは、ダクトテーププログラマというのがソフトウェアの世界におけるイケメンだということだ……息を飲むほどいかした若者で、ベッドから起き出すと、髭も剃らず、髪もとかさず、歯も磨かずに、昨日と同じ汚れた服のまま地下鉄に乗り、それでいて美しい。それが彼らの地なのだ。しかし友よ、我々はといえば髪をとかさずには表にも出られない。子供たちが怖がるだろうから。彼らのように美しくはないのだ。ダクトテーププログラマはあの芸当をやってのけるための才能をたんと持ち合わせている必要がある。製品をリリースできる優れたプログラマだから、我々は彼らがユニットテストを書かないことも大目に見る。あるいは彼らが32ビット節約するためにリンクリストのnextポインタとprevポインタをxorして1つのDWORDに格納しようとも。彼らは十分美しく、十分頭が良く、それをやってのけられるのだから。

プログラムマネージャになるには

優れたプログラムマネージャを持つことは本当に良いソフトウェアを作るための秘訣の一つだ。あなたのところには多分いないだろう。こういう人はほとんどのチームにはいないからだ。
人月の神話問題を、最上位の関数を書く超一流の上級プログラマを一人置いて、低いレベルの関数を必要に応じて下級の単純労働プログラマのチームに書かせることで解決しようとした最初の人でもあった。彼らはこの最上位の関数を書くプログラマのポジションをプログラムマネージャと呼んだ。シモニーは確かに頭が良かったけど、このアイデアはそれほどでもなかった。誰も下級の単純労働プログラマなんてものにはなりたくなかっただろう。
経験から言うと、だいたい4人のプログラマにつき1人のプログラ厶マネージャが必要になる。仕事を分割するのが難しいなら、これはマイク・コンテから学んだことなのだけど、製品をユーザーがやることの種類によって分けるのも一つの方法だ。
最初に私がしなければならなったのは、顧客が何を求めているのかを把握することだった。そこで私は同じことを毎回聞いているせいで退屈になるまで、できるかぎり多くのユーザーと話してみた。それから、多くの時間を使って開発チームと話し合い、18ヶ月のリリースサイクルの間に実装できて、かつ合理的なものは何なのかを探り出そうとした。またVisual Basicチームともたくさんの時間を費して打ち合わせ、彼らがExcel上で使える、私達のマクロ言語のためのコンパイラやコードエディタやダイアログボックスエディタを用意できることを確かめた。
次のステップはヴィジョン・ステートメントを書くことだった。これは大まかな内容の文書で、「このようにしてVisual BasicはExcel上で機能する予定です。マクロのサンプルをいくつか挙げると、こんな感じになってます。それから、これらが作らなくてはならない主な機能です。それでこれはこのようにしてユーザーの問題を解決します」というようなことを書くものだ。この文書に対してあまり反対が出なかったので、今度はもっと詳細な仕様書を作った。これは、製品の各部がユーザーにどのように見えるのかを、最も細かい部分にいたるまで説明するものだ。
プログラムマネージャは、開発チームがどのように機能を内部で実装するのかには関わらないのだ。私は開発チームのトップだったベン・ウォルドマンにこの仕様書を章ごとに送り、そしてウォルドマンのチームは腰をおろして、これを実現するために内部で何をすればいいのかを考える。
率直に言えば、私はどんなことについても全く分かっていなかった。大学を出たてで、コードを書いたり、テストしたり、ドキュメントを書いたり、製品のマーケティングをしたり、ユーザビリティテストを行ったりするだけの経験がなかった。幸運なことに、マイクロソフトのこの各ポジションには経験豊かなグルがいた。私は彼らから今日私が知っていることを全て教えてもらったのだ。しかも、彼らはすばらしい製品を作り出すという本物の仕事をやっていた。
仕様書ができあがるとすぐに開発チームが本腰をあげて動き出した。私は次の二つのことに責任を負っていた: デザインに関して出てきた疑問点を全て解決することと、開発チームの代わりに他の全てのチームと話し合っておくことだ。私はテスターと会って機能がどう動くのかを説明し、あらゆる部分をテストするためのプラン作りに協力した。
プログラムマネージャはたくさんの会議に出席するけど、実のところ、仕様書を除いてはあまり多くを生み出さない。だからこそ、大学出たての未熟者であった私でもこの仕事が勤まったのだ。プログラムマネージャの仕事をこなすのに、14年の経験を積んだベテランプログラマとなる必要はない(むしろ14年のプログラミング経験があると、ユーザーの代弁者となるにはちょっと多くを知りすぎている感がある)。
プログラムマネージャはシンプルでユーザーにとって理解しやすいものを望み、また、心を読んだように反応してくれるインターフェイスとか30インチもあるのにポケットぴったり収まるスクリーンとかに重点を置く。一方で開発者は何か取るに足らないものをコードに実装したがり、それに加えてコマンドラインのインターフェイス(「一体こいつのどこが使えないって言うんだい?」)とPythonバインディングをつけたがる。
議論がちゃんとした根拠に基づいて紳士的になされるようにするためには、プログラムマネージャと開発者達が対等であることが絶対に必要だ。もし、開発者がプログラムマネージャの下の立場だと、議論のどこかでプロジェクトマネージャは何もかもに嫌気がさして、「わかった。もう議論は十分だ。では、このことは私の案でやることとする」と言って議論を終わらせてしまうだろう。もし両者が対等なら、こんなことは絶対に起こらない。これはちょっと法廷に似ている。どちらの弁護士も裁判官を兼任することは許されず、「真実は対等な者同士の議論を通じて明らかになる」という原理に従って事を進めていく。どちらの側にも不公平なアドバンテージがあたえられてないときにのみ議論は公平なものになるのだ。
プログラマをプログラムマネージャの下においてはならないんだ。つまりこのことは、とりわけ開発チームのリーダーやCTOやCEOは機能仕様書を書いてはならないということを意味している。
プログラムマネージャにプログラマを納得させる責任を負わせることになるのだ。というのも、どこかの時点でプログラマが議論をあきらめて何であれ自分がやりたいようにしだすかもしれないからだ。だから、プログラムマネージャとして有能でありたいなら(a)正しい意見を持ち、さらに(b)プログラマ達の尊敬を勝ち得なければならない。でなければ、彼らはあなたの意見の正しさを認めてはくれないだろう。
あなたがプログラムマネージャなら、立派にコーディングできるようになることが尊敬を得ることにつながる。これは不公平なことだと言える。だってプログラムマネージャはコードを書かないことになっているのだから。しかし、プログラマはコードが書けない連中よりも書ける人の方をはるかに尊敬する。たとえ、そのコードが書けない人がどれだけ賢い人物であったとしてもね。もちろん、コードが書けなくても有能なプログラムマネージャにはなれる。しかしその場合、プログラミングチームの尊敬を集めることの負担はもっと重くなる。
仕様書がお役所じみた形式的ペーパーワークのモニュメントみたいになっている開発チームが世の中にたくさんあるおかげで、仕様書を書かないということを基礎とする、ありとあらゆる開発手法が生みだされている。そういう人たちは見当違いのことをしている。機能仕様書は迅速な開発のかなめとも言うべきものなのだ。なぜなら仕様書を書くことで、コードを書く前にデザインの案を素早く次々と検討することができるからだ。コードに比べれば、仕様書を直すのは影響が小さい。しかも仕様書を書くとなれば、頭の中でははっきり掴めていると思っているデザインを現実にじっくりと考えなければならなくなり、そのデザインの欠点も素早く見付けられるようになる。それでさらに多くのデザインを次々検討できるようになる。

開発抽象化レイヤ

若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。
過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。
いったいどんなプログラムを書いているのか。完璧で、美しく、エレガントで、バグがない。ユーザインタフェースはユーザの思考プロセスをそのまま形にしたようなものであり、プログラマーズ・カフェでそれを見た人たちはユーザインタフェースがあることに気づかないくらいだった。まったく素晴らしい作品だった。
仲間たちからのフィードバックに励まされ、彼は会社を立ち上げて注文を取り始めた。
慎み深さから見栄を張ることもできないが、ひと月もすると彼の銀行口座の状態はあまり芳しくなくなってきた。
何ヶ月かが過ぎて、彼の経済状況は危険になりはじめた。彼の犬は彼を悲しげに見つめ、何が悪いのかは分からないが、彼の顔が以前より幾分やつれているのには気づいていた。友達と出かける元気もなく、底をついている食料を補充するために買物に行くこともなく、風呂に入ろうとさえしなかった。
大企業というのはいつまでも恨みを抱いているものではない。彼らは才能を認識し、彼を喜んで高い給料で再び雇い入れた。すぐに彼の様子は良くなって、新しい服も買い、昔の自信を取り戻した。しかしどこかが違っていた。何かが欠けていた――あの目の輝きだ。自分の運命の主になるという望みを、彼は失ってしまったのだ。
ソフトウェア開発者が「マーケティング」と言う時は、単にビジネス関係のことすべてを指している。つまりソフトウェアを作って売ることについて、彼らが理解していない部分すべてだ。
プログラマの作業しているレベル(たとえばEmacsの上)というのは、ビジネスを支えるためにはあまりに抽象化されている。開発抽象化レイヤで作業している開発者には、実装レイヤ――開発者のコードを製品へと変える組織――が必要だ。ドリー・パートンは「素敵な歌を歌う」レイヤで仕事しているが、彼女も膨大な実装レイヤを必要としている。レコードの制作、コンサートホールの予約、チケット販売、オーディオ装置の設置、レコードのプロモーション、ロイヤリティの回収。
抽象化の存在意義は、プログラマの日々の活動(設計し、コードを書き、コードをチェックインし、デバッグし、といったこと)がソフトウェア製品を作り、マーケットへと届けるのに必要なすべてだという幻想を作り出すことにある。これは私がこのエッセイで伝えたい最も重要なポイントにつながっている:
ソフトウェアチームのマネージャの優先度第一の仕事は、開発抽象化レイヤを構築することである。
多くの新米のソフトウェアマネージャはこの点を理解していない。彼らがいつも考えているのは、ハリウッド映画を見て覚えた伝統的な命令統治型の管理だ。
命令統治型では、マネージャ/リーダーがビジネスがどこへ向かうべきか決め、部下の将校たちに適切な命令を下し、ビジネスを推し進める。一方それぞれの将校たちはタスクをより小さな部分へと分割し、部下たちに実行を命令ずる。これが組織図を上から下へと、底辺にいて実際の作業をする人間に行き着くまで続いていく。このモデルでは、プログラマは機械の歯車であり、マネジメントの命令の一部を実行するタイピストにすぎない。
開発抽象化レイヤをはんぱでなく強力なモーターを積んだ美しく大きなヨットだと考えるといい。申し分なく整備されている。当たり前のようにグルメ料理が振舞われる。客室には日に2度ルームサービスがある。航海図はつねにアップデートされている。GPSとレーダーはいつも機能しており、壊れた時には予備がデッキの下にある。ブリッジに立つあなたの元には、スピードと、方角と、それにランチをツナにしようかサーモンにしようかということしか考えていないプログラマたちがいる。一方デッキの下では、すべてがうまく動き続けるよう、糊のきいた白いユニフォームを着たプロフェッショナルたちの大きなチームが、静かにつま先立ちで走り回っている。
ソフトウェア会社におけるマネジメントの主たる責務は、プログラマのための抽象化を作り出すことだ。我々はヨットを造る。我々はヨットを保守する。我々こそヨットである。しかしヨットの舵取りはしない。すべてはプログラマのために漏れのない抽象化を提供するためなのだ。そしてそれはすべて、プログラマたちが素晴らしいプログラムを作り、そのプログラムから恩恵を受ける顧客の元へと送り届けられるようにするためなのだ。
その反対の極端にあるのが、元プログラマの起こした典型的なソフトウェア会社だ。そういった会社は見つけ出すのが難しいが、それは多くの場合、彼らが静かに、どこかの屋根裏でコードを磨き上げているからで、誰にも見つけられることなく、すごいRubyでの書き換えをしたあと、静かに忘却の彼方へと消えていく。彼らの地を揺るがすようなリファクタリングされたコードは、どうしたものか人々に認められなかったのだ。
マネジメントの主たる責務は、ソフトウェア会社がコードを書くことで運営できるのだという幻想を作り出すことだ。なぜならそれがプログラマのしていることだからだ。プログラマがセールスでもグラフィックデザインでもシステム管理でも料理でもうまくやれるのならそれは素晴らしいことだが、あまり現実的ではない。ブタに泳ぎ方を教えようとするようなものだ。時間を無駄にするだけで、ブタの方こそいい迷惑だ。
ドリー・パートンがマイクロホンの接続の仕方を知っていることを誰も期待していない。マネージャや、ミュージシャンや、レコーディング技術者や、レコード会社や、公演マネージャや、ヘアメイクや、広報担当者が彼女の後ろにはいて、ただ彼女が歌うことが、何百万もの人々が彼女の歌を聴くために必要なすべてだという抽象化を作り出している。サポートスタッフとマネジメントは、ドリー・パートンを実現するために、可能な限り完全な抽象化を作り出そうと最善を尽くしている。ドリーが私のために歌っているという最高の幻想を作り出すために。彼女の歌がすべてだ。iPodで彼女の歌を聴く時、それを可能にするために膨大なインフラが必要となるが、インフラのなしえる最善のことは、完全に見えなくなるということだ。そうしてドリー・パートンが私のために個人的に歌ってくれているという、漏れのない抽象化を提供するのだ。

一体化マネジメント法

チーム全員を同じ方向に進ませようとするとき、指揮統制マネジメントも入門経済学マネジメントもハイテク・知識指向のチームにおいては無様に失敗することを見てきた。
残るテクニックは、私が一体化法と呼んでいるものだ。この方法で目指すのは、みんなをあなたが達成しようとしているゴールと一体にさせることだ。これは前に挙げた方法とくらべてずっとトリッキーで、うまくやるにはある種の深い対人スキルが要求される。しかしそれを正しくやれたなら、これは他の方法よりも良く機能する。
一体化法マネージャには、あらゆる社会的スキルを駆使し、従業員たちを組織のゴールと一体化させることが求められる。それによって彼らは強く動機づけられる。それから彼らが正しい方向に舵を切ることができるよう、彼らが必要とする情報を与えなければならない。
私がとても満足している方法は、食事を一緒にすることだ。私は必ず昼食を同僚たちとともにするようにしてきた。Fog Creekでは毎日チーム全員にケータリングのランチが振る舞われ、大きなテーブルで一緒に食べている。これは会社が家族のように感じられるようにする上で言葉にできないくらい大きな効果がある。少なくとも私はそう思っている。6年間で会社を辞めた人は1人もいない。
一般に、一体化マネジメントでは家族のように感じられる結束したチームを作ることが必要とされる。それによって同僚たちに対する誠実さと責任感をみんなが持つようになる。
情報を共有することの要点は、状況が変わった場合でもブレットがFog Creekにとって正しいことをしてくれるということだ。出荷日が4月より何日前になるかに応じて金を払うと提示することでブレットを動かそうとしたなら、彼のインセンティブは既存のバグだらけの開発ビルドを今晩リリースする、ということになるだろう。指揮統制を使い、言った通りのスケジュールでバグなしのコードを出荷しろと命じたなら、彼はやってのけるかもしれないが、仕事が嫌になって辞めてしまうだろう。
マネージャの数だけマネジメントのスタイルが存在する。私は主要な3つのスタイルを示した。機能不全なスタイルを2つと、難しいが機能的なスタイルを1つだ。しかし本当のことを言えば、多くの開発現場では、どちらかというとアドホックな、日により人により変わる「何でもあり」の方法でマネジメントされている。

Fog Creek Softwareマネジメントトレーニングプログラム

私は10代の頃、こんな風にしてオラニムパン工場の夜間シフトの動かし方を覚えた。
ユセフは一見関係なさそうな煙突の小さなノブを右に1度ほど回す。それは理にかなってないし、彼自身なぜそれでうまく行くのか説明できないのだが、実際うまく行くのだ。問題は即座に解決してすぐに完璧なパンが出てきはじめる。80フィートのトンネルになっているオーブン内部の温度と湿度の間の複雑な関係について本当に理解できるようになるには、さらに2年くらいかかった。しかしユセフのように問題を解決できるようになるまでには、たぶん10年以上かかるだろう。
パン工場のあらゆる仕事をして一年かそこらが過ぎたとき、自分の率いているクルーたちから信頼されるようになる。それはあなたが彼らの仕事をやれることをみんな知っているからだ。ほかの誰も理解していないような仕方で、パン工場を完全かつ包括的に理解している。良いマネージャと悪いマネージャを目にする機会があり、うまくいかなくなる可能性のあるさまざまなことについて経験を積み、それをどう直すか(そしてどう直さずに済ますか)を見てきた。そうやって毎晩何十万というパンを製造する5000万ドルの工場の運転を委ねることのできる人間となる。
これまでは、私たちが採用するのはほとんどがプログラマだった。それは始めだったからだが、しかし次世代のマネージャを採用しはじめる必要もある。
プログラマをマネージャに昇進させることにまずいことは何もないのだが、マネジメントはプログラミングとは異なる仕事であり、異なるスキルが必要になる。優れた開発者の多くは、マネージャとしてはひどいものであり、誰かをその人が好きで上手くやれる職から、嫌いで上手くやれない職へと昇進させるのはばかげている。私たちはプログラマが給与水準を上げるためにマネジメントに移行しなくとも済む明確なキャリアパスを計画している。
私たちが今考えているのは、新しい世代のリーダーを一から鍛え上げるということだ。
そのために、私たちは実験的な新しいプログラムである、Fog Creekソフトウェアマネジメントトレーニングプログラムを立ち上げようとしている。
プログラムの趣旨はFog Creekの新しい世代のリーダーを育てるということだが、しかしこのプログラムはあらゆるハイテク企業やハイテクチームを率い、運営し、立ち上げるためのいい準備になるだろう。プログラムが期待通り成功すれば、長い目では、私たち自身の目的に必要なよりも2倍の卒業生が送り出され、彼らは自分の会社を立ち上げたり、この業界の別な会社で高い地位を得たり、大学に戻って研究を続けることになるだろう。いずれにせよ、これは自分をプログラマとは思っていない野心のある頭のいいギークたちに素晴らしいチャンスになると思う。

指揮統制マネジメント法

フリードリヒ大王 「兵士は想像できるどのような危険よりも司令官のことを恐れているべきだ・・・善意によって普通の兵士をそのような危険に立ち向かう気にさせることはできない。兵士はただ恐怖によってのみ、そうするのだ」
指揮統制によるマネジメントは軍隊におけるマネジメントを元にしている。
マネージャたちがそういうテクニックを使うのは、実際に軍隊でそう学んだためだ。封建的な家庭や地域で育ったために、人を従わせるにはそうするのが自然なやり方なのだと思っている人たちもいる。単にもっとましなやり方を知らないという人たちもいる。ほら、軍隊でうまくいってたんだから、インターネットベンチャーでも上手くいくって!
ソフトウェア開発チームではみんな違ったことをやっているので、マイクロマネジメントしたいと思ったなら、ヒットアンドランマネジメントにならざるを得ない。つまり、1人の開発者をマイクロマネジメントして猛烈に働かせ、それから突如その開発者の前から何週間も消えて、その間は他の開発者たちをマイクロマネジメントするのだ。ヒットアンドランマネジメントの問題は、自分の決定がなぜうまくいかないのか理解したり、軌道修正したりできるほど長くその場に留まらないことにある。
ハイテク企業では「リーダー」よりも個々の貢献者の方が常に多くの情報を持っていることで、決断に適した位置にいるのは彼らの方なのだ。2人の開発者が最適な画像圧縮法について2時間議論しているところへボスがふらっとやってきたというとき、この場で一番情報を持っていないのはボスであり、したがって技術的な決断を一番してもらいたくない人間がボスなのだ。
指揮統制がチーム運営方法としてそんなにまずいやり方であるなら、どうして軍隊はそうしているのだろう?
何人かは地雷を踏んで死ぬことになるだろうが、しかしそれはより大きな益のためにしなければならないことなのだ。
問題は、理性的な兵士はそのような状況で突撃しようとはしないことだ。個々の兵士にはずるをすることに対するものすごく大きなインセンティブがある。
生きるか死ぬかという状況において、軍隊は号令ひとつで兵士が自殺的な命令にでも従うことを必要とする。兵士というのは、ソフトウェア会社なんかではまったく必要とならないくらい従順であるようプログラムされている必要があるのだ。
言い換えると、軍隊が指揮統制を使うのは、それが18歳の若者に地雷原の中を突撃させるための唯一の方法だからであって、あらゆる状況で最善のマネジメント法だからではない。

入門経済学マネジメント法

私は「入門経済学」(Econ 101)という言葉を皮肉で使っている。アメリカ人以外の読者のために説明すると、アメリカの大学では"101"という番号のついた授業があって、これはそれぞれの分野の入門的な授業となっている。入門経済学マネジメントは、経済学をちょっとかじって逆に危険であるような人々のやり方を指している。
ソフトウェア会社ならバグの最も少ないプログラマにボーナスを支給するかもしれない。
これがどれくらいうまくいくかというと、鶏に食べ物を買うよう金を渡すのと同じくらいのものだ。
1つ大きな問題は、それが内的な動機づけを外的な動機付けで置き換えてしまうことだ。
人々がやりたいことをやることに対して報酬を払うと、「過剰正当化」と呼ばれる効果が生じる。「自分がバグのないコードを書かなきゃいけないのは、それによってもらえるお金がほしいからなんだ」と考え、内的な動機付けが外的な動機付けによって置き換えられることになる。外的な動機付けは効果としてはずっと弱いものなので、結果的に彼らのいい仕事をしたいと思う気持ちを減らすことになる。ボーナスを出すのをやめたり、彼らが別にお金はいいやと思うようになったなら、もはやバグのないコードを書こうという気持ちはなくなる。
入門経済学マネジメントのもう一つの大きな問題は、人々が極大を求めがちになるということだ。彼らはあなたが本当に求めていることを達成しようとするのでなく、お金が支払われる特定のことについて最適化する方法を探るようになる。
ロバート・オースティンは、その著書「組織におけるパフォーマンスの測定と管理」において、新たなパフォーマンスメトリクスを導入するときには、二つの段階があると書いている。最初あなたは望んでいた結果を手にするが、それはまだ誰も誤魔化す方法を見つけていないためだ。次の段階になると、元よりもまずい結果を手にするようになり、それはあなたが測定しているものを最大化するトリックをみんな見つけ出し、たとえそれが会社を損なうとしてもお構いなしになるためだ。
入門経済学マネジメントの最大の問題は、それが実はマネジメントなんかではけっしてないということだ。それはむしろマネジメントの放棄と言える。物事がどうしたら改善できるか探ることを意図的に避けているのだ。これはマネジメントが単によりよい仕事の仕方を教える方法が分からないしるしであり、それでみんなに仕事の仕方を自分で考え出すよう強いているのだ。
スターバックスの標準トレーニングには、完全な命名システム、カップに書き込むこと、注文を大きな声で繰り返すことが含まれており、それは客がドリンクの注文を一度言えば済むようにするためなのだ。このシステムはスターバックスの本部で開発され、とてもよく機能しているが、それを他のチェーンの店員が自分で考え出すということはまずないだろう。
彼らはそんなこと気にかけていないし、賢くもないし、十分な情報も持たず、そして自分の仕事のためにあまりに忙しいからだ。
マネージャとしてのあなたの仕事は、システムを考え出すことだ。それがあなたが大金をもらっている理由なのだ。
一般にマネジメントはみんなが仕事を成し遂げられるシステムを作る必要があり、そのシステムは内的な動機付けを外的な動機付けで置き換えてはならない。それでは恐怖を使ったり怒鳴りつけて命令するのと大して違わないのだ。

FogBugz 4½と主観的幸福感

講演のテーマの1つは、私がPsych 110から学んだもっとも重要な事実を元にしていた。すなわち、人は環境をコントロールできるとハッピーになり、環境をコントロールできないと不機嫌になるということだ。
人々がまわりにあるものを直接コントロールできるようにしてやると、多かれ少なかれ、彼らはハッピーになる。これはマニュアルシフトを好む人たちがいる理由を説明している。これは鈍いユーザインタフェースを使っているとイライラし、気が沈む理由を説明している。
去年頃から多くのWeb開発者たちが、Ajaxとして知られるようになったテクニックを使い、アプリケーションを改良すべく努めてきた。これらのアプリケーションはJavaScriptを使っていて、何かをクリックすると、Webサーバがゆっくりしたペースで新しいページを送り返してくるのを待つことなく、即座に反応する。サーバからもっと情報を取ってくる必要がある場合には、サーバがまるまる新しいページを生成するのを待つのでなく、断片的なデータを必要なだけダウンロードする。この結果として得られる、早く、てきぱきとした反応は、ユーザにコントロールしている感覚を与え、「主観的幸福感」を生み出す。つまり、ユーザをハッピーにする。これは生物化学的には、でっかいチョコレートを食べるのといっしょなのだ。
ユーザがFogBugzでほとんどの時間を過ごす場所が2つあって、それはバグレポートの参照と編集を行うバグ詳細ページと、バグレポートを一覧し、ソートし、スライス&ダイスするバグ一覧ページだ。バージョン5.0では、この2つのページについて、JavaScriptとAjaxでユーザ体験を改善できそうなところはすべて、徹底的にやることにした。
ブレットはまた、以前から入れたくてうずうずしていた機能を忍び込ませた。すっごくたくさんのキーボードショートカットだ。しかしユーザが覚えなきゃいけないショートカットはたった1つだ。Ctrl+; でFogBugzはキーボードモードに切り替わり、画面上のそれぞれのコマンドに対するショートカットが何か思い出させてくれる小さな文字が浮かび上がる。

なぜテスターが必要なのか?

犬をしつける一番のこつは、フィードバックをすぐに与えてやることだ。もし、あなたが家に帰ってきて、犬が数時間前にキッチンのゴミ入れをひっくり返していたことを見つけたなら、もうしつけをするには遅すぎる。
プログラマーについても、自分がやっていることをもっとうまくできるようにしたいなら、自分がやったことについてすぐにフィードバックをもらう必要がある。それがポジティブなものであれ、ネガティブなものであれね。フィードバックをもらうのが早ければ早いほど、すぐに学ぶことができるようになる。
私たちがテスターを持つ理由の一つはここにある。すばらしいテスターがいれば、プログラマは何を正しくやり、何を間違えてやってしまったのたのかについて即座にフィードバックを得られる。信じられないかもしれないが、テスターを持つことの最も大きな効能は、プログラマの良い振る舞いに対して良い評価を与えることでそれを助長してくれることにあるのだ。
頻繁に開発者からリリースを受け取り、それを試し、ネガティブなフィードバックに加えてポジティブなフィードバックを与えてくれる熱心なテスターにしくものはない。そういうテスターがいなければ、プログラマになるのはひどく気が滅入ることになるだろう。ほら、僕はここでキーボードをカタカタやって、この素晴らしいコードを全部書き上げたけど、関心を持つ人は誰もいない。あーあ。
もちろん、自動テストスイートは便利だが、ソフトウェアのテストという仕事は単にそれだけにはとどまらない。そういうスクリプトにあまりに重きを置きすぎると、ずれたテキストや意地悪いユーザーインターフェイス、まずい色使い、一貫性の無さなどを見落としてしまうだろう。そして、さらに悪いことに、テスターが自分のコードを動くものにしようと夢中になって取り組み出すようになりかねない。そうなれば、あなたがテスターにやってほしいと考えていた仕事—つまり、他の人のコードを評価する仕事—が放り出されてしまう。
確かにテスターがプログラマである必要はないのだが、テスターが単なる能力の足りないプログラマの仕事であるかのようにしていると、そのうちに有能なテスターグループの代わりに能力の足りないプログラマのチームが出来上がってしまう。テストすること自体は仕事で教えられるが、汎用な知性はそのように鍛えることができないので、その人がたとえテスター関連の仕事をやったことが無かろうが、とにかく非常に頭の切れる人をテスターにしなければならない。現に私が一緒に働いたことにある最も優れたテスターの多くは、その仕事をオファーされるまでテスターの仕事をやってみたいと思ってすらいなかったのだ。

コンピュータサイエンスの学生へのアドバイス

WindowsのリッチGUIクライアントにこそソフトウェアの未来があると私がわめいていたのはほんの1、2年前だというのに、学生がe-mailでキャリアについてアドバイスを求めてくることがある。今は採用シーズンでもあることだし、彼らが読んで、笑って、無視できるような一般的なアドバイスを書いてみようと思う。
あなたがプログラミングが好きなら、自分の恵まれていることに感謝することだ。あなたは自分の好きなことをしていい暮らしができる数少ない幸運な人間の1人なのだ。多くの人はそんなに幸運ではない。「自分の仕事を愛する」というのは近代的な概念だ。仕事というのは、お金を稼ぐために何か不愉快なことをすることだと考えられている。そうして稼いだお金で自分の本当に好きなことをやるのだ。65になって引退したときに。
リーナス・トーバルズが伝道していなかったなら、Linuxは果たして成功しただろうか? 彼が優れたハッカーであったということと同時に、e-mailやメーリングリストを通して文章で自分のアイデアを人に伝えるリーナスの能力が、世界中のボランティアをLiunxに引きつけたのだ。
プログラミング組織はどんなものであれ、最も大きな権力や影響力を持つプログラマは、明確に、説得力を持って、やすやすと書き、話せる人間だ。背が高いというのも助けにはなるが、それについてはあなたはどうすることもできない。
まあまあのプログラマと優れたプログラマの間にある違いは、どれだけたくさんのプログラミング言語を知っているかではなく、JavaとPythonのどちらを好むかということでもない。違いは彼らがアイデアについてコミュニケートできるかどうかという点にある。
私は英語で文章を書け、しかも上手く書けるのでなければプログラマを雇わない。あなたが良く書けるなら、あなたが職を得たときすぐに仕様書を書くように頼まれるようになり、それによってあなたは影響力を伸ばすことができ、マネジメントの目にもとまるようになる。

自分の会社が何であるかを理解する

最近、キャシー・シエラを読んで考えさせられたのだ。キャシーはそのブログ「Creating Passionate Users」と著書「Head First」シリーズでもってデベロッパー教育に革命を起こした人なのだけど、彼女は同じことを繰り返し言い続けていた: 「ユーザーがスゴい人になるのを手助けしてやりなさい」
キャシーが言うことには、もしあなたが自分の会社のミッションを「私たちは $TYPE_OF_PERSON の方々が $THING についてスゴい人たちになるのを手助けしています」という形で説明できないなら、熱心なユーザーを獲得することはできないだろうという。あなたのスローガンは何だろう? このテンプレートに当てはめることができるだろうか?
会社ができて間もないころは、私たちはニューヨークにおいて、ソフトウェア開発者にとって素晴らしい職場を作りだすことだけを目指していた。
うん、本当にただそれだけだったんだ。当時、ニューヨークのソフトウェア関連の仕事といえば、ほとんど全てがひどいものだった。あなたはただどうひどいのかを選べるだけだった。
私たちはこの目標を達成した。線を引いてリストから消そう。じゃあ次は? 私たちは会社の新しい目標を探す必要があった。
そしてそれはこの形の文句でなくてはならない: 「私たちは$TYPE_OF_PERSONが$THINGについてスゴい人たちになるのを手助けしています」
私ははっと気がついた。私たちがやったことで成功したものはどれも、一つの共通点を持っていた。これらは皆、ソフトウェア開発者たちがソフトウェアを製作することおいてスゴイ人たちになるのを手助けするものだったのだ。
このことは、Joel on SoftwareやStack Overflow、私が執筆してきた本全て、DevDaysやBussiness of Softwareのようなカンファレス、Jobs Board、Stack Overflow Careersなどに当てはまる。
だから、ほら、新しいスローガンはこれだ: 「私たちは世界で最高の開発者たちがより優れたソフトウェアを作れるように手助けします」
ここまでいろいろと考えてみたおかげで、将来のバージョンのFogBugzに何がふさわしく、何がふさわしくないのかの見通しを立てるのが易しくなったように思う。
10年近くかかってしまったが、どうやら私たちはついに次の10年の目標をはっきりとらえることができたようだ。

Clearの底知れぬ楽天主義

Clearがやっていたのはこういうビジネスだ。まず、あなたは200ドル払って一年間の会員資格を手に入れる。そして、大がかりで複雑な身元調査を受けて、あなたが絶対確実に信用の置ける人物だということを証明する。
その代わりに、あなたはいくつかの大空港で、TSAのスクリーニングのために並んでいる行列の一番前に入ることができるようになる。
Clearの本当のビジネスプランはこれとは違っていた。当初のプランでは、Clearが綿密な身辺調査を行うことで、(絶対確実に信頼の置ける)旅行客はセキュリティチェックを完全にとばせるようになるはずだった。
もしかしたら、最前列に入れるということを売り物にするのは商売になるかもしれないね。ここには何らかのビジネスモデルがあるのかもしれない。
けど、それならなぜClearはまだ身辺調査をやっていたわけ? これにはまったく何の意味もない。
状況が変わり、そしてClearの「事前のスクリーニング」というビジネスモデルは成り立たないということが明らかになった。しかし、Clearはともかくこの事業を続けた。一体どんな組織の機能不全があれば、状況の変化を完全に無視して採算のとれない事業を続けるなんてことになるんだろうか?
Clearの人間は誰一人として何も考えていなかった。彼らにはビジネスモデルがあったが、それは実際には不可能なものだった。これは分かりきっていたことで、しかしそれでもClearはこの商売をやりつづけた。頭の足りない楽天主義。私は彼らに敬意を表すべきなのだろうか、それとも笑ってやるべきなのだろうか。

ケンブリッジの春

個人の声を持っていた。そのホームページに行くと、楽しげな小さなノートがあり、新しいオフィスのことや最新のコースの紹介をしていた。そのスタイルは企業の退屈な告知とは違っており、フィリップがあなたに語りかけているのだ:あなたにお金がないなら無料のサービスがあるし、もしお金持ちなら、たくさんのお金と引き替えにあなた自身のすてきなサービスを作ってあげましょう、だって将来はとても明るくて、サングラスが必要なのだから。
私が興奮するのはarsDigitaが個人の声をインターネット上に持つそのやり方であり、それは人々が人間的な仕方でそれに関わることを可能にし、それが人々が欲していることなのであり、なぜなら私たちは人間だからだ。
arsDigitaが間違っていたことが2つあると思う。第一に彼らはコンサルティングがあまり良くスケールしないということを理解していなかった。本当にインパクトのあることをしたいなら、ソフトウェアをライセンスする必要がある。プロジェクトで働くコンサルタントが上げる儲けは10%から20%だ。あなたがソフトウェアをライセンスしたなら、あなたの売るそれぞれの限界単位は100%収益となる。ソフトウェア会社の評価額がしばしばコンサルティング会社の25倍にもなる理由がこれだ。
あなたが「我々はUnixの方が良く分かっているので、Unixでやったほうがいい結果になる」と言うなら、あなたは科学者だ。あなたが「私たちはMicrosoftのクズは何も使わない、最低だからだ」と言うなら、あなたはただの狂信者で、それはあなたが良い仕事をする妨げとなる。
VCが即座に任命した退屈で保守的なマネジメントは、「単一なデータモデルによる完全な統合で、すべてのビジネス・プロセスに渡る一貫性を確保し、 ACSはエンドユーザにとっての価値を最大化するWebサービスを構築して組織に力を与える」みたいなまったくでたらめなことを言い、マーケティング・コミュニケーションWebサイトにこだわり続けた。
フィリップは去った。
あの声は消えてしまった。
成熟には何か悲しいものがある。
しかし空気には春の気配があり、それを埋め合わせてくれる。