# もうひとつの未来への道 原題: The Other Road Ahead（Paul Graham, 2001年9月／マサチューセッツ州ケンブリッジの BBN Labs での講演を基にしたもの。表題は Bill Gates『The Road Ahead』のもじり）／進捗 24%〜42% **中心主張**: 次世代のソフトウェアの多くはデスクトップではなくサーバ上で走るようになる。それはユーザにとって便利であるだけでなく、開発者にとってリリース・バグ・サポート・士気・人数のすべてを変え、少人数のベンチャーが大企業に勝てる直接の方法を与える。Viaweb（後の Yahoo Store）の3人での経験が、その未来の最初期の旅行記である。 **実践指針**: - 新しいソフトウェア事業を始める場面では、Web ベース（サーバ上で走る）を選べ。誰の許可も要らず、ライセンスも棚の確保も OS バンドルの交渉も不要で、ユーザに直接届けられる。 - リリースを設計する場面では、「バージョン」という考え方を捨てよ。動く前に出す必要はなく、動いたらすぐ出せる。Viaweb は1日に3〜5回リリースしたこともあった。年1回のリリースは、数え切れないバグを溜め込んだ塊を作る行為である。 - バグを減らしたい場面では、変更を小さく段階的にリリースせよ。新鮮なバグを直すのは古いバグより簡単で、複合バグ（別のバグが相互に影響し合うもの）が生まれにくい。「床はつねに綺麗に掃かれていて、あとでどこかにひっかかりそうな邪魔なものはきちんと片付けられている」。 - 状態を持つコードを減らせる場面では、関数的プログラミング（副作用を避ける）を使え。状態を持たない部分は独立してテストでき、常に小さな変更をテストしている環境ではとても有効。Viaweb のエディタの大部分と、専用スクリプティング言語 RTML は純粋関数型だった。 - カスタマーサポートを設計する場面では、開発者から離すな。Viaweb ではサポート部門がプログラマから10m と離れておらず、バグと分かった時点でプログラマの仕事に割り込めた。ユーザからのバグ報告が1分もたたないうちに修正される。サポートは実質的に品質管理部門であり、営業部門でもあり、フォーカスグループの代理でもある。 - 「計画」を求められた場面では、それが「棚に積まれたアイディア」の言い替えでないか疑え。良いアイディアを思いついたらすぐ実装できるなら、計画は要らない。アイディアを寝かせておくことは、その実装が遅れるだけでなく、実装から得られたはずの新しいアイディアをすべて失うことでもある。 - チームを大きくしたくなった場面では、Brooks の逆転を思い出せ。グループが小さくなればなるほど、ソフトウェア開発の効率は指数的に増大する。Viaweb はプログラマ3人で、ミーティングをした記憶がない。 - 最適化する場面では、ベンチマークではなく実際のユーザを見よ。サーバにログインして CPU を食いつぶしているものを見ればいい。Viaweb はエディタを、CPU ではなくメモリが律速になるところまで最適化してそこで止めた。 - 設計指針が欲しい場面では、ユーザがどこで困っているかを見よ。Viaweb では多くのユーザが試用サイトの途中でブラウザの Back ボタンを押していたので、そのステップに「もう最後まで来たので Back を押さないで」というメッセージを入れた。試用サイトを最後まで使う割合が 60%→90% に跳ね上がり、それだけで利益が 50% 増えた。 - 顧客を選ぶ場面では、まず小さな顧客を相手にせよ。大会社は遅れて気づく（デスクトップと同じ）。残りは後からついてくる。 - ISP をリセラーにするな。サーバへの直接の制御を手放すと、Web アプリケーションを開発する利点の多くを手放すことになる。「Web ベースソフトウェアを ISP を通じて売るというのは、寿司を自動販売機で売るようなもの」。 - ベンチャーを始めるのを恐れている場面では、ビジネスについて知るべきことは二つだけと知れ。「ユーザが気に入るものを作ること」と「使った金より多くの収入を得ること」。 - 製品を作り始める場面では、まず自分が使いたいと思う明快で簡単なものを作れ。バージョン1.0を素早く出し、ユーザの声を聞きながら改良せよ。ライバルのソフトウェアの現状ではなく、自分のソフトウェアのあるべき姿と比べよ。 - 肩書きで判断するな。マーケティングやデザイナやプロダクトマネージャの意見を、そういう肩書きだからというだけで鵜呑みにしない。「ソフトウェアはデザインを知っているハッカーによってデザインされるべきで、ソフトウェアのことをほとんど知らないデザイナーによってデザインされるべきではない」。 **根拠となる事例・考え方**: - 1995年の夏、著者はロバート・モリスとベンチャーを立ち上げた。最初の1〜2週間は普通のデスクトップアプリを作るつもりだったが、「Web サーバ上でソフトウェアを走らせ、Web ブラウザをインタフェースにしたらどうか」と思い付いた。サーバ上で走らせればユーザにとっても自分たちにとっても全てが簡単になる。 - 当時これを理解する人はほとんどいなかった。1年後に Hotmail がスタートし、ようやく人々が理解しはじめた。後に ASP（アプリケーションサービスプロバイダ）という名前が付いた。 - デスクトップソフトウェアの時代は、初期の自動車の持ち主に似ている。最初の2〜30年は車を持つには車のエキスパートでなければならなかった。著者の母（65歳、メールと家計簿にしか使わない）が新しい OS のインストールについて考えなければならないのはどこかがおかしい。 - Web ベースアプリケーションは単一のバイナリではなくプログラムの集合であり、設計はビルディングより都市を作るのに似ている。Viaweb にはユーザが直接対話するアプリケーション群、監視プログラム群、立ち上げ直しプログラム、統計・サーチインデックス、ユーザのエミュレーション、ネットワーク診断、バックアップなどが含まれていた。「Viaweb の一部は『プログラムが存在しないこと』により作られていた」——不要なユーティリティを走らせないのが Unix のセキュリティでは重要だから。 - 言語の自由: サーバベースなら OS と同じ言語で書く必要がない。ライバルの多くは C や C++ を使っていて、CGI スクリプトが状態を持たない問題を回避できなかった。Viaweb は Lisp を使うことでエディタをデスクトップソフトウェアのように振る舞わせた。 - 効率が資本コストに直結する: サーバ当たりどれだけのユーザをサポートできるかが分母に効くので、ソフトウェアを効率良く書けば競争相手より安く提供してなお利益を上げられる。Viaweb はユーザ当たりの資本コストを $5 程度まで下げた。 - Brooks の逆転: 中規模のデスクトップソフトウェア会社では技術部門100人以上のうち製品開発は13人だけで、残りはリリースや移植。Web ベースなら最大でもその13人でよい。フレッド・ブルックス『人月の神話』の指摘（人員追加はプロジェクトを遅らせる）は逆方向にも働く。 - 欠点: 全てのプログラマがある程度システム管理者でもなければならない。「Web ベースソフトウェアは、一日の分を書いて、チェックインして、家に帰る、みたいなものにはならない。それは生きていて、今まさにサーバ上で走っている」。ストレスは総量としては減るが、プログラマにとっては増大する。 - なぜ前回メインフレームが敗れたか: デスクトップの方により良いソフトウェアがあり、それは小さな会社がそれを書くことが可能だったから。メインフレームソフトウェアを書くベンチャーは、開発機が高額で顧客が大会社なので、始めるまえに多大なコミットメントが必要だった。VisiCalc は2人の若者が屋根裏で書き、人々はそれを走らせるためだけに Apple II を買った。 - マイクロソフトへの推測: サーバ/デスクトップ複合体を開発するだろうが、クライアントにブラウザだけを置いて全計算をサーバへ持ってゆくことはしない。ブラウザだけならクライアントにマイクロソフトは必要ないから。「Web ベースアプリケーションの世界には、マイクロソフトの場所はあらかじめ用意されてはいない」。 - Web ページを UI として見た貧弱さは問題だが、「とりあえず使える」ことが決定的。初期のマイクロコンピュータのプロセッサも本物のコンピュータの CPU を目指してはいなかったが、Altair を設計したエド・ロバーツは「とりあえず使うには十分だ」と気づいた。 - Viaweb はマンションの一室のリビングに3人で座ったまま製品を公開でき、サーバは ISP に置いていた。最初のサービス開始は $10,000 以下。数千ドルをサーバに、数千ドルを SSL に使った（当時 SSL を売っていた唯一の会社は Netscape）。 - ケンブリッジのかつてのドイツ美術の美術館の壁の忠告 "Du kannst denn du sollst"（可能なら、やらねばならない）。Web ベースアプリケーションでは出来ることがいくらでもあるため、プレッシャーが最大限になる。パーキンソンの法則を逆に適用しているようなもの。 - E. B. ホワイトの逸話: 電流を流す柵の多くは実際には電流を切っている。牛は一度感電したら近寄らなくなるから。「立ち上がれ、牛たちよ！ 君主が寝ている間に自由を手にせよ！」——ハッカーがベンチャーをためらわせる二つの柵（ビジネスを知らないこと、競争が怖いこと）にも、電流は流れていない。 - 締めの一文: 「マイクロソフトはあなたを恐れているよ。（…）だって、1975年、新しいソフトウェアの開発法が出現した時、彼は、あなただったのだから。」 **キーワード**: - **ASP（アプリケーションサービスプロバイダ）**: サーバでソフトウェアを走らせて提供する業態。本エッセイ執筆時点(2001年)の呼び名で、現在の SaaS の原型。 - **コードの都市**: Web ベースアプリの設計思想。単一バイナリではなく、上下水道・警察署・災害対応計画まで含む都市を作るような設計。 - **Brooks の逆転**: 『人月の神話』の逆。グループが小さくなるほどソフトウェア開発の効率が指数的に増大する。 - **複合バグ**: ひとつのバグが別のバグの不具合をたまたま隠してしまうもの。一方を直すともう一方が現れ、最後の修正が間違っていたかのように見える。段階的な小リリースが最も効く対象。 - **RTML**: Viaweb のユーザがページスタイルを定義するために使った専用スクリプティング言語。純粋関数型で、ユーザが RTML に手を出すことが「組み込みのページスタイルでは足りない」という目安になった。 - **試用サイト（demo site）**: 5分ほどで実際に動くオンラインストアを構築できたもの。ほとんど全てのユーザを獲得した経路であり、広報部門のスライドより有効だった。