Treasureの概要

インターンの概要については、以下のブログがわかりやすいです！

https://techblog.cartaholdings.co.jp/treasure

今年は3週間オフライン開催で、私は遠方からの参加でしたが、3週間ホテルを用意してくれるので初めから最後まで安心して参加することができました。

今年の技術スタックは、フロントエンドがReact + TS、バックエンドがHono + TSでした
※Treasureでの学びを最大化するため、技術の勉強で終わらないように、フロントとバックどちらもTSを利用する形になったそうです。

最初の週が火曜からの4日間、後半2週間は5日間フルということで、合計14日間のインターンでした。Day1からDay14でまとめましたので、気になったところからご覧いただければと思います。

Day1(顔合わせ)

参加初日。今年は3週間全日程オフライン参加なので、他のTreasure生とうまくやっていけるか不安がありましたが、みなさん穏やかな雰囲気でお話しをすることができて、早々に安心したのを覚えています。

初週の講義パートでは、3〜4人のTreasure生が1つのテーブルに集まって、CARTAの内定を持っている1つ上の先輩がTAとしてついてくれました。

初日はチーム開発でのベースアプリの動作確認や、チーム開発を行う上での注意点、その他注意事項などの説明がある日でした。講義の途中Slackのチャンネルが盛り上がっていて、私が知らない技術で盛り上がったりしているのを見て、参加者の優秀さに驚いておりました。

そしてなんと、お昼ご飯には弁当が用意されており、TAの方も含めてTreasure生とご飯を一緒に食べていました。なんという手厚いインターンなんだろうかと驚きが隠せませんでした。

初日が終わった後、懇親会があり、席替えをして新たなチームでボードゲーム大会を行いました。CARTAのボドゲ部の方が用意してくれたゲームで、チーム対抗戦としてとても盛り上がりました。

懇親会中もご飯を用意していただいて、見た目もおしゃれで美味しかったです…

Day2(モデリング講義)

t-wadaさんによる、DBモデリングの講義がありました。RDBの需要はまだまだあるという教え()を受けた後に、モデリングの手法について教えていただきました。

講義の後半では、コンビニのレシートの情報をもとに、モデリングしてみるという体験を4人グループとなって行いました。

自分たちなりにモデリングを行なった後、自分たちが作ったモデルを壊すような買い物をしてくるというお題が行われました。買い物は虎ノ門ヒルズ内を周りました。

たとえば、量り売り、キャンペーンによる値引き、複数個買うことによる値引きなどが考えられ、試行錯誤しながら買い物をしました。

この講義を終えた後に身の回りのサービスを見渡してみると、自分が思っていた以上に世の中は複雑であることがわかります。

↓とてもざっくりとしたテーブル設計

Day3~4(FE, BE講義)

フロントエンド、バックエンドの講義が行われました。Treasureが開催されるまでの事前課題として配布されていたベースアプリとほぼ同様のアプリを使用して行われました。

講義の流れとしては、どちらもベースアプリを拡張していくような形で行われました。ここでも4人ほどのチームで分かれて、それぞれにTAが1人ついて進める形でした。

Day4はフロントエンド講義ですが、この日は台風が来てしまい、急遽オンラインでの参加でした…。遠方組はAPAホテルからオンラインで行うことに。

それでも運営の方々は私たちの学びを最大化させるために、全力で対応してくれました。

講義とはいえ、時間も限られているのでかなりスピーディに進んだ記憶があります。ある程度Web技術についての基礎知識はあった方が良いと思います。
※講義中の課題をこなすので手一杯になるので、途中に調べたりしている時間はあまりありませんでした。

また、講義パートの最終日には講義打ち上げ会がありました！

Day5(チーム発表, PDM講義)

チームビルディング

2週目初日。ここからはチーム開発を行うフェーズのため、チーム発表が行われます。

今後2週間を共にするので、ここでまた少し緊張してました…

そして、私は「Treasure生4人 + サポーター3人」のチームで結成されました！

チームが組成されてすぐに和やかな空気が流れていて、とても居心地の良いチームだと感じた印象が強いです。

