Google徳生氏「2chに“これ作ったやつ死ね”って書かれて…」 サービス企画者が心得ておくべき、"失敗の哲学"とは？

良いプロダクトは、良い「問い」から生まれる

小野裕史氏（以下、小野）：今までアイデアの持ち上がり方みたいな話だったんですけども、それではどう実行、最終的なプロダクトにしていくかっていうのは、結構ここがさらに次のハードルになっていくと思うんですが。ここの部分をいかに実現していくかという部分においての、ハック面でもいいですし、文化面でも構わないので教えてください。

須藤憲司氏（以下、須藤）：そうですね。佐々木さんのアプローチとすごく似ているというか、我々も、今規模がちっちゃいんで、僕らすごく「問い」を大事にしていて。要は、ある物を作りたい、ある事を解決したいというときに、良い問いだと熱狂できるんですよね。

この問題を解決しようっていうときに、数名が集まって「よし！」ってテンションが上がってディスカッションが活発になってくる。良い問いを、いかに生み出せるかってすごく大事かなと思っていて。

その問いの設定がすごく良いと、結果的に言うと、そのプロダクトとして盛り上がっていくというか。なので、その問いの設定みたいなのは毎回本当に結構気を付けていますね。

ゴールを確認することで、チームの動き方が変わる

徳生健太郎氏（以下、徳生）：もうちょっと具体的に、どういった問いですか？

須藤：そうですね。例えば、我々A/Bテストのツールを作りたいのか？　それとも改善させたいのか？　どっちなのかと。そうすると、A/Bテストのツールって複雑な機能あるんだけど、大体使わないよね、みたいな。もっと人のアイデアが欲しいんだよね、じゃあ、そっちにフォーカスしていけるよね、とかですね。

言葉とか問いの設定みたいのは本当に大事かなと思っていて。なので、その問いが良いと、その盛り上がりが変わるみたいなことを大事にしていますね。そういうのってないですか？

佐々木大輔氏（以下、佐々木）：あります、あります。まさに、僕たちも特に仕様も決めないとか、そういう中でやっていると、重要なのはみんなが「ゴールって何だっけ？」っていうのを認識していることであって。そうすると、新しく出てくる機能なり、もしくは改修なりというのが、なんとなくいい方向に向かっているなって形になるんですよね。

例えば僕たちは最初「全自動の会計ソフトをつくってます」、それくらいの握りで、みんなでやっていったんですけど、ある時「これって何のためにやってるんだっけ？」ってわからなくなったことがあって。

そこに対して、皆「あぁいう機能があっても良い、こういう機能があっても良い」、とあれこれ言い始めて、皆の共通問題意識がなくなっちゃった時があって。その時に、「やりたいことって何なの？」っていうふうに話し合って、「いや、僕たちはまず、経営者のために使える会計ソフトにしたいと思う。経理の人のためのソフトではない」というふうに定義したんですよね。

そしたら実は、それ自体は小さなことなんですけども、それによってみんなが、僕たちは経営者のためにやろうとしているから、「こういう機能よりこっちの方が重要だからそれを先に作ります」とか、「この機能を作るときも、こうやってやったほうがいいから、こういうふうに実現しました」とか、そういうことが自然発生的に出てきてですね。やっぱり同じような経験ってあるんだなと思いました。

ローンチするための条件を決めることが重要

徳生：ローンチするまでに絞らなきゃダメなんですね。絶対アイデアの方が先行しちゃうから、「これをできたらローンチしよう。それって何だっけ？」っていうのが、常にチームの中で問われますよね。

1回ローンチすると、少し次の目標が立てやすくなるっていうのは、こういう、良い意味で明らかに「断崖絶壁」みたいのがあって。それでもそれを定めるというのは、結構大事な作業になっていると思いますね。

小野：それに対して、大宮さんがAirREGIを立ち上げられた時って、今の話的にいかがですか。

大宮英紀氏（以下、大宮）：そうですね。同じだなと思っていまして、本当AirREGIも最初「やろうぜ！」っていうふうにすごくノリで始まって、「じゃあ、実際何を作ろうか」っていうところから始まったんですね。

本当にお店に行きながら、実際にやってみてこうでした、というフィードバックをもらいながら絵コンテを書いて。これで「ああでもない、こうでもない」と言っていると、大体このプロダクトのコンセプトみたいなのが、だんだん本当にディスカッションすればするほど煮詰まってきて。まずは、シャープに行こうってことになった。

