【2026年版】未経験からエンジニアになる学習ロードマップ｜何を・どの順で・どれくらい学ぶか

この記事は、「これからエンジニアを目指す」完全未経験の社会人・学生、あるいは学習を始めたばかりで「次に何をやればいいか分からない」段階にいる人へ向けた、学習ロードマップの詳細ガイドです。読み終えたときに、「何を・どの順番で・どれくらいの期間かけて学ぶか」の全体地図が手元に残ることを目指します。

最初に、この記事の立ち位置をはっきりさせておきます。passed.jp は「学び・上達を通じた成長と、人とのつながり」を扱うサイトです。だからこの記事が丁寧に扱うのは、あくまで「土台をつくり、自走して学び続けられる状態になる」までです。求人の探し方や年収の目安、スクールの保証制度の実態といった「就職・転職の実務」には踏み込みません。この記事が送り届けたいゴールは、職探しの入口ではなく、学びを続けられる自分自身です。

もう一つ、先に置いておきたい但し書きがあります。この記事に出てくる「学習時間の目安」「挫折する人の割合」などの数値は、すべて"目安"です。 学習にかかる時間は人によって大きく振れますし、公開されている統計も調査方法や対象がまちまちで、単一の「正解の数字」は存在しません。本文では、特定の数値を「事実」として断定せず、なるべく定性的に示します。数値を判断材料にする際は出典と as_of（いつ時点の情報か）を確認してほしい、という前提で読み進めてください。創作した数値や、都合よく丸めた統計は使いません。

そして、このロードマップが定義するゴールは「特定の言語を覚えること」ではありません。言語やフレームワークは移り変わります。目指すのは、分からないことを自分で調べ、手を動かし、続けられる状態＝"自走"できるようになることです。

読み進め方は次のとおりです。まず全体像（6ステップ）をつかみ、各ステップの中身を順に見て、途中で折れやすい「挫折ポイント」への備えを確認し、「独学 vs スクール」を適性で判断する材料をそろえ、最後に「続けて伸ばす技術」で締めます。気になる節から拾い読みしても構いませんが、初めての人は上から順に読むと、なぜこの順番なのかが腑に落ちるはずです。

全体像：未経験→エンジニアの6ステップと期間の目安

未経験からエンジニアになるまでの学習は、大きく6つのステップに分けて考えると迷いにくくなります。

基礎・土台 — コンピュータと Web が動く仕組み、ファイル操作、環境構築
言語選択 — 「何を作りたいか」から逆算して最初の1言語を決める
フレームワーク — 選んだ言語の代表的なフレームワークを1つ動かす
Git・開発実務 — バージョン管理、データベース、API、デプロイなど「現場の土台」
ポートフォリオ — 学びを「考えて作れる証拠」に変える
継続 — 続ける仕組みと、人とのつながりで伸ばす

順番には理由があります。土台（ステップ1）を飛ばして、いきなり言語やフレームワークに入ると、「なぜエラーが出るのか」「この設定は何をしているのか」が分からず、途中で手が止まりがちです。急がば回れで、最初に地図を持つほうが、結果的に速く進みやすくなります。

総学習時間の目安について。 よく「未経験からエンジニア転職まで◯◯時間」といった数字が語られますが、出典によって前提（対象言語、目指すレベル、学習効率）がまるで違い、幅も非常に大きいのが実情です。短い準備で最初の一歩を踏み出す人もいれば、じっくり長く時間をかける人もいます。ここで大事なのは特定の数字を鵜呑みにしないことです。 具体的な時間の目安を知りたい場合は、複数の一次情報（各種調査・スクールの公表データなど）を、その as_of（参照時点）とともに確認してください。求人や年収に紐づくデータは、この記事では扱いません。

代わりに、自分ごととして役に立つのは「1日あたりの確保時間から逆算する」考え方です。同じ総量でも、1日に確保できる時間が変われば、到達までの月数は大きく変わります。次の表は、学習量そのものではなく"ペース配分のイメージ"を示すための例です。

1日あたりの学習時間の確保	到達までの体感
平日30分＋休日2時間ほど	生活を崩さず長く続けやすいが、到達まで相応の月数がかかる
平日2時間＋休日たっぷり	標準的なペース。数ヶ月〜の腰を据えた計画になりやすい
ほぼ専念（1日6時間以上）	短期集中で進むが、燃え尽き・生活破綻のリスク管理が必須

この表も「目安」であり、数値を保証するものではありません。強調したいのは、「最短◯ヶ月」という煽りに合わせて自分を追い込む必要はない、ということです。到達スピードより、途中で折れずに続けられる設計のほうが、最終的な成否を分けます。

