1年かけたチーム開発での失敗と学び
Livesenseでプロダクト・エンジニアをしている山下です。
自分は個人開発が好きで、今までに個人（チームも含めて）でwebサービスを6つほどリリースしてきました。
その中でも、チームで1年かけて開発したwebサービスが、ほとんど使われることなく終了した経験が、その後の自分に大きな影響を与えました。
そこで今回は、このチーム開発で失敗したことと、そこから得た学びをまとめていこうと思います。
どんなサービスを作ったの
「旅行者と現地のガイドをマッチングさせる、ガイドマッチングサービス」を作っていました。
「海外に行きたいけど、知らない土地はちょっと不安」という人に向けて、現地でガイドを行なっている方を紹介することにより、不安を解消するといったサービスになっています。
作ってから1年ほどで、ほとんどアクセスがなくなり、サイト自体も閉じてしまいました。
どんなチーム？
ディレクター1人、エンジニア（兼デザイナー）2人、営業3人の6人チームでした。
大半がディレクターの先輩の友人で「海外旅行に行った際に、現地の友人にガイドをしてもらったらすごく楽しかった」という経験から、自分たちでもサービスを作ろうと声がけを行い、自分も参加しました。
当時、自分も新卒一年目で開発経験もそんなになく、他のメンバーも自分たちでプロダクトを1から作る経験はなかったので、今振り返ってみると失敗ばかりだった気がしています。
簡単に、どんな失敗だったのかと、そこから得た学びを、まとめておこうと思います。
作るものが終始ぼんやり、、、
ディレクターの先輩の「旅行版instagramを作りたい！」という声から、プロダクト作りは始まりました。
そこから企画のブラッシュアップを行い、提供する価値などを決めていたのですが、この過程をディレクター、エンジニアのみで行なってしまったため、うまく他のメンバーに共有することができていませんでした。
その結果、当初の「旅行版instagram」がベースにある営業陣と、ブラッシュアップしてでてきた「現地ガイドマッチングサービス」がベースにあるディレクター、エンジニア陣で、イメージがずれたまま企画が進んでしまいました。
どちらが提供すべき価値なのかがふわっとした状態で、お互いの要望を継ぎ足した結果、手戻りもたくさん発生し、作るべきプロダクトの全体像もメンバー間でずれてしまっていました。
ここから得た学びは以下です。
・最終ゴールは言語化して共有する
・チーム内で認識がずれていないか、確認を怠らない
これができていない状態で開発に入ってしまうと、あらぬ方向にプロダクトが進んでしまいます。
時間をかけてでも、ここは認識を揃えるべきです。
参考に、スクラム開発におけるインセプションデッキというものを紹介します。
インセプションデッキとは、開発を始める前に明らかにすべきことを網羅的に洗い出しているものです。
スクラム開発を用いないとしても、ここにある項目は非常に参考になるかと思います。
ユーザーの課題に目を向けられていなかった！
今回は「海外旅行に行った際に、現地のガイドに案内してもらった体験がすごくよかった」というのが起点でした。
「こんなのがあったら、きっとユーザーは使ってくれるだろう！」と信じたまま、ユーザーの課題を深く調べずにプロダクトの開発に乗り出してしまいました。
その結果、イベントなどで対象となるユーザーに直接アプローチすることができても、あまり使ってもらえませんでした。
このような進め方になった原因として、プロダクトの初期段階から使ってくれると見込みがあるユーザーが一定数いたということと、作っているものに（なぜか）絶対的な自信があったことがあげられるかと思います。
海外に住む知り合いも多く、ガイドに対して協力的であったことや、旅行系のインフルエンサーとの繋がりもあったことから、リリースしたら瞬く間に拡散され、たくさんの投稿が来るだろうと、信じて疑っていませんでした。
ここから得た学びは以下です。
・早い段階から、ユーザーからのフィードバックをもらう
・実際に使ってくれるというユーザーを初期の段階で集めておく
プロダクトを作るにあたって、たくさんの仮説を立てるかと思いますが、大体が外れるかと思います。
精度を高めるには、なんども仮説 -> 検証を繰り返す必要があるということを実感しました。
また、投稿系のサービスであれば、事前に投稿してくれる人を集めておくことも重要です。
魅力的なサービスを作っても、投稿がほとんどない状態であれば、ユーザーは何もせずに帰ってしまいます。（もちろん投稿もしません）
リリース前に、実際に投稿してくれる人を集めておくことも非常に重要な学びでした。
最初から機能盛り込みすぎ！
初めての1からのプロダクト作りだったということもあり、企画ミーティングではみな張り切って「こんな機能があったらよさそう！」や「ここも自動でできたらかっこいい！」などと、アイディアをたくさん出し合いました。
自分もなるべくみなさんの要望に答えようと、出てきた機能はほとんど実装しました。
その結果、振り返ってみると最初に集まってからリリースするまで1年弱かかってしまっていました。
終業後であったり、土日しか時間は取れなかったということもあるが、リリースまでに一年というのはリスクが大きすぎたかと思います。
幸い、自分も含めてみな本業とは別で関わっていたため、金銭的に失うものはほとんどないですが、かけた時間はどうしようもありません。
ここから得た学びは以下です。
・機能は最小限に抑えて、早くリリースする
・ユーザーからのフィードバックを元に、機能の優先度をつける
繰り返しになりますが、仮説 -> 検証を繰り返すことによって仮説の精度をあげていくためには、とにかく数をこなすことが重要です。
小さく、最小限のコストで検証を繰り返すべきでした。
また、不要な機能を作ってしまうコストを減らすことも重要ですが、必要な機能の漏れに気づけることも重要です。
リリースしてからのフィードバックで「投稿時に選択した画像の取り消し機能が欲しい」という声をいただき、このような機能を作ることを忘れていたことに気づきました。
良かったところ！
最後に、チーム開発を通してよかった学びも共有したいと思います。
最初にチーム構成を聞いて「比率おかしい！」と思った方もいるかと思いますが、僕たちは営業3人、エンジニア2人、ディレクター1人（営業出身）という過半数が営業というチーム構成でした。
さらに、エンジニアチームと営業陣では、年齢も5 ~ 6つほど離れており、（意識しないで接すれば）営業陣の方が強いような力関係でした。
にも関わらず、営業メンバーは開発を第一に考え、どんな些細なことでも過剰なくらい褒めてくださり、お互いを尊重しながら進めることができました。
これにより、1年間モチベーションを保ち続け、リリースまで持っていくことができたかと思います。
そのおかげで、楽しくプロダクト開発を行うことができました。
また、プロダクトを作るにあたり、市場の調査や協力者への依頼、旅行業を営むための資格取得など、営業の方がたくさん入ってくださったことによってできたこともたくさんありました。
これも、この構成だったからこそできたことかと思います。
開発に関しても、エンジニアが二人いたということもあり、技術選定や構成の幅が広がり、スムーズに開発を行うことができました。
当時お互い新卒だったこともあり、このような経験を積めたのは、非常にいい経験になったかと思います。
まとめ
最近個人開発系の記事が多く、取り組む人も多いような気がして非常に嬉しいなと思いつつ、チーム開発での記事はあまりないなと感じ、今回書かせていただきました。
うろ覚えのところが多く、今回書ききれなかった内容が多々あるので、興味ある方いらしたら個別で連絡ください！
自分も色々な方のお話し聞きたいので、ぜひ気軽にDMくださいー！