改善チームエンジニアとしての1年目振り返り

# 背景🖼
社内で改善（横串）チームとして運用チームとは少し距離を置いて業務をしています
改善チームは私一人のみです
ほぼフロントエンドエンジニアの動きをしています
この一年を振り返りながら、やったことの棚卸しと今後の展望を共有したいと思います

# 業務で取り組んでいること💪
- 複数プロダクトをまたぐ開発
- 新規プロダクト開発
- バックエンドエラーログ調査
- ライブラリバージョンアップ、ライブラリ選定
- サイトリニューアル対応（Nuxt→React+Vite）

# 自分が+αで取り組んでいること🏃
## 運用チームの定例会議(2チーム)に参加
課題をヒアリングします
↓
求められていることを把握し、それに対して徹底的に調べ上げます
↓
記事にまとめて来週の定例で共有しています
- Qiitaで書いてます、以下が例です
    - [ノーフレームワークのChrome拡張機能にCssModulesを導入する](https://qiita.com/yamatai12/items/cd8ae7efb06e785a7d40)
        - 背景:tsファイルでcssを管理しているのをcssで管理できるようにしたい
    - [EsLintのルールを幾つ知っていますか？](https://qiita.com/yamatai12/items/ebde3b4e92c870227712)
        - 背景:コーディングルールが多くなり、覚えるのが大変になりそう

実はもう1チームあるので参加してみようと思います、キャパが足りるか不安です😂

## 社内のtechshareチャンネルで投稿
投稿する内容は社内で需要がありそうなものに絞っています
有益な投稿をたくさんして社内のエンジニアの方に刺激を与えることを心がけています

### 記事を書き共有する
例:[ESLintで命名規則のチェックをする](https://qiita.com/yamatai12/items/8d229f318a1a57b7af5e)
命名規則は社内の共通のコーディングルールとして統一されている為、これを自動でチェックしてくれるのは需要がありそうだと思いました

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/405182/1587217e-971f-d65e-8873-3496b2b7312c.png)

Qiitaで記事を毎月10本書いてます
- 記事を書くと忘れずらいなと思いました
- 自分のトラブルシューティングにもなってます
2023年の9月から始めてこれで92投稿目です💪✨

Qiita Organizationランキングで自分の会社が何位か確認することにハマってます（株式会社iimon）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/405182/3b12068c-9564-bd38-ee2d-64fb24766080.png)

嬉しかったことがあってそれは、今までこのチャンネルで投稿してなかった人が僕を見て「アウトプットするようになりました」と言ってくださったことです。
お互い切磋琢磨していける環境をこれからも作りたいです。

### techイベントの共有
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/405182/ae5c4cb6-e685-04a0-55fc-759e042bcbb1.png)

