トコロテンの日記

自分の活動内容や普段考えていることをアウトプットするためのブログです。ITに関わる話がメインであり、開発、競技プログラミング、気に入った技術などの話が多くなります。

Treasure2020に参加してきた!

f:id:tokoroten_lab:20200806220543j:plain

はじめに

こんにちは。トコロテンです。

今年の8月にVOYAGE GROUPさんのTreasureというインターンに参加してきました。 インターンが終わった後にも忙しいイベントがたくさんあり、1ヶ月近く時間が経ってしまっていますが覚えている限り書いていこうと思います。

人生で初めてのインターンだったので参加が決まったときは嬉しさと「本当に自分はやっていけるのか」といった不安が半々くらいでした。 しかし、インターンが始まるとそんな不安は消し飛びました。 なぜなら、本気で頭を使っているとそんなことを考えている暇なんて無いからです。

「Treasureとは何か」といった問に僕が一言で答えるなら、「本気になれる営み」だったと思います。 いや、一言で答えるならですよ。 本当に一言で全てを表すことなんてまず無理です。 それほどに様々な要素があり、学びがあり、本気になれる機会がありました。

Treasureでやったこと

Treasureでは、大まかに分けて2つのことを行いました。

  • 講義
  • チーム開発

講義

講義は、以下の内容のものがありました。

  1. フロントエンド講義(JavaScript)
  2. バックエンド講義(Go, REST)
  3. バックエンド講義(Go, WebSocket, WebRTC)
  4. データベース講義(RDB)
  5. インフラ講義(AWS)
  6. イデア講義

全ての講義について講義課題がリアルタイムで出題され、それを解きながら理解を深めるといったものでした。 課題は、クイズ形式のもの、プログラムを実装してプルリクを出すもの、他者と議論して考えをまとめて全体で発表するものといった様々なものがありました。 講義内容も課題もしっかり聞いたり考えたりしなければ理解できないレベルの高さだったので常に頭がフル回転していました。

チーム開発

チーム開発では、自分含め4人のインターン生と3人のサポーターさんの7人チームになって主に以下の3つのことを行いました。

  1. イデア出し
  2. 設計&技術検証
  3. 実装

期間は以上の全ての工程を含めて大体2週間弱といったところでした。 正直「え、2週間あって4人で協力すれば僕たちが考えた最強のWebサービス余裕で作れちゃうんじゃね?まぁいけるっしょ笑」みたいな気持ちでした。 チーム開発が始まるまでは。 本当に浅はかな妄想でした。

チームについて

チームが発表されるとまずチーム名の決定をしました。 中々チーム名を決めたりするのが苦手なので共通点を探すといったことを行ったところ、全員お酒が好きといった共通点がありました。 僕は、特にエビスビールが好きだったので「ヱビス」という名前を提案したところ、無事チーム名は「ヱビス」に決まりました!🍺

そして、チームが決まった日の夜にチームメンバーと飲み会を行いました。 実は、この時ものすごくお腹が空いている状態でビールを飲んでいたのでとても眠くて殆ど記憶が残っていません😉

ただし、この日話した大事なことは記憶に残っています。 飲み会をしながら、チームでのスローガンのようなものと目標を語り合いました。 チームメンバー各々の目指すものは、以下のようなものがありました。

  • CI/CD等のDevOpsに力を入れたい
  • 発表のためだけの作品ではなく、継続して開発していけるようにしっかりと作りたい
  • フロントエンドでUI/UXに力を入れたい
  • 優勝したい

僕が掲げた目標は「優勝したい」といった目標でした。 「目標なんだから本気でやれるように大きな目標がいい」といった気持ちでこれを掲げました。 本当に単細胞だと思います。 しかし、チームメンバーもこの目標に賛同してくれてチーム全体でも優勝を目指すようになりました。

チームメンバーが各々の思いを語る中で「妥協したくない」といった旨のものが共通してありました。 そこで僕たちのチームのスローガンは、「妥協しない」に決定しました。 優勝を目指す上では必要不可欠だと思います。

イデア出し

チーム開発を行う中で圧倒的に難しかったのがアイデア出しです。 冗談抜きで人生の中で一番頭を使ったと思います。 チームメンバー間でアイデア出しの期間を「暗黒時代」と言って笑ったりもしましたが、本当にその通りだったと思います。

