エンジニア歴2年目にしてバックエンドチームへ異動して実践していること・反省点

はじめに

こんにちは！
D2Cエンジニアの廣瀬です

この度、所属しているPJのフロントエンドチームから同PJのバックエンドチームに異動しました

本記事では、エンジニア歴2年目にしてバックエンド実務経験皆無だった私が、少しでも早くバックエンドチームの一員として戦力になれることを目指して実践していること・これまでの反省点について、自身の振り返りも兼ねて書いていきたいと思います！

異動前は何をしていたのか

• 新規PJのフロントエンドチームに新卒で配属され、1年半ほどそこでお世話になりました
• 開発言語としては主にTypeScriptを使用しており、ライブラリはReact、またテストコードはPlaywrightとVitestを使用していました
• 異動後に勉強することになるDIやDDD等については、名前をなんとなく知っている程度の理解度でした
• また、バックエンドチームの主要開発言語であるGolangも入社後の新卒研修で勉強してから1年半ほどは全く触れておらず、異動時にはほとんど忘れてしまっていました

実践していること

ここでは、バックエンドチームへの異動後、私が実践していることについて書いていきます。
まず結論としては以下になります。

• 現状のチーム運用について学習する
• 疑問解消会を設ける
• とりあえずメモしてみる
• 定期的に振り返りを実施する

それぞれ見ていきます

現状のチーム運用について学習する

こちら開発中に気になったことを調べてみたり、独自で時間を作ったりしながら学習を進めています。
具体的な学習内容としては以下です。

• 設計手法 / アーキテクチャ
  • バックエンドチームではDDD（ドメイン駆動設計）を採用しているため、チームの先輩におすすめされたDDDに関する書籍を実際のソースコードと照らし合わせながら読み進める形で勉強しています
• コードの詳細
  • 大まかなデータの流れや、どのようにエラーをハンドリングしているのか等、現状のコードの詳細について理解を進めています。
  • また、コードを理解するのに必要な知識（例えばGolang、DI、オニオンアーキテクチャ等）も併せて学習しています。
• 他のチームとの繋がり方
  • シーケンス図の作成というアウトプットを意識しつつ、学習を進めています。
  • 私の所属しているPJはマイクロサービスアーキテクチャのような設計になっており、バックエンドチームはブラウザとその他複数のマイクロサービスのインターフェースの役割を担っています。
  • そのため異動前（フロントエンドチーム在籍時）にはバックエンド以外を意識しなくても開発にはあまり支障はなかったのですが、異動後では複数のマイクロサービスを意識する必要が出てきたため改めて理解を進めています。（本当はフロントエンドチームに在籍していた時も意識すべきだったと思いますが…）

疑問解消会を設ける

週2回、チームの先輩方のご厚意で疑問解消会を設けていただいています。
ここでは私が疑問を持っていきそれについて先輩が回答する、という形式をとっています。

ここでの疑問とは何かというと、
主に「現状のチーム運用について学習する」セクションで紹介した内容の実践中に生まれたものになります。

疑問も出せないくらいの強度の学習を続けていると、この会で何も議題がないという状態が発生してしまうので、それは勿体無いという心理からより学習を継続していくことができていると思っています。

また、意外と私の無邪気な疑問がチームの課題点だったりすることもあるので、チームにとっても非常に微量ではあるとは思いますがプラスアルファで何かしらの価値があるのではないかと思っています（願っています）。

毎回お時間割いて下さる先輩方には、日頃からでもありますが非常に感謝しており、本当に頭が上がりません！

とりあえずメモしてみる

こちらについては、社会人なら当然という方ももしかしたらいらっしゃるのかなと思うのですが、私としては社会人2年目にしてその重要さに気付き意識して実践しております…！

メモする内容としては、「疑問に思ったこと」「先輩に教えていただいたこと」「書籍から学んだこと」「ふと思いついた考え」など様々です。

個人的には以下を目的としてメモをとっています。

• 補助記憶的な役割として、確実に情報を保存する為
• 言語化する為
  • 理解できないロジックをメモして言語化していくと、意外と理解できたりする
  • 学習内容をメモして言語化する過程で、曖昧だったり理解できていなかった点が明確になり整理されやすい
  • 抽象的な理解をメモして言語化していくことで、より具体的な形で理解することができ、応用が効きやすくなったりする

