新卒エンジニアが配属から今日までを振り返ってみる

eyecatch

こんにちは、ギフティでエンジニアをしているReiです。今年の4月に新卒でギフティに入社し、現在 Gift Experience（以下 GX）というチームで主にバックエンドを中心に業務を行なっています。

気付けば今年も残りわずかとなってきたので、配属されてから今日までやってきたことを新卒エンジニア視点で振り返りたいと思います。

拙い文章ではあると思いますが、最後まで読んでいただけると幸いです。

成長と学んだこと（技術 & 考え方）

まずは学んだことを中心に振り返ろうと思います。

Go 言語

私が配属された GX チームのプロダクトの大半が Go 言語を使って書かれており、私がジョインしたプロダクトもバックエンドの言語として Go 言語が採用されていました。ギフティが Go 言語を採用している理由などは過去の記事のギフティで Go を採用してきた経緯に詳細が書かれているので、ここでは省略させていただきます。

私の Go 言語の経験は入社前はほぼないと言ってもいいレベルで、A Tour of Go を少し触ってみたり、簡単なアプリを作ったことがある程度で、実務レベルの経験はゼロでした。そうした背景もあり、配属後のオンボーディングの一部として Go 言語を勉強する時間を設けていただき、書籍などを通して基礎を学びました。

まず読み書きができるようにならないと何もできないので、配属後の最初の2~3週間ほどで A Tour of Go と、O’Reilly の「初めての Go 言語」（ここでは初版を使いました。今年第2版が出ましたね。）を一通り手元で動かしながら読み進め基礎のキャッチアップを行いました。

その後、ペアプログラミング形式で簡単なタスクをメンターと共に行い、タスクを通して実務での Go 言語の書き方や、プロダクトのアーキテクチャへの理解を深めさせていただきました。

ペアプログラミングを通して理解を深めた後は、新規の REST API エンドポイントを実装するタスクや、既存の REST API の一部を改修するなどの API 関連のタスクを主に担当していました。既存の API 実装を参考にしながらほぼゼロからコードを書き、適宜メンターやチームの方にレビューや壁打ちをしていただきました。最終的に複数の API をステージング環境で動作するところまで持っていくことができました。また、この API 拡充タスクは、単に Go 言語で機能実装するだけでなく、AWS の特定のサービス仕様を調査したり、データベース周りの対応をする必要があったりと、技術スタックを跨いでいろいろなことに挑戦させてもらえる内容でした。このような経験を新卒のうちから体験させていただき、大変ありがたかったです。

最後に、仕事とは直接関係ありませんが、9月末に開催された Go Conference 2025 に会社の技術向上支援制度を使って参加させていただきました。Go 言語初学者なのでわからないことだらけでしたが、いろいろな Go 言語の仕様を知れたり、「Go 言語はこんなところにも活用できるんだ！」と感じるような活用方法を聞けたりと、とても刺激を得られる会でした。次回以降も機会があれば積極的に参加しようと思っています。

アーキテクチャ

Go 言語はデファクトスタンダードなアーキテクチャが存在せず、プロダクトの規模や要件によって柔軟にアーキテクチャを変更できます。私がジョインしたプロダクトでは DDD × レイヤードアーキテクチャが採用されていました。アーキテクチャの詳細に関しては、アドベントカレンダーの2日目のGo のアーキテクチャどうしてる？ギフティで実際に試した構成パターンを紹介しますで紹介されているので、気になる方はぜひ読んでいただけると幸いです。

入社前までは MVC を中心にアプリ開発を行なっており、それ以外のアーキテクチャはほとんど触ったことはありませんでした。その状態でいきなり業務に入るのは難しいので、Go 言語編でも少し触れたオンボーディングで「Clean Architecture 達人に学ぶソフトウェアの構造と設計」を読む時間をいただきました。

本を読み始めた当初は、新しい概念や抽象的な内容を理解することがとても難しかったです。ですが、実際の業務のコードと内容を見比べたり、自分の理解が合っているかをメンターが壁打ち形式で確認してくれる時間をとってくれたこともあり、完璧には程遠いですが理解することができました。業務に入ってからもこの本を読んだおかげか、「何もわからない」という状況はかなり少なかったです。

