読者です 読者をやめる 読者になる 読者になる

カタパルト式!スープレックス!!

クールなものだけメディア!(クラフトビール・スタートアップ・音楽・デザイン)

グロースハックやリーンスタートアップの本質!バインドリーの開発から得た学びだよ!

アプリ デザイン グロースハック 開発

 おかげさまでビジュアルノートアプリのバインドリーが日本語が使えるようになりました!さらにビジュアルノートをシェアできるようになりました。本来ならこのバイドリーについて大々的に宣伝したいところなのですが、今回はバインドリーを作る過程で得たリーンスタートアップやグロースハックの学びを共有します。

 ダッシュモートのインタビューでも創業者のデニス・タンさんが言っていましたが、スタートアップって助け合いなんです。何か得るものがあったら、コミュニティーに還元する。それがスタートアップの素晴らしさだとボクも信じています。

 ボクがバインドリーを作ることで学んだことがこれからアプリを作る人の参考になったらいいなと思います。

f:id:kazuya_nakamura:20160829040842j:plain

 まずはプロダクトを出すことが大事

 バインドリーをリリースするのに実は一年半くらいかかりました。これは今考えると大きな反省点です。機能を限定したMVPを半年くらいで出すべきでした。単機能のやりたいことに絞った製品。これをベータではなく製品としてリリースすべきでした。アプリということにこだわってしまったのですが、今考えればWebでも良かったと思います。どのような形であろうとまずはプロダクトとして出す。これが大事です。

なぜプロダクトとして出すことが大事なのか?

 それは数字を使って改善することができるからです。これはビジネス面でもそうですし、開発面でもそうです。

 ボクの場合は外部の開発もコンサルティングとして受けているからよくわかるのですが、多くの人は最初から完璧なものを作ろうとしすぎです。夢の製品が500%位だとしたら、自分持つお金や時間を鑑みてが現実的に作れるのが100%になります。ここでまず最初の妥協になります。

 でも100%もダメです。そこでボクがバインドリーで目指したのがさらに妥協した80%のMVPだったのですが、これでも機能を詰め込みすぎでした。今から考えると本当にコアとなる機能をどんなに見た目が悪くても30%くらいで出すべきでした。

 え?そんなの出せない!と思うかもしれません。恥ずかしいよ!と感じるかもしれません。でも、それは自意識過剰というものです。ご安心ください。世間は自分が考えるほど注目なんてしてくれません。

f:id:kazuya_nakamura:20160830211931p:plain

 最初のリリースは30%だとして、そこからアップデートしながら改善していき100%を目指していきます。

