Voyage GroupのTreasureというインターンでは技術的な部分だけでなく、良いプロダクトを作る具体的なアイデア出しの手法やチーム開発のノウハウまで教えていただくことができます。
そして、僕個人としては何よりもこのプロダクトを作る具体的な手法を最初から最後まで体験できたということが一番の学びだったように感じます。
Treasureに参加した具体的な記事は以下をご覧ください。
アイデアを出す
時流に沿って考える
課題から考えるという手法がよくとられるのですが、時代の進歩とともにほとんどの課題が解決されてしまっていることが多くなってきて、課題ベースで考えることがどんどん難しくなってきました。
それに、よっぽど強烈な原体験がない限りありふれた課題しか思いつかないし、自分ごととして考えられないのでふわふわしたプロダクトになりがちです。
そんな中、今回のインターンでは時流に沿って考えるという手法を教えてくださいました。
具体的には、時流を洗い出しそれを元に解決できそうな問題を考えるというものです。
テクノロジーの変化によって10年前には解決できなかった問題が解決できるようになったり、時代の変化や考え方の変化によって5年前では流行らなかったものが流行るようになってきています。そこに注目しようぜって話です。
普段から解決できそうな課題を常に考えている人はあまりいませんが、時代の変化をほとんどの人は肌で感じているはずです。
この時流を洗い出してみて整理しなぜそれが最近流行っているのかまで考えると、アイデアがとても出しやすくなりました。
ユーザーとその課題を洗い出す
次に市場を一つ決めます。そして、その市場にいるプレイヤーを洗い出します。このときはふざけたものや大喜利的なものも出して全然okです。それが思わぬプロダクトを生み出すかもしれませんからね。
プレイヤーの洗い出しが終わったら、時流と照らし合わせてどこにニーズや課題があるのかを考えていきます。
時流を明確に考えているのとそうでないのでは明らかに出るアイディアの数が多くなりました。
チームでやるときは最初は自分だけで考えて、詰まってきたら他の人の意見を見るようにします。そのようにすることで特定の意見に引っ張られることがなく多様な意見を出すことができます。
いろんな意見が出るとそこから他の人の意見を参考にすることができて、さらにいい意見を出すことができました。
ソリューションを打ち出す
ここにきてやっとどんなプロダクトを作るかを検討していきます。
これまでにあげたUserとNeedsに対してSolutionを提案します。
ここまでは基本的に論理的に進めてきたのですが、正直Solutionを出すのはひらめきだそうです。
ジャストアイディアや大喜利でもいいから出してみることが大切でした。
もう一つ大切なことがあって、それはUNS（User, Needs, Solution）の全部が必ず揃っているということです。これが一つでもかけているプロダクトはカスです。（って先生は言ってました！）
仕様を考える
発散と収束
ここまでは、ずっとアイディアを出し続けてきました。アイディアを出すときはくだらないものでもどんどん出していくべきなのですが、議論が発散してばかりではいつまでたってもアイディアを絞ることができません。
そこで、ある程度意見がでて議論が煮詰まってきたら今度は意見を絞っていきます。このときは、論理的にこれまでに出てきた意見や案を検討して絞り込みます。
このときどうしても横道にそれて議論が発散しがちなのですが、そうならないように時間を決めたり議論を整理する人間が重要になってきます。
実際に僕たちがやったときはサポーターの方が議論がそれかけたときに軌道修正をしてくださったので、無駄な時間を過ごすことなく着実に議論を進めることができました。
サービスのコアの決定
具体的なソリューションが決まれば、そのサービスのコアなコンセプとを考えていきます。
本当にそのサービスのコアがユーザーの課題を解決しているのかを徹底的に考えることで、しっかりとした軸を作ることができます。
このコアをしっかりと定めチーム全員で共通意識を持っていることで、今後の開発の中で意見が別れて議論になったときに、「でも、このサービスのコアってこれだよね？それだとこっちの機能の方がよくない？ 」といった風に無駄な発散を避けたり誤った方向に進むことがなくなります。
ただ決めるといっても、「それって他のあのサービスでよくない？」とか「それって本当にニーズあるんだけ？」といったことに行き詰まることが多くとても大変でした。
ユーザーの対象が自分を含まない限りなかなか開発が難しいということもよくわかりました。
ユーザーの行動を考える
コアに沿ってユーザーの具体的な行動を検討していきます。そのときには付箋などを使って壁に貼りながら実際にどのような行動をするのかを並べていきます。
その行動の際に具体的などのような機能が必要なのかを書き出していきます。複数のユーザーがいる場合は全てのユーザーに対して検討します。
これはユーザーストーリマッピングという手法です。
実際にこの本に書いてある手法の一部を教えていただき実践しました。
この際に本当にその機能が必要なのかを十分に検討する必要があり、コアから外れた無駄な機能をつけようとしていないかを検討していく必要があります。
このときの判断基準としては、「あったらいい気がする」ものはつけないことです。「気がする」ものは一度ちゃんと検討してみて、論理的に考えて必要だから搭載するという進め方がおすすめです。
実際に僕たちも「気がする」といってしまうことが多くあったのですが、それをその都度検討することで無駄な議論や機能がなくなりました。
ワイヤーを書く
ここまできてやっとサービスを形にしていきます。といってもこの段階ではデザインは全く考えずに、先ほど洗い出した機能をどのように配置するのかを決めていきます。
この際には具体的なページのエンドポイントも決めてしまいます。意外とここが共通意識を持てなくて、あとで意見の入れ違いや混乱が起きたりしたので初期の時点で整理しておくと良さそうす。
エンドポイントを決めてしまうことでむしろわざわざ機能の説明を丁寧に書かなくても意思疎通ができるというのが大きかったです。
DBの設計
ここまで仕様が決まればデータモデリングをしていきます。
正規化してER図を書いていくという王道のやり方です。
気をつけるべきポイントとしては、UIに引っ張られた設計にしないことです。もし、実際に開発している段階でUIの変更が起きた際に破綻してしまうからです。
あくまで必要な機能から考えて実装していきます。
先に全部の設計を終わらせてしまえばMVP（後述）に反するのではないかとの議論もあったのですが、DBの設計は後から変更するのが困難なことが多いので先に実装してしまうことがbetterです。
実際にコーディング
スクラム開発
ここまできてやっと動くもを作っていける段階になります。今回はスクラム開発という手法をとりました。
スクラム開発では小さく動くもの（MVP）をどんどん作っていきます。何を作るかを決めて開発し振り返りをするという一つのサイクルをスプリントとよび、このスプリントをどんどん回していきます。
このやり方のメリットとして少しづつ動くものを作っていくことができるので、本当に動くかどうかわからない不安にかられながら開発を進めることがありませんし、メンバーとの認識の相違も早期に埋めることができます
最初は、一気に動くものを作ってしまいたい！と思っていたのですが、上記の理由から途中からスクラム開発にしてよかったと痛感しました。やっぱり現場で働いてる方の意見はしみますね、、笑
その甲斐あって僕たちのグループは開発体制を評価していただけました。
MVP
先ほども軽く説明したMVP（Minimum Viable Product）は動けばどんなものでもいいというわけではありません。
Viableとある通り、それだけでコアな機能をなしていなければいのです。本当に重要な機能から作って行いきます。
MVPが完成するたびにそのスプリントの振り返りをしていくので、スプリントを回せば回すほど開発効率が上がっていきます。
MVPを意識しなくて結果動かないというチームもあったのですが、僕たちはそのようなこともなく精神衛生的に余裕を持って開発できました。（もっともそのチームが技術的にめちゃくちゃチャレンジングなことをしていただけなのですがw）
まとめ
最初は半信半疑で効率悪そうというイメージがあったのですが、騙されたと思ってやってたら実際にはとても効率がよかったし、細部までブレることなくいいサービスを作れました。（完璧なサービスが作れたとは言ってないw）
人数が増えれば増えるほどチーム開発が大変になりますが、適格な開発体制を敷くことで人数が多いメリットを教授できるようになるんだと理解しました。
今回僕が学んだこのチーム開発の手法は一つのフレームワークにすぎないので、他のフレームワークも学んでそのチームにあった最適なものを選択できるようになりたいです！