STEP1 基礎：コンピュータとWebが動く仕組みの土台

最初のステップで身につけたいのは、暗記ではなく「全体地図を持つこと」です。ここが後の全ステップの土台になります。

具体的に触れておきたいのは、次の4つです。

HTML/CSS で「画面が作られる感覚」を持つ。 文字や画像がどう配置され、色やレイアウトがどう決まるのか。実際に自分の手で簡単な1ページを作ってみると、「Web ページは魔法ではなく、指示の積み重ねでできている」ことが体感できます。
Web が動く仕組みの大枠を知る。 ブラウザ（クライアント）が、どこかのサーバに「このページをください」とお願い（HTTP リクエスト）し、サーバが返す。この往復のイメージを持つだけで、後の学習で出てくる用語がつながって見えるようになります。
ファイルとディレクトリ、ターミナルの基本操作。 フォルダの階層、ファイルの場所を指定する感覚、黒い画面（ターミナル）で簡単なコマンドを打つこと。ここに苦手意識を残すと、後々ずっと足を引っ張ります。
開発環境の構築。 エディタ（コードを書くソフト）を入れ、便利な拡張機能を入れる。自分の「作業場」を整える工程です。

よくある落とし穴が、この最初の環境構築でつまずいて先に進めなくなることです。 OS の違い、バージョンの違い、エラーメッセージの意味不明さ——ここで数日溶かし、やる気ごと折れてしまう人は少なくありません。

対策として、環境差をできるだけ減らす選択肢を知っておくと安心です。たとえば、ブラウザ上で完結するクラウド型の開発環境や、環境をまるごと箱に入れて再現するコンテナ技術を使えば、「自分のパソコンだけで起きる謎のエラー」に振り回されにくくなります。どれが唯一の正解ということはなく、まずは「詰まったら別の環境で試す逃げ道がある」と知っておくことが、ここでは何より効きます。

このステップの所要は人によって幅がありますが、「完璧に理解してから次へ」ではなく「地図が持てたら次へ」 の温度感で進めるのがコツです。基礎は、後のステップを進めながら何度も戻ってきて、少しずつ深まっていきます。

STEP2 言語選択：目的から逆算する言語マップ

ここでいちばん陥りやすいのが、「どの言語が最強か」という問いにハマることです。結論から言うと、「最強の言語」は存在しません。 言語は道具であり、道具は「何を作りたいか」で選ぶものです。

用途から逆算する地図として、大きくはこう整理できます（優劣ではなく、向いている領域で並べています）。

Web のフロントエンド（画面まわり） … JavaScript / TypeScript。ブラウザで動くものを作るなら避けて通りにくい領域です。
Web のバックエンド（サーバ側） … Ruby、PHP、Python、Java、Go など。それぞれに得意分野と学習コミュニティの厚みがあり、どれか一つが絶対的に優れているわけではありません。
モバイルアプリ … スマホアプリを作りたいなら、その領域で使われている言語・環境。
データ・AI・機械学習 … Python がよく使われる領域です。

各言語は、「向いている領域」「学習コミュニティやドキュメントの厚さ（つまずいたときに助けが見つかりやすいか）」「求人の傾向」といった軸で公平に眺めるのが健全です。ただし求人数や年収に直結するデータは、この記事では踏み込みません——このあたりは時期で動くため、断定せず一次情報にあたるのが安全です。

初学者が最初に意識したいのは、「浅く広く」より「1本を実務で通用するレベルへ」 という方針です。複数言語を同時に薄く触ると、どれも中途半端になり、達成感も得にくくなります。まず1つに絞り、その言語で「動くものを作れた」という成功体験を積むほうが、結果的に伸びやすくなります。

「1つに絞って、あとで潰しが効かなくなったら？」という不安もあるでしょう。安心してほしいのは、プログラミングの土台（変数、条件分岐、繰り返し、関数、データ構造といった考え方）は言語をまたいで共通 だということです。1本を深く理解しておけば、2言語目・3言語目への移行は、最初の1本ほど大変ではありません。だからこそ、最初の1本を「何となく人気だから」ではなく「自分が作りたいものに近いから」で選ぶ意味があります。特定の言語を「これさえやれば勝ち」と押し付ける情報とは、距離を取ってください。

STEP3 フレームワーク：言語の次に何を積むか

言語の基本文法にひととおり触れたら、次はフレームワークです。

