もう一つのロード・アヘッド | Paul Grahamのエッセイ

2001年9月

(この記事では、次世代ソフトウェアの多くがサーバーベースになる理由、それがプログラマーに与える意味、そしてこの新しい種類のソフトウェアがスタートアップにとって大きな機会となる理由を説明します。BBN Labsでの講演から派生したものです。)

1995年の夏、友人のロバート・モリスと私はスタートアップを立ち上げることにしました。当時、NetscapeのIPOに向けたPRキャンペーンが全盛期で、オンライン商取引についてメディアで盛んに議論されていました。当時、Web上には手作業で作られた実際の店舗が30軒ほどしかなかったかもしれません。もしオンラインストアがたくさんできるのであれば、それらを作るためのソフトウェアが必要になるだろうと考え、私たちはそのソフトウェアを書くことにしました。

最初の1週間ほどは、これを通常のデスクトップアプリケーションにするつもりでした。しかしある日、Webサーバー上でソフトウェアを実行し、ブラウザをインターフェースとして使うというアイデアが浮かびました。ソフトウェアをWeb上で動作するように書き直してみると、これが正しい道であることが明らかになりました。サーバー上で動作するようにソフトウェアを書けば、ユーザーにとっても私たちにとっても、はるかに簡単になるからです。

これは良い計画であることが判明しました。現在、Yahoo Storeとして、このソフトウェアは最も人気のあるオンラインストアビルダーであり、約14,000人のユーザーがいます。

Viawebを始めた当初、私たちがソフトウェアがサーバー上で動作すると言っても、ほとんど誰もその意味を理解してくれませんでした。1年後にHotmailがローンチされて初めて、人々はそれを理解し始めました。今では、これが有効なアプローチであることは誰もが知っています。私たちが当時そうであったものには、今では「アプリケーションサービスプロバイダ」、略してASPという名前がついています。

次世代ソフトウェアの多くがこのモデルで書かれるようになると思います。最も失うものが多いMicrosoftでさえ、デスクトップから一部を移行させることの必然性を認識しているようです。ソフトウェアがデスクトップからサーバーへと移行すれば、開発者にとってはまったく異なる世界を意味するでしょう。この記事では、この新しい世界への最初の訪問者として、私たちが目にした驚くべきことを記述します。ソフトウェアがサーバーへと移行する限り、ここで私が説明していることは未来なのです。

次のもの？

デスクトップソフトウェアの時代を振り返ると、初期の自動車所有者が耐え忍んだことに今私たちが驚くように、人々が耐え忍んだ不便さに驚嘆するでしょう。最初の20年か30年間は、自動車を所有するには自動車の専門家でなければなりませんでした。しかし、自動車は非常に大きな恩恵をもたらしたため、自動車の専門家ではない多くの人々もそれを欲しがりました。

コンピュータは今、この段階にあります。デスクトップコンピュータを所有すると、その内部で何が起こっているかについて、知りたくなかったことまで多くを学ぶことになります。しかし、米国の世帯の半分以上がそれを所有しています。私の母は、メールと会計のためにコンピュータを使っています。約1年前、彼女はAppleから新しいバージョンのオペレーティングシステムの割引を提供する手紙を受け取り、驚きました。メールと会計のためにコンピュータを使いたい65歳の女性が、新しいオペレーティングシステムのインストールについて考えなければならないというのは、何かおかしいです。一般のユーザーは、「オペレーティングシステム」という言葉さえ知るべきではありません。ましてや「デバイスドライバ」や「パッチ」など。

ユーザーがシステム管理者になるのを防ぐ、別のソフトウェア提供方法が今では存在します。Webベースのアプリケーションは、Webサーバー上で動作し、Webページをユーザーインターフェースとして使用するプログラムです。平均的なユーザーにとって、この新しい種類のソフトウェアは、デスクトップソフトウェアよりも、より簡単で、より安価で、よりモバイル性が高く、より信頼性が高く、そしてしばしばより強力になるでしょう。

Webベースのソフトウェアでは、ほとんどのユーザーは使用するアプリケーション以外の何も考える必要がありません。厄介で変化の激しいものはすべて、どこかのサーバー上に置かれ、その種のことに長けた人々によってメンテナンスされます。そのため、通常、ソフトウェアを使用するためにコンピュータそのものは必要ありません。必要なのは、キーボード、スクリーン、そしてWebブラウザを備えた何かだけです。おそらく無線インターネットアクセスも備わっているでしょう。もしかしたら、それはあなたの携帯電話でもあるかもしれません。それが何であれ、それは家電製品になるでしょう。約200ドルで、人々は主にケースの見た目で選ぶようなものです。ハードウェアよりもインターネットサービスに多くを支払うことになるでしょう。ちょうど今、電話でそうしているように。[1]

クリックがサーバーに到達して戻るまで約0.1秒かかるため、Photoshopのような高度にインタラクティブなソフトウェアのユーザーは、引き続きデスクトップで計算が行われることを望むでしょう。しかし、ほとんどの人がコンピュータを使用する目的を考えると、0.1秒のレイテンシは問題にならないでしょう。私の母は本当にデスクトップコンピュータを必要としていませんし、彼女のような人はたくさんいます。

ユーザーにとっての利点

私の家の近くに「不便さより死を」と書かれたバンパーステッカーを貼った車があります。ほとんどの人は、ほとんどの場合、最も労力の少ない選択肢を選びます。Webベースのソフトウェアが勝利するなら、それはそれがより便利だからでしょう。そして、ユーザーと開発者の両方にとって、そうなるように見えます。

純粋なWebベースのアプリケーションを使用するには、インターネットに接続されたブラウザだけが必要です。そのため、Webベースのアプリケーションはどこでも使用できます。デスクトップコンピュータにソフトウェアをインストールすると、そのコンピュータでしか使用できません。さらに悪いことに、ファイルはそのコンピュータに閉じ込められてしまいます。人々がネットワークに慣れるにつれて、このモデルの不便さはますます明らかになります。

この楔の薄い端はWebベースのメールでした。今や何百万人もの人々が、どこにいてもメールメッセージにアクセスできるべきだと認識しています。メールが見られるなら、カレンダーもどうでしょう？同僚とドキュメントについて議論できるなら、なぜ編集できないのでしょうか？なぜあなたのデータが、遠く離れた机の上にあるどこかのコンピュータに閉じ込められている必要があるのでしょうか？

「あなたのコンピュータ」という概念全体が消え去り、「あなたのデータ」に置き換えられつつあります。あなたはどのコンピュータからでも自分のデータにアクセスできるべきです。いや、むしろどのクライアントからでもアクセスできるべきであり、クライアントはコンピュータである必要はありません。

クライアントはデータを保存すべきではありません。電話のようになるべきです。実際、それらは電話になるかもしれませんし、その逆かもしれません。そして、クライアントが小さくなるにつれて、データをそこに保存しないもう一つの理由が生まれます。持ち歩くものは紛失したり盗まれたりする可能性があるからです。タクシーにPDAを置き忘れるのはディスククラッシュのようなものですが、データは蒸発する代わりに他の誰かの手に渡ります。

純粋なWebベースのソフトウェアでは、データもアプリケーションもクライアントに保存されません。そのため、使用するために何もインストールする必要がありません。そして、インストールがないということは、インストールの失敗を心配する必要がないということです。ソフトウェアがオペレーティングシステム上で動作しないため、アプリケーションとオペレーティングシステム間の互換性の問題も発生しません。

インストールが不要なため、「購入」する前にWebベースのソフトウェアを試用することが簡単になり、一般的になるでしょう。Webベースのアプリケーションは、提供されているサイトに行くだけで無料で試用できると期待すべきです。Viawebでは、サイト全体がユーザーを試用版へと導く大きな矢印のようでした。

デモを試した後、サービスにサインアップするには、簡単なフォーム（短いほど良い）に記入するだけで済みます。そして、それがユーザーがしなければならない最後の作業であるべきです。Webベースのソフトウェアでは、追加料金を支払ったり、作業をしたり、あるいは知らず知らずのうちに新しいリリースを入手できるはずです。

アップグレードは、今のような大きな衝撃にはならないでしょう。時間の経過とともに、アプリケーションは静かに強力になっていきます。これには開発者側の努力が必要です。ユーザーを混乱させることなく更新できるようにソフトウェアを設計しなければなりません。それは新しい問題ですが、解決策はあります。

Webベースのアプリケーションでは、誰もが同じバージョンを使用し、バグは発見され次第すぐに修正できます。そのため、Webベースのソフトウェアはデスクトップソフトウェアよりもはるかにバグが少ないはずです。Viawebでは、一度に10個以上の既知のバグがあったことはなかったと思います。これはデスクトップソフトウェアよりも桁違いに優れています。

Webベースのアプリケーションは、複数の人が同時に使用できます。これは共同作業アプリケーションにとって明らかな利点ですが、ユーザーはこれが可能だと気づけば、ほとんどのアプリケーションでこれを望むようになるでしょう。例えば、2人が同じドキュメントを編集できることは、しばしば便利です。Viawebでは、複数のユーザーが同時にサイトを編集できましたが、それはユーザーが望むからというよりも、ソフトウェアを正しく書く方法だったからですが、多くのユーザーが実際にそうしたことが判明しました。