イデア出しの際には、以下のMiroというWebアプリを使っていました。 リアルタイムでメンバーとホワイトボードを共有することができます。

miro.com

僕は普段趣味で開発を行っています。 その際にはなんとなく自分がほしいものを作ってみて使いづらかったら改善するといったことをしています。 この場合、ペルソナが自分自身であることが殆どで課題が自分の中にあり、検証を1人で行うことができます。

しかし、Treasureで創るものは「ガチ」です。 アイデア出しは、フレームワークのようなものに則って行いました。 大まかなアイデア出しの手順は以下の通りです。

  1. 世の中の変化を捉えて「時流」をたくさん挙げる
  2. サービスを開発する領域である「市場」を決定する
  3. 選んだ市場に存在する「プレイヤー」をたくさん挙げる
  4. 選んだ市場と組み合わせて価値を生み出せそうな時流を複数個選ぶ
  5. 選んだ時流から今後起こりうる「社会のゆらぎ」をたくさん挙げる
  6. 以上の情報を基に「UNS」(ユーザー・ニーズ・ソリューション)をたくさん挙げる

以上の手順で実際にアイデアを出してみるとめっっっっっっっっっっっっっっっっっっちゃ難しいです。マジで。 ここで当時の僕のツイートを見てみると…

はい、ハゲるくらい難しかったです。 アイデア出しの日は、毎日シャワーを浴びる前に前髪を上げて生え際がどこまで後退しているか確認してました(実話)。

暗黒時代

最後のUNSが全然出て来ないんですよね。。。 UNSのユーザの抽象度が高すぎてニーズもそれに伴ってふわっとしたものになってしまっていました。 深堀りができていなかったために、イメージがしっかりと湧くアイデアが出せていませんでした。 こうなってしまうのには、多くの要因があったと思います。

例えば、手順1の時点で挙げた時流の抽象度が高すぎたり、何が原因で起こっている時流なのかといったことがわかっていなかったりといったことがありました。 なので手順1から手順6を全て終えた後にもう一度手順1の時流を考えるところをやり直しました。

他にも、手順4で面白いアイデアが出ることを期待して市場からかけ離れた時流を選んだはいいものの、本当に市場と全く合わなくて何もアイデアが出ないといったこともありました。

さらには、選んだ市場が問題でアイデアが出ないのではないかといったことも考え、一度市場ごと変えたりもしました。

焦燥感

何度も立ち返ってアイデア出しをやり直していくうちに本当に2週間アイデア出しだけで終わるんじゃないかと思う瞬間もありました。 アイデア出しが始まって最初の2日間は、早くアイデアを決めなければという焦りの気持ちがあり、今出ているアイデアだけで無理やり決めようとする場面もありました。

しかし、サポーターさんのツッコミにしっかりと答えられるレベルのアイデアではない点、チームの「妥協しない」というスローガンの下、無理やり決めずにもっと良いアイデアを探すことにしました。

再考

イデア講義の講師の方にアドバイスを頂き、ユーザーを固定してみたら良い、実際に存在する人にインタビューをしてみるといったことを実践してみるとユーザーの具体性が上がりました。 しかし、上記のことを実践してもまだ少しユーザーの抽象度が高いと感じていました。

ここでサポーターさんから「時間軸を考えてみると良い」といった旨の助言を頂き、これを実践してみると劇的に解像度が上がりました。 時間軸を意識することによって、ユーザーが困るタイミングや欲求のタイミングを考えられるようになって具体的なシチュエーションが思い浮かびました。

このあたりで「あ、これならいけるかもしれない」といった希望の光が見えてきました。

時間軸に沿って出したアイデアをさらに深堀り、ニーズを具体化、そのニーズを満たすソリューションを考え、「これならいける!」と思ったアイデアが出来上がりました。

ここまでで4日間かかりました。 4日間の間も本気で頭を使ってアイデア出しをするといった経験が人生で無かったため、本当に貴重な経験でした。

設計&技術検証

