VOYAGE GROUPのTreasureに参加してきました
VOYAGE GROUPのサマーインターンであるTreasureに参加してきました.
- このブログを読んだ人がTreasureの参加を考えるとき, 参加するときに何かしらの役に立てば嬉しいなぁ
- 自分の反省点を言語化するぞ！
という2つの思いをもって書きます
そもそもTreasureとは
VOYAGE GROUPが開催するサマーインターンです.
- 期間: 8月の3週間
- 報酬: 12万
- 内容: 講義+チーム開発
- 分野: web
参加に至るまで
参加に至るまでを軽く紹介しておきます.
申し込んだ理由
2018年の夏に長期インターン先の学生たちとサマーインターンを調べてて「Treasureって面白いって聞く」と誰かが言ってたのを思い出して, 調べてました.
過去の参加者のブログを読んだら「Treasureっていうインターンでブログがこれだけアップされるって何だ. どんなインターン生が集まってるんだ. そしてこれだけTreasure情熱を注いでるVOYAGE GROUPってどんな会社なんだ...」と興味を持ったのがきっかけで, 申し込みました.
↓読んだブログを一部紹介↓ monpoke1.hatenablog.com
ほとんどの人がサポーターズ経由だったので, 少しアウェイでした.
面接
エンジニア面談2回, 人事面談1回を30分ずつ行います.
エンジニア面談では具体的には以下のようなことを聞かれたと思います.
- 自己紹介
- 志望理由
- 今までどんなことやってきたのか
- 将来どうなりたいのか
- 実際に作ってきたものを見せて, 質疑応答する
- 質問があれば何でもしてね
人事面談では面白い質問をされました(詳細は省く)
正直面接が終わったとき, 落ちたと思いましたwww
受かるために何やればいいかとかはわかりませんが以下のことを意識して面接に望むと良いかも知れません
- 自然体でいくこと
- 制作物はコードとかも見せれるようにPCも持っていくこと
(大したアドバイスにはなってない)
Treasureはどんな感じで進められるのか
皆が書いてるので, 皆のを読んでください(日毎に詳しく書いてる感じがした2つを持ってきました)
感想としては, めっちゃ内容が濃く, 範囲も広いです.
講義内で触れたものに関して, 少しでも疑問があれば講師へ後からslackで聞くなどしてどんどん質問すべきだと感じました
Treasureに参加してからのあれこれ
事前課題が出るぞ！！
びっくりしたけど事前課題が出る！！
これは絶対にやっておいたほうがいい！！！！特に自信がない人ほどやっておくべきだと思いました.
Treasure参加者について
- 個性豊か. 本当に個性がすごい.
- web経験者も未経験者も居る
- 笑いのツボが僕とは合わない人が居た
- コミュニケーション能力が高い人が多い
- おしゃれな人が多い
どれくらい個性豊かというと, 筋トレキャラがおそらく毎年1人は居ます.
席替え
前半の講義では席を強制的に変えたいという需要が発生します.
席替えするアプリをインターンで作成すると, インターンをより楽しめます.
ちなみに僕は席替えアプリを作成しました.
「席替えのロジックだけ変えればOKだよ！だからみんなどんどんPR出してね！！」みたいなソースコードに工夫したつもりでしたが, 僕を含めてコントリビューターは2人でした...思ったよりも講義の演習でやり残したことを家で演る人が多いのか, 席替えアプリに尽力する人はいませんでした...
インターンは楽しんだもん勝ちだと思うので, 今後参加する人は是非積極的にやってほしいと思います.
席替えアプリの反省点としては, 席替えのついでにランチの組み合わせも決めちゃえばいい感じに交流できたかも, と思いました.
強制ランチを嫌う人もいるかも知れないので, 強制にはせず「こういうグループでランチ行ってみてはいかが？」みたいなきっかけづくりにも席替えがなると良かったかもと思います.
僕は一緒に席替えアプリを作ってくれたぎーたかと一緒に二人ぼっちランチを楽しんでました
日報書くぞ
日報を書くと, 社員さんが見てくれて, コメントをくれる. なのでその日やったことをただ書くだけでなく, 感想やふと思ったことを書いたほうが良いと思います.
それと余裕があれば他の人の日報も読んでみると良いです. 僕はちらちら見てたけど「ほ〜こんなことしてたのか」とか「こういうこと持ってるのか〜」とか知れました.
チーム開発
このTreasureはチーム開発がとても魅力だと思う. 何がすごいって
- 何故これを作るのか
- 何故今これを進めていくのか
- 何故テストは書くのか
- 何故, 何故, 何故...
考え抜く機会がめっっちゃあるから...
チーム開発で意識した方が良いなと思ったのは以下の2つです.
- 「俺はこれが良いと思うんだよなぁ...んーーなんでかっていうとぉ...」って話ながらでも良いから根拠を持つ(何故かそう思ったかを考える)
- 「いや, なんか違う気がしてて...」ってもやもやを発信してくれる人が居てくれるおかげで, 軌道修正もできるので, 違和感を感じたら迷わず発言する
チーム開発での個人的な反省・感想
ここからは自己満で書きます.
メンバーのレベル差を埋めるためにモブプロをやったのはよろしくなさそうだった
僕らのチームにはwebやってるよー！って人も入れば, やったことない...って人も居ました. また, チーム開発中はフロントエンド, バックエンドの役割分担はしない方針を僕が最初に持っていました(せっかくweb勉強したくてインターン来たのに一部しかできなかったらもったいないと思った). なので, APIを作る全体の流れ, フロントエンドの画面を作る流れを全員で掴むためにモブプロをすることにしました.
皆優しいので「モブプロのおかげで分かったよ」と言ってはくれますが, 実際これは適切な方法では無かったように思います. 一応良かった点もあるので記述しておきます.
モブプロの良かった点
ある程度ソースコードを理解している人にとって, モブプロでやっている内容は「ふんふん, あーなるほどね, そうやっっていくのね」くらいの感覚で進むため, 「次は自分でやってみたいな〜〜」くらいの気持ちが出てきます. 苦手意識をそういう意識に変えれたのは良かったかな〜と思います.
そして以下のような悪かった点があった様に思います.
モブプロの悪かった点
- 分からないことがバラバラなため, 個人個人に合わせて教えることができなかった
- その結果モブプロでやった内容を少し発展させたことをやろうとすると何がなんだか分からなくなることがあった
モブプロのスピードはサクサク進んでいくため, あまりソースコードが理解できていない人からするとただ誰かがコーディングしているのを見ているだけ, になっていたかも知れません. 僕はそもそもモブプロで「皆, 超サイヤ人になってくれ！」という気持ちがありましたが, これが間違いだったんだとすべてが終わってから気付きました...猛省.
どうすればよかった？？
色々考えますが, まずモブプロはフロントエンドのディレクトリ構成を伝えるためのみにして, APIの作り方についてはペアプロで苦手意識がある人につきっきりのほうが良かったかも知れません.
それと, ペアプロは時間を割と使うため, 短い開発期間中には限界があります. なので, 素直にサポーターに頼ればよかったと思いました. 最終的にどうなりたいかって, チームのアウトプットも最大にしたいし, 個々人の成長も最大にしたかった. だからチームの成果を出すためにも, 僕は僕がやらなきゃいけないことに集中して, もし開発でわからないことが出てきたらすぐサポーターに相談する, みたいな空気を作り出せていれば良かったのかもなぁ...と. 下手に僕ができもしないのにでしゃばって「分からなかったら相談してね」と言って気を使わせてしまってたなぁ...と. 悲しい.
補足: 成長できずに最後まで何もできない人が居た, というわけでは全然なくて, 動くAPIだって作ったし, 画面だってしっかり作成できてて, 多分皆4日間でめちゃくちゃできること増えたと思います. そう願っている.
メンターの発言をないがしろにしがちだった
メンターは度々僕たちに 「テストとかどうするの, 一応評価項目にはあったけど」 「これだと○○されると危ないよね」 「(今コレ実装進めてるみたいだけど)本当にそれでいいの？？」
と投げかけてくれていました.
でも, 正直 「テストとかどうするの, 一応評価項目にはあったけど」 => 「いやテストなんて書いてる暇ないですよぉぉ」
「これだと○○されると危ないよね」 => 「○○されると危ないですけど, 今は一旦ミニマムで機能実装進めたいんでこのままいきますよぉぉ」
「(今コレ実装進めてるみたいだけど)本当にそれでいいの？？」 => 「どうなんですかね...」
と, 最初はあまり深く考えませんでした. というか, すべて「テストないから書け」「危ないから対策しろ」って言いたいのかと思ってしまってたんですよね...
でもこれって実際は
- テスト書くようなところがあるのかどうか一度考えてみる => 書くべきところはあるか, 書かなくて良さそうなら何故書かなくて良さそうか理由を持つ
- ○○されると危ないなら, どうしたら安全かの考えだけは持っておく
- 今実装しているものを実装し終わったときに, サービスの目指すことはできるのか？？を明確にする
みたいなことを考えるきっかけにすべきだったんだろうなと思いました.
何か言われたら「それはXXXだからYYYだと思います」と, 理由を考えるようにして, それをチーム全体でも共有して, 全員が納得した上で開発をすすめると迷いも無く進めたのかなぁ...と.
2時間おきにスタンドアップミーティングを行ったが, 何故行うのかが明確でなかったため, 活かしきれなかった
隣のチームがやってたから俺らも何か困ってることあったら共有するためのミーティングを2時間に一回やろうぜ〜と持ちかけてみました.
実際そのミーティングの中で「これってXXXだっけ？」と議論になって, 出戻りを少なくできたり良いこともありました. ただ, そもそも何故2時間に1回のそのミーティングを設けるのか, ミーティングの目的をはっきりさせてメンバーでも同じ認識を持てていればもっと有効に活用できたのではないか, と思います.
インターン生とだけじゃなくて, 社員さんにたくさん話しかけたのは良かった
インターン期間中は, ランチもインターン生どうしなので, 社員さんとゆっくり話す時間はあまりありませんでした.
僕は最終日の打ち上げのときにチームメンバーよりも社員さんとひたすら話していました.
結局終電逃して朝まで居たんですが, めちゃくちゃ良かったです. CTOも朝までいて, 机に突っ伏している姿は少し微笑ましかったです.
この反省点が出てきたのは社員さんと話していて, 徐々に浮き彫りになってきたものたちです. 僕にとって大きくプラスなので, 感謝しか無いです.
まとめ
まとまらないですけど, たくさん考えぬいて, 可能な限り振り返るとこのインターンで学べることはとても大きいものになると思います.
少なくとも僕は最後には「参加してよかったなぁ」と思えました.
興味があれば, ぜひ.