Webベースのアプリケーションを使用すると、データはより安全になります。ディスククラッシュは過去のものではなくなりますが、ユーザーはそれについて聞くことはなくなるでしょう。それらはサーバーファーム内で発生します。そして、Webベースのアプリケーションを提供する企業は実際にバックアップを行います。これは、実際のシステム管理者がそのようなことを心配するだけでなく、人々のデータを失うASPは非常に大きな問題に直面するからです。人々がディスククラッシュで自分のデータを失った場合、怒る相手が自分自身しかいないため、それほど怒ることはできません。企業が彼らのデータを失った場合、彼らははるかに怒るでしょう。

最後に、Webベースのソフトウェアはウイルスに対して脆弱性が低いでしょう。クライアントがブラウザ以外何も実行しない場合、ウイルスを実行する可能性が低く、ローカルに損傷するデータもありません。そして、サーバー自体を攻撃するプログラムは、それらが非常によく防御されていることを発見するでしょう。[2]

ユーザーにとって、Webベースのソフトウェアは_ストレスが少ない_でしょう。平均的なWindowsユーザーの内部を覗けば、その説明に合致するソフトウェアに対する、巨大でほとんど手つかずの欲求があると思います。それが解き放たれれば、強力な力となる可能性があります。

コードの都市

開発者にとって、Webベースのソフトウェアとデスクトップソフトウェアの最も顕著な違いは、Webベースのアプリケーションが単一のコードではないということです。それは単一の大きなバイナリではなく、異なる種類のプログラムの集合体となるでしょう。そのため、Webベースのソフトウェアを設計することは、建物を設計するよりも都市を設計するようなものです。建物だけでなく、道路、道路標識、公共施設、警察、消防署、そして成長と様々な種類の災害に対する計画も必要になります。

Viawebでは、ソフトウェアには、ユーザーが直接対話するかなり大きなアプリケーション、それらのプログラムが使用するプログラム、問題を探してバックグラウンドで常に実行されるプログラム、壊れた場合に再起動を試みるプログラム、統計をコンパイルしたり検索用のインデックスを構築したりするために時折実行されるプログラム、リソースをガベージコレクションしたりデータを移動または復元したりするために明示的に実行するプログラム、ユーザーを装って（パフォーマンスを測定したりバグを露出させたりする）プログラム、ネットワークトラブルを診断するプログラム、バックアップを行うプログラム、外部サービスへのインターフェース、リアルタイムサーバー統計を表示する印象的なダイヤルコレクションを駆動するソフトウェア（訪問者には好評でしたが、私たちにとっても不可欠でした）、オープンソースソフトウェアへの修正（バグ修正を含む）、そして非常に多くの設定ファイルと設定が含まれていました。Yahooに買収された後、トレバー・ブラックウェルは、ストアを停止することなく、全国の新しいサーバーに移動させるための素晴らしいプログラムを書きました。プログラムは私たちにページングし、ユーザーにファックスやメールを送り、クレジットカード処理業者と取引を行い、ソケット、パイプ、HTTPリクエスト、SSH、UDPパケット、共有メモリ、ファイルを通じて互いに通信しました。Viawebの一部は、プログラムの不在でさえ構成されていました。Unixセキュリティの鍵の一つは、人々がサーバーに侵入するために使用する可能性のある不要なユーティリティを実行しないことだからです。

それはソフトウェアだけにとどまりませんでした。私たちはサーバー構成について多くの時間を費やしました。私たちはコンポーネントからサーバー自体を構築しました。一部はコストを節約するため、一部は私たちが望むものを正確に手に入れるためです。私たちは、上流ISPがすべてのバックボーンに十分な速度の接続を持っているかどうかを考える必要がありました。私たちはRAIDサプライヤーと連続的にデートしました。

しかし、ハードウェアは心配するだけのものではありません。それを制御することで、ユーザーのためにもっと多くのことができます。デスクトップアプリケーションでは、特定の最小ハードウェアを指定できますが、それ以上追加することはできません。サーバーを管理していれば、関連するハードウェアをインストールするだけで、すべてのユーザーがページングしたり、ファックスを送ったり、電話でコマンドを送ったり、クレジットカードを処理したりできるようになります。私たちは常に、ハードウェアで機能を追加する新しい方法を探していました。それはユーザーを喜ばせるだけでなく、デスクトップソフトウェアを販売しているか、ISPを通じてWebベースのアプリケーションを再販しているため、ハードウェアを直接制御できない競合他社と差別化する方法でもあったからです。

Webベースのアプリケーションのソフトウェアは、単一のバイナリではなくプログラムの集合体であるため、任意の数の異なる言語で書くことができます。デスクトップソフトウェアを書く場合、アプリケーションを基盤となるオペレーティングシステムと同じ言語、つまりCとC++で書くことを事実上強制されます。そのため、これらの言語は（特にマネージャーやVCのような非技術者の間で）「本格的な」ソフトウェア開発のための言語と見なされるようになりました。しかし、それはデスクトップソフトウェアが提供される方法の単なる副産物にすぎませんでした。サーバーベースのソフトウェアには、好きな言語を使用できます。[3]今日、多くのトップハッカーはCやC++とはかけ離れた言語、Perl、Python、さらにはLispを使用しています。

サーバーベースのソフトウェアでは、システム全体をハードウェアに至るまで制御しているため、誰も使用する言語を指示することはできません。異なる言語は異なるタスクに適しています。それぞれのタスクに最適なものを使用できます。そして、競合他社がいる場合、「できる」は「しなければならない」を意味します（これについては後で述べます）。なぜなら、この可能性を利用しなければ、競合他社が利用するからです。

私たちの競合他社のほとんどはCとC++を使用していましたが、これにより彼らのソフトウェアは明らかに劣っていました（とりわけ）、CGIスクリプトのステートレス性を回避する方法がなかったからです。何かを変更する場合、すべての変更は1つのページで、下部に更新ボタンを置いて行わなければなりませんでした。私が別の場所で書いたように、多くの人がまだ研究言語と考えているLispを使用することで、Viawebエディタをデスクトップソフトウェアのように動作させることができました。

リリース

この新しい世界における最も重要な変化の一つは、リリースの方法です。デスクトップソフトウェアビジネスでは、リリースは巨大なトラウマであり、会社全体が単一の巨大なコードを押し出すために汗を流し、奮闘します。そのプロセスと結果として生じる製品の両方に、明らかな比較が示唆されます。

サーバーベースのソフトウェアでは、まるで自分自身のために書いているプログラムのように、ほとんど変更を加えることができます。ソフトウェアは、時折の大きな爆発ではなく、一連の段階的な変更としてリリースされます。典型的なデスクトップソフトウェア会社は、年に1回か2回リリースを行うかもしれません。Viawebでは、1日に3回から5回リリースを行うことも珍しくありませんでした。

この新しいモデルに切り替えると、ソフトウェア開発がリリースの方法によってどれほど影響を受けるかを実感します。デスクトップソフトウェアビジネスで見られる最も厄介な問題の多くは、リリースの壊滅的な性質に起因しています。

年に1回しか新しいバージョンをリリースしない場合、バグをまとめて処理する傾向があります。リリース日のしばらく前に、コードの半分が削除され置き換えられた新しいバージョンを組み立て、数え切れないほどのバグを導入します。その後、QA担当者の部隊が介入してそれらを数え始め、プログラマーはリストをこなしていき、修正します。彼らは通常、リストの最後までたどり着くことはなく、実際、終わりがどこにあるのか誰も確信していません。それは池から瓦礫を釣り上げるようなものです。ソフトウェアの内部で何が起こっているのか、本当に知ることはできません。せいぜい、統計的な正確さにたどり着くのが関の山です。

サーバーベースのソフトウェアでは、ほとんどの変更は小さく、段階的です。それ自体がバグを導入する可能性を低くします。また、ソフトウェアをリリースする際に最も慎重にテストすべきもの、つまり最後に変更したものを知っていることを意味します。結果として、コードをはるかにしっかり把握できるようになります。一般的に、その内部で何が起こっているかを知ることができます。もちろん、ソースコードを記憶しているわけではありませんが、ソースを読むときは、探偵が謎を解き明かそうとするようにではなく、パイロットが計器盤をスキャンするように読みます。

デスクトップソフトウェアは、バグに対するある種の宿命論を生み出します。バグだらけのものを出荷していることを知っており、それを補うためのメカニズム（パッチリリースなど）さえ設定しています。では、なぜもう少しバグが増えることを心配するのでしょうか？すぐに、壊れていると分かっている機能全体をリリースするようになります。Appleは今年の初めにこれを行いました。彼らは新しいOSをリリースするというプレッシャーを感じており、リリース日はすでに4回延期されていましたが、一部のソフトウェア（CDとDVDのサポート）は準備ができていませんでした。解決策は？未完成の部分なしでOSをリリースし、ユーザーは後でそれらをインストールしなければならないというものでした。

Webベースのソフトウェアでは、動作する前にソフトウェアをリリースする必要はなく、動作し次第すぐにリリースできます。

業界のベテランは、動作する前にソフトウェアをリリースする必要がないというのは聞こえの良いアイデアだが、特定の期日までに新しいバージョンのソフトウェアを納品すると約束した場合どうなるのか、と考えているかもしれません。Webベースのソフトウェアでは、そのような約束はしないでしょう。なぜなら、バージョンというものが存在しないからです。ソフトウェアは徐々に、そして継続的に変化します。一部の変更は他の変更よりも大きいかもしれませんが、バージョンの概念はWebベースのソフトウェアには自然に適合しません。

