見出し画像

VOYAGE GROUPのインターン「Treasure」に参加してきました。

8月の1ヶ月間(8月1日(土)・8日(土)・15日(土)・8月17日(月)~8月28日(金))VOYARGE GROUPの「Treasure」というインターンに参加してきました。
技術はもちろん、エンジニアとしてかなり成長することができたのでそれについて書いていこうと思います。

目次

Treasureとは
前半:講義、後半:チーム開発といったスケジュールで行われるエンジニア向けインターンシップです、今年はコロナの影響でオンライン開催でした!
詳しくは公式を参考にしてください。

参加まで

自分は早期選考から参加しました。
選考フローとしては、ES→面接3回(エンジニア2人、人事1人)といった形で、4月末ごろに電話で合格をいただきました!
ESに関しては、これまでの制作物や自分の成長のためにやってきたことをとにかくアピールしました。
エンジニア面接では技術的な話が多く、ESに書いた内容から話題が膨らんでいったという感じです。ESなどでアピールした技術をしっかり理解していたら問題ないと思います🙆‍♂️
人事面接はあまり覚えていないのですが、自分の将来なりたい姿みたいなのを聞かれたと思います。

その後、事前課題としてGoとReactで構成されたアプリのCRUD機能を実装するといったものを出されました。

前半の講義

ざっくりと
・フロントエンド
  - javascriptの基礎(だけどあまり深く理解せずに使っているもの)
  - skyway
・バックエンド
  - APIの設計
  - WebRTCのサーバー側について(これが難しかった)
・DB
  - データモデリング
・インフラ
  - 事前課題のインフラ構成の説明
・アイデア
  - フレームワークを元にチームでアイデア出し

前半はグループワークが多かった印象です。

後半のチーム開発

後半は過去の参加者さんのブログでも評判が高い、Treasure名物のチーム開発です。
形としては学生4人・メンターさん3人のチームになってお題を元に開発を進めていくハッカソンでした。

結論からいうと結果は僕の価値観からするとあまりよくなかったです。
アイデア出しにかなり時間を取られ、開発期間がほぼなくなってしまい満足のいくものを作りきれませんでした。これはエンジニアとして恥ずべきことだという自覚はあります。

ですが、もしこの失敗を経験をしていなかったとしたら、僕のTreasureは今の半分以上薄いものになっていたと思います。
それくらい様々なことを学ぶことができました。

アイデア出し
ここにほとんどの時間を費やしました。
議論が発散してしまったり、案がポシャった時にどうするかを考えていなかったりと色々と問題点が多かったと思います。

how的なところでやってよかったこと
・KPTを細かく挟むことでPDCAを早く回せる。
・時間を区切って、今何について話しているか・話題がそれていないかを確認する。
・議事録を取る。

設計

一つのエンドポイントに役割を持たせすぎないことや、今後のユースケースを考えながらのモデリングなどを意識しました。

実装
機能自体はシンプルで、技術的に難しいことはなかったです。
開発効率をあげるという点で、issueを細かくきったり、自動でformatかけてコミットし直してくれるCIをいれたりしてました。(これはメンバーの一人が気づいたらやってくれてた。)
issueに関しては単純なTODOやバグだけではなく気づきや学んだことをタグ付けをしてissueに上げておくことで、後から他のメンバーもキャッチアップできるようにしていました。

発表
あまり練習できずボロボロでした。。。もうちょっとできたはずなんだ。。。

こんな感じの流れで、特に何の賞にもかからず終わりという感じでした。
僕らのアウトプットに対して妥当かなという感じなので特に文句はないです。(悔しさはめちゃくちゃあります!)
最後にメンターさんやチームメンバー同士と飲みながらフィードバックみたいなことをして終わりました。

チーム開発で終始悩んでいたことと自分の中での結論

最後にチーム開発でずっと考えていた、リーダーとエンジニア組織について書こうと思います。

