もう一つの道

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 台を所有しています。私の母は、電子メールと会計用にコンピュータを 1 台持っています。約 1 年前、母は Apple から、オペレーティングシステムの新バージョンを割引価格で提供するという手紙を受け取って驚きました。電子メールと会計用にコンピュータを使いたい 65 歳の女性が、新しいオペレーティングシステムのインストールについて考えなければならないというのは、何かがおかしいのです。一般のユーザーは、「オペレーティングシステム」という言葉さえ知らないはずです。ましてや、「デバイスドライバー」や「パッチ」など知りません。

ユーザーがシステム管理者になる手間を省くソフトウェアを提供する別の方法があります。Web ベースのアプリケーションは、Web サーバー上で実行され、Web ページをユーザーインターフェイスとして使用するプログラムです。平均的なユーザーにとって、この新しい種類のソフトウェアは、デスクトップソフトウェアよりも簡単で、安価で、モバイル性が高く、信頼性が高く、多くの場合、より強力です。

Web ベースのソフトウェアでは、ほとんどのユーザーは、使用するアプリケーション以外のことは何も考えなくて済みます。煩雑で変化するものはすべて、どこかのサーバーに置かれ、その種のことに長けた人々によって管理されます。したがって、ソフトウェアを使用するために、通常はコンピューター自体は必要ありません。キーボード、画面、Web ブラウザーを備えたものがあれば十分です。ワイヤレスインターネットアクセスも可能かもしれません。携帯電話も必要かもしれません。いずれにせよ、それは消費者向け電子機器です。つまり、約 200 ドルで、ケースの外観で選ぶ人が多いものです。現在電話を購入するのと同じように、インターネットサービスにはハードウェアよりも多くの料金を支払うことになります。[1]

クリックがサーバーに到達して戻ってくるまでに約 10 分の 1 秒かかるため、Photoshop のような高度にインタラクティブなソフトウェアのユーザーは、依然としてデスクトップで計算が行われることを望むでしょう。しかし、ほとんどの人がコンピューターを使用する用途を考えれば、10 分の 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 では、ソフトウェアには、ユーザーが直接対話するかなり大きなアプリケーション、それらのプログラムが使用するプログラム、問題を探すためにバックグラウンドで常に実行されるプログラム、壊れた場合に再起動を試みるプログラム、統計をコンパイルしたり検索用のインデックスを作成したりするために時々実行されるプログラム、リソースのガベージコレクションやデータの移動や復元のために明示的に実行されるプログラム、ユーザーのふりをするプログラム (パフォーマンスを測定したりバグを発見したりするため)、ネットワークの問題を診断するプログラム、バックアップを実行するプログラム、外部サービスへのインターフェイス、リアルタイムのサーバー統計を表示する印象的なダイヤルのコレクションを操作するソフトウェア (訪問者には好評でしたが、私たちにとっても不可欠でした)、オープンソースソフトウェアへの変更 (バグ修正を含む)、および非常に多くの構成ファイルと設定が含まれていました。Trevor Blackwell は、私たちが Yahoo に買収された後、店舗をシャットダウンせずに全国の新しいサーバーに移転するための素晴らしいプログラムを書きました。プログラムは私たちに呼び出しをかけ、ユーザーにファックスや電子メールを送信し、クレジットカードプロセッサとのトランザクションを実行し、ソケット、パイプ、http リクエスト、ssh、udp パケット、共有メモリ、およびファイルを介して互いに通信しました。Viaweb の一部はプログラムが存在しない状態でさえありました。Unix セキュリティの鍵の 1 つは、サーバーへの侵入に使われる可能性のある不要なユーティリティを実行しないことだからです。

ソフトウェアだけでは終わりませんでした。私たちはサーバーの構成について考えるのに多くの時間を費やしました。部品からサーバーを自分たちで構築しました。これは、一部はコストを節約するため、一部はまさに私たちが望んでいるものを手に入れるためです。上流の ISP がすべてのバックボーンに十分な速度で接続できるかどうかも考慮する必要がありました。私たちは RAID サプライヤーを順番に調べました。

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

Web ベースのアプリケーションのソフトウェアは、単一のバイナリではなくプログラムの集合体であるため、さまざまな言語で記述できます。デスクトップソフトウェアを作成する場合、実質的には、基盤となるオペレーティングシステムと同じ言語 (つまり、C および C++) でアプリケーションを作成する必要があります。そのため、これらの言語 (特にマネージャやベンチャーキャピタルなどの非技術者の間で) は、「本格的な」ソフトウェア開発用の言語と見なされるようになりました。ただし、これはデスクトップソフトウェアの提供方法の産物にすぎません。サーバーベースのソフトウェアでは、任意の言語を使用できます。[3] 今日、トップハッカーの多くは、C や C++ とはかけ離れた言語 (Perl、Python、さらには Lisp) を使用しています。

サーバーベースのソフトウェアでは、ハードウェアに至るまでシステム全体を制御できるため、どの言語を使用するべきかを指示できる人はいません。タスクによって適した言語は異なります。それぞれに最適な言語を使用できます。また、競合相手がいる場合、「できる」ということは「しなければならない」という意味になります (これについては後で説明します)。この可能性を利用しなければ、競合相手が利用してしまうからです。

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

リリース

この新しい世界における最も重要な変化の 1 つは、リリースの方法です。デスクトップソフトウェアビジネスでは、リリースを行うのは大変な苦労であり、会社全体が 1 つの巨大なコードを作成するために汗を流し、苦労します。プロセスと結果として得られる製品の両方に、明らかな類似点が浮かび上がります。

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

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