Viawebを覚えている人にとっては奇妙に聞こえるかもしれませんが、私たちは常に新しいバージョンを発表していました。これは完全にPR目的で行われました。業界誌はバージョン番号で考えることを私たちは学びました。彼らはメジャーリリース、つまりバージョン番号の最初の桁が変わるものには大規模な報道を与え、ポイントリリース、つまり小数点以下の桁が変わるものにはせいぜい段落程度の報道しか与えません。

競合他社の中にはデスクトップソフトウェアを提供しており、実際にバージョン番号を持っていました。そして、私たちには後進性の証拠としか思えなかったこれらのリリースに対して、彼らはあらゆる種類の宣伝を得ていました。私たちはそれを見逃したくなかったので、私たちもソフトウェアにバージョン番号を付け始めました。宣伝が欲しいときは、前回の「リリース」以降に追加したすべての機能のリストを作成し、ソフトウェアに新しいバージョン番号を付け、新しいバージョンがすぐに利用可能になったというプレスリリースを発行しました。驚くべきことに、誰も私たちを問い詰めることはありませんでした。

買収されるまでに、私たちはこれを3回行い、バージョン4になっていました。私の記憶が正しければバージョン4.1です。ViawebがYahoo Storeになった後、宣伝に対する切迫した必要性はもはやなかったので、ソフトウェアは進化し続けましたが、バージョン番号という概念全体は静かに廃止されました。

バグ

Webベースのソフトウェアのもう一つの主要な技術的利点は、ほとんどのバグを再現できることです。ユーザーのデータがディスク上にそのままあります。誰かがソフトウェアを壊した場合、デスクトップソフトウェアのように何が起こっているのか推測しようとする必要はありません。電話で話している間にエラーを再現できるはずです。アプリケーションにエラーを通知するコードが組み込まれていれば、すでにそのことを知っているかもしれません。

Webベースのソフトウェアは24時間体制で使用されるため、行うすべてのことがすぐに厳しく試されます。バグは迅速に現れます。

ソフトウェア会社は、ユーザーにソフトウェアのデバッグをさせていると非難されることがあります。そして、それこそ私が提唱していることです。Webベースのソフトウェアにとっては、それは実際には良い計画です。なぜなら、バグは少なく、一時的だからです。ソフトウェアを段階的にリリースすると、そもそもバグがはるかに少なくなります。そして、エラーを再現し、変更を即座にリリースできる場合、ほとんどのバグを出現と同時に見つけて修正できます。私たちは、正式なバグ追跡システムを必要とするほど、一度に多くのバグを抱えたことはありませんでした。

もちろん、リリースする前に変更をテストすべきなので、大きなバグがリリースされることはないはずです。避けられない数少ないバグは境界ケースに関わるもので、誰かが苦情を申し立てる前にそれらに遭遇する少数のユーザーにしか影響しません。バグをすぐに修正する限り、平均的なユーザーにとっての純粋な効果は、はるかに少ないバグです。平均的なViawebユーザーがバグを見たことはほとんどないと思います。

新しいバグを修正する方が、古いバグを修正するよりも簡単です。書いたばかりのコードのバグを見つけるのは通常かなり迅速です。バグが見つかったとき、ソースを見る前に何が間違っているかを知っていることがよくあります。無意識のうちにすでに心配していたからです。6ヶ月前に書いたもの（年に1回リリースする場合の平均的なケース）のバグを修正するのは、はるかに多くの作業です。そして、コードをそれほど理解していないため、醜い方法で修正したり、さらにバグを導入したりする可能性が高くなります。[4]

バグを早期に発見すると、複合バグも少なくなります。複合バグとは、2つの別々のバグが相互作用するものです。階段を降りるときにつまずき、手すりに手を伸ばすとそれが手から外れるようなものです。ソフトウェアでは、この種のバグは最も見つけにくく、最悪の結果をもたらす傾向があります。[5]従来の「すべてを壊してからバグを取り除く」アプローチは、本質的に多くの複合バグを生み出します。そして、一連の小さな変更でリリースされるソフトウェアは、本質的にそうではありません。床は常に、後で何かに引っかかる可能性のある緩んだ物体が掃き清められています。

関数型プログラミングと呼ばれる手法を使用すると役立ちます。関数型プログラミングとは、副作用を避けることです。商用ソフトウェアよりも研究論文でよく見られるものですが、Webベースのアプリケーションでは非常に役立つことが判明しています。プログラム全体を純粋な関数型コードとして書くのは難しいですが、かなりの部分をこの方法で書くことができます。これにより、ソフトウェアのそれらの部分は状態を持たないため、テストが容易になり、小さな変更を常に作成しテストする状況では非常に便利です。私はViawebのエディタの多くをこのスタイルで書き、スクリプト言語であるRTMLを純粋な関数型言語にしました。

デスクトップソフトウェアビジネスの人々には信じがたいことかもしれませんが、Viawebではバグはほとんどゲームのようになりました。リリースされたバグのほとんどが境界ケースに関わるものだったため、それらに遭遇したユーザーは上級ユーザーであり、限界を押し広げている可能性がありました。上級ユーザーはバグに対してより寛容です。特に、おそらく彼らが求めていた機能を追加する過程でバグを導入したからです。実際、バグはまれで、それらを見るには洗練されたことをしている必要があったため、上級ユーザーはバグを発見することを誇りに思うことさえありました。彼らは怒りよりも勝利の精神でサポートに電話をかけ、まるで私たちからポイントを獲得したかのように振る舞いました。

サポート

エラーを再現できると、カスタマーサポートへのアプローチが変わります。ほとんどのソフトウェア会社では、サポートは顧客の気分を良くするための方法として提供されます。彼らは既知のバグについて電話しているか、単に何か間違ったことをしていて、あなたが何を間違っているのかを突き止めなければなりません。どちらの場合も、彼らから学ぶことはあまりありません。そのため、サポートの電話は開発者からできるだけ隔離したい面倒なものと見なす傾向があります。

Viawebではそうではありませんでした。Viawebでは、顧客からの意見を聞きたかったので、サポートは無料でした。誰かが問題を抱えていれば、すぐにそれを知り、エラーを再現して修正をリリースしたかったのです。

そのため、Viawebでは開発者は常にサポートと密接に連絡を取り合っていました。カスタマーサポートの人々はプログラマーから約9メートル離れた場所にいて、本物のバグの報告があればいつでも中断できることを知っていました。私たちは深刻なバグを修正するために役員会議を中断することもありました。

私たちのサポートへのアプローチは、誰もをより幸せにしました。顧客は大喜びでした。サポートラインに電話をかけ、重要なニュースをもたらす人として扱われることを想像してみてください。カスタマーサポートの人々は、スクリプトを読み上げる代わりにユーザーを助けることができるので、それを気に入りました。そしてプログラマーは、漠然とした二次情報だけを聞く代わりにバグを再現できるので、それを気に入りました。

その場でバグを修正するという私たちのポリシーは、カスタマーサポート担当者とハッカーの関係を変えました。ほとんどのソフトウェア会社では、サポート担当者は低賃金の人間の盾であり、ハッカーは父なる神の小さなコピー、世界の創造者です。バグを報告する手順がどうであれ、それは一方向的である可能性が高いです。バグについて聞いたサポート担当者は、最終的に（おそらくQAを介して）プログラマーに渡されるフォームに記入し、プログラマーはそれを自分のTo-Doリストに入れます。Viawebではまったく異なりました。顧客からバグについて聞いてから1分以内に、サポート担当者はプログラマーの隣に立ち、「くそ、その通り、バグだ」という彼の言葉を聞くことができました。サポート担当者はハッカーから「その通り」と聞くことを喜びました。彼らはまるで、殺したばかりのネズミを持ってくる猫のように、期待に満ちた表情で私たちにバグを持ってきました。それはまた、彼らの名誉がかかっていたため、バグの深刻さを判断する際により慎重にさせました。

Yahooに買収された後、カスタマーサポートの人々はプログラマーから遠く離れた場所に移動しました。そのとき初めて、彼らが実質的にQAであり、ある程度はマーケティングでもあったことに気づきました。バグを捕まえるだけでなく、彼らはユーザーを混乱させる機能のような、より漠然としたバグのようなものの知識の管理者でもありました。[6]彼らはまた、一種のプロキシフォーカスグループでもありました。私たちは彼らに、2つの新しい機能のうちどちらをユーザーがより望んでいるかを尋ねることができ、彼らは常に正しかったのです。

士気

ソフトウェアをすぐにリリースできることは、大きなモチベーションになります。仕事に向かう途中、ソフトウェアに加えたい変更を思いつき、その日のうちにそれを実行することもよくありました。これはより大きな機能にも当てはまりました。何かを書き上げるのに2週間かかったとしても（それ以上かかるプロジェクトはほとんどありませんでしたが）、完成し次第すぐにソフトウェアにその効果が現れることを知っていました。

もし次のリリースまで1年待たなければならなかったら、これらのアイデアのほとんどは、少なくともしばらくの間は棚上げになっていたでしょう。しかし、アイデアというものは、さらなるアイデアにつながるものです。何かを書き始めると、最終的にその中に含まれるアイデアの半分は、書いている間に思いついたものであることに気づいたことはありませんか？ソフトウェアでも同じことが起こります。一つのアイデアを実装しようとすることで、さらなるアイデアが生まれます。したがって、アイデアを棚上げにすることは、その実装の遅延だけでなく、それを実装することで生まれたであろうすべてのアイデアをも失うことになります。実際、アイデアを棚上げにすることは、新しいアイデアを阻害することさえあるでしょう。新しい機能を考え始めると、棚が見えて「でも、次のリリースでやりたい新しいことがたくさんある」と考えてしまうからです。