個人的には2点目の「言語化するため」という目的でメモすることが多いです。
今後はこれを無意識的にできるようになるまで習慣化していけたらと思っています。

定期的に振り返る

PJではスクラム開発手法を採用しており、こちらもチームの先輩方のご厚意で1スプリントに1度私の学習状況やそのスプリント内での立ち回り方についての振り返りの場を設けていただいます。
（スクラムイベントの1つであるレトロスペクティブとは別物です）

内容としては、今後「いつまでに」「どのくらい」「何を」できるようになるか等の具体的な目標を立てた上で、私から見た自身の課題点（何の知見が足りていないか等）と先輩から見た私に対する課題点についてすり合わせ、次回以降のスプリントの私のアクションの方向性を決定します。

この振り返りを実施することで、学習の方向性やそのスプリント内での私の立ち回りについてフィードバックをいただき、より効果的に改善を促進できていると実感しています。

反省点

ここではバックエンドチームに異動してきてから、「こうすれば良かった」という反省点について書いていきたいと思います。
まず結論としては以下になります。

• もっと早く質問すればよかった
• コードを理解するには自分で書いてみた方が早い
• キャッチアップする内容には優先度がある

それぞれ見ていきます

もっと早く質問すればよかった

よく、質問される側が「はい」か「いいえ」で答えられるような問い方をするようにと言われることがあると思います。
私も普段質問する側として基本的にはこの考え方なので、なるべく徹底しています。

ただ、これを完全に徹底しようとすると自分なりの考えを固める必要があるため、質問しに行くまでに時間がかかってしまうことが多かったです。
時間がかかってしまうと、かえってチームの迷惑になってしまうこともありますし、他のタスクを進めたり、新しいことを学んだりする時間が削られてしまいます。

なので、15分〜30分ほど悩んでも自分なりの考えが固められなかった場合は、先輩やそれについて詳しい人に、丸投げでも質問しに行った方が良いかと思いました。（勿論、相手への感謝の気持ちは忘れずに）
そうすると、より早く問題を解決することができますし、残った時間をそのチームのためにより有意義に活用することができると思います。

コードを理解するには自分で書いてみた方が早い

ソースコードのリーディングを実施してもあまり理解が進まない場合は、自分でサンプルを書いてみた方が理解が捗りました。

異動してからソースコードの理解を進めている際、DI（Dependecy Injection）が表現されている部分だけ「なぜこれで動くのか」という疑問を拭いきれずにいました。
この時の私は、ひたすらコードを読んでいるだけでした。

定期的に実施する疑問解消会でチームの先輩から、
「実際に自分でDIを使ったサンプルを書いてみると良いよ」とアドバイスをいただき、コードを読むだけではなく自分で書いてみるというアプローチに切り替えたところ、とても理解が進みました。

コードを自分で書いて理解を進めるとなると、読むよりもそれなりに時間がかかってしまうと思われるかもしれませんが、意外と書くアプローチを取った方が効率的だったりするのかなと思います。
（所謂、「急がば回れ」ですね）

ただ、読んで理解できるのならそれで十分かと思うので、必ずしもコードを書いてみる必要もないのかなと思います。

キャッチアップする内容には優先度がある

新しいチームに異動するとキャッチアップすべきことが沢山出てくるかと思うのですが、その中でも何を先にキャッチアップすべきかという優先度があると教わりました。

個人的な癖で、気になり始めると細かい部分まで深く踏み込みすぎてしまい、必要以上に時間をかけてしまうことがあります。
今回、全体を俯瞰して見直してみた結果、そういった細部にこだわるよりも、他の部分に時間を割いた方が全体として効率的にキャッチアップできる場面が多かったと思いました。

ただ、どこの部分をどれぐらいキャッチアップするのか、という線引きは人によって感覚が異なるのかなとも思っており、バランスが難しいと感じています。

まとめ

バックエンド実務経験が全くない状態で新しい環境に飛び込み、その中でのアクションや反省点についてまとめてみました！

まだまだ成長途中ですので、これから更に自身の行動を改善していき、着実に1歩ずつ進んでいきたいと思っています！

この記事がどなたかの参考になれば幸いです！
また、「もっとこうしたら良いのでは」や「自分だったらこうする」などのアドバイス・ご意見あればぜひコメントで教えていただけると嬉しいです！

最後までお読みいただきありがとうございました！🙇