いざ実装!と行きたいところですが、アイデア出しが終わった状態では、必要なAPIやDBのスキーマ、画面構成等が何も決まっていない状態なのでまずはそこを決めていきます。

この設計をする際には、ユーザーがサービスを使う流れを考え、その流れの中に出てきた操作や動きを実現するために必要なAPIを生やしたりしていました。 普段の趣味の開発では、いつも以下の感じで生やすAPIが決まっていました😅

僕「この機能なんか欲しいなぁあああああ!?!?なあハム太郎!!!!お前もそう思うだろ!!!!???!!」

ハム太郎「そうなのだ!!!!!!!まったくもってその通りなのだ!」

僕「んじゃ、作っちゃいますか」

ユーザーがサービスを使う流れを考えてから設計に取り掛かる方法だと設計時に必要の無いものが含まれづらく、サービスとして成り立つ必要最低限(MVP)の機能に絞って考えることができるため、かなり画期的な方法だと感心していました。

以下は、DBのスキーマを設計する際に利用していたWebアプリです。 SQLライクな言語でスキーマをサクサク組むことができ、最終的にできたスキーマSQLに変換することができます。 個人的にかなり好きなのでインターンで紹介してもらった後も結構使ってます。

dbdiagram.io

また、設計をする前に軽く技術検証をしていました。 というのも、今回の開発では時間がとても限られていることから、外部サービスを利用して効率的にアイデアを実現していく必要がありました。 外部サービスを利用する際には、外部サービスで提供されているAPIを叩くことになりますが、そもそも自分たちのほしい機能がAPIとして提供されているのか、それをコードに落とし入れて実装できそうかといった実現可能性について調査をしていました。 検証が終わって「いけそう!問題になるとしたら時間だけだ」といった気持ちになり、いよいよ実装に入りました。

実装

設計が終わってついに実装パートに突入します。

インターンが始まる前は、インターンが始まると実装ゴリゴリのゴリラになるのかと勘違いしていたのですが実際に開発をしたのは3日程度でした。 APIのエンドポイントがしっかり定義されていたり、これまでのアイデア出しや設計でメンバーとサービスについて長い間話し合って来たことから、自分が何を開発するのかといった象が具体的で迷いが少なく、普段の趣味の開発よりも早いスピード感で開発に取り組むことができました。

ただし、開発の進め方について反省すべき点がありました。 それは、インクリメンタルな開発をしていたという点です。

以下の図は、インクリメンタルな開発とイテレーティブな開発のそれぞれを表したものになります。 これは、開発時にサポーターさんに指摘していただくまで気づくことができせんでした。

f:id:tokoroten_lab:20200921224838p:plain

図から分かるように、インクリメンタルな開発では、1つ1つの機能を完成させていきながら最終的に全体を作っていきます。 これに対し、イテレーティブな開発では、1つ1つの機能を完成させるというより、全体像が早く見えるように「とりあえず動く」といった状態にしてから段々と細部を作っていきます。

インクリメンタルな開発では、機能が完成してから初めて共有が可能になるのでもし認識のズレがあった際にやり直しコストが大きくなったり、シンプルに全体像が見えづらいので機能を繋げていくのもどのように繋げるのかイメージが湧きづらかったりするといった欠点があります。

実際、開発時にこの問題点を抱えていて、初めの方はフロントエンドとバックエンドの連携の取りづらさを感じていました。 自分一人だけの開発では、何をするにしても自分だけが理解していれば良いのでこういった問題点は見えづらいですが、チーム開発ではそれが顕になって身にしみました。

僕が実装した箇所としては、バックエンドがZoomと連携する必要があったのでZoomのOAuth認証やZoom APIを叩く処理を主に実装しました。 OAuth認証、言葉や概念自体は前から知っていましたが、実装したことは無かったのでトリッキーな実装になってしまい無理やり実装した感がすごかったです(小並感)。 実装していく中でOAuthのフローやトークンとユーザーを結びつける方法の知見を獲得しました。

チームメンバーは、ガチプロでした。 僕がZoomの連携で手こずっている間、バックエンドを主に担当していたもう一人は無限にAPI生やして他の外部サービスとの連携が殆ど完了しているし、フロントエンドの二人も次々とページを作成してレイアウトを整い始めてるし… 本当にメンバー全員が凄くて、ここに居ることができて良かったなぁと染み染み思いました。

