立ち上げからサービスリリースまでの失敗と学び
伊藤敦之氏（以下、伊藤）：僕の話はみなさんとすこしレイヤーが違ってて、サービスの立ち上げからやってリリースまでにやった失敗と学びについて、お話したいと思います。
最初に言っておかないといけませんが、僕、今朝まで完全にテーマのネタを間違えてたんですね。エンジニアがギークな話をする場だとばかり思っていて、実は「Slackを自分で作ってみた」がもともとのテーマだったんです。
それをいきなりやめてこっちに変えたら、広報の方から「社外秘のデータがありすぎるからやめてくれ」っていろいろ言われてしまったので、今回、スライドの写真撮影は勘弁してください。
僕は伊藤敦之といいます。株式会社ローカルワークスというスタートアップで働いていて、新卒2年目です。自分ではRailsエンジニアだと思っていて、たぶん、これから話すことはぜんぜんエンジニアっぽくないです。
プロトタイプをいろんなかたちで作るのが好きですね。ああ、下のSlackは、技術スタックは、裏側はElixirで作って、表はReactで作るという、ちょっとニッチなことをやってみました。
これまでやったこととしては、コンセプト設計とUX設計とユーザーインタビューして、弊社にはデザイナーがいないのでUI設計もして、実装をやって、現在はカスタマーサクセスをやっています。
立ち上げからやっていると失敗と学びがいろいろあったので、それをみなさんにフィードバックできたらと思います。
コンセプト設計における失敗と経験
まず、コンセプト設計の段階でいろいろ失敗しました。1つ目、「自分たちの希望でいきなりプロダクトを作ってしまう」。サービスが立ち上がる以上なにかしらのビジネス要件が必ず会社の中にあって、それにかなり引っ張られてしまったことが一番最初の失敗でしたね。
2つ目、「仮説なしでコンセプトの検証ができないプロダクトを作ってしまう」。なにか作る以上、検証は回せる、つまり失敗か成功かわかる状態にして作らなくちゃいけないんですけど、それが甘い状態で作ってしまって、失敗して、その経験を活かしてコンセプトをちゃんと作ろうってなりました。
「いろんな機能があっていろんなことできたらいいよね」みたいな、もりもりのコンセプトで作ってしまうというありがちな失敗を、僕たちもやりました。
本当に、最初はなにも手がかりがないです。なにが正しくて、なにを検証しなければいけなくて、どんな状態なのかぜんぜんわからない。だから、ちゃんと整理と言語化することが、コンセプト設計の段階で一番重要だと感じたところです。
まず、リーンキャンバスを書きました。ここで辻褄が合ってなかったらユーザーに売れるわけはないので、確実に辻褄が合うものを作りました。
それから、ユーザーが使うときのストーリーに沿って紙芝居を作りました。辻褄が合うようにものづくりをできているかの整合性をちゃんと合わせて、自分たちで言語化と整理を進めました。
その結果「こういうものを作っていこう」とか「こういうことをやっていこう」というコンセプトがシャープになって、かなり小さい単位でものづくりに向かっていけました。
なにを検証しなくちゃいけないかもかなり明確になってきますね。今ここでわかっていることと、次の段階で検証して確証を得ていかなくちゃいけないものが、かなり明確になりました。
インタビューの設計
この段階でいろいろプロトタイプを作ったんですが、コードを書く必要がないことに気づいてしまったわけです。薄々「僕なんか必要ないんじゃないか」と感じながら仕事をしていました。
その時に、インタビューに行こうということになりました。UXっぽくやると、ちゃんとユーザーからインタビューして、それをプロダクトにフィードバックしていこうということをやりました。
インタビューは実際にユーザーと触れ合う機会なので、かなりおもしろいですね。インタビュー設計もしたんですが、どういう質問をするか、どんなことを確認するかを決める作業自体が、言語化や仮説とかをシャープにしていく作業を非常に手助けしてくれるので、僕たちの中でもかなりいいことをやったなと思っています。
その中で「失敗しちゃったな」と思った部分は、ユーザーへの提案を忘れてしまったことです。なかなかいいフィードバックが出ないなと思うときもあるんですけど、どちらかというとユーザーからニーズを聞き出そうと思っていることがかなり多くて、でも、そうじゃないんだなって後々わかってきた。
あと、理想を探しすぎてしまったことです。どこで実際のプロダクトに回すかをはっきり決めなきゃいけないタイミングがあったのに、インタビューに時間を費やしすぎて、そのタイミングからかなり遅れてしまったという印象ですね。
根本的にユーザーは、自分たちのニーズに気づいていないことが多いんです。そういう中からニーズを引き出そうとするのは、かなりの無茶なんですね。
だから、僕たちは比較を作ってあげることにしました。紙芝居で3パターン用意して「どのパターンがいいですか？」みたいなインタビューをしたり、あと、Sketchでアップデートも含めて4パターン作って「どれがいいですか？」とか「どこがいいですか？」というふうに聞いていった。
そうすると「ここはこっちがいいけど、ここはこっちがいい」みたいな、比較によって出てくるインサイトがあって、すごく勉強になりました。ここからインタビューの精度がかなり上がったと思います。
検証スピードを上げるために
どこまでがインタビューでどこからがプロダクトの検証なのかというところは白黒つかないんですけど、これって答えがないので、どこまででも思考できてしまいますね。そのことに気づくのがかなり遅くなってしまったので、コンセプトと提供価値を削りました。
考えすぎて、少し欲張りすぎて肥大化していたものをシャープにしたり、検証可能な範囲に留められるようにしました。スタートアップなので、スピードが確実に求められているので、速い単位でちゃんと検証できるフィードバックループにしましょうということです。
（スライドを指して）この図は、僕たちがコンセプトを決めるときのツリーです。そのコンセプトに対してどういう提供価値を与えるかを紐づけて考えていたんですが、バツになっているところを削って、よりシャープに検証できる状態に持っていこうとしました。
まとめると、比較のかたちでユーザーに提案することで、結果としてよい意見がもらえた。プロダクトも肥大化していたものをかなりスリムにしたので、検証項目がシャープになりましたということです。
こうなってくると、要件がかなり見えてきますね。Sketchも自分で作っているし、ユーザーがどういうものを求めているかもわかっているので、データベース設計ももうだいたいできているし、どういう画面ブローかもかなり想像がついていた。
このまま作って、あとはもう実際のプロダクトでファネルのKPIを計測するほうが、実際にユーザーが自分の意図どおり動くのか、いい検証になるんじゃないかと考えました。
まぁ、フリーザ状態ですね。「ここからは俺の仕事だ！ やってやるぜ！」みたいな。すいません（笑）。
たくさんつくりたくなってしまう問題
実際にここからサービスを作るんですけど、ここでやっちゃった失敗としては、ありがちだと思うんですけど、本当にたくさん作りたくなっちゃうんですね。今まではこういうものを作ろうと思ってて、To-Beをすごく意識していたのが、As-Isをちゃんと見てなかったことにもここでようやく気づきます。
自分の考えが形になってくるので、すごくうれしくなっちゃうんですよ。画面になってくるとなにかギミックを足したくなるし、「ここってこういうインタラクションあったほうがいいんじゃない？」とか、細部にこだわるようになっちゃう。
「それって、実際にKPIに落とすとぜんぜん関係ないことやってるんじゃないの？」みたいなことになってきて、スケジュールが押してしまうようなことが初期の段階であったので、ここでかなり『アジャイルサムライ』を読んで、アジャイルを導入しました。
まずFeature Listを作って、目的を確実に決める。それに対するリリース日を決めて、Velocity、自分でどれだけ関わるかを計測して「1週間で積めるVelocity は10ぐらいだよね」というような数字を決める。これを1週間イテレーションでやることにしました。
To-Beを意識しててAs-Isがわからなくなっていたことについて、もうちょっと詳しく。実際にCS作業してて、ユーザーと話したり電話すると「これ誰がいつ使うんだっけ？」みたいなことがあると、ファネルのKPIが思ったとおりに動いていなかったりする。
入ってきてくれたユーザーって、みんなすごく大切に思えちゃって、手厚くフォローしたくなっちゃうんですけど、それってCSのコストをかなり圧迫して「これ誰のためにやっているんだっけ？」とか「いつ使うんだっけ？」という、かなり曖昧な状態になってしまいます。
そこで僕たちはこの段階で、ペルソナをかなり具体的に書くようにアップデートしました。それに伴って、ユーザーの1週間のAs-Isのカスタマージャーニーを再調査して、みんなどこでどういう行動してるのかというタッチポイントの洗い出しに近いことをやりました
ペルソナを詳細にすることによって、CSの工数を減らせたことがまず大きかったです。「この人はユーザーじゃないから、サービスインしてくれたのはすごいうれしいけど、工数を割かない」とか「この人はかなり対象だから、ちゃんとフォローしてインタビューまで設定してがんばってみよう」とか、そういうことをやりました。
As-Isを理解すると、ユーザーが使えるタイミングやシーンがかなり明らかになってくるので、正しいタッチポイントとソリューションを考察できて、今、実装中という感じです。
今は新しいものをやっていて、E2E、End to Endのテストを書いてます。テストを書かないでやっているのでバグをめちゃくちゃ出しているんですけど、まぁ、スタートアップのありがちなところかなと思います。
デッドラインを決めて進めるべし
まとめとしましては、必ずデッドラインを決めてやったほうがいいということですね。いろいろやったんですが、かなり思考してしまえば深みまでいけるし、なんでも考えられちゃうんですけど、期限を決めてやることがある種、一定の選択と集中になります。
取捨選択できるタイミングを自動的に作らなくちゃいけないので、いつまでにコンセプト設計を終わらせて、いつまでにインタビューを終わらせて、いつまでにリリースする。いつまでに検証を終わらせて、それを磨くのかスクラップにするのか判断する、そういうデッドラインを確実に決めたほうがいいです。
最後におまけ話ですが、最初にプロトタイプを作るのが好きだって言ったんですけど、「東京プロトタイパー」という勉強会を作ろうと思ってまして（笑）。
みんなで自分で作ったものを交流して技術力を上げていく勉強会をしようと思ってます。毎月、月初にやろうと考えていて、来月が第1回目なので、もし興味がある方がいましたらぜひ参加してください。以上です。
（会場拍手）
