別の道のり

2001年9月

(このアーティクルは、次世代のソフトウェアの多くがサーバーベースになる理由、それがプログラマーにとってどのような意味を持つか、そしてこの新しいタイプのソフトウェアがスタートアップにとって大きな機会であることを説明しています。これはBBN Labsでの講演に基づいています。)

1995年の夏、私の友人ロバート・モリスと私はスタートアップを始めることにしました。当時、ネットスケープのIPO宣伝キャンペーンが全力で行われており、オンラインコマースについて報道されていました。その当時、Web上に実際にあったオンラインストアは手作りのものが30店舗ほどでした。オンラインストアが増えていくには、それを作るためのソフトウェアが必要になるので、そのソフトウェアを書くことにしました。

最初の1週間ほどは、通常のデスクトップアプリケーションを作る予定でした。ある日、Webサーバー上で動作し、ブラウザをインターフェースとして使うというアイデアが浮かびました。Webで動作するように書き換えてみると、これが正解だと分かりました。サーバー上でソフトウェアを動作させれば、ユーザーにとってもウチにとってもずっと簡単になります。

これは良い計画だと証明されました。現在、Yahoo Storeとして知られるこのソフトウェアは、約14,000ユーザーを持つ最も人気のあるオンラインストア構築ツールになっています。

Viawebを立ち上げた当時、ソフトウェアがサーバー上で動作するということがよく理解されていませんでした。Hotmailが1年後にローンチされてから、ようやく人々がこのアプローチを理解し始めました。今では誰もがこれが有効なアプローチだと知っています。これを表す言葉もできました。Application Service Provider、つまりASPです。

私は、次世代のソフトウェアの多くがこのモデルで書かれるようになると思います。最も損をするマイクロソフトでさえ、デスクトップから一部のものを移行するのは避けられないと見ているようです。ソフトウェアがデスクトップからサーバーに移行すれば、開発者にとっては全く違う世界になるでしょう。この記事では、この新しい世界の第一人者として目にした驚くべきことを説明しています。ソフトウェアがサーバーに移行していけば、ここで述べていることが未来の姿となるでしょう。

次なるもの?

デスクトップソフトウェアの時代を振り返ると、人々が我慢していた不便さに驚くだろうと思います。まるで、初期の自動車所有者が我慢していたことを今は驚いて見ているようです。最初の20年から30年は、自動車の専門家でなければ自動車を所有できませんでした。しかし、自動車はそれほど大きな利点があったので、自動車の専門家でない人々も所有したいと思うようになりました。

コンピューターはまさにこの段階にあります。デスクトップコンピューターを所有すると、内部で何が起きているかについて、知りたくないほど多くのことを学ばなければなりません。しかし、アメリカ世帯の半分以上がコンピューターを所有しています。私の母は、メールと家計簿管理のためにコンピューターを使っています。ある年、Apple社から新しいオペレーティングシステムのバージョンの割引を提案する手紙が届いて、彼女は驚いていました。メールと家計簿管理をしたいだけの65歳の女性が、新しいオペレーティングシステムをインストールしなければならないのは問題があります。一般ユーザーは「オペレーティングシステム」や「デバイスドライバー」、「パッチ」といった言葉を知る必要はありません。

ユーザーがシステム管理者にならずに済むソフトウェアを提供する別の方法があります。Webベースのアプリケーションは、Webサーバー上で動作し、Webページをユーザーインターフェースとして使うプログラムです。一般ユーザーにとって、この新しいタイプのソフトウェアはデスクトップソフトウェアよりも使いやすく、安価で、モバイルで、信頼性が高く、しばしば強力になるでしょう。

Webベースのソフトウェアを使う場合、ほとんどのユーザーは使うアプリケーションのことしか考える必要がありません。汚れた変化するものはすべてどこかのサーバーにあり、そういったことに長けた人々によって管理されます。したがって、通常はコンピューター自体を必要としません。キーボード、ディスプレイ、Webブラウザがあれば十分です。無線インターネットアクセスがあるかもしれません。携帯電話かもしれません。いずれにしろ、それはコンシューマー向け電子機器で、約200ドルほどの価格で、ケースの外観で主に選ばれるでしょう。ハードウェアよりもインターネットサービスの方が高くつくでしょう。今の電話と同じように。[1]

クリックがサーバーと往復するのに約0.1秒かかるので、Photoshopのようなインタラクティブ性の高いソフトウェアのユーザーはデスクトップでの計算を望むでしょう。しかし、ほとんどの人がコンピューターを使う用途を見ると、0.1秒の遅延は問題にならないでしょう。私の母にはデスクトップコンピューターは本当に必要ありません。そして、彼女のような人は大勢いるのです。

ユーザーにとっての勝利

私の家の近くには、「不便より死を」と書かれたバンパーステッカーのついた車があります。ほとんどの人は、ほとんどの時、最も手間のかからない選択肢を取ります。Webベースのソフトウェアが勝つのは、それが便利だからです。そして、ユーザーにとっても開発者にとっても、それのようです。

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

ここでくさびを打ち込んだのがWebベースのメールでした。何百万人もの人々が、場所に関係なくメールにアクセスできるべきだと理解するようになりました。メールが見られるなら、カレンダーも見られるはずです。同僚と文書について議論できるなら、編集もできるはずです。なぜデータの一部がどこかの机の上にあるコンピューターに閉じ込められているのでしょうか。

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

クライアントはデータを保存してはいけません。電話機のようになるべきです。実際、クライアントは電話機になるかもしれませんし、その逆もあるでしょう。クライアントが小さくなるにつれ、クライアントにデータを保存しないことにもう一つの理由があります。持ち歩くものは紛失や盗難の対象になるからです。PDAsをタクシーに置き忘れるのは、データが蒸発するのではなく、他人の手に渡るディスククラッシュのようなものです。

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

インストールが不要なため、Webベースのソフトウェアを「購入」する前に試すのが簡単で一般的になるでしょう。Webベースのアプリケーションは、提供サイトにアクセスするだけで無料で試用できるはずです。Viawebでは、サイト全体が試用への誘導となっていました。

デモを試した後、サービスに登録するには簡単な入力フォームに記入するだけで十分です(できるだけ簡単に)。それ以上の作業は必要ありません。Webベースのソフトウェアでは、追加料金を払ったり作業をしたりすることなく、ユーザーが気づかないうちに新しいバージョンが提供されるはずです。

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

Webベースのアプリケーションでは、すべてのユーザーが同じバージョンを使い、バグは発見され次第修正されます。したがって、デスクトップソフトウェアに比べてバグが格段に少なくなるはずです。Viawebでは、同時に存在していたバグは10個以下だったと思います。これはデスクトップソフトウェアと比べて桁違いに少ないです。

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