僕らのチームは上で書いた通り、議論がなかなかまとまらずにアイデア出しにかなりの時間を取られてしまいました。
その途中僕はこの状況を打破したいと思い、リーダーを決めるのはどうかと提案しましが、結局現状で一応回っているのだから決める必要はないということになりました。
その時の僕の意図としては、一般的な組織だとリーダーを決めるし、
とりあえずリーダーを決めたら議論が進むのではというかなりふわっとした理由でした、もちろんそんな理由では改善されるわけがないし、むしろその決め方だとただただリーダーにヘイトが向いてしまうだけなので決めなくてよかったと思います。
今になってわかるのですが、どうやら僕は「ファシリテーター」と「リーダー」を同一視していたようです。

そこから僕はリーダーってなんなのだろう、なぜ普通の組織ではリーダーを決めるのだろうと考えるようになり、先輩やルームシェアのメンバー、メンターさんやCTOの小賀さんなど、色々な人に話を聞いて回りました。

そこから出た僕の中での結論を書いていこうと思います。
※あくまで僕の考えです。違う意見があればぜひお聞かせください!

エンジニア組織は大きく三つに分けられると僕は考えます。
まず、個々人それぞれが意思を持ち、目標の達成に向け行動する組織(ティール組織というらしい)。
こういった組織は、しっかりとした目標があり、個々人の能力が高くセルフマネジメントできるなどといった前提があるため一朝一夕で作れるものではありません。

次にシステム化された組織。
この組織は、集められたばかりのまとまりのない状態でいきなりティール組織を目指すことは難しいので、システム化することで組織を上の状態に持っていこうとします。
ですが、このシステム化というものも一朝一夕でできるものではなく、色々と試行錯誤を経て形成されていくものだと考えます。

最後に集められたばかりで何もない状態の組織。

このティール組織 ← システム化された組織 ← 集められたばかりの組織の中で上の段階へと組織をリードしていくのがリーダーなのだという結論に至りました。
※もちろんリーダーといっても色々な側面があり、これだけでリーダーとは何であるとは言えないことは承知しています。

では、僕らがうまく議論を収束させることができなかった理由はなんだったのだろうと考えたところ、そもそも僕が大事にしていたものと、メンバーの一人が大事にしていたものが違っていて、僕が大事にしていたものをうまく言語化できていなかったことに原因があったのかなと思います。

最後の打ち上げでそのメンバーと話をしていてわかったことが、そのメンバーは「人」に注目して進めいきたいという考えでした。
リーダーを決めることでチームメンバーの誰かが納得いかずに進んでしまうなら、時間をかけてでも全員の合意を取るべきだという考えでした。
いっていることはすごくわかったのですが、どこか違和感を感じることがありました。

これについて先輩に相談したところ、この違和感の正体がわかりました。
どうやら、僕の考えは「自分たちが達成したい目標」に注目しているようだったのです。
その目標を達成するために必要であればやるべきで、そうでなければやる必要はないという考えです。

ここをうまく言語化できて、最初に全員に共有できていたら、うまく議論を収束させられたのかなと思います。

追記)
今回は「自分たちが達成したい目標」にとっては失敗した結果でしたが、「人」に注目したものならば大成功だと思います。
ここの価値観を早い段階で合わせることが重要なんだなと学びました。

まとめ

長々と書いてきましたが、このインターンに参加したことで僕はまたエンジニアとして大きく成長できたなと思います。
ここまでチームで議論したのは僕の人生を通して初めてで、本当の意味でのチーム開発を経験できたなと思います。

最後になりますが、
VOYAGE GROUPの社員さん、Treasure生のみんな、色々と相談に乗ってくれた方々本当にありがとうございました!

Treasure最高!!!!!!


他参加者の記事

おぎじゅん:
https://ogijunchang.hatenablog.com/entry/2020/09/03/023132

たくりんとん:

ゴリにゃ : 
https://hirocky86.hatenablog.com/entry/2020/08/30/032735
https://hirocky86.hatenablog.com/entry/2020/08/30/032735
https://hirocky86.hatenablog.com/entry/2020/08/30/032735
https://hirocky86.hatenablog.com/entry/2020/08/30/032735
https://hirocky86.hatenablog.com/entry/2020/08/30/032735


メンターさんの記事
かーたーさん:
https://techlog.voyagegroup.com/entry/2020/09/08/184336

この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
4
コメントを投稿するには、 ログイン または 会員登録 をする必要があります。