LoginSignup
23

僕が思う「実務経験のないエンジニアが最初の職場で心掛けるべきこと」

Last updated at Posted at 2023-12-05

はじめに

僕がDMM WEBCAMPさんでプログラミング学習を始めたのは2020年12月なので今月でちょうど3年が経ちました。
時の流れが早くてとても驚いてます。DMMさんにはとてもお世話になりました。ということで、現在の受講生さん含め今後未経験からエンジニアとして働こうとしている人に向けて、「実務経験のないエンジニアが最初の職場で心掛けるべきこと」を考えて記事にしてみました。

自走力を履き違えない

特に未経験のエンジニアは自走力が大事なんて言われることもありますが、自走力とは具体的にどういう状態を意味しているかをイメージできますでしょうか?

自走力とは何か。いろんな答えがあると思いますがとにかく、自走力とは何でもかんでも1人でやり抜くことって思い込んでると詰みます

困ったときは、必ず適宜質問をしたり助けを求めましょう。
「質問の仕方」に関するいい記事がたくさんあるので、是非色々調べて目を通しておくといいです。(下手な質問をすると先輩の時間を奪ってしまうことがあるので、ちゃんと質問の仕方を知っておきましょう)

僕は最初の頃自走力を履き違えていて極力自分でなんとかしていくことを心がけてました。しかしあるタスクで曖昧なところを自己解釈して進めてしまったせいで、仕様の認識のずれが判明し、大きな手戻りを発生させ納期に大幅な遅れを生じさせてしまったことがあります。
まずは何かしらのタスクをもらったらどのように進めていくのかをざっと考えてみて、曖昧なところは積極的に質問していきましょう。
また、タスクを振られた時にやるべきことはこちらの記事に書いてある手順や考え方がとても参考になるのでおすすめです。

チームやプロダクトの課題は何かを考えてその解決策を提案してみる

未経験で最初の現場に入るとどうしても「教えてもらう側」といいますか、とにかく受け身になりがちではないでしょうか。
それは仕方ないと思いつつ、まだ何もわからない状態でも是非問題意識を持ちながら、主体的にプロダクトと向き合ってみましょう。
どんな小さいことでも構いません。例えば、「ここめんどいからこーいうライブラリ入れてみませんか」などと提案してみるといいです。

なぜかというと、チーム・プロダクトがより良いものになるのは当然のこととして、問題意識を持って能動的にプロダクトをよくしていこうとするとそれに伴って自分がとても成長できます。
「プロダクトやチームにはこーいった問題がある」

「それを解決するためには何ができるかというのを勉強する」
という流れが生まれます。
提案して、否定されることもあるでしょう。しかし提案というアプトプットのおかげで、自分の考えのどこが未熟だったのかを知ることができます。どんどん恥をかいていきましょう。
(あと、再度転職するときにチーム、プロダクトのここを改善しましたーというネタにできるという副産物もあります)

エラーログをしっかり確認する

エラーが起きたらちゃんとログを確認して、なぜエラーが起きたのかをチェックしましょう。
当たり前だろwwwと思われた方が結構いらっしゃるかもしれませんが、どうやらそんなこともないようで、ちゃんとログを見てただけで先輩に褒められたことがあります。
逆に、エラーログを見ればわかるようなことを先輩に質問すると、「ちゃんとエラーログを読みましょう」と注意されます。
英文がたくさん出てくると圧倒されて読むのが億劫になりますが、頑張って読んでいきましょう。

自分が書くコードに対して根拠を持つこと

これはAIでコードを簡単に生成されるこの時代において、より重要性を増したように思えます。
AIで生成されたコードだったりネット上に落ちてるコードをまるっとコピーし、よくわかんないけど動いてるからプルリクあげよーくらいの感覚でいると後で想定しないエラーが出て面倒なことになります。
また、書いた本人がよくわかってないコードは、他のメンバーも信頼することができません。最悪の場合、「適当なやつだ」といったイメージを与えてしまう可能性もあるので絶対に避けましょう。
自分が書いたコードはちゃんと他のメンバーにも説明できるくらい理解してた方がいいです。
具体的には

  • なぜそのコードは動いているのか
  • なぜそのコードを書くことを選択したのか(他の選択肢ではなく、なぜその書き方をしたのか)
    を理解して、プルリクのDiscriptionにかけるくらいにしときましょう。

「なんかよくわからんけど動いてるからとりあえずリリースしちゃおう」みたいな考え方もあり、ごくたまにそーいった事態に陥るかもしれませんが、たとえそうなったとしてもしっかりテストを書いて期待する動作をするかを担保してあげましょう。

(できるだけ)テストを書く

これもまた当たり前だろと思われるかもしれませんが、どうやらそこまで当たり前の話ではなく、結構テストを書かないという会社もあるようです。
転職先がテストを書かないとプルリクが通らないといった会社であればいいのですが、そうでない場合でも率先的にできるだけテストを書いていくといいと思います。
私の担当したプロジェクトではテストが書かれているのの、必須ではありませんでした。そのような環境でもできるだけテストを書くように心がけていたところ、先輩に「テスト書いてて偉いですね〜」と言われたことがありますw

テストを全く書いてない会社であれば、なぜそのような方針なのか聞いてみるといいですね。何かしらの事情がありテストを書いてないということもあるかと思いますので「できるだけ」という文言を使いました。
テストもコードなのでもちろん実装・管理コストがあります。がむしゃらにたくさんテストコードを書くのではなく、最初は力の入れ方に濃淡をつけて書くといいです。(例えばRailsならまずはmodelのテストはちゃんと書こうみたいな)

スクール等でRuby on Railsを学習してるなら、機能として動かせるだけで満足せず、ちゃんとRSpecの書き方にも慣れておきましょう。

【最後に】「なにがわかってないのか」を明確にしていき、少しずつ解消していく

未経験からの最初の現場では間違いなくわからないことだらけだと思います。ミーティングで先輩たちが何を喋っているのかも理解できないことがあるかもしれません。
勉強でも同じことが言えますが、自分はなにがわかってないのかを明確にしていき、少しずつでいいので解消していきましょう。一気に全部理解していこうとすると無理すぎて萎えます。ステップバイステップで成長していきましょう。
ほとんどの未経験エンジニアが通る道だと思います。
最初は辛くて大変かもしれませんが、少しずつできることが増えていくことを楽しみながら勉強できるといいですね。(僕も頑張ります!)

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
23