Webベースのアプリケーションを使うと、データの安全性が高まります。ディスククラッシュは過去のものにはならないかもしれませんが、ユーザーはそれを聞かなくなるでしょう。それらはサーバーファームの中で起こるでしょう。Webベースのアプリケーションを提供する企業は、バックアップを確実に行うはずです。それは、本当のシステム管理者がそのようなことを心配するからだけでなく、ユーザーのデータを失えば大変なことになるからです。ユーザー自身のディスククラッシュでデータを失っても、自分のせいだからそれほど怒ることはできません。しかし、企業がユーザーのデータを失えば、ユーザーはずっと怒るでしょう。

最後に、Webベースのソフトウェアはウイルスに対してより脆弱性が低いはずです。クライアントがブラウザ以外何も実行しないのであれば、ウイルスに感染する可能性が低く、ローカルのデータを破壊される心配もありません。そして、サーバー自体を攻撃するプログラムは、非常に堅牢に守られているはずです。[2]

ユーザーにとって、Webベースのソフトウェアはストレスが少なくなるでしょう。平均的なWindowsユーザーの中には、そのような特徴を持つソフトウェアに対する大きな(ほとんど開発されていない)需要があると思います。それが解き放たれれば、強力な力になるかもしれません。

コードの街

開発者にとって、Webベースのソフトウェアとデスクトップソフトウェアの最も目立った違いは、Webベースのアプリケーションが単一のコードではなく、さまざまなタイプのプログラムの集合体であることです。したがって、Webベースのソフトウェアを設計するのは、建物ではなく街を設計するようなものです。建物だけでなく、道路、標識、ユーティリティ、警察・消防、成長と様々な災害への対応計画も必要です。

Viawebでは、ユーザーが直接話しかけるかなり大きなアプリケーション、それらのアプリケーションが使うプログラム、常時バックグラウンドで動いて問題を探知するプログラム、壊れたものを再起動しようとするプログラム、統計を集計したりインデックスを構築するためのプログラム、リソースをガベージコレクションしたり、データを移動・復元するために明示的に実行するプログラム、ユーザーになりすまして動作させるプログラム(パフォーマンスを測ったりバグを発見するため)、ネットワークの問題を診断するプログラム、バックアップを行うプログラム、外部サービスとのインターフェース、オープンソースソフトウェアへの修正(バグ修正を含む)、そして多くの設定ファイルやパラメータが含まれていました。Trevor Blackwellは、ストアをシャットダウンすることなく新しいサーバーに移行するすばらしいプログラムを書きました。プログラムはユーザーにページを送ったり、ファックスやメールを送信したり、クレジットカード処理業者と取引したり、ソケット、パイプ、HTTPリクエスト、SSH、UDPパケット、共有メモリ、ファイルを通じて互いに通信したりしていました。Viawebの一部は、Unixのセキュリティの鍵の1つである不要なユーティリティを実行しないことで構成されていました。

ソフトウェアだけでなく、サーバー構成にも多くの時間を費やしました。コストを節約し、欲しい構成を得るために、自分でサーバーを組み立てました。上流のISPが全バックボーンに十分な速度の接続を持っているかどうかも考慮しました。RAIDサプライヤーとはデートしました。

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

Webベースのアプリケーションのソフトウェアは、単一のバイナリではなく、さまざまなプログラムの集合体になるため、さまざまな言語で書くことができます。デスクトップソフトウェアを書く場合、実質的に、基盤となるオペレーティングシステムと同じ言語(C、C++)で書かざるを得ません。そのため、これらの言語(特に、マネージャーやVCなどの非技術者にとって)が「本格的な」ソフトウェア開発の言語とみなされるようになりました。しかし、これはデスクトップソフトウェアの配信方法に起因するものにすぎません。サーバーベースのソフトウェアであれば、使用する言語は自由に選べます。[3] 今日、多くのトップハッカーが、C/C++から遠く離れたPerl、Python、Lispなどの言語を使っています。

サーバーベースのソフトウェアでは、ハードウェアまで完全に制御できるため、使用する言語を誰も指定できません。タスクに応じて最適な言語を使うことができます。競合他社がいる場合、「できる」ではなく「しなければならない」(後述)ということになります。そうしないと、競合他社に先を越されてしまいます。

多くの競合他社がC/C++を使っていたため、(その他の理由もありますが)、CGIスクリプトの無状態性を回避する方法がなく、ソフトウェアが明らかに劣っていました。何かを変更する場合、すべての変更は1ページ内で行い、ページ下部の「更新」ボタンを押す必要がありました。別の場所で書いたように、私たちは研究用言語とみなされることの多いLispを使うことで、Viaweb エディターをデスクトップソフトウェアのように動作させることができました。

リリース

この新しい世界での最も重要な変化の1つが、リリースの方法です。デスクトップソフトウェアビジネスでは、リリースは大きな出来事で、会社全体が汗を流して単一の巨大なコードを押し出します。明らかな比較が思い浮かびます。

サーバーベースのソフトウェアでは、自分で書いているプログラムのように、ほぼ随時変更を加えることができます。大規模なリリースの代わりに、段階的な変更の連続としてソフトウェアをリリースします。一般的なデスクトップソフトウェア企業は年に1、2回のリリースを行うかもしれません。一方、Viaweb では1日に3〜5回のリリースを行うこともありました。

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

年に1回しか新バージョンをリリースしない場合、バグは一括して処理されがちです。リリース日の少し前に、半分のコードが書き換えられた新バージョンを組み立てると、無数のバグが発生します。その後、QAチームが入ってきてそれらを数え始め、プログラマーがリストを片付けていきます。しかし、リストの最後まで到達することはほとんどありません。どこまでバグがあるかもわかりません。瓦礫を池から引き上げるようなものです。ソフトウェアの内部がどうなっているかを完全に把握することはできません。せいぜい統計的な正確性しか得られません。

サーバーベースのソフトウェアの場合、ほとんどの変更は小さく段階的です。これ自体がバグを引き起こしにくくなります。また、リリースする直前に最も慎重にテストすべきものが、最後に変更したものだけであることを意味します。コードをより確実に把握できるようになります。一般的に、ソフトウェアの内部がどうなっているかがわかります。もちろんソースコードを暗記しているわけではありませんが、探偵が謎を解くように読むのではなく、パイロットがダッシュボードを見るように読むことができます。