1 年に 1 つの新バージョンしかリリースしない場合は、バグを大量に処理する傾向があります。リリース日の少し前に、コードの半分を削除して置き換えた新バージョンを組み立て、無数のバグを導入します。その後、QA チームが介入してバグを数え始め、プログラマーがリストに沿って作業してバグを修正します。通常、リストの最後までは到達しません。実際、終わりがどこなのかは誰にもわかりません。池から瓦礫を釣り上げるようなものです。ソフトウェア内で何が起こっているのか、実際にはわかりません。せいぜい、統計的な正確さに終わる程度です。

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

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

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

業界のベテランは、ソフトウェアが動作する前にリリースする必要はないというのは聞こえはいいが、特定の日付までにソフトウェアの新しいバージョンを提供すると約束した場合はどうなるのかと考えているかもしれません。Web ベースのソフトウェアでは、バージョンがないため、そのような約束はしません。ソフトウェアは徐々に、継続的に変更されます。変更の中には、他の変更よりも大きいものがあるかもしれませんが、バージョンの概念は Web ベースのソフトウェアに自然には適合しません。

Viaweb を覚えている方なら、これは奇妙に聞こえるかもしれません。なぜなら、私たちは常に新しいバージョンを発表していたからです。これは完全に PR 目的で行われていました。業界紙はバージョン番号で考えるということを私たちは学びました。彼らは、バージョン番号の最初の数字が新しくなるメジャーリリースに対しては大きな報道を行い、小数点の後に新しい数字が付くポイントリリースに対しては通常、最大 1 段落程度しか取り上げません。

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

買収されるまでに、私たちはこの作業を 3 回行っていたため、バージョン 4 になっていました。私の記憶が正しければ、バージョン 4.1 でした。Viaweb が Yahoo Store になった後、宣伝の必要性はそれほど切実ではなくなり、ソフトウェアは進化し続けましたが、バージョン番号の概念はひっそりと廃止されました。

バグ

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

Web ベースのソフトウェアは 24 時間使用されるため、実行するすべての操作はすぐに厳しくチェックされます。バグはすぐに発生します。

ソフトウェア会社は、ユーザーにソフトウェアのデバッグを任せていると非難されることがあります。そして、まさに私が主張しているのはそれです。Web ベースのソフトウェアの場合、バグが少なく、一時的なものであるため、これは実際には良い計画です。ソフトウェアを徐々にリリースすると、最初からバグがはるかに少なくなります。また、エラーを再現して変更を即座にリリースできると、ほとんどのバグは発生次第すぐに見つけて修正できます。正式なバグ追跡システムに煩わされるほど、一度にバグが多すぎることはありません。

もちろん、リリースする前に変更をテストする必要があります。そうすることで、大きなバグがリリースされないようにすることができます。必然的に見逃される少数のバグは、境界線上のケースであり、誰かが苦情を訴える前にそのバグに遭遇した少数のユーザーのみに影響します。バグをすぐに修正する限り、平均的なユーザーにとっての最終的な効果は、バグがはるかに少なくなることです。平均的な Viaweb ユーザーがバグを見たことがあるとは思えません。

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

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

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

デスクトップソフトウェア業界の人には信じられないかもしれませんが、Viaweb ではバグはほとんどゲームのようなものでした。リリースされたバグのほとんどは、限界ぎりぎりのケースに関係していたため、バグに遭遇したユーザーは、限界に挑戦している上級ユーザーである可能性が高かったです。上級ユーザーは、バグに対して寛容です。特に、バグは、彼らが求めていた機能を追加する過程で作り込まれた可能性が高いからです。実際、バグはまれで、バグを見つけるには高度なことをしなければならなかったため、上級ユーザーはバグを見つけると誇らしげに感じることが多くありました。彼らは、私たちからポイントを獲得したかのように、怒りよりも勝利の精神でサポートに電話をかけてきました。

サポート

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

Viaweb ではそうではありませんでした。Viaweb では、お客様の声を聞きたかったため、サポートは無料でした。問題が発生した場合は、エラーを再現して修正プログラムをリリースできるように、すぐに知りたいと考えていました。

そのため、Viaweb では、開発者は常にサポートと緊密に連絡を取り合っていました。カスタマーサポートの担当者はプログラマーから約 30 フィート離れた場所にいて、本物のバグの報告があればいつでも中断できることを知っていました。私たちは、重大なバグを修正するために役員会議を抜け出すこともありました。

私たちのサポートへの取り組みは、皆を幸せにしました。顧客は喜んでいました。サポートラインに電話をかけ、重要なニュースを伝える人として扱われたらどんな気分になるか想像してみてください。顧客サポートの担当者は、スクリプトを読み上げるのではなく、ユーザーを支援できることを喜んでいました。また、プログラマーは、漠然とした伝聞報告を聞くのではなく、バグを再現できることを喜んでいました。

バグを即座に修正するという当社の方針は、顧客サポート担当者とハッカーの関係を変えました。ほとんどのソフトウェア会社では、サポート担当者は低賃金の人間の盾であり、ハッカーは世界の創造主である父なる神の小さなコピーです。バグを報告する手順が何であれ、それは一方通行である可能性が高いです。バグについて聞いたサポート担当者は何らかのフォームに記入し、最終的には (おそらく QA 経由で) プログラマーに渡され、プログラマーはそれをやるべきことのリストに加えます。Viaweb では状況が大きく異なりました。顧客からバグについて聞いてから 1 分以内に、サポート担当者はプログラマーの隣に立っていて、彼が「くそ、その通り、それはバグだ」と言うのを聞くこともありました。ハッカーから「その通りだ」と聞くと、サポート担当者は喜びました。彼らは、猫が殺したばかりのネズミを持ってくるのと同じ期待感を持って、私たちにバグを持ってきました。また、彼らは、名誉がかかっているため、バグの重大性を判断する際にもより慎重になりました。

