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

未経験からエンジニアを目指す人が、何を・どの順で・どれくらい学ぶかを6ステップで整理した学習ロードマップです。基礎の土台をつくり、言語を1つ選び、フレームワークを1つ動かし、Git と開発実務を身につけ、ポートフォリオを作り、続ける仕組みで伸ばす、という順番です。この道筋に加えて、折れやすい7つの挫折ポイントの対策と、独学とスクールを適性で選ぶ6つの軸を、passed.jp が中立の立場でまとめます。

対象は、完全未経験の社会人・学生と、学習を始めたばかりで「次に何をやればいいか分からない」人です。読み終えたとき、「何を・どの順番で・どれくらいの期間かけて学ぶか」の全体地図が手元に残る状態を目指します。

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

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

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

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

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

未経験からエンジニアになる学習は、6つのステップに分けると迷いにくくなります。期間は1日に確保できる時間で大きく変わるため、この記事は特定の総時間を示さず、逆算の考え方を示します。

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

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

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

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

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

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

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

STEP1 で身につけるのは暗記ではなく、コンピュータと Web の「全体地図」です。HTML/CSS、Web の仕組み、ターミナル操作、開発環境の4つに触れれば、後の全ステップの土台ができます。

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

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

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

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

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

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

最初の言語は、「何を作りたいか」から逆算して1つに絞ります。「最強の言語」は存在しません。 言語は道具であり、道具は作りたいもので選びます。

ここでいちばん陥りやすいのは、「どの言語が最強か」という問いにハマることです。そうならないための、用途から逆算する地図は、大きくはこう整理できます（優劣ではなく、向いている領域で並べています）。

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

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

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

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

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

言語の基本文法にひととおり触れたら、次はフレームワークです。選んだ言語の代表的なフレームワークを1つだけ選び、小さくても動くものを最後まで作りきることが、このステップの目標です。

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

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

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

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

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

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

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

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

STEP4 で身につけるのは、バージョン管理・ターミナル運用・データベースと SQL・API/HTTP・デプロイといった現場の土台スキルです。「作る → バージョン管理する → 公開する」の流れを一度でも最後まで通せば、学習の質が大きく変わります。

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

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

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

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

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

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

ポートフォリオは学習量の証明ではなく、「自分は、考えて、作れる」ことを示すものです。自分の困りごとを解決する小さなアプリを1本、背景と工夫と詰まりを書いた README 付きで公開します。

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

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

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

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

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

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

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

未経験者が折れる場所は、環境構築・エラー・孤独・進捗の不安・完璧主義・時間不足・他人との比較の7つに集中します。

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

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

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

独学が折れる構造そのものと、それを仕組みで立て直す具体策は、独学プログラミングが続かない時の立て直し方｜やる気ではなく「仕組み」で続ける6つの方法にまとめています。

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

どちらが上ということはありません。自分の適性で選ぶものです。 費用・学習時間の確保・性格・質問できる環境・挫折時の立て直し力・欲しいのが知識かサポートか、の6つの軸で判断します。

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

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

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

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

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

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

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

伸びる人と途中で消える人を分けるのは、技術そのものより「続ける仕組み」を持てるかどうかです。続ける燃料は精神論ではなく、設計でつくれます。

ここが、このサイトが最も濃く扱いたい節です。続けるための具体的な仕組みを挙げます。

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

モチベーションには波があります。これは意志が弱いからではなく、当たり前のことです。だからこそ、波を「気合い」で乗り切ろうとせず、仕組みで乗り切ります。これが passed.jp の一貫した立場です。伸び悩んだときに、やる気ではなく仕組みで立て直す具体策は、勉強の伸び悩み（停滞期）を仕組みで立て直す方法｜やる気に頼らない3つの手順に書きました。

仕組みには、経験的に知られた後押しの働きがあります（厳密な学術用語というより、実感として語られるものです）。

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

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

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

6ステップの順番を守り、今日できる最小のアクションから始めることが、最初の一歩です。大きく始める必要はありません。

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

今日できる最小のアクションを置いておきます。

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

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

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

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

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

よくある質問（FAQ）

Q. 未経験からエンジニアになるまで、何時間くらい学習が必要ですか？ A. この記事は特定の総時間を示しません。出典によって前提（対象言語、目指すレベル、学習効率）が違い、幅が非常に大きいためです。代わりに「1日あたりの確保時間から逆算する」考え方をすすめます。具体的な数字が欲しい場合は、複数の一次情報を as_of（参照時点）とともに確認してください。

Q. 最初に学ぶプログラミング言語は何を選べばいいですか？ A. 「何を作りたいか」から逆算して1つに絞ります。Web のフロントエンドなら JavaScript / TypeScript、バックエンドなら Ruby、PHP、Python、Java、Go など、データ・AI・機械学習なら Python がよく使われます。「最強の言語」は存在しないので、作りたいものに近い言語を選んでください。

Q. 環境構築でつまずいて先に進めません。どうすればいいですか？ A. ブラウザ上で完結するクラウド型の開発環境や、環境をまるごと再現するコンテナ技術で、環境差を減らします。「詰まったら別の環境で試す逃げ道がある」と知っておくことが、ここでは何より効きます。気合いではなく、道具の選択で解決する領域です。

Q. ポートフォリオは何本作ればいいですか？ A. 「たくさん作る」より「1本を深く」です。自分の困りごとや身近な課題を解決する小さなアプリを1本作り、README に「背景・工夫・詰まりと乗り越え方」を書いて、GitHub とデプロイで公開します。

Q. 独学とスクール、どちらを選ぶべきですか？ A. どちらが上ということはなく、適性で選びます。費用・学習時間の確保しやすさ・性格（自走型か伴走型か）・質問できる環境・挫折時の立て直し力・欲しいのが知識かサポートか、の6つの軸で判断してください。この記事は特定の1社を推さず、アフィリエイトリンクも置きません。