33
27

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

もし今からエンジニアを目指すならこうする

Last updated at Posted at 2024-10-13

この記事はどういうものか

かつて未経験転職をした現役エンジニアとして、
「もしも今から未経験転職を目指すならこんなふうに学習する」
という内容をまとめてみました。
何をどれだけどうやって学習すべきかの記事です。

誰に向けてのものか

これからエンジニアになろウトしている学生、未経験転職を目指す社会人に向けてです。
趣味でプログラミングを始める人はあまり気にしなくても問題ないです。

はじめに自己紹介

現在24歳。2019年の時に19歳でエンジニアに転職しました。
現在はフルリモートでphpを使用した開発業務に携わっています。

SNSアカウントを作る

Twitterあたりで同じ目標を持つ仲間を見つけます。積極的に交流しなくても、同じように勉強している人がいるだけでモチベーションの維持につながります。
どれだけ勉強したか、何を勉強したか、どんな実装したかなど学習内容を日記感覚でメモするのもありです。

期限を決める

ダラダラとやっていても意味がないです。
最長でも1年以内に転職まで目指します。理想は半年です。

基礎知識を学ぶ

まずはITに関する基礎知識を学びます。
最初に基礎知識を軽くでもいいので頭に入れておくと実際にプログラミング学習したときに何をしているかのイメージが掴みやすくなります。
プログラミング学習を始める際にいきなりprogateやudemyでコーディングを始めようとする人もいますが、その前か並行して知識を取り入れましょう。

勉強する内容としては基本情報技術者試験の内容をおすすめします。
合格レベルまで持っていく必要はなく、網羅する必要もないですが、最低限テクノロジ系の内容に目を通して「見覚えがある」程度は欲しいです。

読み物として「Webを支える技術」あたりも読んでおくといいでしょう。
集中して勉強するものではなく、空いた時間やプログラミングができないときなどに本を読む感覚で勉強していきます。

学習する言語を決める

どうやって学ぶかの前に何を学ぶかを決めます。
プログラミング言語にはフロント言語とサーバー言語があります。
フロント言語はHTML、CSS、JavaScriptで決まりです。
最近ではフロントだけでサーバーが不要なフレームワークTypeScriptや複数のプラットフォームに同じコードで対応できるFlutterなどがありますが、それらの言語は発展系なので初心者は避けるべきです。

サーバー言語の選び方ですが、考えるべきは将来性、学習難易度、求人数、コミュニティ規模、
新規制です。
3択で選んで問題ないと思います。

  • Python
  • php
  • Ruby

Pyton

AI開発でよく使用されている言語です。
web開発でも使用できるため最初に学習する言語として人気ですが、未経験者向けの求人が多くない印象です。3つの中では将来性が一番で、コミュニティ規模が大きいため困った時に頼れる存在が多いと思います。
フレームワークはDjangoかFlaskあたりが王道ですが、選ぶならDjangoです。

将来性:5
学習の簡単さ:3
求人数:3
コミュニティ規模:5

php

web開発に特化した言語です。
3つの中では実は最も新しい言語ですが、処理速度の遅さと脆弱性から最近は人気が無くなりつつありました。昔から使われていた言語なので一番求人数が多い言語の印象です。しかし、php 7.0へのバージョンアップとlaravelの登場により人気言語に返り咲いています。
フレームワークはlaravel、cakePHP、Zendあたりが人気ですが今からならlaravelをおすすめします。

将来性:4
学習の簡単さ:4
求人数:5
コミュニティ規模:4

Ruby

日本人が開発したプログラミング言語です。
Ruby on Railsというフレームワークを使用することがほぼ前提になっている言語ですが、その分3つの中でも特に学習がしやすいです。
Ruby on Railsチュートリアルという学習サイトが存在しており、それに従って学習を進めることで必要なことはほとんど学ぶことができます。
ただ、3つの中ではコミュニティ活動が最も下火になっており、将来性は低いと言えます。
現在でもスタートアップではよく導入されているため求人がないわけではないです。
将来性:3
学習の簡単さ:5
求人数:4
コミュニティ規模:3

3つ以外ではjavaやC#がよく挙げられますが、学習難易度が違うのであまりお勧めはしません。
ただ、progateあたりで色々触れてみて一番面白そうだと思った言語で学習を進めるといいと思います。

とりあえず書きながら学習する