大企業が機能の実装の代わりにすること、それは計画です。Viawebでは、この点で時々問題に遭遇しました。投資家やアナリストは、将来の計画について尋ねてきました。正直な答えは、計画は何もなかった、ということでしょう。改善したいことについて大まかなアイデアはありましたが、どうすればよいか知っていれば、とっくに実行していたでしょう。次の6ヶ月で何をしますか？最も大きな成果が見込めることなら何でも。私はこの答えをあえて言ったかどうかは分かりませんが、それが真実でした。計画とは、棚上げされたアイデアの別名にすぎません。良いアイデアを思いついたら、私たちはそれを実装しました。

Viawebでは、多くのソフトウェア会社と同様に、ほとんどのコードには明確な所有者がいました。しかし、何かを所有するということは、本当にそれを所有するということでした。ソフトウェアの一部を所有する人以外は、リリースを承認する必要も（知る必要さえも）ありませんでした。破損に対する保護は、同僚に馬鹿だと思われることへの恐れしかありませんでしたが、それだけで十分でした。私は、私たちがただ無邪気にコードを書き進めていたかのような印象を与えたかもしれません。私たちは確かに速く進みましたが、それらのサーバーにソフトウェアをリリースする前には非常に慎重に考えました。そして、信頼性には、ゆっくり進むことよりも注意を払うことの方が重要です。海軍のパイロットは、夜間に揺れる空母の甲板に、時速140マイルで40,000ポンドの航空機を着陸させることができます。平均的なティーンエイジャーがベーグルを切るよりも安全に。それは彼が細心の注意を払っているからです。

このソフトウェアの書き方は、もちろん諸刃の剣です。それは、悪いアイデアがアイデアを出した人々ではなく委員会によって捕らえられるような、平凡なプログラマーが大勢いる大企業よりも、優秀で信頼できる少人数のプログラマーチームにとってはるかにうまく機能します。

逆ブルックス

幸いなことに、Webベースのソフトウェアはより少ないプログラマーしか必要としません。かつて私は、エンジニアリング全体で100人以上の従業員を抱える中規模のデスクトップソフトウェア会社で働いていました。そのうち製品開発に携わっていたのはわずか13人でした。残りの全員はリリースや移植などに従事していました。Webベースのソフトウェアでは、リリースや移植などがないため、（せいぜい）その13人だけで済みます。

Viawebはわずか3人で書かれました。[7]私たちは買収されたかったので、常にもっと多くの人を雇うようプレッシャーを受けていました。3人のプログラマーしかいない会社に高値を支払うのは、買い手にとって難しいだろうと知っていたからです。（解決策：私たちはもっと多くの人を雇いましたが、彼らには新しいプロジェクトを作成しました。）

より少ないプログラマーでソフトウェアを書けるようになると、お金以上のものが節約できます。フレッド・ブルックスが『人月の神話』で指摘したように、プロジェクトに人を追加すると、速度が低下する傾向があります。開発者間の可能な接続の数は、グループのサイズとともに指数関数的に増加します。グループが大きくなるほど、ソフトウェアがどのように連携するかを交渉する会議に費やす時間が増え、予期せぬ相互作用によるバグも増えます。幸いなことに、このプロセスは逆にも機能します。グループが小さくなるほど、ソフトウェア開発は指数関数的に効率的になります。Viawebのプログラマーが実際に会議をした記憶はありません。昼食に向かう途中で話せる以上のことは、一度に話すことはありませんでした。

ここに欠点があるとすれば、すべてのプログラマーが多かれ少なかれシステム管理者でもある必要があるということです。ソフトウェアをホスティングしている場合、誰かがサーバーを監視しなければならず、実際にはこれを適切に行えるのはソフトウェアを書いた人だけです。Viawebのシステムは非常に多くのコンポーネントを持ち、頻繁に変更されたため、ソフトウェアとインフラストラクチャの間に明確な境界はありませんでした。そのような境界を恣意的に宣言することは、私たちの設計の選択肢を制限したでしょう。そのため、いつか（「数ヶ月後には」）すべてが十分に安定して、サーバーのことだけを心配する人を雇えるようになることを常に望んでいましたが、それは決して実現しませんでした。

製品を積極的に開発している限り、他に方法はないと思います。Webベースのソフトウェアは、書いて、チェックインして、家に帰るようなものではありません。それは今、あなたのサーバー上で動作している生きたものです。ひどいバグは、一人のユーザーのプロセスをクラッシュさせるだけでなく、全員をクラッシュさせる可能性があります。コードのバグがディスク上のデータを破損させた場合、それを修正しなければなりません。などなど。私たちは、サーバーを毎分監視する必要はないこと（最初の1年ほど経てば）を発見しましたが、最近変更したものを注意深く監視したいと強く思いました。夜遅くにコードをリリースして家に帰ることはありません。

ユーザーを観察する

サーバーベースのソフトウェアでは、コードとより密接に接触できます。また、ユーザーともより密接に接触できます。Intuitは、小売店で顧客に自己紹介し、家に付いていくことを頼むことで有名です。誰かが初めてあなたのソフトウェアを使うのを見たことがあるなら、彼らをどんな驚きが待っていたかを知っているでしょう。

ソフトウェアは、ユーザーがそうあるべきだと考えるように動作すべきです。しかし、ユーザーが何を考えているか、信じてください、彼らを観察するまでは全く分かりません。そして、サーバーベースのソフトウェアは、彼らの行動に関する前例のない情報を提供します。あなたは小規模で人工的なフォーカスグループに限定されません。すべてのユーザーによるすべてのクリックを見ることができます。ユーザーのプライバシーを侵害したくないので、何を見るかを慎重に検討する必要がありますが、最も一般的な統計サンプリングでさえ非常に役立ちます。

サーバーにユーザーがいる場合、例えばベンチマークに頼る必要はありません。ベンチマークはシミュレートされたユーザーです。サーバーベースのソフトウェアでは、実際のユーザーを観察できます。何を最適化するかを決定するには、サーバーにログインして、何がCPUをすべて消費しているかを確認するだけです。そして、いつ最適化を停止すべきかも知っています。私たちは最終的にViawebエディタをCPUバウンドではなくメモリバウンドの状態にまで持っていきました。そして、ユーザーデータのサイズを減らすためにできること（簡単なことではありませんが）は何もなかったので、そこで停止しても良いと知っていました。

サーバーベースのソフトウェアでは、ハードウェアの費用を支払うため、効率が重要です。サーバーあたりでサポートできるユーザー数は資本コストの除数となるため、ソフトウェアを非常に効率的にすれば、競合他社より安く販売しても利益を上げることができます。Viawebでは、ユーザーあたりの資本コストを約5ドルにまで下げました。今ではもっと安く、おそらく最初の月の請求書を送る費用よりも安いでしょう。ソフトウェアが合理的に効率的であれば、今やハードウェアは無料です。

ユーザーを観察することは、最適化だけでなく設計においてもあなたを導くことができます。ViawebにはRTMLというスクリプト言語があり、上級ユーザーが独自のページスタイルを定義できました。RTMLは一種の提案箱になったことがわかりました。なぜなら、ユーザーは事前定義されたページスタイルでは望むことができない場合にのみそれを使用したからです。例えば、当初エディタはページ全体にボタンバーを配置していましたが、多くのユーザーがRTMLを使ってボタンを左側に配置した後、私たちはそれを事前定義されたページスタイルのオプション（実際にはデフォルト）にしました。

最後に、ユーザーを観察することで、彼らが困っているときをしばしば知ることができます。そして、顧客は常に正しいので、それは修正する必要がある何かの兆候です。Viawebでは、ユーザーを獲得する鍵はオンライン試用版でした。それはマーケティング担当者が作成した一連のスライドだけではありませんでした。私たちの試用版では、ユーザーは実際にソフトウェアを使用しました。約5分かかり、その終わりには、実際に機能するストアを構築していました。

試用版は、私たちがほとんどすべての新規ユーザーを獲得した方法でした。ほとんどのWebベースのアプリケーションでも同じだと思います。ユーザーが試用版を成功裏に完了できれば、彼らは製品を気に入るでしょう。混乱したり飽きたりすれば、気に入らないでしょう。したがって、より多くの人々を試用版を完了させるためにできることは何でも、私たちの成長率を高めるでしょう。

私は試用版を利用する人々のクリック履歴を調査し、ある段階で彼らが混乱し、ブラウザの戻るボタンをクリックすることを発見しました。（Webベースのアプリケーションを書き始めると、戻るボタンが最も興味深い哲学的な問題の一つになることに気づくでしょう。）そこで、その時点でメッセージを追加し、ユーザーにほとんど完了していることを伝え、戻るボタンをクリックしないように注意を促しました。Webベースのソフトウェアのもう一つの素晴らしい点は、変更から即座にフィードバックが得られることです。試用版を完了する人の数は、この変更だけで60%から90%にすぐに上昇しました。そして、新規ユーザーの数は完了した試用版の数に比例するため、私たちの収益成長率は50%増加しました。

お金

