この記事はうるるAdvent Calendar 2022の16日目の記事です。
はじめに
今回社内でQiitaのAdventCalendarに参加するということだったので、
これを機にこれまでのエンジニアキャリアについて振り返ってみました。
私自身、30歳からエンジニアとしてキャリアをスタートさせ、今もエンジニアとして食べていけている状況です。
世間一般的には遅いタイミングでのキャリアチェンジかと思いますが、
そんな私のチャレンジも誰かの参考になるかなと思い、記事としてまとめてみました。
少しでも誰かのお役に立てれば幸いです。
完全に初心者向けの内容になっており、少し稚拙な内容等あるかもですがご了承ください
この記事を書く理由
改めて今回このテーマでまとめた理由としては、
- エンジニアとして丸3年経って、自身のこれまでやってきたことを整理し、何が良かったのか、もっとすべきことは何だったかを棚卸ししたかったため
- 未経験からエンジニアになるまでの方法やTips的な記事は多く目にしていますが、実際にエンジニアになってからどういうことをやってきたのかを見る機会が少ないため
- 30歳と遅いタイミングでもキャリアチェンジして、どういう生存戦略で乗り越えてきたのか整理したかったため
この記事に書く内容
- 今までやってきてよかったこと(Good)やもっとこうすればよかったこと(More)
- これまでに培われたマインド（おまけ）
どちらかといえば、これまでの生存戦略的な内容がメインになっています。
実際振り返ってみると、いかにして周りからの信頼を勝ち取るかを重視してやってきたんだなと気付かされました。
やはり30歳からということもあり、色んな不安やプレッシャーを感じていたんだと思います。（「自分よ、よく挑戦し、よく乗り越えてきた」と褒めてあげたいです笑）
3年間のGood&More
3年間の中で『やってきてよかったこと』と『もっとこうすればよかったこと』をまとめてみましたので、気になるところがあればぜひ見ていただければと思います。（文字メインです）
● Good
- 徹底したドメイン知識の理解
- 劣等感を味方にする
- 業務で使っている技術を用いた個人開発
- 率先した障害対応
- 生産性UPのための作業効率化
● More
- 圧倒的な読書量
- 得意分野の確立と強化
■ [Good①]徹底したドメイン知識の理解
技術も知識もなく、すぐに活躍できる場がない自分に何ができるかを考えたとき、真っ先に浮かんだのは業務に使用するドメイン知識の理解でした。
どうしても技術やスキルを身につけることを先決しがちですが、ドメイン知識をいち早くキャッチアップすることをきっかけに周りとの信頼関係が構築できていた気がします。
（「こいつ知っている....」的なやつです）
その結果、技術のことをあまり知らない1~2年目でも会話が成り立つことが多く、
逆にこちらから提案できるケースも多々ありました。
また、仕様の調整をするだけで実際の作業工数が圧倒的に削減できるケースも多いため、
ドメイン知識を深く知ることによるメリットはかなり大きいと思います。
【私の事例】
私のおすすめは、自分なりのドメイン知識に関するドキュメントを作成することです。
担当プロダクトに関するドキュメントは現場によって充実さも変わってくると思いますが、まずは最初の1ヶ月でひたすらインプットし、並行してドキュメントにまとめていきます。
自分の理解が合っているかメンバーに確認する際も、そのドキュメントを使えば認識齟齬も大きく減ります。
さらに、もしドキュメントが整備されていない現場なら一石二鳥です。チーム、そして会社としての資産となり、評価もあがります。
参考：成果を出すプログラマーが習得している「コードを書かない技術」
■ [Good②]劣等感を味方にする
エンジニアになってからというものの、劣等感を感じない日々はありませんでした。（現在進行形）
周りは若いエンジニアか自分と同年代かつすでにミドル層以上のエンジニアになっているため、焦りや劣等感を常に感じていました。（比較しても意味がないことは百も承知でしたが....）
ましてや新卒時代のあまり変わらない年収にタイムスリップしているわけですから、焦らない理由はないですよね。
ですが、この劣等感のおかげで自己研鑽へのモチベーションを維持でき、常に成長するための意欲が湧いてきているのも事実です。
「こいつすごい貪欲だ...」と思われると、先輩エンジニアも「こいつにならもっと教えたい」と思ってもらえるはずです。
なので、現在は生涯付き合っていくパートナーとして迎え入れています。
■ [Good③]業務で使っている技術を用いた個人開発
いわゆる模倣して開発することで、良き復習として技術が定着し、自身の引き出しとなるための手法です。私はこのやり方で一番成長できました。
せっかく業務で使っているのに、いざ違う現場やプロジェクトに入った途端に「どうやるんだっけ？」「わからない」という状態にはなりたくなかったので、どうにかして自分のものにしたいという気持ちでやっていました。
特にCI/CD、Docker、AWS周りは基本構築がされている状態からプロジェクトへ参画するため、理解できているようで理解できていない状態が多いです。
ゼロから自分で構築することで、「こういう仕組みだったのか」「だからこの設定をしているのか」など、多くの気づきがあり、自信に繋がったのを今でも覚えています。
さらにプロジェクト内のソースやアーキテクチャもより理解できるので、機能拡張や仕様変更にもスムーズに対応できるため一石二鳥です。
【私の事例】
Webスクレイピングを用いたシステム開発をしていたので、実際に自分が欲しい情報を対象にして同じアーキテクチャで開発しました。
（当時はiphoneの在庫を調べて通知するプログラムなどを作ってました）
困った時はプロジェクトのコードを参考にできるので、ある意味メンターがいてくれる状況と同じため、だいぶ心強かったですね。
■ [Good④]率先した障害対応
習うより慣れろ精神でとにかく障害対応に飛び込んでいました。
信頼を得るためにはもってこいです。
障害時の精神状態の方が対応内容や経験が記憶に残りやすく、今でも生かされるケースが多い気がします。
もちろん２次災害を招くケースもありましたが、失敗から学ぶことの方が多かったですね。
また、障害対応を続けることで勘所が鍛えられ、システム設計時に役立つことが多いです。
こういうアラートがあったらいいのに、ログがあったらいいのに、と気付かされるケースは多く、そういう辛みが設計時に活きてきます。
■ [Good⑤]生産性UPのための作業効率化
地味にやってきて良かったことNo1です。
ただでさえアウトプットを出す速度が遅いので、日常の作業速度を上げるための努力は惜しみませんでした。
例えば、画面共有しながら作業する場合、相手にもどかしさを感じさせてしまうと期待値は下がってしまいます。
逆に技術力はないけど、色々使いこなしていると期待値はあがりますよね。それも信頼に繋がります。
私の場合は、
- ショートカットキーの多用（特にエディター）
- 便利ツール導入やスクリプトによる自動化（特にターミナル）
- タイピング練習(何気に一番役立っている)
と本当に当たり前のことを愚直にやっていました。
余談ですが、エンジニアになろうと思って一番最初に始めたのがタイピング練習でした。
エンジニアのイメージがキーボードを軽快に打っているのが真っ先に浮かんだからだと思います。安易ですw
実際、コード書くよりもドキュメントやSlack打っている時の方が多いのでやっていて良かったです。
よく使っていたタイピング練習サイト：https://www.typingclub.com/
※ ほぼ★MAXにしました
■ [More①]圧倒的な読書量
過去の自分に何か伝えられるなら、まず「もっと本を読みなさい」と言っているはずです。
全く読まなかったわけではない（月1~2冊程度）ですが、読む量もさることながら、誤った読み方や身になっていないことがほとんどでした。
買って満足、読み切ることで満足という状況だったので、もったいないことをしたなと反省しています。
特に2年目以降は、周りのエンジニアの方々と会話していても、自分の語彙力の無さ、引き出しのなさを痛感していました。（今も）
改めて、著者が数年・数十年とかけて蓄積した知識や技術を、数千円で手に入れられるのは冷静に考えたらすごいことだなと思います。
今まで読めなかった難易度の高い本でも今では少し読めるようになってきているので、最近は楽しみながら読めているのも事実です。
技術書が苦手な私でも読めるようになった本：「技術書」の読書術
■ [More②]得意領域の確立
これも過去の自分に伝えられるなら、「武器を手に入れ、ひたすら磨きなさい」と言っているはずです。
もちろん、開発現場やプロジェクトによって大分左右される領域ではありますが、
エンジニアとして強みがあるだけで自信にもなるし、横展開しやすいのでもっと深めていくべきでした。
自分の場合は、各プロジェクトでそれぞれ異なる技術スタックに触れてきたので、
どちらかと言えば、広く浅く。そして、そこまで広くもないといった具合です。
もちろん、将来的にフルスタックとして活躍できることが理想ですが、その中でも武器はあったほうがいいのは間違いありません。それがインフラなのか、フロントなのか、特定の言語なのかはさておき。
今後はここを目指していきたいですね。
■ [おまけ]うるるで培われたマインド集
うるるに入社してから、会社の文化はもちろん、様々な方に影響を受けてきたので、
最後にそこで培ったマインドを紹介します。
-
考えやイメージを図で表現し、説明できるようにする
- この人の説明わかりやすいなという人はみんなやっていたので、率先して真似してます
- この記事ではまったく図を使っていないですが（笑）
-
楽しく働くことを目指せば、自ずとチームとしての生産性があがる
- 尊敬している先輩エンジニアのマインドをパクっています
-
既存のシステムを使ってできないかをまずは判断する（車輪の再発明を回避）
- 自前で実装しがちな時にストップをかけてくれる
-
ミニマムにできる方法を考え、スモールステップでのリリース
- 最低限の状態でリリースや実装することで見えてくることも多いですね
もっとあるでしょう？と突っ込まれてもおかしくないですが、きっともっとあります（笑）
うるるでは日々学びしかないので、少しでも恩返しできればと思います。
さいごに
読んでいただきありがとうございました。
正直、当たり前すぎる内容がほとんどだったかと思います。
もちろん当たり前と思っていても、それを実践できるかは別だと思いますが、
根底には、エンジニアとして働くことの楽しさやもっと活躍したい・成長したいという意欲があったからこそ、やってこれたのだと思っています。
正直うまくいっている方なのか、成長度合いは足りているのか不安に思う面も多々あります。
とはいえ、ここまでやってこれたことには自信を持ってこの先も進んでいきたいと思っています。
この記事を読んで頂けた方の少しでも参考になって頂けたら嬉しいです。
改めて、読んでいただきありがとうございました。
明日は@swcityさんの記事です！みなさんお楽しみに！