みなさん、こんにちは！ギフティに25年度新卒エンジニアとして入社した asano です。
大手飲食店チェーンのeギフトシステムを担当する専任プロジェクトチームに所属していて、開発からテスト、リリースまで一貫して担当しています。
今年もそろそろ終わりでキリが良さそうなので、入社してから今までを振り返ってみようと思います。（会社での振り返り時期も被っていてナイスタイミング！！）
入社してからやってみて良かったこと
フレームワークを使わずに開発してみた
ギフティの新卒エンジニアは入社後に2か月間の技術研修を受けます。この研修の最大の特徴は、「あえて便利なフレームワークを使わずに、Rubyのみを使用してWebアプリケーションを開発する」という点です。
なぜフレームワークを使わないのか
目的は、基礎的なWeb技術、データベース、アプリケーションの仕組みを深く理解するためです。配属後に現場でRailsを使用した開発をする中で、「なぜこのコードで動くのだろう？」と立ち止まって考える場面が多々あります。そんな時、研修で基礎を学んでいたおかげで、フレームワークが抽象化している裏側の仕組みを想像できるようになりました。 例えば、/users/1 のようなURLへのリクエストが来た際、Webサーバーがどのようにリクエストを受け付け、それがどのコントローラーに渡されるのかといったルーティングとリクエスト処理の全体像を把握できるようになりました。基礎を学んだからこそ、改めてフレームワークの偉大さと便利さに気が付くことができました。
アウトプットの習慣化を学んだ
研修では技術力だけでなく、「アウトプットの大切さ」も学びました。学生の頃は、学んだことをノートに書き留めておくという習慣がありましたが、コードを書いている時は調べて解決したら終わりになりがちで、調べた本質や思考のプロセスを書き留める場がありませんでした。その結果、理解したつもりで終わったり、後で同じ問題に直面した時に解決策を忘れていたりすることがありました。そこで活躍したのがtimesです。timesとは「分報」とも言われるもので、私は思ったことや調べたことをざっくばらんに呟いています。timesに呟いてみると、自分の理解が整理されます。さらに、先輩から有益な情報をもらえるチャンスが生まれます。配属後の現在も続けている大切な習慣の一つです。
同期が執筆した研修の振り返り記事がございますので、こちらもぜひご覧ください。 tech.giftee.co.jp
プロダクトのために資産を残してみた
社会人になり実務に入って最も痛感したことは、プロダクトに対する時間軸の捉え方の違いです。学生の頃は、そのプロダクトの5年・10年後なんて考えたこともありませんでした。正直なところ今動けばOK、発表までに間に合えばOKという短期的な思考で開発していました。一方で、会社のプロダクトを開発するということは、長く運用され、使い続けられることを前提とします。
なぜ資産が大事だと思うのか
長く運用されているプロダクトでは、そのコードを書いた人がもうチームにいないということが往々にしてあります。私がチームにジョインした時もそうでした。ロジックを読み解く際、過去の先輩方が残してくれたPRや、ドキュメントに何度も助けられました。コードそのものだけでなく、「なぜその実装にしたのか」というコンテキストが残っていれば、書いた人がもういない状態でも、迷わずに改修を進めることができました。
経緯や意図を残す大切さを学んだ
この経験から、自分がいなくても経緯や意図が伝わる情報を残すことを意識しています。
- PRの概要欄に、実装の背景や考慮した点を丁寧に書く
- 複雑な仕様はドキュメントに書き残しておく
私が顔も知らない先輩の資産に助けられたように、私が書くコードやドキュメントも、未来のチームメンバーを助ける有益な資産になるよう、丁寧なアウトプットを心がけていきたいです。
日報を書いてみた
研修時から続けていることで、毎日日報を書くようにしています。フォーマットはシンプルに以下の4点です。
- 業務内容
- 学んだこと、思ったこと、困っていること
- 翌営業日の業務内容
- よもやま
なぜ日報を書くのか
特に重視しているのが「学んだこと、思ったこと、困っていること」の項目です。これは一種の備忘録になっています。事象に対して思ったことがあっても、数時間、次の日になると忘れている、そんな経験ありませんか？私はよくあります。とった行動は覚えていても、その時の意思は忘れがちです。また、その日のうちに吐き出すことで頭の中が整理されます。
ちなみに、よもやまは書くことがなくてネタ切れ気味です。リモートが続くと出来事がなくてネタ切れになりがちです。出社しよう。
日報のメリットを学んだ
私が所属しているチームでは、隔週に1回振り返りのタイミングがあります。「この2週間、自分は何をしてたっけ？」と忘れがちですが、日報を見返せば一目瞭然です。最近ではSlack AIに「この2週間の間、私何してた？」と聞くと日報を元にいい感じにまとめてくれるので、非常に助かっています。
イベントに参加してみた
社内イベントだけでなく、カンファレンス、地域コミュニティなど、とりあえず行ってみる精神でイベントに参加しました。
なぜイベントに参加するのか
普段、社内ではチームメンバーと話す機会が大半です。しかし、技術イベントに行くことで、チーム外のエンジニアや他社のエンジニアと話す貴重な機会を得ることができます。イベントで新卒エンジニアの友達ができたり、イベントをきっかけに知り合った仲間と一緒に地域のコミュニティに参加する仲になったりと、想像していなかった繋がりを築くことができました。
視野が広がることを学んだ
イベントで普段話さない人と交流すると、自分とは全く異なる思考やアプローチに触れることができて、大きな刺激となります。社外に出ることで、技術的な刺激を得るだけでなく、自分の視野やコミュニティが広がっていくことを強く実感しました。
来年やってみたいこと
登壇してみたい
今年は多くのイベントに参加しましたが、あくまで「参加者」止まりでした。振り返ると、心のどこかで「自分が学んだ技術や知識なんて、周りのベテランエンジニアはみんな知っているだろう」という思いを抱いていました。この「どうせみんな知っている」という自己否定の気持ちが、登壇への最後の一歩をためらわせる大きな壁になっていました。しかし、これは「登壇は、誰も知らない最新技術を紹介する場である」という、前提の捉え方が間違っていたことに気づきました。
登壇の本質的な価値は、「自分が学んだこと、解決した課題、そして得られた気づき」を共有することにあると思います。「知らない技術を知ってもらう場」ではなく、「自分が得た学びを発信し、定着させる場」だと意識を改め、来年こそは発信に挑戦したいと思っています。
技術的な知識を向上させたい
私がチームにアサインされて最初に担当した案件は、主に既存のコードの改修がメインでした。もちろん、そのおかげで大規模なプロダクトのコードリーディングの重要性や、テストの書き方を学ぶことができましたが、一方で「ゴリゴリとコードを書く」という経験量が少なかったという課題が残りました。また、自分が触ったコードの範囲は理解できても、その外側にある機能や、プロダクト全体がどんな技術で構成されているのかについては、詳細まで理解できていない状況です。
来年はとにかく技術力を向上させることを目標としたいです。これまでは、自分の担当範囲を理解することで精一杯だったので、担当箇所の外側にある機能連携や、使用しているgemの選定理由、インフラ構成など、周辺領域まで理解の範囲を広げていきたいです。そのためには「動いているからOK」で終わらせず、「なぜ動くのか？」「どんな仕組みになっているのか？」を追求していくことが大切だと思います。ブラックボックスになりがちなフレームワークやライブラリの内部挙動に興味を持ち、疑問を持ったらソースコードを追いかける癖をつけたいです。
最後に
最後まで読んでいただき、ありがとうございます！ そして、いつも親身にサポートしてくださるメンター、チームメンバーの皆さん、本当にありがとうございます。まだまだ未熟で、これからもたくさんお世話になってしまうかと思いますが、来年は少しでも恩返しができるよう精一杯頑張ります。引き続きよろしくお願いいたします！
