3Daysインターン振り返り

7/19(土)~7/21(月)の3Daysインターンのふりかえり。

メンターの方から個人FB

メンターを頼るのはわからない部分も多いので良いが、自分たちの意思で頼れると良い。
まとめようとしている行動→たくさんの頭からでた意見をまとめるのは前提難しい
- ので、どの役についたらいいか役回りを考えて動く。
ファシリのときは結論を急ぎすぎるのは良くない。みんなの意見を発散させていく。←もっとパフォーマンスの質問をする（それはどうして思ったか？結局何を決めているんだっけ？など）
色々な話をふっていく→抽象度が高いものの解像度を上げていく作業
- 例）レベル４、５の承諾数に関して滞っていたときになにで悩んでいることなのかは聞いてあげる
- ファシリ（アシストする人間側）になった時にはそちらに徹する。答えを言わない、割り切る。

空中での議論が多いので（プログラミングと違う）難しい
- 口頭なのでそもそも全員の認識が合っているかわからない時もある。
- 全員の頭の中を整理するムーブが必要。
共通点もある←それを考えられると面白いかも。
自分の役割を探す（ファシリ、議事録）
- この辺りは状況を見て選べるといい。議論が盛り上がっていると感じたら議事録をとるとか、ちょっと停滞していたらファシリになるとか
コードは書き慣れている
案出しの方で具体を急ぎすぎている←見えてしまっているからある程度の実装が見えてしまっていて具体に早めに収束させがち
- もっと発散させても良い←ファシリとなって積極的に意見を求めにいく、深掘りするのも手。
DB設計で考えるべきはは変更容易性
- コードの方はいくらでもリファクタできるがDBは修正が困難
- DB設計は通常たくさん時間をかけてやるべきことだし、現役の人でも難しい
- 集計はDB側でやらない方がいいことが多い
- 長く続くかわからないものは容易性を後から考える場合もある←とりあえずで作ってみようみたいなプロダクトは一旦DB設計とかを細かく考えずに作る場合もある
- テーブルによっての重要度はもちろんある
  - 根幹の部分は長い時間をかけて設計している。逆に結構枝葉の部分の設計はそこまでリソースをかけない場合もある
選ぶ企業について第一印象で決めてしまうのは機会損失でもったいない
- 必ずバイアスはあると思う
- 自分がどんなバイアスがあるかを把握しておく
自分がやりたいところ、やりたくないところを偉い人に伝えておくと良い
- 採用コストをかけて取っている人材が気分が悪くなることはしない

メンバーからのFB

教えてくれる時に優しくて心理的安全性が高い
途中途中での内容の整理が良かった
全体をまとめる動きが良かった
声が小さい
もっと自信を持っていい

技術面での学び

Dockerの拡張機能の作り方
cherry-pick
DB設計
- DB側は変更容易性を意識する←ここもっと勉強したい

総括

まずシンプルに楽しかった！3日間という短い時間だったのですが、とても濃い時間でソフトスキル面、技術面でかなりの学びがあった3日間でした。特にメンバー（というか参加者全員）の熱量がとても高く、こんな人たちと仕事をしたいなと思ったインターンでした。

今回特にソフトスキル面での学びが非常に多かったのですが、グループのメンバーがとても良かったからだと思っています。全員が「いい人」で（メンターの方も含め）、かなりスムーズにグループ活動が進んだ気がします。誰かがイエスマンとかではなく、しっかりと全員が自分の意見を持った上で建設的に話し合いが進みました（←これすごかった）。

改めて「人」が大事だと思った経験でした。もともと就活の軸に「人」を入れていたのですが、改めて面接の時だけではわからない現場の方々の雰囲気、熱量、カルチャー的なものが見えてきたのでこれからのインターンも楽しみつつ、どこが合いそうか見ていきたいと思っています！！