Yahoo に買収された後、カスタマーサポートの担当者はプログラマーから遠く離れた場所に移動されました。そのとき初めて、彼らは事実上 QA であり、ある程度はマーケティングも担当していることに気づきました。バグを捕まえるだけでなく、ユーザーを混乱させる機能など、より曖昧でバグっぽいものに関する知識の保持者でもありました。[6] 彼らは一種の代理フォーカスグループでもありました。2 つの新機能のうちどちらがユーザーにとってより必要かを尋ねると、彼らは常に正しい答えを返しました。

士気

ソフトウェアをすぐにリリースできることは、大きなモチベーションになります。仕事場へ歩いているときに、ソフトウェアに加えたい変更点を思いついて、その日のうちに実行することがよくありました。これは、より大きな機能にも有効でした。何かを書くのに 2 週間かかる場合でも (いくつかのプロジェクトではそれより長くかかりました)、完成するとすぐにソフトウェアにその効果が現れることがわかっていました。

次のリリースまで 1 年待たなければならなかったら、少なくともしばらくの間は、これらのアイデアのほとんどを棚上げしていたでしょう。しかし、アイデアはさらなるアイデアを生み出すものです。何かを書き始めると、そのアイデアの半分は、書いているときに思いついたものだということに気づいたことはありませんか? ソフトウェアでも同じことが起こります。1 つのアイデアを実装しようとすると、さらに多くのアイデアが生まれます。したがって、アイデアを棚上げすると、実装が遅れるだけでなく、実装によって生まれたはずのアイデアもすべて失われます。実際、アイデアを棚上げすると、新しいアイデアが生まれにくくなる可能性もあります。新しい機能について考え始めると、棚が目に入り、「でも、次のリリースではやりたいことがたくさんある」と思うのです。

大企業が機能の実装の代わりに行うのは、機能の計画です。Viaweb では、この点で時々問題に遭遇しました。投資家やアナリストから、将来に向けて何を計画しているのかと聞かれました。正直に答えると、計画はなかったでしょう。改善したい点について大まかなアイデアはありましたが、その方法がわかっていれば、すでに実行していたでしょう。今後 6 か月で何をするつもりだったでしょうか。最大の成果になりそうなことなら何でも。この答えを言う勇気があったかどうかはわかりませんが、それが真実でした。計画とは、棚上げになっているアイデアの言い換えにすぎません。良いアイデアが思いついたら、それを実装しました。

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

もちろん、このようなソフトウェアの書き方は諸刃の剣です。優秀で信頼できるプログラマーの小さなチームにとっては、平凡なプログラマーの大企業よりもずっとうまくいきます。平凡なプログラマーの大企業では、悪いアイデアはそれを思いついた人ではなく委員会によって取り上げられます。

逆さまのブルックス

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

Viaweb はたった 3 人によって書かれました。[7] 私たちは買収されたかったので、私は常にもっと人を雇わなければならないというプレッシャーを感じていました。また、3 人のプログラマーしかいない会社に買い手が高額を支払うのは難しいだろうとわかっていました。(解決策: 私たちはもっと人を雇いましたが、彼らのために新しいプロジェクトを作成しました。)

より少ないプログラマーでソフトウェアを作成できれば、お金以上の節約になります。フレッド・ブルックスが*『人月の神話』で指摘したように、*プロジェクトに人を追加すると、プロジェクトが遅くなる傾向があります。開発者間のつながりの数は、グループの規模に応じて指数関数的に増加します。グループが大きくなればなるほど、ソフトウェアがどのように連携するかを話し合う会議に費やす時間が増え、予期しない相互作用からバグが増えます。幸いなことに、このプロセスは逆方向にも機能します。グループが小さくなると、ソフトウェア開発は指数関数的に効率化されます。Viaweb のプログラマーが実際に会議を開いたことは一度もありませんでした。昼食に向かう途中で話せる以上のことが一度に起こったことは一度もありませんでした。

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

製品を積極的に開発している限り、他の方法はないと思います。Web ベースのソフトウェアは、書いてチェックインして家に帰るようなものではありません。それは、今まさにサーバー上で実行されているライブなものです。ひどいバグは、1 人のユーザーのプロセスをクラッシュさせるだけでなく、すべてのプロセスをクラッシュさせる可能性があります。コード内のバグによってディスク上のデータが破損した場合は、それを修正する必要があります。などなど。私たちは、サーバーを毎分監視する必要はない (最初の 1 年ほど後) とわかりましたが、最近変更した点には必ず目を光らせておく必要があります。夜遅くにコードをリリースして家に帰ることはありません。

ユーザーの監視

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

ソフトウェアは、ユーザーが期待する通りに動作する必要があります。しかし、ユーザーを観察しない限り、ユーザーが何を考えているのかはまったくわかりません。サーバーベースのソフトウェアは、ユーザーの行動について前例のない情報を提供します。小規模で人工的なフォーカスグループに限定されるわけではありません。すべてのユーザーが行ったすべてのクリックを確認できます。ユーザーのプライバシーを侵害したくないため、何を確認するかを慎重に検討する必要がありますが、最も一般的な統計的サンプリングでも非常に役立ちます。

たとえば、ユーザーがサーバー上にいる場合は、ベンチマークに頼る必要はありません。ベンチマークはシミュレートされたユーザーです。サーバーベースのソフトウェアでは、実際のユーザーを見ることができます。何を最適化するか決めるには、サーバーにログインして、CPU を消費しているものを確認するだけです。また、最適化を停止するタイミングもわかります。最終的に、Viaweb エディターは CPU ではなくメモリにバインドされるようになりましたが、ユーザーのデータのサイズを縮小する方法がなかったので (簡単にできることは何もありません)、そこで停止するほうがよいことがわかりました。

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

