現役エンジニアが考える「エンジニア転職の学習ロードマップ」（前編）

導入編では以下のことを書きました。

導入編をまだ読んでいない方はぜひ読んでいただけたら嬉しいです。

あわせて読みたい

現役エンジニアが考える「エンジニア転職の学習ロードマップ」（導入編） 2020年4月からWebエンジニアとして活動をしている本ブログ運営者である僕が考える（異業種からの）エンジニア転職に向けた学習ロードマップを書きます。 1つの記事に書…

長い前置きを終えて、前編から本題に入っていきます。

前編では

現役エンジニアが感じた実務で絶対に必要な知識・スキル

をまとめます。

僕がエンジニアの仕事はおろか、エンジニアに必要な知識やスキルを全然わかっていないままがむしゃらに勉強していた当時、喉から手が出るほど欲しかった内容です。

この記事に書いていることは1人のエンジニアが感じたことです。申し訳ありませんが世界標準ではありませんm(__)m

というわけで早速説明していきます。

現役エンジニアが感じた実務で絶対に必要な知識・スキルまとめ

僕がエンジニアにジョブチェンジしてこれまでに感じた“実務で絶対に必要な知識・スキル”はこちらです。

そこまで差はないですし独断と偏見になりますが、重要度順に並べています。

上記のリストを見て

あれ？僕（私）がこれまで学習したことと結構違うぞ…？

と思われる方もいらっしゃるかもしれません。

ゆーたろー

ご安心ください。僕なんか実務に入ってから痛感しましたので（笑）

これだけでも僕が実務に入ってどれだけヘコんだかがわかるかと思います。

この記事を読んだ方が僕のようにならなくて済むよう、上記リストの細かく解説していきます。

後編の学習ロードマップに行くまで少し長めの寄り道になりますがぜひ最後までご覧ください！

質問力

いきなり一見プログラミングと全然関係ない項目だなと思ったかもしれません。

質問力はエンジニアとしての仕事というより新しいキャリアをスタートする時に必須の能力というかスキルです。

中でもエンジニアという職業では質問力がかなり大事だと感じています。

質問力ってちょっとフワッとしていますが、ざっくり言うと“相手のことを考えた良い質問をする力”です。

異業種からエンジニアに転職していざ仕事を始めると本当にわからないことばかりです。

むしろわかることの方が少ないんじゃないのかと思える程…
（僕は超最小限の勉強で業界に潜り込んだので僕のケースは極端かもしれません）

その時に先輩や上司に質問することになるのですが、質問の仕方によって

が大きく変わります。（あえて「犠牲」という言葉を選びました）

まず始めに注意点ですが、

わからないことがあったらどれだけ時間がかかろうが自分で解決できるまで質問しない

というのはエンジニアとして、というよりビジネスマンとしてアウトです。

どんな仕事にも“納期”と“出すべきアウトプット”があります。

なのである程度のラインでわからないことは質問すべきです。

では質問する際にどのようなことに注意すれば良いのか、というと個人的にはこのような要素があれば良いと思っています。というか理想的です。

初めから全ての項目を満たす質問をすることは極めて難しいです（僕自身も完璧ではないと思います）が、常に上記を意識して“質問された側（答える側）がこの質問をされて答えやすいかどうか”という相手目線を持つことがとても大事です。

ゆーたろー

質問する前に必ず「自分がこの質問を受けた時にスムーズに答えられるだけの情報が十分に入っているか？」と考えてみてください。

相手に渡す情報は多ければ多い程良いと思っている派です。

自分では不要な情報と思っていても、自分よりスキルや経験のある人からすれば必要な情報、なんてこともあります。

少なすぎるのはダメ、多すぎるくらいでちょうど良い

これも意識してみると良いのではないかと思います。

プログラミング初心者目線での質問についてとても良い記事があるので貼っておきます。ぜひ参考にしてみてください。

初学者目線で見たプログラミング学習において最も大切な｢質問する｣ことについて

Web知識

ゆーたろー

はい、僕が実務に入ってヘコんだ1番の理由がこれです＿|￣|○

（1番目に質問力を挙げていますが僕は質問についてはマシな方でした）

Webアプリ開発の仕事をする上ではWebの知識をおろそかにすると、爆死確定です。

突然ですが、以下の用語が理解できてい場合は実務に入るまで調べて理解しておくことをオススメします。
（できれば人に説明できればGood）

