Speeeインターンに参加して

2022年夏、株式会社Speeeさんのインターンシップに参加しました。 未来の参加者のために選考フローと対策の勘所を、自分のために学びの備忘録を残します。

インターンシップの概要

Speeeのインターンでは、サービス立ち上げを以下の日程で行いました。詳細はSpeee開発者ブログをどうぞ。

1. 1day: 事業戦略からDB設計

2. 12days: サービス設計→実装

選考では思考の言語化が大事

選考過程は以下の通りです。

1. サポーターズの1on1面談イベントで人事+エンジニアと面談
   馬が合いその場で選考に進むことに。

2. 技術面接
   これまでの開発経験を言語化しました。開発経験に至った背景、技術選定理由、ぶつかった課題とその解決など。私は学び続ける姿勢（”ラーニングアニマル”）が評価されたようで。経験をしっかり振り返れていた点、体系化された・再現性ある学び方を持っていた点かな。

3. 人事面接
   今後のキャリア観、性格に影響した経験などを聞かれました。うまく言語化できなかったですが、相槌や深掘りなどとても話しやすい流れを作っていただきました。あと目標に向け夏はどんな経験・知見を得たいかなど、私の成長機会とインターンの相性を深く考えてらっしゃる印象を受けました。

4. コーディングテスト
   基礎的なプログラミング経験があれば問題ないはず。

5. 1dayインターン
   12daysの選考も兼ねていたようで。議論で方針を予めはっきりさせた点が左右したかな。

12days参加者の多くが似たルートでしたが、他にも、Athletics→2〜のルート、1dayなしに1進んだ個別ルートの方などもいました。

特徴的な目標設定と振り返りの文化

Speeeさんでは、目標を設定し面談を通して評価・改善を繰り返す文化が浸透していて。 実際にこの経験でも、身につけたい目標を事前に設定・深掘り、最中の振り返り、事後面談での評価で体感しました。特にインターン最中では毎朝その日の目標を掲げ、終業時に振り返りと明日の指針を決める、1日置きに1on1面談でFBを受ける、開発スプリント毎にKPTを議論する、など機会に溢れてました。

私たちがこのインターンで届けたいことは、 自分の得意不得意を知り、 エンジニアとして生きていく指針を見つけてほしい という思いがあります。

何度転生しても受けたい異世界インターンの話 ～Speee 23卒エンジニアサマーインターン～

と謳われるように、まさに今後の指針を見つめる上で絶好でした。その後の就活のためにも、この内省と客観視、実践のサイクルを夏に経験できてよかったです。

学び

【1day】 再認識した3つの視点

1dayでは、チームメンバーのレベルが高いこともあり、選考過程ながら多くの学びがありました。ここでは、意思決定軸・多面的思考・メタ認知の3点について書きます。

この1dayはなかなかのボリュームながら、私のチームは順調すぎるほど議論が進みました。これは最初に意思決定軸を「MVPを作り切る」と決めたため。いきなり設計に入りあれもこれもと肥大化するより、必要な取捨選択を経て詰めていくことがいかに重要かを深く理解できました。

また、メンターの提案に乗るときに他のメンバーが発した「賛成。だけど理由は違う。〜の面で。」という言葉にハッとさせられました。これこそ意見を鵜呑みにせず多面的に議論する姿だと。自分の現状を直視し、目指す一面をはっきりと見据えることができました。

すべて順調かというと個人的にはそうではなくて。議論は進んだのですが、メンバーの中には突っ走る方もいて、合意形成が疎かになっている・個人的に腑に落ちていない、という肌感がありました。その最中に再発見した自分の志向性として、「もらうだけで周りに価値を与えられない環境が苦痛である」ことや「表層の進捗よりメンバーの足並みが揃っているかを重視する」ことなども持ち帰りました。

これらの学びは周りのレベルが高かったおかげであり、12daysでも同様に横の刺激が得られると期待できたのも収穫でした。

余談ですが、この1dayが12daysの選考を兼ねている旨は直前に知らされ当時とても焦りました。他社インターン選考などの兼ね合いもあるため、予めうかがっておくといいかも。

【12days】 困難は"適切に"分割せよ

12daysは、頻繁な目標設定と振り返り、メンバーやメンターとの議論、コードレビューなど、あらゆるレイヤーで考え続けた期間でした。その中でも1番の困難だった進捗の遅れについて。

1dayとは対照的に、12daysでの開発進度は大幅に遅れました。その1番の原因は分担するタスクが不適切だったこと。開発最初期にMVCパターンにおける縦割りでIssueを分割してしまい、それが悪手でした。問題は以下の2点。

1. バラバラなPR粒度
   モデルを一気に実装した重いPRはレビュー負荷が大きかったり、片や小さいViewの変更のみなど小さなレビュー依頼による横槍が多かったり。PRが出されるまで個人の進捗が全く見えない、レビュー待ちとその修正がボトルネックになる、コンフリクト地獄になる、などてんやわんや。

2. タスクの相互依存
   縦割りのせいでタスク間に依存があるものの多く、マージ前はハードコーディングで開発を進めていたことも。そのせいで修正のタスクも追加して。遅れが遅れを呼んでは際限なく。

結局、後から残りのIssueを全て切り直し、開発を巻き取りました。

Issueはマージすると1つの機能が出来上がるのが理想。このようにタスク間を疎結合に・適切な粒度にというアーキテクチャ論に通ずる学びを自分の経験として語れるようになった、苦くて楽しい機会でした。

おわりに

Speeeさんのインターンにおける最大の価値は、学生の成長にフルコミットしてくださることだったと思います。大事なのは自分の成長に当事者意識をもち、「したい・なりたい」やその過程をしっかり言語化・行動すること。それぞれに合った成長が待っているはず。