ユーザーを観察すると、設計や最適化の指針が得られます。Viaweb には、上級ユーザーが独自のページスタイルを定義できる RTML というスクリプト言語がありました。RTML は、定義済みのページスタイルでは希望どおりに機能しない場合にのみユーザーが使用するため、一種の提案箱になっていることがわかりました。たとえば、当初エディターはページ全体にボタンバーを配置していましたが、多くのユーザーが RTML を使用して左側にボタンを配置した後、定義済みのページスタイルでこれをオプション (実際はデフォルト) にしました。

最後に、ユーザーを観察すると、彼らが困っていることがよくわかります。顧客は常に正しいので、それはあなたが解決すべき何かの兆候です。Viaweb では、ユーザーを獲得する鍵はオンラインテストドライブでした。それは、マーケティング担当者が作成した一連のスライドではありませんでした。テストドライブでは、ユーザーが実際にソフトウェアを使用しました。所要時間は約 5 分で、最後には実際に機能するストアが構築されていました。

テストドライブは、ほぼすべての新規ユーザーを獲得する方法でした。ほとんどの Web ベースのアプリケーションでも同じだと思います。ユーザーがテストドライブを無事に通過できれば、その製品を気に入ってくれるでしょう。ユーザーが混乱したり退屈したりすれば、そうはならないでしょう。したがって、テストドライブを通過できるユーザーを増やすためにできることは何でも、成長率を高めることにつながります。

私は、試乗した人々のクリックトレイルを研究し、あるステップで彼らが混乱してブラウザーの [戻る] ボタンをクリックすることを発見しました。(Web ベースのアプリケーションを書いてみると、[戻る] ボタンが最も興味深い哲学的問題の 1 つになることがわかります。) そこで、その時点でメッセージを追加し、ユーザーにほぼ完了したことを伝え、[戻る] ボタンをクリックしないように注意するようにしました。Web ベースのソフトウェアのもう 1 つの優れた点は、変更に対するフィードバックが即座に得られることです。試乗を完了した人の数は、すぐに 60% から 90% に増加しました。また、新規ユーザーの数は完了した試乗の数の関数であるため、この変更だけで収益が 50% 増加しました。

お金

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

アプリケーションのホスティングは、フリーウェアでは対応できない、企業が果たす役割の領域です。アプリケーションのホスティングには多くのストレスが伴い、実際に費用もかかります。無料でやりたいと思う人は誰もいないでしょう。

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

最後の「利点」は問題になるかもしれません。ある程度の著作権侵害はソフトウェア会社にとって有利です。あるユーザーが本当にどんな値段でもあなたのソフトウェアを購入しないのであれば、そのユーザーが著作権侵害コピーを使用してもあなたは何も失うことはありません。実際、そのユーザーはあなたのソフトウェアを標準にするのに協力するもう 1 人のユーザーであり、高校を卒業したら後でコピーを購入するかもしれないので、あなたは得をすることになります。

企業は、可能な場合には、価格差別と呼ばれることをしたがる。これは、各顧客に支払えるだけの金額を請求することを意味する。[8] ソフトウェアは、限界費用がゼロに近いため、価格差別に特に適している。これが、一部のソフトウェアがインテルのマシンよりもサンで実行する方がコストがかかる理由である。サンを使用する企業は、コスト削減に興味がないため、より高い料金を請求されても問題ない。著作権侵害は、実質的に価格差別の最低レベルである。ソフトウェア企業はこれを理解しており、ある種の著作権侵害には意図的に目をつぶっていると私は思う。[9] サーバーベースのソフトウェアでは、別の解決策を考え出す必要があるだろう。

Web ベースのソフトウェアは、デスクトップソフトウェアと比べて、特に購入しやすいため、よく売れます。人々が何かを購入することを決めてから、それを購入するという 2 つのステップを別々に考えるかもしれません。これは、Viaweb が登場する前、私がこの質問について考えた範囲ではそう考えていました。実際、2 番目のステップは最初のステップに波及する可能性があります。何かが購入しにくい場合、人々はそれを欲しかったかどうか考えを変えます。逆もまた同様です。購入しやすいものの方が売れます。Amazon が存在するため、私はより多くの本を購入します。Web ベースのソフトウェアは、特にオンラインデモを行ったばかりの場合は、世界で最も簡単に購入できるものと言えます。ユーザーは、クレジットカード番号を入力する以上のことをする必要はありません (それ以上のことをさせると、危険です)。

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

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

顧客

顧客は誰になるのでしょうか? Viaweb では当初、個人や小規模な企業が顧客でしたが、これは Web ベースのアプリケーションでも当然のことだと思います。これらのユーザーは、新しいものを試す用意ができています。その理由の一部は、より柔軟であること、そして一部は新しいテクノロジの低コスト化を望んでいることです。

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

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

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

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

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

お金持ちの顧客は、たとえ安いソリューションの方が優れている場合でも、常に高価なソリューションを購入する傾向があります。なぜなら、高価なソリューションを提供する人は、それを販売するためにより多くの費用をかけることができるからです。Viaweb では、常にこの問題に直面していました。Web コンサルティング会社に説得されて、高級な商店をいくつか失いました。その会社は、50 万ドルを支払って、自社のサーバーでカスタムメイドのオンラインストアを作った方が得だと説得しました。クリスマスショッピングシーズンが近づき、サーバーの負荷が急増したときに、多くの人が気づいたように、彼らは概して得をしませんでした。Viaweb は、これらの商店のほとんどが持っているものよりはるかに洗練されていましたが、私たちにはそれを彼らに伝える余裕がありませんでした。月額 300 ドルでは、きちんとした服装で威厳のある声を出す人々のチームを顧客にプレゼンテーションに派遣する余裕はありませんでした。