デスクトップソフトウェアは、バグに対する諦めの念を生み出します。バグだらけのものをリリースせざるを得ないことを知っており、それを補うメカニズム(パッチリリースなど)も用意しています。そのため、さらにいくつかのバグがあっても気にしなくなります。壊れた機能全体をリリースするようになります。Appleは今年初めにこれを行いました。リリース日が4回も延期された新OSを、一部の機能(CD/DVDサポートなど)が完成していないにもかかわらずリリースしました。ユーザーにはそれらの未完成の部分を後からインストールしてもらうことにしたのです。

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

業界のベテランは、「動作するまでソフトウェアをリリースする必要がない」というのは素晴らしい考えだが、特定の日までに新バージョンを提供すると約束した場合はどうするのかと疑問に思うかもしれません。Webベースのソフトウェアの場合、バージョンという概念自体が適切ではありません。ソフトウェアは徐々に、継続的に変化していくのです。変更の大きさに差はあっても、バージョン番号という考え方はWebベースのソフトウェには自然に当てはまりません。

Viaweb の場合、常に新バージョンをアナウンスしていたように思えるかもしれません。これは完全にPR目的で行っていたことです。業界紙は、バージョン番号に着目しているため、メジャーリリース(バージョン番号の整数部が変わる)には大きな報道を行い、マイナーリリース(小数部が変わる)には1パラグラフ程度しか割いてくれないことを学んでいたのです。

私たちの競合他社は、デスクトップソフトウェアを提供しており、実際にバージョン番号を持っていました。そしてこれらのリリースについては、単にバージョン番号があるという事実が、彼らの後進性の証拠だと思われていました。そのためにさまざまな宣伝を受けていました。私たちも取り残されたくなかったので、私たちのソフトウェアにもバージョン番号をつけるようになりました。宣伝したい時には、前の「リリース」以降に追加された機能をリストアップし、新しいバージョン番号をソフトウェアに付けて、新バージョンがすぐに利用可能になったと発表するプレスリリースを出していました。驚くことに、誰も私たちをつかまえることはありませんでした。

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

バグ

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

Webベースのソフトウェアは24時間使われるので、行うすべてのことが即座に試されます。バグは素早く見つかります。

ソフトウェア企業は時々、ユーザーにソフトウェアのデバッグをさせていると非難されます。そしてそれこそが私が提唱していることです。Webベースのソフトウェアの場合、これは実際に良い計画です。バグが少なく一時的だからです。段階的にリリースすれば、最初からバグが非常に少なくなります。エラーを再現して即座に修正できれば、現れた時点ですぐに見つけて直せます。Viaweb では、正式なバグ追跡システムを使う必要がありませんでした。

もちろん、リリースする前に変更をテストする必要があるので、重大なバグがリリースされることはありません。避けられないわずかなバグは、例外的なケースに関わり、苦情が入る前に遭遇したユーザーにしか影響しません。バグを即座に修正すれば、平均的なユーザーにとってはバグがはるかに少なくなります。Viaweb のユーザーの大半がバグを見たことがないと思います。

新しいバグを修正するのは、古いバグを修正するよりも簡単です。自分で書いたばかりのコードのバグは、通常すぐに見つかります。バグが見つかった時は、潜在的に心配していたことがわかるので、ソースコードを見る前から何が間違っているかがわかることが多いです。6か月前に書いたものの(年に1回リリースする場合の平均)バグを修正するのはずっと大変です。コードの理解も深くないので、汚い修正をするか、さらにバグを導入する可能性が高くなります。[4]

早期にバグを発見すれば、複合バグも少なくなります。複合バグとは、2つの別々のバグが相互作用するものです。階段を踏み外して、手すりを掴もうとしたら手すりが取れてしまうなどです。ソフトウェアでは、これが最も見つけにくく、最悪の結果を招きます。[5] 「すべてを壊してからバグをフィルタリングする」という従来のアプローチは、必然的に多くの複合バグを生み出します。一方、小さな変更を繰り返してリリースするソフトウェアは、そうした傾向がありません。床は常に清掃され、後で何かに引っかかるものは残されません。

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

デスクトップソフトウェアの人間には信じられないかもしれませんが、Viaweb ではバグがほとんど遊び感覚になっていました。ほとんどのリリースバグは例外的なケースに関わるものだったので、それに遭遇したユーザーは、おそらく高度なユーザーで、限界を押していたはずです。高度なユーザーはバグに寛容で、特に自分が求めた機能を追加する際に導入されたものなら尚更です。実際、バグが珍しく、高度な操作をしないと見つからないので、高度なユーザーはバグを見つけるのを誇りに思っていました。怒りではなく、まるで私たちに点数を取ったかのように、サポートに電話してきたのです。

サポート

エラーを再現できると、カスタマーサポートへの取り組み方が変わります。ほとんどのソフトウェア企業では、サポートは顧客を気分良くさせるためのものです。既知のバグについて電話してくるのか、単に何かを間違えているだけなので、何も学べません。そのため、サポート電話は面倒なものと見なされ、開発者から可能な限り隔離しようとします。

Viaweb ではそうではありませんでした。Viaweb では無料のサポートを提供し、顧客からの連絡を歓迎していました。誰かに問題があれば、すぐに再現して修正するためです。

そのため、Viaweb では開発者とサポートが常に密接に連絡を取っていました。カスタマーサポートの人は開発者から30フィート(約9m)ほど離れた場所にいて、本当のバグの報告があればいつでも割り込めました。重大なバグが見つかれば、ミーティングの最中でも修正に取り掛かりました。

私たちのサポートへの取り組み方は、みんなを幸せにしました。顧客は喜んでいました。重要な情報を持ってきたと扱われるのはどんな気分でしょうか。サポートの人も喜んでいました。ユーザーを助けられるからです。スクリプトを読むだけではありません。開発者も喜んでいました。バグを再現できるからです。曖昧な二次情報を聞くだけではありません。

飛び付きバグ修正のポリシーは、カスタマーサポートの人々とハッカーの関係を変えました。ほとんどのソフトウェア企業では、サポート担当者は低給与の人間の盾で、ハッカーは創造主の小さな模倣者です。バグを報告する手順は、おそらく一方向的です。サポート担当者がバグを聞いて、最終的にプログラマーに渡される何らかのフォームに記入します。Viaweb では全く違っていました。顧客からバグの報告を受けてから1分以内に、サポート担当者がプログラマーの隣に立って「そうだ、バグだ」と言うのを聞くことができました。ハッカーから「そうだ」と言われるのを聞いて、サポート担当者は喜んでいました。彼らはまるで猫が捕まえたネズミを持ってきたかのように、期待に満ちた様子でバグを持ってきていました。また、バグの深刻さを慎重に判断するようになりました。なぜなら、今や彼らの名誉がかかっていたからです。

