VOYAGE GROUPのTreasureに参加しました
またお久しぶりになってしまいました、じゅぎのんです。
8月上旬は授業が佳境に入り、テストがあったり提出物があったりで忙しく、研究も実験をちょっとだけやったりと忙しい日々が続いていました。
そんな8月下旬、ついにVOYAGE GROUPの夏のインターンであるTreasureが始まり、二週間+αの戦いの末無事生還して戻ってきたので、今日はその報告をしようかなと思います。
Treasureとは？
このブログを見ている人は大体みんな知ってそうなので特にかしこまって書く必要があるかは分かりませんが。。
Treasureとは、VOYAGE GROUPって会社が開催してる夏のインターンシップのことです。去年のレポートとか会社ブログ、そしてすでに今年の参加報告もちらほら上がってきているので、是非そちらも確認してみてください（きっと僕なんかよりいい文章書いてる）
うちのチームにいた人事のなみさんのテックブログ
今年、共にTreasureに参加した人たち
https://blog.takurinton.com/17
昨年のTreasureに参加した人たち（TAとして今年参加していただいてる人もいます）
今年は例に漏れずコロナウイルスの影響ですべてオンラインで、8/1, 8, 15の土曜日と8/17~28の計13日間（表記上は）の開催となりました。
去年までのTreasureのレポートをみて「オフィスきれいそうだし、お酒もタダで飲めるし、お菓子も食べ放題みたいでいいな〜」と思っていたので、そこがなかったのは少し（かなり）残念でした。。
でも、前回の記事でも書いた通り自分は普通だったらこの時期部活の大会・練習でこんなに時間がとれていなかったはずなので、このインターンに参加できただけで嬉しかったです。
あ、お菓子に関しては安心してください（？）、今も食べ切れていないほどのお菓子他の詰め合わせが段ボール二箱分配送されてきました。
そんなわけで、お菓子も気持ちも用意完了！いざTreasureへ :muscle:
前半戦（講義）
8/1, 8, 15、そして8/17はVOYAGE GROUPの方がフロント・バック・DB・インフラ・アイデアについて講義をしてくれました。
フロントエンドはJavaScriptの歴史からJSのtips（function関数とarrow関数の違いとか、bindについてとか）を学びました。
意外とずっと書いてきたのに知らなかったこととかがあって、フロントエンド講義も学びが多くあったなぁと感じます。
バックエンドはTreasure-voiceという1対1の通話サービス的なものを作りながらGolangを学びました。
Repository, Service, Controllerの役割やAPIのエンドポイント設計、WebSocket、WebRTCなどバックエンド経験ほぼ皆無な自分にとってはすべてが初めて聞く単語で、完全にコンフォートゾーンから外れた状態（むしろ体半分パニックゾーンに入ってる）でしたが、TAのらぴおさんが講義のあとに1対1で画面共有をしながら丁寧に教えてくださり僕は感涙にむせび泣きました。本当にありがとうございました…！
DB講義では実際にdbdiagramというDB設計ツールを使いながら、発表されたチームごとに実際の運用のことを考えながらDB設計をしていきました。
DBも僕にとっては初めての領域で、わからないながらも設計に関しては自分の考えをもって発言することができたんじゃないかなぁと思います。
インフラ講義では、今回チーム開発時にベースとなるTreasure-appのインフラ周りの部分についての解説を聞きました。
正直ここはまだあまり理解できてない…（しょうたさん、ともかつさんすみません）AWSむずすぎです。解説スライドをいただいたので、がっしりと読み返して学んでいこうと思っています。
最後にアイデア講義。僕たちのチーム開発は後述するようにアイデア出しでありえん時間がかかったので、今回のインターンで一番学びになったと言っても過言でもないのはアイデア講義で得たことでした。
フロントエンド・バックエンド共にわからないことがあったときは補講を開催してくださったり、個別に質問を受け付けていただけてとてもやりやすい環境でした。
ヤンウェイさん、バックエンドがわからなさすぎて初心者みたいな質問ばっかしてすみませんでした。僕もっと強くなります。
後半戦（チーム開発）
決起！
講義が無事に終わると、ついにチーム開発がスタートします。今回のTreasure参加者数は全部で24名、4名×6チームに別れてアイデア出しから始まります。
僕は大学院のテストの関係でチーム発表の場に居合わせることができませんでしたが、チーム名が無事ヱビスと決まり、サポーターさんにれぞさん、ちゅうこさん、なみさんがついてくれました。
チーム名の由来は「時間がなくなったからみんなの共通点ぱっと出したときにみんなヱビスビールが好きだったから」だそうです。
ごめん、僕お酒そんなに好きなわけじゃないんだ…
無事にチームが発表になった日の夜は決起会という名の飲み会がありました。
今回のインターンで得たいことを各々語り、チームとしてはこんな感じの目標が立ちました。
- DevopsとかCI/CDに興味があるから、テストを頑張りたい
- Treasure期間で作り終わってはいおしまい、じゃなくて、その先も作っていけるようなものが作りたい
- UI/UXに興味があるから、できればデザインも頑張りたい（僕）
- とりたい賞はいっぱいあるけど、やっぱりグランプリを目指したい
目標は高く、グランプリを目指せるような、将来性のあるサービス。
それを目指すためにみんなで決めたことは、「妥協しない」ことでした。きっとこの"妥協しない"があったからこそ、今回いいサービスが作れたんじゃないかなと思います。
そして、地獄みたいなアイデア出しが始まります。
アイデア出し前半
まず、僕たちヱビスチームのいっっちばん最初の目標日程を見てみましょう。
そして、次に23日（チーム開発残り5日）に変更された目標日程を見てみましょう。
おかしいなぁ…8/23までの4日間が消滅しているのはなぜだ…？
はい、アイデア出しで計4日間かかりました。今改めて最初の目標をみると鼻で笑えますね。
去年のレポートとかみても、どこにも「アイデア出しがつらかった」と書かれていないのでみんな記憶をどこかに置いていってしまったのでしょうか？
僕は絶対に忘れたくないし、多くの学びがこの4日間にはあったのでアイデア出しがどれだけ大変だったかをレポートしちゃいます。
アイデア出しと言っても、どうすれば価値のあるアイデアが出せるのか？ ただ単純に自分たちが使いたいから作る、というだけでは価値のあるプロダクトにはならないとアイデア講師のわーみーさんから教えられ、こんな手順でアイデアを出していくのがいいと言われました。
最近、社会に起きている「時流」を書き出す
ディスカッションをしながら内容を整理する
考える領域（市場）を決める
決めた市場にいるプレイヤーを書き出す
決めた市場と組み合わせて、面白いプロダクト案が思いつきやすそうな時流を選ぶ
選んだ時流に対して、今後発生していきそうな事象を書き出していく
実際に具体的なアイデアを考えていく
文字にすると簡単なんですけどね、これエゲツなく難しいんですよ。
まず時流がわからん。え、運動不足の人が増えたのは時流じゃないの？外出が減ったことも時流じゃないの？
どんなに自分で「これが時流だろう」と思ったことを書いても、「じゃあこれは何が原因で起こったの？」と言われる。
なんやかんやしながらも捻り出した時流たちがこれ。
時流を出したら、次は市場選び。「チーム開発なら自分がユーザーになれそうだし、意見もいっぱい出そうだからチーム開発を選んでみよう」
…え、ちょっとまってなんか全然アイデア出てこないんだけど
まず出てきたアイデア全然チーム開発関係ないし…（今振り返ると） 社会のゆらぎに「電子書籍が増えた」っていうちょっと意味不明なゆらぎを選んでみたことで面白いアイデアがでるかも、と期待したものの、意味不明なアイデアを量産する始末。
ちなみに先に言っておくと、全部でこのサイクルを3回やりました。
「やっぱり時流が足りないからゆらぎがでないんじゃない？」「じゃあちょっと一番最初に戻って時流考え直してようか」
これを3回。最初に見せた時流は完成形で、それまではもっと雑な時流が並んでいました。
市場選びもコロコロ変えながら、だんだんと「市場はオンライン趣味教室が良さそう」というところに落ち着いてきました。
アイデア出し後半
オンライン趣味教室に市場を決定した。そこまでは比較的スムーズに進みました。でも地獄はここからでした。
市場が決まってから実際にアイデアを出していき、「SNS上の有名人になにかを教えてもらうときって、聞くのはレベルが高すぎるよね」という話から、だんだんと質問箱のような質問サービスを作ろうか、という流れになります。
このときはまだアイデア出しは1日で終わらせなきゃいけない、早く実装を始めないと置いていかれるという焦りがあり、あまりアイデアとしてのまとまりがないまま決定しようとしていました（今振り返ると）
そしてなみさんから言われます。「ちょっと席外してて今までの流れわからなかったから、説明してもらってもいい？」
（えっと…なんでこういうアイデアになったんだっけ…）
サービスを使うユーザーは具体的にどんな人で、その具体的な人はどんな課題や欲求を持っていて、それに対してどんな解決をするのか。
それをちゃんと言えない限りはいいアイデアとは言えないし、このまま進んでも開発の途中で疑問が出てくる。ここから地獄のような「「「深掘り」」」が始まります。
アイデア講師のわーみーさんに相談。「ユーザーの抽象度が高すぎてポイントを絞れないんじゃないかな」ユーザーの抽象度ってなんやねん…
ユーザーを固定してみる。固定したはいいけどユーザーの抽象度がよくわかってないから固定できたのかわかんねえ…
これってシステムで解決できる問題なのか…？
ペルソナってどうやって出せばいいの…？
このままペルソナ一つづつやってたら時間溶けまくらない…？
亀のような進行度で議論が進み、だいぶみんなの頭が沸騰してたと思います。
答えに近づいていっているのかわからない、でも今更もどったら確実に時間がない、でもこれ以上アイデアが出ない。
わーみーさんの「あとほんのちょっとでいいアイデアが出そう」という言葉を信じて、自分はあとちょっと同じテーマでがんばりたいとみんなに伝えました。多分ここら辺がいちばんしんどかった。
全部立ち返るか、そのままのテーマで進むのかの選択はかなりの分岐点だったと思います。
そのままのテーマで進むことがきまり、具体的なペルソナを出すために身近な人にインタビューをし、改善点を探すもののシステムで改善できるような部分が見当たらない。
そこにれぞさんの「時間軸を変えて考えてみたらいいんじゃない？」という最強の言葉が投下され、今までの地獄が一変します。
まってなんかこれいけそう、みたいな雰囲気が流れ始めて、ついに、とうとう、満を辞して、アイデアが固まります。
ここまで丸4日。どれだけつらかったか、みなさんわかっていただけましたか？
コーディング開始！とはいかない
アイデアが無事出たら、うおおおおコード書くぞ！！！とはならないことはTreasure経験した皆さんならわかると思います。
ここにきて初めて、アイデアを固めることの大切さに気付きました。アイデアがフワフワしているとサービスに必要な機能が定まらないし、そのあとの設計に移れない。
僕たちは事前にばっこりとMVPを固めたことで設計にはそこまで時間をかけずに終わらせることができました。しかし、残された時間はあとたった3日。
妥協しないと決めたものの、時間内に終わらせるためには設計に優先順位をつけて最低限の実装を終わらせなければいけません。
頑張ればここまでいける、というラインを決めて、1日の目標を決めてコーディングに入りました。
爆速コーディング
実際にコードを書き始めてからは、チームメンバーがエゲツないスピードで開発を進めていきました。
外部サービスとの接続、credential管理、各画面とのつなぎ合わせ… 自分が小さなところで詰まっている間に、みんなが各自頑張ってくれました。
一番最後の最後までサービスとして成立するのか（最低限の機能が備わり、動く状態になるのか）が不透明だったものの、最終日前夜の深夜1時ごろにすべてがつながり、本番環境で動作した時は「マジですげえ…」としか言いようがなかったです。
結局最終日の朝6時までスタイルを当てたり実装が続き、なんとか見せられる形になって完成しました。1時間だけ寝て、発表資料を作って発表。
妥協せずに頑張ったかいがあり、無事にグランプリ・UI/UX賞・ニーズ賞というすべての目標を達成することができました。
Treasureで学んだこと
めちゃ長文になってすみません。ここからは個人的にTreasureに参加して、チーム開発を初めてしてみて勉強になったことを書いていきます。
「予定は往々にしてうまくいかないものなので」
これ最初に誰がいったのかもう覚えていないんですが、Treasure期間中に5回以上は言っていると思います。
最初のアイデア出しの日程もそう、設計の段階もそう、予定はつくったところで基本的には延びることになる。
その中でも本当に大切にしなきゃいけないものはなんなのか全体で共有しておかないと、すべてがうまくいかなくなる。
戻ることを提案する勇気
アイデア出しを始めて2日目、チーム内に「早くアイデアを決めないといけない」という焦りのある中で、まとまりのないアイデアに対して一旦考え直すことを提案できたことはとてもよかったなと思っています。
そして、今までやってきたことを自分の一声で無に返すのではないかという恐怖がそこにはあること、それでも戻ることが提案できればさらによいアイデアが出せることがわかりました。
チームメンバーに本音で話そう、とここで思えたのもよかったです。
フロントだから、バックエンドのコードは見なくていいわけじゃない
今までフロントエンドエンジニアと自分で名乗ってきたけど、今回Treasureに参加して、フロントエンドはバックエンドがわかった上でこだわれる領域なんだということがわかりました。
APIを叩いてうまくいかないとき、データをバックエンド側に送ったとき、DBやバックエンドのコードを読むことは避けられません。
今までサーバーレスのシステムばっかり触ってきた自分にとっては、このプログラミング初心者みたいな気付きをやっとできました。
人をいい意味で待たずにどんどん自分から実装していく、そんな姿勢を持っているチームメンバーを見てとても意識が高まりました。
チーム開発では指示待ち人間にならない
「指示待ち人間になるなァ！」って中学校の部活でよく言われていたんですが、チーム開発でもそうだと感じました。
APIがバックエンド側でできておらず、データが取れない状態だったとしてもフロントエンド側で理想のデータを作って表示させることくらいはできる。
個人個人が最速の動きができていれば、時間がなくても実装はできるんだなぁと感じました。
自分の得意な領域
開発の面ではチームメンバーがすごくてあまり自分の得意というものが見つけられたかは曖昧ですが、「チームで開発をする」という点では、自分は他の人の意見を聞きながらもそれをまとめて自分で次に進もうとすることが得意なんだなと気づくことができました。
これはきっと誰しもが持っているものではないし、これにさらに技術力がつけば最強のエンジニアになれそう、と自分で勝手に思ってます。
みんなで一つのものに向かって全力で取り組むのはやっぱり楽しい
チーム開発の醍醐味ですね。僕は今までチーム開発と言えるものをやったことがなかったので、本当にいい経験になりました。
僕ももっと勉強して、みんなと肩を並べるくらいの技術力を持って、今回作ったサービスの続きを是非つくりたいと思っています。
総括
いかがだったでしょうか。他の方が書くようなレポートというよりかは感想文みたいな感じになってしまいましたが、この記事を見て少しでもTreasureに興味をもってくれたら、是非参加してみて欲しいです。
アイデア出しではとても苦労しましたが、その分得られるものがとっても多くて、この1ヶ月でだいぶ成長することができたと思っています。
あと、僕の周りには高い技術を持った同年代の人が少な（特に研究室にはいない）かったので、参加するだけで刺激になりました。チームメンバーのみんな、ついていくことしかできなくてごめん。
僕は学会や部活の大会があるため他のインターンシップには参加予定はないので比較することはできませんが、Treasureは得るものだらけの間違いなくおすすめのインターンです。チームメンバーのみんな、サポーターのみなさん、一緒にTreasureに参加してくれたみんな、ありがとう！これからも頑張ります！