これを全部理解していたら実務で全く困らないかと言われたらそんなことはありませんが、まずは上記の用語の意味だけでも知っておくと良いです。

実務に入るとこれらの用語はわかっているのが当たり前！な感じで仕事の話は進んでいきます（泣）

ゆーたろー

僕は実務に入ったばかりの時、上司・先輩が何を言っているのか全然わからずかなりヘコみました…
（今だから笑えますが、当時は本当に辛かったです…）

いきなり

「公開鍵と秘密鍵を作って私に送って」

と言われても混乱しないようにしましょうね（笑）
（僕は混乱しまくってめっちゃググって、めっちゃ先輩に聞きました…）

と、ここまででWebの知識がどれだけ重要か、最低限何を知っていおけば良いかがわかりました。

次はWeb知識の勉強方法についてです。

紹介する2冊の内1冊の書籍を1周してあとは都度ググる

これで良いです。

イラスト図解式 この一冊で全部わかるWeb技術の基本

キタミ式イラストIT塾 基本情報技術者 令和03年

個人的には前者をオススメしますが、基本情報技術者試験を受けるご予定があれば後者で良いです。
（後者のキタミ式の書籍はWeb知識への相関が低い内容も結構あるので見極めが必要です）

番外編として、イラスト図解式 この一冊で全部わかるWeb技術の基本の内容も読めば「ふむふむ、なるほどな」くらいになればこちらの書籍もオススメです。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

ただし、この書籍は結構難しいことが書いているので実務に入って業務に慣れた時に読むのでも良いと思います。
（僕は実務経験6ヶ月くらいで読みましたけど前提知識がある分、とても勉強になりました）

またまた番外編で僕は読んだことがないのですが、こちらの書籍も初心者にオススメという声をよく聞くのでご紹介しておきます。

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

自分の経験と周りからの評判を踏まえると初心者のファーストチョイスは以下のどちらが無難なのかなと思います。

イラスト図解式 この一冊で全部わかるWeb技術の基本

「プロになるためのWeb技術入門」 ――なぜ、あなたはWebシステムを開発できないのか

繰り返しになりますが、Webエンジニアとして仕事をしていく上ではWeb知識は必須なので、最低限は勉強しておきましょう！

チーム開発でのGit操作

これも先ほど説明したWeb知識と同じくらい必須です。

Gitに関してはTwitterでもよく必須ということは見かけるので知っている人は結構いるのかなと思いますが、チーム開発でGitが使えないとなると…終了です。

業務は100%に限りなく近い確率でチーム開発ですからね。

参考までに僕が普段業務で使っているGitコマンドをご紹介します。
（順番に意味はありません）

$ git status
$ git add .
$ git commit -m "コミットメッセージ"
$ git push origin リモートブランチ名
$ git checkout ブランチ名
$ git checkout -b ブランチ名
$ git stash
$ git stash apply
$ git pull origin リモートブランチ名
$ git rebase ブランチ名 // 会社によっては $ git marge ブランチ名 の場合も
$ git branch
$ git log

実務に入る前にこれらのコマンドを自在に扱えたら正直実務で困ることはありません。

またまた僕の経験談ですが、僕は実務に入るまでは一人でポートフォリオを作成していた時に少しだけGitを使っていた程度で

$ git add .
$ git commit -m "コミットメッセージ"
$ git push origin main // 当時は master

しか使ったことがありませんでした。
（ブランチとかマージとか言葉は知っていたのですが、実践までしていませんでした）

案の定ですが見事（？）、チーン…な状態になりました。

チーム開発でのGit操作を言葉でざっくり説明すると以下の流れになります。
（詳細は会社によって違うかもですが、大まかな流れは同じです）

この流れで作業するために先ほど紹介したGitコマンドを使います。

実務に入って初めて上記の流れでGitを使わなければならないという残酷な事実（？）を知った僕と同じ轍を踏まないためにも実務に入る前にGitの学習＆実践をしておくことをオススメします。

学習教材としては以下の動画教材をしておけば間違い無いです。

Git： もう怖くないGit！チーム開発で必要なGitを完全マスター

Gitの学習なら山浦さんのこのUdemy動画一択ですね。めちゃくちゃわかりやすい。

Gitは概念の理解が難しく初心者には意外とハードルが高いのですが、この動画が解決してくれると思います。

