3
2

More than 1 year has passed since last update.

未経験からエンジニアになって爆速で技術を習得するナレッジ

Posted at

はじめに

皆さんこんにちは。
今回は、約半年前にアップした、【実務未経験者がバックエンドエンジニアとして基礎を固めるためのナレッジ】に次いで、
実務未経験者がバックエンドエンジニアとしていかに早く技術を身につけていくかのナレッジについて少し書いていこうと思います。

早いもので、
現在の会社に入社して半年以上が経過しました。

ようやくではありますが、研修を経て、社内案件に少しずつではありますが参画させていただいているような状況です。

実務未経験で、勉強してきた言語も今と違う。
(もともとRubyを独学で学んでおり、現在はPHPを書いています。

そもそも、WEBサービスをつくることにウェイトを置きすぎていたゆえ、
基礎をほぼほぼ理解しないで独学でサイト作成をしていました。

なので基礎力はほぼ0。

あるのはやる気だけ、そんな感じでスタートしましたね。

詳しくは、過去記事を是非御覧ください。
未経験からエンジニアになりました【実務未経験者がバックエンドエンジニアとして基礎を固めるためのナレッジ】

前置きが長くなりましたが、
今回は研修を通じてプログラミングはもちろん、マインド面だったり色々とわかってきたことがあります。

実際実務未経験から半年ちょっとの研修を通じて、
エンジニアとして一歩前に進んだと自身でも思っております。

未経験からエンジニアとして早く技術を習得していくために、
大事だと思ったこと。

今回はこれらをまとめていきたいと思います。

※前回アップしたものと重複するところもあるかと思います。
その場合はやっぱり大事なんだなということでご理解ください。

早く技術を身につけるうえで大事なこと

扱っている言語(技術)に多く触れる

人があることのプロフェッショナルになるには一万時間時間を要するなんて話聞いたことあるでしょうか。

得手不得手があるので、必ずしもその時間やればどうとかではないとは思いますが、
如何に多くの時間をその分野に注げるかは当然重要だと思います。

1日業務時間が8時間だとして、
その時間だけ学んでいたのでは圧倒的に足らないです。

残業がどうとか言っているのではなく、
日々何気ないときにプログラミングのことを考えているか、
そういったプログラミング脳に持っていけるかが重要だと思います。

僕自身、業務以外に移動するときだったり
割と多くの時間を調べごとに使ったりしています。

研修で扱ったあの技術、他で活用できないかな。
あのバリデーション機能、自身のサイトでも入れてみよう!

など割と常にプログラミングのことを考えています。

嫌になってしまうほど考える必要は当然ないと思いますが、
なるべく多くの時間を注ぐというのはやはり重要なことだと思います。

自分で考える癖をつける

プログラミングスクールに少しだけ通っていたときに、

「エンジニアはとにかくググりゲーだから、如何にうまく調べられるかが重要だ!」

と教わった記憶があります。

なので独学でWEBサイトを作っていたときも、
とにかくググり、それっぽいコードがでてきたら引っ張ってきて確かめて、、、
という感じでやっていました。

この癖が実はかなり厄介なものだったと、
今も痛感しています。

先輩方に聞いてみると、
結局のところ、ググりゲーではあるそうです。

ですが、先輩方のようなエンジニアとして長くコードを書いてきた人と、
僕のような未経験にしっぽが生えたような人とでは、
捉え方が全く違ってきます。

先輩方の場合は、
導入したい技術があったときに、まず頭で構成を考え、そのために必要な技術を考え、その上でググって必要な情報を探します。

これが、正しくググるということなのです。

僕の場合はそこがまず違いました。

キーワードでとりあえずググって、その上で情報がうまいこと拾ってくれば課題クリア。
なければひたすら見つかるまで探す。
これでは考える力が身につかないですし、
そのコードがネットに落ちていなければ一生課題がクリアできません。

ググることは悪ではありません。
むしろ絶対に身に着けなければならない一つの技術です。

ですがそれが一番にこないように。
まずは自分の頭で冷静に考え、必要なものを洗い出してから、ググるようにしましょう。

公式ドキュメントを読もう

前回アップした記事にも同様のことを書きました。

公式ドキュメントを第一に読むというのは

やはりなかなか難易度が高いです。

難しいことが書いてあったり、時にはわかりづらく書いてあったり、
正直読み飛ばしたくなることが今でもあります。

ですが、結局のところ公式と言っているくらいなので
絶対に正しい情報が載っているんですね。

なので公式ドキュメントを読んであげるのが
確実に良いに決まっています。

そりゃ読みやすさで言ったら、
Qiitaの記事だったり、zennだったり他サイトのほうが圧倒的に読みやすいケースがほとんどです。

ですが読みやすい記事と絶対に正しいことが書いてある記事だったら
後者のほうがいいですよね。

他サイトは公式を読んだ上で
読むようにしましょう。

逃げないで頑張って公式を読む癖をつける。
僕も頑張って逃げないようにします。

一つ一つ丁寧に理解するよう心がける(コピペ禁止!!!)

とにかく駆け出しエンジニアのうちは、理解を優先して取り組むようにしましょう。

関数の意味、
返り値、
なぜ動くのか、エラーになるのか…

細かいところも1つ1つ理解するように心がけることが大切です。

次同じコードが出てきたときに、
使いこなすことができるようになるのが理想です。

ただなんとなく使って、動いた。
よくあると思います。

でもそこで考えるのをやめてしまわないように。

なぜ、動いたのか。
理由が説明できてはじめて理解したと言えます。

とにかく意識しましょう。

息抜き方法を見つける

僕らは何年もエンジニアとして働いてきたわけではありません。

なんなら僕は営業からジョブチェンジしてエンジニアになりました。

  • 難しいコードにぶち当たったとき。
  • エラーがわけわからなかったとき。
  • 怒られたとき…笑

メンタル的にしんどくなることだってあります。

秒で切り替えられる人はいいですが、
全員がそういうわけではないですよね。

なので、しんどくなったときの息抜き方法をしっかりと持っておきましょう。
それでリセットできるよう心も整えましょう。

僕の場合は、
筋トレだったり、サウナだったりがその役目をもっています。

ずっと気を張ってるのもしんどいですからね。
少しくらい忘れる時間があっても良いんじゃないですかね。

自分でWEBサイトを作ってみる

結局のところ、どんなに学習してもアウトプットしないことには意味がないと思います。

もちろん研修の中で実際に手を動かしてアウトプットするかと思いますが、
アウトプットの場を増やすという意味でも作ってみるのは効果的です。

僕の場合はRailsで過去に作ったWEBサイトがあるので
それをLaravelで書き直すことをしています。

そうすることで、
少し前に習った技術を思い返すきっかけになったり、
研修時には理解しきれなかった部分を理解につなげたりもできます。

環境構築からぜひ頑張ってやってみましょう!

失敗したなと思ったこと

質問がなかなかできなかった

反省点の1つとして、質問があまりできなかったというのがあります。

有効な質問をすることができれば、
もっとスムーズに進められたかもしれません。

自分の力ですすめるというのは当然大事なマインドだと思いますが、
詰まりすぎてしまっては本末転倒です。

現にそういうこともありました。

なぜ質問があまりできなかったのか。

あくまで自己分析にはなりますが、

  • 場合によってわからないところが多すぎて質問するのが難しかった
    →初心者あるあるの何がわからないのかわからないというのは減ったのですが、うまいこと説明が浮かばなかったり、どこまで理解しているか自分でも曖昧だったりして結局質問ができないなんてことはありました

  • 気軽に質問をすべきか躊躇した
    →どのくらい悩んだら質問すべきかわからなかったというのはあります。

  • 確認会のタイミングでまとめて質問しようとした
    →時期などによってまちまちではありましたが、定期的に確認会を開いてもらってました。そのタイミングでまとめて聞こうと考えていることが多かったです。

上記の理由でうまいこと質問ができませんでした。
今考えてみると、質問はすべきタイミングでしないと機会損失につながるなと。

まとめて質問をしようとしても、時間が過ぎてしまい聞けなかったり、期間が空いていた場合内容を忘れてしまっていたりする可能性だってあります。

やはり聞くタイミングというのは重要だと今あらためて書きながら思いました。

解決策としては、

メンターの方とどのくらい悩んだら質問をするか決める
フォーマットを作りそれに沿って質問をする(僕の場合作ってもらったのに活かせなかった)
質問する癖をつける(結局質問も技術みたいなところがあると思うので、練習あるのみ?)

他人の書いたコードを見る機会がなかった

もう1つは、他人の書いたコードを見る機会がなかったことです。

今後1人で開発をしていくというより、
複数人で開発していくことがほとんどだと思います。

そう考えると、他人の書いたコードというのは
今後たくさん目にすると思いますし、
そのコードを意識しながら書いていくことになると思います。

研修のうちから他人のコードを読む癖をつけ、
理解できるようにすることがどのくらい重要なのか、必要なのかわかりませんが、

やっておくのも1つの手だったかなと素人ながら思った次第です。
必要そうなら是非次の研修で取り入れていただけると嬉しいです!

さいごに

未来はきっと明るいぞ

この記事を読んでいただいている方がどのような状況、立場かはわかりませんが、
駆け出しエンジニアの方などがいればお伝えしたいです。

未来は明るいです。

エンジニアが今後どうとか正直わかりません。

ですが、なんかしらのきっかけをもって、
皆さんはエンジニアになった(もしくはなろうとしている)んだと思います。

研修時わかんないことだらけで挫けそうになったり、
エラーが意味わからんくて心折れそうになったり、
Dockerってなに?美味しいの?ってなったり。

案件に入ったら入ったで、
レベル高くてこれまた挫けそうになったり。
僕らにとって難関とはすべての状況です。
まじで。

でも今やっていることが実を結んだら。
当たり前にコードがかけるようになったら。
なんか今より明るい未来がありそうじゃないですか?

僕の場合、一人で学習していたときに作っていたWEBサイトがありますが、
何年かたったらもっと凄いサイトが作れるようになっているんだろうなと心踊ってます。

なんかマネタイズできるようになってるかもしれないし、
それってエンジニアしかできないことだし。
0から1を作り出すってやっぱ凄いことだし。

そんなことを考えるとワクワクするし、
無理なことではないとも思ってます。
だから未来は明るいんです。

今しんどくても、
やり続けましょう。もがき続けましょう。
きっと未来は明るいです!

おわり。

3
2
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
3
2