大企業が余分に支払うものの大部分は、高価な商品を販売するためのコストです。(国防総省がトイレの便座に 1,000 ドルを支払うのは、1,000 ドルの便座を販売するには多額の費用がかかることが一因です。) そして、これが、おそらく悪いアイデアであるにもかかわらず、イントラネットソフトウェアが今後も繁栄し続ける理由の 1 つです。単にコストが高いからです。この難問に対してできることは何もありません。したがって、最善の計画は、まず小規模な顧客をターゲットにすることです。残りは時間が経てば手に入ります。

サーバーの息子

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

当初、デスクトップコンピュータはそれほど脅威には見えませんでした。最初のユーザーは全員ハッカー (当時は趣味人と呼ばれていました) でした。彼らはマイクロコンピュータが安価だったため、それを好みました。初めて、自分専用のコンピュータを持つことができました。「パーソナルコンピュータ」というフレーズは今では言語の一部になっていますが、最初に使用されたときは、今日の「パーソナルサテライト」というフレーズのように、意図的に大胆な響きがありました。

なぜデスクトップコンピューターが主流になったのでしょうか。それは、デスクトップコンピューターのソフトウェアが優れていたからだと思います。また、マイクロコンピューターのソフトウェアが優れていた理由は、小規模な企業でも作成できたからだと思います。

スタートアップが初期段階でいかに脆弱で不確かなものであるかに気付いている人は多くないと思います。多くのスタートアップは、ほとんど偶然に始まります。昼間は仕事に就いているか学生である 2 人の男が、将来有望であれば会社になるかもしれない何かのプロトタイプを書くのです。この幼虫の段階では、重大な障害があるとスタートアップは完全に止まってしまいます。メインフレームソフトウェアを書くには、最初に多大なコミットメントが必要でした。開発マシンは高価で、顧客は大企業であるため、彼らにそれを販売するには見栄えの良い営業部隊が必要でした。メインフレームソフトウェアを書くスタートアップを始めることは、夜に Apple II で何かをハッキングするよりもはるかに真剣な取り組みです。そのため、メインフレームアプリケーションを書くスタートアップはそれほど多くありませんでした。

デスクトップコンピュータの登場は、多くの新しいソフトウェアの誕生につながりました。デスクトップコンピュータ用のアプリケーションを作成することは、新興企業にとって達成可能な目標に思えたからです。開発コストは安く、顧客はコンピュータストアやメールオーダーを通じて入手できる個人でした。

デスクトップコンピュータを主流に押し上げたアプリケーションは、最初のスプレッドシートであるVisiCalcでした。これは屋根裏部屋で作業していた 2 人の男性によって作成されましたが、メインフレームソフトウェアではできなかったことを実現しました。[11] VisiCalc は当時としては先進的だったため、それを実行するためだけに Apple II を購入する人もいました。そしてこれがトレンドの始まりでした。デスクトップコンピュータが勝利したのは、スタートアップ企業がそのソフトウェアを作成したからです。

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

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

デスクトップソフトウェアの作成が以前よりずっと楽しくなくなってきているので、スタートアップ企業が Web ベースのソフトウェアを作成する理由はますます増えています。デスクトップソフトウェアを作成する場合は、Microsoft の条件に従って、同社の API を呼び出し、バグの多い OS を回避して作業します。そして、うまく成功するソフトウェアを作成できたとしても、Microsoft のために市場調査を行っていただけだったことに気づくかもしれません。

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

デスクトップソフトウェアを作成するためにスタートアップを立ち上げることはなかったと思います。デスクトップソフトウェアは Windows 上で実行する必要があるため、Windows 用のソフトウェアを作成する前に Windows を使用する必要があるからです。Web により、Windows を迂回して、Unix 上で実行されるソフトウェアをブラウザーを通じてユーザーに直接提供できるようになりました。これは、25 年前の PC の登場とよく似た、解放的な展望です。

マイクロソフト

デスクトップコンピューターが登場した当時、IBM は誰もが恐れる巨大企業でした。今では想像もつきませんが、そのときの気持ちはよく覚えています。現在、恐ろしい巨大企業は Microsoft ですが、Microsoft は IBM ほど脅威に気づいていないと思います。結局のところ、Microsoft は意図的に IBM の盲点に自社のビジネスを構築したのです。

先ほど、母はデスクトップコンピュータをあまり必要としていないと述べました。ほとんどのユーザーもおそらくそうではないでしょう。これは Microsoft にとって問題であり、Microsoft もそれを認識しています。アプリケーションがリモートサーバーで実行される場合、Windows は不要になります。Microsoft はどうするでしょうか。デスクトップの制御を利用して、この新世代のソフトウェアを阻止または制限できるでしょうか。

私の推測では、Microsoft は、オペレーティングシステムが同社が管理するサーバーと連携して動作する、サーバー/デスクトップハイブリッドのようなものを開発するでしょう。少なくとも、ファイルは、それを希望するユーザー向けに一元的に利用可能になります。Microsoft が、サーバー上で計算を実行し、クライアントにはブラウザーのみを使用するという極端な方法に踏み込むことは、避けられるのであれば考えられません。クライアントにブラウザーのみが必要な場合は、クライアントに Microsoft は必要ありません。また、Microsoft がクライアントを管理していない場合は、ユーザーをサーバーベースのアプリケーションに誘導することはできません。

マイクロソフトは、魔神を瓶の中に閉じ込めておくのに苦労するだろうと思う。クライアントの種類が多すぎて、すべてを制御できないからだ。そして、マイクロソフトのアプリケーションが一部のクライアントでしか動作しない場合、競合他社はどのクライアントでも動作するアプリケーションを提供することで、マイクロソフトに勝つことができるだろう。[14]