Yahoo に買収された後、カスタマーサポートの人々はプログラマーから遠く離れられました。それまでは、彼らが事実上のQAであり、ある程度マーケティングの役割も果たしていたことがわかりました。バグを見つけるだけでなく、ユーザーを混乱させるような曖昧なバグ的なものの知識の保管者でもありました。[6] また、ある意味でのプロキシ・フォーカスグループでもありました。新機能のうちどちらがユーザーに欲しがられるかを尋ねると、彼らは常に正解を教えてくれました。

士気

ソフトウェアをすぐにリリースできることは大きな動機付けになります。仕事に向かう途中、ソフトウェアに加えたい変更を考えつき、その日のうちに実行したことがよくありました。大きな機能についても同様でした。2週間かかるプロジェクトでも、完成したらすぐにその効果を見ることができました。

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

大企業がするのは、機能をプランニングすることです。Viaweb ではこの点で時々トラブルに巻き込まれました。投資家や分析家に、これからの計画を聞かれることがありました。正直に答えると、計画はないということになります。改善したいことについての大まかなアイデアはありましたが、それを実現する方法がわかっていれば、もう実行しているはずです。これから6か月間に何をするつもりか? 一番大きな効果が期待できるものを実行するつもりです。この答えを言い出せたことはないかもしれませんが、それが真実でした。計画というのは、棚に上げられたアイデアに過ぎません。良いアイデアが浮かんだら、それを実装しました。

Viaweb では、多くのソフトウェア企業と同様、ほとんどのコードに明確な所有者がいました。しかし、所有者になると本当の意味で所有していました。ソフトウェアの所有者以外の誰も、リリースを承認したり知る必要はありませんでした。壊れないようにする唯一の防御は、仲間から馬鹿扱いされるのを恐れることだけでしたが、それで十分でした。私たちはコードを書くときに軽率に前に進んでいるように見えたかもしれません。確かに速いペースでしたが、サーバーにソフトウェアをリリースする前には非常に慎重に考えていました。ゆっくり進むよりも、注意深く行うことが信頼性には重要なのです。熟練のパイロットなら、夜間の動揺する空母デッキに時速140マイルで40,000ポンドの航空機を着陸させることができますが、平均的な10代の少年がパンを切るよりも安全に行えるのは、注意深く行動しているからです。

このようなソフトウェア開発の方法は、もちろん両刃の剣です。少数の優秀で信頼できるプログラマーのチームには非常に適していますが、平凡なプログラマーが大勢いる大企業では、委員会ではなく、アイデアを持った本人によって悪いアイデアが阻止されるべきです。

逆のブルックス法則

幸いなことに、Webベースのソフトウェアには、それほど多くのプログラマーは必要ありません。かつて中規模のデスクトップソフトウェア企業で働いたことがありますが、エンジニアリング全体で100人以上いました。そのうち13人しか製品開発に携わっていませんでした。残りはリリース、ポーティング等に従事していました。Webベースのソフトウェアでは、リリースやポーティングがないので、最大でも13人のプログラマーで十分です。

Viaweb は3人のプログラマーによって書かれていました。[7] 買収されるためには、プログラマーを3人しか抱えていては買い手に受け入れられないと常に圧力がかかっていました。(解決策: 新しいプロジェクトを立ち上げて、プログラマーを増やした。)

プログラマーを少なくて済むことで、お金以外にも多くのメリットがあります。フレッド・ブルックスが『人月の神話』で指摘したように、プロジェクトにメンバーを追加すると、プロジェクトが遅くなる傾向にあります。グループのサイズが大きくなるほど、開発者同士の接続の可能性が指数関数的に増えます。グループが大きくなるほど、ソフトウェアの連携方法を話し合う時間が増え、予期せぬ相互作用によるバグも増えます。幸いなことに、この過程は逆方向にも機能します。グループが小さくなるほど、ソフトウェア開発の効率が指数関数的に高まるのです。Viaweb のプログラマーが実際の会議を開いたことを覚えていません。昼食に行く途中で話すことしか、一度に言うことはありませんでした。

ソフトウェアを運用するには、プログラマーがシステム管理者の役割も担う必要があるのが難点です。ソフトウェアをホスティングする際は、サーバーの監視が必要不可欠ですが、実際にそれができるのはソフトウェアを開発したプログラマーだけです。Viaweb では、システムが複雑で頻繁に変更されていたため、ソフトウェアとインフラストラクチャの境界線を明確に引くことはできませんでした。そのような境界線を設けると、設計の自由度が制限されてしまいます。そのため、「数か月後には」安定化して専任のサーバー管理者を雇えるようになると願っていましたが、実現することはありませんでした。

製品開発を続けている限り、このような状況は避けられないと思います。Webベースのソフトウェアは、書いて、チェックインして、帰宅というわけにはいきません。それは常時稼働しているライブなものです。バグによってユーザーのプロセスが一つクラッシュするだけでなく、全てのユーザーに影響が及ぶ可能性があります。コードのバグがディスクのデータを破損させた場合、修正しなければなりません。つまり、サーバーを常時監視する必要はありませんが(1年目以降は)、最近変更した部分には注意を払う必要があります。深夜にコードをリリースして帰宅するわけにはいきません。

ユーザーの観察

サーバーベースのソフトウェアでは、自社のコードに密接に関わることができます。また、ユーザーとも密接に関わることができます。Intuitは有名で、小売店でお客様に自社製品を紹介し、自宅まで同行して使用状況を観察しています。自社のソフトウェアを初めて使うユーザーの様子を見れば、ユーザーが驚くであろうことがわかります。

ソフトウェアはユーザーの期待通りに動作するべきですが、ユーザーの思考を完全に把握するのは難しいものです。サーバーベースのソフトウェアでは、ユーザーの行動を詳細に把握できます。小規模な人工的なフォーカスグループに限定されることはありません。全てのユーザーの全ての操作を記録できます。プライバシーを侵害しないよう慎重に検討する必要はありますが、最も一般的な統計サンプリングでも非常に有用です。

ユーザーをサーバー上に抱えることで、ベンチマークに頼る必要がなくなります。ベンチマークはシミュレーションされたユーザーに過ぎません。サーバーベースのソフトウェアでは、実際のユーザーを観察できます。最適化すべき箇所を決めるには、サーバーにログインして CPU 使用率の高い部分を確認するだけです。そして、メモリ使用量が CPU 使用量を上回るようになったら、それ以上の最適化は不要だと判断できます。Viaweb のエディターはそのような状態に達しました。