ビジネス面の数値化

 まずはビジネス面から。例えばバインドリーの場合はDAU(1日の利用者数)と1日に作られたビジュアルノートの数(# of note created by DAU)が一番大事な数値指標です。これをKibanaElasticsearchを使ったダッシュボードで管理しています。

 7月に最初のバージョンを出した後、Product Huntにも掲載されてDAUはそれほど悪くない出だしでした。ただ、1日に作られるノートの数が少ない。このままノートが作られないとDAUは減少していくのは明らかです。つまり、今回のバージョンではノートを作りやすいUXに変えないといけませんでした。

 フィードバックとして一番多かったのが「インストールした後に何をしていいのかがわからない」でした。開発側からするとFacebookやInstagramといったアプリとつなげてくれればあとは勝手にノートを作ってくれるので便利ですよ!と考えていました。

 ノートを作るのって能動的な行為ですが、バインドリーは受動的なノート作成ですね。でも、ユーザーの感覚は違っていた。受動的なアプリは単に何をやっていいのかわからないアプリだった。そこでカメラをメインのCTAとすることにしました。新しいバージョンではカメラボタンの色を変えただけですが、次はもっと変わります。

 次に多いフィードバックは「シェアしたい」でした。え?シェアするんだったらFacebookでもTwitterでもたくさんあるし、チャットアプリでもいいじゃないの?と思ってあえてつけていなかった機能です。しかし、実際にシェア機能を作ってみると確かに便利なんですね。プライベートでシェアできるし、待ち合わせの時に写真と位置情報を同時に送れるし。

f:id:kazuya_nakamura:20160830211849p:plain

 製品を出した後と前では完成系のイメージが全く違う。でも、今なら簡単に方向修正ができる。このフィードバックとダッシュボードで管理している数字を使って完成度を30から40、50に持っていくわけです。グロースハックとかリーンスタートアップの真髄ってここだと思います。

開発面の数値化

 キレイなコードよりとにかく動くコードが正しいです。まずは動く!動かしてから具合の悪いところを直す。どんなにアーキテクチャを考えたって、結局ビジネスの要望は変わるんです。先を読んで作ってもあまり意味がない。それより動くものを作ってデータからやるべきことを導き出したほうがいい。

監視ツール

 バックエンドはNode.jsなのですが、最初はボロボロでした。全く安定しない。テストコードもない。といっても、最初はあまりコードの品質とか気にしないほうがいいです。必要な機能がゴロッと変ったりして、テスト要件が安定しない。そこで、まずは動き続けてもらうことに焦点を当てました。神様にお祈りしても落ちるものは落ちるので、頑張って安定したシステムを作ります。サービス監視ですね。

 無償のトライアル期間を使って(!)TraceでバックエンドのメモリとCPUの消費を監視して、アップタイムを99%まで持って行きました。Traceの無償期間が終わってしまったので、今はGrafanaを使った自前の監視ツールを使っています(ごめんね!でもTraceはいいツールなんで広告収入が入ったらぜひ使わせてね!)。

 そういうわけで、アップタイムは今の所99.9%です。

静的コード解析とプロファイリング(バックエンド)

 パフォーマンスもめちゃくちゃ悪くてメモリーリークも大量に発生していました。静的コード解析のSonarQubeInferやプロファイルツールのFlamegraphも合わせて使って、バックエンドの最終的なメモリー消費量は半分以下に減らしました。

 これがベストかといえばそうでもないと思うのですが、低スペックなサーバーでも大丈夫になりました。大事なのは可視化をして数値的なゴールを持つことです。動くこと、動き続けることが正義!

プロファイリング(フロントエンド)

  フロントエンドに関してはビジネス優先順位の変更に伴って機能の優先順位も変更になりました。最初はオフラインファーストにしようと思ってたんですよ。オフラインでノートを作れる方が便利だろうと。Evernoteもオフラインで使っていたし。ただ、これにはアーキテクチャの根本的な見直しが必要でした。どうせアーキテクチャを変えるのだから、フロントのパフォーマンスは目をつむってしまおう!という判断。割り切り大事!

 それが製品を出した後にオフラインの重要性は下がって、むしろパフォーマンスの優先順位が上がった。カメラをメインのCTAにするなら起動は早くないといけない。そうすればカメラを使ってノートをもっと作ってくれるという仮説。ほらね?100%の姿なんて簡単に変わるんですよ。いや、むしろ変わらないといけない。

 フィードバックとしてやはり多かったのが「立ち上げが遅い」でした。じゃあ、どれくらいが「早い」なの?というのでやはり数値的な指標が必要となります。それを測るのがNimbleDroidです。このツールはFrame Graphのようにプロファイルをとって、立ち上げのどこに時間がかかっているのかを可視化してくれます。

 最初のバージョン(1.0.0)では起動に7.2秒かかっていたのですが、最新のバージョン(2.0.3)では1秒台になりました。Facebookと同じくらい。Twitterより優秀です。Google Play Store内のアプリの起動平均よりだいぶ短いはずです。これくらい起動時間を短くできればカメラをメインのCTAとして使える余地が出てくる。

UX

 カメラをメインのCTAにした場合、実際に何クリックが必要なのかを数えてみることも重要です。手前味噌ですが、サービスジオラマはUXのデザインにとても役に立ちます。ユーザーがやりたいことを何タップでできるのかを数えるのはとてもいいですよ。

 例えばInstagramはカメラを立ち上げて写真を撮るのに2タップ必要です。ところが、Snapchatは1タップしか必要ありません。Slackはユーザーを招待するのに2クリックですが、今ひとつパッとしないHipchatは前数えた時は4クリックでした。今はSlackと同じ2クリックですけどね。

 ただ、最初は何がメインのCTAになるのかよくわからないです。最初にリリースした時にカメラをメインのCTAにするなんて思ってませんでしたから!

 ですから、最初のバージョンはあまりデザインしすぎないほうがいいです。デザインすればするほどリリースが遅くなります。

 下は例になります。今回のバージョンからシェアできるようになりました。このシェアページもだいぶ素っ気ないですよね?リリースしておいてこんなことを言うのはなんですが。アプリは日本語なのにシェアページは英語しかないし。おかしいじゃないか!と思う人はここまで書いて伝えたいことがまだわかっていません。早く出すことが大事なんです。それがスタートアップでの正義。

 これは最初のバージョンだからまずはそのまま出しています。これが30%です。ここからヒートマップとか色々使って何が必要なのかをデータで理解していくわけです。次のリリースから徐々にデザインしていく予定です。

リーンスタートアップやグロースハックとは結局何なのか?

 リーンスタートアップやグロースハックというのは自分で実践して思うことは「30%くらいの製品を早く出して、数値を管理しながら40、50と改善していく」ということなんだと思います。そして、一番大事なのは30%でまず出してみる。これです。MVPってなに?とよく言われますが。自分の考える機能の30%くらいのものと考えておけば感覚的にいいかなと。

 100%でだそうとするのは愚の骨頂です。100%を目指す人はまずスケジュール通りに行きません。必ず遅れます。外部コンサルをしていて多いのはこのパターンです。80%を目指していいのは大企業だけ。それでも失敗した時に80%を回収しないといけないのです。これって大変だと思いませんか?30%だったら失敗しても傷は小さい。数値で測定すれば学びもある。

 バインドリーを開発する過程で得た学びはもっとたくさんあるのですが、長くなったのでまずはここまで!

 バインドリーはどんどん進化していくアプリですので、応援してね!

ここで紹介したツール