Web ベースのアプリケーションの世界では、Microsoft が居場所を確保できるわけではありません。Microsoft は居場所を確保することに成功するかもしれませんが、デスクトップアプリケーションの世界でそうであったように、この新しい世界を独占できるとは思えません。

競合他社に足を引っ張られるというよりは、彼ら自身がつまずくという方が正しい。Web ベースのソフトウェアの台頭により、彼らは技術的な問題だけでなく、自らの希望的観測にも直面することになる。彼らがすべきことは、既存のビジネスを食いつぶすことだが、彼らがそれに直面するとは思えない。これまで彼らを導いてきた同じひたむきな姿勢が、今度は彼らに不利に働くことになるだろう。IBM もまったく同じ状況にあり、それを克服できなかった。IBM がマイクロコンピュータ事業に参入したのは、彼らの金のなる木であるメインフレームコンピューティングを脅かすことに二の足を踏んだため、遅まきながら気乗りしないものだった。Microsoft も同様に、デスクトップを救いたいという思いで足かせをはめられるだろう。金のなる木は、背中にのしかかる重荷になり得るのだ。

サーバーベースのアプリケーションを支配する者がいないと言っているのではありません。おそらく、いずれはそうなるでしょう。しかし、マイクロコンピュータの初期の頃のように、楽しい混沌の時代が長く続くと思います。それは新興企業にとって良い時代でした。多くの中小企業が繁栄し、クールなものを作ることでそれを実現しました。

スタートアップ企業だがそれ以上に

典型的なスタートアップは、人員も資金も少なく、スピードも速く、非公式です。少数の人員が懸命に働き、テクノロジーが彼らの決定の影響を拡大します。成功すれば、大きな勝利となります。

Web ベースのアプリケーションを作成するスタートアップでは、スタートアップに関連するすべてのことが極限まで追求されます。より少ない人数とより少ない資金で製品を作成し、リリースできます。より迅速に作業を進め、より形式ばらない方法でもかまいません。文字通り、アパートのリビングルームに 3 人の男が座り、ISP に設置されたサーバーで製品を発表できます。私たちはそれを実現しました。

時が経つにつれ、チームはより小規模になり、より迅速になり、より形式ばらないものになっていった。1960 年代、ソフトウェア開発といえば、角縁の眼鏡をかけ、細い黒のネクタイを締めた男たちが部屋いっぱいに集まり、IBM のコーディングフォームで 1 日に 10 行のコードを熱心に書いていた。1980 年代には、8 人から 10 人のチームがジーンズをはいてオフィスに行き、vt100 に入力していた。今では、リビングルームでラップトップ PC を使っている男が数人いる (そして、ジーンズは形式ばらないものの決定版ではないことが判明した)。

スタートアップはストレスがたまるものですが、残念ながら、Web ベースのアプリケーションではこれが極端にまで達しています。多くのソフトウェア会社、特に最初の頃は、開発者が机の下で寝るなどといった時期がありました。Web ベースのソフトウェアで憂慮すべきことは、これがデフォルトになることを防ぐものが何もないということです。机の下で寝るという話はたいてい、最後には出荷して、全員が家に帰って 1 週間寝るというところで終わります。Web ベースのソフトウェアは出荷されません。1 日 16 時間働きたいだけ働けます。そして、自分も競合他社もできるから、そうせざるを得ない傾向があります。できるから、そうしなければならないのです。これは、パーキンソンの法則が逆になっているようなものです。

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

Viaweb では、最初の 6 か月間はソフトウェアの作成だけに費やしました。初期のスタートアップ企業ではよくあることですが、長時間労働でした。デスクトップソフトウェア会社であれば、この段階で一生懸命働いていたはずですが、次の段階である、ユーザーを自社のサーバーに取り込む段階に比べれば、休暇のような気分でした。Viaweb を Yahoo に売却したことによる 2 番目に大きなメリット (お金に次いで) は、すべての責任を大企業の肩に負わせることができたことです。

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

ちょうどいい

Web ベースのアプリケーションの作成を思いとどまらせる要因の 1 つは、Web ページの UI としての不十分さです。これは確かに問題です。HTML と HTTP に追加したかった機能がいくつかあります。しかし、重要なのは、Web ページが十分に優れているということです。

ここには、最初のマイクロコンピュータとの類似点があります。これらのマシンのプロセッサは、実際にはコンピュータの CPU として意図されたものではありません。信号機などに使用するために設計されました。しかし、 Altairを設計した Ed Roberts のような人たちは、それが十分に優れていることに気づきました。これらのチップの 1 つとメモリ (最初の Altair では 256 バイト)、およびフロントパネルのスイッチを組み合わせれば、動作するコンピュータが完成しました。自分専用のコンピュータを所有できることは非常に魅力的で、制限があったとしても、それを購入したい人はたくさんいました。

Web ページはアプリケーションの UI として設計されたわけではありませんが、十分に優れています。また、多くのユーザーにとって、どのブラウザーからでも使用できるソフトウェアは、それ自体が UI の不便さを補って余りあるほどの利点です。HTML を使用して最も見栄えの良いスプレッドシートを作成することはできないかもしれませんが、特別なクライアントソフトウェアを使用せずに複数のユーザーが異なる場所から同時に使用できるスプレッドシートを作成したり、ライブデータフィードを組み込んだり、特定の条件がトリガーされたときにページングしたりすることはできます。さらに重要なことは、まだ名前さえ付いていない新しい種類のアプリケーションを作成できることです。結局のところ、VisiCalc はメインフレームアプリケーションのマイクロコンピューターバージョンではなく、新しい種類のアプリケーションでした。