1990年代初頭、私は誰かがソフトウェアはサブスクリプションビジネスだと言っている記事を読みました。最初は非常にシニカルな発言だと思いましたが、後にそれが現実を反映していることに気づきました。ソフトウェア開発は継続的なプロセスです。人々にお金を払い続けてもらうために、新しいバージョンを買い続け、インストールさせ続けるのではなく、公然とサブスクリプション料金を請求する方がクリーンだと思います。そして幸いなことに、サブスクリプションはWebベースのアプリケーションの請求方法として自然なものです。

アプリケーションのホスティングは、フリーウェアでは埋められない役割を企業が果たす分野です。アプリケーションのホスティングには多くのストレスと実際の費用がかかります。誰もそれを無料でやりたがらないでしょう。

企業にとって、Webベースのアプリケーションは理想的な収益源です。四半期ごとに白紙の状態から始めるのではなく、継続的な収益源があります。ソフトウェアは徐々に進化するため、新しいモデルが失敗することを心配する必要はありません。新しいモデルそのものが存在する必要はなく、ユーザーが嫌うようなことをソフトウェアにしても、すぐにわかります。回収不能な請求書に悩むこともありません。誰かが支払わない場合、サービスを停止するだけです。そして、著作権侵害の可能性もありません。

最後の「利点」は問題になるかもしれません。ある程度の著作権侵害はソフトウェア会社にとって有利に働きます。もしあるユーザーがどんな値段でもあなたのソフトウェアを買わなかったとしたら、彼が海賊版を使っても何も失うものはありません。実際、彼はあなたのソフトウェアを標準にするのを助けるもう一人のユーザーであるため、あるいは高校を卒業した後にコピーを買うかもしれないため、あなたは利益を得ます。

企業は可能な場合、価格差別と呼ばれることを行いたがります。これは、各顧客が支払えるだけの金額を請求することを意味します。[8]ソフトウェアは特に価格差別に適しています。なぜなら、限界費用がゼロに近いからです。これが、一部のソフトウェアがIntelマシンよりもSunで実行する方が費用がかかる理由です。Sunを使用する企業は費用を節約することに興味がなく、より多く請求しても安全だからです。著作権侵害は、実質的に価格差別の最低層です。ソフトウェア会社はこれを理解しており、ある種の著作権侵害には意図的に目をつぶっていると思います。[9]サーバーベースのソフトウェアでは、彼らは他の解決策を考え出さなければならないでしょう。

Webベースのソフトウェアは、特にデスクトップソフトウェアと比較して、買いやすいためによく売れます。人々は何かを買うことを決めてから、それを買うという2つの別々のステップだと考えるかもしれません。Viaweb以前は、私がこの問題について考えた限りではそう思っていました。実際には、2番目のステップが最初のステップに逆流することがあります。もし何かを買いにくい場合、人々はそれを欲しがっていたかどうか考え直すでしょう。そしてその逆も然りです。買いやすいものであれば、より多く売れるでしょう。Amazonが存在するから、私はより多くの本を買います。Webベースのソフトウェアは、特にオンラインデモを終えたばかりであれば、世界で最も買いやすいものです。ユーザーはクレジットカード番号を入力する以上のことをする必要はありません。（それ以上をさせると危険です。）

Webベースのソフトウェアは、再販業者として機能するISPを通じて提供されることがあります。これは悪いアイデアです。ハードウェアとソフトウェアの両方を常に改善する必要があるため、サーバーを管理しなければなりません。サーバーの直接制御を放棄すると、Webベースのアプリケーションを開発する利点のほとんどを放棄することになります。

競合他社のいくつかは、この方法で自滅しました。おそらく、巨大な潜在的チャネルに興奮し、それを介して販売しようとしていた製品を台無しにするとは気づかなかったスーツ組に圧倒されたためだと思います。ISPを通じてWebベースのソフトウェアを販売するのは、自動販売機で寿司を売るようなものです。

顧客

顧客は誰になるのでしょうか？Viawebでは、当初は個人や中小企業でした。Webベースのアプリケーションでもこれが一般的になると思います。これらは新しいことを試す準備ができているユーザーであり、一部はより柔軟であるため、一部は新しい技術の低コストを望んでいるためです。

Webベースのアプリケーションは、大企業にとっても最良のものとなることがよくあります（ただし、彼らがそれに気づくのは遅いでしょう）。最高のイントラネットはインターネットです。企業が真のWebベースのアプリケーションを使用すれば、ソフトウェアはより良く機能し、サーバーはより良く管理され、従業員はどこからでもシステムにアクセスできるようになります。

このアプローチに対する反論は通常、セキュリティにかかっています。従業員にとってアクセスが容易であれば、悪意のある人々にとってもそうなるからです。一部の大規模な商人は、顧客のクレジットカード情報が自社のサーバーにある方が安全だと考えたため、Viawebの使用をためらいました。この点を外交的に説明するのは簡単ではありませんでしたが、実際にはデータは彼らの手にあるよりも私たちの手にある方がほぼ確実に安全でした。セキュリティを管理するためにより良い人材を雇えるのは、サーバーの運用を事業とするテクノロジースタートアップでしょうか、それとも衣料品小売業者でしょうか？私たちはセキュリティについてより良い人材を抱えていただけでなく、より心配していました。もし衣料品小売業者のサーバーに誰かが侵入した場合、せいぜい一人の商人に影響を与えるだけで、おそらく隠蔽され、最悪の場合でも一人が解雇されるだけでしょう。もし私たちのサーバーに誰かが侵入した場合、数千人の商人に影響を与え、おそらくCNetのニュースになり、私たちを廃業に追い込む可能性があります。

お金を安全に保ちたいなら、自宅のマットレスの下に隠しますか、それとも銀行に預けますか？この議論は、サーバー管理のあらゆる側面に当てはまります。セキュリティだけでなく、アップタイム、帯域幅、負荷管理、バックアップなどです。私たちの存在は、これらのことを正しく行うことに依存していました。サーバーの問題は私たちにとって大禁忌でした。危険な玩具が玩具メーカーにとってそうであるように、サルモネラ菌の発生が食品加工業者にとってそうであるように。

Webベースのアプリケーションを使用する大企業は、その範囲でITをアウトソーシングしていることになります。過激に聞こえるかもしれませんが、これは一般的に良いアイデアだと思います。企業は、社内システム管理者からよりも、この方法でより良いサービスを受けられる可能性が高いです。システム管理者は、競争圧力に直接さらされていないため、不機嫌で反応が悪くなることがあります。営業担当者は顧客と取引しなければならず、開発者は競合他社のソフトウェアと取引しなければなりませんが、システム管理者は、老独身者のように、彼を規律正しく保つ外部の力がほとんどありません。[10]Viawebでは、私たちを規律正しく保つための外部の力が豊富にありました。私たちに電話をかけてくる人々は顧客であり、単なる同僚ではありませんでした。サーバーが詰まると、私たちは飛び上がりました。何年も経った今でも、それを考えるだけでアドレナリンが湧き上がります。

したがって、Webベースのアプリケーションは通常、大企業にとっても正しい答えとなるでしょう。しかし、デスクトップコンピュータの場合と同様に、彼らがそれに気づくのは最後になるでしょう。そして、一部は同じ理由からです。大企業に、より高価なものが必要だと納得させるには、多額の費用がかかるからです。

裕福な顧客が高価なソリューションを購入する傾向は常にあります。安価なソリューションの方が優れている場合でもです。なぜなら、高価なソリューションを提供する人々は、それを販売するためにより多くのお金を費やすことができるからです。Viawebでは、常にこれに直面していました。私たちは、いくつかのハイエンドの商人をWebコンサルティング会社に奪われました。彼らは、自社のサーバーで特注のオンラインストアに50万ドルを支払えば、より良い状態になると彼らを納得させました。彼らは、クリスマス商戦が始まり、サーバーの負荷が上昇したときに、複数の人が発見したように、通常はより良い状態ではありませんでした。Viawebは、これらの商人のほとんどが得たものよりもはるかに洗練されていましたが、私たちはそれを伝える余裕がありませんでした。月額300ドルでは、身なりの良い、権威ある声の人々のチームを顧客にプレゼンテーションさせる余裕はありませんでした。

大企業が余分に支払う費用の大部分は、高価なものを彼らに販売するためのコストです。（国防総省が便座に1000ドル支払うなら、それは便座を1000ドルで販売するのに多大な費用がかかるためでもあります。）そして、これがイントラネットソフトウェアが、おそらく悪いアイデアであるにもかかわらず、繁栄し続ける理由の一つです。単に高価だからです。この難問についてできることは何もないので、最善の計画はまず小規模な顧客を狙うことです。残りはやがてついてくるでしょう。

サーバーの息子

サーバー上でソフトウェアを実行することは、何も新しいことではありません。実際、それは古いモデルです。メインフレームアプリケーションはすべてサーバーベースです。もしサーバーベースのソフトウェアがそんなに良いアイデアなら、なぜ前回は負けたのでしょうか？なぜデスクトップコンピュータはメインフレームを凌駕したのでしょうか？

当初、デスクトップコンピュータはそれほど脅威には見えませんでした。最初のユーザーはすべてハッカー、あるいは当時そう呼ばれていたホビイストでした。彼らはマイクロコンピュータが安価だったため、それを気に入りました。初めて、自分自身のコンピュータを持つことができたのです。「パーソナルコンピュータ」という言葉は今や言語の一部ですが、それが初めて使われたときには、今日の「個人衛星」という言葉のように、意図的に大胆な響きを持っていました。

