RethinkDBという会社をやめることにしたとアナウンスした時、私は振り返りを書くと約束しました。経験をまとめるのにいくらか時間がかかりましたが、はっきりと振り返りを書こうと思います。
説明不可能な強情な人間性のせいだという説に始まり、MongoDBのマーケティング担当者のずる賢い陰謀、経験豊かな市場開拓チームを作れなかった、そして64ビットfloat以外の数値型のサポートがなかったといったことまで、HackerNewsのスレッドではRethinkDBが失敗したのはなぜかというたくさんの理由が挙げられました。それらのコメントについては、挙げられた失敗の原因の一覧にまとめました。
これらの理由の中には真実に迫るものもありますが、どちらかといえば原因というよりは症状を表すものです。例えば、マネタイズに失敗したから、というのはトートロジーの類です。これは我々が失敗した理由を明らかにしてはいません。
後から考えてみれば、2つのことがうまく行きませんでした。それは、ひどいマーケットを選択してしまったことと、間違った成功指標にプロダクトを最適化してしまったことです。それぞれの間違いで、おそらく1桁か2桁の規模でRethinkDBの価値を下げてしまったでしょう。つまり、どちらかをうまくやっていれば、RethinkDBはMongoDBの規模になっていたでしょうし、どちらもうまくやれていれば、最終的にはRedHatの規模[1]になっていたかもしれません。
ひどいマーケット
私たちの考えはこんな感じでした。新しい会社はOracleをベースに作るわけではないので、新しいインフラの会社を作る絶好のチャンスが存在している。それにデータベースのマーケットは巨大だ。そういったマーケットのいくつかを捉えられれば、とても成功した会社を作れるはずだ。
残念ながら、あなたは自分が想像するマーケットにいるのではなく、あなたのユーザが考えるあなたのマーケットにいます。私たちのユーザは明らかに、私たちをオープンソースの開発者ツールの会社だと考えており、実際我々はそうでした。しかし、オープンソースの開発者ツールはおそらくたどり着く中で最悪のマーケットのひとつであり、ユーザからそう考えられるのはとても残念なことだったと分かったのです。たくさんのユーザが、ビジネス用途も含めてRethinkDBを使ってくれました。しかし、多くの人は使用期間に対してスターバックスのコーヒーの値段すらも払おうとしませんでした(つまり全く払ってくれようとはしませんでした)。
これは、製品がとても良かったから誰もサポートにお金を払う必要がなかったわけでも、開発者が予算をコントロールできなかったからでも、資本主義の失敗によるものでもありません。答えは基本的なマクロ経済学にあります。開発者は開発ツールを作るのが大好きで、しかもそれは無料であることが多いのです。従って、大きな需要があると、それをさらに上回って供給が発生します。この仕組みはたくさんの代替品を産み出し、価格はゼロに行き着きます。
これが他の会社にどのようにはたらくかを見るには、MongoDB(評価額およそ16億ドル、従業員700人未満)とDocker(評価額およそ10億ドル、従業員300人未満)を考えてみればよいでしょう。どちらの会社もそれぞれのマーケットを完全に独占しています。株式公開前の成長過程にあるテクノロジー企業に対する非常に大ざっぱな経験則から言って、評価額は年間収益の10倍、従業員あたりの収益は年間20万ドル前後です。つまり、MongoDBの年間収益はおよそ1.4億ドルから1.6億ドル、Dockerの年間収益はおよそ6000万ドルから1億ドルになります。
これはかなりよい数字に見えるでしょう。しかし、開発者ツール以外のマーケットにいる、支配的な地位のB2Bテクノロジー企業、つまりSalesforceやPalantirやBox(厳しい競争に直面していますが)といった会社を見るとどうでしょう。突如として、MongoDBやDockerがとても小さく見えてきます。
それに、巨大な成功企業たちもいます。既存のパートナーシップや流通網、大口顧客へのつながりを持っている比較的世間に認められた企業たちが成長に困難を感じているのなら、立ち上げ期にあるスタートアップにとっては一体これはどういう意味を持つのでしょうか？
私たちにとって、これは手に負えない顧客獲得ファネルに入り込んだようなものでした。豊かなB2Bマーケットのスタートアップが1回売上を作るために100の見込み客をさばき10回の売り込みの機会を作る必要があるなら、開発者ツールのスタートアップでは10倍の数が必要になります。たくさんの人々があなたのプロダクトをダウンロードし、開発に協力してくれているので、あなたはたくさんの質の高い潜在顧客を抱えてはいます。しかし、たった1回売りを立てるために、ばかばかしい程の数の見込み客をさばく必要があるのです。
これは破滅的なドミノです。チームのやる気を失わせ、投資を呼び込んだりトップ級の人材を雇ったりするのが非常に難しくなります。さらに、リソースが制約されるのでプロダクトや流通に対して十分な投資ができなくなります。スタートアップの生死は勢いで決まります。初期の流通の問題が最終的な破滅に繋がるというのは、ほとんどいつものことです。
間違った成功指標
さて、マーケットが悪いのは分かりましたが、たくさん製品を売っている開発者ツールの会社は存在しています。なぜRethinkDBはダメだったのでしょうか？
マーケットの力学に対しては(違う製品を作る以外)何もできませんでしたが、製品に対する決断は完全に私たち自身の制御下にありました。洗練されていて、堅牢で、美しい製品を作りたかったので、私たちは製品を以下の指標に最適化しました。
- 正しさ : データに対して非常に厳格な保証を作り、それにきちんと従った。
- インタフェースのシンプルさ : 複雑さの多くを実装部分で吸収し、アプリケーション開発者が気にしなくていいようにした。
- 一貫性 : 問い合わせ言語からクライアントドライバ、クラスタの設定、ドキュメント、トップページのマーケティング文句まで、すべてを可能な限り一貫して作り込んだ。
これらのトレードオフに馴染みがあるのは、悪いほうがいいというエッセイから持ってきたものだからです。正しさ、インタフェースのシンプルさ、一貫性というこれらの指標は、多くのユーザには間違った成功指標だと分かりました。ユーザの大多数は以下のトレードオフを代わりに欲しがったのです。
- タイムリーな製品リリース : ユーザは、3年後ではなく、欲しいと思った時に製品が実際に存在していて欲しかった。
- 明白なスピード : ユーザは、私たちが推奨した「実世界の」負荷ではなく、ユーザが実際に試してみた負荷に対して高速なRethinkDBを欲しがった。例えば、読み出しを一切せずに1万ドキュメントを挿入するのにどのくらいかかるかを調べる簡単なスクリプトを書いた。私たちがマーケットを教育する負け戦をしている一方、MongoDBはこれらの負荷を見事に処理した。
- ユースケース : 私たちはよいデータベースシステムを作ろうと試みたが、ユーザはXをするうまい方法を欲しがった(例えば、hapiからJSONドキュメントを格納するうまい方法、ログを保存して解析するうまい方法、レポートを出力するうまい方法、等々)。
私たちがリリースを早くしたり、RethinkDB自体を高速にしたり、便利な機能を簡単にするエコシステムを作ったりと言ったことをしようとしなかったわけではありません。そういうこともやりました。しかし、正しくてシンプルで一貫性のあるソフトウェアは作るのに非常に時間がかかります。その間に、私たちはマーケットから3年遅れてしまいました。
RethinkDBが私たちのデザインゴールに到達し、自信を持って本番環境で使えると進められるようになるまでに、ほとんどすべての人が、「RethinkDBはMongoDBと何が違うの？」と質問しました。私たちは正しさとシンプルさと一貫性がいかに重要であるかを頑張って説明しましたが、結局のところ、これらはほとんどのユーザにとって意味のある成功指標ではなかったのです。
正直、これはつらかった。とてもつらかった。やるべきこと(データを保存する)すらまともにできず、長いカーネルロックがあり、でまかせでエラーを出し、1ノード構成はシャーディングを動かすと使えなくなり、製品のコア機能なのにシャーディングのシステムはまともに動かず、実質的にデータの正しさの保証もできず、見た目の一貫性やビジョンの一致のかけらもないごちゃごちゃのインタフェースをさらすようなシステムをどうして人々は選ぶのか、私たちは到底理解できませんでした。
MongoDBが新しいリリースを公開し、改善が加えられたことを人々が祝っているのを見るたび、私は腹立たしさから心の痛みを感じました。彼らはBKL(Big Kernel Lock)を直したと発表しましたが、実際にはその粒度をデータベースからコレクション単位に小さくしたに過ぎません。彼らはより多くの処理ができるようにしたと言いましたが、それはシステム全体に適用できるように編集可能なインタフェースを作ったのではなく、1回限りのコマンドをただくっつけただけです。彼らはシャーディングを改善たと言いましたが、嫌々やったか、原始的なデータの一貫性の保証すら実装できなかったのが明らかでした。
しかし時間が経つにつれ、私はこの集合知を理解できるようになりました。MongoDBは、時間が経ってからではなく、誰かがそれを必要としたその時に、ただの開発者をヒーローに変えたのです。MongoDBはデータストレージを高速にし、人々がプロダクトを素早く世に出せるようにしました。そして時が経ち、MongoDBは成長しました。ひとつひとつアーキテクチャの問題を修正し、今やそれは素晴らしいプロダクトになりました。私たちが望んだように美しいものではないかもしれませんが、やるべき仕事をやり、しかもうまくやるのです。
私たちに勝ち目はなかった2014年半ばにこれが明らになった時、私たちはMongoDBとの差別化に注力しました。私たちはリアルタイムにプッシュするとても洗練された方法を見つけて、それまでに作れなかったようなアプリケーションの世代を開発者たちが作り上げられることを期待していました。しかしそれは十分ではなかったのです。突如として、MeteorやFirebaseといった私たちが考えもしていなかった何年も前からリアルタイム問題を解決することに取り組んでいた会社と競合であることに、私たちは気づきました。やはり私たちはマーケットから3年遅れており、またしても勝ち目がないことが分かってしまったのです。
クラウドについてどう考えていたか
何人かの人がクラウドサービスを提供するべきだったと提案していました。実は私たちも作ろうとしていたのです。というわけでこれは触れておきたい興味深いトピックです。
クラウドサービスを作ろうとする小さなデータベース企業の明白な問題は、スタートアップにありがちな、フォーカスを分散してしまうという失敗パターンに一致してしまうことです。マルチテナントのクラウドサービスを構築し、世に出して、運営していくのは大変なことです。それには非凡な経験とリソースが必要で、その道を進むことはつまり2つのスタートアップを同時にやっていくことだと気づくでしょう。しかし私たちは現実に脅威にさらされていましたし、急速に打つ手を失っていたので、とにかくそれに賭けてみることにしました。一旦、それがうまく行ったと考えてみましょう。
私たちの論法はこうでした。データベースクラウドサービスの提供は、マネージドホスティング、Database as a Service (DBaaS)、付加価値をつけたPlatform as a Service (PaaS)のどれかを意味することになるでしょう。上で使った従業員あたりの年間収益が20万ドルになるという経験則を使って、簡単なマーケット分析をやってみましょう。
| マネージドホスティング | DBaaS | PaaS | |
|---|---|---|---|
| 企業 | Compose.io, mLab | FaunaDB | Parse, Firebase, Meteor |
| 社員数 | ~30 | ~30 | ~30 |
| 収益 | < $10M | < $10M | < $10M |
つまり、これらのマーケットは小さく、しかもデータベースのマーケット自体よりも小さいのです。とは言え、どれかが他よりもマシになりうるでしょうか？
マネージドホスティングは、本質的にはユーザのためにAWSでデータベースを動かすことで、そうすることでユーザたちは自分で動かす必要がなくなります。これらのサービスを使う代わりになるのは、AWSに自分でデータベースを立てることです。したがって、マネージドなデータベースホスティングサービスが課金できる額には、非常に厳しい上限があることになります。Compose.ioやmLabが、RethinkDBよりも1桁あるいは2桁多いユーザを抱えるMongoDBを提供していることを考えて、マネージドホスティングを提供することには少しの良い点もないという結論を下しました。
Database as a Serviceはマネージドホスティングの更に複雑なバージョンです。DBaaSの提供により、ノードの管理をユーザから完全に切り離します。ユーザはシンプルにクエリを走らせれば、あとはシステムがそれを処理してくれます。裏で何台のノードが動いているかについては関知しません。このビジネスは非常に難易度が高いと言えます。理由の一部はDBaaS企業は大企業(例えばDynamoDBやDocumentDB)に勝つ必要があるためですし、また別の理由として、たくさんの代替製品や選択肢がある時には顧客はデータ管理を完全にスタートアップに任せてしまうのに非常に抵抗を感じるためでもあります(あなたはスタートアップが提供するDBaaSを使っている人を知っていますか？)。そんなわけで、DBaaSの提供も消えました。
最後の案は付加価値をつけたPlatform as a Serviceを作ることでした。私たちは、非常に大きな技術的なアドバンテージを持っていたので、これを可能性のある方向性だと考えました。FirebaseやMeteorは、リアルタイムなクエリの機能や大規模環境でのパフォーマンスを制限してしまうMongoDB上に、アプリケーションレベルでリアルタイムなロジックを組む必要があったのです。一方で私たちはスタックの端から端までをコントロールしていたわけで、FirebaseやMeteorが作り得ない明確な優位点を提供できる可能性がありました。
そして私たちはHorizonというサービスを作り、RethinkDBとHorizonアプリケーションをデプロイしスケールする仕組みであるHorizon Cloudに取り組み始めました。非常に小さなチームで3つの大きなプロジェクト(RethinkDB、Horizon、Horizon Cloud)を作るという挑戦は、結果的に悪い結果をもたらし、私たちは金を使い果たす前にクラウドサービスを世に出すことができずに終わりました。しかし、エンジニアリングチームには賞賛を。彼らはもうほんの少しというところまで来たのです。
メタな質問
私たちができるもう一歩踏み込んだ根本原因の分析があります。なぜ私たちはひどいマーケットを選び、間違った指標に製品を最適化してしまったのでしょうか？
小さな子供の頃、私は自分のラジオを作りたいと思いました。ベニヤ板で箱を作り、金属製のガラクタをそこに突っ込み、電源コードを箱につなぎました。電子工学に関する本も家にありましたが、読む必要があるとは考えませんでした。ひとりでできるという断固とした自信があったのです。結局私はちゃんと動く受信機を作りましたが、基礎的な電子工学を学ぶ必要があると最終的に分かるまでに何年もかかりました。
初期のRethinkDBはこれとかなり似ていました。プロダクトやマーケットに対してなんの勘もなかったので、実際何をしているのか理解しないままに会社を作ったふりをしていたのです。その上、私たちはとてつもない楽観バイアスを持っていました。医者達が、製薬会社からの贈り物が他の医者にはバイアス効果があるのに自分はその効果の影響を受けないと思っているように、私たちは経済原理やビジネスしていく上での数学とは関係がないと信じていたのです。当たり前ですが、そう言った数学は、結局悪い結果に結びつきました。
私たちは、これらの間違いを避けるために何かできたのでしょうか？子供の頃にちゃんと動くラジオを作れたのとは違うのです。私たちは無意識のうちに無力になっていて、その無力さに気づくのに何年もかかったのです。
私たちが経験豊富な市場開拓チームを作れればもっとうまくできたはずという指摘をした人たちもいました。これは100%正しいのですが、私たち個人の成長が、会社のニーズとぴったり合いませんでした。最初は自分たちが市場開拓の知識が必要とは思っていなかったので、創業チームにそういう人を含めようとしませんでした[2]。現実に即したメンタルモデルを作る段階になって、現金が不足していて、優秀な競争相手でいっぱいの難しいマーケットにいて、製品が3年遅れであることに気づいたのです。その時には、世界で最高の市場開拓チームも私たちを救うことはできなかったのです。
別れの言葉
開発者ツールの市場に非常に強烈な考えを持っている人はたくさんいます。エンジニアは開発者ツールを作るのが大好きですし、だからこそ開発者ツールの会社にぜひとも生き残って欲しいと思っています。
私はマーケット全体がダメだというのは気が引けます。それは、1回だけの経験から一般化したくないからでもあり、「できない」というのは好きではないからでもあり、例外がいくつか存在するからでもあります。GitHub、MongoDB、Dockerは素晴らしい会社を作り上げています。GitLabやUnityもうまくやっているようです。
もしあなたが開発者ツールの会社を立ち上げるなら、注意して進むべきです。マーケットは優れた選択肢にあふれています。ユーザの期待値は高い一方で、価格は低いでしょう。あなたが顧客に提供する価値について、深く考えるのです。世界をこうしたいと望んでもそうはならないということを忘れないように。
2009年に、YCombinatorのデモデーに投資家たちにRethinkDBの初期アイディア(当時まだソフトウェアはありませんでした)を提示しました。私たちは、覚えておくべき3つのキーポイントを書いたスライドをそのピッチの最後に持ってきました。「RethinkDBについて3つのことを覚えさえすれば」「これを覚えてください」と私たちは言い、うまくいきました。ピッチの他のことを覚えている人はいませんでしたが、最後の3つのポイントは覚えていました。
さて、私は覚えておくべき3つのキーポイントを挙げようと思います。この記事について何も覚えていなくても、これは記憶してください。
- 巨大なマーケットを選びつつ、明確なユーザ群を形成しろ。
- 不足している人材を認識する方法を学び、その人材をチームに入れるよう死に物狂いで取り組め。
- The Economistを本気で読め。あなたをより早く成長させてくれるだろう。
[1] 数字に関して詳細に考え過ぎないでください。概算しただけですが、これらの間違いの大まかなコスト感は分かるはずです。
[2] ちなみに、しっかりしたビジネス上の感覚がないにもかかわらず優れた経営者を評価することは、エンジニアリングに関するしっかりした感覚がないのに優れたエンジニアを評価するのと同じぐらい難しいことです。