もちろん、サーバーベースのアプリケーションは Web ベースである必要はありません。他の種類のクライアントを用意することもできます。しかし、それはよくない考えだと私は確信しています。誰もがクライアントをインストールすると想定できれば非常に便利です。非常に便利なので、誰もがインストールするだろうと簡単に納得できます。しかし、インストールされなければ、あなたは困ったことになります。Web ベースのソフトウェアはクライアントについて何も想定しないため、Web が機能する場所であればどこでも動作します。これはすでに大きな利点ですが、新しい Web デバイスが普及するにつれて、その利点は拡大します。ソフトウェアが問題なく機能するため、ユーザーはあなたを好みます。また、新しいクライアントごとに調整する必要がないため、あなたの生活は楽になります。[16]

私は Web の進化を誰よりも注意深く見守ってきたつもりですが、クライアントに何が起こるかは予測できません。おそらく収束は来るでしょうが、それはどこで起こるのでしょうか? 勝者を選ぶことはできません。1 つ予測できることは、AOL と Microsoft の対立です。Microsoft の .NET がどのようなものになるにせよ、おそらくデスクトップをサーバーに接続することになるでしょう。AOL が反撃しない限り、彼らは押しのけられるか、Microsoft のクライアントとサーバーソフトウェア間のパイプにされるでしょう。Microsoft と AOL がクライアント戦争に突入した場合、両方で確実に機能するのは Web の閲覧だけであり、つまり Web ベースのアプリケーションがどこでも機能する唯一の種類となるでしょう。

結局どうなるのか? 私にはわかりません。Web ベースのアプリケーションに賭けるなら、知る必要はありません。ブラウジングに支障をきたさずにそれを破ることはできません。Web はソフトウェアを提供する唯一の方法ではないかもしれませんが、現在機能しており、今後も長く機能し続ける方法です。Web ベースのアプリケーションは開発コストが安く、最も小さなスタートアップでも簡単に提供できます。作業量が多く、特にストレスの多い作業ですが、スタートアップにとっては勝算が高くなります。

なぜだめですか？

EB ホワイトは、農家の友人から、多くの電気柵には電流が流れていないと聞いて面白がっていた。牛はどうやら柵に近づかないように学習するらしく、その後は電流は必要ない。「牛たちよ、立ち上がれ！」と彼は書いた。「独裁者がいびきをかいている間に、自由になろう！」

いつかスタートアップを始めようと考えているハッカーなら、おそらくそれを実行できない理由は 2 つあるでしょう。1 つはビジネスについて何も知らないこと。もう 1 つは競争を恐れていること。どちらの柵にも流れはありません。

ビジネスについて知っておくべきことは 2 つだけです。ユーザーが気に入るものを作ることと、支出以上の利益を上げることです。この 2 つを正しく行えば、ほとんどのスタートアップ企業よりも優位に立てます。残りは、その過程で理解できます。

最初は支出額よりも収入額が多くならないかもしれませんが、その差が急速に縮まれば大丈夫です。資金不足で始めたとしても、少なくとも倹約の習慣が身に付きます。支出額が少ないほど、支出額よりも収入額が多くなるのは簡単です。幸い、Web ベースのアプリケーションは非常に安価に開始できます。私たちは 1 万ドル以下で開始しましたが、現在ではさらに安くなっています。サーバーに数千ドル、SSL を取得するためにさらに数千ドルを費やさなければなりませんでした (当時 SSL ソフトウェアを販売していた唯一の会社は Netscape でした)。今では、帯域幅のみに支払った金額よりも安く、SSL を含むはるかに強力なサーバーをレンタルできます。今では、高級なオフィスチェア 1 台分の費用よりも安く Web ベースのアプリケーションを開始できます。

ユーザーが気に入るものを作るための一般的なヒントをいくつか紹介します。まずは、自分自身が使いたいと思うような、すっきりとしたシンプルなものを作りましょう。バージョン 1.0 をすぐにリリースし、その後もユーザーの声に耳を傾けながらソフトウェアを改良し続けます。顧客は常に正しいのですが、顧客によって正しい点は異なります。最も洗練されていないユーザーは、何を簡素化して明確にする必要があるかを示し、最も洗練されたユーザーは、どのような機能を追加する必要があるかを示します。ソフトウェアは簡単になるのが最善ですが、そのためには、ユーザーの選択肢を制限するのではなく、デフォルトを正しく設定する必要があります。競合他社のソフトウェアが劣っていても、油断しないでください。ソフトウェアを比較する基準は、現在の競合他社がたまたま持っているものではなく、ソフトウェアがどのようなものになる可能性があるかです。常に、自分でソフトウェアを使用してください。Viaweb はオンラインストアビルダーになるはずでしたが、独自のサイトの作成にも使用しました。マーケティング担当者、デザイナー、製品マネージャーの肩書きだけで彼らの言うことに耳を傾けないでください。良いアイデアがあればそれを使用しますが、決定権はあなたにあります。ソフトウェアは、ソフトウェアについて少ししか知らないデザイナーではなく、デザインを理解しているハッカーによって設計されなければなりません。ソフトウェアを設計することも実装することもできないのであれば、スタートアップを始めないでください。

さて、競争についてお話しましょう。あなたが恐れているのは、おそらくあなたのようなハッカーのグループではなく、オフィスや事業計画、営業マンなどを持つ実際の企業ですよね? まあ、あなたが彼らを恐れている以上に、彼らはあなたを恐れていますし、彼らの言う通りです。ハッカーが数人いれば、オフィスを借りたり営業マンを雇ったりする方法を考え出すのは、どんな規模の企業でもソフトウェアを書くよりもずっと簡単です。私は両方の立場にいたことがあるので、よくわかっています。Viaweb が Yahoo に買収されたとき、私は突然大企業で働いていることに気付きました。それはまるで腰まで水に浸かっているような感じでした。

