もう年度の節目ということで、新卒エンジニア１年目を振り返ることにしました。
私は学生時代に開発経験が多少あり、IT経験者として入社しましたが、実務に１年取り組んでみて何を感じたか、直面した壁や気付きを中心に書きたいと思います。
4月〜8月：（研修）
経験者でのチーム開発で自己組織化を学ぶ
はじめに、新卒社員のうち経験者のみでアジャイル開発研修を行いました。
初めてのチーム開発でした。
私はこの研修で、チームの成果を最大化することを第一の目的とし、アジャイルサムライという本で学んだ、自己組織化を実践してみました。自己組織化とは、すごく簡単にいうと自分の強み・特徴を活かし組織に貢献するというものです。
本当は、自分が技術者として成長するためにできるだけ自分が多くコーディングを行いたかったです。
ですが、細かいところに意識が向く自分の特徴を活かしたほうがチームの成果が最大化されるのではと考え、コード自動フォーマッターの導入やリファクタリングの提案など、メンバーが開発しやすいように環境を整える縁の下の力持ち的な役割にシフトしました。
自分の特徴をチーム内でどう活かすかという観点を養うことができ、開発自体は楽しく完遂することができました。
苦戦したチームリーダー
次に、新卒社員未経験も含めたチーム開発を行いました。私はプログラミング経験者としてテクニカルリーダーを務めました。ですが個人開発しかしてこなかった私にとって、チーム開発でリーダーを務めることは思っていた以上に難しかったです。
特に難しかったのは、
- 誰にどの仕事をどの分量でお願いするか
- 自身が軽度のHSPなこともあり、お願いした仕事を相手がどう感じているか考えてしまう
- 応急処置
- メンバーの得意分野・性格的特徴を知り、それを判断材料にした
→ 例）成長のためにあえて不得意分野に取り組んでもらうなど
- メンバーの得意分野・性格的特徴を知り、それを判断材料にした
- メンバーを成長させることの難しさを実感
- エラーで詰まったときに正解をそのまま教えてしまった
- ヒントや解決の糸口のみを教えることで本人の根本的な技術的成長につなげることができたのではと反省した
- エラーで詰まったときに正解をそのまま教えてしまった
あくまで、この研修の目的としては開発物の完成度よりも新入社員の技術力向上のほうが大きかったのですが、開発物をより良いものにしたい気持ちも大きく、両者のバランスの取り方も難しかったです。
個人開発研修
個人で勝手にテスト駆動開発を学び（もちろん研修時間外で）、研修で実践しました。
テストコードを実際に書いたわけではないですが、考え方を取り入れて開発していました。これにより、まず目的を考えるクセがつきました。
学んだことは、この記事に書きました。
9月以降：（配属後のリアル）
キャリア観の挫折・視野の狭さに気づく
自分の中での「ITエンジニアのキャリア」は、＝「Webエンジニアのキャリア」となっていて、視野が狭い状態でした。なんとなく、バックエンドエンジニアとして３〜５年コードを書き、徐々にリーダー/PMポジションになるくらいに考えていました。
しかし、実際の配属はデータ基盤に関する部署でした。学生時代に簡単なWebアプリ開発、機械学習には触れていましたが、データ基盤は初めて聞く言葉で「？？？」状態でした。この予想外の配属に戸惑い、いかに自分のキャリアについて適当に考えていたかを痛感しました。この部署での仕事を通してどんなキャリアを描けるのかわからずはじめは不安でした。
挫折からの立ち直り・マインドの変化
部署の中で私がアサインされたのは社内データ活用基盤の新規構築案件でした。
その案件の業務では、データ基盤を構築する際のAzureのネットワーク構成について検討する機会が多かったのです。構築するネットワークにより自社のポリシーを満たすセキュアなデータの受け渡しが実現できるかといった検討が進められました。
私はネットワーク分野・クラウドインフラの知識・経験がほとんどなく、キャッチアップしていくのは大変でした。ですが、システムのネットワーク構成を企業レベルで俯瞰して見る・理解することは楽しかったです。
また、先輩からおすすめされた ITアーキテクチャのセオリー を読んでみると、自分がアサインされた案件は、EAの中でも重要なDAの構造を変革する重要な案件であることがわかりました。かつ日本では前例のないアーキテクチャを構築しようとしているということで、やりがいを持って働くことができました。
それからは、キャリアについては情報収集しつつ、まずは今は配属された部署で吸収できる技術を吸収しきるマインドに切り替えて努めました。
ソフトスキルの壁### ソフトスキルの壁
- マルチタスクに苦しむ
- もともとめっちゃ苦手
- とにかく、仕事を振られたらすぐに期日も添えてKANBANに投げる癖付け
- タスク依頼元のチャットリンクも添える
- 業務のメモ残しと、その検索性について
- 一度任されたタスクを再度振られた際に、一度目に先輩に教わりながら取り組んだときのメモが見つけきれず、泣く泣くもう一度聞いてしまう失敗があった
- 酷いときはそもそもメモしていないこともあった
- 検索性の工夫を行い乗り越えつつある
- フォルダ整理
- VScodeの文字検索機能で即アクセス
- メモ先を基本VScodeに統一
- メモ時、どこにメモするかという迷いをなくす
- メモを探すときの迷いをなくす
自分のキャパを超えて色々手を出した（悔いはない）
- 社内AI勉強会での輪読会
- ゼロつくの内容がなかなか重く、インプットして発表できる形にアウトプットするのに時間がかかった
- 量子コンピューティング勉強会の参加
- 学生時代の数学の勉強が甘くついていくのが大変だった
- プライベートでのWebアプリ開発
1年目は技術を吸収し切ることに振り切りましたし、どれも自分の技術力を高めてくれる非常に有益な活動でしたので後悔はありません。また、こういった勉強はすればするだけ物事を身につける速度が早くなると信じています。
ですが今後は優先順位つけて取り組む対象を絞り、徐々に成果を出す方にシフトしていきたいと考えています。
技術キャッチアップで大変だったこと
非定型業務である点
維持管理ではなく、データプラットフォームを新たに自社ネットワークに導入する取り組みだったため、要件が固まっていなかったり過去事例がないなど、否定型業務ならではの難しさがありました。
ユーザー企業へのデータプラットフォーム導入時には、課題や検討事項が大量にあり、その一つ一つを理解する前に次々と課題が解決され流れていってしまうという現実も、キャッチアップの難しさを一層際立たせていました。
幅広い知識が求められる点
具体的には、ネットワークやAzureの知識、自社のネットワーク構成、Databricksに関する知識、一般的なデータエンジニアリングといった分野の知識が求められました。
学んだ知識の整理がついていない、点と点が繋がらない感覚が続きました。業務で使われる用語や技術が、Databricks固有のものなのか、データエンジニアリングの一般知識なのか、自社独自のものなのか、どれがどれだかわからず混乱しました。
また、Webアプリ・機械学習領域のように「この書籍・サービスでこの分野は体系的に理解できる」というような教材が豊富な分野ではなく、キャッチアップが非常に困難でした。
いくつか先輩からおすすめいただいた技術書をつまみ食いしたり、公式Docを読んだりしていました。
3月以降：思うこと
配属案件でのキャッチアップは大変でしたが、この案件だったからこそ成長できたことがあると思っていますし、1年目から新規構築案件の基本計画から携わらせていただけるなんて、大変ありがたい環境だったと思っています。
この記事に書ききれなかった取り組みや、先輩方の教育のおかげで、ようやく学んだことの点と点がつながってきた感覚があります。
これからもこのありがたい環境を活かしきれるように、楽しみながら技術を吸収したいと思います。
また、この記事に書ききれなかった１年目にやってよかったことについては、また別の記事でまとめようと思います！