はじめに
こんにちは。エンジニア歴3か月の駆け出しエンジニア(?)です。
今年の4月から社会人となり、6月までは全体での研修、そこから2か月間の開発研修、そして7月からエンジニアとして実務に入り始めました。
実務が始まってから丁度3か月くらいたったので、この3か月間で取り組んだこと、学んだこと、気持ちの変化などをつらつらと書いてみようと思います。
この3か月間で取り組んだこと
7月下旬 配属決定、配属先でのオンボーディング開始
配属前、新製品開発をやりたい！とずっと言っていたら、リリース仕立てホヤホヤの製品の開発チームへの配属となりました。やったー！そしてエンジニアとしての実務が開始しました。最初はチームで用意してもらったオンボーディング資料に従い、自分が携わる製品の理解、環境構築、開発で使うツールの理解を進めていきました。
私が携わるプロダクトでは、フロントはreact, typescriptで、バックエンドがjava(spring)でした。springは新卒エンジニア全体での開発研修である程度学習したので、react, typescriptの学習を進めていきました。
typescriptは、サバイバルtypescript を使って学習を進めました。こちらのサイトでは、typescriptの基本的な文法から、ある程度難易度の高い文法、reactで簡単に動くものを作るハンズオンなど、typescriptを用いた開発に必要な知識が網羅的に掲載されています。
reactは、React(v18)完全入門ガイド｜Hooks、Next.js、Redux、TypeScript というudemyの講座で学びました。こちらも、reactの基本的な部分から、useEffectなどreact特有のわかりずらい機能も詳しく解説されており、理解の促進にとても役立ちました。
8月上旬 初バグ修正案件
キャッチアップや環境構築を終え、初めてバグの修正の案件をいただきました。内容は、複数人で同じことをすると正しく動かないから直してね、というものでした。排他制御ですね。正直、「初案件なのにいきなり難しすぎる！」と感じていました。最初は既存のコードがどうなっているのかを調べるところからでしたが、これが非常に時間がかかりました。数日間は全然手を動かせませんでした。しかし、少しずつコードを掘り下げていき、原因を探り、修正していくプロセスは結構面白く、初めて自分の意図したとおりに動作した時はとてもうれしかったのを覚えています。
また、修正を行いコードレビューを受ける中で、可読性の高いコードの書き方、適切なエラーハンドリングの仕方なども教わり、コードを書く上で必要である基本的な技術を学んでいきました。
9月上旬 初バグ修正完了
なんだかんだ一か月くらいかかりました。かなり難しかったので、やり切ったときはとてもうれしかったです。バグ修正の一連の流れを学ぶことができました。やることが非常に多くて驚きました。
9月中旬 自分の修正にミスが発覚、大慌てで直す
1か月以上かけて何とか完了した初案件でしたが、あとから重大なミスが発覚しました。自分の修正によって、特定の条件下で画面の動きがめちゃくちゃになるというものでした。まず、1か月以上1つのバグ修正に向き合って試行錯誤したのに、このミスを自分で事前に発見できなかったことが悔しかったです。また、今回はリリース前に気づいたのでよかったですが、発見がリリースされた後だったり、実際にユーザーがそのミスの影響を受けてしまったらと考えると怖いなと思いました。ただ、これがきっかけで、その後の修正案件ではより慎重になれたので、結果的にはいい勉強になったな、と前向きにとらえることにしています。
9月中旬 バグ調査案件
なんだかんだで1件目の修正を終えました。1件目で同時操作系のバグの修正に取り組んだので、今度は他の同時操作系のバグを精査してまとめ、自分で直していくという案件に取り組みました。バグを調べるって、ただ実際に触ってバグが発生するか見てみるだけでしょ？と思うかもしれませんが(実際そうですが)、配属されたばかりの私には大きなメリットがありました。それは、バグ調査を通じてシステム上の知らない機能や言葉を学ぶことができる、ということです。そもそもバグを発生させる操作の説明文の意味がわからないこともあり、用語を調べたりチームの人に聞いたりしながら精査を進めていきました。バグ調査は様々な機能に触れられる機会を得られるという点で自分にとって有益だなと感じました。
9月下旬 〜 10月下旬 自分が調査したバグを直していく
9月中旬に調査したバグのいくつかを、自分で修正していきました。結果10月末までに6件のタスクをこなすことができました。バグ修正は結構慣れてきました。
これから
機能追加案件をやらせてもらえることになりました。最近は企画、要件定義、設計のフェーズで苦戦していますが、楽しみながら進めています。このあたりも、終わったら感想などを記事にしてみたいなと思います。
この3か月間で学んだこと
毎日知らないこと、できないことの連続で、プレッシャーや不安を感じることもよくありますが、日々成長を実感しながら仕事ができていることに喜びを感じています。その中で、今後にも活かせそう、活かすべきだと感じた学びをいくつか書こうと思います。
自分のありのままをtimesで発信
配属されてからの主な業務はバグ修正でした。学生時代や開発研修である程度コードは書いてきましたが、既存のコードに手を入れるのは簡単なことではありませんでした。
「まず今回の動作はどこのコードが関係しているのか？」
「どのコードを触るとどこに影響するのか？」
このあたりが全然わからないのです。コードの量は非常に多いので最初は仕方のないことだと思います。でも、バグは直さなければならないですし、期限もあるので、それなりのスピードでコードを理解していく必要があります。そこで私が実践して(というよりは上司にアドバイスを頂いて)役に立ったのが、自分の思考の過程を言語化し、発信するということです。言語化、発信を行うツールは何でもいいと思いますが、私はtimesで発信していました。
そもそもtimesとはなんなのか？については、こちらの記事がわかりやすいです↓
https://qiita.com/satomihoya/items/b125e1eaf44c4a643e6e
timesとは、簡単に言えば社内twitterのようなものです(最近はtimesを取り入れている企業も多いようですね)。弊社では、slackで各々が自分のtimesチャンネルを作ってそこで発信したいことを自由に発信しています。このチャンネルには自分のチームのメンバーの方々や同期が入っているのですが、私はここで自分が理解したこと、わからないことを独り言のようにずっと垂れ流しています。
これを実践するとこんなメリットがあります↓
- 自分の思考の過程を整理でき理解の速度が上がる
- チームの方が、私が何に困っていて何がわかっていないのかを容易に把握することができる
- 後に同じ課題、似た課題に出会ったとき、その時の思考の記録を読み直すことで思考の過程を復元できる
自分の思考の過程を整理でき理解の速度が上がる
例えば、既存のコードを理解しようと思い、ある動作のデータの流れを追うとき、流れが複雑で追っているとよくわからなくなってくる、ということがよくあります。この原因は、データを追う過程で自分が覚えておくべき情報がオーバーフローするからだと思っています。例えば、この引数に入っている変数はどっから来たんだっけ、とか。慣れてくればこの辺はすっと理解できるのだと思うのですが、最初のうちは初歩的なデータの流れも言語化しておくことで、頭の中がかなり整理されます。とてもおすすめです。
チームの方が、私が何に困っていて何がわかっていないのかを容易に把握することができる
私はほぼフルリモートで働いている関係上、私が開発している様子や悩んでいる様子をチームの方が見ることはありません。例えば、出社していてチームの方と同じ空間で仕事をしていて、明らかに私が焦っている様子であれば、「あれ、進捗まずいのかな」みたいに私の状況を察することができるわけですが、リモートだとこういった雰囲気は伝わりません(毎日の進捗確認などはあります)。そこで、自分が今何をしていて、こんなことで悩んでいて、こういう仮説を立てこういうことを試そうとしている、ということを発信しておくことで、リモートワークであっても自分の状況がわかる材料を提供することができます。同じ空間で仕事をすればで伝わるはずの"空気感"を、リモートで、非同期的に伝えることができるわけです。
後に同じ課題、似た課題に出会ったとき、その時の思考の記録を読み直すことで思考の過程を復元できる
何度も似たような案件に取り組むと、行き詰ってしまう場面にも傾向があったりします。そんな時、毎回同じことを調べたり聞いたりするのは時間の無駄です。でも、times等で逐一記録を残しておけば、それを見返すことで短時間で解決に至ることが可能です。
自分の修正の影響範囲調査は慎重に
冒頭で書いたように、私は初案件で既存の動作が壊れていることに気づかなかったというミスをしました。この原因は、自分の修正がどこまで影響を及ぼすかよく考えていなかったことでした。
ミスや抜け漏れを防ぐ。また、他人に対して修正に問題が無いことを証明するためにも、感覚に頼らない影響範囲調査が必要であることを身をもって実感しました。
感覚に頼らない影響範囲調査をするために重要なことは、
1: 自分が手を加えたメソッドについて、呼び出し階層を見て影響箇所を漏れなく調査
メソッドに手を加えたということは、修正前と比較して入出力やエラーを投げる箇所が変わっている可能性があります。手を加えたメソッドが呼び出されている個所は漏れなく調査し、問題なく動作することを確認します。加えて、テストケース作成時にも、これらの影響範囲を通る動作を組み込みます。
2: 自分が手を加えたメソッド、作ったメソッドの中で呼び出されるメソッドや、参照される値を漏れなく調査
自分が改変したメソッドの中で新たに呼び出すメソッドや参照する値のチェックは重要です。特に、参照する値については、その値がほかの場所でどのように書き換えられる可能性があるかまで調査すべきです。自分の意図しない書き換えが発生する可能性があったら、バグの原因になります。
自分の修正範囲に責任を持つためにも、このあたりをしっかり調査することが大切ということを学びました。
開発は楽しい
反省やうまく行かなかったことをそのまま書いてみましたが、なんだかんだ言って開発は楽しいです。原因を考え、解決策を考え、試し、うまく行かず、また試す。これを繰り返していくと最終的には成果が目に見える。この過程が面白いです。締め切りなどがありプレッシャーを感じることもありますが、この楽しいという気持ちは今後も忘れないようにしたいです。これからは自分で機能を作る機会も少しずつ増えてくると思うので、楽しみです。
終わりに
実務が始まってからの3か月間で、開発を基礎の基礎から学んできました。その中で感じたことは、当然技術力は大切ですが、それと同じくらい、問題を迅速に解決する力が大切だということでした。例えば技術的な問題にぶつかったとき、まずはググったり書籍に頼ったりしますが、ほかにも、チームメンバーや、生成AIなど、問題の解決に使えるリソースはたくさんあります。こういったものをうまく活用しながら、たくさんの案件に取り組み、経験を積み、開発者として強くなりたいと思います。また何か月か経ったら振り返りを書いてみようと思います。
最後までご覧いただきありがとうございました！