progate、udemy、youtube、ブログ、本などを参考に色々書いていきます。
作りたいものとか関係なくhtml、css、javascript、サーバーでその日学んだことを書いてみることが大事です。フロント、サーバー関係なく満遍なく一通り学習していきます。
webエンジニアは基本的にフロント、サーバーで得意不得意はあれどどちらも使用できなくてはいけないからです。

学習の優先度は
1.サーバー
2.javaScript
3.css
4.html
です。
サーバーとjavaScriptは基礎的な部分だけでも結構勉強することがあります。
htmlとcssは上2つが飽きた時に軽くやるだけで十分です。

githubを使う

この時点でgithubを使います。といってもgithubの機能の内、基本的な部分のみを使用します。リポジトリの作成とブランチの作成、pull、pushあたりが使えれば十分です。
developブランチから勉強する日でブランチを切り学習内容をコミットしていきます。その日最後のコミット後、developに学習内容をマージしていきます。
学習日記のように使用していきます。

Qiita、Zennに学んだことを書いてみる

その日学んだことを誰かに説明するつもりで書いて投稿します。
アウトプットを行わないと評価されることすらできません。

アウトプットを優先する

インプットしたからアウトプットするのではなく、アウトプットするためにインプットする意識を持ちます。アウトプット7インプット3ぐらいのつもりです。

勉強しながらメモアプリを作る

設計とか何も気にせず、学んだことをすぐに実装するためにメモアプリを作ります。
ポートフォリオとしてではなく学習したことを実装して動作確認するために作ります。
学習日記とは違ってちゃんと動くことを目的にして、アプリを作っていきます。
作っていく中で必要なことをインプットしていったり、より発展系を調べて実装してみたりします。

他人のコードを読む

githubで公開しているコードを読みます。できる限り長い間動きがあ理、複数人が参加しているリポジトリが望ましいです。
1人で機能を追加し続けているリポジトリでも問題ないですが、初心者のコードは避けたほうがいいでしょう。
どのような機能をどのようなコードで追加しているかを確認します。

やらなくていい勉強法

写経

全く意味がないとは言いませんが、写そうと思った時点でほとんど意味がないです。
本やサイトで見つけたコードをただ写すのではなく、自分なりに理解して一から書くべきです。結果として同じコードになったのであれば問題ありません。

模写

ほぼ意味がないです。
webサイト全体を丸ごとコピーするのは全く意味がありません。そこまでしてhtml、cssを学んだところで時間の無駄です。
やるとしたらそのサイトで最も特徴的な部分がどうなっているのかを知るときぐらいです。
一度自分なりに書いた後であれば、どのようにコードが違うのかを理解するために確認するぐらいはいいかもしれません。

競技プログラミング

まだ早いです。

生成AIを使う

基礎を培う段階です。AIを使用すると意味がありません。

タイピング練習

いらないです。そんなことをするぐらいなら1行でも多くコードを書いてください。いつの間にか慣れます。

どんなエンジニアになりたいか決める

一通り学んだ後フロント、サーバーのどちら方向のエンジニアになるかを決めます。
見栄えのいいwebサイトを、直接動くもの作りたいならフロントエンジニアを、より複雑でプログラミング的なことをしたいならサーバーエンジニアの方向性で学習を進めていきます。
フロント方向ならjavaScriptを優先的に学習し、UI、UXの知識をつけていくといいと思います。
サーバー方向ならより複雑な処理を書いてみたりインフラ方面の知識をつけるといいでしょう。

デザインセンスが皆無だったのでサーバーエンジニアを目指します。

学習してきた内容で集大成を作る

ここからがメイン、いわゆるポートフォリオを作ります。

そもそも作るべきか

結論は「なくてもいい。あったほうがはるかにいい」です。
ポートフォリオを作る目的はどれだけ技術力があるかよりもどれだけ学習意欲があるか、どれだけITに対する理解があるかを客観的に示すためです。
未経験エンジニアに即戦力レベルの技術力を求めるほうがおかしいです。
未経験であればポテンシャル採用になることがほとんどですが、そのポテンシャルを示すための判断材料の1つとして使えます。
ポートフォリオを作らないのであればそれに代わるポテンシャルを示す何かが必要です。
なければ作ってください。

意識すること

学んできたもの全てを出し切るイメージで作ります。
何を目的に作ったのか、どこに力を入れたのか、これからどう発展させていくかあたりを意識します。
また、無理をしてはいけません。自分の言葉で説明できないものを追加しないようにしましょう。