[connpass](https://connpass.com/)で血眼になりながらイベントを探しては共有しています！
社内で直近盛り上がりそうなイベントは5/11にある[TSKaigi](https://tskaigi.org/)ですかね

## 他のチームのプルリクを見て学ぶ
私は一人で活動しているので他人のソースを見る機会が少ないです。
ありがたいことに弊社は担当外のリポジトリもアクセスできます。
それを生かして自分とは関係ないプロジェクトのソース、プルリクを見て学んでいます

## 新しい取り組みをする
自分が今までしたことがないことをし続けることを心がけています
私の実装のReviewerは運用チームの方々なので彼らにとっても有益なソース、開発手法を共有します

### クラス図を作成してから実装に入る
実は運用チームにいた頃はいきなりソースを書いていました
これだと以下の問題が発生しました
- 俯瞰的にクラス間の関係が見れない
    - Rv依頼時のReviewer、プロジェクトの新規参入者等の初見でソースを見ても分からない
    - 実装の手戻りが発生する

そこで毎回クラス図を作成しそれをプルリクに載せています

draw.ioでよく作成しています。
以下のVSCodeの拡張機能でも作成したりしてます。
[classdiagram-ts](https://marketplace.visualstudio.com/items?itemName=AlexShen.classdiagram-ts)

### JSDocをソースコメントに入れる
今までJSDoc記法とは決めずにコメントを書いていました。
JSDocで記述するとコードヒントで説明が表示されるのでとても便利です。

以下の記事で紹介しているのでよければご覧ください！
[JSDocについて理解する](https://qiita.com/yamatai12/items/3482fc31b9c73c6938bd)

### gitのブランチを細かく切る
今は以下のように細く切っています
```
main
|-release/product
    |-feature/A
    |-feature/B
    |-feature/C
        |-feature/C-1
```
このようにすることで以下のメリットを感じました
- Review待ち中にも開発を進められる
- まめにプルリクを作成できることで進捗が可視化されやすい
- ReviewerがReviewしやすい
- プルリクで差分を少なくすることでより高度な議論ができるようになりました

### featuresディレクトリの導入
```
src
|-new-product
    |-api
    |-types
    |-utils
    |-views
```
featuresディレクトリにより以下のメリットがありました
- コンフリが起きづらい
- 影響範囲が明確になる
    - 工数見積がしやすい
    - 新規参入者の認知的負荷の軽減にもなり、生産性が上がる

### テストコードと実装を同時に進める（工数に余裕があればという所になると思いますが。。）
今まではリリース後にテストコードを書いていました
これだと以下の問題がありました
- リリース後にバグが頻発する
- デグレが起きやすい
- 修正に追われテストコードが追いつかない

実装とテストコードを同時に進めることで以下のメリットがありました
- テスターにテスト依頼をする前にデグレに気づき、再テストになりづらくなる
- テスト環境（フロントなのでjsdom）でバグを再現でき、ブラウザで確認せずとも修正可能
- リリース後のバグ報告がない、使われているのか心配になるくらい

### 最近クロスブラウザ対応したdialog要素を導入
今までは```role=dialog```で実装していました
[dialog要素](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog)を使用することで実装の手間が減り、またアクセシビリティの向上もしました
以下はdialog要素について書いた記事です、よかったらご覧ください！
[dialog要素をEscキーでcloseした際にoverflow:hiddenを解除したい](https://qiita.com/yamatai12/items/43f2613a5556674542a4)

### AntDの導入
社内では既に[MUI](https://mui.com/)を使っているプロジェクトがありましたが以下の理由で[AntD](https://ant.design/)を導入しました
- AntDの方が対象のプロジェクトの仕様との相性が良い
- コミュニティの規模としても十分大きい

### ESLintのルールの設定を充実させる
自分が今までReviewで指摘された内容がESLintのルールにあることを知り、それら全てをLintで設定しました
これにより、プルリク上では高度な議論に専念することができます

## Reactに関することを何でも呟けるチャンネルを作った🍵
Reactは言うまでもなくトレンドで、弊社でもReactを導入しています。
現在サイトリニューアル対応（Nuxt→React+Vite）をしており、運用チームの方々がReactに慣れたり、質問できる場を作れないか考えたところチャンネルを思いつきました
また、他のプロダクトでReactを使っているのでプロダクトを超えて社内にReactのノウハウを蓄積させることができます

今対応しているサイトリニューアルの概要はこちらです！
[パス単位でVueからReactにリプレイスする](https://qiita.com/yamatai12/items/0730f60859ef792f1537)

## 社外のtechイベントに参加し情報を収集する🕵️
### 社内で困っていることを相談する
- 導入に迷っているライブラリが社内では実績がなかった（当時[zod](https://zod.dev/)で迷っていました) 
    - よく使われていることがわかった
- [NuxtBridge](https://nuxt.com/docs/bridge/overview)でNuxt3移行できた前例が中々調べても見つからなかった
    - vuefesjapanに参加されていた方々に聞くと、NuxtBridgeをお勧めされなかった
    - これはとても有益で現在のReact移行に踏み切れました
### 便利なライブラリを知る
- dependency-cruiserという依存関係を管理してくれるライブラリの存在を知った
    - 記事にまとめ、社内で共有しました、以下よければご覧ください！
    - [dependency-cruiserについて理解する](https://qiita.com/yamatai12/items/fce4104e273981f78807)

### 領域限らず有益な情報を知る
- 「認知的過負荷」というワードを知りました
    - 以下にまとめましたのでよければご覧ください！
    - [認知的過負荷を回避して生産性を向上させる](https://qiita.com/yamatai12/items/e523166bf282b5b7b18d)

社外のtechイベントに参加することで
```社内で当たり前、当たり前でないことが社外では違うこともある```
ということを知れて良かったです

## 技術的な相談の対応
技術的に困っていることの質問をありがたいことに運用チームの方に相談をして頂けるので勉強になっています！
直近ですとJestのテストコードだったり、namespaceを導入するか等です。
今後も有益な情報や助言ができるように日々インプット、アウトプットしていきたいです。

## 色々なことに挑戦する
現在ありがたいことにそのような機会を頂いてます
フロントエンドエンジニア寄りでしたが他に領域の経験値が低すぎる為自分にムチを打ってます
例えば以下です
- AWSのCloudFrontでリバースプロキシを作成する
- バックエンドのAPI作成

# 最後に
- 社内の運用チームから引き続きヒアリングをし、彼らの求めてることにダイレクトに自分の全力を注ぎたいです
- 社外でLT登壇し、壁打ちをいてもらいブラッシュアップしていきたいです（いずれは社内でtechイベント開きたい。。）
- Qiitaやアウトプットで自分の知名度を上げることで会社自体の知名度も上げていきたいです
- 社内のエンジニアに良い影響、刺激を与え続けたいです
- 技術選定の経験をもっと積みたいです
- バックエンドも一般レベルまではつけないといけないなと思ってます
- 使用中のライブラリのメンテナンスの経験を積みたいです
- これからも社内で技術に尖ったエンジニアを目指します

最後までご覧いただきありがとうございました
いいねいただけると記事執筆の励みになります！
参考になったと思われた方は是非よろしくお願い致します🙏