セブ島で働いていたブリッジエンジニアがエンジニアに転職して1ヶ月経ったので、振り返りしてみた。
初めに
こんにちは、daichikiと申します。
事業会社のWebエンジニアとして転職して1ヶ月が経ったので振り返りをしたいと思ったのと、今エンジニアとして転職を考えている方に対して実際のエンジニアの仕事がどういったものか参考になればと思い、この記事を書きました！
ぜひ最後までご覧ください！
私の簡単な経歴
元々、フィリピンのセブ島というところでファーストキャリアをスタートし、約二年弱様々な業務をやりながらブリッジエンジニアとしてオフショア開発に従事していました。
ただ、元々開発に関する経験がない状態でブリッジエンジニアをしていたので、顧客から技術的な質問を投げかけられた時にその場で答えられないことが度々あり、やはりまずは技術力をしっかりと身に付けた方が良いのではないかと思うようになりました。
そこで2023年11月に日本へ帰国し、上場しているとある事業会社にWebエンジニアとして転職をしました。
転職先の開発体制
転職先の会社では複数のサービスを運用しているので、それぞれのチームが2~3つほどサービスを担当するような形をとっています。
ただ、サービスの数に対してエンジニアの数が十分ではないためフルスタックな技術が求められており、この1ヶ月の間にもフロントエンドをメインでやりつつもバックエンドのタスクも少し行ないました。
現在私が担当している技術としては、フロントエンドがNuxt.jsでバックエンドがLaravel、また単体テストとしてJestとPHPUnitを使っています。
どんなことをやったのか
主に下記のことを行いました。
- 担当するそれぞれのサービスの環境構築
- フロントエンドの改修（Nuxt.js）
- バックエンドの改修（Laravel）
> 担当するそれぞれのサービスの環境構築
私が担当しているサービスは全てDockerを使っていたのとドキュメントがしっかりと用意されていたので、そこまで苦労はしませんでした。
ただ、一部のDockerfileが古く、npmをlatestでインストールしようとするとnodeのバージョンと互換性が取れなくなりエラーが起きたので、その解決には少し手間取ったかもしれません。
> フロントエンドの改修（Nuxt.js）
具体的に行ったタスクは下記になります。
- モーダルの作成
- WordPressに投稿されているQ&Aの記事をWordPress REST APIを使ってカテゴリーごとに取得し、表示する
- ユーザーの動作に応じて、バックエンドに送るクエリパラメーターを変更する
- 特定のページにて、noindexを適応させる
StoryBookでUIの確認を行いながら、Jestでそれぞれの機能の単体テストを行いました。
> バックエンドの改修(Laravel)
具体的に行ったタスクは下記になります。
- 既存のAPIにて、DBからデータを取得する際の条件を追加する
- データの追加（SQL）
- カラムの追加（Laravel）
- ユニーク制約の修正（Laravel）
- Eloquentの修正（Laravel）
Postmanを使用して、追加した条件がしっかりとAPIの処理に反映されているのかを確認しながら開発を行いました。
また、DBに新しくデータを追加し取得する必要があったので、直接SQLを書いたりもしました。
単体テストではPHPUnitを使用しました。
苦労したところ
私が苦労したと感じた点は下記の四つです。
- システムへの理解
- テストコードの理解
- コーディングのお作法
- SQLとEloquentの理解
>システムへの理解
前職と比べて規模が大きいシステムを扱っているため、システムの理解をするのに非常に苦労しました。（今も現在進行形ですが...笑）
フロントエンドであればNuxt.jsを使っていることもあり、ある程度ディレクトリ構造を見ればなんとなくどこでどういった処理が行われているのか分かるのですが、バックエンドに関してはLaravelでFat Controllerにならないように、ServiceとRepositoryが導入されているので、複数のファイルを跨ぎながら処理の全体像を把握するのに苦労しました。
>テストコード
転職先では、テストのカバレッジが100%にならないとCIの際にビルドが失敗し、デプロイができないようになっています。
しかし、テストコードを書く経験がそもそも初めてだったので、要件を満たす機能を開発できたとしてもテストのカバレッジが永遠に100%にならず、何度も先輩エンジニアに助けを求めてしまいました...。
あの時助けを求めなければ、永久にリリースができなかったでしょう。
>コーディングのお作法
個人で学習をしているときはあまり命名やコメントの付け方、コンポーネントの分割方法などは気にせず自由に行なっていたのですが、チーム開発となるとそうはいきません。
チーム内で決めているコーディング規則はもちろんのこと、一般的に提唱されているものを共通認識として持っておきながらコードを書かないと、ソースコードがぐちゃぐちゃになりますし、レビューをするときも大変です。
私はこのことで、一つのPRの中で100以上のコメントが付いたこともありました。泣
今はリーダブルコードとチームのコーディング規則を読んで、必死にお作法を勉強中です。
>SQLとEloquentの理解
Laravelを個人で学習しているときは、あまりEloquentがどのようなSQLを生み出しているのか考えておらず、とりあえずwhereを使っていたら検索条件を加えられて、findでidを使ってデータを絞り込めるんだ〜程度の理解しか出来ていませんでした。
しかし、実際に既存のAPIの処理の中でDBからデータを取得する条件を加えるタスクを依頼されたときに、カラムを新しく追加したりユニーク制約を加えてみたはいいものの、どのようにEloquentを修正すればいいのかさっぱり分かりませんでした。
そこで一からSQLを学習し直し、EloquentのそれぞれのメソッドがどのようなSQLを発行するのかを確認することで、joinSubやwhereRaw、leftJoinなどを駆使出来るようになり、無事にデータの取得条件を加えることができました。
心がけたこと
私が心がけたことは下記の二つです。
- 気楽に考える
- 先輩エンジニアをランチに誘う
>気楽に考える
まず大前提、私は開発経験のないひよっこエンジニアなので、いきなり会社で大活躍して貢献してやるぞ！という熱い思いはあまり持たないようにしました。
え、それっていいの？と思う方もいらっしゃるかとは思いますが、あくまで自分なりに考えたときにこれが心理的に楽だと思いました。
そもそも、未経験で入社して一ヶ月で大活躍できるほどエンジニアという仕事は甘くないと思いますし、熱い気持ちを持ちすぎると周りのエンジニアと自分のレベルを比べた時のギャップに絶望してしまうような気がします。
例えるなら、お金をもらうようなサッカーとか野球のクラブチームだって、仮に未経験で入部して一ヶ月でスタメンになれるはずないですよね...。（もちろん例外はいると思います）
最低でも数年は、地道な練習を重ねる必要があると思います。
エンジニアの仕事もそれと一緒で、数年は地道に勉強と経験を重ねて初めて活躍ができるものだと思っています。
なので、私は楽しく長く続けるためにも最初からエンジンを全開にするのではなく、少しずつエンジンを上げていくやり方でいこうと思いました。
このおかげで、周りのエンジニアと自分を比較してしまう時は「あの人はあんなことやこんなこともできるのか〜、まぁ勉強していればそのうち追いつくか！」とポジティブ思考になり、勉強へのモチベーションも上がるようになりました。
>先輩エンジニアをランチに誘う
今の部署は週二日の出社を義務付けられているのですが、出社したタイミングでSlackのgeneralチャンネルで
「12~13時でランチを取る予定です！タイミング合う方がいたら一緒にどうですか？」
と＠channelのメンションをつけて投稿していました。
なぜこんなことをしていたかというと、人間関係が仕事において一番大切だと思っているからです。
まず、私は技術的にしばらくは貢献することができない立場なので、先輩エンジニアからしたら私に教える工数が余計にかかってしまい、自身のタスクに集中できない時もあるかと思います。
ここで人間関係が良ければ、気軽に質問にも答えてくれると思いますし、ミスをしてしまった時も手を差し伸べてくれやすくなり、自ずと自身の仕事環境も良くなるのではないかと思っています。
なので、ランチを通じて普段聞けないプライベートな話や技術的な雑談をして、関係値を深めていけたらなと思っています。
ちなみに、この施策は部長にウケて、「daichikiが入社してから明らかに会社の雰囲気が良くなった」と褒めてもらったので、未経験でエンジニアに転職する方には個人的にオススメです笑
最後に
今の職場では先輩エンジニアに気軽に質問ができたり、コードのレビューをしていただいた時に様々なアドバイスを頂けるので、ひよっこエンジニアとしては非常にありがたいです...。
今はまだ実装の部分しか担当していないので、早いうちに自分で設計も担当出来るように勉強と経験を重ねていきたいと思います。
セブ島での生活は非常に楽しかったので正直捨て難かったですが、改めて日本に帰国し転職して良かったと思います！
最後まで読んでいただきありがとうございました！
Discussion