フレームワークとは、ざっくり言えば「よくある機能を作るための"土台つきの枠組み"」です。Web アプリには、ログイン、データの保存・取り出し、ページの表示といった「どのアプリでも必要になる共通の仕組み」があります。これを毎回ゼロから自分で書くのは、車輪の再発明——時間もかかり、ミスも増えます。フレームワークは、その共通部分をあらかじめ整えてくれるので、実務でも標準的に使われています。

代表的なものを、これも公平に並べておきます（どれか1つが「正解」ではありません）。

フロントエンド … React、Vue など
バックエンド … Rails、Laravel、Django、Spring、Express など

ここで大切な方針は2つです。

選んだ言語の主要なフレームワークを、まず1つだけ触る。 バックエンドに Ruby を選んだなら Rails を、PHP なら Laravel を、というように、自分の1言語に対応する代表的なフレームワークを1つ選びます。「どれが一番いいか」を延々と比較して手が止まるより、1つ選んで動かすほうが学びは早いです。
学びすぎない。 フレームワークは奥が深く、機能も膨大です。最初から全機能を理解しようとせず、「小さくても動くものを最後まで作りきる」 ことを優先してください。

ライブラリ・フレームワーク・エコシステムの関係も、ここで整理しておくと混乱しません。ライブラリは「特定の機能を助けてくれる部品」、フレームワークは「アプリ全体の骨組み」、エコシステムは「その周辺に集まった道具や情報の集まり」——というイメージです。この段階で全部を完璧に区別できなくても構いません。1つのフレームワークで小さなアプリを動かすうちに、自然と輪郭が見えてきます。

所要期間は言語・フレームワーク・確保時間で大きく変わるため、ここでも「目安」としてのみ捉えてください。目標は「期間を守ること」ではなく、「1つのフレームワークで、自分の手で動くものを作れた」という状態に到達することです。

STEP4 Git・開発実務：現場で必須の土台スキル

「コードが書ける」ことと「仕事ができる」ことの間には、意外と大きな溝があります。それを埋めるのが、このステップです。そしてここは、独学では後回しにされがちで、就職後にじわじわ効いてくる部分 でもあります。

現場で土台になるスキルを挙げます。

バージョン管理（Git / GitHub） … コードの変更履歴を記録し、いつでも戻せるようにする仕組み。コミット（変更の記録）、ブランチ（作業の枝分かれ）、プルリクエスト（変更をレビューしてもらう流れ）といった基本操作は、チーム開発の共通言語です。
ターミナル運用 … STEP1 で触れた黒い画面での操作を、実務で使うレベルに慣らしていきます。
データベースと SQL の基礎 … アプリが扱うデータをどこに、どう保存し、どう取り出すか。SQL は、そのデータに問い合わせるための言葉です。
API / HTTP の理解 … アプリ同士、あるいはアプリとサーバがどうやって情報をやり取りするか。STEP1 の Web の仕組みを、より具体的に理解し直す工程です。
簡単なデプロイ（公開） … 自分のパソコンの中だけで動くものを、インターネット上に公開して、他人が触れる状態にすること。

ここでおすすめしたいのは、「作る → バージョン管理する → 公開する」という実務っぽい小さな流れを、一度でいいから最後まで通してみる ことです。小さなアプリでかまいません。この一連を自分の手で通した経験があるかどうかは、学習の質を大きく変えます。

チーム開発の作法——たとえば、変更をいきなり本番に入れず、いったんレビューしてもらう文化や、やるべきことを issue（課題）として書き出して管理するやり方——も、この段階で「そういうものがあるんだ」と知っておくだけで十分です。就職してから、その意味が体でわかるようになります。編集部の見立てでは、コードを書く力だけでなく、この"開発実務の土台"を持っている人ほど、現場に入ってからの立ち上がりで差が出やすい部分です。

STEP5 ポートフォリオ：学びを「見える成果」に変える

ポートフォリオは、「これだけ勉強しました」という学習量の証明ではありません。目的は、「自分は、考えて、作れる」ことを示すこと です。

作るものについては、既存の有名アプリをそのまま真似た「クローン」よりも、自分自身の困りごとや、身近な課題を解決する小さなアプリ をおすすめします。「毎日の◯◯が面倒だから、それを楽にするツールを作った」——そういう動機のあるものは、規模が小さくても、あなたの考える力が伝わります。

評価されやすい構成のポイントは、機能の多さや見た目の派手さよりも、「なぜ作ったか・どこを工夫したか・どこで詰まって、どう解決したか」を言葉にできているか です。README（説明書きのファイル）に、次のようなことを書いておくと、作ったものの価値がぐっと伝わります。

どんな課題を解決したくて作ったのか（背景）
どんな工夫をしたのか
作る途中でどこに詰まり、どう乗り越えたのか

