はじめまして、ソフトウェアエンジニアやってますkazuです🦌
エンジニアを目指した時からつけている学習記録が、ついに4000時間に到達したので、振り返りをしました！
※2025/11/30 この記事を改めてみると、1000時間の振り返りというより2025年の振り返りになっていたことに後から気づきました（まあ、ご愛嬌ということで...笑）
エンジニア歴2年半で、「どんなことを学んでいるのか」「何を身につけたのか」など気になる方は見ていってください✨
学習記録
エンジニアを目指し始めてから、ここまで至るのに学習時間を記録してきました。エンジニアになってからは、特に時間を目標にしてたわけではないのですが、せっかくなら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設計などプロダクト作りにおける一通りの経験を積めるので、幅広い知識と視野、経験を手に入れることができます。普段のプロダクト作りにおいて見えてる世界は点で捉えていたんだなと改めて思い知った。線で捉える世界観は、開発フロー全体を体験したからこそ見えた景色です。
学習スタイルの変化
網羅的に学び、迅速に行動して、フィードバックを得るスタイルを構築
前までは、教科書なりチュートリアルなりを読み込んでから行動して、そこから照らし合わせながら進めていくスタイルだったのですが、cursor課金するようになってからは、いまのスタイルになりました。ざっくりでもいいのでとりあえずなにをすればゴールなのかを自分で設定して、そこまでできるようにしながら、足りない部分をチュートリアルで補填しながら、出来たものに対してcursorからフィードバックを得るやり方をしています。
友達がPRコメントしてくれる場合は、そちらの方が学びが多い場合があるのでそうします。何にせよ失敗までのサイクルを早める事で学習効率は上がったように思います。
各タスク毎にnotionページで管理するようにした
- そのタスクで学んだことをまとめられるようになったので、検索と過去の振り返りが格段にしやすくなった
これは1月から始めたのですが、タスクをこなしていると必ずそこに付随した学びがあるので、タスクごとにそれを管理したいなと思いタスク管理ページを作りそこで管理しています。
検索性が良くなったことで、似たような事象に対峙した時にも過去のやり方を参考にできたり、過去の振り返り自体をする時にも役に立ちます。内容を覚えてなくても、自分の記憶 or notionの記憶のどちらかで検索をすればいいので、覚えておく必要もありません。これをやるようになってから過去の振り返りをしたい時などかなり楽になりました。
※一部
問いを立てる意識
これまでは行き当たりばったりで、わからない単語や知らない仕組みを調べたりでどうにかなっていた部分も、どうにもならない時があります。例えば、議論をしているときに意図的に問いを投げかけたい時、もしくは自分の中でのフックを作りたい時など普段から問いを立てることを意識してないと意外とできません。僕は、それが得意なものと不得意なものがあり、特に前提知識がないことに関してはフックの作り方がわからず議論の場で苦戦することもありました。とはいえエンジニアとしては必要なスキルのため、少しずつ癖はつけるようにしています。
図を意識した理解/説明
自分の頭の中を可視化することで相手と自分の認識のずれをなくし、議論をスムーズに進めるために図を用いてます。これはかなり効き目があり、ブレストするときもmiroなどで可視化することで思考の流れをみんなで確認するようにしています。こうすることで、他人の思考からアイディアとなるインスピレーションを受けたり、新しい視点が見えたりするので、図や付箋を利用したアウトプットはかなり効果的です。
また自分が理解する時にも、文字より図の方が理解が捗るので最近は図に起こすことも多いです。
業務上カオスなコードを調査することもありますが、そういう時はClaudeに構成図やフロー図、シーケンス図などmermaidで描かせるようにしてとりあえず理解できる形まで持って行けるようにしてます。
例）
抽象と具体の切り分け
こちらは、エンジニアなってからもやってますが、最近はcursorなどAIに対して指示をするときに、すぐに雑な指示を投げるのではなく、手順などを整理したり抽象度を合わせたものの情報を整理してから投げるようにしています。cursorで確かに素早くコードの生成はできるようになりましたが、その分人にとってはわかりづらいコードであったり、不要なものを追加したりして、確認する作業も多くなりました。そのためそういったゴミコードをなるべく生成しないためにもテキスト設計をしっかり行なった上で指示をするようにしました。タスクの洗い出しともに、チェックボックスを設けて、できてるタスクとできてないタスク、今はやらないタスクなど全て可視化しておくとAIも自分も後々確認が楽です。
AIをただのアウトプットマシーンとして利用すると、自分の中になにも残っていないことに気づいたので、面倒でも上記のようなやり方をすることにしました。
身につけた習慣/新しく始めたこと
LeetCodeでのアルゴリズム勉強
これまでも時間があるときは、アルゴリズムの問題は解いていたのですが、業務が忙しくなったり、転職活動でなかなか時間が取れないとなってからはぱったりやらなくなりました。やっと最近は落ち着いてきたので再開。
最近意識しているのは、「想起力」と「具体的な計算手順の理解」。
僕の中で、アルゴリズムの問題をこなすのはアルゴリズムの問題に特化するというより、計算ロジックに慣れる、計算手順を思考する、コードに慣れる、これらのニュアンスが強いです。
白紙の状態から、コードを生み出せるくらいには1つの問題をやり続け、コードに対する理解や問題に対する理解、類似問題で応用できるようにしたりできることは色々あるので、趣味程度に遊んでいます。わからない問題だと、問題を見てもわからないので、解答をみたりして、その解答のロジックをコードリーディングして理解に落とす。2回目以降、できる/できないの部分を自分で把握することで、言語仕様につまづいているのか、計算ロジックの理解につまづいているのか、制御フローの構造理解でつまづいているのかなど同じ問題を回数こなすと見えてくるものがあります。自分ができないことを理解できれば、あとはできるようにするだけなので、その繰り返しで少しずつ解ける問題が増えていってるように思います。
まとめ
3000-4000時間を振り返ると、新しいことに挑戦した1000時間だったなと思います。まだまだエンジニアとしては未熟であり、幅広く浅く経験しただけに過ぎないのでこれからが勝負かなと思います。バックエンドエンジニアとしての土台をこれからの1000時間では少しずつ固めていければと思います。今回の転職活動で「クリエイティブなエンジニアを目指す」というエンジニアとしての目標も一つ見えてきたので、その道を目指しながらこれからも邁進していきます！