なぜデスクトップコンピュータが主流になったのでしょうか？私は、彼らがより良いソフトウェアを持っていたからだと思います。そして、マイクロコンピュータのソフトウェアがより良かった理由は、中小企業によって書かれることができたからだと思います。

多くの人が、スタートアップが初期段階でどれほど脆弱で一時的なものかを知らないと思います。多くのスタートアップはほとんど偶然に始まります。日中の仕事をしているか、学校に通っている数人の男が、有望に見えれば会社になるかもしれないもののプロトタイプを書くことから始まります。この幼虫段階では、どんな大きな障害でもスタートアップをその場で停止させてしまいます。メインフレームソフトウェアを書くには、事前のコミットメントが大きすぎました。開発マシンは高価で、顧客が大企業であるため、彼らに販売するためには見栄えの良い営業部隊が必要でした。メインフレームソフトウェアを書くためのスタートアップを始めることは、夜にApple IIで何かをハッキングして作り上げるよりもはるかに真剣な事業でした。そのため、メインフレームアプリケーションを書くスタートアップは多くありませんでした。

デスクトップコンピュータの登場は、多くの新しいソフトウェアを刺激しました。なぜなら、それらのアプリケーションを書くことは、幼虫段階のスタートアップにとって達成可能な目標に見えたからです。開発は安価で、顧客はコンピュータストアや通信販売を通じて到達できる個人でした。

デスクトップコンピュータを主流に押し出したアプリケーションは、最初のスプレッドシートであるVisiCalcでした。それは屋根裏部屋で働く2人の男によって書かれましたが、メインフレームソフトウェアではできなかったことを成し遂げました。[11]VisiCalcは、その時代において、人々がそれを実行するためだけにApple IIを購入するほどの進歩でした。そして、これがトレンドの始まりでした。デスクトップコンピュータは、スタートアップがそれらのためにソフトウェアを書いたために勝利したのです。

サーバーベースのソフトウェアは、今回も成功するでしょう。なぜなら、スタートアップがそれを書くからです。コンピュータは今や非常に安価なので、私たちが行ったように、デスクトップコンピュータをサーバーとして使用して始めることができます。安価なプロセッサはワークステーション市場を食い尽くし（今ではその言葉を聞くことさえめったにありません）、サーバー市場のほとんどを席巻しています。インターネット上で最も高い負荷を処理するYahooのサーバーはすべて、あなたのデスクトップマシンと同じ安価なIntelプロセッサを搭載しています。そして、ソフトウェアを書き終えれば、それを販売するために必要なのはWebサイトだけです。私たちのユーザーのほとんどは、口コミやメディアの言及を通じて直接私たちのサイトに来ました。[12]

Viawebは典型的な幼虫段階のスタートアップでした。私たちは会社を始めることに怯えており、最初の数ヶ月間は、すべてをいつでも中止できる実験と見なすことで自分たちを慰めていました。幸いなことに、技術的なもの以外に障害はほとんどありませんでした。ソフトウェアを書いている間、私たちのWebサーバーは開発に使用していたデスクトップマシンと同じで、ダイヤルアップ回線で外部と接続されていました。その段階での唯一の費用は食費と家賃でした。

今、スタートアップがWebベースのソフトウェアを書く理由はさらにあります。デスクトップソフトウェアを書くのがはるかに楽しくなくなったからです。今デスクトップソフトウェアを書きたいなら、Microsoftの条件に従い、彼らのAPIを呼び出し、彼らのバグの多いOSを回避しながら行わなければなりません。そして、もし成功するようなものを書けたとしても、あなたは単にMicrosoftの市場調査をしていただけだったと気づくかもしれません。

企業がスタートアップが構築するプラットフォームを作りたいのであれば、ハッカー自身が使いたくなるようなものにしなければなりません。それは、安価でよく設計されている必要があるということです。Macは最初に出たとき、ハッカーに人気があり、多くのハッカーがそれのためにソフトウェアを書きました。[13]Windowsではこれがあまり見られません。なぜなら、ハッカーはそれを使わないからです。ソフトウェアを書くのが得意な人々は、今ではLinuxやFreeBSDを実行する傾向があります。

私たちはデスクトップソフトウェアを書くためのスタートアップを始めることはなかったと思います。なぜなら、デスクトップソフトウェアはWindows上で動作しなければならず、Windowsのためにソフトウェアを書く前に、私たちはそれを使わなければならなかったからです。Webは私たちにWindowsを回避させ、Unix上で動作するソフトウェアをブラウザを通じてユーザーに直接提供することを可能にしました。それは、25年前のPCの登場と非常によく似た、解放的な見通しです。

Microsoft

デスクトップコンピュータが登場した頃、IBMは誰もが恐れる巨大企業でした。今では想像しにくいかもしれませんが、その感覚をよく覚えています。今、恐ろしい巨大企業はMicrosoftであり、彼らはIBMがそうであったように、自分たちに迫る脅威に盲目ではないと思います。結局のところ、Microsoftは意図的にIBMの死角でビジネスを構築しました。

先ほど、私の母は本当にデスクトップコンピュータを必要としていないと述べました。ほとんどのユーザーもおそらくそうではありません。それはMicrosoftにとって問題であり、彼らはそれを知っています。アプリケーションがリモートサーバー上で動作する場合、誰もWindowsを必要としません。Microsoftはどうするのでしょうか？彼らはデスクトップの支配力を使って、この新しい世代のソフトウェアを阻止したり、制限したりできるのでしょうか？

私の推測では、Microsoftは何らかのサーバー/デスクトップハイブリッドを開発するでしょう。そこでは、オペレーティングシステムが彼らが管理するサーバーと連携します。少なくとも、ファイルを中央で利用できるようにするでしょう。Microsoftが、クライアントとしてブラウザだけを使用し、計算をサーバーで行うという極端なところまで行くことは、避けられるのであればしないでしょう。クライアントとしてブラウザだけが必要な場合、クライアントにMicrosoftは必要なく、Microsoftがクライアントを制御できない場合、ユーザーを彼らのサーバーベースのアプリケーションに誘導することはできません。

Microsoftが魔法のランプの魔神を瓶に閉じ込めるのは難しいと思います。彼らがすべてを制御するには、あまりにも多くの異なる種類のクライアントが存在するでしょう。そして、Microsoftのアプリケーションが一部のクライアントでしか動作しない場合、競合他社はどのクライアントからでも動作するアプリケーションを提供することで彼らを凌駕できるでしょう。[14]

Webベースのアプリケーションの世界では、Microsoftのための自動的な場所はありません。彼らは自分たちの場所を確保することに成功するかもしれませんが、デスクトップアプリケーションの世界を支配したように、この新しい世界を支配することはないと思います。

競合他社が彼らをつまずかせるというよりも、彼ら自身がつまずくでしょう。Webベースのソフトウェアの台頭により、彼らは技術的な問題だけでなく、自分たちの希望的観測にも直面することになります。彼らがしなければならないことは、既存のビジネスを共食いすることですが、彼らがそれに向き合うことはできないと思います。彼らをここまで導いた一途さが、今度は彼らに不利に働くでしょう。IBMもまったく同じ状況にあり、それを克服できませんでした。IBMは、稼ぎ頭であるメインフレームコンピューティングを脅かすことへの葛藤から、マイクロコンピュータビジネスへの参入が遅く、中途半端でした。Microsoftも同様に、デスクトップを救いたいという思いに妨げられるでしょう。稼ぎ頭は、背中に乗った厄介な重い猿になり得ます。

サーバーベースのアプリケーションを誰も支配しないと言っているわけではありません。おそらく最終的には誰かが支配するでしょう。しかし、マイクロコンピュータの初期の頃と同じように、陽気な混沌とした良い長い期間があると思います。それはスタートアップにとって良い時代でした。多くの小さな会社が繁栄し、かっこいいものを作ることでそれを成し遂げました。

スタートアップ、さらにその先へ

古典的なスタートアップは、少人数で資金も少なく、迅速で非公式です。その少人数が非常に懸命に働き、テクノロジーが彼らの決定の影響を増幅させます。彼らが勝てば、大きく勝ちます。

Webベースのアプリケーションを書くスタートアップでは、スタートアップに関連するすべてが極端にまで高められます。さらに少ない人数で、さらに少ない資金で製品を書き、ローンチできます。さらに迅速である必要があり、より非公式であることも許されます。文字通り、アパートのリビングルームに座った3人の男と、ISPにコロケーションされたサーバーとして製品をローンチできます。私たちはそうしました。

時間の経過とともに、チームはより小さく、より速く、より非公式になりました。1960年には、ソフトウェア開発とは、角縁メガネと細い黒いネクタイをつけた男たちが部屋いっぱいに集まり、IBMのコーディング用紙に1日10行のコードを熱心に書くことでした。1980年には、オフィスにジーンズを履いてvt100sにタイプする8人から10人のチームでした。今では、リビングルームでラップトップを囲んで座る数人の男たちです。（そして、ジーンズは非公式さの究極ではないことが判明しました。）

