はじめまして！CREとして働いてるkazuです🦌
僕が未経験エンジニアの時から続けている学習記録ですが、2023年12月26日に2000時間を超えたので、改めて1000→2000時間からの振り返りをしようと思い今回はそれを記事にしました！
エンジニアになってから、何を学び、どんなことをしていたのか、つらつらと綴っているのでよければ見ていってください✨
学習記録をつけ始めた理由
元々、エンジニアを目指していた時に、継続して勉強できることを定量的に評価しやすい指標が必要だと思っていたので、1000時間を目標に学習を行っていました。
このような流れから、1000→2000時間も記録をつけてみようということになり、その流れで今に至ってます。
以下は、実際に使用している学習記録帳です。
学習を始めた日
2022年2月13日
1000時間到達した日
2023年1月16日
2000時間到達した日
2023年12月26日
こんな、感じで手書きでざっくり学習記録をつけていました。
※初めた時がメモ帳を使用してたため、ずっとそのまま。
結果的に、未経験エンジニアから自社開発のエンジニアとして働けることになり、この学習記録も無駄ではなかったなと思います。
詳しい内容については、noteに記載してますので興味ある人は是非ご覧ください。
何を学んだか
CREエンジニアになってからは、主にバックエンド側を触る事が多く、独学時代はvueなどのフロントを触っていたため、最初の方は苦労しました💦※サーバー何？DBなに状態🙄
どんな事を学んだのか下記に記しました。
業務
- 業務上のコード理解
- PHP/Laravelの基礎
- PHPの基本的なメソッド
- Laravelのディレクトリ構成
- 各ディレクトリの役割
- テストコードの書き方
- サーバー/ネットワーク周り
- AWS
- ネットワーク構成
- 基本的なgit操作
- デバック手法
- フロントエンド
- 検証ツール
- バックエンド
- Xdebug
- フロントエンド
- SQL
- 基本的なクエリの書き方
- テーブル周りの把握
プライベート
- Linuxについて/コマンド操作
- gitコマンド/GitHub
- 低レイヤー
- OS
- ハードウェア周り
特におすすめしたいのが、デバック手法！「えっ、デバック？」ってなるかと思いますが、侮れません。CREでは、主に調査タスクをこなすため、この技術が必要不可欠であることは言わずもがなだと思いますが、コードを書くようになってもそれは変わらないと思います。結局、最初から綺麗に動くコードを書くことは不可能なので、どうしてもエラーが発生してしまいます。その時に必要なのが、デバックです。これを使用することで、問題の切り分けが可能ですし、エラー解決までの最短ルートを見つける事もできるわけです。
また、デバックと言ってもいろいろなやり方があるので、色んな武器を持った上で、エラーに立ち向かった方が、エラーの種類によって武器を選定できるので、結果生産性の向上も見込めるわけです。
僕は今までフロントのデバックをする際、console.logを埋め込むという原始的なやり方をしていたのですが、業務でそれをやるとかなりの時間がかかってしまいます。それをブラウザ上の検証ツールでブレークポイントを置くことで、関数の中身を知ることができたり、どのタイミングで関数が呼ばれるのか詳細に分かるので、結果生産性爆上がりしたという実体験があります。
当たり前だけど、意外とおざなりにされがちな技術と一年目から向き合えたのはとてもラッキーだったかもしれません。
どんな新しい習慣ができたか
エンジニア1年目は、これからエンジニア人生を歩んでいく上で、重要な時期であると認識してます。僕は学生時代バドミントンを中・高と6年間、社会人になってからはゴルフを5年くらいやってますが、やり始めにどれだけ土台を作れるかが重要であることを身をもって体感しました。ゴルフで言うと、スイングの基礎をどれだけ積み上げられるかがスコアに大きく影響します。
つまり、エンジニアも同様で、最初の1年~3年の間にどれだけ土台作りをできるかでその後の成長にも大きく影響してくると思います。そのような考え方から、エンジニアにおける土台とはなんだろうと考えた時「習慣」の事かなと一つの解を出しました。
以下はその解から、エンジニアになって始めた習慣になります。
- ドキュメント作成習慣
- エラーをまとめる
- 技術的に理解が不足してるところをまとめる
- 仮説を立てる習慣
- 細かく調べる習慣
- 業務タスク/プロダクトに関して
- 技術書に関して
- 読書習慣
- AtCoder習慣
ドキュメント作成習慣
僕は、とにかく言語化を心がけてドキュメントを作成しています。頭の中だけで、整理するのが苦手なのと相手に伝えるときに可視化してる方が伝えやすかったりするので、習慣化するようにしました。また仮説を立てる際もドキュメント化してると、どのパターンまで試したか、他にどんなパターンがあるかなど思考の整理もしやすいので、おすすめです！
仮説を立てる習慣
これはまだまだ未熟ですが、手当たり次第に物事を進めていくのではなく、論理的に物事を進めていくことで、相手に状況を伝えやすくなったり、自分の中の思考の整理もできたりするので、何をするにしても、ゴール設定とそこに向かうためのプロセスは意識しながら、行動するようにしています。これは、プログラミング思考を養う意味でも重要だと思うので、コードを書かないにしても、その思考を持てるようにしていきたいと考えています。
細かく調べる習慣
常日頃調査タスクや仕様の確認といったタスクが落ちてくるわけですが、とにかく最初の方はわからない事が多い。何なら、今も初見の問題と遭遇するといったことがあるわけです。その時に、まずは情報収集をするわけですが、今自分が必要としてる情報は何なのか、どんな仮説のもとその情報を集めようとしているのかなど言語化した仮説を軸に情報を集める事が必要になります。
その時に、プロダクト機能のこと、コード処理のこと、過去の類似例、挙動の再現性、エラーの有無、適切な仕様であるかなど色々調べる事が出てくるわけです。また、コードリーディングしていても、初めてみるメソッドや言語もあると思います。とにかく、こういった細かいところまでわからない事を調べる癖をつけるというのが、大事だと思います。これらが詳細であれば、問題の原因となる核も見つけやすくなるので、当たり前のことをやる大切さを学びました。
実際、強い人達ほど、こういった基本的なことをきっちりやっている印象です。
また上記で調べたことをメモとしてnotionなどに残しておくと、後々同じような事を調べる時に、役に立ったりします。技術書なんかも、1冊をしっかり調べながらやると、その技術から派生して他の分野と関係してたりするので、技術が体系的に頭の中にインプットされます。
読書習慣
エンジニアになったからには、技術書を読むことは避けられないと思います。でもせっかく読むなら、本そのものを読むことを楽しみながら、読み進めたいなと思い、読書を工夫することで、習慣化しました。元々、そこまで本を読むタイプではなかったですが、習慣化することで、月に4~5冊は読めるようになりました。※技術書以外も読みます。
そして、読書でインプットした後にアウトプットする事で、知識が定着していくので、このサイクルを回すことの重要性を知る事ができました。
AtCoder習慣
これは、プログラミングをする楽しさを忘れないために、やり始めました。業務だと、そこまでプログラミングを書く機会がないので、少しでも機会を増やすことで、自分のモチベの源泉を忘れないようにしてる感じです。また、自分以外の人の処理を見ることで、違った考え方も知る事ができたり、初見のメソッドなどを知れたりするので、長い目で見るとこれからのエンジニア人生に必要なことが詰まっている気がします。
まとめ
エンジニアになってから、色んな習慣を確立してますが、好奇心があればどのタイミングで始めても成長できるもんだなとしみじみ感じてます。エンジニアとしての土台が「習慣」とお話ししましたが、あとはどんな習慣を身につけるかだと思います。僕自身もまだ模索してる段階ではありますが、これから必要な土台を1年目から少しずつ作れたのは今後のエンジニア人生においてとても重要な意味があると考えています。
なりたいエンジニア像に近づくために、何をすればいいのか、どんな成長曲線を描くか、少しずつ探していければなと思います。