エンジニアがサービス作りで見失いがちなこと
株式会社キネカCTOの竹口です。リーン開発時に、エンジニアだからこそハマりやすい落とし穴について、経験を交えて書いていきたいと思います。
私は以前の記事「創業1年目のスタートアップがIonicを採用した方が良い5つの理由」の自己紹介で書いた通り、DeNA時代に数十の新規事業が立ち上がり死んでいく環境の中で、リーン開発のノウハウを叩き込まれました。また、キネカを創業してから二つのアプリを立ち上げ、現状どちらもPMF（Product Market Fit）に達しつつあります。
DeNA時代とキネカでの経験から、どのようなサービスがもっともスピード感を持って仮説検証ができているのかが見えてきたように感じています。
本記事が日本全体のスタートアップの速度を高められるような記事になれば幸いです。
前提
今回の記事は問題解決型のサービス（主にブルーオーシャンな市場に当てたサービス開発）について当てはまるものです。現在レッドオーシャンな市場を見ているなら読まないほうが良いでしょう。例えばpaypayのようなサービスはPMFされたプロダクトがほぼが決まっていて、リーンに開発する必要がなく即座にグロースフェーズに入ります。全く性質が異なります。0->1を考える場合なんでもリーンにやればいいのではなく、ドメインにあったフレームワークを採用するべきです。
エンジニアリングは手段という割り切りが大事
サービスのコアバリューを検証する上で、エンジニアリングが必要不可欠であり、モノがないと始まらないように思っている人が多いように感じます。しかしこれは必ずしも正しくありません。
エンジニアリングしなくてもリーン検証は始めることができます。サービスを開始する上でここ数年の流行りがweb・アプリであったり、それらがチャネルとして優秀だからこそweb・アプリ化するのであって、その選択肢は手段でしかありません。
特にリーンに検証を進めるのであれば、初期検証フェーズではアプリを作成する、というのはリソースを多く消費しやすいため、慎重になるべきです。最小工数で最速で検証可能な方法がないか議論するほうが良いでしょう。
特にエンジニアを学んできた人が創業者であったり、最初期フェーズなスタートアップに入ったりすると、今まで培ってきたエンジニアリングを利用したくなるのが心情です。常に0ベースでそれが本当に必要なのか？検討する時間を作るほうが良いでしょう。
エンジニアはなるべく開発しないように意識する
仮説検証において、web・アプリ以外の選択を与えられるかどうかが、エンジニアの価値の一つだと思います。逆説的ですが、エンジニアは自分がいかにエンジニアリングする時間を減らせるか、というマインドを持っておくとスタートアップにおいてスピードが出しやすいです。
ここで最も大切なのがチームメンバーの理解です。一般的にエンジニアがエンジニアリングをなるべくしないような思考で物事を考えて提案すると「ラクしたいから実装しない」と思われることがしばしばあります。信頼関係が高ければ問題ありませんが、まずこの思考を理解してもらうことが大切です。
解決しようとしている問題を正確に捉える
How to Get Startup Ideas（日本語訳@yamotty）に詳しく書いてある通り、問題を正しく捉えることは成功の確度を大きく増大させます。
スタートアップにとって最も重大な過ちは、どこにも存在しない問題を解こうとすることである。How to Get Startup Ideasには二つの例が載っています。「オンラインアートギャラリー」と「ペット所有者向けのソーシャルネットワーク」です。どちらも失敗したと書いてありますが、それを事前に知ることはとても困難です。困難にしている理由は「もっともらしく聞こえる悪い着想が生み出されてしまうから」です。この着想が生まれる状況としては、チーム内で閉じた議論をしている場合に起こりがちです。
この状況を防ぐために、私は経験上二つのことを意識的に行なっています。
一つ目は最初期ユーザーとの対話です。ここでいうユーザーというのはサービスがリリースされていなくても良いです。最初期ユーザーになりうる身近な人のことです。新たな視点を取り入れて、0ベースで考える時間を作ることで、誤った着想と視点に気付きやすくなります。これを定期的に行なって、何度も仮説を崩しては立てていく。この作業を繰り返すほど正しい問題にたどり着く可能性が高まります。
二つ目は解決したい問題がSNS上やオフライン、アナログな方法で無理矢理にでも解決されている場所はないか調査することです。例えば、最近はパパ活アプリが話題となっていますが、パパ活という行動は主にTwitter上で数年前から行われていました。どうにか世の中にあるサービスの中で達成しようとして考え抜いた結果の行動であり、そうまでして達成したい行動なのです。もし解決したい問題がこのような形で世の中に存在しているのであれば、正しい問題の可能性が高まります。さらに、その行動を行なっている人はまさに最初期ユーザーそのものです。ヒアリングできたら最高ですね。
サービスリリース直後の課題
問題が正しく捉えられたら、次はその問題の解決方法を模索します。ここではその解決策がアプリリリースだとします。webサイトのリリースでも同じですが、リリース直後はマインド的に多くの落とし穴があります。
目に見えやすいバグを修正したくなる
リリース直後に陥りやすいのが、小さい穴の修正に時間をかけてしまって、そもそも検証したいことを忘れてしまうことです。アプリをリリースすると離れていくユーザーがどうしても目についてしまいます。その結果、どうしたらそのユーザーをリテンションさせられるのかを中心に考えてしまう。これは初期フェーズでは不要な時間です。
アプリがどれだけ使いにくくても良いです。本当にそのアプリを必要としているユーザーであれば、使いにくいところを乗り越えてでも使ってくれます。
エンジニアは作った自分がバグを生んだことに引け目を感じやすく、その修正に時間を取りたいという思いが強くなりがちです。この点も、チームの理解が重要となります。目に見えるバグを放置するのは慣れないとかなりの違和感があります。しかし、コアバリューの検証とは無関係なバグを修正している時間を削ることが大きなスピードを生みます。
コアバリューの検証にのみ目を向ける
真に考えるべきはコアバリューに届いているユーザーの有無と、そのユーザーの行動と思考です。
コアバリューに届いているユーザーがいない場合、そのプロダクトはMVPではない可能性が高いです。ユーザーに使って欲しい機能のみ、コアバリューのみに絞ったアプリにするべきです。
コアバリューに届いているユーザーがいる場合、そのユーザーの一挙手一投足に目を向けて、可能な限りユーザーと対話します。定性的な意見から、アプリの方向性を変えうる大きく破壊的な施策を検討し、それにのみ時間を使うように心がけましょう。
最初期ユーザーとの繋がりがサービスの成功を決める
最初期ユーザーと直接会ってヒアリングするとき、自分たちの熱量をぶつけて「一緒にサービスを作っていくんだ！」というマインドセットにできるかが勝負です。
最初期ユーザーとコミュニティを作り、そのコミュニティを醸成し成長させること、これがサービスを作るという言葉の本質だと思っています。
私が過去に経験したサービスの中で、成功したサービスは全てこの条件に当てはまっています。エンタメマッチングアプリpatoやSHOWROOMはまさにこれに当てはまります。
弊社サービスであるpatoの場合、キャストとの繋がり、ゲストとの繋がりをとても大切にしています。そのため社内にコミュニティマネージャーチームがあり、ユーザーとの接点を強めるチームがあります。このチームは運営とユーザーを繫げる役割を持っており、ユーザーの定性的な意見やフィードバックを常に感度高く発見します。その結果、アプリの改修や新機能にユーザーの意思が入りやすく確度の高い施策を多く打てるようになります。
0->1のフェーズは定量ではなく定性を大切にするべきですが、その定性的な意見をどれだけ多くキャッチできるかが、PMFへの道のりの最短距離だと考えています。
エンジニアはこのコミュニティに関して無関心になることが多いです。なぜなら、チームの中で最もユーザーとの距離が遠くなる役割だからです。しかし、アプリを作っているのはエンジニア。このギャップを埋めることがサービスを作る上で肝心であり、多くのエンジニアができていない部分なように感じます。
まとめ
今回はサービスを立ち上げるに当たって、エンジニアだからこそ陥りやすい思考やマインドについて書きました。これらは全て私が経験してきたことであったり、落とし穴にハマっているチームを目で見てきた経験です。自戒の念を含めて、この記事にまとめていきました。
最後に
サービス作りが大好きなエンジニアを大募集しています！一緒に世界を変えるサービスを作ってみたい方はTwitterでDMください！お待ちしております。