そして私のチームでは、チーム開発における気を付けることとして、以下のような点を挙げました。

聞きやすい環境づくり
- すぐには反応できなくても、何かしらリアクションはする
- 今の現状を常に報告
  - timesを使ったり、口頭で報告したり
- 10分間わからなかったら誰かに相談する
前提とイメージの共有を積極的に
- 少しでも違和感を感じたらそれを伝える
- 反論を淀みなく伝え、言われた側も真摯に向き合う
指摘する際も、言葉に気を付ける
- 否定的な言葉は使わない
- 意見や技術への否定は良くても、人格否定は絶対だめ

上記以外にもありますが、大体こんな感じでチームルールは出来上がりました。

PDM講義

PDM講義は、「10年前にタイムスリップして、LINEを開発する」というお題に基づいて、アイデアの詰め方、Design Docsの書き方を学ぶというものでした。

難しかったこととしては、以下が挙げられます。

そもそもアイデア出しに慣れてなく、どう進めていいのか混乱してしまった
チームでの課題出しにおいて、課題を多く出すことはできたが、そこからどの課題について話していくか決めるのにとても時間がかかった
Design Docsを書いていく途中で、この課題について議論することが難しいことに気づいて、他の課題に立ち返る判断が遅れてしまう
MVP（課題を解決する上で絶対に必要な最低限のもの）が、チームメンバーごとに認識がずれていた

課題や解決策を煮詰めている間に、実現が難しいことや、そもそも課題ではないことに気づくことは往々にしてあるようで、そうなったらまた課題出しに戻って、そしてまたDesign Docsを書くというサイクルを回すことが重要だそうです。

「この課題は難しい！一回課題出しに戻ろう！」の意思決定をするのは、とても難しいことだと感じました。とはいえ時間は限られているので、エンジニアとして働く上では非常に重要な判断能力だと学びました。

Day6~7(チーム開発のアイデアだし)

アイデア詰め

「コミュニケーションに関する課題を解決しよう」というお題で、チームごとのアイデア出しが始まりました。与えられた期間は2日間で、Design Docsを書いて提出しなければなりません。

最初に課題をみんなで出し合ってから、どの課題を解いていくかを決めていくという流れで行いました。

しかし、なかなか決まらず…

意見は出るが収束せず、刻一刻と時間が過ぎていってしまう…

そこで、「エンジニア就活においての意見交換って難しいから、そこを解決したいよね」という意見が出て、アイデア出し1日目は終了

アイデア出し2日目に突入。就活においてどこが大変なのかということで、さらに課題を深掘りしていきました。

そこでまた、以下のような様々な意見が出ては収束しない時間が続く。

就活生同士で、状況の近い人同士がマッチングできるようなシステムにして、クローズにチャットができるようなサービスにしたらどうか
卒業年度が同じ就活生同士しか見られないようなサービスにして、就活生同士で情報共有できるようなサービスにしたらどうか
- 企業側が見られないようにする
- ESや面接内容、コーディングテストの内容を公開しあったり…
  - それってグレーゾーンでは…？
過去のインターン経験やアルバイト経験、制作物などを見せ合うことができるサービスにしたらどうか
- 入力する側はどういうモチベーションで入力してくれるの？

上記に出ていない意見も含めて、なかなか意見がまとまりませんでした。

そして締切1時間前になってPDM講師の方から、「結局みんなが欲しいと思う情報ってなんだっけ？」「行きたい企業に受かりたいんじゃないの？」「そのためにはどんな情報を就活生から得れば嬉しいの？」などのフィードバックをいただき、怒涛のDesign Docsの修正に入りました…。

アイデア決定

結果、私たちが作ることを決めたサービスは、以下のような仕様に決まりました。

行きたい企業に受かるため、その企業に受かった人と自分の技術力の差を知れるサービス
企業ごとに、受験者の合否情報が載っている
- 合否情報をさらにタップすると、その受験者の制作物や、他の企業の合否状況が見られる
受験者の制作物や合否状況を見るにはポイントが必要
ポイントは、自分が制作物や合否状況を入力することで得られる

