新卒3年目、最初の3ヶ月。一皮むけた（気がする）ジュニアengの振り返り

3行サマリー

これまで短・中期のプロジェクトリードがメインだった自分が、新卒3年目になり初めてプロダクト全体に影響が出る技術的な改善で成果を出せて嬉しかった、という素直な気持ち
なぜそれができたのか？を振り返ると、「自発的な興味」と「環境の変化」という2つの要因があった
出社は色々な機会に恵まれる

はじめに

こんちゅわ。freeeのエンジニアのnagiです。freeeに2023年に新卒で入社し、2025年6月まで「freee申告」プロダクト開発部門で主に個人事業主向けの確定申告周りの機能開発を担当していました。この記事はこのときの話です。2025年7月現在は異動し、「freee人事労務」の開発を担当しています。

普段は機能改修などのプロジェクトリードなどを担当することが多いのですが、新卒3年目で初めて、技術的な改善でプロダクト全体で自分なりに成果を出すことができました。正直、嬉しかったので、今回は「なぜうまくいったんだろう？」という点を自分なりに振り返ってみたいと思います。

何が良かったか？

ブラックボックスになっている内部に興味を持つようにした

意識的に、技術的なことについて興味を持つようにしました。そして、「自分の管轄でできそうなことは実際にやってみる」というマインドで3年目になってからは仕事していました。自分は、本を読むより実際に仕事で取り扱う方が圧倒的に吸収できるタイプです（おそらく多くの人がそうではないかなと思います）。

僕の場合は、アプリケーションレイヤーのエンジニアにとってはブラックボックス感のあるインフラ周りに興味があって、社内の記事とかを読んだりしてました。

例えば、バックエンドでRuby on Railsを利用している「freee会計」では、メモリ使用量・インフラコストの観点で、メモリアロケーターが「malloc」から「mimalloc」に変更されました。その社内記事を読んで早速、自分たちのfreee申告でもメモリ使用量・インフラコストの改善を狙って、メモリアロケーターを同様に「jemalloc」を導入しました。その結果、実際にメモリ効率が改善されました。そこから、さらにメモリ割り当ての調整を行ったり、確定申告期にはスロットリング解消などもサポートをもらいつつプロダクト全体のパフォーマンス改善を実施しました。

プロダクト開発チームに所属していると、インフラみたいな基盤周りに目を向けることが少ないし（これは健全な証拠でもあります）、OKR達成が最優先になるので、意識的にインフラへ興味を向ける必要がありました。freeeは、それが「マジ価値」だったらなんでもできる環境である反面、強制的にやらされるということがないホワイトな環境であるからこそ、自分から興味関心を持ってキャッチアップすることが結構大事であると考えています。

（「結局技術力の伸びって自分の興味の問題なんだよね」という話を部長との1on1でしました。）

規模が大きすぎない部署に異動して相談しやすい環境だったこと

僕はfreee申告開発部門に異動するまで、freee会計の所得税・消費税機能を開発するチームに所属していました。

freee会計開発部門はプロダクトもチームの数も多く、何か基盤系に変更を入れようとすると、影響がほぼ読めなくて、自分みたいなペーペーのジュニアがOKR以外の部活動的な改善を入れるにはハードルが高かったです。

一方で異動先のfreee申告開発部門は、会計と比べると規模は小さく（あくまで会計と比較して）会計ほど影響が読めないわけではなかったです。さらに申告部門では、部門全チームで共有・相談・称賛を行う「dev monthly」といった月次のミーティングがあったり、freee申告の基盤部分専門のSlackチャンネルがあったりして、そこでなんでも相談できる環境がありました。

会計部門にもそういったコミュニティ・チームはありましたが、自分がいたチームの組織とドメイン的に距離があり、そこに参加するには若干のハードルがありました。

あとは、申告部門には「この人に承認もらっておけば大丈夫でしょう」という人がいて、なおかつその人がほぼ出社していて、10分くらいで同期的にサクッと相談できる環境があったというのもかなり大きかったです。

例えば、freee申告内の電子申告データ出力の速度をmax10s → 2s まで縮めるパフォーマンス改善施策を行いたかったのですが、この改修は申告プロダクト全体、全ての税目に影響がありました。しかし、前述の通り常に相談できる人がいたからこそ、実装に加え、リスクアセスメントやQA実施方針等も相談でき、無事最小限のコストでリリースすることができました。