WEBエンジニアとしてレベルが上がった気がする経験と考え方

## はじめにと対象読者

高卒、エンジニア知識0、ブラインドタッチもできなかった私が、7年のエンジニア経験で個人的にレベルが上がったと思う経験や、考え方について書きたいと思います。

対象読者はエンジニア歴1~2年ぐらいの方や、伸び悩んでいる方です。
そういった方が少しでも成長するきっかけになればと思います。

## 私のスキルスタック・経歴

### スキル

スキルと経験年数は以下の通りです。
メインはjava,kotlin,Springのバックエンドエンジニアです。

* 言語
    * java:6年
    * kotlin:2年
    * python:0.5年
    * html,css,js:7年
* フレームワーク・ライブラリ
    * Spring,Spring boot:6年
    * Struts,SAStruts:1年
    * Django:0.5年
    * React:0.5年
    * Vue:0.5年

### 経歴

ざっくりとした経歴は以下です。
7年間緩やか~に成長してきましたが、ITの知識0の田舎者にしてはうまくやってこれたような気がします。

* **2017年4月**:21歳で単身上京し、社員20人程度の小規模SESの会社に入社
* **2017年4月~7月**:厳しい研修を耐え抜く
    * 3人入社したが、残ったのは自分ひとり
* **2017年8月~2018年3月**:社内請負の新規システム開発に参画
    * 新人なのに一本目の機能開発をやり、後から入ってきた先輩に直されまくる
    * バグをだしまくる
* **2018年4月~2019年3月**:金融系の会社に出向
    * 大規模なガチガチのウォーターフォールを経験
* **2019年4月~2019年10月**:python、Djangoの案件に参画
    * 新しい言語、フレームワークに触れる
* **2019年11月~2020年3月**:別案件に参画
* **2020年4月~2020年9月**:2017年8月~2018年3月でやっていた社内案件の新規機能開発に参画
    * 3人体制(自分、後輩二人)のチームリーダーになる
* **2020年10月~2022年4月**:金融系の会社に再度出向
* **2022年5月**:HR系のWeb会社に転職
* **2023年1月~2024年5月現在**:運営しているサービスの大規模リプレイス案件にリードエンジニアとして参画

## レベルが上がった経験

### 新しい言語、フレームワーク、ライブラリ、ツールに触れる経験

私は新しい言語、フレームワーク、ライブラリ、ツールに触れることで、設計の幅が広がりました。
例が少なくて恐縮ですが、以下のような感じです。

* Pythonではなるべく書かずに、ライブラリをガンガン入れる
    * それまでは外部のライブラリを使わなかったけど、やりたいことに合わせたライブラリを探すようになった
* Djangoではfactory_boyというRepository層のテストでテスト用のデータの作成と管理を簡単にすることができるライブラリがある
    * 同じようなものを自分たちの現場で自作できないかと考える

あの言語、フレームワーク、ライブラリ、ツールではこんな便利なものがあったけど、今の現場で似たようなものがあるかどうか探したり。
なければ作るなど、発想や設計の幅が広がりました。

新しい技術に触れることは、その技術を身に着ける以上の価値があると私はその時感じました。

### フレームワークやライブラリのコードまで読む

経験が浅い人は、フレームワークやライブラリのコードまで読まない人が多い気がします。
私もそうでした。
過去に未知のエラーが発生したときに、先輩に泣きついたことがありました。
その先輩はエラーの原因を誰かに聞くのではなく、フレームワークやライブラリのコードまで追って原因を突き止めていました。
このようなエラーの特定以外にも、フレームワークやライブラリのコードを読むことはメリットがあります。

* コードを読む練習になる
* よいコードが読める
* どのように実装されているかを知ることで、設計の幅が広がる

## レベルが上がった考え方

### 実装はできて当たり前

「プロのエンジニア、プログラマである以上実装できるのは当たり前で、そのうえで綺麗なコードを書いたり、よりよい設計、仕様などをお客さんに提案できるようならなければならない」

これは、1年目の最後に3か月間研修をしてくれたベテランエンジニアが教えてくれたことです。
「エラーが出て実装できないとか言っている場合ではなく、そのレベルを早く乗り越えて付加価値を提供できるようになりなさい」という意味です。
「そんなの当たり前じゃん」と思うかもしれませんが、作ることに精一杯だった当時の私にとっては目から鱗でした。

この考え方を取り入れてからは、もらった設計書をただコーディングするだけでなく、次のようなことを考えるようになりました。

* このプログラムで実現したいことは何なのか？
* この仕様は本当に必要なのか？
* もっといいやり方はないか？

これにより、設計者やお客さんに対して、より良い提案ができるようになったと感じています。
また、「良いコードとは何か？」についても考えるようになり、今ではリファクタリングやコード設計でチームに貢献できていると思います。

### リファクタリング

もし他のエンジニアと比べて、コーディングが遅かったり、バグが多い気がするなら、リファクタリングについて学ぶことをお勧めします。
仕様を整理して、だれがみてもわかるようにコードに落とし込めれば、劇的にスピードが上がり、バグが減らせます。
後からそのコードを修正することも簡単になるでしょう。

当たり前のことしか言えなくて恐縮ですが、WEBアプリケーションにおいてはわかりやすいコードを書くのはかなり重要ですし、最強です。
アホみたいな布教の仕方ですが、とにかくリファクタのことを学んで、実践してください。
とりあえず、[リーダブルコード](https://www.amazon.co.jp/%E3%83%AA%E3%83%BC%E3%83%80%E3%83%96%E3%83%AB%E3%82%B3%E3%83%BC%E3%83%89-%E2%80%95%E3%82%88%E3%82%8A%E8%89%AF%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%9B%B8%E3%81%8F%E3%81%9F%E3%82%81%E3%81%AE%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%81%A7%E5%AE%9F%E8%B7%B5%E7%9A%84%E3%81%AA%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF-Theory-practice-Boswell/dp/4873115655)を読むことをお勧めします。

もう一歩先の勉強をするとっかかりとして、[t_wadaさん](https://twitter.com/t_wada)の記事、動画、podcastを見るのもおすすめです。
まとめてくださっている記事がありました！

https://qiita.com/daijinload/items/3a884037875f317f813f

個人的には以下がおすすめ。

* [[fukaborifm] 100. A Philosophy of Software Design (1/3) w/ twada](https://fukabori.fm/episode/100)
* [[fukaborifm] 101. A Philosophy of Software Design (2/3) w/ twada/ twada](https://fukabori.fm/episode/101)
* [[fukaborifm] 102. A Philosophy of Software Design (3/3) w/ twada](https://fukabori.fm/episode/102)