サーバーベースのソフトウェアでは効率性が重要です。ハードウェアのコストを負担しているためです。1台のサーバーで何人のユーザーをサポートできるかが資本コストの分母になるので、ソフトウェアを高効率に設計すれば、競合他社より低価格で提供しつつ利益を上げられます。Viaweb では、ユーザー1人当たりの資本コストを約5ドルまで下げることができました。現在ならさらに低くなっているでしょう。ハードウェアのコストはほとんどゼロに等しいと言えます。

ユーザーの観察は、最適化だけでなく設計にも役立ちます。Viaweb にはRTMLというスクリプト言語があり、上級ユーザーが独自のページスタイルを定義できました。RTMLは提案箱のようなものでした。ユーザーは、予め用意されたページスタイルでは自分の要望を満たせない場合にのみ、RTMLを使っていたからです。当初、エディターはページ上部にボタンバーを配置していましたが、多数のユーザーがRTMLを使ってボタンを左側に配置したため、それをデフォルトのオプションとして組み込みました。

さらに、ユーザーの行動を観察すれば、ユーザーが困っている兆候を捉えられます。そして、ユーザーは常に正しいので、それは修正すべき問題の兆候です。Viaweb では、オンラインテストドライブが新規ユーザー獲得の鍵でした。それは、マーケティング部門が作ったスライドの羅列ではありませんでした。テストドライブでは、ユーザーが実際にソフトウェアを使用していました。5分ほどで、本物の稼働するストアを作れるようになっていました。

テストドライブはほとんどの新規ユーザーを獲得する手段でした。Webベースのアプリケーションでも同様だと思います。ユーザーがテストドライブを問題なく完了できれば、その製品を気に入るでしょう。混乱したり退屈したりすれば、気に入らないでしょう。したがって、より多くのユーザーがテストドライブを完了できるようにすれば、成長率を高められます。

テストドライブの履歴を調べると、ある段階でユーザーがブラウザの戻るボタンを押して混乱していることがわかりました。(Webベースのアプリケーションを開発すると、戻るボタンが非常に興味深い哲学的問題になることがわかります)。そこで、その段階でユーザーに「あとしばらくです。戻るボタンを押さないでください」と伝えるメッセージを追加しました。Webベースのソフトウェアの素晴らしいところは、変更に対する即時のフィードバックが得られることです。その変更により、テストドライブの完了率が60%から90%に上がりました。新規ユーザー数はテストドライブの完了数に比例するので、この変更だけで収益が50%増加しました。

収益

1990年代初頭に、ある人がソフトウェアは定期購読ビジネスだと述べた記事を読みました。当初はかなり冷めた見方だと思いましたが、後に現実を反映していると理解しました。ソフトウェア開発は継続的なプロセスです。新しいバージョンを買い続けさせて支払いを続けさせるよりも、定期購読料を請求する方がスッキリしています。Webベースのアプリケーションにとって、定期購読は自然な課金方式です。

アプリケーションのホスティングは、フリーウェアでは担えない領域です。ホスティングにはストレスと実際のコストがかかります。誰もが無料でやりたがるものではありません。

ウェブベースのアプリケーションは、企業にとって理想的な収益源です。四半期の始まりを空白から始める代わりに、定期収入のストリームがあります。ソフトウェアが徐々に進化するため、新しいモデルが失敗するかどうかを心配する必要はありません。新しいモデルが必要になることはなく、ユーザーが嫌うような変更をソフトウェアに加えた場合、すぐにわかります。未収金の問題もありません。支払いをしない人がいれば、サービスを停止するだけです。また、海賊版の可能性もありません。

この最後の「利点」が問題になる可能性があります。ある程度の海賊版は、ソフトウェア企業にとって有利です。ユーザーが製品を購入する意思がない場合、海賊版を使用しても何も失うものはありません。実際、その人がソフトウェアの標準化に貢献したり、後に正規版を購入する可能性があるため、利益になります。

企業は、顧客ができるだけ多くを支払うように価格設定をすることを好みます。[8] ソフトウェアは、限界費用がほぼゼロであるため、価格差別に特に適しています。これが、Sunサーバー上で動作するソフトウェアが、Intelボックス上のものよりも高価な理由です。 Sunを使用する企業は節約に興味がなく、より高い価格を支払うことができます。海賊版は、事実上、価格差別の最低レベルです。私は、ソフトウェア企業がこれを理解しており、特定の種類の海賊版を意図的に見逃していると考えています。[9] サーバーベースのソフトウェアでは、別の解決策を見つける必要があります。

ウェブベースのソフトウェアは、特にデスクトップソフトウェアと比較して、購入しやすいため、良く売れます。人々が何かを購入しようと決めてから、実際に購入するという2つの別々の段階があると思うかもしれません。 Viaweb以前は、この問題について深く考えたことはありませんでした。実際、2番目の段階が最初の段階に影響を及ぼすことがあります。何かを購入するのが難しければ、人々はそれを欲しいと思わなくなるでしょう。逆も true です。購入が簡単であれば、より多くを売ることができます。 Amazonが存在するため、私はより多くの本を購入しています。ウェブベースのソフトウェアは、特にオンラインデモを行った後であれば、世界で最も購入しやすいものの1つです。ユーザーは、クレジットカード番号を入力するだけで十分です。(これ以上のことをさせると危険です。)

時にはウェブベースのソフトウェアがISPを通じて販売されることがあります。これは良くない考えです。ハードウェアとソフトウェアの両方を絶えず改善する必要があるため、サーバーの管理を行う必要があります。サーバーの直接的な管理権を放棄すれば、ウェブベースのアプリケーションを開発する利点のほとんどを失うことになります。

競合他社の何人かは、この方法で自分の足を撃ってしまいました。おそらく、スーツ組が、この巨大な販売チャネルに興奮し、それがプロダクトを台無しにすることを理解していなかったためだと思います。 ISPを通じてウェブベースのソフトウェアを販売するのは、自動販売機でお寿司を販売するようなものです。

顧客

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

ウェブベースのアプリケーションは、大企業にとっても最適なソリューションになることが多いでしょう(ただし、それに気づくのが遅いかもしれません)。最良のイントラネットはインターネットです。企業が本当のウェブベースのアプリケーションを使用する場合、ソフトウェアの機能が向上し、サーバーの管理が良くなり、従業員がどこからでもシステムにアクセスできるようになります。