最低作らなければならない機能である「MVP」(Minimum Viable Product)としては以下が挙げられる

ログイン機能
企業一覧表示
合否情報表示
制作物、合否表示
プロフィール画面
- 卒業年度登録
- 合否登録
- 制作物登録
ポイント機能

Day8~13(チーム開発)

アイデアも決まり、いよいよお楽しみの開発フェーズに入りました。

まずは設計から

まずはサービスの形として、どんな見た目のサービスにするのかをチームで議論を進めました。

↓画面遷移の図

ある程度画面のデザインも決まったところで、DBモデリングを行いました。DBモデリング講義で学んだことを活かして！と言いたいところですが、なかなか意見がまとまらず、かなり時間かかった印象があります。（最初に決めた予定が大幅に後ろ倒しになってしまう…）

チームで持っている共通認識と、自分だけが思っている認識がいつの間にか混同してしまい、チーム間で意見がバラバラになってしまうこともしばしばあって、サポーターの方にそこを指摘していただきました。

チーム全員が共通認識を持っていることを崩さず積み上げていって、自分の意見とはしっかりと分けて議論をすることが重要だと学びました。

コードを書き始める

大枠の設計もある程度定まり、コードを書き始めました

私たちのチームでは、みんながフロントもバック両方触れられるように、機能で役割を分担しました。（途中開発速度が求められる箇所では、フロントとバックで分けて行うなど、所々で柔軟な対応はしていました。）

基本的にはGithubのissueベースで開発を進めました。

詳細を記載するとかなり長くなってしまうため、ざっくりと「良かったこと」「課題」「解決策」としてまとめました。

チーム開発で良かったこと

最後まで雰囲気良く開発できた
見積もりは難しかったが、それでも時間割をみんなで決めてから実行できたのは良い動きだった
何について議論しているかの共通認識を持って議論できた
要所要所で、サポーターの方の意見を能動的にもらいに行けた
反論も淀みなく伝えられて、他のチームメンバーもそれを受け入れて会話ができた
開発の際、PRは必ず誰かがレビューをしてからマージできた
- バグの発見も早かった
- 事前にバグを見つけられた

チーム開発の課題

タイムキーパーが難しい
- どうしても最初に決めた予定通りには行かない
- そもそもの作業見積もりが甘い
- 故に、全然休憩が取れない！！
- 資料作り、アプリのデザインもかなり後ろ倒しになってしまった
チームで共通認識が取れていない場面が所々あった
時間がなくなってくると、PRのレビューが適当になってしまう
PRが大きくなってしまい、他の人の開発が止まってしまうことがあった
実装において、こだわり過ぎてしまう部分があった
やはり、意見は出るが収束しない

課題の解決策

何が一番重要なのかを常に考え、それをチーム間で共有する
- 重要じゃないと分かったらすぐに切り捨てる。その判断を素早く
対立意見が出てきた時は、各々の意見を聞いた上で、落とし所を見つけよう
- その判断はなるべく早く、そこでも重要にしている考えを共有しながら
見積もりは余裕を持って行う
- だからこそ、一番重要なものから行なっていくことが重要
- 見積もりが甘いと、あれもこれもとなってしまい、最終的に何も間に合わないということになってしまう
どんなに忙しくても、休憩の時間は最初に決めておいて、強制的に取る！
自分とチームの共通認識がずれていると思ったら、すぐに相談！
タスクはとにかく細かく切って、ブランチの寿命を短く！
- ついでにやりたいことが出てきたら、同じブランチでやろうとせず、新しいIssueを立てる

補足

開発の途中には中間発表があり、審査員の方々から「MVPからずれずに作れているか」「進捗はどんな感じか」という点で、フィードバックをいただきました。

制作物入力について、当初のMVPでは入力項目が1つの自由記述であり、それでは入力者ごとにかなり情報のムラが出てきてしまう
今一度、「私たちが入力してほしい情報ってなんだっけ？」ということで、一旦開発を止めてもう一回議論をし直した方が良いかも
それによって、入力項目はかなり多くなってしまうかもしれないけど、情報を閲覧する側としてはとても有意義な情報を得られる方がよっぽど大事だと思う
運用面のことよりも、そもそもユーザーが何を求めているかということを考え詰めた方が良い

