[ポエム] 5年間で学んだこと、足りなかったこと、これからやること

# :tea: 前置き

タイトルに「エンジニアとして」と書きましたが、実際にはプロジェクトマネージャー（PjM）のような立ち位置や、技術以外のこともたくさん経験してきました。

技術力・コミュニケーション力ともにまだまだ未熟ですが、5年間の振り返りを通じて自分の成長や課題を整理し、次のステップに活かしていきたいと思います。  

また、30歳という節目を迎えるにあたり、「これまでの自分はどうだったのか」「これからどう成長したいのか」を言葉にすることで、改めて自分の姿勢や未来を見つめ直す機会にしたいと思います。  

技術的な話ではなく、自分の仕事に対する向き合い方や考え方について書くので、これはある意味**ポエム**です 笑。  

# :eyeglasses: 前提
大まかに5年間どのような経験をしてきたかをまとめます。

- 同じ開発会社に所属し、7つほどのプロジェクトに参加（数ヶ月〜1年以上含む） 
- フロントエンド（FE）、バックエンド（BE）、PjM といった複数の役割を経験  
- **技術スタック**：Laravel, Next.js, NestJS あたり
- **インフラ経験**：SAA取得や ElasticBeanstalk でのデプロイ経験はあるが、インフラはまだ弱い  

ここ3年ほど Laravel には触れていませんが、JavaScript（TypeScript）を中心に取り組み、いくつか記事を書きました。  
- [Next.jsのエラーハンドリング: サーバーからクライアントまで](https://qiita.com/aburasoba/items/a1fd399dd490e7402518)  
- [JavaScript の Date オブジェクトについてのメモ](https://qiita.com/aburasoba/items/48737b118d75e40e7488)  

PjM ロールの際には、開発管理や仕様書作成についても記事を書いています。  
- [小規模チームでの開発管理とスクラム](https://qiita.com/aburasoba/items/21024b8b79bc344e7edb)  
    - 当時は Jira がなかったため GitHub でプロジェクト管理しました。今はすっかり Jira に依存しています。  
- [認識齟齬を防ぐための仕様書](https://qiita.com/aburasoba/items/a18dd4f6b1a907f6ab87)  

インフラ系では Amplify について書きましたが、結局は Vercel に落ち着いて静的ページをホスティングしています。
- [Amplify にデプロイしたアプリケーションをサブドメインで運用する](https://qiita.com/aburasoba/items/2c8d992b051e87565951)  
- [実際にホストしたサイト](https://ttsubasa.com/)  

# :point_left: ポイント

## 懸念を早めに共有する
この1年で特に意識するようになったのが「懸念の早期共有」です。  
会議や業務中に「あれ、これどうなってるんだっけ？」「この部分がふわっとしてるな」と感じたことは、後になってトラブルや手戻りの原因になることが多いです。  

最初は自分の違和感や不安をチームに伝えることに抵抗がありましたが、思い切って早めに共有することで、**火種を未然に防ぐ**ことができると実感しました。  

リスク管理において大切なのは 
- **リスクの可視化**（重要度・発生頻度の整理）  
- **対応策の分類**（回避 / 転嫁 / 軽減 / 受容）  

最初は簡単な報告や口頭ベースでも良いですが、徐々にリスク管理シートを活用することで、より体系的に管理できるようになります。

これにより、チーム全体の安心感が増し、「**リスクは共有するものだ**」という認識も生まれました。  

## ドキュメントを書く  
以前は「エンジニアの仕事はコードを書くこと」だと思っていましたが、今では設計やドキュメント作成がどれだけ大事かを痛感しています。  
コードを書く前にしっかりと設計し、それをドキュメント化してチームに共有することで、手戻りやコミュニケーションロスを減らせます。  

PjMロールを経験した際に「どうすれば共通認識をとれる仕様書を作れるか」を考え、記事にもまとめました。  
- [認識齟齬を防ぐ仕様書のポイント](https://qiita.com/aburasoba/items/a18dd4f6b1a907f6ab87)  

**設計とドキュメントは、チーム全体の効率を上げる基盤**です。エンジニアとして働く今でも、この経験が活きていると感じます。  

## なぜこのコードが必要か  
エンジニアになりたての頃は「動いたらOK！」という気持ちで満足していました。動いた瞬間の達成感は最高ですが、その無計画なコードが**大きな負債**になることを学びました。  

- **なぜこのコードが必要なのか？**  
- **このコードが将来どう影響するのか？**  

当たり前のことですがこれを理解し、説明できる状態で PR を出す、コードの質と安心感は大きく変わります。


## 英語力  
エンジニアにとって英語力は避けられないスキルです。  
ドキュメントを読むのも英語ですし、海外エンジニアと協働する機会も増えてきました。

最初は苦労しましたが、少しずつ慣れ、議論や共有ができるレベルに近づいてきたと思います。  

12月には TOEIC を受けましたが、出来栄えは微妙でした……。引き続き継続して勉強します。  


# :imp: 足りなかった  

## 技術書を読む  
いくつか技術本を読みまとめ記事を書きましたが、全く足りませんでした。
- [「良いコード/悪いコードで学ぶ設計入門」を読んで所感とメモ](https://qiita.com/aburasoba/items/58d235bdccad005f3ee5)
- [感想「Clean Architecture 達人に学ぶソフトウェアの構造と設計」](https://qiita.com/aburasoba/items/828a147ccea5d127ad2a)

ブログや技術記事も良いですが、技術書から得られる体系的な知識はエンジニアの基盤です。  
2025年に読む技術書を宣言します
- [ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本](https://amzn.asia/d/8H8ixvC) 
- [SQLアンチパターン](https://amzn.asia/d/8iq0cn6)
- [オブジェクト指向UIデザイン](https://amzn.asia/d/awNO1VX)  
- [テスト駆動開発](https://amzn.asia/d/3qaVm8R)

# ポジティブ  
物事をネガティブに考えがちな性格ですが、ネガティブ思考はリスクを避ける力でもあります。

大切なのは**バランス**。ただネガティブになるのではなく、**建設的なポジティブさ**を意識し、周囲に良い影響を与えられるエンジニアを目指します。  

## アプリのアウトプット  
「これが自分の作ったものだ！」と胸を張って言えるアプリがまだありません。  
2025年の目標は**自分のアプリを1つ作る**ことです。

趣味の範囲でも良いのでアウトプットを続け、技術力と会話の幅を広げたいと思います。  

# :footprints: 最後に  

この5年間、振り返ればまだまだ未熟で学ぶことばかりですが、確実に積み重ねてきたものがあります。
30歳も頑張っていきます。