どんなものを作るのか

「未経験エンジニア ポートフォリオ」あたりで検索すると色々出てきます。
ポートフォリオの作り方や採用側から見た記事ではオリジナルを作れ、みたいなことが書かれていますがいきなりオリジナルのものを作るのはかなりハードルが高いためおすすめしません。

作ってはいけないもの

  • TODOアプリ
  • メモアプリ
  • 既存のアプリの完全コピー
    とはいってもこの辺りはやめておいたほうがいいです。
    メモアプリ、TODOアプリは基礎的な実装だけで完結してしまうので初期学習のチュートリアルに含めているプログラミングスクールも多く、ポートフォリオには向いていません。
    既存アプリの完全コピーも「なぜそれを作ったのか」の理由がないためNGです。

「誰」が「何人」で「いつ」「どうやって」使うかを考える。

「誰」

基本的には自分が使う前提でアプリの方針を考えていきます。大人数に使ってもらうことは考えず、自分にとって必要なニッチな内容を考えます。
自分の趣味に特化したSNSや掲示板アプリがよく作られますが、趣味や困りごとによって結構変わるものなので被りを気にしなくてもいいでしょう。

「何人で」

SNSや掲示板アプリならば複数人で使いますが、中には1人で完結するようなアプリもあります。
1人用のアプリに比べてSNSのようなアプリはそれだけでフォロー機能やいいね機能などが追加できるので極力複数人で使えるアプリがいいです。

「いつ」

家で使うのか、外で使うのか、どんな状況で使うのかを考えます。
景色を共有する際、料理中、映画を見たとき、スポーツ観戦時などアプリの根幹が決まるため存分に悩みます。

「どうやって」

写真を共有して自慢するのか、それとも相談するのかなどを考えます。
大抵の場合どちらも似たような機能ですが、アプリの方向性を決めるため明確にしたほうがいいです。

実際に昔作ったもの

実際にポートフォリをを作った際は小説投稿サイトを作成しました。


  • 自分を含めた二次創作好き
  • 何人
    2人以上。多ければ多いほどいい
  • いつ
    誰かの創作物の二次創作を作りたくなったとき。自分ならこうすると思ったとき
  • どうやって
    他人の投稿した小説の続きを投稿する

小説投稿サイトはいくらでもありますし、当時からXで短編を投稿していた人もいました。
その中で、二次創作はオリジナルを横に広げる形で発展していたので、縦に発展させるサイトを作ってみました。
自分の書いたものを他人はどのように広げていくのか、を重視しました。

最低限必要な機能

  • CRUD
  • ログイン、ログアウト機能
  • フォロー機能
  • いいね機能
  • お気に入り機能
  • 独自機能。最低でも1つ
    上記の場合では他人の投稿に紐づけて投稿できる機能でした。

基本的に上のものがあれば最低限は満たしています。

まずは最低限を完成させる

まずは完成させることを意識します。
機能を充実させたいところですが、完成しない、動かないという最悪を避けるためにまずは最低限機能の実装を優先させます。

要件定義・設計

何を作るのか、どんな機能を実装するのかをなんとなく決めたら他人に説明するためドキュメントを作成します。
どんなシステムか、どんな機能がいるのかあたりを明文化します。
明文化できたらシステム全体のDB構造を考えてER図に起こします。
機能実装にあたり、どのようなAPIが必要なのか、何をフロントから渡してサーバーから返すのかを考えます。

この段階はやればやるだけ後が楽になりますが、初心者にとってあまり気にしなくてもいい部分です。
初心者には求められるものではないため、作ったシステムの内容に関して質問された時に答えるため作るイメージで問題ないです。

実装

一番重要なところです。
実装にあたって意識することは他人が読むコードであるということです。
自分さえわかればいいという独りよがりのコードは絶対にやめましょう。

可読性

上から下まで流し読みができるようなコードを意識します。
理想を言えば考え込まずにどのような処理を行なっているかがわかるコードがいいです。関数、処理ごとにコメントを記載しておくといいでしょう。
書いている時はコメントがなくても理解できているでしょうが、1年後に読み直すと意外とどんな処理かがわからなくなっています。完全初見の人にも質問されないような実装を心がけます。

保守性

1つの関数で全ての処理を行うのではなく、ある程度分割して書きます。
システム何に同じコードが存在しないようにします。同じコードは共通メソッドとして独立させ呼び出しましょう。