フィードバックをもとに、一旦開発を止めて、制作物入力の項目を議論し直しました。

↓制作物について、欲しい入力を考え直した時の様子

Day14(最終発表)

各チーム「発表5分 + 質疑応答5分」で行いました。後半は、審査員やTreasure生同士が、各チームのサービスを見て回るということを行いました。そしてこの日の最後に賞をとったチームの発表が行われます。
本インターンでは、「グランプリ」「技術賞」「アイデア賞」という3つの賞があって、それぞれ1チームに贈られます。

結果発表

私のチームは、なんとアイデア賞 をいただくことができました！！！！！

↓修了証書とアイデア賞(本名の記載がある部分を削除)

賞をいただいた理由として、以下の点を褒めていただきました。

本当に使えそうなアプリだと思ってもらえた
はじめに考えたMVPからずれずに作り切れた
中間発表でのフィードバックをもとに、かなり良いサービスになった

私たちのチームは、どこのチームよりもアイデア出しでかなり苦戦したチームだと思っています…。時間いっぱいアイデアが右往左往した挙句、締切の1時間前にアイデアを変えるということもあったりして、チームメンバーが全員疲弊していた日でした。

ただ、その結果アイデア賞をいただけるほど良いプロダクトを考えることができたので、結果的には非常に良かったと思います。

しかも、チームメンバー同士でバチバチに議論したにもかかわらず、最後まで良い雰囲気で終われたため、とても良いチームだったと心から思います。チームメンバーには本当に感謝しています。

ただ、グランプリではなかった理由として、以下の点をフィードバックとしてもらいました。

アプリとして使ってもらうために、ポイント制度などをもっと考え込んでも良かった
- 他のアプリとの連携を想定するなど、アイデアとしてもっと煮詰めても良かった
ベースアプリの技術をそのまま使ったので、もっと技術的にチャレンジしても良かった

チーム全員が知っている技術を使ったほうが効率良いというのと、時間的にも厳しかったので、なかなか技術的な挑戦をするのは難しかったです。ただグランプリを取ったチームは外部APIなどを使って、アプリをよりよくしようと技術的なチャレンジを行なっていました。また、アイデアとしても実際に使われるイメージができるプロダクトだったので、グランプリを取ったことも納得です。

また、技術賞を取っていたチームは以下の点で評価されていました。

PRを小さく回して開発していた
コミットとかも細かく分けていた
本当に必要な機能のみを実装できていて、その流れも綺麗だった

技術的な挑戦というより、開発の仕方的なところで評価されていた感じがしています。このチームは3人チームでしたが、ペアプロとかも取り入れていて、他のチームとは少し違う進め方をしていたイメージがありました。限られた時間の中で何を優先するべきかをしっかり考え、gitを使ったチーム開発の進め方もとても綺麗だった点は見習いたいと思いました。

まとめ

本当にTreasureでは、何から何まで至れり尽くせりの3週間でした。技術はもちろんですが、それ以上に、エンジニアとして必要な考え方や、今後の自分の課題を見つけることができました。

どんな時もMVPを見失わないように！
タスクに優先度をつけ、常に何が一番重要かを考えよう！
タスクを細かく切り分けよう！
自分の意見と、チームでの共通認識は、切り分けて発言しよう！

上記のことを忘れずに、これからもエンジニアとして成長していきたいと思います。

また、せっかくの東京ホテル暮らしということで、合間の土日には他のTreasure生と一緒に様々な場所で遊びました。（蒙古タンメン食べたり、ボドゲカフェ行ったり、秋葉原行ったり… etc）

他のTreasure生と横のつながりを作れたことも、私にとってはかなり大きな収穫でした。

27卒以降のエンジニア就活生の皆様、Treasureに少しでも興味を持ったら、是非とも挑戦してほしいです！

最後に、このインターンに関わった全ての方に感謝いたします！！

目次