Yahoo をけなすつもりはありません。優秀なハッカーが何人かいて、経営陣は本当にすごい人たちでした。大企業としては並外れた人たちでした。しかし、それでも小規模なスタートアップ企業の 10 分の 1 程度の生産性しかありませんでした。大企業でこれより優れた成果を上げることはできません。Microsoft の恐ろしいところは、これほど大きな企業がソフトウェアを開発できるということです。彼らは歩くことのできる山のようなものです。

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

信じられないかもしれませんが、マイクロソフトはあなたを恐れています。現状に満足している中間管理職はそうではないかもしれませんが、ビルは恐れています。なぜなら、1975 年にソフトウェアを提供する新しい方法が最後に登場したとき、彼もかつてあなたと同じだったからです。

注記

[1] 収益の大半はサービスにあると認識した軽量クライアントを構築する企業は、通常、ハードウェアとオンラインサービスとを組み合わせようとしてきた。このアプローチはうまくいかなかった。その理由の 1 つは、消費者向け電子機器の製造とオンラインサービスの運営には 2 種類の企業が必要であること、もう 1 つは、ユーザーがこのアイデアを嫌うためである。カミソリを無料で配布して刃で儲ける方法はジレットには有効かもしれないが、カミソリは Web 端末よりはるかに小さなコミットメントである。携帯電話端末メーカーは、サービス収益を獲得しようとせずにハードウェアを販売するだけで満足している。おそらく、インターネットクライアントもこのモデルになるはずだ。誰かが、どの ISP 経由でも接続できる Web ブラウザーを備えた見栄えの良い小さなボックスを販売しただけなら、国中のハイテク嫌いの人全員がそれを購入するだろう。

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

[3] 1995 年に Viaweb を立ち上げたとき、Java アプレットは、サーバーベースのアプリケーションを開発するために誰もが使用するテクノロジになるはずでした。アプレットは私たちにとっては時代遅れの考えに思えました。クライアントで実行するためにプログラムをダウンロードする? 最初からサーバーでプログラムを実行したほうが簡単です。私たちはアプレットにほとんど時間を費やしませんでしたが、他の無数のスタートアップがこの泥沼に誘い込まれたに違いありません。生きて逃げ切れた企業はほとんどいなかったでしょう。そうでなければ、Microsoft は最新バージョンの Explorer で Java を廃止しても逃げ切れなかったでしょう。

[4] この点は Trevor Blackwell によるもので、彼は「ソフトウェアの作成コストは、そのサイズに比例して増加する以上のものになります。これは主に古いバグを修正するためであり、すべてのバグが迅速に発見されればコストはより比例する可能性があります」と付け加えています。

[5] 最も見つけにくいバグは、あるバグが別のバグを補う複合バグの一種かもしれません。1つのバグを修正すると、もう1つのバグが目に見えるようになります。しかし、その修正が最後に変更した部分であるため、修正に問題があるように見えます。

[6] Viaweb 社内で、かつて私たちのソフトウェアの最悪の点を述べるコンテストがありました。カスタマーサポート担当者 2 名が、今でも思い出すとぞっとする作品で同点 1 位になりました。私たちはすぐに両方の問題を修正しました。

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

[8] 価格差別は非常に蔓延しており（小売業者が、自分たちの購買力によって価格が下がると主張するのを何度聞いたことがありますか？）、米国では1936年のロビンソン・パットマン法によって価格差別が禁止されていることを知って驚きました。この法律は厳格に施行されているようには見えません。

[9] ナオミ・クラインは著書『ノー・ロゴ』の中で、 「都会の若者」に好まれる衣料品ブランドは、彼らのターゲット市場では万引き犯がファッションリーダーでもあるため、万引き防止にあまり力を入れていないと述べている。

[10] 企業は、何をアウトソーシングすべきか、何をアウトソーシングすべきでないか、とよく考えます。1つの答えは、競争圧力に直接さらされていない仕事はすべてアウトソーシングすることです。なぜなら、アウトソーシングすると、競争圧力にさらされることになるからです。

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

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

[13] Macがそれほど優れていたのなら、なぜ負けたのか？これもコストの問題だ。マイクロソフトはソフトウェア事業に集中し、Appleのハードウェアに安価な部品サプライヤーを大量に投入した。また、重要な時期にスーツを着た人たちが支配権を握ったことも、状況を悪化させた。

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

とりわけ、適切なオープンソースブラウザは、HTTP と HTML の継続的な進化につながります (たとえば Perl のように)。Web ベースのアプリケーションでは、リンクの選択とリンクの追跡を区別できるようになるため、非常に役立ちます。これを行うには、HTTP を少し拡張して、リクエストで複数の URL を許可するだけで済みます。カスケードメニューも便利です。

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

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

「さらに言えば、サーバーベースのソフトウェアはプログラマーにとって非常に過酷であるため、大企業から経済が根本的に離れる原因となるでしょう。プログラマーは、自分の会社でなければ提供しようとしないような熱意と献身を要求されます。ソフトウェア会社は、それほど過酷ではない環境で作業する熟練した人材を雇うことができますし、困難に耐える未熟練の人材を雇うこともできますが、懸命に働く高度なスキルを持つ人材を雇うことはできません。資本が不要になったため、大企業が提供できるものはほとんどありません。」

[16] このエッセイのオリジナル版では、Javascriptを避けるようにアドバイスしました。2001年には良い案でしたが、今ではJavascriptでも大丈夫です。

この論文の草稿を読んでくださった Sarah Harlin、Trevor Blackwell、Robert Morris、Eric Raymond、Ken Anderson、Dan Giffin に感謝します。また、VisiCalc に関する情報を提供してくださった Dan Bricklin と Bob Frankston にも感謝します。さらに、BBN での講演に招待してくださった Ken Anderson にも感謝します。

このエッセイと他の 14 件のエッセイはHackers & Paintersに掲載されています。