この方法に反対する議論は、通常、セキュリティに関するものです。従業員のアクセスが容易になれば、悪意のある人物にとっても同様になります。一部の大手マーチャントは、顧客のクレジットカード情報がウェブベースのサービスよりも自社のサーバーの方が安全だと考えていました。この点を丁寧に説明するのは難しかったですが、実際にはデータはウェブベースのサービスの方が安全でした。テクノロジースタートアップ企業のようにサーバーの運営が事業の中心であれば、服飾小売業者よりもセキュリティを管理する優秀な人材を雇うことができます。また、セキュリティに対してより気を配っています。服飾小売業者のサーバーに侵入された場合、影響は1社に留まり、隠し立てできる可能性があり、最悪の場合でも1人が解雇されるだけかもしれません。一方、私たちのサーバーに侵入された場合、数千人の顧客に影響を及ぼし、CNetのニュースになり、私たちの事業を潰してしまう可能性があります。

お金を安全に保管したい場合、自宅のマットレスの下に置くのと、銀行に預けるのとではどちらが良いでしょうか? このような議論は、セキュリティだけでなく、稼働時間、帯域幅、負荷管理、バックアップなど、サーバー管理のあらゆる側面に当てはまります。私たちの存続は、これらのことを適切に行うことに掛かっていました。サーバーの問題は、おもちゃメーカーにとっての危険なおもちゃや、食品加工業者にとってのサルモネラ感染のようなものでした。

ウェブベースのアプリケーションを使用する大企業は、ITの一部を外部委託しているといえます。これは一見過激な考えですが、一般的に良いアイデアだと思います。企業は、社内のシステム管理者よりも、このようなサービスの方が良いサービスを受けられる可能性が高いです。システム管理者は、顧客や競合他社のソフトウェアと直接向き合う必要がないため、気難しくなったり、対応が鈍くなったりする傾向があります。一方、Viawebでは、私たちには十分な外部の圧力がありました。私たちに電話をかけてくるのは同僚ではなく、顧客でした。サーバーがハングアップすれば、私たちは素早く対応しました。今でも、その思い出が私にアドレナリンを与えます。

したがって、ウェブベースのアプリケーションは、大企業にとっても通常が最適な解決策になるでしょう。ただし、デスクトップコンピューターの場合と同様に、それに気づくのが最も遅いかもしれません。その理由の一部は、より高価なものを必要としていると説得することが、多くの収益につながるためです。

高額な顧客は高価な解決策を購入する傾向がありますが、安価な解決策のほうが優れている場合でも、高価な解決策を販売する側が多くの費用をかけられるためです。Viawebではこの問題に常に直面していました。ウェブコンサルティング会社に説得され、自社のサーバー上に500万ドルの専用オンラインストアを構築することになった高級マーチャントが何人もいました。しかし、クリスマスシーズンにサーバーの負荷が高まると、それほど良い選択ではなかったことが分かりました。Viawebのシステムはこれらのマーチャントが得たものよりはるかに高度でしたが、私たちにはそれを伝える余裕がありませんでした。月300ドルでは、お洒落な服装をした権威的な人間を派遣してお客様にプレゼンテーションをする余裕がなかったのです。

大企業が余分に支払うのは、高価な製品を売るためのコストの一部です。(国防総省がトイレの蓋に1000ドルも支払うのは、1000ドルのトイレの蓋を売るのにコストがかかるためです)。これがインtranetソフトウェアが今後も発展し続ける理由の1つです。単に高価だからです。この難題に対処する方法はありませんので、まずは小規模な顧客を獲得するのが最善の計画です。その後、大手顧客も徐々に来るはずです。

サーバー版

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

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

なぜデスクトップコンピューターが台頭したのでしょうか。私の考えでは、それはより優れたソフトウェアを持っていたからだと思います。そしてマイクロコンピューターのソフトウェアが優れていた理由は、小規模企業が書けたからだと思います。

多くの人は、創業初期の新興企業がいかに脆弱で不確かなものかを理解していないと思います。多くの新興企業は偶然のように始まります。日中は別の仕事をしながら、夜にApple IIで何かのプロトタイプを書いているカップルのようなものです。この幼虫期の段階で、重大な障害があれば新興企業は一瞬にして潰れてしまいます。メインフレームソフトウェアを書くには、あまりにも大きな前のめりが必要でした。開発マシンが高価で、大企業顧客に売るには威圧的な営業力が必要だったのです。メインフレームソフトウェアの新興企業を立ち上げるのは、夜にApple IIでなにかをハックするのとは比べものにならない大きな取り組みでした。そのため、メインフレームアプリケーションを書く新興企業はあまり現れませんでした。

デスクトップコンピューターの登場により、多くの新しいソフトウェアが生み出されました。なぜなら、それらを書くことが幼虫期の新興企業にとって現実的な目標に見えたからです。開発は安価で、顧客は個人ユーザーなので、コンピューターショップや郵送でアプローチできました。

デスクトップコンピューターを一般市場に押し出したアプリケーションがVisiCalcという最初のスプレッドシートでした。これは2人の人間がアトリエで書いたものでしたが、メインフレームソフトウェアでは実現できないことができました。[11] VisiCalcは当時としては画期的な進歩で、人々はApple IIをわざわざ購入してそれを使っていました。これが始まりでした。デスクトップコンピューターが勝利したのは、新興企業がそのためのソフトウェアを書いたからです。

今回、サーバーベースのソフトウェアが良いものになるのは、新興企業が書くからだと思います。コンピューターがとても安価になったので、私たちのようにデスクトップマシンをサーバーとして使い始められます。安価なプロセッサがワークステーション市場を食い尽くし(この言葉をほとんど聞かなくなった)、サーバー市場の大部分を占めるようになりました。Yahooのサーバーは、インターネット上で最も高負荷なものの1つを扱っていますが、デスクトップマシンと同じ安価なIntelプロセッサを使っています。そして一度ソフトウェアを書けば、Webサイトがあれば販売できます。私たちのほとんどのユーザーは、ウォードオブマウスや報道機関の紹介で直接私たちのサイトに来てくれました。[12]

Viawebは典型的な幼虫期の新興企業でした。私たちは起業することを恐れていて、最初の数か月は実験的に扱い、いつでも中止できると自分に言い聞かせていました。幸い、技術的な問題以外の障害はほとんどありませんでした。ソフトウェアを書いている間、私たちのWebサーバーは開発に使っていたデスクトップマシンで、ダイヤルアップ回線で外部とつながっていました。その段階での唯一の経費は食費と家賃でした。

今、新興企業がWebベースのソフトウェアを書く理由はさらに強くなっています。デスクトップソフトウェアを書くのは楽しくなくなってきたからです。デスクトップソフトウェアを書くには、Microsoftの条件に従わなければならず、その buggy OSに合わせて開発しなければなりません。そして何か良いものを書いても、Microsoftの市場調査をしただけかもしれません。