逆に聞きたいんですけど、高速で走るF1みたいなものって、重要なのはスピードを出すこともそうなんですけど、良いブレーキをちゃんと付けておかないと、やっぱ事故になっちゃうっていうことでどういうブレーキの使い方をされていたのか。そこの良いブレーキとか、そこのどういうふうに組織として担保されているのか、すごく教えてほしいなと思っているんですけど。

成功が指標で測れるように設計する

小野：良いですね。どなたか……。

徳生：さっきのローンチ、ローンチアビリティーっていうんですかね。任せても問題意識を共有できていれば、どこがソリューションかっていうのがわかる。彼らも3ヶ月も4ヶ月も長々と延々と作業をしていて、何にも世の中に出ないと言うのは非常にフラストレイティングです。

そこで、このソリューションはこの目的で、このターゲットのユーザーだから、ここで話せばいいよねっていうのを、開発エンジニアが自分で決めていきますよね。

それで、プロダクト側の人間がああだこうだ、これもあれも必要だとか言い始めると、そもそもこれをやるんじゃなかったのっていう問いが逆に返ってきて。そのバランスが効いている感じがするので、一応僕たちは仕様書らしきものは作りますけれども、「どこができるのか」っていうのが、わりと自然に決まっていくという気がします。

我々が「ここで止めろ」とか言わなくても、彼らが「早く出そうよ」という形になるような気がします。

佐々木：僕たちもそうですね。新しい何かを作りますっていうときに、一応その何かっていうもの。「これは何のためにするのか」だけは、ちゃんと明らかにするようにしていて、何のためにするのか、あと、もしその成功が指標で測れるんだったら、この結果としてこの数字が良くなるはずとか、そういうところをしっかり握るようにしてますね。

それさえあれば、失敗が明確になるので。すぐに例えばロールバックするなりなんなりできますから。あともう1つは、テストを自動化するとか、そういった話もあると思うんですけど。

須藤：全く同じですね。数字にできるっていうのはわかりやすいなと思っていて。数字でなんか違っていたら、何が違ったのかねって、たぶん振り返るところができるので。なるべく数字で置けるっていうのがあるかな。あと本当に滑った時は、なかったことにするでしょうね（笑）。本当にもう、これどうしようもねぇな、みたいなやつはちょっと戻そうみたいな（笑）。

プロダクト失敗の判断基準

小野：今、盛り上がった「いかに実行するか」っていう話から、今度は「とはいっても、これいけなかったな、失敗だったな」っていうケースも今までたくさんの経験があると思うんですけども。

そのときの判断で、特にたくさんのプロダクトが関わっているであろう、徳生さんだとか大宮さんとか、どのようにジャッジするか、ちょっと経営者的視点も含めてですけれども、その辺っていかがですか？

徳生：僕自身は引っ込めたことがないんですけど、いやそれが良いのか悪いのかは別として、昔でも製品を出しましたね。言っていいのかな。モバイルのUIを1回変えたんですよ。iGoogleみたいな、天気だとか、いろんなニュースとか情報をHPに出すっていう。よかれと思ってやったら、すごく不評でして……。

小野：ユーザサイドから？

徳生：ユーザサイドから、遅いとか。当たり前なんですけどね、情報いっぱい載っけたらレイテンシーが上がるに決まっているんですけども、2ちゃんねるとかでは、「これ作ったやつ死ね」とか書かれたりしてね（笑）。

それで「じゃあ、やめよう」って正直言って、僕は思っちゃいましたね。思いましたけど、エンジニアは「どう改善したらいいか」っていうことを考えてモノを作った人間なので、よくよく考えてみれば、作ってくれた人に対して、俺がすぐ「ひっこんでやめよう」っていうのは、確かに間違った発言だよなっていうことをそのときに思いましたね。

結局は量を減らしていったうちに、スマホが出てきちゃったりしたんで、また定時のやり方と、スマホとを両立させるためとかいう目的で、結局それはやめちゃったことになりました。でも、それが直接の原因となったというよりは、少しずつ改善を加えていったというところですね。

出す前に辞めるとかいう判断とか、もっと大変かもしれませんね。せっかくあったのをどうしよう、みたいなのは。

必要とあればコンセプトさえも変える

小野：大宮さんのところはいかがですか？