公開方法は、コードを GitHub に置き、実際に動く状態でデプロイして、リンクを踏めば触れるようにするのが基本です。

数について言えば、「たくさん作る」より「1本を深く」 です。浅いものを何個も並べるより、1本を、詰まりも含めてきちんと作り込んだほうが、伝わるものは大きくなります。

なお、ポートフォリオを就職・転職の場でどう見せるか・どんな軸で評価されるかという実務的な話は、この記事では扱いません。ここで強調しておきたいのは、あくまで 「作る過程そのものが、いちばんの学びになる」 という点です。ポートフォリオ制作は、これまでの STEP1〜4 で断片的に学んだことを、一つの流れの中で総動員する作業です。作りきる過程で、基礎が"使える知識"として定着していきます。

よくある挫折ポイント7つと乗り越え方

未経験からの学習で人が折れるのは、たいてい似た場所です。あらかじめ「ここでつまずくのは、よくあること」と知っておくだけで、乗り越えやすくなります。つまずくのは、あなただけではありません。 同じところで足を止める人は、決して珍しくありません。

環境構築で進めない。 → 一人で抱え込まず、クラウド型の環境やコンテナといった「環境差を減らす逃げ道」を使う。ここは「気合い」より「道具の選択」で解決する領域です。
エラーメッセージが怖い、読めない。 → エラーは「叱られている」のではなく「どこが問題かを教えてくれるヒント」です。メッセージの文言（特に英語の一文）をそのまま検索し、問題を最小限の形に切り分けて再現してみる。この「調べて、切り分ける」習慣そのものが、エンジニアの中核スキルです。
独学の孤独、質問できる相手がいない。 → 後述するコミュニティや勉強会に一つでも所属する。「聞ける場所がある」だけで、詰まったときの心細さがまるで違います。
進捗が見えず、不安になる。 → 学習ログを1行でも残す。「今日はここまで進んだ」が積み上がって見えると、不安は「手応え」に変わります。
完璧主義で先に進めない。 → 「動けば OK、改善は後で」を合言葉にする。最初から美しいコードを書こうとして固まるより、まず動かして、後から直すほうが、学びも速く進みます。
学習時間が確保できない。 → 「やる気」に頼らず「習慣」に落とす。時間帯を固定する、朝の15分だけと決める、といった"設計"で乗り切る。意志の強さより、仕組みのほうが続きます。
他人と比較して自信を失う。 → 比べる相手は「過去の自分」にする。SNS で見える他人の進捗は、うまくいった瞬間の断面です。自分のペースで、昨日より一歩、で十分です。

なお、「未経験者の◯割が挫折する」といった割合を語る情報は世の中に多くありますが、その手の数値を引用する際は、必ず出典と as_of を確認し、"目安"として扱ってください。 調査対象や定義がまちまちで、数字だけが独り歩きしがちな領域です。ここでは創作した割合は使いません。大事なのは正確なパーセンテージではなく、「折れるのはあなただけではない」という点のほうです。

独学が折れる構造そのものと、それを仕組みで立て直す具体策は、独学プログラミングが続かない時、やる気ではなく『仕組み』で立て直す話にまとめています。

独学 vs スクール：どちらが上でなく「適性で選ぶ」中立判断

「独学とスクール、どちらが正解か」という問いには、中立に答えます。どちらが上ということはありません。自分の適性で選ぶものです。

判断の材料になる軸を、対称に並べます。

費用 … 独学は費用を抑えやすい。スクールは費用がかかる分、環境やサポートを買う。
学習時間の確保しやすさ … 独学は自分のペースで組める反面、自分で律する必要がある。スクールはカリキュラムで学習リズムを外から与えてくれる。
性格・学習スタイル … 一人でも黙々と進められる「自走型」か、伴走してくれる相手がいたほうが続く「伴走型」か。
質問できる環境の有無 … 独学では自分で質問先を探す必要がある。スクールは質問できる相手が用意されていることが多い。
挫折時の立て直し力 … 詰まったときに一人で復帰できるか、誰かに引き上げてもらう仕組みが欲しいか。
欲しいのは「知識」か「サポート」か … 学ぶこと自体が目的なのか、伴走してくれる環境まで含めて欲しいのか。

独学のメリット は、費用が抑えられ、自分のペースで、興味の赴くままに深掘りできること。デメリット は、孤独になりやすく、間違った方向に進んでも気づきにくく、モチベーション管理をすべて自分で背負うことです。