概念ではなく、Gitコマンドについては僕も記事を書いています。

あわせて読みたい

【ブックマーク必須】お探しのGitコマンドはここで全て見つかります（一覧） この記事では複数人でのチーム開発に必須のバージョン管理ツールであるGitの主要コマンドをまとめます。 QiitaでLGTM1000を超えました。 Qiitaの記事画面 本記事は上記…

Git操作を身につけるためには以下の順序がオススメです。

③に関しては1人では難しいので、Twitter等のSNSで共同開発を一緒にしてくれる方を見つける or 共同開発を経験できるスクールを受講するのがオススメです。

GitはGitでもチーム開発でのGit操作ができるように最大限、準備しておきましょう。

ゆーたろー

僕みたいにadd、commit、pushだけの状態で実務に入ったらダメですよww

Linuxコマンド

LinuxコマンドだけでなくLinuxの知識も必要ですがまずはコマンドが使えるようになれば正直なんとかなると思っているので敢えて”Linuxコマンド”と書いています。

Webアプリ開発の業務でよく使うのはこの辺です。

// 絶対使えた方が良い
$ pwd
$ ls
$ ls -a
$ cd
$ mkdir
$ touch
$ cat
$ vi
$ rm
$ rm -rf
$ sudo

// 実務に入ってからでも良いと思う
$ ls -ls
$ ls -la
$ ssh
$ chmod
$ grep

これが正しい学習方法なのかはわかりませんが、Linuxコマンドは使っていればどんどん覚えます。

FinderやVSCodeで行っていたディレクトリ移動やファイル作成をちょっとターミナルでやってみる

こんな感じで敢えて（ググリながら）Linuxコマンドを使ってみて慣れていくのがオススメです。

※権限周りはLinuxコマンド必須なのでそこは頑張って調べながらやるしかありません。

勉強方法についてですが、Liunxコマンドだけであればググればたくさん出てくるので参考書を買う必要はないかなと思います。

例えばこんな記事とか。

Qiita

Linux コマンド一覧表 – Qiita 機能に続いてLinuxのコマンドについてまとめようと思います。詳細コマンドmanコマンド(コマンド内容表示)基本の前にmanコマンドを書きます。対象のコマンドの使い方や使用…

あとは無料で学べるものとしてはこちらを活用してみるのも良いかなと思います。

あわせて読みたい

Linux標準教科書 ダウンロード LinuCレベル1対応 | Linux技術者認定試験 リナック | LPI-Japan Linux技術を基礎から習得するために必須のテキスト。学校教育にも独学にも最適な「Linux標準教科書」の無料ダウンロードページです。LinuCレベル1（101試験、102試験）の教…

Linuxの知識もコマンドもある程度は身につけることができそうですね。

僕は見ていませんm(__)m

想像以上にLinuxコマンドは使うので基本的なコマンドはマスターしておきましょう！

フレームワークではなくネイティブ言語の理解

ネイティブ言語＝プログラミング言語です。

JavaScript/TypeScript/Ruby/PHP/Java/Python/Go

この辺です。

ここで言いたいこととしては

フレームワークでサクッとアプリを作ったあとはちゃんと元の言語のこともしっっっかりと理解しておこうね！

ということです。

個人的にはプログラミング学習の順序としてプログラミング言語の基礎を学習して、簡単（手軽）にアプリ開発ができるフレームワークを使ってサクッと作って、“プログラミングで開発する楽しさ”を感じるのはとても良いと思っています。

ゆーたろー

何事も楽しくないと続けられませんからね。

ただ、フレームワークを使える＝Webアプリ開発ができる訳ではないですし、ベースであるネイティブ言語（プログラミング言語）そのものへの理解が乏しいと結構詰まったり困ったりすることもあります。
（1年目の時は結構感じました）

よくありがちなのが、

エラーの原因がプログラミング言語の範疇なのか、フレームワークの範疇なのかがわからない

です。つまりどこから手をつければ良いのかの判断が難しい。

最近だとTwitterでよく

Reactの勉強の前にまずJavaScriptの勉強をせよ！

という発信を見かけますが、同じ意味ですね。

まあ、土台がプログラミング言語なのでそこの知識は必須だよね、という当然っちゃ当然な話です（笑）

どうすればプログラミング言語の知識を深めれば良いのかというとズバリ

