新卒エンジニア研修を終えて ─ 2ヶ月で得た学びと成長

はじめに

こんにちは。株式会社bitAで25卒エンジニアとしてキャリアをスタートしました、すずけん(@suzuken0210)です。
本記事では、約2ヶ月間にわたって行われた研修について、学びや成長を振り返りたいと思います。その中で、私がどのように課題と向き合ったのかを、ハードスキル（技術力）とソフトスキル（コミュニケーション能力）の2つの側面に分けてお伝えします。 私と同じように、新卒でエンジニアとしてのキャリアを歩み始めた方の参考になれば幸いです。

研修の全体像

私は初期配属としてグループ会社のourlyに加わりました。そのため研修では、ourlyが実際に提供しているプロダクト「ourly」の既存の機能をRuby on Railsを使って再実装するという内容でした。プロダクトには、記事にコメントを入れる機能があり、本研修ではこのコメント作成、編集、削除のAPIとそれぞれのテストコードを実装するという内容でした。
各機能ごとにプルリクエストを作成し、現場のエンジニアからレビューを受けるという流れで研修が進んで行きました。

実際に作成したコメント投稿機能

ハードスキル面での学び

ここからは、研修を通して学んだことを、ハードスキルの側面から振り返ります。 一言で言うと、「動くコードを書くのは当たり前。その上で、「将来の自分やチームにとって『良いコード』とは何か」を考えた2ヶ月間でした。

要求は「最小限」で満たす

コードは、自分以外のメンバーが読むことを常に意識する必要があります。コードが意図していることを、誤解なく明確に伝えることが、保守性の高いプロダクトに繋がります。
一例として、ある値が空かどうかを判定するロジックを Rails で実装した際のことを挙げます。 私は、nilや空文字("")だけでなく、空白文字(" ")も空と判定する blank?というメソッドを使いました。
しかし、レビューで「empty?で十分である」という指摘をいただきました。
blank?は empty?よりも判定範囲が広いため、「大は小を兼ねる」と考えがちです。しかし、今回の要件は「nilか空文字であること」であり、空白文字の考慮は不要でした。
将来このコードを読むエンジニアを「なぜここは空白文字まで許容する blank?なんだろう？何か特別な意図があるのか？」と、不要に悩ませてしまうため、empty?にすべき実装でした。

この指摘を含め、コードは常に「将来の読み手」を意識し、最小限の実装を選択することの重要性を多くの指摘で学びました。

対象の値	empty? の結果	blank? の結果	解説
"" (空文字)	true	true	どちらも「空」と判定
" " (空白文字)	false	true	blank?のみが「空」と判定
"a" (文字あり)	false	false	どちらも「空ではない」と判定

仕様を明確に、変更に強いコードへ

プロダクトはリリースされた後も、機能追加や改善で絶えず変化し続けます。だからこそ将来の変更に備え、誰が修正してもミスが起きにくいコードを書く必要があります。
その典型的な例が、コメント投稿の文字数上限を50文字に制限する実装でのことでした。 当初、私は if text.length > 50 のように、いわゆる「マジックナンバー」をコード内に記載していました。
これもレビューで、「定数として定義しましょう」という指摘を受けました。理由は2つあります。

仕様が不明瞭：コード上で突然 50 という数字が現れても、それが何を意味しているのか、初見では分からない。
変更に弱い：将来、文字数上限が変更された場合、コード内の 50 という数値をすべて探し出して修正する必要があり、漏れやミスの原因になる。

COMMENT_MAX_LENGTH = 50 のように意味のある名前の定数にすることで、これらの問題は一気に解決します。

##before
if text.length > 50

##after
COMMENT_MAX_LENGTH = 50
if text.length > COMMENT_MAX_LENGTH

上記は一例ですが、コードの可読性を上げ、将来の仕様変更に強くする工夫を多く学びました。

負荷を考えた実装をする

Webサービスは、多くのユーザーが同時に利用するため、処理の「コスト」を考慮した実装は不可欠です。コストの高い処理は、サービスの応答速度を低下させ、ユーザー体験を損なう原因になります。
例えば、コメントを投稿するAPIでは、以下の2点を確認する必要がありました。

1. コメントの形式が正しいか、
2. 投稿先の記事が存在しているか

上記のうち「2.投稿先の記事が存在しているか」についてはデータベースへの問い合わせが必要なため、「1.コメントの形式が正しいか」を確認する処理よりもコストが高くなります。
もし、データベース問い合わせが必要な「2.投稿先の記事が存在しているか」を先にチェックしてしまうと、そもそも形式が不正なコメントに対しても、毎回高コストなデータベースアクセスが発生してしまいます。
レビューでの指摘を受け、先にAPIサーバーのチェック（1.コメントの形式が正しいか）で弾けるものは弾き、それを通過したものだけがデータベースサーバー（2.投稿先の記事が存在しているか）へ問い合わせるように順序を修正しました。
小さな違いに見えますが、アクセスが増えれば増えるほど、この差はサーバー負荷に大きく影響します。常に処理の「コスト」を意識する癖をつけるきっかけになりました。

