VOYAGE GROUPのTreasureに参加したので反省する(自分用)

*注意

こちらは〇〇インターン参加しました!みたいなよくあるやつではありません。初めはそんな感じで書こうと思ってましたが、結局みんなと同じような記事を書くの微妙だなぁと思ったので辞めました。

 

インターンの内容を知りたい方はこちらの記事をどうぞ↓

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

VOYAGE GROUPのTreasureに参加しました - じゅぎのんの徒然日記

VOYAGE GROUPのサマーインターン「Treasure」が最高だった話。 - ゴリにゃのブログ

じゃあ何書くの?

f:id:yayoicoffee:20200919200040p:plain

反省を書きます。ただただ今回のインターンについて反省するだけの自分専用の記事です。

*ネガティブなことが出てきますが、これは僕自身に向けてのものであり、voyage groupのインターン自体は最高だったのでそこは誤解のなきよう...

 

一応途中まで書いた残骸も貼っときます。↓

はじめに

voyage groupのエンジニア向けサマーインターン「treasure」に8/1, 8/8, 8/15, 8/17~28の日程で参加してきました!最高だったのでここに書き留めておきます。

参加まで

早期選考で申し込んだので、4月に合格を頂きました。面接はエンジニア×2,人事×1の計3回を1日で行いました。

参加前の僕の技術力

僕はもともとゲーム畑の人間でUnityでゲームばかり作ってました。そのためWEBに関する技術力は高くはなかったと思います。(Railsチュートリアルをやったくらい)

前半

インターンの前半は講義形式で行いました。フロントエンド、バックエンド、DB、アイデアなどWebアプリケーションを作る際に役立つ知識を学びました。(圧倒的準備不足の僕には難しかった。特にフロント)

後半

ここからチームに分かれてプロダクトを作って行きます。アイデア出しから要件定義、コーディング、プレゼン資料作成までやります。

結果

DevOps賞を頂きました。優勝できなかった悔しい。

 

反省

基本的に後半戦(チーム開発)についての反省です。

アイデア出しのやり方にこだわり過ぎた

アイデア講義において、とあるフレームワークを用いたアイデア出しの方法を学びました。僕たちのチームを含め、ほぼ全チームが実際のチーム開発においてもこのフレームワークを用いてアイデア出しを行いました。しかし後になって振り返ってみると、別の方法を検討してもよかったのかなと思っています。
何故こんなことを思ったのかというと今回のフレームワークを使用すると確かに良いアイデアは出やすいですが、それと引き換えにめちゃくちゃ時間がかかるからです。実際に僕たちは最終的なアイデアを出すまでに4日ほどかかってしまいました。
今回の目的はあくまで良いアイデアを出すことであって、必ずしも「このフレームワークを用いて」という制約があったわけではありません。
そのため、試しに自由にアイデアを考えてみるみたいな時間を取ってもよかったのかなと思います(アイデアは突飛な発想から出てくることもよくあるので)。もしここで良い感じのアイデアが出れば、他のチームよりも多くの開発時間を取ることができたし、出なかったとしてもさほどのロスになるわけではありません。
また実際に別の方法を取らないまでも、アイデア出しの時点で別のやり方もあるのでは?と検討すらできなかった自分は反省するべきだと思いました。

フロントの技術力が足りなかった

僕たちのサービスはフロントの実装が重い仕様でした。僕の担当はバックエンドだったのであまり重いタスクはなかったのですが、フロントはすごく大変そうだったので、代わりにタスクをもっと受け持ったりするべきでした。
しかしあまりフロントに自信がなく、結果的にプレゼン資料作成のタスクに取り掛かってしまったのは微妙だったかなと思っています。

プレゼン資料が微妙だった

プレゼン資料の草稿は僕が作り、その後みんなで話し合い、資料を改善していく方法を取ったのですが、ここにかける時間が少なさ過ぎたと反省しています。
発表自体は悪いものではなかったのですが、自分たちが頑張った点や工夫した点をしっかり伝えることができたかと言われると正直微妙です。
この問題はサポーター陣からも指摘されていたのですが、修正する時間をとれず、そのままにしてしまったというのが正直なところです。
僕は他のインターンでもプレゼン資料が微妙なゆえにうまくいかなかったことを経験してるので、今回は良いプレゼン資料を作りたかったのですが、結局また同じ失敗を繰り返してしまいました。