フレームワークを使わず何かアプリケーションでも機能（API）でもいいから作ってみる

これだと思います。

僕はジョブチェンジ時の転職活動ではLaravelを使わずにPHPだけで簡単なWebアプリを作りましたが、面接で「なぜフレームワークを使っていないのですか？」と聞かれた時に

ゆーたろー

フレームワークを使えてもその根幹のプログラミング言語の理解ができていないと開発に苦労すると思ったからです。

と一丁前に答えていました。

※当時使ってた教材の説明をそのまま使いました（笑）

まあこれは実務には必要な知識ですが、転職活動で内定を獲得するためにはそこまで重視しなくても良いと思うので転職活動終了〜入社までの期間とかでやってみるのも良いと思います。

クライアントツールの使い方

これ、クライアントツールというちょっとイメージしづらい用語を敢えて使っているのですが、

クライアントツール ＝ GUIツール

です。

僕は実務に入って初めて知ったのですが、GUIツールのことをクライアントツール（もしくは単純にクライアント）と呼びます。
（会社によっては普通にGUIツールと呼ぶかもしれません）

色々なクライアントツールがありますが、中でもデータベース用のクライアントツールが1番使う確率が多いのではないかと思います。

ゆーたろー

僕はある日突然「クライアントで開発環境のDBに接続しておいて！」と言われて、「クライアント…？誰…？」となり混乱しましたw

正しくは

データベース用のクライアントツール（GUIツール）で開発環境に接続できる状態にしておいて！

という意味ですね。

データベース用クライアントツールにはいくつかありますが、有名どころを紹介します。

僕は現在は

という感じです。

ゆーたろー

余談ですが、PostgreSQLは「ポストグレスキューエル」と読みます。「ポストグレ・エスキューエル」ではないみたいですw

現役エンジニアだけでなく、駆け出しエンジニアの方々もポートフォリオ作成（開発）する場合は、データベースを使うことがほとんどだけ思うのでぜひクライアントツールで接続してみてください。

ちなみにですが、クライアントツールの呼び方として「○○クライアント」という場合も結構あります。

例えばこんな感じ。

こういうのも知っておくと、先輩同士の会話にも付いていきやすいと思います！

SQL

SQLに関してはバックエンド（サーバーサイド）エンジニア志望の方向けなのでフロントエンドエンジニア志望の方は飛ばしてください。

Webアプリケーションを開発する上でほぼ100%データベースを使うので、データベースを扱うSQLはほぼ100％使う。つまり絶対勉強しておきべきである！

という考えを以前は持っていたのですが、Ruby on Rails、LaravelなどのフレームワークにはSQLを書かずにデータベースを操作できるORM（Object-Relational Mapping）という機能が準備されているので、ぶっちゃけSQLが書けなくてもたいていの機能を開発することができます。（ORMの詳しい説明は割愛しますのでわからない方はこちらの記事なんかを読んでみてください）

Qiita

オブジェクト関係マッピング – Qiita Ruby on RailsなどでDBを扱いやすくしてくれる、「オブジェクト関係マッピング」の概要をまとめた。オブジェクト関係マッピング（ORM）とはWikipediaより抜粋。オブジェク…

なので、転職活動までにマストで勉強する技術でもないかな、という印象です。

（もちろん勉強するに越したことはありません）

データ分析業務に携わったり、ビジネスサイドからデータの提供を依頼された時や、ORMでは実装できない複雑なクエリを発行したい時などはSQLをゴリゴリ書く必要がありますが、万人に共通した話ではないかと思います。

勉強するタイミング、目安としては「（早いに越したことはないのは大前提として遅くても実務に入るまでにORMの裏側でどのようなSQLが発行されているかの理解をしておく」。こんな感じです。

ORM⇄SQLの対応は理解しておいた方が良いとは個人的には思います。

SQLの学習教材は初心者にはこちらが良いとよく聞くのでご紹介します。（僕は読んだことはないです）

スッキリわかるSQL入門 第2版 ドリル222問付き! (スッキリシリーズ)

SQLを学習する際には以下のSQL関数の意味はざっくりでも良いので理解しておくことをオススメします。
（書く順番などの細かい書き方については都度ググる、で良いかと）

SELECT
FROM
WHERE
JOIN(INNER JOIN/RIGHT JOIN/LEFT JOIN)
ORDER BY
GROUP BY
INSERT
UPDATE
DELETE
ALTER TABLE

