これは、Paul Graham：The Other Road Ahead を、原著者の許可を得て翻訳・公開するものです[訳註1]。
<版権表示>
本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。
(「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。
Copyright 2001 by Paul Graham
原文: http://www.paulgraham.com/road.html
日本語訳：Shiro Kawai (shiro ＠ acm.org)
<版権表示終り>
Paul Graham氏のエッセイをまとめた『ハッカーと画家』の
邦訳版が出版されました。
出版社の案内ページ
Amazon.co.jp
サポートページ
2004/3/21 翻訳公開
2004/4/11 武井伸光さん、ひろせあつしさんからの誤記の訂正を反映
1995年の夏、私は友人のロバート・モリスと共にベンチャー企業を立ち上げる決心をした。 当時Netscapeの株式公開へ向けたPRキャンペーンは最高潮に達しており、 オンラインコマースに関する報道がひっきりなしになされていた。 その頃、おそらくWeb上には30ばかりのオンラインストアが、全て手作りのサイトで 運営されていた。オンラインストアがもっとずっとたくさんできるなら、 オンラインストアのサイトを構築するソフトウェアが必要だろう、 そう考えて私達はそういうソフトウェアを書き始めた。
最初の1〜2週間は、私達は普通のデスクトップアプリケーションを作るつもりでいた。 ところがある日、Webサーバ上でソフトウェアを走らせて、Webブラウザを インタフェースをして使ったらどうかと思い付いたんだ。 Webで動くようにソフトウェアを書き直してみて、これが進むべき方向だとわかった。 サーバ上で走らせるようにすれば、ユーザにとっても私達にとっても全てが簡単になる。
この選択は成功だった。こんにちでは、このソフトウェアは Yahoo Storeとして 14,000ユーザをサポートする最も人気のあるオンライン ストアビルダーとなっている。
我々がViawebをはじめた時、サーバでソフトウェアを走らせるんだと聞いて 理解してくれる人はほとんどいなかった。1年後にHotmailがスタートし、その頃になって ようやく人々は理解しはじめた。今では誰もが、それは有効なアプローチであると 知っている。こういう業種に名前まで付いた：アプリケーションサービスプロバイダ、ASPというやつだ。
次世代のソフトウェアの多くは、このモデルで書かれるようになるんじゃないかと 私は考える。失うものが一番大きいはずのマイクロソフトでさえ、 デスクトップからサーバへとシフトすることは不可避だと見ているようだ。 ソフトウェアがデスクトップからサーバへシフトすれば、 開発者の世界はずいぶん違ったものになるだろう。 この記事では、我々がこの新世界の最初期の旅行者として得た いくつかのびっくりするような経験を述べたいと思う。 ソフトウェアをサーバへ移動させたという点においては、 ここで述べていることは未来そのものである。
将来、デスクトップソフトウェアの時代を振り返った時、我々は 人々がどんなに不便な思いをしていたか感心することだろう。 ちょうど、初期の自動車の持ち主がどんなに不便な思いをしていたかを 現在感心するようにね。最初の2〜30年くらいは、 車を持つためには車のエキスパートでなければならなかった。 でも、車はとても便利だったから、エキスパートでない人々も 車を欲しがったんだ。
コンピュータも今、ちょうどその時期にある。 デスクトップコンピュータの持ち主になれば、 知りたくもないその中身の動作をいやが応にも学ぶ羽目になる。 でも、米国では半分以上の家庭にコンピュータがあるんだ。 私の母だって、メールと家計簿のためにコンピュータを持っている。 一年ほど前、母はAppleからOSの新しいバージョンの割引購入特典を知らせるメールを 受け取って困惑していた。 メールと家計簿を使いたいだけの65歳の女性が、 新しいオペレーティングシステムのインストールについて考えなくちゃならないっていうのは、 どこかがおかしい。普通のユーザは、「オペレーティングシステム」なんて 単語、知らなくても済むようじゃなくちゃダメだ。ましてや 「デバイスドライバ」や「パッチ」だなんて。
いまや、ユーザをシステム管理者にしなくてもよい ソフトウェアの配布方法がある。Webベースアプリケーションは Webサーバで走り、Webページをユーザインタフェースとするような プログラムだ。平均的なユーザにとって、この新しい種類のソフトウェアは 簡単で、安く、どこでも使えて、信頼性も高く、しかも デスクトップソフトウェアより強力であることさえある。
Webベースソフトウェアでは、多くのユーザは自分が使うアプリケーション 以外を気にする必要がない。煩わしいことがらは全てどこかの サーバにあって、そういうのが得意な人が管理してくれている。 だからソフトウェアを使うのに、いわゆるコンピュータというものを使う 必要はないわけだ。キーボードと画面とWebブラウザがついた 何かがあればいい。 ワイヤレスのインターネットアクセスがついているかもしれない。 携帯電話と一緒になっているかもしれない。何であれ、それは家電製品になるだろう。 せいぜい$200くらいで、外観で選んで買って行くようなものに。 人々はハードウェアよりもインターネット上のサービスにお金を払うようになるだろう。 今、電話がそうであるように[1]。
クリックしてサーバから返事が帰って来るのに10分の1秒ほどかかるから、 Photoshopのようなインタラクティブ性が重要なソフトウェアのユーザは、 計算がデスクトップで行われることを望むだろう。 でも、ほとんどの人がコンピュータを何に使っているか見てみれば、 1/10秒の遅延は問題にはならない。私の母はデスクトップコンピュータなんて 必要としないし、母のような人々は他にもたくさんいる。
うちの近所に、こんなステッカーを貼った車が停めてある： 「不便なら死んだほうがまし」。多くの人は、ほとんどの場合、 一番手間のかからない方法を選ぶ。Webベースのソフトウェアが勝つとすれば、 それが便利だからに他ならないはずだ。 そして、どうもそれは正しいようだ。ユーザにとっても開発者にとっても。
純粋なWebベースのアプリケーションを使うのに必要なのは、 インターネットに接続されたブラウザだけだ。従って、Webベースアプリケーションは どこでも使うことができる。デスクトップコンピュータにソフトウェアを インストールした場合は、そのコンピュータでしかソフトウェアを使うことができない。 さらに悪いことに、使うファイルはそのコンピュータに閉じ込められてしまう。 人々がネットワークを使うようになるにつれ、このモデルの不便さは よりはっきりしてくる。
この楔の薄い方の端は、Webベースのメールだ。何百万という人々が、 どこでもメールを読み書きできる必要性に気づいている。 メールが読めるなら、予定表だって使えたらいいじゃないか。 同僚と文書に関して議論できるなら、それを編集できたっていいじゃないか。 どうしてデータをはるか遠くの机に鎮座しているコンピュータに閉じ込めて おかなくちゃならないんだい?
「私のコンピュータ」という概念自体がなくなり、 「私のデータ」に置き換わるだろう。 どのコンピュータからも自分のデータにアクセスできなくちゃ。 いや、むしろどのクライアントからでも、と言っておこうか。 クライアントがコンピュータである必要はないからだ。
クライアントはデータを保存すべきではない。電話器のように なるべきだ。実際、クライアントは電話器になるかもしれない(逆かもしれないが)。 そしてクライアントが小さくなってゆけば、ますますクライアントに データを置いておきたくなくなるだろう。持ち運ぶものは、 無くしたり盗まれたりするかもしれない。 PDAをタクシーに置き忘れるのは、ディスククラッシュと同じような事故だ。 ただ、データが消えてしまうのではなく 他人の手に渡るってところが違うがね。
純粋なWebベースのソフトウェアでは、データもアプリケーションも クライアント上には置かれない。だから、それを使うのにインストールする 必要もない。インストールの必要が無ければ、インストールがうまくいかなかった 時の心配をする必要もない。OSとアプリケーションの互換性の問題も 起こらない。ソフトウェアは手元のOS上で走るわけじゃないからね。
インストールが要らないということから、 購入する前にWebベースのソフトウェアを試してみることは簡単だし、 おそらくそれがあたりまえになってゆくだろう。どんなWebベースアプリケーションも、 そのサイトに行くだけで、無料で試用できるようになるだろう。 Viawebでは、私達のサイト全てがユーザを試用に誘導するようなでっかい矢印みたいな ものだった。
デモを試した後に、サービスにサインアップするには、 短いフォームに記入するだけでいい(短ければ短いほどいい)。 そして、それがユーザにとって最後の作業であるべきだ。 Webベースソフトウェアでは、新しいリリースは追加料金も余分な作業も無しで 使えるようになる。新しいリリースがあったことにさえ気づかないかもしれない。
アップグレードは、現在のように大がかりなものではなくなるだろう。 時が経つにつれ、アプリケーションは静かに、より強力なものに成長してゆく。 この点に関しては、開発者側にある程度の努力が必要だ。 ソフトウェアのアップデートがユーザを混乱させないようにあらかじめ 設計しておかねばならない。これは新しい問題ではあるが、 解決法はある。
Webベースアプリケーションでは、誰もが同じバージョンを使い、 バグは見つかるはしから修正されてゆく。 従って、Webベースアプリケーションはデスクトップソフトウェアよりも バグが少ないだろう。Viawebでは、たぶんどの時点でも、知られているバグの 数は10以下だったんじゃないかと思う。これはデスクトップソフトウェアとは 桁違いだ。
Webベースアプリケーションは複数のユーザから同時に使える。 これは、共同作業を行うアプリケーションにとって明確な利点だが、 ユーザは、それが可能だと知ったら、ほとんどのアプリケーションが そのように使えることを望むのではないかと私は睨んでいる。 例えば、2人で同時に同じ文書を編集するのが便利な時は良くある。 Viawebでは複数のユーザが同じサイトを同時に編集できた。 ユーザが欲したからというより、そうするのがソフトウェアとして 正しい方法だったからなのだが、結果的に多くのユーザがその機能を 使いたがったのだ。
Webベースアプリケーションを使えば、データはより安全だ。 ディスククラッシュが過去のものになることはないだろうが、 ユーザがそれを気にする必要はなくなる。クラッシュはサーバファーム内で 起こるからだ。そして、Webベースアプリケーションを提供する会社は ちゃんとバックアップを取るだろう。ちゃんとしたシステム管理者がいて、 そういうことを気にかけているから、というだけではない。ASPにとって ユーザのデータを失うということは、重大な問題だからだ。 ユーザは、自分のディスククラッシュで自分のデータを失った時には、 それほど怒らない。自分を責めるしかないからね。だが会社が自分の データを失ったとなれば、かんかんになるだろう。
最後に、Webベースのソフトウェアはウィルスに対してより頑健であるだろう。 クライアントがブラウザだけを走らせるなら、ウィルスが走る危険はより 少なくなるし、被害を受けるローカルデータは存在しない。 そして、サーバを攻撃しようとしても、ずっと守りが固いだろう [2]。
ユーザにとって、Webベースのソフトウェアはストレスの少ないものに なるだろう。平均的なWindowsユーザの心の中には、 ストレスの少ないソフトウェアに対する満たされない欲求というものが いっぱい溜っているに違いないと私は思っている。 解き放たれれば、それは巨大な力となるだろう。
開発者にとって、Webベースとデスクトップソフトウェアとの 最も顕著な違いは、Webベースアプリケーションはひとつのコードの塊では ないということだ。Webベースアプリケーションは単一の大きな バイナリではなく、むしろ違ったタイプのプログラムの集合になるだろう。 従って、Webベースアプリケーションの設計は、ビルディングを作るよりも 都市を作るのに似てくる。ビルディングだけでなく、 道路や標識、上下水道にガス電気、警察署と消防署、そして 拡張計画や災害への対応計画なんかが必要だ。
Viawebで使っていたソフトウェアには、ユーザが直接対話する かなり大きなアプリケーション群と、それらが使うプログラム群、 そして問題を監視するためにバックグラウンドで常に走っているプログラム群、 おかしくなった時に再立ち上げを行うプログラム群、時々走って 統計情報をまとめたりサーチインデックスを構築するプログラム群、 データの移動や資源のごみ集めのために手動で走らせるプログラム群、 性能評価やバグ出しのためにユーザのエミュレーションを行うプログラム群、 ネットワークのトラブルを診断するプログラム群、バックアップ、 外部サービスへのインタフェース、リアルタイムでサーバの統計情報を なかなか見事なダイアルの集合で表示するプログラム(訪問者に好評だったが、 我々にとっても無くてはならないものだった)、 オープンソースソフトウェアへの変更やバグフィクス、 その他数え切れないくらいの設定ファイルなどが含まれていた。 トレバー・ブラックウェルは、我々がYahooに買収された後で、 外国にあるサーバへとサービスを止めずに オンラインショッピングサイトを移動する、見事なプログラムを書いた。 プログラムが我々を呼び出し、ユーザにファックスやメールを送り、 クレジットカード会社と取り引きを行った。 プログラム群は互いにソケット、パイプ、httpリクエスト、ssh、 udpパケット、共有メモリ、ファイルを通じて会話した。 Viawebの一部は、「プログラムが存在しないこと」により作られていた。 というのも、外部からの侵入を試みる者が使える不必要なユーティリティを走らせないことが Unixのセキュリティでは重要だからだ。
これはソフトウェアだけに止まらなかった。 我々はサーバ構成についても多くの時間をかけて考えた。 我々はサーバを部品から自分達で組み立てたんだ。 費用を節約するためでもあり、また必要なものを的確に得るためでもあった。 上流のISPがバックボーンに十分速い接続を持っているかを考えなければ ならなかったし、 RAIDメーカーの記録を逐次とっていた。
でも、ハードウェアは心配の種ってだけじゃない。 ハードウェアを制御することができれば、ユーザに対してもっと多くを提供できるんだ。 デスクトップアプリケーションでは、 最低動作条件を指定することはできるけど、より高性能のハードウェアは当てにできない。 サーバを管理しているならば、必要なハードウェアをインストールする だけで、メッセージング機能とか、ファックス送信機能、電話で指示を出せる 機能、あるいはクレジットカードの処理機能なんかを追加することができる。 我々はいつでも、ハードウェアを追加することで新しい機能が追加できないかと 考えていた。それはユーザを喜ばせるってだけじゃない。 ライバル会社は、デスクトップソフトウェアを売ったり、ウェブベースアプリケーションをISPに 売ったりしていた。 ハードウェアを直接制御できない彼らに対して、 我々のサービスを差別化するよい方法だったんだ。
Webベースアプリケーションはひとつのバイナリではなく プログラムの集合であるということは、それをいくつもの異なる言語で 書くことができるということでもある。 デスクトップソフトウェアを書いている場合、現実的には、あなたは アプリケーションを下層のオペレーティングシステムと同じ言語で 書かざるを得ない---つまり、CかC++ってことだ。 そのせいで、これらの言語は、特に管理職や投資家のような非技術者の間では、 「本格的な」ソフトウェア開発の言語だと思われるようになったみたいだ。 でも、それはデスクトップソフトウェアの開発の現状から生まれた 副作用にすぎない。サーバベースのソフトウェアでは、 望みのどんな言語でも使うことができる [3]。 こんにちでは、優れたハッカー達の多くがCやC++からかけはなれた言語を 使っている。Perl、Python、あるいはLispでさえも。
サーバベースのソフトウェアでは、あなたにこの言語を使えと 指示する人はいない。あなたがハードウェアに至るまで全てのシステムを 制御しているからだ。異なる仕事に向いた、異なる言語がある。 それぞれの仕事にいちばん向いた言語を使えばいい。 もしライバルが現れたら、むしろあなたは積極的に異なる言語を使うべきだ (この点は後でまた述べよう)。だって、あなたがそのチャンスを利用しなかったら、 ライバルが利用してしまうだろうからね。
我々のライバルの多くはCやC++を使っていて、そのせいで 彼らのソフトウェアは(他の多くの欠点に加えて)見かけがみすぼらしかったし、 CGIスクリプトが状態を持たないという点を回避できていなかった。 何かを変えたければ、ページ内で全てを編集して、ページ下の 「更新」ボタンを押すしかなかった。他のところで書いたように、 未だに多くの人には研究用言語と考えられているLispを用いることで、 我々はViawebのエディタを、デスクトップソフトウェアのように ふるまわせることができたんだ。
この新世界における最も重要な変化のひとつは、リリース方法だ。 デスクトップソフトウェアビジネスでは、リリースはでっかい頭痛の種だ。 会社を挙げて頑張って、ひとつの巨大なコードの塊を仕上げる。 それと比べてみれば、開発プロセスと結果の製品の両方で、 変化を見て取ることができる。
サーバベースのソフトウェアでは、自分用に書いているプログラムと ほとんど同じような感じで変更を加えることができる。 ソフトウェアのリリースは、たまにある爆発のようなものではなく、 段階的な変更の連続になる。普通のデスクトップソフトウェア会社は、 年に1〜2回、リリースするだろうか。Viawebでは、ときには1日に3〜5回の リリースをすることがあった。
この新しいモデルに切替えてみれば、ソフトウェアの開発プロセスが リリース方法にどれだけ影響されているかがわかるだろう。 デスクトップソフトウェアビジネスの危険な問題の多くは、 このリリース方法の混乱する性質に起因している。
年に1回だけ新しいバージョンをリリースするとしたら、 バグをまとめて処理しなくちゃならなくなりがちだ。 リリース日のしばらく前に、半分がたコードを入れ換えた新しいバージョンを かき集める。その中には数え切れないほどのバグが隠れている。 そこで品質管理部隊が登場して、バグをリストアップし、プログラマが それを片っ端から直して行く。だいたいは、リストの最後まで全部終える ことはない。実際、どこでリストが終わるのかさえわからないことが多いだろう。 池からがらくたを引き揚げるようなものだ。 ソフトウェアの中で正確に何が起こっているかを完全に知ることは できないだろう。せいぜい、確率的に正しい、という状態に持ってゆければ御の字だ。
サーバベースのソフトウェアでは、ほとんどの変更は小さく、段階的だ。 それだけで、バグが忍び込む可能性が低い。また、リリースする前に 何を重点的にテストすれば良いのかもわかる。最後に変更したところだ。 結果として、コードをがっちり掴んでいることができる。 中で何が起こっているかがはっきりわかるんだ。 もちろん、ソースコードをすっかり暗記出来る人なんていないが、 パイロットが計器盤を監視するみたいな感じでソースを読むことができるだろう。 探偵が謎を解き明かすように読むんじゃなくてね。
デスクトップソフトウェアは、バグに関して、それがある種仕方のない ものだという観念を養ってきた。バグでいっぱいの製品を出荷して、 例えばパッチリリースみたいにそれを埋め合せる方法も提供して、 その上2つ3つ新しいバグが出たからどうたっていうんだ? すぐに、新しい機能満載(でも動かないけど)のリリースを出すんだから。 Appleは今年はじめにそれをやった。 いくつかの機能(CDとDVDのサポート)がまだ終わってないのに、 もう4回もリリースを伸ばした新しいOSをどうしても出さなくちゃならないという プレッシャーに耐えられなかった。どうしたかって? 未実装の部分を除いたOSをリリースして、ユーザはその部分を 後でインストールしなくちゃならなかったんだ。
Webベースのソフトウェアなら、動く前にソフトウェアをリリースしなくちゃ ならないなんてことはないし、動いたらすぐにリリースできる。
この業界に長い人はこう考えるかもしれない。 動くまでソフトウェアをリリースしないってのは素敵だけれど、 ある日付までに特定のバージョンを出すって約束してたとしたらどうなるんだい。 Webベースソフトウェアでは、そんな約束はしないんだ。 だってバージョンってものが無いんだから。 ソフトウェアは徐々に、連続的に変化してゆく。 大きい変更も小さい変更もあるだろうけれど、バージョンという考え方は Webベースソフトウェアには馴染まない。
Viawebを覚えている人ならこれを聞いてちょっと疑問に思うかもしれないね。 我々はいつだって新しいバージョンってやつをアナウンスしていたから。 あれは純粋に宣伝のためにやっていたんだ。業界のニュースを報道する人達は、 バージョン番号で考えるってことを我々は知った。 メジャーリリース、つまりバージョン番号の最初の桁が変われば、 詳しく報道してくれる。マイナーリリース、つまりピリオドの後のバージョン番号の 変更のときは、一段落ほどの扱いになる。
我々のライバルのうちの何社かはデスクトップソフトウェアを提供していて、 実際にバージョン番号を持っていた。そしてリリースの度に、 我々から見れば彼らが遅れていることの証明でしかないようなことがらが、 大々的に報道されていた。 それに乗り遅れたくはなかったので、我々も自分のソフトウェアにバージョン番号を つけることにしたんだ。宣伝が欲しくなったら、その前の「リリース」からこっち 追加した機能のリストを作って、ソフトウェアに新しいバージョン番号を振って、 「新バージョン直ちに出荷！」とプレスリリースを流したんだ。 おもしろいことに、誰もそれについて文句をつけることはなかった。
会社が買収されるまでに、それを3回やったから、バージョン4まで 行ったことになる。私の記憶が正しければ、確かバージョン4.1だった。 ViawebがYahoo Storeになってからは、そこまでして広告を打つ必要は なくなったから、ソフトウェア自体はどんどん進化していたけれど、 バージョン番号ってものはひっそりと消えてしまった。
Webベースのソフトウェアのもうひとつの技術的な利点は、 多くのバグを再現できるということだ。自分の手元のディスクに ユーザのデータがあるわけだから。誰かがソフトウェアを壊してしまったとき、 デスクトップソフトウェアの場合のように、何が起きているかを推理する 必要はない。ユーザの電話に答えている間に、同じエラーを再現できるんだ。 それどころか、アプリケーションにエラーを通知するコードを仕込んでおけば、 ユーザが電話をかけて来た時には既にエラーの所在を知っていることだって可能だ。
Webベースソフトウェアは一日中使われているから、 どんな変更も直ちに試練に晒される。バグは素早く現れる。
しばしば、ソフトウェア会社はユーザにデバッグをさせていると 非難されることがある。私がここで言っていることも、ユーザにデバッグをさせる ということに他ならない。でも、Webベースソフトウェアではそれはむしろ よい方策なんだ。バグは少ないし、ごく一時的なものだからだ。 ソフトウェアを段階的にリリースすれば、はるかに少ないバグから始めることに なるし、エラーを再現できて変更を直ちにリリースできるということは、 ほとんどのバグは見つかるや否や修正されることになる。 Viawebでは、正式なバグトラッキングシステムが必要なほどバグがたまることは 一度も無かった。
もちろんリリースの前に変更箇所をテストするのは当然で、 大きなバグがリリースされるようなことはあってはならない。 ただ、どうしてもテストをすりぬけてしまったごく少数のバグがあったとしても、 それに影響を受けるのは、苦情の電話が来るまでにそのバグに出会ってしまった 少数のユーザだけだ。バグを直ちに修正するのであれば、全体として、 平均的なユーザにとってはバグがはるかに少ないことになる。 平均的なViawebユーザは、バグに出会ったことさえないんじゃないかと思う。
新鮮なバグを直すのは、古いものを直すよりも簡単だ。 書いたばかりのコードからバグを見つけるのは、たいていは素早くできる。 それどころか、バグを見た瞬間に、ソースを見なくてもだいたいどこが 悪いか見当がつくことさえある。そういうところは、意識下で なんとなく気にしていたりするものだからだ。 年1回のリリースなら、平均して6ヶ月前に書いたコードのバグを見つけることに なるが、それはずっと難しい。そして、コードの理解が行き届かないうちに 修正すれば、その修正はぶかっこうなものになりがちで、新しいバグを 入れてしまうことだってある [4]。
バグを早めに見つければ、複合したバグに悩まされることも少なくなる。 複合したバグとは、別々のバグが相互に影響を及ぼしているようなものだ。 まるで、階段を降りるときにつまづいて、あわてて手すりを掴んだら それが外れてしまった、みたいな羽目になる。 ソフトウェアではそういう類のバグは最も見つけにくく、また 最悪の結果をもたらすことも多い [5]。 伝統的な、「とりあえず壊れるにまかせて後でバグを直してけばいい」という 方法は、本質的にたくさんの複合バグを生み出す。一方、小さな変更だけで 次々にリリースされるソフトウェアは、本質的に複合バグが出にくい。 床はつねに綺麗に掃かれていて、あとでどっかにひっかかりそうな 邪魔なものはきちんと片付けられている。
関数的プログラミングと呼ばれる手法を使うのも役に立つ。 関数的プログラミングとは、副作用を避けることだ。 商用ソフトウェアよりは研究論文でよく目にする言葉だけれど、 Webベースアプリケーションではこれが非常に役に立つことがわかった。 全てのプログラムを純粋に関数的に書くのは難しいけれど、 かなり多くの部分を関数的に書くことはできる。 そういう部分は状態を持たないから、独立してテストするのが簡単だ。 小さな変更を常にテストしているような環境ではこれはとても便利だ。 私はViawebのエディタの大部分をこのスタイルで書いたし、 我々の作った専用スクリプティング言語であるRTMLは、純粋関数型言語だった。
デスクトップソフトウェアビジネスから来た人には信じ難いことだろうけれど、 Viawebではバグはほとんど狩りの獲物みたいなものになっていった。 リリースに紛れ込んでしまったバグのほとんどは境界的な場合だったため、 バグを見つけるのは、限界を押し広げようとしている進んだユーザであることが 多かった。進んだユーザはバグに対してより寛容だし、特に そのバグがユーザの望んだ機能を追加する過程で入ったものであればなおさらだ。 実際、バグが滅多になかったから、バグを見るためにはかなり高度なことを やらなくちゃならなかったので、進んだユーザはバグを見つけたことを自慢した くらいだ。サポートにかかって来る電話は、怒りにまかせたものよりも、 まるで我々から一本取った、みたいな勝利の響きを持ったものが多かった。
エラーを再現することができると、カスタマーサポートの方法も違って来る。 多くのソフトウェア会社では、サポートはどっちかっていうと顧客の 機嫌をとりなすためのようなものだ。ユーザは、既知のバグについて かけてくるか、何か間違った操作をしてあなたにそれを解決してもらいたがってる。 どっちにせよ、サポートに電話をしてきたユーザからあなたが学べることは あまりない。結果として、サポートの電話は苦痛の根源になり、 開発者をそんなものからはなるべく離しておきたいと思うようになる。
Viawebでは全く違っていた。Viawebではサポートは無料で、 というのもユーザからのフィードバックは大歓迎だったからだ。 誰かが問題に当たったら、我々はすぐにそれを知りたかった。 そうすればエラーを再現できて、修正をリリースできるからだ。
だからViawebでは開発者はいつもサポート部門と緊密に連携していた。 カスタマーサポート部門はプログラマから10mと離れていないところに いて、バグだとはっきりわかっていることがらに関してはいつでも プログラマの仕事に割り込むことができた。バグが重大なものなら、 取締役会だって抜け出した。
我々のサポートのやり方は、みんなを幸せにした。 ユーザは喜んだ。サポートに電話して、まるで重要なニュースを もたらしてくれた人のように扱われることを想像してみてほしい。 カスタマーサポートスタッフはその仕事が気に入った。 ただ与えられたマニュアルを読み上げるんではなく、実際に問題解決の プロセスに関われたからだ。 そしてプログラマもそれが気に入った。 また聞きの、曖昧なバグレポートなんかではなく、実際にバグを再現することが できたからだ。
バグをその場で修正するという我々の方針は、カスタマーサポートスタッフ とハッカーの関係を変えた。多くのソフトウェア会社では、サポート要員は 安い給料で雇われる人間の壁で、一方ハッカーは偉大なる神の小さき分身、 世界の創造者だ。バグレポートの方法が何であれ、それは一方通行のものに なりがちだ。サポートスタッフはバグのことを聞いて、一定の様式の書類を 埋め、いずれ(QA部門を通ることもあるが)それがプログラマの手元に届き、 プログラマはそれをやるべきことのリストに加える。Viawebでは様子は大きく違っていた。 ユーザからのバグがあがって来て1分もたたないうちに、 サポートスタッフはプログラマの横に立っていて、 プログラマが「あちゃー、君の言う通りだ。これはバグだね」というセリフを 聞いている。ハッカーから「君の言う通りだ」と聞くことを、 サポートスタッフは大いに喜んだ。彼らの以前の経験では、 バグをプログラマのところに持ってゆくと、 まるで猫が殺したての鼠をくわえてきたかのような顔をされていたのだ。 さらに、このことによって、サポート要員はバグの重大性についてより 注意深くなった。自分の名誉がかかっているわけだから。
Yahooに買収されてから、カスタマーサポートはプログラマから 離れてしまった。実は、そうなって初めて、我々はカスタマーサポートとは 実質的に品質管理部門であり、また営業部門でもある、ということに気づいたんだ。 バグをつかまえるのに加えて、サポート要員は「バグに近いような曖昧なこと」、 例えばユーザを混乱させるような機能についての知識を蓄えていた [6]。また、ある意味で彼らはフォーカスグループの代理でも あった。ふたつの機能のどっちがユーザに望まれているかを尋ねると、 いつでも正しい答えが返ってきたからだ。
ソフトウェアを直ちにリリースできるということは、 大きな励みになった。出勤する途中でソフトウェアに加えたい変更を 考えて、その日のうちに実装してしまうことがよくあった。 大きな機能でもこれはうまくいった。書くのに2週間かかるような ものでさえ(それ以上かかるプロジェクトなんてほとんどなかった)、 できあがったら直ちにその効果を見られると知っていたからだ。
効果を見るのに1年後のリリースを待たねばならなかったとしたら、 これらの多くのアイディアを、すくなくとも暫くの間はどこかに仕舞って いたことだろう。でも、アイディアが大事なのは、それがもっと多くのアイディアに 結び付くからだ。腰を据えて何かを書き始めて、書きあがってみたらその中の アイディアの半分は書きながら思い付いたことだった、っていう経験は無いかい。 ソフトウェアにもそういうことがある。ひとつのアイディアを実装してゆく 過程で、もっとたくさんのアイディアがひらめくんだ。 だから、アイディアを仕舞ってしまうことは、ただ単にそれの実装が遅れる だけでなく、それを実装することで得られたであろう全てのアイディアを 失うことになる。実際、アイディアを寝かせておくことは、 新しいアイディアを得る邪魔にさえなり得る。 新しい機能を考えはじめる度に、やるべきことが溜っている棚が目に入って、 「うーん、でも次のリリースまでにやりたいことがもうこんなにあるんだよな」と なるからだ。
大企業が、機能を実装するかわりにやることは、それを計画することだ。 Viawebでも、この点に関して時々問題になった。 投資家やアナリストは、我々の将来の計画についてよく質問した。 でも正直なところ、我々には何も計画がなかった。そりゃあ改善したい点についての 漠然としたアイディアはあったけれども、それをどうやるかがわかった時点では、 もうその実装が終わっている状態だった。次の6ヶ月で何をするかって? 何であれ最大のメリットが得られるようなものさ。もちろん そんなことを言い出す勇気は無かったけれど、それが正直なところだった。 「計画」っていうのは、「棚に積まれたアイディア」を言い替えたものだ。 よいアイディアを思いついたら、我々はすぐにそれを実装していた。
Viawebでは、他の多くのソフトウェア会社と同じように、コードの多くは 一人の所有者が決まっていた。でも、何かを所有するってことは、 本当に所有することを意味していた。 そのソフトウェアの所有者は、他の誰にもリリースについて許可を得る 必要はなかったし、そのリリースがあることさえ知らせる必要がなかった。 何かを壊してしまうことに対する安全ネットはただ一つ、そんなことをしたら 同僚に対して恥ずかしいってことで、それで十分だったんだ。 いままでの私の話で、我々はやみくもにソフトウェアを書き続けていたような 印象を持たれたかもしれない。我々は確かに速く進んでいたけれど、 サーバにソフトウェアをリリースする前には十分に注意深く考えたんだ。 信頼性にとって重要なのは、 ゆっくり動くことよりも、注意を払っておくことだ。 十分に注意を払っているからこそ、空軍のパイロットは、 ふつうのティーンエイジャーがベーグルを切るのよりもっと安全に、 時速200キロで飛んでいる18トンもある航空機で 傾いた空母のデッキに夜間着陸をやってのけるんだ。
こんなソフトウェアの書き方は、もちろん両刃の剣だ。 信頼できる、良いプログラマからなる小さなチームでの方が、 大企業での平凡なプログラマからなるチームよりもうまくいく。 後者では、悪いアイディアは、それを考えた人が気づいて直すのではなく、 委員会まで先送りされてしまうからだ。
幸いなことに、Webベースソフトウェアは少数のプログラマしか 必要としない。私は中規模のデスクトップソフトウェア会社で働いたことが ある。そこには技術部門全体で100人以上のスタッフがいた。 そのうち13人だけが製品開発部門だった。残りの皆は、 リリースとか、移植とか、そういうことをやっていた。 Webベースソフトウェアでは、必要なのは最大でもこの13人だけってことになる。 リリースやら移植やらの作業が要らないわけだから。
Viawebは3人で書いた [7]。 私はいつでも、もっと人を雇わなくちゃならないんじゃないかというプレッシャーを 感じていた。というのも、いずれ買収されることを望んでいたんだが、 プログラマがたった3人しかいない会社に高い金を払う買い手は あまりいないからだ。(解決策：我々はもっとプログラマを雇ったけれど、 その分、新しいプロジェクトを作ったんだ)。
ソフトウェアをより少ない人数で書くことができれば、 人件費以上のものが節約できる。フレッド・ブルックスが「人月の神話」で指摘したように、 プロジェクトに人員を追加することは、プロジェクトを却って遅れさせがちだ。 開発者間の可能な連携の数はグループの大きさに対して指数的に増大する。 グループが大きくなればなるほど、スタッフは各ソフトウェアがどう協調すべきかを 話し合うミーティングにより多くの時間をとられ、意図しなかった相互作用から 生まれるバグも増えて行く。幸いなことに、このプロセスは逆方向にも動くんだ。 グループが小さくなればなるほど、ソフトウェアの開発の効率は 指数的に増大する。Viawebで、プログラマがミーティングというものを したことがあったか、思い出せない。昼食での会話以上に 話し合わなければならないことを抱えていたことなんて無かった。
欠点があるとすれば、それは全てのプログラマがある程度は システム管理者でもなければならないということだ。 ソフトウェアをホストしていれば、誰かがサーバを監視していなければならない。 そして、現実にはその仕事に適任な唯一のスタッフは、ソフトウェアを開発した 本人に他ならない。Viawebではシステムは膨大なコンポーネントから 構成されていたし、変更も非常に多かったので、ソフトウェアと インフラとの間に明確な境界線は無かった。そこに適当な境界線を 設けることは、我々のデザイン上の選択の足かせになっただろう。 我々も、いつの日か(「あと2ヶ月のうちには…」)全てが落ち着いて、 サーバを監視するためだけのスタッフを雇いたいと望んでいたけれど、 それはついにかなわなかった。
製品を積極的に開発している限り、別の選択肢は無かったと思う。 Webベースソフトウェアは、一日の分を書いて、チェックインして、 家に帰る、みたいなものにはならない。それは生きていて、 今まさにサーバ上で走っているんだ。最悪のバグがあれば、 それは一人のユーザのプロセスだけでなく、全てのシステムをクラッシュさせて しまうかもしれない。自分のコードのバグがディスク上の何かのデータを 壊したら、自分で直さなくちゃならない。全てがそんな具合だ。 1年ほど運用したら、そう神経質にサーバを常時監視している必要はないことは わかったが、それでも最近更新したものに関しては注意を 怠ることはできない。夜遅くにコードをリリースしてそのまま家に帰ってしまう、 ということはできないんだ。
サーバベースのソフトウェアでは、コードにより密に接していることができる。 それだけでなく、ユーザにもより密に接することができるんだ。 Intuitは、小売店で製品を買う客に、マーケットリサーチャが家まで同行して インストールするところを見せてもらえないかと頼むことで有名だった。 自作のソフトウェアをユーザが最初に触る様子を見たことがあるなら、 彼らが顧客の自宅でびっくりするようなことを目にしたであろうとは 想像に難くない。
ソフトウェアは、ユーザが期待するように動作すべきだ。 でも、ユーザが何を期待するかなんて、実際にユーザを見てみるまでは 見当もつかないんだ。サーバベースソフトウェアでは、 ユーザの振舞いについて、他では得がたい情報を与えてくれる。 作為的な小さいフォーカスグループに限定されることはない。 全てのユーザが行う、全てのクリックを見ることができるんだ。 もちろんユーザのプライバシーを侵すことはできないから、 何を見るかについてはじっくり考えなくちゃならないけど、 ごく一般的な統計的サンプリングでさえ、とても有用だ。
例えば、ユーザが実際にサーバ上にいると、ベンチマークに頼る必要は 無くなる。ベンチマークはシミュレートされたユーザだ。 サーバベースソフトウェアでは、実際のユーザを見ることができる。 何を最適化すればいいかを見つけるには、単にサーバにログインして、 CPUを食いつぶしているのがいったい何かを見るだけでいい。 どこで最適化を止めたらいいかを知ることもできる。 我々はViawebのエディタを、CPUではなくメモリが律速になるところまで 最適化した。そこまで行ったらあとはユーザのデータのサイズを減らすしか ない(それは簡単じゃない)。だから、そこで止められるということがわかったんだ。
効率はサーバベースソフトウェアでは重要だ。 ハードウェアに金を払っているのはあなたなのだから。 サーバ当たりどれだけのユーザをサポートできるかが、 資本コストの分母に効いて来るから、ソフトウェアを非常に効率良く書けば、 競争相手より安く提供してなお利益を上げることができる。 Viawebでは、ユーザ当たりの資本コストを$5程度まで下げることができた。 今ではもっと安いだろう。多分、最初の月の請求書を郵送するコストより 安くなったんじゃないだろうか。ソフトウェアが十分に効率良ければ、 今ではハードウェアはただみたいなものだ。
ユーザを見ることは、最適化だけでなく、設計上の指針にもなる。 Viawebでは、進んだユーザはRTMLというスクリプティング言語を使って 自分のページスタイルを定義できた。我々は、RTMLが一種の目安箱に なっていることに気づいた。というのも、ユーザがRTMLを使うということは、 組み込みのページスタイルではユーザのやりたいことが出来ないということだったからだ。 例えば、最初のエディタはボタンバーをページに横長につけていたのだが、 たくさんのユーザがRTMLを使ってボタンを左側に縦に並べるのを見て、 そういうスタイルも組み込みのものにした(実際、それをデフォルトにしたんだ)。
最後に、ユーザを見ることで、ユーザがどこで困っているかを 知ることができる。そして、ユーザはいつでも正しいのだから、 それは何かを直さなくちゃならないということだ。 Viawebでは、ユーザを得るための鍵はオンラインの試用サイトだった。 広報部門が作ったスライドなんかじゃない。 試用サイトでは、ユーザは実際にソフトウェアを使うことができた。 5分ほどで、実際に動作するオンラインストアを構築することができた。
[試用サイトはまだオンラインだけれど、今はいくつかのフォームを 埋めなくちゃならなくなったし、作ったサイトが実際に使えるものだと 教えてくれなくなった。あなたが試用サイトを試してみたなら、 "foo"をあなたが選んだidとすれば、作り終わったオンラインストアは store.yahoo.com/fooでアクセスできる]
試用サイトこそが、ほとんど全てのユーザを獲得した方法だった。 大抵のWebベースアプリケーションはそうなんじゃないだろうか。 ユーザが試用サイトを無事最後まで進めたら、ユーザはその製品を気に入るだろう。 でも、もし途中で混乱したり飽きたりしたら、気に入らないだろう。 だから少しでも多くの人々に試用サイトを最後まで使ってもらうことが、 成長を加速することに直結していた。
私は試用サイトでの人々のクリック履歴を調べて、あるステップで 多くのユーザが混乱してブラウザのBackボタンをクリックすることを見つけた。 (Webベースのアプリケーションを書いて見ると、Backボタンは最も哲学的な 問題であることがわかるだろう)。そこで、私はそのステップで、 もうほとんど最後まで来たのでBackボタンを押さないようにユーザにお願いする メッセージを入れた。 Webベースソフトウェアのもうひとつの素晴らしい点は、 フィードバックが直ちに得られることだ。 試用サイトを最後まで使う人の割合が、60%から90%に跳ね上がったんだ。 新規ユーザの数は試用サイトを最後まで使った人の関数だから、 このたったひとつの変更で、我々の利益は50%増加したことになる。
1990年代の始め頃、ソフトウェアはサブスクリプションビジネスになるだろう という記事を読んだ。最初は、それがずいぶんシニカルな意見に思えたものだ。 だが、後に私はそれが現実を反映していることを知った。 ソフトウェア開発は継続するプロセスだ。 だから、人々に次々と新しいバージョンをインストールさせることで 収益を得るよりも、はっきりと購読料という形で料金を設定した方が明解だろうと思う。 うまい具合に、Webベースアプリケーションではサブスクリプション形式が 自然な課金法だ。
アプリケーションのホスティングは、フリーウェアによって 会社の活動の余地が無くなってしまわない分野のひとつだろう。 ホスティングはストレスの多い活動だし、実際の経費もかかる。 無料ではやっていけない。
会社にとっても、Webベースアプリケーションは理想的な収益源だ。 毎四半期を白紙で始めるかわりに、定常的な収益が上がって来る。 ソフトウェアは徐々に進化するから、新モデルが失敗することを 心配する必要はない。いわゆる新モデルというのが必要になる ことはないわけだし、ユーザがソフトウェアの何かを気に入らなかったら すぐにそれと知ることができる。回収できない請求を抱えることもない。 料金を払わない人に対しては、サービスを打ち切るだけでいい。 また、海賊版が出回る可能性もない。
上に挙げた最後の「利点」は、もしかすると問題かもしれない。 ソフトウェア会社にとっては、ある程度の海賊版は役に立つこともある。 どんな値段でも正規には絶対に買わないというユーザがいるのなら、 その人が海賊版を使ったところで、何も失ってはいないわけだ。 実際は、そういう人もあなたのソフトウェアをデファクトスタンダードに するのに役立つ一人になってくれているから、利益であるとも言える。 それに、そういう人だって高校を卒業したら、ちゃんと金を払って 正規版を買ってくれるかもしれない。
会社は、可能な限り、価格差別と呼ばれるものをやりたがる。 各ユーザに対してそれぞれが払えるだけ払わせるというやりかただ [8]。ソフトウェアは限界コストがゼロに 近いので、 特に価格差別に適している。 これが、Sun上で走るバージョンがIntel PCで走るバージョンより高い ソフトウェアがある理由だ。Sunを使っている企業は金にしぶくないから、 値段を高くしても大丈夫というわけだ。ソフトウェア会社は この原理を理解して、ある種の海賊版を黙認しているんじゃないかと思う [9]。 サーバベースのソフトウェアでは、そういう会社は 別のソリューションを必要とするだろう。
Webベースソフトウェアは、特にデスクトップソフトウェアに比べ、 良く売れるだろう。買うのが簡単だからだ。 人がものを買う時に、まず最初に買うことを決めて、それから買う、という 2つのステップがあると思うかもしれない。私もViawebを始める前は そう思っていた。もっともほとんどそんなことを考えたことは無かったんだが。 ところが実際は、第2のステップが最初のステップへと逆に伝搬するんだ。 つまり、何かを買うことが難しい場合、人々は自分の心を変えて、 それが欲しくないと思うようにするんだ。逆も成り立つ。 買いやすいようになっていれば、より売れる。Amazonが出来て、 私は本をたくさん買うようになった。Webベースのソフトウェアは 世界中で最も買いやすいもののひとつだろう。特に、オンラインデモを 終えたばかりの人にとっては。ユーザは、クレジットカード番号を入れる以上の 作業をしなくて済むようになっているべきだ (それ以上の作業をさせるなら、 覚悟しておくこと)。
しばしば、WebベースソフトウェアはISPをリセラーとして提供される。 これは悪いアイディアだと思う。自分でサーバを管理すべきだ。 それによって、ハードウェアとソフトウェアの両方を常に改良してゆくことができる。 サーバへの直接の制御を手放したら、Webベースアプリケーションを 開発する利点の多くを手放すことになる。
我々のライバル会社のいくつかは、この方法で自滅してしまった。 多分、彼らは、ISP経由にすることで得られるかもしれない 巨大な収入に目が眩んだスーツ達に乗っ取られて、それによって 売るべき製品を台無しにしてしまうことに気づかなかったのだろう。 WebベースソフトウェアをISPを通じて売るというのは、 寿司を自動販売機で売るようなものだ。
どういった人々が顧客になるだろう。 Viawebでは、最初は個人や小さな会社だった。 私はそれがWebベースアプリケーションの主要な顧客になるだろうと思う。 そういったユーザは新しいことに挑戦してみたがる。 考え方が柔軟だし、 新しい技術によって経費を下げたいという要求もあるからだ。
Webベースのアプリケーションは、大会社にとっても最良のものに なり得る(ただ、大会社がそれに気づくのは遅いだろう)。 最良のイントラネットはインターネットだ。会社がほんとうのWebベースアプリケーションを 使えば、ソフトウェアはよりうまく動くし、サーバはもっと良く管理され、 従業員はどこからでもシステムにアクセスできる。
それに対する反論は、セキュリティに関するものだ。 もし従業員が簡単にアクセスできるなら、悪い人間も簡単にアクセスできて しまうんじゃないか。いくつかの大手の商店は、クレジットカード情報は 自社サーバにあったほうが安全だという理由で、Viawebを使うのを ためらっていた。この点を角が立たないように説明するのは難しいんだが、 現実的にはほぼ確実に、データは彼らに任せておくより我々が扱った方が安全だ。 サーバ運営に特化した技術ベンチャーと、衣料小売店と、どっちが セキュリティを管理するのによい人材を雇えるだろうか。 しかも、ただセキュリティの面倒を見る適任者を雇っていたというだけじゃない。 我々は彼らよりもっとセキュリティに神経を尖らせていた。 もし誰かが衣料小売店のサーバに侵入したとしても、それはせいぜい その小売店にしか影響を与えないし、大したニュースにもならず、 悪くても責任者一人が馘になるだけだろう。だが、もし我々のサーバが侵入されたら、 それは何千という店に影響をあたえ、多分CNetあたりにニュースが出て、 我々は潰れていたかもしれない。
金を安全に保管したかったら、ベッドの下に隠しておくのと、 銀行に預けるのと、どっちを選ぶ? この議論はサーバ管理の全ての面に 適用できる。セキュリティだけじゃない。アップタイム、バンド幅、 負荷管理、バックアップ、等々。我々は、 これらの仕事をちゃんとこなすことを前提に存在しているんだ。 サーバが問題を起こすのは、我々にとって何が何でも避けるべきことだった。 ちょうど、おもちゃ屋にとっての危険なおもちゃとか、 食品業者にとってのサルモネラ菌などと同じようなものだ。
大会社にとって、Webベースアプリケーションを使うことは ITをアウトソースするということになる。過激に聞こえるかもしれないが、 私はそれは一般的に良いことだと思う。社内のシステム管理者に任せるよりも よいサービスを得られるようになる会社が多いだろう。 システム管理者は、競争的なプレッシャーに晒されていないと、 融通がきかなくなり、適切な反応ができなくなる。 セールスマンは常に顧客に接しているし、 開発者はライバルのソフトウェアと競わなくちゃならない。 でも、システム管理者は、独身の老人のように、 きちんとしなくちゃならないっていう外圧があまり無いんだ [10]。 Viawebでは、我々はちゃんとしなくちゃならないって外圧が うんざりするほどあった。何かあって電話をかけてくるのは 同僚じゃない、顧客だ。サーバがおかしくなりそうな気配を 見せるだけで、我々は飛び上がったものだ。何年もたった今でさえ、 そのことを考えるだけでアドレナリンがどっと出るのを感じる。
だから、Webベースのアプリケーションは、大会社にとっても 普通に正しいソリューションとなってゆくだろう。ただ、大会社は 誰よりも遅くそのことに気づくだろう。ちょうどデスクトップコンピュータに 関して彼らがそうだったように。たぶん、その理由も似たようなものだ。 大会社に、より高いものを売りつけるために、より多くの金を費すことには 十分に見返りがあるからだ。
金持ちの顧客は、たとえ安くてしかも良いソリューションがあっても、 高いソリューションを買う傾向がある。高いソリューションを提供するところは それを売るためにも多くの費用をかけているからだ。Viawebではいつも そういうことに反対していた。ハイエンドの顧客のいくつかを、 50万ドルで自社サーバ上でカスタムオンラインストアを作ることを提案した Webコンサルティングファームに持って行かれた。そういうところは べつに我々より良かったわけじゃない。クリスマスのショッピングシーズンが 近付いて、サーバロードが跳ね上がった時に、そのことは露呈した。 Viawebはそういう大口顧客が建てたサーバよりもずっと優れたシステムを 構築していたのだけれど、それを伝えるだけの予算がなかったのだ。 月に$300という広告経費では、さっぱりとしたスーツをぴしっと着こなして 荘重なプレゼンを披露する営業部隊を雇うことなんてとてもできなかった。
大企業が余分に支払っている金の多くは、それをその会社に売り込むために 使われている。(たとえば、国防省がトイレの便座に$1000払っているとしよう。 それがそんなに高価なのは、トイレの便座を$1000で売るには多大な経費がかかるからだ)。 この原理のおかげで、イントラネットソフトウェアは、 おそらく悪いアイディアであるにもかかわらず、長く生き残るだろう。 単にそれが高価だというだけで。 この難問に対してできることはほとんどない。だから、 まず最初に小さな顧客を相手にするのが良いだろう。 残りは後からついてくる。
ソフトウェアをサーバで走らせるのは別に新しいことではない。 いや、むしろ古いモデルと言えるだろう。メインフレームの時代、 アプリケーションは全てサーバベースだった。 サーバベースソフトウェアがそんなに良いアイディアなんだとしたら、 どうして前回、このモデルは敗れたんだろうか。 なぜ、デスクトップコンピュータがメインフレームに勝ったんだろう。
当初、デスクトップコンピュータはたいした脅威には見えなかった。 最初のユーザ達はみんなハッカーだった(当時はホビイストと呼ばれていた)。 彼らがマイクロコンピュータを気に入ったのは、それが安かったからだ。 初めて、彼らは自分のコンピュータというものを所有することができたんだ。 「パーソナルコンピュータ」というフレーズは今ではふつうの言葉だが、 最初に使われた時、それにはむしろ自慢げな響きが含まれていた。 ちょうど、現代で「パーソナルサテライト」とかいう言葉の響きのようなものだ。
どうしてデスクトップコンピュータが台頭したんだろう。私の考えは、 デスクトップの方により良いソフトウェアがあったからだ。そして、 マイクロコンピュータのソフトウェアの方が良かった理由は、 小さな会社がそれを書くことが可能だったからだ。
立ち上がったばかりのベンチャーが、どれだけ脆く、不確かなものであるかを 知っている人はあまりいないんじゃないかと思う。 多くのベンチャーは、ほとんど偶然のようにして始まる。 例えば、昼は仕事を持ってたり学校に行ってたりする2人の若者が、 ちょろっとプロトタイプを書いてみて、それがいけそうだったら 会社にするってな具合だ。この幼生期においては、適当な大きさの障害が ひとつあれば会社はそこで止まってしまう。 メインフレームソフトウェアを書くためには、始めるまえに多大な コミットメントが必要だ。開発機器は高価だし、顧客は大会社になるから、 よりすぐりのセールス部隊を用意して売り込みをかけなくちゃならない。 メインフレームソフトウェアを書くベンチャーを立ち上げるのは、 夜に自分のApple IIをハックして何かを書くようなベンチャーよりもずっと 大掛かりな事業になる。これが、メインフレームアプリケーションを書くベンチャーが あまり生まれない理由だ。
デスクトップコンピュータの到来は多くの新しいソフトウェアを生み出した。 幼生期のベンチャーにとって、それ用のソフトを書くことは到達可能なゴールに 見えたからだ。開発は安価で、顧客はコンピュータショップや 手紙での注文をしてくるような個人だった。
デスクトップコンピュータを主流にのし上げたアプリケーションは、 最初のスプレッドシート、 VisiCalcだ。 それは、2人の若者によって 屋根裏で書かれ、それでいてどのメインフレームソフトウェアも なし得なかった機能を持っていた[11]。 VisiCalcが当時はあまりに斬新だったため、人々はそれを走らせるためだけに Apple IIを買ったものだ。そして、これが現在に至るトレンドの 始まりだった。ベンチャーがソフトウェアを書くことで、デスクトップコンピュータが 勝利を収める。
とすれば、現代においては、サーバベースソフトウェアが有利になるように思える。 ベンチャーがそれを書くだろうから。コンピュータの価格がこれだけ下がったため、 我々がやったように、誰もがデスクトップコンピュータをサーバとして使って 始めることができる。安価なプロセッサはワークステーションの市場をすっかり 喰い尽くし(今では「ワークステーション」という言葉を聞くことさえ滅多になくなった)、 そしてサーバの市場にも大きく食い込んでいる。インターネット上でおそらく 最も多くの負荷をさばいているサーバのひとつであろうYahooのサーバは、 デスクトップマシンが使っているのと同じ、安価なIntelプロセッサを 使っている。そしてソフトウェアを書き上げたら、それを売るのに必要なのは Webサイトひとつだ。Viawebでは、ユーザのほとんどは口コミか 報道を見て直接我々のサイトを訪れた[12]。
Viawebは典型的な幼生期のベンチャー企業だった。 会社を始めるってこと自体、ひどくおっかないことだったから、 最初の数ヵ月は、全てはひとつの実験で、止めたくなったらいつでも 止められると自分たちに言い聞かせていたほどだ。幸いなことに、 技術的な問題以外て、邪魔になるものはほとんどなかった。 ソフトウェアを書いている間、我々のWebサーバは開発に使っていた デスクトップマシンと同じもので、ダイアルアップ回線を通じて 外の世界につながっていた。この時期の経費は食費と家賃だけだった。
いまや、ベンチャーがWebベースソフトウェアを書くべき理由は もっとずっとたくさんある。デスクトップソフトウェアを書くのは どんどんつまらなくなっているからだ。デスクトップソフトウェアを書こうと 思ったら、マイクロソフトの土俵にあがらなくちゃならない。 OSのバグを回避しつつ、彼らのAPIを呼ばなくちゃならない。 そしてやっとのことで、売れるソフトウェアを書き上げた時、 あなたは単にマイクロソフトのマーケットリサーチをやっていただけだった ということを知るのだ。
ベンチャーに何かを書きたいと思わせるプラットフォームを 作ろうとするなら、それはハッカー達が使ってみたいと思うようなものじゃ なくちゃいけない。つまり、安価で、しかも良く設計されているものだ。 Macは最初に出た当時はハッカーの間でとても人気があり、 たくさんのハッカー達がソフトウェアを書いたものだ [13]。 Windowsではそういうことがあまり起こっていない。ハッカー達が使っていないからだ。 ソフトウェアを書くのが得意な人は、今ではLinuxやFreeBSDを使っているだろう。
我々は、たとえチャンスがあっても、デスクトップソフトウェアを書く会社を 立ち上げることは無かっただろうと思う。売れるデスクトップソフトウェア はWindows上で走らなくちゃならない。ということは、ソフトウェアを書く 以前にWindowsを使わなくちゃならないということだ。 Webを利用することでWindowsを回避することができたし、 ブラウザを通じてユーザに直接Unix上で走るソフトウェアを届けることが できた。これはとても解放的な見通しだった。ちょうど、25年前の PCの到来がそうであったように。
デスクトップコンピュータが到来した当時、IBMは誰もが恐れる 巨人だった。今それを想像するのは難しいかもしれないが、私はあの感じを まだ覚えている。現在、そのおそるべき巨人はマイクロソフトだ。 そして、彼らは、かつてのIBMのように迫り来る脅威に盲目ではないと思う。 実際、マイクロソフトは意識的にIBMの盲点をビジネスにしたのだから。
私は上の方で、私の母はデスクトップコンピュータなんて必要じゃないんだ と述べた。たぶん多くのユーザがそうだろう。これがマイクロソフトの問題であり、 そして彼らはそれに気づいている。アプリケーションが離れたサーバで 動くなら、誰もWindowsを必要としない。ではマイクロソフトはどうするだろうか。 デスクトップ上で持っている力を使って、この新世代のソフトウェアを 邪魔したり、制限したりすることが彼らにできるだろうか。
私の推測は、マイクロソフトはある種のサーバ/デスクトップ複合体を 開発するというものだ。OSは彼らが制御するサーバと連携して動作する。 少なくとも、ファイルに関してはユーザが望めば中央のサーバに置いておけるように なるだろう。ただ、マイクロソフトが、クライアントにブラウザだけを置いて 残りの全ての計算をサーバまで持ってゆくまでやるとは私は思わない。 可能な限りそれは避けるだろう。なぜってクライアント側にブラウザだけが 必要なら、クライアントにマイクロソフトは必要ないってことだから。 マイクロソフトがクライアントで制御を失えば、ユーザを彼らのサーバベース アプリケーションへと引っ張り込むこともできなくなる。
マイクロソフトは、このランプの妖精をランプに閉じ込めておくのに 苦労するだろう。色々なタイプのクライアントが出てくれば、それを全て コントロールするのは非常に難しくなる。そしてマイクロソフトのアプリケーションが 特定のタイプのクライアントでしか動作しないとなれば、 ライバルは全てのクライアントで動作するアプリケーションを出すことで マイクロソフトに勝てるだろう [14]。
Webベースアプリケーションの世界には、マイクロソフトの場所は あらかじめ用意されてはいない。もちろん彼らは自分の領地をある程度確保することに 成功するかもしれないが、デスクトップアプリケーションの世界を制覇したように この新しい世界を制覇することはできないだろうと思う。
ライバルに食われるだけじゃなく、自分自身に食われることも心配しなくては ならない。Webベースソフトウェアの台頭により、彼らは単なる技術的な 問題だけではなく、自分の願望というやつに向き合わなくちゃならなくなるだろう。 本当に必要なのは、彼らが今持っているビジネスの基盤を自ら崩すことなんだが、 まだその決断をするには至っていないようだ。 彼らをここまで発展させて来た、強い思い込みが、ここに来て邪魔になっている。 IBMもかつて全く同じ状況に置かれ、それを完全に乗り越えることはできなかった。 メインフレームという金のなる木を傷つけることを恐れるあまり、 IBMのマイクロコンピュータビジネスへの参入は、遅く、中途半端なものとなった。 マイクロソフトも同じように、デスクトップを救おうと望むあまりに 動きがとれなくなるかもしれない。金のなる木は、それを背負っていかなくちゃ ならないとしたら、ものすごく重い荷物になる。
サーバベースアプリケーションの世界に、支配者が現れないと言っているわけじゃ ないよ。いずれ、誰かがこの世界を支配するだろう。でも、たぶんそうなるまでに、 かなり長い、陽気などんちゃん騒ぎが続くと思う。マイクロコンピュータの出現期 がそうであったように。それはベンチャーにとって良い時期だった。 たくさんの小さな会社が芽を出し、クールなものを作ることで花を咲かせた。
伝統的なベンチャー企業は、少人数で資本も少ないが、動きが速く、 格式ばっていない。人数は少ないが、猛烈に働く。 技術は彼らの決断の効果を拡大する。勝つことができれば、見返りは大きい。
Webベースアプリケーションを書くベンチャー企業は、 あなたがベンチャー企業と聞いて思い浮かべる全ての要素を 最大限に引き延ばしたようなところだ。より少ない人数と資本で、 製品を書いて公開できる。より速く動かなくちゃならないし、 社内はよりくだけた感じになる。なにしろ、製品を公開するのに、 マンションの一室のリビングに3人で座ったままできるんだから。 サーバはISPに置いておけばいい。それが我々のやったことだ。
時代を経るにつれ、チームはより小さく、より速く、そして よりくだけたものになってきた。1960年には、ソフトウェア開発というものは、 鼈甲縁の眼鏡をかけ、細い黒ネクタイを締めた部屋いっぱいの男たちが、 IBMのコーディングシートを一日に10行づつ黙々と埋めて行くという ものだった。1980年には、ジーンズを履いて出勤する8〜10人のチームが、 vt100に向かってプログラムをタイプしていた。今や、リビングで 2人のプログラマがラップトップに向かってプログラムするようになっている (それに、ジーンズはまだ十分にカジュアルじゃないってことも証明された)。
ベンチャー企業はプレッシャーも大きいが、この点に関しても、 残念ながら、Webベースアプリケーションでは最大限になる。 ここケンブリッジには、昔、ドイツ美術の美術館だった建物があるのだが、 その壁にはぞっとするような忠告が刻まれている。"Du kannst denn du sollst" --- 「可能なら、やらねばならない」。Webベースアプリケーションでは、 困ったことに、出来ることがいくらでもある。
多くのソフトウェア会社では、とりわけ初めのうちは、 開発者が机の下で眠らなければならないような期間がある。 Webベースソフトウェアで恐いのは、それが日常になることへの歯止めが 無いことだ。普通の「机の下で眠る」話には、必ず終りがある。 ソフトウェアを出荷して、みんな家に帰って1週間眠るんだ。 だが、Webベースソフトウェアは出荷しておしまいというものじゃない。 やろうと思えばいくらでも、一日16時間働き続けられる。 しかも、あなたがそれをできるし、ライバルもそれができるということは、 結果としてそうせざるを得なくなりがちだってことだ。 可能なら、やらねばならない。 これはパーキンソンの法則を逆に適用しているようなものだ。
もっと悪いのは、労働時間ではなく、責任だ。 プログラマとシステム管理者は、普通はそれぞれ違った心配を抱えているものだ。 プログラマはバグについて心配するし、システム管理者はインフラについて 心配する。プログラマは長時間、肘までどっぷりソースに漬かって仕事を しているが、あるところまで到達したら、家に帰ってそれを忘れることができる。 システム管理者は仕事のことをすっかり忘れてしまうことはできないが、 朝4時に呼び出しを食らった場合でも、やるべき作業はたいして複雑でない場合が多い。 Webベースアプリケーションでは、このふたつの異なった責任が 一緒にかかってくるんだ。プログラマはシステム管理者になり、 普通なら仕事を楽にしてくれるはずだった明確な責任の限界が無くなる。
Viawebでは最初の6ヶ月かそこいらは、ソフトウェアを書くだけで過ごしていた。 普通のベンチャー企業の立ち上げ時と同じように、長時間働いていた。 デスクトップソフトウェア会社では、そういう時期が一番きつい時期ということになる。 しかし、我々が経験した次の時期、ユーザをサーバに迎えた時期に比べたら、 ソフトを書くだけで良かった最初の期間はまるで休暇みたいなものだった。 ViawebをYahooに売却したことによる2番目のメリットは(1番目はもちろん金だが)、 この究極の責任を全て大会社に背負ってもらえたということだろう。
デスクトップソフトウェアはユーザがシステム管理者になることを強いると 書いたが、Webベースソフトウェアではプログラマがシステム管理者になることを 強いるとも言える。トータルとしてのストレスは減少するが、プログラマにとっての ストレスは増大する。もっとも、これは悪いことばかりではない。 もしあなたが大会社と競っている立ち上がったばかりのベンチャーだとしたら、 これは良いニュースだ[15]。 Webベースアプリケーションは競争相手に仕事で勝つための、直接の方法を 提供してくれる。それはベンチャーに取って一番ありがたいものだ。
Webベースアプリケーションを書くことをためらわせる要因のひとつは、 WebページをUIとして見た場合の貧弱さだろう。 これは確かに問題だ。HTMLとHTTPに追加してもらえたらと切望することは 確かにいくつかある。だが、重要なことは、Webページはとりあえずは使えるという ことだ。
ここにも、初期のマイクロコンピュータと通じるものがある。 それらのマシンのプロセッサは、本物のコンピュータのCPUを目指して いたわけじゃなかった。むしろ、例えば信号機のようなものを制御する 機器として設計されていたんだ。でも、Altairを設計したエド・ロバーツのような 人間が、それはとりあえず使うには十分だということに気づいたんだ。 そういうチップと、いくばくかのメモリ(最初のAltairでは256バイトだった) を組み合わせて、スイッチつきのフロントパネルをくっつければ、 動作するコンピュータが出来た。自分でコンピュータを持てるということは 当時は凄いことだったから、やれることにどんなに制限があっても、 それを買いたいという人はたくさんいたんだ。
WebページはもちろんアプリケーションのUIになるために設計された わけじゃないけれど、それはとりあえずは使える。そして、非常に多くの ユーザにとっては、どのブラウザでも使えるソフトウェアというのは それだけでUIの不格好を補って余りあるメリットがある。 もちろん、HTMLでかっこいいスプレッドシートを書くことはできないだろう。 でも、特別のクライアントをインストールすること無しに 別々の場所から複数人で使えるスプレッドシートがあったらどうだい? あるいはライブデータが取り込まれたり、何かの条件が満たされたら 自動的に通知してくれる機能はどうだい。 さらに重要なことに、まだ名前がついてないような新しい種類のアプリケーションを 書くことだってできる。VisiCalcはメインフレームアプリケーションの 単なるマイコン版ではなかった。それは新しい種類のアプリケーションだったんだ。
もちろん、サーバベースのアプリケーションが必ずしもWebベースで なければならないわけじゃない。他の種類のクライアントを使うことも考えられる。 ただ、私はそれは悪いアイディアだと思う。もちろん、皆があなたのクライアントを インストールしてくれると仮定できるなら、こんなに便利なことはない。 (あまりに便利だから、思わずそれが出来ると信じてしまいそうだ)。 でも、もし皆がそうしてくれなかったら、おしまいだ。Webベースソフトウェアは クライアントに関して何も仮定しないために、Webが動作するところでは どこでも動作する。これは既に大きな利点だ。新しいWebデバイスが でてくれば、その利点はさらに増加する。ユーザは、なにもしないでも あなたのソフトウェアが動くことから、それを気に入るだろう。 あなたは、クライアントごとにソフトウェアをいじらなくて良いから 楽ができる。私だったら、Javascriptだって使わないだろう。 Viawebでは使わなかった[16]。
私はWebの進化を誰よりも密接に見てきた人間の一人のような気がしているが、 それでもクライアント側で次に何が起こるかは予測できない。 どこかに収束してゆくだろうが、それがどこかは分からない。 誰が勝つかもわからない。一つ予測できるのは、AOLとマイクロソフトの衝突だ。 マイクロソフトの.NETがどういう形になるにせよ、 それはデスクトップとサーバをつなぐものを含むだろう。 AOLは反撃しない限り、脇に押し退けられるか、単にマイクロソフトの クライアントとサーバソフトウェアをつなぐパイプに成り下がってしまう。 マイクロソフトとAOLがクライアントの領域で戦うならば、 動作を確実に保証できることはWebをブラウズすることだけになるから、 Webベースアプリケーションのみが、どこでも動作するという解になる。
どういう結末が待っているだろう。私にはわからない。 ただ、Webベースのアプリケーションに賭けるのに、この結末を知る必要はない。 だって、Webベースアプリケーションを負かすには、ブラウザというモデルを 壊さないとならない。Webはソフトウェアを届ける唯一の方法ではないけれど、 現在も動作し、将来も長期に渡って動作しつづけるものになるだろう。 Webベースアプリケーションは安価に開発できて、最も小さなベンチャー企業だって それを公開することができる。もちろん簡単な仕事じゃないし、とりわけ ストレスの高い仕事だが、だからこそそれはベンチャー企業にとって有利なんだ。
E. B. ホワイトは、農場を持っている友人から、電流を流せる柵の多くは 実際には電流を切っていると聞いて感心した。牛は一度感電を経験したら そういう柵に近寄らないようになるから、電流を流し続ける必要はない。 「立ち上がれ、牛たちよ！」彼は書いた。「君主が寝ている間に自由を手にせよ！」。
あなたがハッカーで、いつかベンチャー企業を立ち上げたいと思っているとする。 たぶん、二つのことがらがあなたにそうすることをためらわせているんじゃないかと思う。 ひとつは、あなたがビジネスについて何も知らないということ。 もう一つは、競争が恐いということ。実は、このどちらの柵にも、 電流は流れていないんだ。
ビジネスに関しては、二つのことだけを知っておけばいい。 ユーザが気に入るものを作るということと、使った金より多くの収入を得るということだ。 この二つがちゃんと出来れば、それだけで多くのベンチャー企業よりも 進んでいることになる。残りは、やってゆくうちにわかって来るだろう。
最初のうちは収入より支出が多くなるだろうけれど、 その差額が十分に速く縮まっていっていれば大丈夫だ。 少ない資金で始めるなら、すくなくとも節約の習慣はつけられる。 支出が少なければ少ないほど、それを上回る収入を得ることは楽になる。 幸い、Webベースアプリケーションはとても安価に始められる。 我々は最初のサービスのスタートを$10,000以下でやったし、 現在ならもっと安いだろう。数千ドルをサーバーに、数千ドルをSSLを得るのに 使った(当時、SSLソフトウェアを売っていた唯一の会社はNetscapeだった)。 現在では、SSLつきでもっとずっと強力なサーバを、我々がネットワークバンド幅に 払っていた料金よりも安く借りられるだろう。 たぶん今なら、 素敵なオフィス椅子よりも安くWebアプリケーションを立ち上げられるんじゃないだろうか。
ユーザが気に入るものという点に関しては、いくつか一般的な ヒントがある。まず、自分でも使いたいと思うような、明快で簡単なものから 作り始めることだ。バージョン1.0を素早く出して、それからユーザの声を よく聞きながらそれを改良してゆく。顧客は常に正しいっていうのは 本当だけれど、それぞれの顧客は別々の点に関して正しいんだ。 入門レベルのユーザは、どこを簡単で明快にすべきかを教えてくれる。 最も進んだレベルのユーザは、どういう機能を足したら良いかを教えてくれる。 最良のソフトウェアは、簡単であるものだが、それはデフォルト設定がそうなっている ためで、ユーザが望めばその選択に限界があってはならない。 ライバルのソフトウェアが駄目だからって悦に入っててはいけない。 あなたのソフトウェアが比較すべきは、ライバルのソフトウェアの現状ではなく、 あなたのソフトウェアのあるべき姿だ。自分で作ったソフトウェアを常に 自分で使うこと。Viawebはオンラインストアビルダーだったけれど、 我々は自分のサイトもそれで作っていた。 マーケティングとかデザイナーとかプロダクトマネージャだとかいう 人達の意見を、単にそういう人達がそういう肩書を持っているからというだけで 鵜呑みにしないこと。彼らが良いアイディアを出してくれたら使えばいいけれど、 それはあくまであなたの判断だ。ソフトウェアはデザインを知っているハッカーに よってデザインされるべきで、ソフトウェアのことをほとんど知らない デザイナーによってデザインされるべきではない。 あなたがソフトウェアの実装はできるがデザインはできないというのなら、 ベンチャーを立ち上げるのはあきらめた方がいい。
さて、競争について話そうか。たぶんあなたが恐れているのは、 あなたのような出来たばかりのハッカーの集団ではなく、ちゃんとしたオフィスと ビジネスプランとセールスマンとその他諸々を備えている本物の会社だろう。 違うかい? 本当のところは、あなたが彼らを恐れる以上に、彼らは あなたを恐れているし、それは正しい。 ハッカーのグループがオフィスを借りてセールスマンを雇う方法を見つけるのは、 規模によらず会社がソフトウェアを書き上げることよりもずっと易しい。 私はどちらの側も経験したから知っている。 ViawebがYahooに買収されて、私は突如として大会社で働くことになった。 そこでの経験は、まるで腰までの深さの水の中で走ろうとしているような感じだった。
いや、Yahooをけなすつもりはないよ。素晴らしいハッカー達がいたし、 マネジメントのトップは凄い連中だった。大会社としては、彼らは例外的な 部類に入るだろう。それでも、彼らは生産性では小さなベンチャー企業のほんの1/10くらい だったんじゃないかと思う。大企業でそれより高い生産性を持てるところは ない。マイクロソフトが凄いのは、あの大きさの会社でありながら ソフトウェアを開発することが出来ているという事実だ。 まるで、歩くことができる山のようだ。
いずれにせよ、びくびくしないことだ。あなたはマイクロソフトのようなことは できないが、同じくらい、マイクロソフトはあなたができるようなことが出来ない。 そして、誰もあなたを止めることはできない。Webベースのアプリケーションを 書くのに、誰の許可も要らない。ライセンスを取る手続きだとか、 店舗に棚を確保したりだとか、OSにアプリケーションをバンドルしてもらうように 交渉するだとか、そういうことは必要ないんだ。 あなたはソフトウェアを直接ブラウザに届けられる。 あなたと将来のユーザの間に入って邪魔するには、人々がWebをブラウズすることを 止めるしかない。
あなたは信じないかもしれないけれど、マイクロソフトはあなたを 恐れているよ。悦に入っている中間管理職はどうか知らないけど、 ビル・ゲイツはきっとそうだ。だって、1975年、 新しいソフトウェアの開発法が出現した時、彼は、あなただったのだから。
軽量クライアントを作る会社の多くは、 多くの金がサービスに支払われるようになるということに気づくと、 ハードウェアとオンラインサービスを組み合わせようとした。 このアプローチはうまくない。家電機器を作るのとオンラインサービスを 提供するのには全く違った種類の会社が必要だというのがひとつの理由で、 ユーザがそういう抱き合わせを嫌がるというのがもうひとつの理由だ。 かみそりを只で提供して替え刃で儲けるという戦略はジレット社にとっては うまくいったが、かみそりはWeb端末よりはるかに小さなコミットメントだ。 携帯電話のハンドセットのメーカーは、サービスによる収入をも手に入れようとは せずに、ハードを売って商売になっている。インターネットクライアントも そういうモデルになるべきなんだろう。誰かが、Webブラウザ内蔵でどんな ISPにもつなげるようなカッコいいデバイスを売り出したら、 国中の新しもの好きが買うに違いない。
セキュリティは、他のどんなデザイン上の決断にも増して、「失敗しないこと」 が重要だ。サーバベースのソフトウェアでは、原理的に開発者は 失敗しないように自然に注意を払うようになる。 サーバに侵入を許すことは、ASPにあまりに巨大な被害を与えるため (もちろん彼らはビジネスを続けたいだろうから)、とりわけセキュリティには 十分に注意するようになるだろう。
我々がViawebを始めた1995年当時、Javaアプレットがサーバベースの アプリケーションを開発するのに誰もが使う技術だと思われていた。 でも、我々にとっては、アプレットは古いアイディアのように思えた。 クライアントで走らせるためにプログラムをダウンロードするだって? すっぱりと全てサーバ側でプログラムを走らせるようにした方が 簡単じゃないか。というわけで我々は二度とアプレットを考慮することは しなかった。でも、数え切れないほどのベンチャーがこのタールの底無しの穴に 誘われたに違いない。そこから生きて抜け出せたものはほとんどなかった。 でなければ、マイクロソフトが最新のExplorerでJavaのサポートを 削るなんてことは不可能だったろう。
この点はトレバー・ブラックウェルが指摘した。 彼はさらにこうも言っている。「ソフトウェアを書くコストは、 サイズの増加よりも急速に上昇する。たぶん、その主要な要因は、 古いバグを修正しなければならないためだ。バグが全て素早く 見付かるなら、コストは線形に近付くだろう。」
最も厄介なバグは、複合バグの一種で、ひとつのバグが別のバグの不具合を たまたま隠してしまうようなものだ。一方を直すと、もう一方が 現れる。でも、それはまるで最初のフィックスが間違っていたかのように 思いがちだ。それが最後に変更したところだから。
Viaweb内で、いちど自分達のソフトウェアについて最悪のことを挙げる、 というコンテストを行ったことがある。カスタマーサポートのスタッフ2人が、 同率で一位を分けあった。彼らの挙げた内容は、今思い出しても震えがくるほどだ。 それをすぐに直したのは言うまでもない。
ロバート・モリスは、買いもの客が注文を出すシステムを書いた。 トレバー・ブラックウェルは店側が注文を取り出したり、統計情報を 見たり、ドメイン名を設定したりするための画像生成部と管理プログラムを 書いた。私は店が自分のオンラインショップを構築するためのエディタを書いた。 注文システムと画像生成部はCとC++で、管理プログラムは主として Perlで、そしてエディタはLispで書かれていた。
価格差別は広く浸透している(小売店が、彼らの購買力によって消費者に より安い価格を提供できます、と宣伝しているのを何度も聞いたことがあるだろう)。 だから、実はそれが米国では1936年のRobinson-Patman法により禁止されている ことを知って私はびっくりした。ただ、この法律はあまり厳格に 運用されていないようだ。
ナオミ・クラインの『ブランドなんか、いらない』では、 都市部の若者に好まれるブランドの衣料店は万引きを防ぐ工夫をそれほど きつくしないということが述べられている。それらブランドのマーケット においては、万引き犯は往々にしてファッションリーダーでもあるからだ。
何をアウトソースすべきで、何をすべきでないかは、会社にとって しばしば問題となる。こういう解答はどうだろう。競争的なプレッシャーに さらされていない職種を全てアウトソースする。アウトソースすることで、 そういう職種も競争的なプレッシャーにさらすことができる。
その2人とは、ダン・ブリックリンとボブ・フランクストンだ。 ダンはプロトタイプをBasicを使って2日ばかりで書き上げ、 それから翌年にかけて、2人は(主に夜間に)より強力なバージョンを 6502の機械語で書き上げた。ダンは当時ハーバードビジネススクールの学生で、 ボブはいわゆる昼の仕事としてもソフトウェアを書いていた。 「ビジネスをやることにそんなに大きなリスクはなかった」とボブは書いている。 「失敗したら、それまでさ。どうってことない。」
もっとも、ここでさらっと言う程簡単なことではなかった。 口コミがひろがるのにはひどく時間がかかったし、マスコミに取り上げられた のは、我々がようやく広告会社(その分野では最高の会社だったが)を、 月に$16,000という費用で雇ってからだ。ただ、我々の主要な顧客獲得窓口が 我々のWebサイトであった、ということは間違いない。
Macがそんなに良いものなら、どうして負けたんだろう? コストだ。またしても。 マイクロソフトはソフトウェアビジネスに集中し、 アップルのハードウェアに対しては、大量の安い部品業者に対抗させたんだ。 もちろん、重要な時期にスーツ族が会社を牛耳っていたというのも原因のひとつではあるが。
Webベースアプリケーションの追い風になり、 また次世代のソフトウェアをマイクロソフトの影から解法するのに 役立つものの一つは、オープンソースの良いブラウザだろう。 Mozillaはオープンソースではあるが、長い間、会社で作られるソフトウェア であったことからの影響をまだ抜け切れないようだ。 小さく、軽く、アクティブに開発されるブラウザがあれば、 それ自体が良いものであるだけでなく、ちょっとしたWebアプライアンスを 作ろうという会社を助けることにもなるだろう。
さらに、正しいオープンソースのブラウザはHTTPとHTMLが 進化しつづけることを助けるだろう(例えばPerlがそうしたように)。 Webベースのアプリケーションが、例えばリンクを選択することと それをたどることを区別できるようになることでWebベースのアプライアンスは 大いに助かるだろう。必要なのは、リクエストに複数のurlを指定できるようにする、 HTTPのちょっとした拡張だけだ。複数段のメニューもあったら良いだろう。
世界を変えたければ、新しいMosaicを書くことだ。もう遅すぎるって? 1998年には、多くの人は新しいサーチエンジンを出すのは遅すぎると思っていたが、 Googleはそれが間違っていることを証明した。 現在のバージョンが十分にダメな場合はいつでも、何か新しいものにチャンスはある。 もしそれを作るなら、まず全てのフリーなOSでの動作を保証することだ。 新しいことは、往々にしてフリーなOSのユーザから始まる。
おそらく、個人的な経験を通じて誰よりもこの問題を知っているであろう トレバー・ブラックウェルはこう書いている。
「僕なら、もう一歩進めて、サーバベースのソフトウェアは プログラマにとって非常に難しく、従って大企業が離れて行くという 根本的な経済上の変革をもたらすと言うだろうね。 サーバベースソフトウェアは、プログラマにものすごい密度で 全身全霊をかけることを要求するから、自分の会社だというのでもなければ とてもやる気にならないさ。スキルの高いプログラマを雇って、それほどきつくない 環境で働いてもらうことはできる。また、スキルの無いプログラマを 雇って、きつい環境で働かせることもできる。 でも、非常に高いスキルを持つプログラマを雇って馬車馬のように働かせることなんて できやしない。資本が必要ないこのフィールドには、大会社が持ち込めるもの なんてほとんど無いさ。」
私がWeb上で見たJavascriptのほとんどは不要なものであり、 その大部分はうまく動かなかった。 (私の頭の中のイメージでは、JavascriptプログラマはDilbertのWallyだ。 頭の上に「僕のコンピュータでは動くのに」って吹き出しが浮かんでる)。 Yahooはいくつかの箇所でJavascriptを使っているが、それほど多くない。 以前、誰かに、Javascriptを使ってみてどんな具合だい、と尋ねたことがある。 答えは「ブラウザのいろんなバージョンの違いをさんざん勉強することになるよ」 というものだった。マイクロソフトは、JavaでやったようにJavascriptを 採用してから拡張し、囲い込んでゆくだろう。そして、もしWebページが 携帯電話やPDA(あるいはトースター)で見られるようになったら、 いったいJavascriptがどこまでサポートされるかなんて誰にも分かりはしない。
原文のタイトル「The Other Road Ahead」は、 Bill Gatesの「The Road Ahead」(邦題「ビル・ゲイツ、未来を語る」)のもじり。
今年：この記事の書かれた2001年のこと。 翻訳をしている2004年現在、 サーバサイドソフトウェアの一時期のようなhypeはすっかり鳴りを潜めたが、 そのようなソフトウェアが無くなったのではなく、 むしろ、宣伝するまでもないほど浸透してきたということだろう。