Zenn
👏

【未経験向け】新卒エンジニアが実務を通して学んだ やって良かったこと、ダメだったこと "5選"

2024/09/14に公開
ポエム
Tips
新人プログラマ応援
新卒エンジニア
idea

概要

2021年10月に内定者アルバイトとして入社し、現在(2022/12)で約1年になりました 👏
この1年間の振り返りとして、やって良かったことを3つ、ダメだったこと(反省点)を2つ、合計5つを、それぞれランキング形式でまとめたいと思います 🏃‍♀️💨

対象者

  • エンジニアを目指している方
  • これから実務経験を積む新人エンジニアの方

やって良かったこと

先輩方から「こうした方が良いよ」と言われたことや、自分でやってみて良かったことなどをまとめたいと思います。

1位 学習する習慣をつける

言わずもがな、圧倒的1位ですね。
以下では、自主学習と勉強会に分けて、説明したいと思います。

自主学習

初めての実務で今まで触れたことない技術に触れる機会が多かったのですが、そこで、自主学習がとても役に立ったと感じました。(個人的には、入社したてのモチベMAXな時に習慣付けれたのが良かったなと)
ちなみに私の場合、土日の午前中はコ◯ダ珈琲で勉強してます(モーニングのパンが無料なのが最高ですよね 🍞 )

個人的な習慣付けるためのポイント

  • 今の実務に近い内容をやる
    • 仕事に直接繋がるため、モチベの維持がしやすい
    • 書籍やUdemyが体系的に学べるのでおすすめです
  • 脳死でやる
    • 「うぉ〜!!やったる~!!」ではなく、「当たり前だよね、うん」くらいのテンションでやった方が続くのかなと思ってます(たぶん)

勉強会に参加する

connpassを定期的に見て、自分の興味あるものがあれば参加していました。
勉強会は、知りたい分野を自分よりもできる人から無料で学べる という超絶コスパの良い勉強だと思ってるので、やって良かったなと思っています。

私はよくconnpassでStudyCoさんの勉強会に参加させてもらっています。
実務1~2年目の方向けの比較的入門系の勉強会が多いイメージです。
オンラインで顔出しも無いので、勉強会が初めての方でも参加しやすいかなと思います 👍

2位 質問はなるべく簡潔に

回答者が答えやすいように、以下のフォーマットを意識して質問するようにしています。

  1. [質問] <- メッセージがどういうものかぱっと見でわかるように
  2. 結論（回答者に聞きたいことを1行で）
  3. 現状や前提条件の共有
  4. 聞きたいことの詳細
  5. 自分の意見とそう思う理由（できれば）
  6. 問題のコードや参考にした記事などのリンク

具体的には、

  • 文章は無駄を省いて、短く
  • 結論(聞きたいことや相談したいこと)から書く
  • [質問] や [相談] を冒頭につけて、パッと見でわかるようにする
  • 送るリンクも必要な箇所に絞る(ファイル全体のリンクではなく、わからない行を選択したリンクにする)
    • https://github.com/~~/見せたいファイル#L10-L14のようにすると10行目〜14行目という風に複数行の選択ができます。
  • コードやログは画像ではなく、文字で送る(コピペできるので、調査しやすい)
  • わからない箇所がわからない時は、エラーまでの経緯をなるべく丁寧に説明（読んだ記事などのリンクなど）
  • 可能であれば、自分の意見を添える(私はこう思いますがどうでしょう？的なやつ)
    • 「どっちが良いか考えて」っと回答者に丸投げするより「こう思うのでこれで良い？」と自分なりに考えた解決策とか提案の方が受け入れやすかったりする
# ex) 質問例
1. [相談]
2. ~~~~~機能の実装について以下の2つ方法を考えていますが、どちらが良いか伺いたいですmm
3. 要件では、~~~~~との事でした。
4. 方法 A の説明 と 方法 B の説明
5. この場合、Aだと~~~~~~が懸念が。Bだと~~~~~の懸念があると思います。
個人的には、~~~~~のため、Aの方が良いと考えますがいかがでしょうか？
6. 以下、参考にした記事になりますmm
https://~~~~~記事のリンク~~~~~

3. ブラウザのブックマークやslackのピン留めを活用して、無駄な時間を減らす

「あれ？これ、前にも似たことあった気がするけど、どこだっけ？？🤔💭」 の対策になります。
ブラウザのブックマークプロジェクトごとにフォルダを作り、資料や使っているツールのリンクをまとめておくと、便利でした。

参考までに、私のブックマークは以下のような構成をとっています。

プロジェクトまとめ
|
|- プロジェクトA
|　　　|-- prod環境のURL
|　　　|-- stg環境のURL
|　　　|-- Githubのリポジトリ
|　　　|-- Sentry
|　　　|-- ER図
|　　　|-- 議事録
|　　　|-- .....
|
|- プロジェクトB ....

slackのピン留めも同様に、今後も振り返りたいメッセージにピン留めすると振り返りたい時に時短になり便利でした〜✌️

ダメだったこと(反省点)

こちらは、この1年でよく陥りがちだった良くない事象を自戒の意を込めて、以下にまとめした。

1位 理解を曖昧なままにする(機能やドメイン知識、実装の仕方など)

堂々の1位です 😭
私がやった事例でいうと、

  • CFnをなんとなくコピペで書き、無駄なコードや誤ったコードが多く、レビュアーの負担を増やしてしまった
  • ドメイン知識への理解が浅く、誤った認識で実装を進めてしまい、手戻りが発生
  • 実装方法に不安があるのに相談せず、レビューの時に指摘される

初めて手戻りが発生した時は、「俺の今までの時間がぁ〜〜!!」と泣きそうになりました 😭
いづれも、理解が曖昧な状態で取り組んだタスクによる失敗になります。
これは自分も相手も損するので、百害あって一利なしの状態です。

個人的なポイントとしては、

  • 「ちょっと聞きすぎかな〜？」くらい擦り合わせるのがちょうど良い(合意取れてるので後からいちゃもんつけるのは無しですよ?の圧にもなるw)
  • (超当たり前ですが)早めに質問する（時間置くほど、ハードル高くなりますよね ><）

2位 考えすぎ、調べすぎ

何も調べずに質問するのもいかがなものかと思いますが、こちらもなかなかに厄介な問題ですよね。
対策としてよく聞くのはGoogleの人口知能チームの15分ルールが有名かと思います。
簡単にいうと、「15分調べてみて、わからなかったら聞こう」 ってやつですね。

自分もやってみたのですが、
「え？これ、質問する前にちゃんと調べた？」って思われるのが怖かったり、
「先輩の時間をこんな質問で奪ってしまうのはちょっと、、、自分で調べて解決すれば良い」
となって、ずーーーーっと調べて解決しないことがありました 😣

15分ルールを実践できれば、それが良いと思いますが、それが苦手なHSPな自分なりの解決法として、以下を実践してみると意外と良かったので共有です。

「調べてみてわからなかったら、一旦、質問する文章を考えてみる」

先に文章だけ準備する段階で、自分で言語化することで、意外と思考が整理されて、「あれ？ってことは、こうすれば良いんじゃね？」ってなることが結構あります。
実際に質問するときも、送信ボタンをポチッと押すだけなので、心理的なハードルも低くて良いのでおすすめです。

おわりに

社会人1年目で、技術のことも仕事の進め方もわからない中、多くの先輩方にアドバイス頂きました。
自分も完璧ではなく、まだ意識しているくらいで、備忘録も兼ねた記事になりますが、この経験が誰かのためになれば幸いです。

Discussion