スタートアップはストレスが多く、残念ながらこれはWebベースのアプリケーションでも極端にまで高められます。多くのソフトウェア会社、特に初期には、開発者が机の下で寝るなどの期間があります。Webベースのソフトウェアの恐ろしい点は、これがデフォルトになるのを防ぐものがないことです。机の下で寝る話は通常、「そしてついに私たちはそれを出荷し、全員が家に帰って1週間眠った」という結末を迎えます。Webベースのソフトウェアは決して出荷されません。望む限り16時間労働を続けることができます。そして、それが可能であり、競合他社も可能であるため、そうせざるを得なくなる傾向があります。できるから、しなければならないのです。それはパーキンソンの法則の逆転です。

最悪なのは時間ではなく責任です。プログラマーとシステム管理者は伝統的にそれぞれ別々の心配事を抱えています。プログラマーはバグを心配しなければならず、システム管理者はインフラストラクチャを心配しなければなりません。プログラマーはソースコードに肘まで浸かって長い一日を過ごすかもしれませんが、ある時点で家に帰ってそれを忘れることができます。システム管理者は決して仕事を完全に置き去りにすることはありませんが、午前4時にページングされたとしても、通常は非常に複雑なことをする必要はありません。Webベースのアプリケーションでは、これら2種類のストレスが組み合わされます。プログラマーはシステム管理者になりますが、通常仕事を耐えられるものにする明確に定義された限界がありません。

Viawebでは、最初の6ヶ月間はソフトウェアを書くことだけに費やしました。私たちは初期のスタートアップの通常の長時間労働をしました。デスクトップソフトウェア会社であれば、これは懸命に働いていた部分だったでしょうが、ユーザーをサーバーに乗せた次の段階に比べれば、休暇のように感じられました。ViawebをYahooに売却したことの2番目に大きな利点（お金の次に）は、すべてに対する究極の責任を大企業の肩に押し付けることができたことでした。

デスクトップソフトウェアはユーザーにシステム管理者になることを強制します。Webベースのソフトウェアはプログラマーにそれを強制します。全体的なストレスは少ないですが、プログラマーにとってはより多くなります。それは必ずしも悪いニュースではありません。もしあなたが大企業と競合するスタートアップなら、それは良いニュースです。[15]Webベースのアプリケーションは、競合他社を凌駕する簡単な方法を提供します。スタートアップがそれ以上を求めることはありません。

ちょうど十分

Webベースのアプリケーションを書くことを思いとどまらせるかもしれないことの一つは、UIとしてのWebページの不十分さです。それは問題だと認めます。HTMLとHTTPに_本当に_追加したかったことがいくつかありました。しかし、重要なのは、Webページがちょうど十分であるということです。

ここには最初のマイクロコンピュータとの類似点があります。それらのマシンのプロセッサは、実際にはコンピュータのCPUとして意図されていませんでした。それらは信号機のようなものに使用されるように設計されていました。しかし、Altairを設計したエド・ロバーツのような人々は、それらがちょうど十分であることに気づきました。これらのチップの1つをメモリ（最初のAltairでは256バイト）とフロントパネルスイッチと組み合わせれば、動作するコンピュータが手に入ります。自分自身のコンピュータを持てることは非常にエキサイティングだったので、どれほど制限されていても、それを買いたいと思う人々がたくさんいました。

WebページはアプリケーションのUIとして設計されたものではありませんでしたが、ちょうど十分です。そして、かなりの数のユーザーにとって、どのブラウザからでも使用できるソフトウェアは、UIのどんな不便さをも上回る十分な利点となるでしょう。HTMLを使って最高の見た目のスプレッドシートを書くことはできないかもしれませんが、特別なクライアントソフトウェアなしで複数の人が異なる場所から同時に使用できるスプレッドシートや、ライブデータフィードを組み込めるスプレッドシート、特定の条件がトリガーされたときにページングで通知できるスプレッドシートを書くことはできます。さらに重要なのは、まだ名前もない新しい種類のアプリケーションを書くことができるということです。VisiCalcは、単なるメインフレームアプリケーションのマイクロコンピュータ版ではなかったのですから、それは新しい種類のアプリケーションでした。

もちろん、サーバーベースのアプリケーションはWebベースである必要はありません。他の種類のクライアントを持つこともできます。しかし、それは悪いアイデアだと確信しています。誰もがあなたのクライアントをインストールすると仮定できれば非常に便利でしょう。あまりにも便利なので、誰もがそうすると簡単に自分を納得させられるでしょう。しかし、もし彼らがインストールしなければ、あなたは窮地に陥ります。Webベースのソフトウェアはクライアントについて何も仮定しないため、Webが機能する場所ならどこでも動作します。それはすでに大きな利点であり、新しいWebデバイスが普及するにつれてその利点は増大するでしょう。ユーザーはあなたのソフトウェアがただ動作するからあなたを気に入るでしょうし、あなたは新しいクライアントごとに調整する必要がないため、あなたの人生はより楽になるでしょう。[16]

私は誰よりもWebの進化を密接に見てきたと感じていますが、クライアントで何が起こるかは予測できません。収束はおそらく来るでしょうが、どこで？勝者を選ぶことはできません。一つ予測できるのは、AOLとMicrosoftの間の対立です。Microsoftの.NETがどうなるにせよ、おそらくデスクトップとサーバーの接続に関わるでしょう。AOLが反撃しなければ、彼らは脇に追いやられるか、Microsoftのクライアントとサーバーソフトウェア間のパイプに変えられるでしょう。もしMicrosoftとAOLがクライアント戦争に突入すれば、両方で確実に動作する唯一のものはWebブラウジングであり、それはWebベースのアプリケーションがどこでも動作する唯一の種類になることを意味します。

すべてがどうなるのか？私には分かりません。そして、Webベースのアプリケーションに賭けるなら、知る必要はありません。誰もブラウジングを壊さずにそれを壊すことはできません。Webはソフトウェアを提供する唯一の方法ではないかもしれませんが、今機能しており、今後も長く機能し続けるでしょう。Webベースのアプリケーションは開発コストが安く、最小のスタートアップでも簡単に提供できます。多くの仕事があり、特にストレスの多い種類ですが、それはスタートアップにとっての勝算を高めるだけです。

なぜやらないのか？

E. B. ホワイトは、農家の友人から、多くの電化されたフェンスには電流が流れていないことを知って面白がりました。牛は明らかにそれらに近づかないことを学び、その後は電流は必要ないのです。「立ち上がれ、牛たちよ！」と彼は書きました。「暴君がいびきをかいている間に自由を掴むのだ！」

もしあなたがいつかスタートアップを始めようと考えているハッカーなら、おそらくそれを妨げているものが2つあります。一つは、ビジネスについて何も知らないこと。もう一つは、競争を恐れていること。これらのフェンスにはどちらも電流は流れていません。

ビジネスについて知るべきことは2つだけです。ユーザーが愛するものを構築すること、そして使う以上を稼ぐこと。この2つを正しく行えば、ほとんどのスタートアップより先行できるでしょう。残りは進みながら解決できます。

最初は使う以上を稼げないかもしれませんが、その差が十分に速く縮まっていれば大丈夫です。もし資金不足で始めたとしても、少なくとも倹約の習慣を奨励するでしょう。使うお金が少なければ少ないほど、使う以上を稼ぐのが簡単になります。幸いなことに、Webベースのアプリケーションをローンチするのは非常に安価です。私たちは1万ドル未満でローンチしましたが、今ならもっと安くなるでしょう。私たちはサーバーに数千ドル、SSLにさらに数千ドルを費やさなければなりませんでした。（当時SSLソフトウェアを販売していた唯一の会社はNetscapeでした。）今では、はるかに強力なサーバーを、SSL込みで、私たちが帯域幅だけで支払った金額よりも安く借りることができます。今なら、豪華なオフィスチェアの費用よりも安くWebベースのアプリケーションをローンチできます。

ユーザーが愛するものを構築することについては、いくつかの一般的なヒントがあります。まず、自分自身が使いたいと思うような、クリーンでシンプルなものを作ることから始めましょう。バージョン1.0を迅速にリリースし、その後もユーザーの声に密接に耳を傾けながらソフトウェアを改善し続けましょう。顧客は常に正しいですが、異なる顧客は異なることについて正しいのです。最も洗練されていないユーザーは、簡素化し明確にする必要があるものを示し、最も洗練されたユーザーは、追加する必要がある機能を示します。ソフトウェアが最も良い状態であるのは「簡単」であることですが、これを行う方法は、デフォルトを正しく設定することであり、ユーザーの選択肢を制限することではありません。競合他社のソフトウェアが不十分だからといって自己満足に陥らないでください。あなたのソフトウェアを比較する基準は、それがどうあるべきかであり、現在の競合他社がたまたま持っているものではありません。常に自分のソフトウェアを自分で使いましょう。Viawebはオンラインストアビルダーであるはずでしたが、私たちは自分たちのサイトを作るためにもそれを使いました。役職があるからといって、マーケティング担当者やデザイナー、プロダクトマネージャーの言うことを聞かないでください。彼らが良いアイデアを持っていればそれを利用しますが、最終的に決めるのはあなたです。ソフトウェアは、デザインを理解しているハッカーによって設計されるべきであり、ソフトウェアについて少し知っているデザイナーによって設計されるべきではありません。ソフトウェアを実装するのと同じくらい設計ができないのであれば、スタートアップを始めないでください。

