【駆け出しエンジニア】初案件で得た気づきと反省

こんにちは！そーたです！

今回は、駆け出しエンジニアである私が初案件での気づきと反省をこちらの記事にまとめようと思います。

こんな悩みをお持ちの方におすすめの記事となっています。

簡単に自己紹介をさせていただきますと、

実務を経験し始めてまだ2ヶ月も立っていないくらいの駆け出しエンジニアです。

フリーランスであるスタートアップの会社様に関わらせていただいています。

簡単な経歴ですが、メーカーで営業（11ヶ月）→web制作フリーランス（約1年半）→駆け出しエンジニアになります。

現状、右も左もわからない駆け出しど真ん中であります。。。

このような私が初めて携わらせていただいた（現在も進行中）案件での気づきを簡単にまとめたいと思います。

5分で読めるので、駆け出しエンジニアの気づきや反省点を少しでも知りたい方は最後まで読んでみてください！

仕様全体の理解

というのも、今回参画した案件はもうすでに出来上がったサービスの保守・改善でして、尚更仕様の理解が必要でした。

今回の例だと、ER図やこれまでの開発の資料などを事前に仕入れ、サービスの全体像を掴むことが必要でした。

先輩のエンジニアの方は、コードを見て仕様がわかることはないと言っていたので、

今回の件で、なおさら情報を自分から取りに行く姿勢が重要だと感じました。

質問内容は見やすくわかりやすく

自分の質問に時間をとって答えていただく先輩のことを考えると、丁寧にわかりやすく質問するのは当たり前ですね。

忙しくテキストでしか返答を貰えない可能性もあるので、わかりやすく書くことは大前提です。

悪い例だと、

のような質問はオワテおります。（僕は一番最初の質問はこのような感じでした。）

また、見やすさもこだわると尚良いかもしれません。

僕の場合は、コミュニケーションツールが基本slackなので、

ハイライト等を使ったりして見やすくすることを最近は心がけています。

駆け出しエンジニアの方は、質問の仕方もわからない方も多いかと思いますので、

下記のqiitaの記事を参考に、質問事項を記載することをオススメします♪

質問は恥ではないし役に立つ - Qiita

一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになっ...

qiita.com

報告・連絡・相談はこまめに

長くても1時間ほど悩んでできなかった場合は、相談または質問するべきです。

そうすることで自分1人で頑張るよりも、時間を無駄にせずに正しい方法を学ぶことができます。

もちろん自己解決能力は大事なのですが、長時間固執してやるより

ある程度やって答えが出ない場合は、潔く相談しましょう。

というかします。（自戒）

PR送る前に鬼確認

駆け出しの間は、自分がいいと思っていても先輩エンジニアからすると抜け漏れが結構あるように思うからです。

実際に僕も、確認漏れで指摘をいただいたことがありました。

例えば、PR送るときはコメントアウトにする箇所や、インデントを揃えるとか、

細かいところまでみる必要があると思います。

自身でこれで確認しきったと思えるくらいまで確認するのがちょうどいいですね。

やるべきことを明確化する

理由は、タスクの内容と自身の認識にズレがないかを確認するためです。

例えば、issue単位の認識や今後の作業の流れの認識など、

粒度に差に関係なく、認識のズレはないか聞いて確かめるべきです。

そうすることで、後に発生する手間を事前に防ぐことができます。

駆け出しだからこそ、認識のズレはしっかり無くした上でタスクをこなしていきたいです。

「なぜこうなるのか？」を考える癖をつける

whyの部分を理解してコードリーディング、コーディングをすることで、

自身の論理的思考のupにつながると思うからです。

なぜこの機能を追加するのか理解する

自分の作業がどの問題解決につながるかを意識することで、

当事者意識を持って仕事ができると思うからです。

まとめ

自身の気づきと反省の羅列でしたが、

自身の足りない部分、自戒を含め書かせていただきました。

これから新たな案件にも携わる予定なので、今回の学びを意識しつつ、

よりエンジニアとして価値提供できるようになっていきたいと思うばかりです。

今回は以上になります。

最後まで読んでいただきありがとうございましたmm