はじめに
こんにちは！
「Develop fun!」を体現する！ Works Human Intelligence Advent Calendar 2024 🎄
19日目を担当する k_uki512 です！🎉
私は、今年4月に新卒として入社した新米エンジニアです。
全体研修・部門研修を経て、現場配属され、10月から開発案件を任されるようになりました。
現在は小さい案件が中心ですが、初めて正社員として開発する上で様々な学びがありました。今回は僕が10月～12月の案件で学んだことを共有していきます。
この記事を読んでほしい人
- 来年からエンジニアとして就職する新卒生・未経験エンジニア
- 個人開発の経験はあるが、企業でのチーム開発の経験は無い人
新卒の立場からお話しするので、主にエンジニアを目指す学生がターゲットになります。
筆者の経歴（前提）
- 情報系の学部を卒業
- 大学時代のキャッチアップは独学が中心
- 個人開発・開発インターンの経験はあるが、ゴリゴリのチーム開発は初めて
教訓１：目的とゴールを常に頭に置く
自分の中で、これが一番大事だと思っています。
目的は「タスクや物事を実施する理由」、ゴールは「達成したい最終地点」を指します。これらを明確にすることで、タスクに対する行動指針がはっきりし、スムーズな遂行が可能となります。
たとえば、上司に修正したソースコードを説明するMTGを想定します。この上司は案件の詳細を把握していないとします。目的とゴールを考えずにMTGに臨むと、ただ修正内容を述べるだけになり、上司には案件の全体像や修正の正当性が伝わりにくくなります。
そこで、MTGに臨む前に以下のような目的とゴールを意識します。
- 目的：修正内容に承認を得て、本番環境に変更を反映する
- ゴール：修正に至った背景と、その妥当性を上司に理解してもらう
このように目的とゴールをはっきりさせると、準備すべき内容が見えてきます。この場合には、修正の背景を説明する資料や、妥当性を示す証拠、説明する順序といった準備が必要です。
小さい案件から目的とゴールを意識する習慣をつけることで、より大きな案件にも柔軟に対応できるスキルが身についていくと考えます。
教訓２：目先の利益を追いすぎない
ここで私が学んだのは、「修正に直接関係するコードだけでなく、修正が影響を及ぼすサブシステム全体も、多少時間がかかっても理解すべき」ということです。
私は「ログイン機能」の不具合修正を担当していました。不具合の原因を調べたところ、「ログイン可能なユーザーかどうかを判定するSQLをDBに送信している箇所」に問題があると判明しました。
そこで私は、仕様調査を中断し、直接関係するソースコードのみを確認した状態で不具合修正を行い、PRを提出しました。
しかし、修正内容を説明するレビューを行った際に、「画面上ではうまく動作しているが、ソースコード上では、成功している理由が曖昧」といった状況になりました。
「タスクを早く完了させたい」という気持ちが強いほど、仕様調査をおろそかにしがちです。
サブシステム全体の処理フローを理解できるまでソースコードを読むことで、エンジニアとしての力が身につき、今後の案件にも対応できる能力を養えると感じました。
教訓３：チーム開発であることを意識する
ここでお伝えしたいのは、「製品開発は、過去・現在・未来にわたる大きなチーム開発である」ということです。大学時代には基本的に独学で開発を行っていたため、自分の書いたコードを他人に説明する機会は少なく、「今作っている機能や修正がとりあえず完了すれば良い」という甘い気持ちがうっすらとありました。
しかし、一つの既存製品を開発するということは、「過去にその機能を開発した人がいて、未来には自分が開発した機能に手を加える人がいる可能性がある」ということです。
このことを念頭に置き、
- 過去に開発した人の意図をソースコードから汲み取る
- 未来の担当者を意識して、可読性や保守性の高いコードを書く
といったことを大切にする必要があると学びました。
最後に
今回は、僕の社会人エンジニアとしての初案件で学んだことをまとめてみました。
案件の規模自体はまだまだ小さいものの、若手のうちから意識しておくことで後々大きな価値となると思える学びをたくさん得ることができました。
これからも、新たな学びを得つつ、既に学んだことにも意識して開発をしていきます。
文字の分量が多めの記事になってしまいましたが、ここまでお読みいただきありがとうございました。