さて、競争について話しましょう。あなたが恐れているのは、おそらくあなたのようなハッカーのグループではなく、オフィスや事業計画、営業担当者などを抱える実際の企業ですよね？まあ、彼らはあなたが彼らを恐れている以上にあなたを恐れており、それは正しいことです。数人のハッカーがオフィススペースを借りたり、営業担当者を雇ったりする方法を考えるのは、どんな規模の企業がソフトウェアを書いてもらうよりもはるかに簡単です。私は両方の立場を経験しましたが、それは知っています。ViawebがYahooに買収されたとき、私は突然大企業で働くことになり、それは腰まで水に浸かって走ろうとするようなものでした。

Yahooを軽蔑するつもりはありません。彼らには優秀なハッカーもいましたし、トップマネジメントは真のやり手でした。大企業としては、彼らは例外的でした。しかし、それでも小さなスタートアップの約10分の1の生産性しかありませんでした。どんな大企業もそれ以上はできません。Microsoftの恐ろしい点は、あれほど大きな企業がソフトウェアを開発できることです。彼らは歩く山のようなものです。

威圧されないでください。Microsoftができないことと同じくらい、あなたができないことをMicrosoftはできます。そして、誰もあなたを止めることはできません。Webベースのアプリケーションを開発するために誰の許可も求める必要はありません。ライセンス契約を結んだり、小売店の棚スペースを確保したり、アプリケーションをOSにバンドルしてもらうためにへりくだったりする必要はありません。ソフトウェアをブラウザに直接提供でき、誰もあなたと潜在的なユーザーの間に割り込むことはできません。彼らがWebを閲覧するのを妨げない限り。

信じられないかもしれませんが、約束します。Microsoftはあなたを恐れています。自己満足に陥った中間管理職はそうではないかもしれませんが、ビルは恐れています。なぜなら、彼もかつてはあなただったからです。25年前の1975年、新しいソフトウェア提供方法が登場した時、彼もそうでした。

注釈

[1] 収益の多くがサービスにあることを認識し、軽量クライアントを構築する企業は通常、ハードウェアとオンラインサービスを組み合わせようと試みてきました。このアプローチはうまくいきませんでした。一部には、家電製品を構築する会社とオンラインサービスを運営する会社という2種類の異なる会社が必要であるため、また一部には、ユーザーがそのアイデアを嫌うためです。剃刀を無料で配り、刃で儲けるという方法はGilletteには通用するかもしれませんが、剃刀はWeb端末よりもはるかに小さなコミットメントです。携帯電話端末メーカーは、サービス収益も獲得しようとせずにハードウェアを販売することに満足しています。インターネットクライアントも同様のモデルであるべきでしょう。もし誰かが、どのISPからでも接続できるWebブラウザ付きの素敵な小さな箱を販売するだけであれば、国内のすべてのテクノフォブ（技術嫌いな人）がそれを買うでしょう。

[2] セキュリティは常に、設計上の決定よりも失敗しないことに依存しますが、サーバーベースのソフトウェアの性質上、開発者は失敗しないことにもっと注意を払うようになるでしょう。サーバーを侵害することは非常に大きな損害を引き起こす可能性があるため、ASP（事業を継続したい企業）はセキュリティに注意を払う可能性が高いです。

[3] 1995年、Viawebを始めた当時、Javaアプレットは誰もがサーバーベースのアプリケーションを開発するために使用する技術だとされていました。アプレットは私たちには時代遅れのアイデアに見えました。クライアントで実行するためにプログラムをダウンロードする？完全にサーバーでプログラムを実行する方が簡単です。私たちはアプレットにほとんど時間を費やしませんでしたが、他の無数のスタートアップがこのタールピットに誘い込まれたに違いありません。生き残った者はほとんどいないでしょう。そうでなければ、MicrosoftがExplorerの最新バージョンでJavaを廃止することに成功するはずがありません。

[4] この点はトレバー・ブラックウェルによるもので、彼は「ソフトウェアの作成コストはそのサイズに対して線形以上に増加する。おそらくこれは主に古いバグの修正によるものであり、すべてのバグが迅速に発見されれば、コストはより線形になる可能性がある」と付け加えています。

[5] 最も見つけにくい種類のバグは、あるバグが別のバグを偶然相殺する複合バグの変種かもしれません。あるバグを修正すると、別のバグが明らかになります。しかし、それが最後に変更されたものであるため、修正が原因であるかのように見えるでしょう。

[6] Viaweb社内で、かつて私たちのソフトウェアの最悪な点を説明するコンテストがありました。カスタマーサポートの2人が同点で1位を獲得しましたが、その内容は今でも思い出すと身震いします。私たちは両方の問題をすぐに修正しました。

[7] ロバート・モリスは、買い物客が注文するために使用する注文システムを書きました。トレバー・ブラックウェルは、業者が注文を取得し、統計を表示し、ドメイン名などを設定するために使用する画像生成器とマネージャーを書きました。私は、業者がサイトを構築するために使用するエディタを書きました。注文システムと画像生成器はCとC++で書かれ、マネージャーはほとんどPerlで、エディタはLispで書かれました。

[8] 価格差別は非常に広範にわたるため（小売業者が彼らの購買力があなたにとっての低価格を意味すると主張するのを聞いたことがありますか？）、1936年のロビンソン・パットマン法によって米国で違法とされていることを知って驚きました。この法律は厳しく施行されているようには見えません。

[9] 『No Logo』の中で、ナオミ・クラインは、「都市の若者」に好まれる衣料品ブランドは、万引きをあまり厳しく防ごうとしないと述べています。なぜなら、彼らのターゲット市場では、万引き犯がファッションリーダーでもあるからです。

[10] 企業はしばしば、何をアウトソースし、何をしないべきか疑問に思います。一つの可能な答え：競争圧力に直接さらされていない仕事はすべてアウトソースする。そうすることで、それを競争圧力にさらすことになるからです。

[11] その2人の男とはダン・ブリックリンとボブ・フランクストンでした。ダンは数日でBasicでプロトタイプを書き、その後1年間（主に夜間に）協力して、6502マシン語で書かれたより強力なバージョンを作成しました。当時ダンはハーバードビジネススクールに在籍しており、ボブは名目上ソフトウェアを書く日中の仕事を持っていました。「ビジネスをすることに大きなリスクはなかった」とボブは書いています。「失敗したら失敗しただけ。大したことない。」

[12] 私が言うほど簡単ではありません。口コミが広がるのに痛ましいほど長い時間がかかり、毎月16,000ドルでPR会社（確かに業界最高でしたが）を雇うまで、多くのメディア報道を得ることはありませんでした。しかし、唯一の重要なチャネルが私たち自身のWebサイトであったことは事実です。

[13] Macがそんなに素晴らしかったのに、なぜ負けたのか？またしてもコストです。Microsoftはソフトウェアビジネスに集中し、Appleハードウェアに安価な部品供給業者の群れを解き放ちました。また、重要な時期にスーツ組が支配したことも助けにはなりませんでした。

[14] Webベースのアプリケーションを助け、次世代ソフトウェアがMicrosoftに影を落とされないようにする一つのことは、良いオープンソースブラウザでしょう。Mozillaはオープンソースですが、長い間企業ソフトウェアであったために苦しんでいるようです。活発にメンテナンスされている小型で高速なブラウザはそれ自体素晴らしいものであり、企業が小さなWebアプライアンスを構築するのを奨励するでしょう。

とりわけ、適切なオープンソースブラウザは、HTTPとHTMLが進化し続ける原因となるでしょう（例えばPerlのように）。Webベースのアプリケーションにとって、リンクを選択することとそれに従うことを区別できることは非常に役立つでしょう。これを行うために必要なのは、HTTPの些細な機能強化だけで、リクエストに複数のURLを許可することです。カスケードメニューも良いでしょう。

世界を変えたいなら、新しいMosaicを書きましょう。もう遅すぎると思いますか？1998年には、多くの人が新しい検索エンジンを立ち上げるのは遅すぎると考えていましたが、Googleは彼らが間違っていることを証明しました。現在の選択肢が十分にひどいなら、常に新しいものの余地はあります。まず、すべての無料OSで動作することを確認してください。新しいものはユーザーから始まります。

[15] トレバー・ブラックウェルは、おそらく誰よりも個人的な経験からこれについて詳しいでしょう。彼は次のように書いています。

「サーバーベースのソフトウェアがプログラマーにとって非常に厳しいものであるため、それは大企業からの根本的な経済的シフトを引き起こす、と私はさらに踏み込んで言いたい。それは、プログラマーが自分の会社である場合にのみ提供しようとするような、集中力と献身を必要とする。ソフトウェア会社は、あまり要求の厳しくない環境で働く熟練した人材を雇うことはできるし、困難に耐える未熟な人材を雇うこともできるが、高度なスキルを持つ人材に尻を叩かせることはできない。資本がもはや必要とされないため、大企業が提供できるものはほとんどない。」

[16] このエッセイのオリジナル版では、Javascriptを避けるよう助言しました。2001年には良い計画でしたが、Javascriptは現在機能します。

謝辞

この論文の草稿を読んでくれたサラ・ハーリン、トレバー・ブラックウェル、ロバート・モリス、エリック・レイモンド、ケン・アンダーソン、ダン・ギフィンに感謝します。VisiCalcに関する情報を提供してくれたダン・ブリックリンとボブ・フランクストンに感謝します。そして、BBNでの講演に招待してくれたケン・アンダーソンに改めて感謝します。

このエッセイと他の14のエッセイは『Hackers & Painters』に収録されています。