企業が新興企業に支持されるプラットフォームを作るには、ハッカー自身が使いたくなるようなものにする必要があります。つまり、安価で設計の良いものでなければなりません。Macは最初の頃、ハッカーに人気がありました。多くのハッカーがソフトウェアを書いていました。[13] Windowsではそうではありません。ソフトウェアを書くのが上手な人たちは、今ではLinuxやFreeBSDを使っているからです。

私たちはデスクトップソフトウェアの新興企業を立ち上げなかったと思います。デスクトップソフトウェアはWindowsで動作しなければならず、Windowsを使う前に使わなければならないからです。Webにより、Windowsを経由せずにUnixベースのソフトウェアをブラウザを通じて直接ユーザーに届けられるようになりました。これは25年前のPCの登場のようなリベレーティングな展望です。

Microsoft

デスクトップコンピューターが登場した頃は、IBMが恐ろしい巨人でした。今では想像できませんが、当時はそう感じていました。今の恐ろしい巨人はMicrosoftですが、IBMほど見えていないと思います。Microsoftは自分たちの事業をIBMの盲点の上に意図的に築いたからです。

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

私の推測では、マイクロソフトはサーバーとデスクトップのハイブリッドを開発するでしょう。オペレーティングシステムがユーザーが制御するサーバーと連携するものです。最低限、ファイルは中央で利用可能になるでしょう。できる限り、クライアントにはブラウザしか必要ないサーバー上での計算処理に移行することは期待していません。クライアントにブラウザしか必要ない場合、クライアントにマイクロソフトは不要になり、クライアントを制御できなければ、ユーザーをサーバーベースのアプリケーションに誘導することはできません。

私はマイクロソフトが瓶の中のジーニーを閉じ込めるのは難しいと思います。制御できるクライアントの種類が多すぎるでしょう。そしてマイクロソフトのアプリケーションが特定のクライアントでしか動作しない場合、競合他社はあらゆるクライアントから動作するアプリケーションを提供することで、彼らを打ち負かすことができるでしょう。[14]

Webベースのアプリケーションの世界では、マイクロソフトに自動的な地位はありません。彼らはそこに居場所を作り出すことに成功するかもしれませんが、デスクトップアプリケーションの世界で支配したように、この新しい世界を支配することはできないと思います。

競合他社に敗れるのではなく、自らつまずくのが問題です。Webベースのソフトウェアの台頭により、技術的な問題だけでなく、自らの思い込みにも直面することになります。必要なのは自社の既存事業を食い潰すことですが、それに取り組むことはできないでしょう。これまでの一途な姿勢が、今では彼らに逆効果となるでしょう。IBMも全く同じ状況にあり、それに対処することができませんでした。IBMはメインフレームコンピューティングという現金の牛を脅かすことを躊躇し、マイクロコンピューター事業への参入が遅く、消極的でした。マイクロソフトも同様に、デスクトップを守ろうとするあまり、足かせをはめられることでしょう。現金の牛は厄介な荷物になることがあります。

サーバーベースのアプリケーションを支配する者がいないと言っているわけではありません。いずれは誰かが支配するでしょう。しかし、マイクロコンピューターの黎明期のように、しばらくは楽しい混沌が続くと思います。スタートアップにとっては良い時期でした。多くの小企業が繁栄し、クールなものを作り出しました。

スタートアップの先へ

クラシックなスタートアップは、少人数で少額の資金で、スピーディーかつ非公式です。その少人数が懸命に働き、テクノロジーがその決断の影響を倍増させます。勝てば大勝利です。

Webベースのアプリケーションを開発するスタートアップでは、スタートアップに関連するすべてのことが極端な形になります。ほとんど人も金も使わずに製品を書いて発売できます。さらにスピーディーでなければならず、より非公式でいられます。アパートの居間に3人で座り、ISPのコロケーションサーバーを使って製品を立ち上げることさえできるのです。私たちもそうしました。

時間とともに、チームはさらに小さく、スピーディーに、そして非公式になっています。1960年代、ソフトウェア開発とは、IBM用紙に1日10行のコードを書き込む、眼鏡をかけた男性たちの部屋でした。1980年代は、8〜10人のチームがジーンズを着て、vt100ターミナルに入力していました。今では、ラップトップを抱えた2、3人が居間に座っているだけです。(そしてジーンズは最終的な非公式さではないことがわかりました。)

スタートアップはストレスフルですが、Webベースのアプリケーションではこれもさらに極端になります。多くのソフトウェア企業、特に立ち上げ時は、開発者が机の下で寝泊まりするなどの時期があります。Webベースのソフトウェアの恐ろしいところは、これが標準になってしまうことです。机の下で寝泊まりしたという話は通常、「そして最後に製品をリリースし、1週間眠った」で終わります。Webベースのソフトウェアにはリリースがありません。好きなだけ16時間働き続けられます。そして、競合他社もそうできるので、余儀なくそうせざるを得なくなります。できるから、しなければならない。パーキンソンの法則が逆行しているのです。

最悪なのは時間ではなく責任です。プログラマーとシステム管理者は traditionally それぞれ別の心配事を抱えています。プログラマーはバグを、システム管理者はインフラを気にします。プログラマーは長い1日ソースコードに没頭しても、ある時点で家に帰って忘れられます。システム管理者は仕事から完全に離れられませんが、4時に呼び出されても、複雑な対応は必要ありません。Webベースのアプリケーションでは、これら2つのストレスが融合します。プログラマーがシステム管理者になりますが、通常の仕事の範囲を超えてしまうのです。

Viaweb では最初の6ヶ月はソフトウェア開発に費やしました。通常のスタートアップ初期の長時間労働でした。デスクトップソフトウェア企業なら、ここまでが頑張った時期だったでしょう。しかし、ユーザーをサーバーに乗せた次の段階に比べれば、まるで休暇のようでした。Viaweb をYahoo に売却した2番目の大きな利点は(お金に次いで)、全体の最終責任をビッグカンパニーの肩に押し付けられたことでした。

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

ちょうど良い

Webベースのアプリケーションを書くのを躊躇させる要因の1つが、UIとしてのWebページの貧弱さです。これは問題があると認めます。HTMLとHTTPにいくつか追加したかったものがありました。しかし重要なのは、Webページがちょうど良いということです。

