はじめまして、ソフトウェアエンジニアやってますkazuです🦌
エンジニアを目指した時からつけている学習記録が、ついに4000時間に到達したので、振り返りをしました！
エンジニア歴2年半で、3000→4000時間の間に何をやって、実務でどこが伸びたのかを中心に振り返ります✨
学習記録
エンジニアを目指し始めてから、ここまで至るのに学習時間を記録してきました。エンジニアになってからは、特に時間を目標にしてたわけではないのですが、せっかくなら1万時間まで目指してみようと思い続けています。
以下に、これまでの学習経過についての記載があります。
※2000→3000時間は、記事にするのをすっかり忘れていました。（無念）
3000時間に到達した日
15時間ごとの内容は詳細に記載されてません。（途中からめんどくさくなってしまった）
紙ベースということもあり、行を取れないことも起因🫠
4000時間に到達した日
紙が書けるスペースなくなったので、notionにやっと移行。
最近は、転職したこともありJavaの勉強がメインになっています。
こうしてみると1年で、1000時間程度勉強している感じです👀
1000時間やっている割には、実が伴っていない気もする…（笑）
これがあったからこそ、未経験からのエンジニア転職とメガベン転職ができた気もするので、結果オーライということで！笑
詳しい内容については、noteに記載してますので興味ある人はぜひご覧ください👇
【独学×未経験から自社開発（SaaS）エンジニアになるまでの道のり】
【エンジニア歴2年、開発歴半年でも年収250万UP＆メガベン内定をもらえた話】
これからの1000時間は、理想のエンジニア像に近づくため「何を学び」「どんなスキルを身につけるか」を意識しながら目標を立てていきたい…
こなしたプロジェクト/タスク
前職と現職でやったことをまとめております。書籍なども紹介しています。
前職
新STG環境へのサービス移行作業
- Serverless FramworkからSAMへの移行作業
AWSを使用していたので、パラメータや連携性を考えてServerless FramworkからSAMへ移行。
SAMに慣れていたため、Serverless Framworkは読みづらかったけど、こういうタスクはcursor君の得意分野なので、かなり楽に移行できました！
- Terraformを利用したインフラ構築作業（VPC/ECS/ECR/ALB）
このタスクで、初めてTerraformを利用。Terraform取り掛かってみて分かったのは、アプリケーション言語と作りが全く違うこと。最初は、まじで読めなさすぎて、「どこになにがあるんじゃー！！！」と何度も発狂しました（笑）
途中で、関わるタスクが変わってしまったため、新STG環境へ全て移行することができず。プライベートでTerraformを勉強しようと思って勉強することがあまりないので業務で触れることができたのはラッキー🦌
GitHub Actionsを用いたCIパイプラインを構築
- Laravel×Docker環境において、lint、静的解析（Larastan）や整形（Pint）などを自動実行するCIを作成
こういう後回しにしてもいいけど、やったほうがいいことは、とりあえず先にやったほうが後々楽になるので、環境整備は気になったら逐一やるべし。
Xdebugの導入
- XdebugとVSCodeを連携するための仕組み理解
Docker環境が整備されていると、Xdebugのような拡張機能も設定されていたりするのですが、新しいプロジェクトだったため、そういうのもなくいざ自分が設定をしてみると知らないことだらけ😭先人の肩の上に乗っていたことを痛感したタスクでした笑
Xdebugを用いたVScodeのデバックをするために、PHPが実行中のDockerコンテナと、ローカルのVSCodeにインストールされたX debug extension との間で通信が行なえるように設定しました。
シーケンス図に起こすとこんなん。DockerもVSCodeも奥が深い…
Laravelを使用したAPI実装
- N+1問題に出くわす
実装してPR出した時に、コメントでN+1問題について言及され、初めて知る。
N+1問題は、親データを取得した後に、関連する子データを個別に取得することで、クエリ回数が増加してしまい、パフォーマンスが低下する問題。Laravelを使用していたので、withを利用することでEager Loadingを適用しクエリの回数を減らす方針をとった。学びのあるタスクでした🙌
新規サービスの開発
- React/Next/TypeScriptを用いたフロントエンド実装
新しいサービスは、Nextを利用することになったので、初めてReactを触ることになりました。これまでフロントのFWは、Vueとかだったので最初は苦戦したものの徐々に慣れてきました！
ただ、TypeScriptだけは最初Reactよりもかなり苦戦した記憶。お作法が掴めるまでは、LeetCodeなどで遊んでました！このタイミングでモダン言語触れたのはラッキーで、転職活動中も一定の評価は得られた。
フロントエンドとバックエンドのチームが分かれた状態での開発
- レスポンスの返り値を意識した型定義
これまでリポジトリが1つしかないプロジェクトでの開発経験しかなかったので、リポジトリがフロントとバックエンドで分かれているパターンをやったのは今回が初めて。
フロント実装部隊を担当したのですが、アーキテクチャの設計、責務の分離をどう行うのか、APIを直呼びしないようにどうカモフラージュすべきか、サーバーコンポーネントとのやりとりはなんのファイルを用いるのかなど新しい観点をたくさん学んだタスクとなりました！
ServerActionsとかこれまで知らなかったし、副作用について意識することの重要性を学べた。
レスポンスに対する意識もだいぶ上がった気がする。バックエンド側の設計がしっかりしてないと、フロント側への影響範囲がでかいことも学べたので、レスポンスをある程度型化テンプレートみたいなの用いて柔軟に対応するなどいろいろやり方があるんだなーとなった。
フロントエンドだけしかやってない人とバックエンドをやったフロントエンドじゃ、見えている範囲が全然違うことも知りました。
社内システム自動化プロジェクト
- AWSサービス（EventBridge/Lambda/DynamoDB/Aurora）を活用したマイクロサービス的なシステムを設計
そんな大きなシステムではないのですが、初めて要件定義から実装までをこなしたのがこのプロジェクト。AWSについてなにも知らなかったのですが、頼る人が誰もいない状態だといつもより自分ごと化が進むのでなんだかんだレベルが上がります。無論、相談できる人たちはいるので自分がわからないところはどんどん相談してました！
最初は「AWSむずい、ワカンナイ」状態だったものの、やればなんとかなるということを学びこれ以降のタスクにもそのマインドはだいぶ活きたと思います。
- DTOクラスを活用して、DB更新時に必要なデータのバリデーションや整合性を担保。データ転送の安全性を重視し、ロジックから分離することで単一責任の原則を徹底しました
この時はDB更新に必要なデータを型変換する必要があり、整合性を担保するために、DTOクラスのデザインパターンを教えてもらい実装。DBの構造に合わせた形でデータを整形することができ、DB更新が楽になった覚えがあります。
- AWS Step Functionsを活用して、複数のLambda関数を一貫して管理可能なワークフローを構築
- AWSリソースのデプロイや管理を効率的にするため、SAMを導入し、GitHubと連携することでインフラコードを管理可能にした
- GitHub Actionsを連携し、samconfig.tomlにパラメータを追加することで自動デプロイのフローを構築。stg/dev/prdの使い分けも可能にした
LambdaAの実行が成功したらLambdaBを実行という形でフロー化したかったので、Step Functionsを利用。SAMでStep Functionsに関する設定をしながら、VPCやプライベートサブネットとパブリックサブネットの違いも学んだ。SAMでのリソース管理により、GitHub上でバージョン管理することができ、デプロイなども効率的にできるようになりました！
イベント企画・運営・実施
- 長期開発イベントの企画立案/運営
1年ほどかけて、社内ハッカソン的なイベントを実施。組織のコミュニケーションを活性化させることを目的にいろんなチームからメンバーを募集して、参加してもらいました！
開発組織の課題洗い出し、解決手段の選定やイベントの計画、タイムスケジュールの計画、工程管理、社内コミュニティとのコラボ企画を提案・実施したり、社会人基礎力向上にはもってこいのイベントだったと思います！イベントの企画などエンジニアがやらないようなことをたくさんやっていると転職活動の場で評価されたりするので、こういうのはどんどんやったほうがいいと思います！組織やチームに対して呼びかけができる、巻き込むことができる人材はどの企業も探してるので、おすすめです✨
- 開発組織オフラインイベントの企画立案/実施
こちらは、プロダクトチームの1日交流イベントということで、寿司職人の友人を呼んでお寿司を振舞ってもらいながらゲームなどをして交流することを目的として開催しました！
イベント当日も楽しかったのですが、コンテンツ企画などアイディアだしが一番大変でした🥹
予算もあったので予算内に収めながら、満足度高いイベントを開催するかという視点は、プロダクト作りでも同じだなと思います。制約がある中で、なにを優先してなにを捨てるかを見極める目は、なにをしても得られる要素だなと感じます。
現職
API組み込み（参照系）
- 調査
既存コードは、Javaで書かれておりコードリーディングから着手しました。
Javaはこれまで使ったことがなく、同様にSpringも初見だったのでこの辺のキャッチアップをしながら読み進めていました。ここで問題だったのが、読み進めていけど全く理解が進まない…
コードがカオスであること、言語仕様の理解不足もあったのですが、コードリーディングを技術として昇華できてなかったことが要因として一番大きいです。
プログラマー脳にも書いてあるのですが、
平均的なプログラマーは、コードを書くではなく読むことに業務時間の60%近くを費やしている
と言われています。これまで自分は「なんとなく読んでいるつもり」になっていただけで、本当の意味でコードを読み解くことができていなかった事実に直面しました。
このタスクによる収穫は以下の2つです。
- つよつよエンジニアからコードリーディングのやり方を学べたこと
- 認知的リファクタリングの重要性
実際、これらを実践してみるとコードを理解することがそこまで難しいものではなく、前よりもはるかに短い時間でコードを理解できるようになりました。
言語化できるようになったら、この辺は記事にできればと思います。
参考
- テスト分析/テスト設計
自分の所属チームでは、既存システムのマイクロサービス化を進めており、その一環として 新規APIを既存システムに組み込むタスク を任されていました。
これまで本格的な テスト分析・テスト設計 を経験したことはなく、
- どんなテストが必要なのか
- そのテストによってどの品質が担保されるのか
- 同値分割や境界値分析がどの観点を保証するのか
といった部分まで踏み込んで考えるのは初めてでした。
しかしこの取り組みを通して、
「自分が実装するとき、どこに気をつけるべきか」
を逆算して考えられるようになり、視野が大きく広がりました。
特に組み込み系のタスクでは、ユーザー影響を絶対に出さない ことが前提となるため、
その目的に適したテスト観点・設計が求められます。
品質とは何かを自分の言葉で語れるレベルまで、プロダクト理解を深めたいという強い気持ちを持つようになりました。
個人で、参考にさせてもらった資料
チームとして参考にしてたのはこちら
- Javaの理解
現職に入ってからJavaを勉強し始めたのですが、1つの言語を追求する楽しさを絶賛味わっている最中です。やはり、最初の方はいろんな言語を触るよりも1つのことに集中して取り組む方が、土台が築きやすいなと思います。Javaのおかげで、オブジェクト指向の解像度も上がりましたし（入口の始まり）、JVM領域におけるメモリ管理もざっくり理解できるようになりました。またJava特有の言語背景（後方互換性やJava バージョンの歴史など）やスレッドセーフ性、リフレクションなどの技術も知ることができ（どこかで実装をしたい）、まだまだ浅瀬にいることは理解しつつも、それらの知識が点と点が結ばれていく過程は勉強の醍醐味だなと改めて実感しております。
参考にしている書籍
プライベート
開発チーム立ち上げ
- DevLab開発チームの立ち上げ、運用、チーム開発
自分たちの技術力向上を目標に、開発チームの立ち上げを行いました！
普段からエンジニアコミュニティには属していたのですが、そこで何かを作ることはしてなかったので、「みんなで遊べる方法ないかなー」と考えた結果、「遊び場を作ってしまえばいいじゃん！！！」となり立ち上げた経緯となります（笑）
最初に、SNSスカウターというミニマムのプロダクトを作り、徐々に課題を解決するようなプロダクトづくりにシフトしていく形で、今3作目となります。
技術的な学びはもちろんのこと、普段携わることのない要件定義から技術選定、画面設計、DB設計などプロダクト作りにおける一通りの経験を積めるので、幅広い知識と視野、経験を手に入れることができます。普段のプロダクト作りにおいて見えてる世界は点で捉えていたんだなと改めて思い知った。線で捉える世界観は、開発フロー全体を体験したからこそ見えた景色です。
学習スタイル/習慣の変化（要点）
この1000時間で、学習の進め方もかなり変わりました。特に効いたのは次の6つです。
- 網羅学習より「行動→フィードバック」を先に回す
- タスク単位で学びを記録する
- 普段から問いを立てる
- 図にして理解と説明を揃える
- 抽象と具体を分けて整理する
- 振り返りを前提に、記録を検索可能な形で残す
このあたりは分量が大きくなったので、具体的な運用方法は別記事に切り出しました。
関連記事
まとめ
3000-4000時間を振り返ると、新しいことに挑戦した1000時間だったなと思います。まだまだエンジニアとしては未熟であり、幅広く浅く経験しただけに過ぎないのでこれからが勝負かなと思います。バックエンドエンジニアとしての土台をこれからの1000時間では少しずつ固めていければと思います。今回の転職活動で「クリエイティブなエンジニアを目指す」というエンジニアとしての目標も一つ見えてきたので、その道を目指しながらこれからも邁進していきます！