この記事はSchoo Advent Calendar2024の2日目の記事です!
株式会社Schoo 新卒1年目の @hiroto_0411です!
気がつけば今年も終わりということで、入社してから約8ヶ月での「学び」と「変化」について書いてみようと思います!
エンジニア研修
5月~7月の約3ヶ月間は、エンジニア研修がありました。基本的には新卒エンジニア+社内エンジニア(講師)という少人数で行われます。内容は、エンジニアの心構えやリーダシップなど働く上で大切になる考え方からGo、AWS、データベース、アーキテクチャなど技術的な内容まで、エンジニアとして仕事をする上で必要な知識を網羅的に学ぶことができる構成でした。(内容の詳細は上記の図を参照)
独自の問題を作成してくださる方がいたり、200ページに迫るような資料を作成してくださる方がいるなど、どの講義も内容が濃く成長を感じられる研修でした。
個人的にこの研修で一番良かったのは、多くのエンジニアの方と長時間関わることができたということです。大体の講師の方と1~2日関わることでその人の人柄を感じることができ、仕事のしやすさがグッと上がり、会社のことをより好きになった気がします。
この期間中、私が意識していたのは講義後に書くレポートで、習った内容プラスαの内容を入れることです。AWSでGoのコードを動かしてみたり、講義で使ったツール(OSS)にコントリビュートしてみたり使える知識にできるよう心がけていました。レポート作成をする時間がたっぷりとあったことで学びを深める時間を取れたのも嬉しかったです。
エンジニアとしての業務
研修が終わり、8月からは実務に入りました。「最高の開発体験とサービスの安全性を創る」ことを目指し、既存サービスのリプレイスやリファクタリングを中心として行うチームに所属し、バックエンドメインで仕事を行なっています。
やったこと
-
開発部門の色々な会議に参加
- 理解しきってはいない状態でも、考えや感想を言うことを意識した
-
自分のいるチームでの会議では1ヶ月間全てファシリテーターを担当
- ただ、進めるだけではなく適宜まとめる、事前におおまかな流れをイメージするなど意識した
- まだ課題がある部分なのでより効率的に目標を達成できるファシリを目指したい
-
バッチ処理に関する実装
- 初めてプロダクトのコードに触れたタスク
- 処理に合わせてk8sのmanifest修正
- 先輩とのペアプロにより自分に足りていない力を実感
-
負荷試験
- k6を使ってサービスの負荷試験を実行
-
認証・認可サービスの調査・設計、リプレイス作業
- フローチャートの作成
- テストケースの作成
- API設計
- 性能要件調査
業務を通して色々な開発の工程を担当させていただき、学びが多く充実感を感じる日々でしたが、技術力・知識不足を感じることも多く悔しさも残りました。
そんな中でエンジニアとして働く上で大きく意識を変えた点が以下の2点になります。どちらも上司の方との2on1や1on1 を通して意識が変わりました。
-
タスクの分割を意識するようになった
- 学生時代もインターンなどで軽く開発に関わる経験がありましたが、特に個人で行うタスクについては分割をなんとなくでやってしまっていました。そんな中で、実務に入ってまず行ったのがタスク分割を行うというタスクであり、「他の人が見ても実行できるくらい詳細でわかりやすくまとめることを意識してほしい」 と教えていただきました。
-
技術力・知識がないなりの振る舞いを考えるようになった
- 技術力・知識がなく、「会議で話されている内容が全くわからずに意見することができなくて悔しい」という相談をさせていただいた時に、「技術力・知識は段々とついてくるもの、それがないなりの振る舞いを考えるのが良いのでは」とアドバイスをしていただきました。「何も分かっていないと思われたくないなぁ」という思いから、ある程度内容を理解した上でないと質問することができなかったり、ある程度形になっていない段階で進捗を見せるのができていなかったので、このアドバイスは私にとても刺さる内容でした。
まだ、改善の途中ですが「気軽に質問したり、感想を述べる」、「完璧でない状態でも一旦見せてみる」というのもスキルの1つだと思って技術力・知識がないなりの振る舞いをできるように心がけるようになりました。
- 技術力・知識がなく、「会議で話されている内容が全くわからずに意見することができなくて悔しい」という相談をさせていただいた時に、「技術力・知識は段々とついてくるもの、それがないなりの振る舞いを考えるのが良いのでは」とアドバイスをしていただきました。「何も分かっていないと思われたくないなぁ」という思いから、ある程度内容を理解した上でないと質問することができなかったり、ある程度形になっていない段階で進捗を見せるのができていなかったので、このアドバイスは私にとても刺さる内容でした。
テックブログの運営
エンジニアとしての業務と同時に、テックブログの運営も行いました。スクーとしてテックブログを2024年9月から再開させており、そのための執筆ルール決め、どのプラットフォームで執筆を行うのか、なぜ会社としてテックブログを始めるかの共有などスクーとしてテックブログを始めるという仕事を任せていただきました。
テックブログの詳細は以下の記事に書いたので見て頂けたら嬉しいです!
テックブログ運営で1番苦戦したのは、「周りの巻き込み方」と「プロジェクトの進め方」です。
当初、プロジェクトはチームで進めるのが正解と思い込んでおり、テックブログを始めるにあたって、まずチームを作成しテックブログの理想を考えるところからみんなで行おうとしました。
もちろん理想や仕組みについて考えることも大切ですが、それをチームで決めるということにこだわり過ぎたことでテックブログがなかなか始まらない状態になってしまいました。
そんな時に、「プロジェクトを始めるときはその熱が冷めないうちにとりあえず始めてみることも大切、熱が冷めないようにするにはスピード感を持って進めることが大切である」 というアドバイスをいただきました。
このアドバイスをいただき、「周りを巻き込む=チームを作ってみんなで決めていく」と思い込んでいましたが、考え方を変え 「プロジェクトでより良い結果を出すために必要なタイミングで必要な人を巻き込む」 ことを意識するようになりました。「スピードを重視したい時はある程度一人で決めてからそのレビューをしてもらう」、「じっくりと考えるべきタイミングでは会議を開き意見を出し合う」など巻き込み方と何をすべきタイミングなのかの意識をするように心がけました。
まだまだ一人で考え込み過ぎて共有が遅れるなど、私自身の課題はたくさんあるので色々試しながら「プロジェクトでより良い結果を出すための巻き込み方」を考えていきたいです。
日報
スクーの新卒1年目は日報を投稿する文化があります。最初の半年は先輩社員との1on1がほぼ毎日あり日報をもとに1日の振り返りを行っていました。(1on1の頻度や日報の使い方は人により差があります)
私は以下のフォーマットで日報を書いています。
【今日やったこと】
【学んだこと/思ったこと】
【今日のGood】
【今日のMore】
【次回やりたいこと】
この8ヶ月で一番変わったのが、Moreについての考え方です。当初は、「今日は〇〇ができなかった」みたいな感じで出来事だけを書いていたのですが、「1on1でなぜそれができなかったと思いますか?」「それを改善するためにはどういう行動をすべきだと思いますか?」と深掘りしていただくことが多かったです。この問いかけが段々と自分で出来るようになり、何が悪かったのか、次やるべきことは何かまで書くことを意識するようにしました。
また、フォーマットにとらわれすぎず、少し考えてもMoreが思いつかない日は「今日は頑張った!」と自分に言い聞かせて無理に小さなMoreを探さないというのもこだわっています。
日報は評価面談などに向けて自分の振り返りを行う際にも役立つと実感しています。当時どう思っていて、どんな変化をしようとしていたのかは変化した後だと忘れてしまうこともあると思うので変化を実感する手段としても利用できるなぁと思っています。
さいごに
エンジニアとして入社して8ヶ月を振り返ってみました!
振り返ってみると、エンジニアとして技術にも色々触れながら、社会人としての考え方や仕事の進め方についても学びが多い期間だったなと思います。エンジニアって技術力をひたすら磨くイメージでいたのですが、それ以外にも学ぶことがたくさんだなと実感しました。
若手のエンジニアの方や、新卒育成に携わっている方、スクーでの働き方に興味がある方の参考に少しでもなったら嬉しいです!
Schooでは一緒に働く仲間を募集しています!