そして、殆どの機能ができ、機能同士を繋げていくのが爆速で行われました。 開発の最後は、自分たちの作ったサービスが動いているのを見てめちゃくちゃエモい気持ちになりました。

最終発表

インターンの最終日に成果物の発表会がありました。

発表時はとても緊張しましたが、何より他のチームの発表を聞くのがとても楽しかったです。 各チームが本気で考えて本気で作ったサービスを見せてくれるため、アイデアやそのクオリティに素直に感動するものがとても多かったです。

全ての発表が終わった後には結果発表があります。 Treasureで講義をしてくれた各分野の講師やCTOの方から以下の賞が各賞1(または0)チームに与えられます。 1チームが複数の賞を得ることもあり得るとのことでした。

  • グランプリ
  • ニーズ賞
  • API設計賞
  • UI/UX賞
  • データモデリング
  • DevOps賞

チームで目指していたのは「グランプリ」でした。 そのために「妥協しない」というスローガンの下で本気で取り組んだ2週間。 結果発表の時は、心臓がバクバクしていました。

そして最終結果は…

  • グランプリ
  • UI/UX賞
  • ニーズ賞

以上の賞を全て頂くことができました!!!

正直、初めは1つのチームに複数の賞が与えられるということはあまりなくて各チームに1つの賞が与えられるのではないかと思っていました。 そのため、UI/UX賞・ニーズ賞のどちらが先だったかは覚えていませんが1つ目の賞を与えられた際にグランプリはもう貰えないじゃないかと本気で落ち込んでました。 しかし、その後、UI/UX賞・ニーズ賞の2つの賞をもらった際に「え、これ本当に1チームが複数の賞もらえるんだ」という意外な気持ちと「だったらまだグランプリは十分ありえるんじゃないか…!?」といった気持ちで心がざわつきました。 そして、最後のグランプリが発表された瞬間はめちゃくちゃ嬉しくて疲れが全部吹き飛びました。

チームで「最終日はヱビスビールで乾杯する」という約束があったので最後に勝利の美酒を飲んで最終日は文字通り優勝しました✌

f:id:tokoroten_lab:20200908215737j:plain

嬉しかったこと

本気になれた

冒頭でも書いた通り、Treasureには本気で取り組むことができました。

これは今思い返せば、本気になれるだけの人、環境、課題が揃っていたからこそだなぁと思います。

普段の趣味の開発って、登場人物が自分しかいなくて、代わり映えの無い環境で、自分がなんとなく不便だなぁとかこんなの欲しいなぁって思ったものを作るんですよね。 しかし、Treasureでは、めちゃくちゃレベルの高い同世代の学生や現役のガチプロエンジニアの方に囲まれて、自分の知らない新しい環境で、本気で課題を探すところから始めるんですよね。

これって刺激の塊みたいな状況でアドレナリンがめちゃくちゃ出ます。 やってやろうって気になります。

本気でものを創る経験をしたい人にはガチでおすすめのインターンです。 自分がついていけるか不安だという人も、冒頭でも述べた通り、参加してみればそんなこと考えてる暇無いのでとりあえず参加することをおすすめします。

自分だけでは気づかないことに気付かされる

Treasureでは初めて会った人と一緒に課題について議論したりチームになって開発を行うので本当に色々な考えに触れることができます。 また、講師の方やチームのサポーターさんからかなり積極的にフィードバックや指摘を頂けるので自分では気づけないような点い気づかされます。

上の方であったモナリザの図なんかがその例です。 それ以外にも他のTreasure生の課題のプルリクからコードを見て自分には無い考え方や実装を取り入れることができました。 チーム開発時には、メンバーのコードから良いところをたくさん盗ませてもらいました。

インターン全体を通して思ったこととして、Treasureでは話し合いの場がかなり多く設けられていたと思います。 それらの場があったからこそ、自分に無いものを他者から得ることがたくさんできたのだと思います。

おわりに

Treasureに関わってくださった方々、本当にお世話になりました。

課題を解決できる最強のエンジニア目指してがんばります。

また何処かで会う機会があればよろしくお願いします。