1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

エンジニアとして成長しない人の特徴4選

Last updated at Posted at 2024-12-10

はじめに

強気なタイトルしました。すいません。

私事ですがエンジニアとして仕事を始め6年経ちました。
未経験でこの業界に飛び込み、最初は大変でしたが気付けばずっとプログラミングを教える側です。

新卒採用の責任者もやっており、長期インターンシップなどでも学生にプログラミングを教えたりしています。
そういった経験もあり、人に教える機会、初心者が成長していく過程をかなり見てきました。

そんな中で成長する人としない人の違いが自分の中で明確になったので書き記しておきます。

体感ですが今まで会った8割のエンジニアがこの特徴に当てはまっている気がします。

毎日のインプットができていない

みなさんインプットしてますか?
Qiitaを見ている方々はインプットを行っている人だと思います。

エンジニアってインプットが全てだなと思います。
技術の移り変わりが早く、プログラミング言語自体のアップデートもあり、気づけばいつも書いていた書き方が非推奨になっていたりするのは日常茶飯事ですよね。

なんならエンジニアじゃない、企画側の人やPO(プロダクトオーナー)、SM(スクラムマスター)の人達がやたら技術に詳しいということがあるあるです。

  • 日頃インプットを行い、良いアーキテクチャはなんなのか提案、検討する。
  • 日頃インプットしたことを日々のコーディングでアウトプットしてより良い品質のシステムを作る。

この辺ができないエンジニアは意外と多いです。
いわゆるできるエンジニアはみんな技術のキャッチアップが早くすぐに実践で使います。
インプットしていないエンジニアはずっと同じ記述、同じ技術しか使わず、差がついていきます。

自分の開発している言語のバージョンぐらいは最低限おっかけて、毎日何かしらの記事やニュースを見ましょう。

技術者として、いや社会人としてマストだと思います。

WhatよりWhyを意識できない

日々の業務が忙しいとプログラミングに慣れてない人は内部の処理を完全に追うことができない場合もあると思います。

変数名や関数名をみて「あーこれは〇〇を取得しているんだな」みたいに処理を詳しく見ず、勝手に判断しています。

何をしているかというは簡単に情報として手に入りますが「なぜその処理をしているのか?」というのを意識しないと、まっさらなファイルから作ることができなくなります。

開発案件に長くいると

  • あのファイルの真似しよう
  • 先輩から「この処理真似すればいいよ」って言われたからとりあえず真似して作ってみる

みたいなことが多くあると思います。

そして渡された処理をみて何をしているかだけ理解してわかった気になり、なぜその処理をしているかを気にせず書き続けてしまう。

その開発現場ではもしかすると戦力になるかもしれないですが、書き方が全く変わった案件になった場合戦力にならないというのはあるあるです。

常日頃、インプットを行い「why」を意識しましょう。

クリティカル・シンキング(批判的思考)ができない

書かれているコードに対して何も疑問を持たない。

  • このコードこれでいいの?
  • この実装だと動かないよね?
  • なぜこの書き方をしているんだろう?
  • これって何をしているんだろう?
  • これ共通化すればかなりシンプルになるような?
  • このUI/UXおかしくない?
    など

既存のコードや実装、動きに疑問を持ちましょう
疑問を持つためにはインプットがないとできないのでインプットは怠らず
自身のチームのコード、実装、挙動を神とせず疑問を持ち続けましょう。

コードレビューをされていない

ここでいうコードレビューは動いているかを第三者に確認してもらうことではないです。

実装に対して

  • ここは冗長だからこのように書くと無駄がなくなるよ
  • 最近はこういった書き方をするのが主流だよ

みたいなアドバイスをもらえるレビューです。

しかし、悲しいことにレビュアーもそこまでプログラミングを理解している人って少ないです(僕の周りだけかも)
現場レベルの知識しかなく、動けばOKみたいな人も多いのが現実です。

レビュー文化がない場合は身近にいる、「この人プログラミング詳しいよなー」っていう先輩や同僚にみてもらいましょう。

レビュー(指摘)というのは最も早く成長する手段だと思います。

動くものを作るのは最低限で、その上より良い品質のものを作る。

  • 保守性が優れている
  • 可読性が高い
  • シンプルな作りになっている
  • 推奨されている書き方をしている

などいろんな観点があります。
レビューを通していわゆるできる先輩から知識を盗みましょう。

チーム内で議論ができる状態だとすごくいいなって思います。

以前のスクラムチームは開発者どうしで、技術の意見交換が積極的に行われており、エンジニア1年目だった私はものすごく成長したと思います。

言われたことをメモして、業務時間外に復習する
というのが私のルーティンでした。

最後に

プログラミング未経験だと焦る気持ちからか、ついつい近道を探しがちですが、そんなものはないです。

一番もったいないのは開発チーム内で年数だけ重ね、仕様に詳くなり修正箇所を暗記して、本質を理解せず、技術力が無くても仕事になっている状態です。

別の会社や案件に言った場合に痛い目にあいます。
そのようなエンジニアを多く見てきました。

日頃のインプットを行い、常日頃「why」を意識して現場の常識を常識と思わず、不安であればレビューをしてもらい適切なインプットを得る。
ということを繰り返してください。

そうすれば最初は苦労しますが、1年もしたら自信がかなり付くと思います。
Pressure makes diamonds! です!

1
0
0

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
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?