この記事は LITALICO Engineers Advent Calendar 2025 シリーズ2 の6日目の記事
です。
はじめに
こんにちは、25新卒でエンジニアとして株式会社LITALICOに入社した@hajimennnです。
本記事では、ひよっこエンジニアとして入社してから現在まで、どのような経験をしたり、どのような課題を抱えたりしていたかを振り返ろうと思います。
同じような状況の若手エンジニアの方や、育成担当者の方のお役に立てば幸いです。
前提
- 25新卒ですが、内定者インターンとして2024年5月から同じチームで業務を行っていたため、期間としては約1年半ほどの内容になります
- 入社時に実務経験は少しありましたが、使用する技術スタックは初めてのものがほとんどでした
- 本格的なチーム開発も初めての経験でした
入社0ヶ月
入社直後はキャッチアップの時期で、主に以下のインプットを行っていました。
- 使用している技術やフレームワーク
- 複数プロダクトの役割や機能
- 事業・業界知識
個人的に漠然と知識を取り入れることが苦手なこともあり、当時は何が何だかわからなかったと記憶しています。
また、チームでは「毎日30分のメンターとの夕会」と、その前に「日報を記載」する時間が設けられ、その日に学んだことや疑問に感じたことなどの振り返りを行うことになりました。この時間は（頻度は減りましたが）今も続いており、非常に多くの学びや成長につながった良い時間であったと感じています。
入社1ヶ月
一通りのインプットを終えたところで、簡単なタスクを振っていただけるようになりました。
この頃から、新しいタスクや技術に触れることが楽しくなる代わりに毎日の振り返りや日報をおざなりにすることが増えていました。当時の私は、正直なところ以下のように考えていました。
- 「今日やったことなんて、コードを見ればわかるじゃん」
- 「書くことが思いつかない、この30分があればタスクを進めたい」
そのため、日報の内容も事実を並べただけの中身のないものになりがちでした。
▼ 当時の日報の一例
今見るといかにもやっつけ作業の適当な内容だなと思います（笑）。
メンターからのフィードバック
この際に、メンターから以下のフィードバックを受けました。
- 最初は時間がかかるが、とにかく丁寧に事象を振り返り、改善策や再現性について考えよう
- 技術のインプット30分より、日報をちゃんと書く方が、今は優先度が高い
- PDCAを回すという基礎的なポータブルスキルをまずは身につけることが最優先
今改めてこのフィードバックを振り返ると、単なる業務報告の質を高めるだけでなく、将来チームを異動したり転職したりした際にも役立つような「汎用的なスキル」を身につけさせようとしてくれていたのだと思います。
当時の私はこれを聞いてもまだピンと来ておらず、「色々言われるのが面倒くさいな...」と渋々詳しく書くようになりました。しかし、丁寧に振り返りを行うことで様々な学びを得たり、意識せずとも振り返りができるようになったりと、今では非常に意味のある訓練だったと感じています。
入社2~5ヶ月
この頃には個人としての小さなタスクを一通りこなせるようになり、少しずつ大きいタスクや他の人との連携を必要とするタスクが増えてきました。そんな中で、技術的なことよりも他者とのコミュニケーションに難しさや課題を感じることが多くなりました。
「議題を持っていく」こと
当時の私は、チーム全員がいる朝会や定例MTGで発言することにハードルを感じており、何か相談事があっても夕会の場でメンターに聞くだけに留まっていました。
しかしメンターとの、
「それは俺だけじゃなくて、チーム全体で相談した方がいい内容だね。明日、朝会に持っていってみよう！」
というような会話をきっかけに、少しずつ「これは朝会に議題として持っていこう」と自分で判断できるようになっていきました。
「相談の質を高める」こと
最初はただ「この部分をどうしたらいいか迷っています」というレベルでしか伝えられず、自分の中でも言語化できていない状態で相談してしまうことが多々ありました。
その結果、「整理してからまた後日」となることも多く、「伝えたいことがうまく伝わらない」「時間がかかる」という状況に陥っていました。
そこからメンターのFBを受け、以下の形式を習慣化しました。
- 丁寧にメリットデメリットやコストを含めた選択肢を提示する
- その上で、自分の意見を持っておく
これを都度調整しながら運用し心がけることで、スムーズに議論に入っていくことができるようになりました。
「情報の取捨選択をして伝える」こと
相談ができるようになると、今度は「丁寧に準備をしすぎた結果、必須ではない細かい内容に触れすぎて議論が長引く」という新たな問題が生まれました。
特に、デザイナーやPdMの方に実装の詳細な話をしてしまい、前提理解に時間を使いすぎたり、判断軸がブレてしまったりすることがありました。
そこでの振り返りから、相手に合わせて情報を絞るようにしました。
- プロダクトレベルでどういう影響があるのか？
- その上で実装工数がどれぐらいかかりそうか？
このように、判断を仰ぐ相手に必要な情報を取捨選択して伝えることを心がけるようになりました。
また、議論の方向性がずれたり、話が膨らみすぎるというような課題感を持つこともあったのですが、そちらに関しては新卒選考の際からお世話になっている先輩の @taka-fujita さんの記事が非常に参考になったので、ぜひ併せてご覧ください。
▼ この頃の日報
以前より事象の振り返り等が詳細になっているように感じます。
入社6~10ヶ月
大きめのタスクもこなせるようになってくると、自然と開発チーム内外との関わりが増えてきました。業務にも慣れてきたこともあり、与えられたタスクをただこなすだけでなく、積極的にコミュニケーションをとる行動が多くなっていきました。
- 仕様やデザインで曖昧な点を放置せず、できるだけ細かく確認する
- 仕様検討を行うミーティングに参加し、積極的に意見してみる
- 社内向け管理画面の改善タスクでは、実際に利用している社員にヒアリングを行う
元々細かい情報を整理したりするのが好きな性格もあり、自然と上記のような行動をとっていたところ、以下のようなフィードバックをいただけるようになりました。
- 「仕様確認が緻密で助かっている」
- 「チーム内外を問わずコミュニケーションが取れており、越境力が高い」
色々と裁量のあるタスクを任せていただいたことで積極的な行動に結びつき、それを機に良い印象を得るという好循環が得られたと感じています。
~現在
上記のような行動は半ば無意識に行っていましたが、新卒として正式に入社し、インターン時と同じチームに配属されたことを機に、より意識して積極的な行動をとることを心がけるようになりました。
具体的には以下の通りです。
- slackのメッセージに積極的に反応、コメントしてみる
- 先輩社員がやっていて、自分がまだできていない役割を意識してできるようにする
- ビジネスサイドの業務で、分からない内容を聞きにいく
こうした行動を重ねることで、少しずつ「自分ができることの範囲」を広げていくことができていると感じています。
結果として一部ではありますが、「チームで自分が一番解像度が高い箇所」や「この部分は第一に自分に任せてもらえるような箇所」も増えてきたように思います。
最後に
最初は言われたことに従いながら少しずつ学びを得ていき、そこから積極的な行動へとシフトしていったことが、タイトルの「信頼を獲得する」ことにつながったのだと思います。
（本当に信頼されているかどうかは保証できません、あくまで体感です。）
もしチームへの貢献の仕方や幅の広げ方に悩んでいる人がいれば、
- まずは任されたこと、言われたことを愚直にやってみる
- 日々の振り返りをもとに少しづつできることの幅を増やしていく
- 現状足りていないこと、チームで求められている役割を探し、積極的な行動をとる
というステップを踏むことで、自身の成長だけでなくチームから信頼を得て、貢献することにつなげることができると感じています。
最後に、入社当初から大変親身に接していただき、私の成長に一番寄与してくださった大尊敬のメンター @k_orita さんにこの場を借りて感謝申し上げたいと思います。
今後ともよろしくお願いいたします！！！