Jim Waldo
2003年12月9日
(Original article: Jim Waldo, Worse is worse
. Japanese translation by Hisashi Morita.)
概要
"worse is better"に関する有名なエッセイは、誤解されているか、あるいは間違っているか、そのどちらかだ。我々が設計に関する主張でそれを引用するとき、我々は我々の顧客と我々の作品の両方をごまかしていることになる。私はこのエッセイを改めて取り上げ、考えてみたい。
最近、東海岸の技術者と西海岸の技術者の違いに関する記事を担当しているリポーターからインタビューを受けたことがある（そのとおり、この手垢のついた話がまた取り上げられているというわけだ）。そのせいでDick Gabrielの有名な"Worse is Better"の記事のことを考えるようになった。これはしばしば、エンジニアリングに対するMIT式（あるいは東海岸式――結局のところ、東海岸には他に何があるというのか）のアプローチ（コードがいくら複雑になろうとも、正しいことをせよ）と、Berkeley式（あるいは西海岸式）のアプローチ（ユーザの負担が増えたとしても、コードを単純に保て）の違いをまずはっきり述べているものとして知られている。
worse is betterという概念は、プログラミング業界において自明のことのように扱われはじめた。よくある例はC言語（Lispより劣っているがとにかく浸透した）とUnix（あるいは最近ではWindows）をMulticsやVMSと対比させ、（全く違う分野では）VHSテープをBetaと比較するものだ。優位に立つ技術はどれも、指摘されるようにもうひとつの選択肢よりも劣っていたが、劣っているほうの技術が結局標準となる。この話の教訓、あるいは議論でこの原則を持ち出す人の理由は、やっつけ仕事のがさつな解決策に注目すべきだと議論の相手を説得するためだ。なぜなら「worse is betterだから」。
もちろん、この一般に信じられている知恵は全くのでたらめだ。この主張は明らかに正しくない。しかしこの原則がテクノロジー業界に与えた損害は大変なもので、我々は、これ以上損害を広げてしまう前に立ち上がって押し戻すべきだ。
まず、主張について。Gabrielのもともとの著述（今でもGoogleで探すかここに行くかすれば読める）は興味深い読み物で、良い点がいくつもあった。これを読み返すと、それがいかによく書かれているかを思い出すだけでなく、一般にこの記事について信じられていることがの多くが誤りであると気づく。例えば、記事では一度も東海岸と西海岸のエンジニアリングスタイルの違いを対比したりしていない。記事で扱われている2つのグループは、MIT/Stanfordスタイル（一つのグループ）とNew Jerseyスタイルの設計だ。今時の、西海岸と東海岸におけるスタイルの対照という思いつきほどに面白いものではない。
論文の残りは、Lispがより優れた言語であったにもかかわらず、プログラミング言語としてCに負けた理由の、素晴らしい分析だ。言い換えれば、少なくともDickが最も重要だと思った基準において優秀だったにもかかわらず。しかしこれは必ずしもLispが実際にCよりも優秀であったということではない。記事中で引用されている基準が、プログラミング言語を選ぶ人にとって最重要なものとは限らないということが、簡単に読み取れる。Cは高速なコードを生成し、ものにしやすく、グループで使うのに適しており、より安価なハードウェアでうまく動いたという事実は、Gabrielにとって重要ではなかった。しかし他の人々はそれらを重視したのだ。それらの基準に基づいて言えば、プログラミング言語としてCが普及したことは、better is betterの例であり、worse is betterの例ではない。
betaとvhsの陳腐な話も、同様に別の解釈ができる。"worse is better"に基づく解釈では、優れた品質を備えたbetaは明らかに劣ったvhsテープ形式に負け、その原因は、人というものの不可解な強情さ（利口なマーケティング部門の策略や、Betaブランドを持っていたSonyの傲慢でもいい）に帰せられる。しかしvhsテープは一つのカセットでより長時間録画でき、より安価なレコーダーで再生でき、さまざまなメーカーから製品が提供されていた。ゆえに、vhsのほうが技術的に優れていたと言える基準があり、それらの基準は市場の大半によって重視されたものであったように思える。vhsがbetaを打ちのめしたのは、worse is betterが理由ではなく、いくつかの側面（コスト、録画時間）において優れたものが、他の側面（画質）において優れたものを打ちのめしたのだ。
Unix vs. Multicsのケースさえも、重要な点を見逃している。Multicsには優れたオペレーティングシステムがあった一方で、Unixには、その時点で存在しており、かなり安価なさまざまなハードウェア上で動作するという2つの有利な点があった。Windows（およびDOS）はさらに安価なハードウェア上で動作し、お望みならどんな技術的な立脚点においてもDOSよりUnixのほうが優れたOSだと主張することは容易だが、本当に安いハードウェア上で実働するという特性は、顧客に対して魅力的な特長となったのだ。Linuxが本物の選択肢の一つとして台頭してきたことは、特にこの選択においてより多くの証拠となるだろう。多分他のすべての事柄が等しい場合に人々が選ぶものは、優れたOSなのだろう。しかし彼らがUnixよりもDOSを選んだとき、物事は等しくなかった。
これらのケースすべてにおいて、選ばれた選択肢には、悪いほうが良いわけではないという結論を導く別の解釈がある。むしろ我々に分かるのは、優れている（better）とは複雑な概念であり、さまざまな別々の基準に依存しうるということだ。我々geekたちが優れていると考えているものが、我々の顧客が優れていると考えているものではないかもしれないと悟るのは、がっかりすることかもしれない。しかしそうだと知ってもさほど驚くことではないはずだ。
もちろん、worse is better（悪いほうが良い）のほうが、better depends on your goodness metric（優れているかどうかは優良さを測る基準による）などの現実を反映した表現よりも、スローガンとしてずっと心を捉える。そして元の記事には、たとえキャッチーな（歴史的には正確でない）スローガンの下でさえ、設計者が参考にできる知恵と洞察が含まれている。
私がこのスローガンを問題にしているのは、元の記事を読んでいなかったり、あるいは読んだけれどもその真意を忘れてしまったかそもそも理解しなかった、そんな人たちによって利用されるキャッチフレーズになってしまっているところだ。この文句はキャッチフレーズとして、粗悪な設計を正当化したり、正しいことをせずに大勢の後を追ったり、あるいは略語として、自分たちの顧客は馬鹿すぎて高品質な製品など正しく評価することもできないし必要もないという意味で、しばしば使われる。この手の論法はこう続く。なぜ正しくやるために時間を費やしたりするんだ、誰もがみんなworse is betterだと知っているというのに。顧客には、提供できるよりも劣っていると分かっているものを与えておけばいい、彼ら（あの無知な顧客たち）はそれが優れていると思うだろう、と。
この考え方の行き着くところは、役に立たないか、使いにくいか、あるいは信頼できない（またはこれら全部を併せ持った）ずさんな製品だ。我々は顧客を説得して、これがソフトウェアのあるべき姿だと信じ込ませる。そして振り向いて自分たち自身に向かい、顧客は優れたものにお金を払う気はないのだと信じ込ませる。しかし、この手の考え方を受け入れている時、我々は、我々の顧客をごまかし、我々の作品を貶めているのだ。元の記事が生み出された時、それが著者の意図するところだったとは、私は思わない。仮にそうだったとしても、我々はこのスローガンを愚かしく解釈するのを止め、そして（必ずしも我々自身のではなく、顧客の持つ優良さの基準において）本当に優れたソフトウェアを送り出しはじめるべきだ。
Jim WaldoはSun MicrosystemsのDistinguished Engineer（特別招聘技術者）であり、同社ではJavaベースの分散プログラミングシステムJiniのリードアーキテクトを務めている。Jini以前はJavaSoftおよびSun Microsystems Laboratoriesで働き、オブジェクト指向プログラミングおよびシステム、分散コンピューティング、およびユーザ環境の分野で研究に従事した。Sunに入社する以前は、Apollo ComputerとHewlett Packardに8年間勤務し、分散オブジェクトシステム、ユーザインタフェース、クラスライブラリ、テキストと国際化の分野に取り組んだ。HPでは、最初のオブジェクトリクエストブローカーの設計と開発を率い、その技術が最初のOMG CORBA仕様に取り込まれるよう尽力した。