本のおかげで0の知識が1にはなったのですが、実際の業務に入ってから何度かアーキテクチャ周りの壁にぶつかることがあり、まだまだ知識や経験が足りていないと感じました。例えば、「この実装はこの層で良いのか？」という責務の切り分け方や、「これがここに定義されているのはなぜなのか？」といった過去の設計意図にぶつかったときに、どのような選択肢が良いのかの判断がつかなかったというものです。その都度調査や既存の実装を見直し、その結果をもとに自分なりの仮説をまとめて、メンターや同じプロダクトのメンバーの方に壁打ちをしていただきました。この壁打ちのおかげで、アーキテクチャの抽象的な考え方だけでなく、プロダクトの設計への理解を深めることができました。

相談の仕方

入社してから個人的に一番成長したと感じているのが「相談の仕方」です。学生時代にも友人や教授に講義や研究に関することを相談させてもらう機会はありましたが、その際は「自分のペース」が中心でした。

私は学生時代、特に時間を決めずに自分が納得するまで調査を続け、自分の意見を持たずに調べた結果だけを持って相談をするか、あるいは自分の中で正解が完成してからようやく相談する、といった方法を取っていました。この方法でも、学習や研究を進める上では特に困ることはありませんでした。

しかし、プロダクト開発という業務の世界に入ると、このやり方では大きな壁に直面してしまいました。

開発遅延の発生: 学生の時間と比較すると業務時間は限られており、一つの調査に時間をかけすぎるとプロダクト開発全体の遅延につながってしまった
コミュニケーションにかかるコストの大きさ: どこまで私が理解できているかを共有しないまま相談する形になってしまい、質問された方々が私の理解度を把握できず、そこの確認作業から入るようなケースもあり、無駄な時間を取らせてしまったことがあった
手戻りのリスク: ある程度進めた状態で相談をしてしまったことがあり、その際に「もし方向性が間違っていた場合、大きな手戻りが発生してしまう可能性がある」というフィードバックをいただいた

これらの経験を踏まえて、現在は次のような形で相談をするように心がけています。

調査時間に最大値を決めて、一定時間が過ぎたら相談するために現状の調査の結果をまとめる
相談をする際に、困っていること、試したこと、自分の仮説、何を聞きたいのかをセットで伝える

この形に変更してから、相談相手との無駄なラリーが少なくなり、本質的な相談のみの時間で済むようなケースが増えたと感じています。また、質問をまとめる際に、自分がどこまで理解をしているかをまとめられるので、質問相手だけでなく自分が整理できるという点でも変えて良かったと感じています。

現状の課題

プロダクト・ドメインの知識不足

入社から8ヶ月、配属から6ヶ月が経った現在、最も課題だと感じているのはプロダクトとビジネスドメインに対する知識不足です。私が所属する GX チームでは、複数の部署が横断的に利用するプロダクトを開発しています。そのような背景から、チームで行われるミーティングの議論では、他部署の知識やビジネス背景を知らないと議論についていくのが難しいケースなどがあります。都度前提の知識を説明してくれたりもするのですが、その場で初めて知るドメイン知識も多く、自分の中で整理している間に議論が進んでしまうケースがありました。せっかくミーティングに参加させていただいているのに、特に発言ができないまま議論が終わってしまうことに、強い課題感を持っています。また、プロダクトに対する知識不足に関しては、携わるプロダクトのあるべき姿を自分の中で確立できていないという問題にもつながっていると感じています。その結果、仕様の検討やミーティングで意見を求められた際に、ビジネス的・プロダクト的な根拠を持って意見を言えていないと感じることがあります。

技術全般の知識不足

Go 言語については基礎的な文法のみを理解している状態で、標準ライブラリの仕様把握や、「Go 言語らしい」と言われる効率的なコードの書き方への理解などが不足していると感じています。また、アーキテクチャに関しても、機能開発をする上での必要最低限のことしか把握ができておらず、DDD や CQRS などの設計思想についてなどは学習不足を感じています。他にも、業務では Go 言語やアーキテクチャ以外に AWS や DB、GraphQL など様々な技術を扱っていますが、どれもまだ基本的な利用方法しか理解できていません。これらの技術全般への知識不足は、特にチームでの議論の際に顕著に感じています。質問や相談の際に自分なりに仮説を立てて臨んでも、知識の裏付けがないため、質が低いあるいは見当違いな考えになっているのではないかと不安になり、チームメンバーの貴重な時間を奪ってしまっていると感じています。