大宮：そうですね。やっているビジネスに違いがあるかもしれないんですけど。僕らがやっている、BtoB向けのAirREGIみたいなものは会計システムとして使っているので、A/Bテストとか出してすぐに引っ込めるって、アプリの配信の問題もありますし、いきなり普通に出していたボタンが、右から左になるとか、アルファベットにするとか絶対にわからなくなるんですね。

やっているビジネス特性もあるなと思っているんですけど、その時に大事だなと思ったのがβテストというか、クローズのテストをやれるような仕組みをちゃんと整えて、BtoCで言うと、A/Bテストと同じように、BtoBで言うとβテストを何重にも走らせて、ある一定回数である満足度が得られたらリリースするとか、そこを組織的にそろそろ担保しなきゃいけないところもありますし。

あと、クローズドはあんまりやったことがないので、なかなかそうなった時に、どちらかというと、もうちょっと頑張りたいというか、結局諦めていないというか、やれるところに対して、登り方がこっちだったり、違ったりっていうだけなので。

それは最初のコンセプトを変える必要があれば変えにいって、それについて責任をもってやってもらうとか、自分も入りながらやるとか、そういうことをしていますね。

一定の失敗をしていることは挑戦している証

小野：佐々木さんのところと須藤さんのところって、1つのプロダクトで、最初会社を立ち上げるっていうそういう意味では、すごくリスクのある形でのスタートだと思うんですが、そのプロダクトがどの段階で「これはいける、世の中に出せる」と判断されるんですか。起業するというところも含めてですけれども、そこに至るまでのプロセスをちょっと教えていただければ……。

須藤：そうですね。それで言うと、いつ、どういうタイミングで、そのプロダクトを成功だと呼べるのかっていうのもあると思っていて。たぶん相当、僕は失敗をしてる方で、たぶんリクルートの中でもすさまじいくらい失敗していると思うんですけど。

まず、大事なのは面の皮をまず厚くしておくと、要はその失敗をしているんだけどしれっとしている、っていうのがひとつ大事なんじゃないかっていうのが、僕の個人的な技術ですね。

あと一定の失敗をしていることは、挑戦していることとイコールなんで、僕はヘルシーだと思っています。僕はやっぱり（成功確率は）6：4くらいじゃないかと思っていて、6：4から5：5の間ぐらい……。要は45％ぐらい失敗していないと、挑戦していないんじゃないかな、っていう感覚でいるんですよね。

だから、しれっとしてなかったことにするとかですね。そういうスタンスで基本的にやると。僕、佐々木さんのところも多分同じ感覚だと思うんですけど、要はある程度アグレッシブに行かないと、マーケットに対するインパクトを与えられないので。

当然、失敗はあるんですけれども、その失敗をいかに早くマネージしていくかのほうが、スタートアップにとっては大事なんじゃないかなと、思っているんですけれども。その辺ってどうですか？

ローンチするかどうかも仮説検証のプロセスの一部

佐々木：このローンチとかっていうのは、きっと仮説検証のプロセスの単なる一部じゃないですか。なんか、僕達が初めてプロダクトをローンチしたときも、ローンチって1回しかないんで、すごく気負うものの、ただ一方で、これって今起業してやってきて、とりあえず最初に出す仮説検証の1つっていう位置づけだったんですよね。

それで、うまくいかなかったら別に似たようなことなのかもしんないし、ちょっとピポットすれば、何でもできるので、とりあえず仮説検証をしたいなと。仮説検証しない限りは、何も次のステップに進まないので、もうなるべく早く検証をしたいっていう。

もうそれだけだったと思うんですね。なるべく早く検証したいとなると、やっぱりそのためにこれを削らないといけないねっていうのが、どんどんどんどん見えてくるので、検証することが遅れていけば遅れていくほど、リカバリーするチャンスっていうのも無くなっていくと。そこまで考えると、遅らせていくことのリスクってすごく大きいですよね。

須藤：大きいですよね。本当にさっきの「時間こそすべて」というか、成長する時にある程度失敗していないと、新しい価値って積み上がっていかないんで。僕、経営者としては、もう割り切っているというか、逆にちょっと失敗してないとやばいんじゃないかという感覚でいますね。

小野：とにかく打席に立て、と。結構共通したキーワードがありました。立ってみないとわからないだろうと。空振りする中で、次にその学びを繋げていけばいいって話ですかね。ありがとうございます。