SQLの関数には他にもたくさんありますが、まずはこの辺りは理解しておいてあとは実務で必要になったタイミングでググったり先輩に聞いたりして使えるものを増やすので良いと思います。

Docker

最後はDockerですね。

Webアプリの開発をしている多くの企業で開発環境にDockerが導入されています。
（少し調べたらモバイルアプリの開発にも導入されているようです）

ここで注意点ですが、

ゆーたろー

Dockerを使った環境構築ができるようになれ！！

なんて1ミリも思っていません。

実務未経験の方が会社に入ってDockerでの環境構築の業務を担当することはまずないです。

既にDocker環境は準備されていてREADME等のドキュメントに沿ってコマンドをポチポチするだけで環境構築が終了します。

なのでこの記事でお伝えしたいのは、

くらいは理解しておくと良いですよ！程度です。

後編でも書きますが、ポートフォリオにDockerを導入するかどうかは本当にどちらでも良いので、導入しない場合は転職活動までではなく、Dockerを使っている企業に入社するまでに以下のコマンドの理解をしておけば十分です。

$ docker-compose build
$ docker-compose up -d
$ docker-compose down
$ docker-compose restart
$ docker-compose exec
$ docker-compose images
$ docker-compose ps

これくらいのニュアンスなので記事で紹介する順番も最後にしています。

実際に僕は実務経験6ヶ月くらいの時に学習を始めました。

Dockerを体系的に学ぶなら個人的にはこちらの教材一択です。

僕はこれだけしか使っていません。（あとはQiitaで記事を読むくらい）

米国AI開発者がゼロから教えるDocker講座

ゆーたろー

Dockerってあれだよね。クジラのあれだよね。あれだよあれ。（すみません全是わかりません）

こんな状態で受講しましたが、めちゃくちゃ理解できました。

正直「この講座でDockerが理解できなかったらもうお手上げです…」ってくらいわかりやすかったです。

これを集中的に最後まで受講すればDockerの基本は完璧です。

概要を理解するためにはこちらの記事も結構オススメです。（前編・中編・後編があります）

Qiita

【図解】Dockerの全体像を理解する -前編- – Qiita この記事は何かイメージやコンテナなどの基本からdocker-compose、docker-machine, docker swarmなどのDocker周りの様々な概念の全体像を整理して、Dock…

番外編：AWS

AWS（Amazon Web Services）は僕自身業務でほとんど触っていないのですが、僕と同じくらいの経験歴のエンジニアの知人何名かに聞いてみたら「AWSはできたら勉強しておいた方が良い！」という声が多かったです。

会社によっては実務に入ってすぐに使う場合もあるみたいなので、実務に入るまでに勉強するのはめっちゃアリだと思います。

僕は転職活動前まではAWSはノータッチで、実務の中でもほとんど触ることはなかったのですが基本的な内容だけでも理解しておこうと思い、実務に入った後に学習しました。

僕が使った教材をご紹介します。

AWS：ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得

Gitのオススメ教材紹介にも登場した山浦さんの動画教材ですね。

Gitと同様、安定のわかりやすさでした。

こちらの講座を最後まで受講すれば、Laravelで作成したWebアプリケーションをEC2/RDS/S3等の基本的なサービスを使ってインターネットに公開（デプロイ）することができるようになります。

僕はこちらも購入して少し読んだのですが、個人的には易しすぎる印象でした。

図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書

もちろんわかりやすいことはわかりやすいです。駆け出しエンジニアには良いかもです。

最後に

前編では現役エンジニアが感じた実務で絶対に必要な知識・スキルをまとめました。

これが絶対解ではないですが、上記の知識・スキルは身に付けておいて損は絶対ないのでこちらの記事を参考に今のご自身に不足しているものを認識いただければ嬉しいです。

後編ではいよいよ

現役エンジニアが考えるエンジニア転職のための学習ロードマップ

をまとめていきます。

導入編、前編と結構長くなっていますが後編もぜひ読んでいただけたらと思います。

あわせて読みたい

現役エンジニアが考える「エンジニア転職の学習ロードマップ」（後編） 導入編・前編では以下のことを書きました。 この記事を書いた理由この記事を読んでほしい方この”現役エンジニアが考える「エンジニア転職のための最適学習ロードマップ…