ソフトスキル面での学び

続いて、仕事の進め方など、ソフトスキルの側面を振り返ります。一言で言うと「優れたプロダクトは、技術力だけで生まれるのではない」ということを、身をもって学びました。

AIの時代だからこそ、意思をもつ

APIもテストコードも、AIに依頼すれば一瞬で生成されますが、それをそのまま提出するなら、そこに自分が介在する意味はありません。
研修当初の私は、AIが出力したコードを完全に理解しないまま、レビューに出してしまうことがありました。AIは要件通りのコードは作ってくれますが、固有のコーディングルールや、将来の運用までを完璧に考慮したコードを出力してくれるわけではありません。
レビューでは「AIが出したコードをそのまま提出し続けると、鈴木さんの存在価値がなくなり、最終的にエンジニアとして働ける可能性がなくなる」と指摘を受けました。
この経験から、AIの使い方を改めました。 AIには要件を実現する手段を列挙させ、それぞれを比較検討した上で、自らの意思で「今回はA案で行こう」と能動的に選択する。そして、AIが生成したコードを鵜呑みにせず、自分の手で修正を加えていきます。たとえ挙動が期待通りであっても、プロジェクトの慣習に合わせたり、より良い変数名に変えたり、自分の意思を込めてコードを修正します。このように「実装に意思を持つこと」こそが、エンジニアの価値なのだと気づきました。

レビューではレビュワーの負荷を想像する

コードレビューは、レビュワーの時間を消費する行為です。レビュー時間が長引けば長引くほど、機能開発や改善に割ける時間が減り、結果としてプロダクトのリリース速度や改善スピードを鈍化させてしまいます。
だからこそ、レビュワーの負担を少しでも減らす工夫は、最大限行うべきだと学びました。
特に学びになったのが「質問されそうな箇所に、先回りしてコメントを書く」という工夫です。 プルリクエストを作成する際に、「この実装にした意図はなんだろう？」「なぜこのメソッドを使っているんだろう？」とレビュワーが疑問に思いそうな点を予測し、あらかじめプルリクエストにコメントを入れる。
この一手間が、レビュワーの思考時間を短縮し、質問のやり取りを減らすことに繋がります。相手の立場を想像し、スムーズなコミュニケーションを設計することも、エンジニアの重要なスキルだと実感しました。

既存メソッドを使う際のセルフレビューでは、影響範囲などの確認事項を先回りして伝えていました

対処より報告。報連相が最重要

エンジニアに限らず、社会人の基本として語られる「報連相」ですが、その重要性を、私は一つの失敗から痛感しました。
研修中、レビューが完了していないコードを、誤ってマージしてしまうという操作ミスを犯しました。
もちろん、ourlyではGitHubのブランチ保護ルールが設定されており、通常はレビューが完了しないとマージできない仕組みになっています。しかし、研修では保護ルールがなくマージが可能な状態でした。
幸い、本番環境に影響が出ない研修用の環境だったから良かったものの、実務であれば不完全な機能をリリースしてしまう大事故です。
しかし、私の本当の失敗は操作ミスそのものではなく、ミスした直後、チームに報告せず、自力でなんとか元の状態に戻そうと、さらに操作を続けてしまったことです。
想定外の事態が起きた時、個人の判断で対処しようとすると、かえって状況を悪化させる危険があるだけでなく、今後の信頼にも影響します。
この一件で、「想定外のことが発生したら、対処よりまず報告」という原則を肝に銘じました。すぐに報告し、チームとして最善の対応策を練ることが、結果的に被害を最小限に抑え、チームとプロダクトを守ることに繋がるのだと、身をもって学びました。

研修を終えて

ハードスキル面

記事中で記載したこと以外にも、N+1問題を解消するためのメソッドの使い分けなど、ここでは書ききれないほど多くのことを学びました。 目の前の機能実装に集中するあまり見落としがちな、保守性やパフォーマンスに関わる観点も、実装後の見直しでチェックする癖を身につけました。多くの学びを通して、ただ動くプログラムを書く段階から一歩先に進めたと感じています。

ソフトスキル面

AIとの向き合い方やレビューの工夫、報連相など、学んだソフトスキルは、ハードスキルと掛け合わせることで「プロダクトの質を最大化する」と学びました。

多い時は100件以上のコメントが付き、伸び代を感じていました

最後に

本記事では、2ヶ月間の新卒エンジニア研修での学びを振り返りました。
この研修で得た最大の収穫は、私のエンジニアとしてのゴールの認識が根本から変わったことです。研修前は「仕様書通りに動くものを作ること」がゴールだと考えていました。しかし、現在の私のゴールは、「プロダクトと、チームの将来を考えながらコードを書くこと」へと変わりました。学んだハードスキルもソフトスキルも、全てがこのゴールに繋がっています。
自分の書いたコードが、プロダクトの品質だけでなくチームの将来にも責任を持つ。この意識を持てるようになったことが、研修で得た最も大きな財産です。
今後はこの意識を常に持ちながら、チームの一員として、品質の高いプロダクト開発に貢献していきます！
最後まで読んでいただき、ありがとうございました！