気が抜けた瞬間にうまく対処できなかった

全員でフロントとバックの接続確認を行う時間がありました。予定では5分くらいで終わらせる予定でしたが、エラーが出てしまい思いのほか時間がかかってしまいました。この確認作業はすぐに終わるからこそ全員でやろうという話だったので、エラーに遭遇した時点でリスケするべきでした。
しかしこの時に疲れもあって気が抜けてしまった僕はその場の流れに従ってみんなでエラー修正を行なってしまいました。
この作業は全員で行う必要は全くなかったので、すごくもったいなかったです。その後案の定サポーター陣からのストップがかかりました。気が抜けている自覚があっただけに、ストップをかけざるを得ない状態までに陥ってしまったことが本当に悔しかったです。気が抜けたと自覚した時点でメンバーに相談して少しでも休憩を挟むべきでした。

良かったところ

タスク管理がいい感じにできていた

miro内のKANBANを使ってタスクを to do,doing,done みたいに分けて作業を行ないました。これのおかげで誰が今どのタスクをやっているかが明瞭化され、作業のコンフリクトがほとんど発生しませんでした。

メンバーの意見をみんなが尊重していた

メンバー全員が他の人の意見をとても尊重していました(というかみんな凄くイイ奴だった)。意見が分かれた場合もその原因を突き止め、全員が納得する解決方法を模索しようとしていました。

目的を確認しながら議論を進められた

「結局僕たちは何をしたいんだっけ?」と何度も目的を確認して目的ベースで議論を重ねていきました。これによって目指す方向性がはっきりし、無駄な議論を減らすことが出来たと思います。

成長したところ

 うまくファシリテーションできた

今回僕は積極的に進行役を務めるようにしていました。というのも今回のインターンに参加した1番の目的が「うまいチーム開発方法を見つけること」だったので、そのためには進行役になることが最適だったからです。
実際の議論の場では、話すテーマやゴールを明確にしてから議論を始めるようにしたり、議論の途中で話の流れを整理したり、最後に話をまとめて食い違いがないかを確認したりなど、良い議論になるように色々心がけてアクションを起こしていきました。
最初の方はこれが難しく、なかなかうまくできなかったのですが、終盤ではしっかりできるようになったと思っています。
うまくファシリテーションをするためには他の人が何を考え、何を望んでいるのかを意識しつつ、全体を俯瞰しながら議論していくことが重要なのだと気づきました。

話が脱線した時に気づけるようになった

前述した話にも繋がりますが、良いファシリテーションを行うために試しに「全体を俯瞰すること」と「常に目的を意識すること」をやっていた時がありました。その時この2つを意識すれば、議論の全体像とゴールを把握できているので議論の脱線に気づけるようになりました。

フロントエンド(React)のコードが読めるくらいにはなった

僕はフロントに関してはhtml,css,jsの基礎が分かるくらいでReactなんて全然知らなかったのですが、最終的にはコードを読んで意図を理解できるくらいにはなりました。

最後に

今回のインターンではすごく成長できました。これは自惚れでも何でもなく、自信を持って言うことが出来ます。

そして何よりも楽しかったです!!仲間たちと熱い議論を交わしながら、サービスを実際に開発していうのは本当に最高でした。(いつか開発が辛くなった時はこの時を思い出せば頑張れそう)

そして僕がこんな経験ができたのも、全て今回インターンに関わった人たちのおかげです。こんな素敵なインターンを提供してくれたvoyage groupの社員の皆様及びTreasure生には感謝しかありません。

ありがとうございました!!!

ps

オフ会楽しみにしてます。

サイバーエージェントのインターンでパフォーマンスチューニングした話

6月6日〜7日の二日間、サイバーエージェントのインターンに初参加しました。

今回はその感想と実際にやったことについて書いていきます。

 

続きを読む