スタートアップのアイデアをどうやって得るか、どうやって計測するか (Startup School 2017 #03, Stewart Butterfield & Adam D'Angelo)

f:id:bfore:20180926154650p:plain

目次

Sam Altman
こんにちは。今日は2人のスピーカーに来て頂いています。まずはStewart、Slackの創業者でCEOでもあります。それからAdamは、Quoraの創業者でCEOです。先ずStewartをインタビューし、アイデアや良いものをどう見つけるかについて伺います。それからAdamが会社のメトリクスについて、なぜそれが重要なのか、何を測るのかについてお話しします。

Stewart Butterfeld - どうやってアイデアを見つけるのか

Sam Altman
Stewart, 今日は 来ていただきありがとうございます。 StewartはFlickrとSlackの創業者で、また私はこれを最近まで知らなかったのですが、二度、大規模マルチプレイヤー・オンラインゲームの創業者になろうとし、その事業は現在それぞれ著名な会社になっています。今日は、ゲームのアイデアをどうやって思いついたのかのプロセスと、そしてFlickrとSlack のアイデアのプロセスについてお聞きしたいと思います。

Flickr と Slack のアイデアの始まり

Stewart Butterfield
はい。そうですね、二度も大規模マルチプレイヤー・オンラインゲームを開発しようとしました。その始まりは1992年に遡ります。私は大学に入学し、学校のUNIX マシンのアカウントを手に入れ、そして初めてインターネットというものを経験しました。本当に、鮮烈な体験をしました。これがインターネットが広く使われるようになるだいたい1年ぐらい前のことです。当時は IRC、Usenet、Talk、Eメールなどがありました。私は、それがどんなものであろうと、それぞれにあったコミュニティを見つけられるというアイデアに魅了されました。

もしあなたが元乳がん患者だったり、電車模型のファンだったりなど何でも良いのですが、何かに興味があればそれに関するコミュニティを見つけることができます。私がそうだったように、19世紀の生物学者に関することでも。またオンラインゲーム、ソーシャルでの交流という言い訳としてのゲームプレイなどはとても魅力的なアイデアに思えます。これについて詳しく説明はしません。なぜなら商業ビジネスとしてはひどい、とてもひどいアイデアだとわかるからです。少なくとも商業ビジネスとしては。 趣味としてなら面白かったのでしょうけど。

最初は社員を雇い続けることができるようなビジネスになれただろう、と思います。レストランやなにかのように。ただ、2009年に後にSlackになる会社を立ち上げたとき、1750万ドルをベンチャーキャピタルから調達し、その投資が正しかったと納得させるようなビジネスには絶対になれなかったでしょう。

1回目は少し状況が違っていました。2002年にはITバブルはすでに崩壊しており、WorldcomとEnronの不正会計もありましたし、9.11(アメリカ同時多発テロ)の後でNASDAQが80%下がりS&P500でもピークから65%下がっていました。

誰もインターネットに関連するものに投資をしたがらなかったので、アイデアがいいか悪いかを見極めるのは大変なことでした。マーケットのどこにも「投資すべきアイデアだ」と示すシグナルがなかったのです。当時は投資すべきものがありませんでしたから。

友人と家族から少量の資金を調達し、一年ほどをかけてオンラインゲームのプロトタイプを開発しました。プロトタイプの評判は上々でしたが、その後完成版をつくるまでに1年半がかかり、その間まったく資金を調達できませんでした。会社の中で子持ちだった一人だけにしか給与を出せない状態にまでなった時、すでに開発してある技術を活用でき、かつより早くマーケットに届く別のものを探そうと決めました。

それがFlickrだったのですが、しかしそれも初めはアイデアとしては良くありませんでした。

最初はゲームから始まった

ゲームクライアントを開発してあり、バックエンドにメッセージングサーバーを持っていたので、それを単に写真共有クライアントに方向転換したのです。オンラインゲームでは道具などのリスト用にスクリーンの下に多くのスロットがありますが、これらはFlickrでは写真を一覧できるスロットになりました。またゲームではリアルタイムコミュニケーションが主なので、写真の共有機能もリアルタイムでした。

しかしこれは、共有をしたい誰かと同時にオンラインでなくてはなりませんでした。技術としてはすばらしいものでしたが、私たちがこれを始めたころ、2003年後期だったと思います、その頃は誰も他の人がインターネット上ですることなんかに興味を示していなかったので酷いプロダクトでした。

この状況は迅速に変わっていきました。体験としてはSlackの製作は少し違うものでした。その時にはそれ以上求めるものがないくらいのリソースを持っていました。アイデアを諦めようと決めた時にも資金は余っていてそれで十分すぎるほどでした。以前は無かったAWSもありましたし、ハードウェアも実際には無料でしたし、インターネット回線も随分良くなり、オンライン人口もかなり増えていましたし、ハードウェアもより良いものでした。この大規模マルチプレイヤー・オンラインゲームが良いアイデアでは無かった理由はそのような外部要因によるものではありませんでした。理由は単にマーケットが十分に大きくなかっただけです。

Slack のアイデアに気づいた理由は IRC

Sam Altman
なぜSlackはいいアイデアだと思ったのですか?どのようにSlackの開発を決めたのですか?

Stewart Butterfield
まずIRCに基づいた内部コミュニケーション用システムを開発し始めました。IRCもSlackも両方使ったことのある方ならわかると思いますが、SlackはIRCにそれが1989年にデザインされた時になかった物を全部足したようなものです。

Slack は徐々に作っていった

これは後付けの分析なので本当かはわかりませんが、Slackがここまで成功したのは、気づかないまま進めていた3年半の長いデザイン・プロセスを経ていたからです。

とにかく、IRCを使い始めたのですがが、多くの欠陥がありました。一つはメッセージを貯めておいたり転送できないことです。もしメッセージを送りたい時に相手がサーバーにその時点で接続していなかったらメッセージを送れないわけです。なので最初に開発したのは全てのメッセージを記録してアーカイブに入れるボットでした。

それができたら、メッセージがデータベースにあることになります、それで検索機能が便利だろうと考え、開発しました。それが2009年でした。iPhoneにはいいIRCクライアントがなかったのでSafari内のアーカイブ用にHTML5で書かれたフロントエンドを作りました。すると今度は投稿機能をつけたくなりました。と、そういう繰り返しでした。

「きっと誰かの役に立つと思う」というエゴに引っ張られないように

しかし普通のソフトウェア開発過程にはエゴと憶測が多くを動かすものです。誰かと、あるアイデアがいいかどうか議論しているときに、啓示でも受けて仏教で言うところの悟りをひらけたなら、まったくエゴを挟まず議論できるでしょうが、実際は皆エゴに引っ張られてしまうし憶測でものを語ってしまうものです。「これは誰かの役に立つと思うんだよね」とか言ってしまうんです。

ですが、Slackのプロトタイプとなるシステムの開発においては一番イラつきを感じる問題に集中しました。何か我慢ならないくらいイライラする問題があればそれを最小限の力を使って対処し、やるべきことに戻って数ヶ月の間寝かしておきました。ゲームのほうで働いている人が45人いたので、リアルな世界からのフィードバックを得ることが出来ました。また、それを利用しないようにはいかないようなあまりにも明らかな機会があればそれにも最小限の時間を費やしてまたするべき事に戻りました。

そのプロセスの終わりに、開発し終えたプロダクトがありました。私たちはそれを使用していました。確かにインプリメンテーションは酷く、一からやり直すんならこうはしませんでしたが、それが巨大な価値を持つものであった事は明らかでした。会社で働く皆が二度とこのような物を使わずに仕事はしないと言っていたので、その基準だけでも素晴らしいアイデアのように思えたのです。と、このようなことをもとにすると、いいアイデアであったようですね。それは何年もかけて得た証拠です。

ピボットのタイミングのエピソード

Sam Altman
他にも方向転換を考えた事業案があったのですか?それとも「これが行く方向だ、うまく行きそうだ」という気持ちがあったのですか?

Stewart Butterfield
個人的に書いたプロポーザルを今も見れたらよかったのですが。本当に酷いアイデアをたくさん書いたので。そのなかでSlack は何らかの価値を生み出すものだろうという広いコンセンサスがチーム内で取れていた案でした。

この時の状況は実はちょっと面白いんですけどね。銀行には500万ドルが残っていて、投資家たちの誰もお金を返してほしいといいませんでした。彼らは私たちに何か新しいことに挑戦して欲しいと思っていたのです。 Andreessen Horowitzは私たちの投資家の一人で私たちは彼とのパートナーミーティングで、この大きなアイデアをプレゼンしました。これは Slackを開発し始める前で、プロトタイプができた時でした。

Slack も最初はそこまで良いアイデアとは思わなかった

私たちは、「いつか、これが年間一億ドルの収入をもたらす事業になる、だからそれを踏まえると10億ドルの価値がつけられます。」と言いました。 私たちは10年がかりで達する、しかも頂点がそれだろうと思っていました。10年で100%までいくだろうと。それを2年目で突破しました。

今年は収入2億ドルを達成するでしょうし、会社の成長率もはやいままです。今では年間収入は100億ドルほどになると考えています。言えば1000億ドルの価値のある企業です。

私たちはこのアイデアがここまでいいとは気づいていませんでした。

オンラインゲームを閉じたときのこと

また面白いのが、オンラインゲームの事業を閉じる時のエピソードです。

まだお金もあったし、比較的大きく、エンゲージメントの大きいユーザーベースを持っていたものの、漏れるバケツのようなもので、私たちの開発していたゲームに新規ユーザーを引き込むのがとても難しかったのです。そのゲームはGlitchと言ったのですが、とても手詰まりな状況にありました。

片方では「良い起業家は我慢強いものだ」「誰もがそのアイデアは良くないという時、それは多分本当にいいアイデアなのだ」とか「もっと深掘りして、他の人たちが間違ってると証明してやろう」とか「大変な時でも前に進み続けるんだ」という気持ちがありましたが、また一方で朝起きた時に「もうこれ以上できない。自分はCEOだ、会長兼取締役だ。これがうまくいくはずなんてないってわかってるじゃないか」と思う時もありました。そしてまた誰を説得するのもとても大変でした。

Sam Altman
アイデアを評価するので実際最も大変なことの一つは 「これがうまくいくはずがない」と言うことだと思います。その、朝起きて「あのさ、他のものに移るタイミングだと思うんだ」と言った時のことを覚えていますか。 

Stewart Butterfield
いいえ、というのも、人というのは自分の知覚の動きについて分析する方法を持っていないので、だいたいあとづけの答えになってしまうと思うのですが、しかしあえて言うと、問題を全部修正しなければならない、と考えることに疲れきっていました。

それで新しいユーザーエクスペリエンスに注力することにしました。どのような製品なのか、どんなことができるのか、を知ってもらい魅力を感じてもらいたかったのです。なぜなら新規の方に興味を持ってもらうところまでは問題なかったのですが、彼らをゲームにつなぎとめることに苦労していたので。

よくするためのアイデアが尽きたときにピボットをする

Sam Altman
それはいつも私がそのアイデアをあきらめろと言うタイミングです。どうやってプロジェクトを成功させるかのアイデアが尽きたときですね。

Stewart Butterfield
まさにその通りです。ひとつ思いついたらやってみて、うまくいかない。もう一つやってみても同じ。初めは付箋や大きなボードにアイデアを書き出してどれが一番大きな価値を持つだろうかとか議論し一つ一つ消去していたんです。

それで数ヶ月が経ち、1年が経ち、また半年が経ち。「 くそ、思いついたアイデアはどれもスタートを切るには最悪なものばかりだ。しかもあと3つしか残ってない。これはきっとうまくいかないだろう」と思いました。

アイデアを思いつく方法

Sam Altman
少し前に、プロポーザルをたくさん持っていたとおっしゃいましたね。どのようにアイデアを思いついたんですか?どうやって Slack がうまくいくアイデアだと考えたんでしょうか。新しいアイデアを思いつき、それを評価する方法はどのようなものですか。

Stewart Butterfield
アイデアを思いつくのは簡単です。むしろ思いつかないほうが難しいと私は思います。必ずしもいいアイデアでないですが。

ただどれがいいアイデアか判別する方が実際にはずっと難しいことです。最近になってやっと Thinking, Fast and Slow (訳注:邦訳は「ファスト&スロー」) を読んだのですが、 Herbert Simonという心理学者がチェスのグランドマスターを研究した話が載っていました。

チェスのグランドマスターにカテゴリわけされる人物というのは、経験豊富な医者のような、他の人たちが状況を捉える能力が奇跡的に優れていると思うような人のことです。チェスボードを一目見て、白が3手でチェックメイトする、と分かるような。他人には、それはとても発達した直観だと思われるんです。

Simon 教授は1歳半の子供が犬を見て「わんちゃん」というのと同じ認識方法でしかないと主張します。また例えば誰かが口を開いたはじめの0.5秒で相手が怒っているかわかる、といったことでも同じです。単に状況を認識したり、頭で明確に理解して説明するのが難しい仕草や合図を認識する能力が発達しているだけだ、と。

みなさんの思考と同じ方法なのですが、繰り返して行くほどどんどんうまく出来るようになって行くのです。私はソフトウェアを仕事として20年ほど作ってきています。特定の小さなアイデア、ソフトウェアに関する機能の実装やアクションの順序、どの機能が他より大切かと言うものに関しては、自分が直観的なセンスを持っていると思いますが、それは実際には長い時間をかけて得た認識する能力で、フィルタリングになっています。皆さんも常にアイデアを持っていると思います。皆が持っています。

私たちはSlackで、できるだけ多くを吸収するためにたくさんの組織設計と実践をしてきました。 私たちのツイッターアカウントには、1ヶ月に一万から二万ツイートが来ますし、それはすべて人の手で応対されています。

またカスタマーサポートへのチケットも同じ数くらいあり、フィードバックを全てまとめ、区分するプロセスもあります。Slackに対するツイートレベルでも事例を組み上げ、人の手でチェックし、絵文字を増やすだとか、 これは成功しそうなアイデアだし実践的で実行できる気がするという敷居を超えているように見えるアイデアを取り上げています。

そのレベルでも議論がありますし、また私の知っているほとんどすべてのテクノロジー業界の人がSlackを使っているので、彼らと話せばいつでも彼らの持っているアイデアを聞くことができます。つまり、どんな不満があるか、どんな改善の点があるか、ですが。

Slack に取り組むと決めたときの考え方:やってみないと分からない

Sam Altman
小さなアイデアに関する直感の重要性については同感です。では大きなアイデアに関してはどうでしょう? Slack に取り組むことを決意する前にたくさん思考の時間を取りましたか?本当に戦略的に価値があることか、ネットワークに大きな効果があるか考える時間を費やしましたか?

Stewart Butterfield
全く考えませんでした。これは個別のチームには価値があり、その価値は自分たちの経験で示されたことでわかると思ったんです。これがどれぐらい応用可能かは全く分かりませんでした。どのくらいの規模になるかだとか。

今の時点で世界中に38000人の有料カスタマーがいます。これはかなりの数です。セールスチームもありますが、 これまで90%以上のカスタマーとは全く話をしてきていません。なぜなら単にそれだけ多くの人と話すことができないからです。 再度になりますが、これはすでに私のチームが到達できるだろうと思った地点を越えているのですから。今の状態は全く予測できていませんでした。

こういう大きなアイデアに関しては、わかりません。これについては以前、私たちの間で少し話しました。その中で私が良かったと思っているのは「小説のいい案があるんです、私に必要なのはこれを書いてくれる人だけ」というものです。明らかに不合理ですよね。 誰もそんなこと思わないでしょう。つまり現実を見ていないような人だけがそれが本当だと思い得るのです。

しかし普通、人々は自分でコードを書けないのにアプリに関するアイデアをいつも持っています。それをいいか判断するのはもっと難しいことです。初見からこれはいいアイデアだなと思うプロポーザルを誰かが持ってるのは極めて稀です。逆にやってみないとわからないなということが多いです。

実際ちょうど昨晩 YouTube である動画を見ようとすると、その前にMileIQというアプリのCMが流れました。そのアプリをオンにして現在位置情報取得の許可をすると車を運転する時いつでも運転の速度や止まった場所がわかるようです。自動のStravaのようなものですね。運転の経路を全て記録して、例えば「このドライブは会社に支払ってもらわなければいけない」ってなったら右にスワイプして、そうでないのなら左にスワイプする。

何にせよとてもシンプルなアイデアです。実際とても良いアイデアですね、なぜなら多くの人は運転の記録を残すことがうまくできないでいます。また 車をこのような目的で使ったということを IRSの監査で証明する時にうまくいかないとか、そういうことです。 よくできてるように見えます。アプリ自体もややこしくはなさそうです。私はこれはいいアイデアだと思います。うまく市場に売る事が出来れば成功事業になるでしょう。しかし95%のアイデアでは、それが成功するかどうか全く分かりません。

アイデアの質と実行だと、どっちが重要?

Sam Altman
「アイデアは重要で、いいものを考えつくことに努力する意義がある」から「すべては実行あるのみでアイデアは全く重要でない」までの範囲で、あなたは何処ら辺に位置しますか。 ある日もともと内に持っていたものが Slack のような成功事例に結びつくまで取り組み続けなければいけないのでしょうか?

Stewart Butterfield
このクラスやスタンフォード大学のたくさんの方が、またサウスベイ、ベイエリアにいるたくさんの方がIT企業を始めて成功したいと思っています。 1億匹の猿がタイプライターに打ち込んでいればそのうち一匹がシェイクスピアのソネットを書き始めるでしょう。それに少し似たようなもので、少しですが固定観念やその他の認知バイアスがここで影響してきます。また一方ではこのようなスペクトラムのどちらの両極端も正しいとは思いません。私なら実行する方に寄ると思いますが。

ひとつSteve Jobsのエピソードががあります。John Sculley が彼に雇われて、アイデアだけが重要であると信じるような人たちをApple に採用し始めました。アイデアは絶対的に重要ですが、実行段階に入ったらたくさんのことをそれはたくさんのことを考えに入れなければならないのです。Steve Jobsのケースでは、ガラスを使って何が可能なのか、バッテリーをどれだけ小さくできるか、プラスチックの強度はどれくらいかというようなことです。

アイデアはこのような詳細に立ち合わなければいけなく、一変してとても違うもの、最終的には認識できないものになります。ですが、実行段階をうまくやれれば、元のアイデアのコアが全ての段階において貫かれているようになります。私は実行をする方が好きです。しかしひどいアイデアを実行してどこにも行けないということもあります。なので両方が必要なのです。

今アイデアを探すとしたらどうするか?

Sam Altman
もし今2017年4月に新しい会社を始めるとしたらどんなエリアでアイデアを探しますか?どんなものを思いつくでしょうか?

Stewart Butterfield
これが他の人でも通じるかわからないのですが、一般的に消費者としての自分の経験を私なら見ます。不満を感じるものを見つけるのは簡単ですから。私はとても良い生活を送っているので不満があればすぐに文句を言います。私は本当に素晴らしい生活を送っていますが、それでも何処かへ行く度に大きな不満を10と小さな不満を50思いつきます。その一つ一つが機会なのです。

あなたが思うほどうまくいかない物事のすべてに改善のチャンスがあります。そのうちいくらかは明らかな欠陥なので、誰か他の人も気づいているだろうと思いますが、実際にはそうでない場合が多いです。一つ会社内でよく用いるエピソードあります。プロダクトデザインチームのトップとバンクーバーで散歩をした時のことです。

私たちのバンクーバーのオフィスの近くの道は、歩道がとても狭いのです。歩道にはサンドイッチ店の看板があり、とても混んでいて、また曲がりくねっています。雨が降り出した時にそこを歩いていたのですが、2/3ほどの人が傘をさしていて、そして私たちは傘を持っていませんでした。傘をさした人たちは私たちの方に向かって歩いてくるんですが、誰も向かい側の私たちの目に傘の先端が突きささらないように傘を歩道の外に傾けたりなどしなかったので、私たちはずっと身をかがめていなければなりませんでした。

なぜこうなったのかにはたくさんの説明を思いつきますが、「無知で説明できることを悪意だと説明しない」ですね。この人達が惨めな人生を生きていて、数少ない権力を振るう機会を利用した訳ではないと思うんです。

ですが、二通りの説明しかありません。一つは道を歩いていて、私達がカサを避けるために身をかがめていることに気づかなかった。彼ら自身も絶対にこういう経験をした事があるにも関わらず。もう一つはこの状況を改善できることなんて何もないと思ってしまったということ。1/100カロリーくらいの努力、ほんの少しの考慮で変えられることなのですが。

このエピソードでいいたいのは、これは世界を眺めるには残念なやり方だということです。しかしほとんどの人は生きる中でこうやって過ごしています。 もっとよくないのは、問題に気づいても、解決策を考えることができないということです。2/3の人たちが傘を傾けないなかで、もしあなたが傘を傾けてもいいかなと思える人であれば、世界中にチャンスが広がっています。

Sam Altman
傘を傾けなければならないと気づく方法に関して何かヒントなどありますか?

Stewart Butterfield
よく注意することです。それが一番大事です。特に他の人に注意を向けてください。そうすると自分自身のシグナルにも注意を向けられるようになります。

気付いたアイデアをフィルタリングする方法

Sam Altman
これは実際Y Combinator の歴史の中で、咄嗟に新しいアイデアを起業家が思いつかなければならなかった時に上手く行ったことがあります。たいていうまく行きませんが、他の人々の行動と、何がうまく機能していないかの観察に全力を傾けて成功した例です。それで、何千ものアイデアを思いつくわけですよね、なにか、経験を積み重ねる以外に、観察で気づいたアイデアをフィルタリングするいい方法はありますか?

Stewart Butterfield
そうですね、実際の実行とアイデアの間には理論的な考察があります。物事は一定水準のしきい値を超えた時に絶対気をつけた方がいいことがあって、それは、そのアイデアにしっかり従って行くことが大事ということです。

アイデアが一番いいからというわけではなくて、すでにある程度のトラクションのあるものがあるのに行ったりばったりに次のアイデアを追いかけるのはとても危険だからです。Slackが良い例です。 Slackはビジネス用のツールだと私たちは考えています。そもそもその用途を前提に開発しましたし、そのような価格設定をして、成功もしました。ですが、その他のソーシャルの場面での利用も考えられます。現在Slack のチームの1/3が、何らかのもっとソーシャルな利用法に関する仕事をしています。

前からたくさんの人がもっと個人のコミュニケーションに向けたサービスを出したほうがいいというアイデアを持っていました。グループ用のSlackを作るとか、むしろ消費者向けの会社に方向転換した方がいいだとか。Twitterなどのプライベートなバージョンですね。Slack としてはそのような方向には行かないとかなり固く決めています。なぜならたくさんのことうまくできるわけではないからです。色々な事が輝かしく見え、それは注意を散らすことになります。

Sam Altman
それらの新しいアイデアにノーというのは主にあなたですか。それともそれを会社に刻み込みましたか。Slackほど成功すると新しいアイデアがとても多いでしょう。

Stewart Butterfield
ノーと言う Chief No Sayer は主に私ですが、会社内には私と同等にノーにコミットする人達がたくさんいます。

Sam Altman
なるほど。もしどうしても聞くべき質問があれば次に行く前に、ひとつ質問を受付けましょう。

Stewart Butterfield
どうしても聞かないといけないもの、だけ。

Sam Altman
プレッシャーかけすぎかもしれませんね。

1回目の起業と2回目の起業の違い

Speaker 3
既に Slack 以前に起業で成功されていますね。最初に起業したとき2回目の違いをお聞きしたいのですが。

Sam Altman
2回目の起業における違いは何ですか?

Stewart Butterfield
外部要因は何にせよずっと簡単でしたね。最初の時は 先ほど言ったように Flickrを作ることになりました。何故なら資金を調達できなかったですし、私達はとても焦って何かを完成させようとしていたので。7年が経って欲しいだけのお金を調達できるようになりました。だからそれは簡単になったと言います。資金調達のためにデッキすら作りませんでした。資金が必要だと言うと、投資家が資金提供してくれたのです。

ほんとたくさんのことがずっと簡単になりました。広報、注目を集めるのも簡単になりましたし、求人も、資金調達も簡単になりました。成功することに関してはもちろん簡単ではありません。

Slackを作る会社を始め2009年から3年半はかなり失敗続きでしたから。そもそも成功しなさそうな物を向かい風に押し込んでいるみたいで、全くうまくいきませんでした。また私たちはそこでやめることもできたわけですがそうしなかったので、投資家にとってはリキャップをせず、ただ同じ会社でずっとやってきて成功したというのは非常に良い結果になりました。私たちはこの会社に背を向けて新しい会社を作ることもできたわけで、そうしたのなら「2番目の会社では素晴らしいピボットをすることができました」の代わりに「2番目の会社は失敗でした」と言われるようになっていたでしょう。何がより難しくなるかはわかりません、多分ないと思います、自己批判の範囲と限界の意識を除いては。 

Sam Altman
どうもありがとうございました。

Stewart Butterfield
どういたしまして。

Sam Altman
来ていただけて大変良かったです。次にアダムがメトリクスについて話します。

 

Adam D'angelo - どうやって計測するか

f:id:bfore:20180925080338p:plain

Adam D'Angelo
本日ここでお話ができて光栄です。今から、メトリクスとその測定について、またこの領域に関して会社を始める時に生じる問題についてお話しします。

このトピックで面白いと思うのは、スタートアップを始める時にしなければいけないことの多くがそのスタートアップに特有のものだと言うことです。 何かの領域のエキスパートでなければならず、その領域において誰よりもできるようにならなければいけない、そのような事の多くはクラスで教えるのが難しいのです。なぜならスタートアップによってそれぞれ違うのですから。しかしメトリクスというのはどの会社にとっても必要な一般的な内容で役に立つトピックです。

Amazon の初期の話

さてこれが90年代初めの一番最初の Amazon.com です。

f:id:bfore:20180925080405p:plain

こういうものを見るのはとても面白いなと思います。たくさんのプロダクトの初期のバージョンを見ることが可能です。そしてそれは、何かを始めるというのは考えている以上にずっと簡単だということを思い出させてくれます。 今となってはそれらの会社が巨大になっていても、です。どういう風にその会社が始まったか見れば、あなた自身、会社がどうやって始まるかという現実を頭に留め置いたままにすることができます。さて、誰か Amazon がなぜ本を売るところから始めたか、わかる人はいますか。

Speaker 5
選択肢、ですか

Adam D'Angelo
選択肢...そうですね、お答えになったのは、たくさんの本を取り揃えた中から選べるからと言うことですよね。ただ単に会社が本を売ることを選んだという意味じゃないですよね。本から始まったのは、Jeff Bezosが店を始めようと思い、その中で最も大事なのは他との違いを作ることだからです。すぐに全員に魅力的に映るような製品を作る必要はありませんが、しかしいくらかの人達に、他のどんなものよりも魅力的に映る製品でなければいけません。他と差別化する方法を見つけることが必要です。

また、自分にとってはやりやすいけれど、現存している他社からしたら大変なようなことから始めたいですね。 Amazon の場合、インターネットがこれを可能にしました。店舗販売店は資材を置くスペースが限られていますが、インターネット店舗では大きな倉庫をどこかに持っておき、どこへでも商品を発送することができます。これが普通の店よりもずっと広範囲の商品の提供を可能にします。

ここで、思考実験を始めることになります。もしより良い品揃えができるのであれば、どのカテゴリーの商品が品揃えや商品のアップグレードから一番利益を出せるだろうかと。それが本というカテゴリーだったわけです。

他の商品の選択肢よりも本のバラエティの方が多いですよね。映画を考えると、映画を一本作るのはとても高価です。また本のようにインターネットからすぐに利益が出る業界でもありません。

計測はあいまいなアイデアを良い事業のアイデアに変える

思うに、ここでのポイントは、計測が、曖昧なアイデアを良い事業のアイデアに変える事ができるということだと思います。このような封筒の裏での走り書きの計算をたくさんすればアイデアを研ぎ澄ます助けになりますし、プロトタイプを作らなければならない場合よりもずっとはやくアイデアの範疇を動き回すことができます。もし Amazon が映画から始めてそれに注力していたことを想像してください。数年後にあまりうまくいっていないと判明し、事業は停滞して、他者と競合になっているでしょう。

f:id:bfore:20180925080450p:plain

メトリクスはアイデアを測定するためにも使え、事業を始める時にとても役に立ちます。 またどのような製品がうまくいくか、どの領域でユーザーに多くの価値を提供できるか判断するのにもとてもいいと思います。市場の大きさなどに関してはメトリクスで測ることはあまりうまくいかないと思います。Stewartの話にありましたね。彼らはチャットサービスの市場サイズは1年に1億ドルぐらいの収入だと考えましたが、100倍も大きいと後からわかりました。このような数値を見極めるのはとても難しいのです。

私ならそんなに時間を費やしません。何をやっているのであれ、最終的には大きくなる方法はなんらかあるかもしれません。でも、どうやって商品を差別化するか、昔不可能だったどんなことが今可能になっているかを知るためにメトリクスを使うべきだと思います。

プロダクトの何を測るべきか

この次のプロセスとして製品を開発している段階でメトリクスとして測るものを考えてください。何を測ったらいいでしょう、何を勧めますか?

f:id:bfore:20180925080547p:plain

Speaker 6
ユーザー数でしょうか 

Adam D'Angelo
ユーザー数、そうですね。もう少し具体的に説明していただけますか。

Speaker 6
どれくらいの人がそれを使っていて、どれくらいの頻度で…

Adam D'Angelo
そうですね、全体で何人が、どれぐらいの頻度で製品を使っているか。では次の方。

Speaker 7
どれくらいユーザーが製品について周りに広めているか...

Adam D'Angelo
つまり、シェア数が伸びているかどうか。では次そちらの方。

Speaker 8
Total Addressable Marketですか?

Adam D'Angelo
Total Addressable Marketですね、そちらは?

Speaker 9
ユーザーのリテンション?

Adam D'Angelo
いいですね、ユーザーのリテンション。

これらすべてがいいアイデアです。測れるものはたくさんあります。スタートアップとしてはとにかく何かに注目しなければなりません。注目したいコアになるコンセプトは、今日バリューを得ているユーザーです。これには様々なメトリクスがあります。アクティブユーザーがひとつです。価値を得ている場合、ユーザーはアクティブになりますから。収入に注目するのでもいいです。収入の大きさはユーザーが製品から価値を得ているサインです。

f:id:bfore:20180925080642p:plain

マーケットプレイスサービスのような事業の場合、売り手と買い手が関わってきます。 このような場合には取引を測るのが合理的です。違う属性のグループが関わっている場合、買い手を調べ、そして売り手を調べよう、としておくと、実際たくさんのことができます。買い手には改善になるけれども売り手には改悪となるような。こういうのはいいと思います。

取引を測るというのは、それらグループごとを統合し、双方に利益となるようにあなたの仕事を結びつける方法です。売り手と買い手が存在するマーケットなどがあなたの事業である場合、取引か取引のバリューの大きさを計りましょう。 eBay のような会社では そのマーケットプレイス 上で売られている全ての商品総流通量を測るでしょう。

まずはじめに、この計測というすぐに出来る事をすると、それがその後長い道のりにつながるのです。数値を計測しなければ、 Stewart が言っていたような認知バイアスなどにかかりやすくなってしまい、その後問題が生じたら一体何が起こってるかわからなくなってしまいます。

継続率とコホートを考える

次に最も大切なことは、継続率を考えることです。はじめに皆さんがコホートについて何を知っているかを確認したいと思います。

コホートというのは、ある一定期間に初めてプロジェクトを使ったユーザー全員を指します。スタートアップでは多分一週間を一つのタイムフレームとするでしょう。 ですから「これがローンチから最初の一週間に製品を利用した新規ユーザーのコホートです」と言えるわけです。それでこれらのユーザーをその後も追跡します。 そして1週間後にプロダクトを使い始めた新規ユーザーのコホートもできるので、そういうコホートを計測しトラッキングします。

これで期間内にユーザーの動向がわかります。ユーザー全体が受けているバリューの総量が分かるのでサービスのバランスをとるのにとても重要なやり方です。これは多少古いインターネット製品のコホート全体の使用率のグラフです。

f:id:bfore:20180925080659p:plain

この青いラインは2004年に製品を使い始めているユーザーのものです。それで、この y 軸がそのうち何パーセントが未だにプロジェクトを使い続けているかを示していて、 X軸は時間を示しています。プロダクトを使い続けている人はどんどん減っているのが分かります。それは基本的には全てのコホートのグラフ線で同じです。ではこの製品は10年後...いや、このグラフのスケールの場合は6年後ですね、6年後にどうなっていると思いますか?何か思いつく方?

Speaker 10
逆方向になる、と思います。

Adam D'Angelo
逆に使用者が増えると。

Speaker 10
はい。

Adam D'Angelo
なるほど。可能性はあります。そうなるためにはなにか別のことが起こらないといけないでしょうね。

Speaker 11

誰も使いたがらない。

Adam D'Angelo
誰も使いたがらない。そうですね、何が起こるかを知るのは難しいことです。私は皆が使用をやめるのではと思います。 いくつかの会社はなんとか回復に持って行けますが、でも利用者がどんどん減っていく状況ではとても難しいことです。古いユーザーからどんどん使用率が下がって行くのです。また、たいていは古いユーザーがいるからこそ、新しいユーザーに繋がるわけです。だからもしそこに問題があればそれはかなり悪い状況です。この状況はかなり怖いですね。全体として多数のユーザーを得ることもあるでしょう、全体の使用率が上がっていることもあるでしょう、しかしすべてのコホートでの使用率が下がっていればそれは大きな問題になるだろうということです。

火のリング

「火のリング」という考え方があって、これはユーザーの減少を明示化しようとしているものです。

f:id:bfore:20180925080738p:plain

どこかで下限値がなければ、全てのユーザーを燃やし尽くすことになります。これはたとえなのですが、大きな土地、枯れ草ばかりの土地があると想像してください。 その中心に誰かがマッチで火をつけたとします。火はどんどん大きくなりますが、火の中心は燃えるものがなくなるので、火は燃え尽きてしまい、輪っかができます。その輪っかがどんどん外側に大きくなりますが最終的にはこの土地の全体で燃えるものが無くなり、火はおさまります。これが事業で起きるのは嫌ですよね。

これはアニメーションで、なんとかどういう動きをするか示そうと私が作ったものです。 最初はどんどん広がります。時間がたつ毎に火は大きくなります。 しかしすぐには何も残りません。

f:id:bfore:20180925080802p:plain

わかりましたか、こういうことが起こるのは避けたいのです。このコンセプトをしっかり身に染み込ませておくのはとても重要で、なぜかと言うとそうしないと自分で自分の目をくらませてしまい、最初はより多くの利用数をもたらすけれども既存のユーザーを犠牲にするような施策をたくさんしてしまう可能性があるからです。これを知っておかなければ、結局会社が駄目になってしまいます。最近としてはGrouponがいい例だと思います。

Grouponは大きく成長して、かなり大きな利用数を持っていましたが、長い目で見るとサービスは多くの出品者にとって良い経験ではなかったようで、皆利用をやめてしまいました。もっと最近になると、ポケモン GO も別の例です。これは本当に多くの利用数を得ましたが、それもなんだか萎んでしまいましたね。 このように一時的な熱狂を作り上げるのはさけるべきでしょう。

長い期間利用される製品を作りたいので、既存ユーザーの利用数を確実に計測するようにしてください。 新しいユーザーを獲得するだけではないのです。既存ユーザーがプロダクトを使い続けるようにすることが必要です。既存ユーザーの利用率が上がると、極めて強いポジションにつくことができます。

利用率が伸びる製品を作ること

実際に、少ない数ですが、既存ユーザーのコホートの利用率が時間を追うごとに伸びている製品もあります。

f:id:bfore:20180925080824p:plain

その一つがWhatsAppです。ほとんどのメッセージアプリのように、アプリ上で友達を追加し、メッセージをより多くの人に送信するのでコホートの利用率を時間を経るごとに増加させることができます。

Uber の乗り手側はまた別の良い例です。Uberを使い始めた人は、 利用者が増えて迎えが来るまでの時間が短縮され、より利用が増え、また値段が下がると、それをもっと使うようになります。ですからUber は本当に強いポジションにあります。ドライバーの側ではそうとは言えません。Uberはドライバーの側に問題を抱えていて、なぜならドライバー側にはこれと同じ性質はないからです。

それからFacebook です。Facebook の公表されている数値を見ればわかりますが、ユーザーの数よりも利用率の方が早く伸びています。ユーザーごとの利用率が増加しているのです、もしこれができれば、ここに到達するのはとても難しいことですが、しかしこの時点に到達できれば本当に強いポジションに立つことができます。プロダクトが成長すれば、ユーザー数が増えれば、マーケットを開発すれば、それで長い間ユーザーが使ってくれるようなプロダクトなのか、という視点は実際アイデアについて考える時の一つのやりかたです。

継続率が時価総額を予測する

アイデアについて考えるときに適用できる他のレンズとして、もう一つデータの視点をあげておきます。Tom Tunguzというベンチャーキャピタリストが行った調査で、どのような予測がスタートアップが資金調達をする際の評価につながるのかというものがあります。

f:id:bfore:20180925080842p:plain

これは単純に相関性を調べたものです。これはどのぐらいそれぞれの異なった要因がスタートアップの得られる時価総額評価に相関しているかのグラフです。

一番左は収入の増加で0.18の相関があります。2番目は全体の収入額です。収入の増加量はもう少し相関が高いですね。しかし一番相関が強いのはアカウントの拡大で、これはユーザーが時を経るごとにもっとプロダクトにお金を費やしているかを見るときに使う割合です。ユーザーの継続率の増加と同じことです。この相関が極端に強いですね。時価総額がどうなるかという複雑な数字が、ユーザー1人当たりの収入が0.54増えているかという変数ひとつだけで説明することができます。

会社には二つの区分があるようなものです。一つは時間が経つごとに収入が増えるもの、もう一つはそうならないもので、この二つで会社の評価額は全く違います。

とにかく継続率を測ること

ここでのポイントは今日からユーザーの継続率を測りましょうということです。

f:id:bfore:20180925080856p:plain

これは何をするにしても役に立ちます。会社の成長、ユーザーの維持、ユーザーが本当に愛してくれるプロダクトの開発などに役立ちます。

指数関数的な成長について

次に指数関数的成長についてお話しします。ユーザーの継続は最も大切なことですが、それだけでは十分ではありません。ユーザーを維持できるプロダクトを開発しなければならないのですが、それは必ずしも大規模で皆に届けられるプロダクトであるとは限りません。指数的成長することが明らかに最も強力な成長方法です。

このスライドはいくつかの関数を図にしたものです。赤いラインは直線的な伸びで、青は三次関数的な伸び、それから緑のラインが指数関数的な伸びです。

f:id:bfore:20180925080908p:plain

直線型の成長の経路も取ることはできます。PRを重ねたりしてユーザーを増やせます。ですが、結局どこまで大きくできるかには限界があります。広告を打つのは費用がかさみます。決まった人数のユーザーを惹きつけるためのこのような施策は費用がかかるのです。しかしもし既に持っているユーザー数に比例してユーザーを増やす策が取れるならば、それは指数関数的成長を可能にするでしょう。

早く成長するためにできることをは他にもありますが、成長を測定している場合、知りたい内容に沿ったデータを計っていることを確認してください。

一週間ごとの成長率を測る

もし指数関数的成長を望むならば測るべきは成長率です。これを測定するのに使えるのがユーザーの使用度や収入の1週間毎の増加率です。

これはPaul Grahamのツイートで、私が特に賛成するものです。

f:id:bfore:20180925080922p:plain

ここには「本当に根気強くやる気のある創業者に提案を行うのであれば収入のグラフを示すのではなく週あたりの成長率のパーセンテージを図示しなさい」と書かれています。私は実はなぜ彼が根気強くやる気のある創業者に向けて、と言ったのかわからないのですが。実際のところは週あたりの成長率を測ることがむしろあなたをとても強くするものだと思います。 ツイートとは逆の因果関係ですね。

成長率を測るのはとても大事なことです。Paulが根気よくなければならないとツイートで言っていたのは 、指数関数的成長を維持することは難しいことになるだろうからです。業績のグラフが伸びないのを見るのはいい気持ちがしないかもしれませんが...また全体の収入を測ることもできます。それを測るには問題はないでしょう。しかし必ず週当たりの成長率を測るようにしてください。

あなたのできることで短期的にはプロジェクトを成功させるけれど、指数関数的成長にはつながらないこともあります。あなたがやるべきなのは短期的にも、そして長期的にもプロダクトの成長に繋がることです。それというのはバイラルな成長や、ユーザーの友達紹介、口コミを広げるなど、プロダクトが大規模になるほど次のユーザーを惹きつけることが簡単になるような動きができることです。

プロセスのイテレーション

次にプロセスのイテレーションについてお話しします。

f:id:bfore:20180925080935p:plain

スタートアップの最も重要な利点のひとつは、大会社に比べてイテレーションのスピードが早いことです。会社にとって方向転換を難しくしたりする様々なことがあります。会社が小さいとそのような力が働いていないのです。他の会社よりも事業サイクルをたくさん回すことができたら、 アイデアを速いスピードで実行できたり、プロダクトの変更を素早くできたり、リテンションの早期改善のため事業内容の変更ができたり、成長率をあげるような変化をつけられます。

速い事業サイクルは会社の位置をより強固にしますが、同時にプロセスの反復が正しい方向に向かっている必要があります。シンプルなメトリクスであってもそれが重要な理由は、あなたの会社が正しい方向に向かっているかどうかを教えてくれるからです。やっていることがうまくいっているか、様々な方法の選択肢がある中で、正しい軌道に乗り続ける助けになってくれます。

また、これはあまりどこでも言及されていないと思うのですが、どれぐらい早く事業のサイクルを繰り返しているかや、反復するプロセスの要素の全てを、うまくいっているか測ることができます。

完全に数量化できているかに関わらず頭の中で「このサイクルがどれくらいの時間かかったか、次のサイクルをもっと早くするには何ができるか」と考えていなければなりません。

Quoraで私たちが追跡しているメトリクスの一つが、エンジニアがコードに取り組み始めてからユニットテストを走らせることができるまで、そしてコードが製品に組み込まれるまでどれぐらいかかるか、です。私たちはコードベースの変更からそれがプロダクション環境に反映されるまで、10分から15分の間を保つようにしています。なぜならこれが事業サイクルの繰り返しをずっと早くすることができるからです。

もしそのメトリクスのトラッキングをしていなければ、事業の動きを遅くする色々な力が自然と働くことになります。たくさんの会社が、初めはこのように分単位のリリースで始まるものの、最終的には日ごと、週ごと、月ごとと期間をあけてリリースをするに至ります。私は3ヶ月ごとに製品のリリースを1つしているチームがあると聞いたこともあります。想像してください、リリースが数ヶ月ごと、もしくは週ごとであったら、一体どのように事業サイクルを反復させることができるだろうか、と。

真剣にメトリクスを捉えること

次に、どのくらい真剣にメトリクスを捉えるかという程度には、スペクトラムがあり、多くの会社がそこでつまづきます。

f:id:bfore:20180925080953p:plain

片方ではこれを真剣にとらえず、特に測定の基準をもたない、もしくは数ページ作るけれども誰も全く読まない、もしくは会社で一人だけがそれを知っていて、他にだれもそれを考慮しないというようなものです。 極端に気にしなさすぎると問題が起こります。自分自身の目をくらませてしまう可能性があるのです。同じことを繰り返してしまったり、何をやるのが正しいのかの感覚を失ってしまいます。

気にしすぎるのも問題につながる

しかしまた逆に極端に気にしすぎると、それも問題です。メトリクスは抽象的なものだととらえておくべきです。その根底にある、実際に気にしないといけないことは、例えばユーザーへのバリュー、もしかすると長期的なバリューでしょう。

よいメトリクスはバリューに強く相関していますが、完璧ではありません。忘れてはならないのが、メトリクスの下にある現実は、メトリクスそのものではないということです。

もしメトリクスにばかり注目していると、「こういうやり方をすればメトリクスを増やすことができる」などとなってしまいます。メトリクスを増やすことはできますが、実際長期的な目で見るとそれは自分たちを傷つけることになり、短期的な利益など上回るダメージになるのです。私ならこれには本当に注意するでしょう。

ただし最初は十分に気にすること

個人的には、だいたい中間くらいが理想だと思います。それからメトリクスをかなり真剣に考えるに近いところまで行ったらいいと思います。メトリクスばかりに真剣になりすぎてはいけませんが、私はほとんどの会社はメトリクスを十分にとらえていなさすぎると思います。もしちょうどいいバランスを取れていたら、事業から学習できており、いい意思決定をしていて、情報をちゃんと持っていると同時にメトリクスの下にはプロダクトがあり、戦略があり、ほかにもこのメトリクスよりも大事なことがたくさんある事が理解できるでしょう。しかし多くの会社が二つの間を揺れ動くことになります。

会社の多くはメトリクスを見るばかりで、それが事業によくないと思うことをする原因になり、「このメトリクスはひどい。これは見ないことにしよう」となってしまいます。そうすると、周りで全く何が起こっているかわからなくなり、そこには信頼性はまったくありません。ですので数値を見るか見ないかの間で揺れ動くのは生産的とは言えません。ちょうどいいポイントをみつけてそこから離れないようにしてください。

計測して現実を直視することは痛みを伴う

最後にお伝えしたいのは、いくつかの心理的要素がメトリクスに関わってきます。

f:id:bfore:20180925081013p:plain

データを測りだした時に出てくる大きな物事の一つは、現実を直視し続けなければならないということです。メトリクスは思ったよりも悪くなって行くこともあり、それはとても辛いことです。実際、時には思ったよりもよくなることもありますし、それはすばらしいことです。皆がいい気分になります。

しかし、もしデータを測定していなければ、大半はチャンスにも気づくことができません。良い数字をうまく出すのは大変なことで、ですからそううまくは行きません。数値の測定を始めたら、それはなんらかの痛みをともなうことになり、時には会社に問題を引き起こす可能性があります。会社トップのレベルではさらに辛いだろうかと思います。

この世の会社を運営するリーダーの多くというのは、彼らに従う人たちを高揚させ、そもそもプロジェクトについて働いてもらうためにいくらかの幻想を作りあげ、それに頼っていると思います。

しかしメトリクスがそれを邪魔するかもしれないのです。こうなった時に人々は、「わかった、では、私たちはどうすべきなのか...」と問うことになります。「リーダーとして、何をすべきか」と。

長い間考えて私が思い至ったのは、過去から学ぶべきだと言う事、つまり何が起こったか、何がうまくいったか、いかなかったかを皆に十分知らせるべきだということです。うまくいっているのならうまくいっていることを理解し、そうでないのならそうでないことを理解し、どこに問題がありどこに問題がないのかを正確に知る必要があります。ですが、それらの事は将来に向かって楽観的であることを妨げてはいけません。

可能性というのはたくさんあるので、将来には楽観的でなければいけません。スタートアップをやっている理由はそのポテンシャルなのですから。そしてもし楽観的になれる方向に進んでいると自信が持てなければ、それは進む道を変えるべきというわかりやすい印です。それは完全にコントロールの範疇なので、変えてみようと取り組んでみてください.

物事がそんなにうまくいっていないと認めることと、周りの人を将来に向けて悲観的にしてしまうことの間には、そんなに強い張力はありません。現実的に考えて、あなた自身が信じていない方法で他の人を将来に対して楽観的にしようとするのはいい考えではありませんが、あなた自身が自信を持ち、未来に大志て楽観的になるために必要だと思うことをするべきです。そうすると他の人にそれについてきてもらうことも簡単になります。

話はこれで終わりにして、いまから質問を受けつけます。

f:id:bfore:20180925081029p:plain

Sam Altman
時間がもうないですね。書き留めた質問の回答が後ほど出るかと思います。ありがとうございました、Adam、ではみなさん木曜日にお会いしましょう。

 

 

記事情報

この記事は原著者の許可を得て翻訳・公開するものです。なお原文は講義の書き起こしであり、整形された文章ではありません。今回、文章としての読みやすさを高めるために、適宜改行し、見出しも訳者がつけました。
原文: How to Get Ideas and How to Measure - Stewart Butterfield & Adam D'Angelo (2017)

BFORE (Biz FOR Engineers) はスタートアップに関するノウハウを届けるエンジニア向けのメディアです

運営元