ソフトウェアにおける高音域
From The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳
2005年7月25日 月曜
私は2000年3月に、成功するソフトウェア会社を作るにはアイデアが必要だと多くの人が考えているのは間違いだという危うげな主張をこのサイトで掲げた。
- ソフトウェア会社を作るのは、それまで解けなかった何かの問題を解決する巧妙なアイデアを見出し、実現し、それによって富を得るのが目的なのだと一般には信じられている。これを「より良いネズミ取り作りの信条」と呼ぶことにしよう。しかしソフトウェア会社の本当の目的は、資本を役立つソフトウェアに変えることであるべきなのだ。
この5年の間、私はこの理論を実社会で試してきた。私が2000年9月にマイケル・プライアとともに立ち上げた会社のプランは、次の4ステップに集約できる:
| 最高の
仕事環境 | → | 最高の
プログラマ | → | 最高の
ソフトウェア | → | 収益! |
このプランは、自分たちが働きたいソフトウェア会社を作るためにFog Creekをはじめた私たちにはとても都合のいいものだった。当時の私の主張は、良い仕事環境を作ることで(照れずに言うなら「世界中の優れたソフトウェア開発者たちが働きたいと思うような会社を作る」ことで)、収益は自然にもたらされるものであり、それはチョコレートが肥満をもたらしたり、テレビゲームのセックスシーンが暗黒街の殺し合いをもたらすのと同じことだ、というものだった。
今日のところは1つの疑問にだけ答えることにしよう。もしこの部分が間違っていたなら、理論全体が崩れてしまうからだ。その疑問とは、「最高のプログラマ」を雇うということにそもそも意味があるのか、ということだ。最高のプログラマを求めることが重要な意味を持つほど、プログラマの能力の違いは大きいものなのだろうか?
この疑問に対する答えは私たち開発者には明らかなことかもしれないが、しかしその他の人々には、依然証明を必要とすることなのだ。
何年か前のことになるが、とある大きな会社がFog Creekの買収を検討していたことがあった。しかし最高のプログラマを求めるという私の持論にその会社のCEOが不同意だというのを聞いたとき、これはうまくいかないなとすぐに悟った。彼は聖書を引用して言った。ダビデ王が１人いれば、あとは命令をただ実行する兵隊がいればよいのだと。彼の会社の株価はその後ほどなく20ドルから5ドルに下がったので、私たちが提案を受け入れなかったのは幸いだったが、彼らの失敗をダビデ王崇拝のせいにするわけにもいかないだろう。
実際のところ、高給取りの経営コンサルタントに自分たちのかわりに考え、噛み砕いてもらっている大会社や、サルまねばかりのビジネスジャーナリストたちの間に一般的な通念では、ソフトウェア会社でもっとも重要なのはプログラマのコストを削減するということなのだ。
業界によっては、安いことが優れていることよりも重要になる。ウォルマートは、優れた商品ではなく、安価な商品を売ることによって、地上最大の企業に成長した。ウォルマートが高品質な商品を売ろうとしたなら、それによりコストが上がって彼らのアドバンテージは失われてしまう。たとえば彼らが過酷な条件——洗濯機で洗われるというような——に耐えられる靴下を売ることに決めたなら、さまざまな高級素材——綿とか——を使う必要が生じ、それは靴下一足一足のコストを押し上げることになる。
それなら、ソフトウェア業界にだって最安価なプログラマを使って低価格のソフトウェアを提供するところが出てきたっておかしくはない。 (みんなクビにして低コストの人材に置き換えるプランがどうやったらうまくいくのかQuarkに聞いてみることにしよう。)
それが間違っている理由は、ソフトウェアの複製にはコストがかからないということにある。そのため、プログラマのコストは売られるソフトウェア全体に薄く拡げることができる。１本あたりのコストをほとんど変えることなく、クオリティを上げることができるのだ。
デザインというのは本質的に、コストを増やすよりも早く価値を増やせるものなのだ。
逆の言い方をすると、プログラマのコストをケチるなら、お粗末なソフトウェアを作ることになり、それでいて大した節約にはならないということだ。
同じことがエンターテインメント業界にも当てはまる。ブラッド・ピットは高いギャラを要求するにしても、次の大作映画のために彼を雇うのは利にかなっている。それはブラッドが出ているから映画を見に行く何百万の人々にコストは分散されるからだ。
そしてまた、アンジェリーナ・ジョリーは高いギャラを要求するにしても、次の大作映画のために彼女を雇うのは理にかなっており、それはアンジェリーナが出ているから映画を見に行く何百万の人々にコストは分散されるからだ。
しかし私はまだ何も証明したことにならない。「最高のプログラマ」とは何を意味するのだろう? 異なるプログラマの作るソフトウェアのクオリティにはそんなに大きな違いがあるものなのだろうか?
単純で馴染み深い生産性の話からはじめよう。プログラマの生産性というのは測定するのが難しいものだ。どんなメトリクス(デバッグ済みコードの行数、ファンクションポイント、コマンドライン引数の数)を考え出したところで、簡単にその裏をかくことができる。それにどの二人のプログラマも同じ作業をすることはめったにないため、大規模プロジェクトで具体的な生産性データを得るのはとても難しい。
私が使うデータは、イェール大学のスタンリー・アイゼンスタット教授からもらったものだ。彼は毎年プログラミングの授業CS 323を教えており、この授業ではそれぞれが2週間くらいを要する5つほどのプログラミング課題を行う。課題は大学の授業の題材としては相当本格的で、Unixのコマンドラインシェルを実装するとか、ZLWファイル圧縮ツールを作成するといったことだ。
この授業のためにどれほど苦労しているかと学生たちが文句を言うものだから、それぞれの課題にどれだけ時間を費やしたのかも合わせて報告するようにアイゼンスタット教授は指示するようになった。彼は何年にも渡ってそのデータを集め続けた。
私はそのデータを少し時間をかけて分析してみた。これは何ダースもの学生が同じ技術を使い同じ課題に同時に取り組んだ生産性データであり、そのようなデータを私は他に知らない。実験のようによくコントロールされた状況で取られたデータなのだ。
最初にやってみたのは、12個の課題のそれぞれに費やされた時間の、平均、最小、最大、標準偏差を求めるということだ。結果は次のようになった:
| プロジェクト | 平均時間 | 最小時間 | 最大時間 | 標準偏差 |
|---|---|---|---|---|
| CMDLINE99 | 14.84 | 4.67 | 29.25 | 5.82 |
| COMPRESS00 | 33.83 | 11.58 | 77.00 | 14.51 |
| COMPRESS01 | 25.78 | 10.00 | 48.00 | 9.96 |
| COMPRESS99 | 27.47 | 6.67 | 69.50 | 13.62 |
| LEXHIST01 | 17.39 | 5.50 | 39.25 | 7.39 |
| MAKE01 | 22.03 | 8.25 | 51.50 | 8.91 |
| MAKE99 | 22.12 | 6.77 | 52.75 | 10.72 |
| SHELL00 | 22.98 | 10.00 | 38.68 | 7.17 |
| SHELL01 | 17.95 | 6.00 | 45.00 | 7.66 |
| SHELL99 | 20.38 | 4.50 | 41.77 | 7.03 |
| TAR00 | 12.39 | 4.00 | 69.00 | 10.57 |
| TEX00 | 21.22 | 6.00 | 75.00 | 12.11 |
| 全プロジェクト | 21.44 | 4.00 | 77.00 | 11.16 |
これを見て最初に目につくのは、ばらつきの大きさだ。一番早い学生は平均的な学生よりも3倍から4倍早く、一番遅い学生と比べると10倍も早い。標準偏差が極端に大きいのだ。それで私はあまりに早い学生は、もしかするとひどいプログラムを出してるんじゃないかと考えた。動かないプログラムを4時間で提出したような学生は勘定に入れたくない。それでデータを絞って、成績が上位1/4のデータだけ使うことにした…コードのクオリティが上位25%のものだけを取るという意味合いだ。アイゼンスタット教授の授業の成績はまったく客観的につけられているということを指摘しておこう。成績は自動化テストをどれだけ通るかに基づいて計算式で算出され、その他のことは一切考慮されない。コーディングスタイルがまずかったりプログラムが遅くとも減点はされない。
次に挙げるのが、上位1/4の結果だ:
| プロジェクト | 平均時間 | 最小時間 | 最大時間 | 標準偏差 |
|---|---|---|---|---|
| CMDLINE99 | 13.89 | 8.68 | 29.25 | 6.55 |
| COMPRESS00 | 37.40 | 23.25 | 77.00 | 16.14 |
| COMPRESS01 | 23.76 | 15.00 | 48.00 | 11.14 |
| COMPRESS99 | 20.95 | 6.67 | 39.17 | 9.70 |
| LEXHIST01 | 14.32 | 7.75 | 22.00 | 4.39 |
| MAKE01 | 22.02 | 14.50 | 36.00 | 6.87 |
| MAKE99 | 22.54 | 8.00 | 50.75 | 14.80 |
| SHELL00 | 23.13 | 18.00 | 30.50 | 4.27 |
| SHELL01 | 16.20 | 6.00 | 34.00 | 8.67 |
| SHELL99 | 20.98 | 13.15 | 32.00 | 5.77 |
| TAR00 | 11.96 | 6.35 | 18.00 | 4.09 |
| TEX00 | 16.58 | 6.92 | 30.50 | 7.32 |
| 全プロジェクト | 20.49 | 6.00 | 77.00 | 10.93 |
大して違わない! 上位1/4に絞っても標準偏差はほとんど変わらないのだ。実際データを良く見れば、時間と成績の間に認識できるような相関がないのは明らかだ。次に挙げるのは、ひとつの課題についての典型的な散布図だ。選んだのはCOMPRESS01で、これは2001年の学生がZiv-Lempel-Welch圧縮法の実装に取り組んだデータだ。これを選んだのは、この課題の標準偏差が、全データの標準偏差に近かったからだ。
ここには特に見るべきものはない。そしてそのことがポイントなのだ。仕事のクオリティと費やされた時間との間には相関がないのだ。
私がアイゼンスタット教授にこのことについて尋ねてみると、彼はもう１点指摘した。課題には決められた締め切り(通常真夜中)があり、締め切りに間に合わないことのペナルティは非常に大きいので、多くの学生はプログラムが完成する前に作業をやめることになるということだ。課題が与えられてから締め切りまでの時間が十分でないため、所用時間の最大値には上限があることになる。学生が課題に取り組むための時間が無制限にあったとしたら(これは職業プログラマの世界に幾分近い状況になる)、ばらつきはさらに大きくなるだろう。
このデータは完全に科学的というわけではない。たぶんずるをしている人もいるだろう。学生によっては、時間を多めに報告すれば、同情を引いて次の課題をもっと簡単にしてもらえると考えるかもしれない。（おあいにく様! CS 323の課題は私が1980年代に取ったときと変わっていない。) 何時間やったか途中で分からなくなって、実際よりも少なく報告している学生もいるかもしれない。それでも、このデータの示しているプログラマの生産性の違いが5:1から10:1というのが誇張だとは思わない。
だけど待って、他にもあるんだ!
プログラマの違いが生産性だけのことなら、1人の際立ったプログラマを5人の凡庸なプログラマで置き換えられることになる。これは明らかに正しくない。「遅れたプロジェクトに人を投入するとさらに遅れる」というブルックスの法則のためだ。１つのタスクを行っている1人の優れたプログラマには、調整やコミュニケーションにかかるオーバヘッドがない。同じタスクに取り組んでいる5人のプログラマには調整やコミュニケーションが必要になる。そしてそういったことには多くの時間がかかる。チームを可能な限り小さくすることには付加的な利点があるのだ。人月というのは本当に神話のようだ。
だけど待って、それだけじゃないんだ!
少数の優れたプログラマの代わりにたくさんの凡庸なプログラマを使うことの本当の問題は、いかに多くの時間をかけようとも、優れたプログラマが作り出すものが彼らには決して作れないということだ。
アントニオ・サリエリが5人いても、モーツァルトのレクイエムはできないのだ。決して。たとえ100年かけようとも。
5人のジム・デイビス——面白くもないネコの漫画の作者で、そのジョークの20%は月曜は最低だという話で、残りはネコがいかにラザニアに似ているかという話なのだ(しかもそれがオチだというのだから!)——が一生をかけてコメディを書いたとしても、サインフェルドのスープナチのエピソードを決して作れない。
Creative Zenの開発チームが彼らの醜いiPod類似品を何年かけて磨き上げようとも、Apple iPodのように美しくエレガントで満足を与えてくれるプレーヤーを作ることはできない。そして彼らがAppleのマーケットシェアに影響を与えることはないだろう。あの魔術的なデザインの才能がそこにはいないからだ。彼らはそれを持ち合わせていないのだ。
凡庸な歌手は最高の歌手がいつでも出している高音域を決して出すことができない。モーツァルトの夜の女王のF6を出せるプリマはごくわずかしかいない。そしてあのF6が出せなければ、夜の女王を演じることはできないのだ。
芸術における高音域が、ソフトウェアでも問題になるのだろうか? 「場合によってはそうなのかもしれないが、私はただ医療廃棄物業界向け会計システムのユーザインタフェースを作っているだけだ」。それは結構。ここで議論しているのはパッケージソフトを作るソフトウェア会社のことであり、そこではコードのクオリティが直接、会社の成功失敗に結びつくのだ。
私たちはこの何年か、すばらしいソフトウェアを、本当の高音域の例をたくさん見てきた。それは凡庸なソフトウェア開発者には決して作ることのできないものだ。
2003年のことだが、NullsoftがWinampの新版をリリースしたとき、彼らはWebサイトで次のような告知をしていた:
- おしゃれな新しいルックス!
- いかした新機能!
- たいがいの部分はちゃんと動く!
すごいのは最後のところだ・・・「たいがいの部分はちゃんと動く!」というのにはみんな笑った。そして嬉しくなり、それでみんなWinampに夢中になり、それを使い、友達にも教え、Winampってすごいと思ったのだ。それというのも、連中が「たいがいの部分はちゃんと動く!」とWebサイトに書いたからだ。こういうのって、クールだと思わない?
余分なプログラマを山ほど投入して、Windows Media Playerは高音域が出せたのだろうか? 何千年かけてもだめだろうね。チームに人を追加するほど、「たいがいの部分はちゃんと動く!」とWebサイトに書いたりするのがプロらしくないと考えるうるさ型のいる可能性は高くなるのだ。
「Winamp 3: Winamp 2と同じくらいに新しい!」なんていうのはまず無理だろう。
そして私たちはWinampのそういうところが好きになったのだ。
AOL Time WarnerのトップがWinampに手を伸ばしたときには、あのおかしなやつはWebサイトからなくなっていた。映画アマデウスのサリエリのように怒りっぽく歪んでいて泣き言を並べるばかりの彼らは、クリエイティビティのあらゆる兆候を叩き潰し、ミネソタのおばあさんを不安にさせないようにする代わりに、みんながWinampを好きだった部分もいっしょに払拭してしまった。
あるいはiPodを見てみるといい。バッテリーが交換できない。だからバッテリーに寿命が来たら具合の悪いことになる。iPodを新しく買わなきゃいけないのだ。実際は工場に修理に出せばAppleは交換してくれるが、それには65.95ドルかかる。
なんでバッテリーを自分で交換できないんだ?
その理由は、私の推測では、美しくセクシーなiPodの完璧に滑らかで継ぎ目のない表面に、安物の電気製品についているような醜悪なバッテリーカバーをAppleは付けたくなかったのだ。小さな引っ掛かりがあってすぐに壊れ、継ぎ目にはごみが溜まってしまう。不快なことだらけだ。家電製品でiPodほど継ぎ目のないものを私は見たことがない。まったく美しい。すべすべした川辺の石のような美が感じられる。バッテリーカバーの引っかかりひとつが、この川辺の石の効果を台無しにしてしまうのだ。
Appleはスタイルに基づいて意思決定したのだ。実際iPodにはスタイルに基づく意思決定がいっぱい詰まっている。そしてスタイルというのはMicrosoftの100人のプログラマや、間違って社名がつけられたCreativeの200人の工業デザイナに到達できるようなものではないのだ。それは彼らの元にはジョナサン・アイブがいないからで、そしてジョナサン・アイブみたいな人間はそうそういるものではない。
悪いけど、iPodの話になると止められない。あのカチカチと音を立てる素敵なサムホイール…Appleは余分のお金をかけてiPodの中にスピーカーを入れたが、それはカチカチという音がサムホイールから聞こえるようにするためなのだ。彼らはカチカチという音をヘッドホンから聞こえるようにすることで、何セントか節約することだってできた…何セントか! しかし、あのサムホイールはユーザにコントロールしている感覚を与えてくれる。人々はコントロールしている感覚が好きなのだ。コントロールできていると嬉しく感じられる。サムホイールが、ユーザの操作に対して、スムーズに、流れるように、音を立てながら反応すると、ユーザは喜びを感じる。その他の6000のポケット家電とは違っている。電源スイッチを入れてもブートするのにすごく時間がかかり、何か反応したことが分かるのに1分も待たされる。これでコントロールしているように感じられるだろうか? 電源ボタンを押したら即座につく携帯電話に以前お目にかかったのはいつのことだろう?
スタイル。
幸福感。
感情にアピールするもの。
これらこそ、ソフトウェア製品であれ映画であれ消費者家電であれ、大ヒットを作りだすものなのだ。そしてこれを正しくやらないなら、問題を解決していたとしても、製品がナンバーワンになることはない。ナンバーワンヒットは社員全員を金持ちにしてくれる。フェラーリ・スパイダーF-1のようなスタイリッシュで幸福感に満ち感情にアピールする車に乗り、余ったお金で裏庭に道場を作れるくらいに。
これは「生産性が10倍」とかいうような話ではない。「平均的な」開発者がすごいソフトウェアを作り出す高音域に達することは決してないのだ。
あいにくとこれは非製品ソフトウェア開発には適用できない。インターナル、インハウスソフトウェアが、ロックスターを雇うのを正当化できるほど重要性を持つことは滅多にない。結婚式で歌ってもらうためにドリー・パートンを雇う人がいないのと同じことだ。だからソフトウェア開発者であれば最も満足できるキャリアはソフトウェア会社なのであって、どこかの銀行のIT部門ではない。
最近では、ソフトウェア市場は勝者がすべてを取るシステムになっている。Apple以外のどこもMP3プレーヤーで儲けることができない。Microsoft以外のどこも、スプレッドシートやワープロで儲けることができない。彼らはその地位につくために反競争的な手段を使ったかもしれないが、勝者がすべてを取るシステムであるという事実は変わらない。
ナンバーツーであったり、製品が「十分に良い」ということではやっていけないかもしれない。際立って良い必要がある。すごく良い製品であるため人々の注意を引かずにはいないというくらいに。本当に才能あるソフトウェア開発者が、注意を引かずにはいない製品に到るための唯一の望みなのだ。そのことはこのプランに織り込まれている:
| 最高の
仕事環境 | → | 最高の
プログラマ | → | 最高の
ソフトウェア | → | 収益! |
(オリジナル: Hitting the High Notes)