スクールのメリット は、体系立ったカリキュラム、質問できる環境、同じ目標を持つ仲間、学習リズムの外部化。デメリット は、費用がかかること、カリキュラムが自分に合わない場合もあること、そして「通っているだけ」で満足してしまうリスクがあることです。

この記事では、特定の1社を「ここが最高」と推すことはしません。 スクールを検討する場合も、費用・期間・サポート範囲・学べる領域・自走型か伴走型か、といった比較軸で見るのが健全です。具体的なサービス名で比べたいときは、複数を公平に並べて検討してください。

そして、転職保証・返金保証・費用対効果といった「お金と就職に直結する判断」は、この記事の範囲外です。この記事にはアフィリエイトリンクや特定商材への誘導を置きません。学びの中立ガイドとして、判断の材料だけをフラットに提供します。

継続と人とのつながりで伸ばす（passed.jp の核）

ここが、このサイトが最も濃く扱いたい節です。技術そのものより、「続ける仕組み」を持てるかどうかが、伸びる人と途中で消える人を分けます。 そして続ける燃料は、精神論ではなく"設計"でつくれます。

続けるための具体的な仕組みを挙げます。

アウトプットを習慣にする。 学んだことを短くてもいいから書く、発信する。人に説明しようとすると、自分の理解の穴が見つかります。書くことは、いちばん手軽で強力な復習です。
学習ログと振り返り。 「何をやったか」を記録し、定期的に見返す。積み上がりが可視化されると、それ自体が続ける動機になります（挫折ポイント4の裏返しです）。
コミュニティ・勉強会・もくもく会に参加する。 一人だと折れる場面でも、同じ方向を向いた人がそばにいると踏ん張れます。「下手でも人前で続ける」ほうが、「一人で完璧に」より伸びやすい、というのがこのサイトの立場です。
メンターや先輩とつながる。 少し先を歩いている人に質問できる関係は、独学の弱点になりやすい「方向のズレに気づけない」問題を補ってくれます。
教え合いで理解を固める。 自分より後から始めた人に説明すると、自分の理解が驚くほど整理されます。教えることは、最良の学びのひとつです。

モチベーションには波があります。これは意志が弱いからではなく、当たり前のことです。だからこそ、波を「気合い」で乗り切ろうとせず、仕組みで乗り切る ——これが passed.jp の一貫した立場です。（伸び悩んだときに、やる気ではなく仕組みで立て直す具体策は、勉強が伸び悩んだ時に、やる気ではなく『仕組み』で立て直す方法に書きました。）仕組みには、たとえば次のような、経験的に知られた後押しの働きがあります（厳密な学術用語というより、実感として語られるものです）。

締切効果 … 「いつまでに、これを発表する」と決めると、人は動きやすくなる、とよく言われます。勉強会での発表枠は、その最たるものです。
社会的なコミット … 「やる」と人前で宣言すると、引っ込みがつかなくなり、続けやすくなる、という後押し。
フィードバックの輪 … 作る → 見せる → 反応をもらう → 直す、の輪が回り始めると、学習は加速しやすくなります。

成長を通じて人とつながること自体が、続けるための燃料になります。 上達は孤独な作業のように見えて、実は「つながり」の中でこそ加速する——この上達観を、精神論ではなく、こうした具体的な仕組みとして持っておいてください。

まとめ：今日から始める最初の一歩

最後に、全体を1枚に圧縮しておきます。

未経験からエンジニアへの道は、(1) 基礎・土台 → (2) 言語選択 → (3) フレームワーク → (4) Git・開発実務 → (5) ポートフォリオ → (6) 継続 の6ステップ。順番には意味があり、土台を飛ばさないほうが、結果的に速く、折れにくく進めます。

そして、今日できる最小のアクションを置いておきます。大きく始める必要はありません。

エディタ（コードを書くソフト）をパソコンに入れる
HTML で、たった1画面でいいから作ってみる
学習ログを、1行だけ書く
気になるコミュニティや勉強会を、1つ登録する

この4つなら、今日のうちに始められます。

最優先にしてほしいのは「最短で終わらせる設計」ではなく、「続けられる設計」 です。速さを競う相手は他人ではなく、比べる相手は昨日の自分。折れそうになったら、この記事の「挫折ポイント」の節に戻ってきてください。

改めて、但し書きをもう一度置きます。本文中の学習時間・割合などの数値はすべて"目安"です。 具体的な数字を判断材料にするときは、必ず出典と as_of（参照時点）を確認し、一つの数字を鵜呑みにしないでください。

土台ができ、自走できるようになっても、学びに終わりはありません。折れそうになったら、いつでもこの地図に戻ってきてください。そして何より——まずは今日、エディタを開くところから。