命名規則

これも大事です。命名規則を明文化する必要はありませんが、意識して統一しましょう。
関数や変数でキャメルケースやスネークケースが混在しているとかなり評価が下がります。

インデント

絶対に揃えてください。揃えていないと見栄えが悪く、可読性が下がってしまいます。
命名規則と揃って意識しなくても動作する上、初心者が忘れがちですが、この2つが意識されていないコードの時点で読む気がなくなってしまいます。

ネスト

ネストが深いコードも絶対にやめましょう。
ループではどうしてもネストが深くなってしまうこともありますが、可能な限り少なくなるようにしてください。
if文では最大でも3つまでにしてください。それ以上だと読みにくいコードになってしまうため、早期リターンやswitchで可読性を上げることを意識します。

セキュリティ

深く考える必要はありません。基本的に言語の方である程度セキュリティ対策がされています。
意識するとしたらtextやstringをサーバーに送る際のSQKインジェクションでしょう。
うっかりしていると忘れます。

ACID

トランザクション管理を実装していないポートフォリオをかなり見かけました。
結構大事なものなのでしっかりと実装しましょう。

処理速度

サーバーエンジニアを目指すのならば意識しましょう。
DBにindexを貼ったりループ数を少なくしたりします。
処理速度が遅い場合大抵この2つが影響しています。
他にもキャッシュやクイックソートの使用などがあります。余裕があれば使ってみましょう。
昔面接の際にindexを貼った理由を聞かれたことがあります。

インフラ

dockerあたりを導入してもいいかもしれません。
インフラはインフラエンジニアが専門的に担当する場合が多いですが、サーバーエンジニアも触れる機会が多いので触ったことがあるということは大きいです。

UI・UX・豪華なフロント

フロントエンジニアを目指す場合意識します。
基本機能の実装が終わった後はこちらに重点を置いてもいいでしょう。
ただあまり派手にしすぎるとサイトの読み込み速度が遅くなってしまうため注意してください。

コードレビュー

可能な限りコードレビューをしてもらってください。
未経験同士のレビューに加え、ある程度経験を積んだエンジニアに見てもらうとより良いでしょう。

追加機能・リファクタリング

転職活動中には機能の追加とリファクタリングを進めましょう。
完成して終わりではなくその後もしっかりとメンテナンスしていることも重要です。

就職・転職活動

これまでのアウトプットを利用して転職活動をします。
エンジニア転職エージェントを利用するといいでしょう。

最初は給料は気にしない

基本的に未経験転職の場合給料を気にするべきではないです。
最近では未経験転職組が増えたため、ライバルが多くなってきたと思います。
よっぽど理想的な会社でもない限り数年以内に再転職することを前提にするといいでしょう。

避けるべき会社

個人的な見解です。
ブラック企業を避ける目安ですが、全て満たしていてもホワイトだったり、逆に満たしていなくてもブラックだったりします。

面接官がエンジニアではない

エンジニアの採用でエンジニアがいない時点でその会社は技術に重きを置いていないでしょう。
現場のエンジニアと話す機会を面接のどこかで与える会社はエンジニアのことを考えてくれています。

ポートフォリオを見てくれていない

ポートフォリオを見てもらえない企業は、応募者が多いかアウトプットに興味がないかのどちらかです。
応募者が多いのであればマシですが、後者の場合エンジニアを大事にしてくれない可能性があります。

大量採用している

大抵の場合SESです。
SESはとりあえず大量に採用して売り込むだけで売り上げにつながるので大量に採用する傾向にあります。その場合ブラックな現場に送り込まれる可能性が高いです。

今ならこう逆質問する

  • 未経験で入社した先輩がいるか
  • もしいるなら何年目かでどのような業務を行なっているか
  • 現在取り入れようとしている技術はどのようなものか
  • 勉強会、アウトプットを会社としてどのようにしているか
  • 現在のプロジェクトで使用している技術

あたりは聞いてみたいです。
社長のSNSがあれば確認しておくといいでしょう。
内定をいただいた会社では社長の趣味に関して面接で話しました。

最後に

エンジニアはいいところも悪いところもたくさんあります。
もしもう1度エンジニアを目指すかと聞かれればYESと即答します。
昔ほどではありませんが今でも未経験エンジニアへの転職は可能です。
頑張ってください。

33
27
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
33
27

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?