最初のマイクロコンピューターとの間には、ここに並行関係があります。これらの機械のプロセッサは実際にコンピューターのCPUとして意図されたものではありませんでした。それらは信号機などに使用するように設計されていました。しかし、Altairを設計したEd Robertsのような人々は、それらがちょうど良いと気づきました。これらのチップの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は唯一のソフトウェア配信方法ではありませんが、今動作しており、長い間動作し続けるでしょう。Webベースのアプリケーションは開発が安価で、最小のスタートアップでも提供できます。大変な作業で、特にストレスの多い種類の作業ですが、それだけスタートアップにとってのオッズが良くなります。

なぜしないのか?

E.B.ホワイトは、農場の友人から、多くの電気柵には電流が流れていないことを知って面白がっていました。牛は柵から離れるのを学習し、その後は電流は必要ありません。「起きろ、牛たち!」と彼は書きました。「独裁者が眠っている間に自由を手に入れろ!」

もしあなたがスタートアップを始めたいと考えているハッカーなら、2つのことがあなたを阻んでいるはずです。1つは、ビジネスのことがよくわからないということ。もう1つは、競争を恐れていることです。これらの柵には電流は流れていません。

ビジネスについて知る必要があるのは2つのことだけです。ユーザーに愛されるものを作り、支出以上の収入を得ることです。これらの2つを正しくやれば、ほとんどのスタートアップを先行できます。その他のことは進めながら学んでいけます。

最初は支出以上の収入を得られないかもしれませんが、その差が十分に早く縮まっていれば大丈夫です。資金不足から始めれば、倹約の習慣が身につきます。支出を抑えれば、支出以上の収入を得るのが簡単になります。幸いなことに、Webベースのアプリケーションを立ち上げるのはとても安価です。私たちは1万ドル以下で立ち上げましたが、今ならさらに安く立ち上げられるでしょう。サーバーに数千ドル、SSLにも数千ドル費やしました(当時SSLソフトウェアを販売していたのはNetscapeだけでした)。今ではバンド幅代だけで支払っていた金額以下で、はるかに強力なサーバーをレンタルできます。高級なオフィスチェアの代金以下で、Webベースのアプリケーションを立ち上げられるでしょう。

ユーザーに愛されるものを作るためのヒントは以下の通りです。まずは自分で使いたいと思うような、シンプルで使いやすいものから始めましょう。素早くバージョン1.0をリリースし、ユーザーの声に耳を傾けながら、ソフトウェアを改善し続けます。顧客は常に正しいですが、顧客によって正しいことが異なります。最も初歩的なユーザーは、簡素化と明確化の必要性を示し、最も高度なユーザーは、追加すべき機能を教えてくれます。ソフトウェアにとって最高なのは使いやすいことですが、これを実現するには、デフォルトを正しく設定することが重要で、ユーザーの選択肢を制限することではありません。競合他社のソフトウェアが劣悪であっても満足せず、ソフトウェアが持つ可能性と比較してください。自分で絶えずソフトウェアを使い続けましょう。Viaweb はオンラインストア構築ツールでしたが、自社のサイトにも使っていました。マーケティング担当者、デザイナー、プロダクトマネージャーなどの肩書きだけで判断せず、良いアイデアがあれば活用しましょう。ただし、最終的な判断はあなたが下します。ソフトウェアは、デザインを理解したハッカーが設計する必要があり、ソフトウェアについて少し知っているデザイナーが設計するのではありません。ソフトウェアの設計と実装の両方ができない場合は、スタートアップを始めるべきではありません。

競争について話しましょう。あなたが恐れているのは、おそらくあなたのようなハッカーのグループではなく、オフィスや事業計画、営業マンなどを持つ実際の企業ですよね?実際、彼らはあなたよりも恐れているのです。ソフトウェアを書くためにオフィススペースを借りたり営業担当を雇うのは、大企業にとってはとても難しいことです。私はこの両方の側面を経験してきました。

Viawebがヤフーに買収されたとき、突然大企業で働くことになりました。それは膝まで水に沈むようなものでした。

ヤフーを非難するつもりはありません。優秀なハッカーもいましたし、トップマネジメントも本当に熱心でした。大企業としては例外的でした。しかし、小さなスタートアップに比べると生産性は10分の1程度でした。大企業がそれ以上のことをするのは難しいのです。マイクロソフトが恐ろしいのは、あれほど大きな企業がソフトウェアを開発できることです。まるで歩くことのできる山のようです。

あきらめないでください。あなたにはマイクロソフトにできないことをたくさんできるのです。そして誰も止めることはできません。Webアプリケーションを開発するのに誰の許可も必要ありません。ライセンス契約を結ったり、小売店の棚に並べたり、OSにバンドルしてもらうために頭を下げる必要もありません。ブラウザ上で直接ソフトウェアを提供できるのです。ユーザーとの間に誰も立ちはだかることはできません。

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

[13] Macが素晴らしかったのに、なぜ負けたのか? コストがまた原因だ。 Microsoftはソフトウェアビジネスに集中し、Appleのハードウェアに安価なコンポーネントサプライヤーの群れを放ち出した。重役が重要な時期に乗り込んできたことも、状況を改善しなかった。

[14] Webベースのアプリケーションを助け、Microsoftに影をおとされることなく次世代のソフトウェアを維持するためには、優れたオープンソースブラウザが必要だ。Mozillaはオープンソースだが、長らび企業ソフトウェアであったため苦しんできたようだ。小さくて高速で、積極的にメンテナンスされるブラウザがあれば素晴らしいだろう。そして、企業にWebアプリアンスを構築するよう後押しするだろう。

その他にも、適切なオープンソースブラウザがあれば、HTTPやHTMLの進化を促進するだろう(Perlなどの例がある)。Webベースのアプリケーションにとって、リンクの選択と実行を区別できるようになることは大きな助けになる。これを実現するには、リクエストに複数のURLを許可するHTTPの些細な拡張で十分だ。カスケードメニューも良いアイデアだ。

世界を変えたいなら、新しいMosaicを書け。遅すぎると思う? 1998年には多くの人がSearch Engineを立ち上げるのは遅すぎると考えていたが、Googleはそれを証明し違った。現在のオプションが十分でなければ、常に新しいものを生み出す余地がある。まずは自由なOSで動作するよう設計すること - 新しいものはユーザーから始まる。

[15] おそらく個人的な経験から、この問題についてもっとよく知っているTrevor Blackwellは次のように書いている:

「サーバーベースのソフトウェアがプログラマーにとてもきついため、大企業から根本的な経済シフトが起きると言えるだろう。プログラマーが自社で行うほどの強い意欲と献身を引き出すことはできない。ソフトウェア企業は熟練者を楽な環境で雇うことができ、未熟な人間に苦労させることもできるが、熟練者に懸命に働かせることはできない。資本が不要になったため、大企業には何も提供するものがない。」

[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に収録されています。