最初に決めるのは言語ではなく、どの役割を目指すか

Webエンジニアという職種名だけでは、必要な学習は決まらない

画面の実装を中心に担うフロントエンド、サーバー側の処理やデータを扱うバックエンド、両方に関わる小規模チームでは、求められる技術の比重が違います。求人票を見ずに人気言語から選ぶと、作品は作れても応募先と合わないことがあります。

迷う場合は、共通部分を学びながら二つの方向を試す

HTMLとCSSで画面を作り、JavaScriptで簡単な動きを加えるところまでは、多くのWeb開発で役立ちます。その後、画面づくりを深めたいか、データ保存やAPIの仕組みに興味が向くかを見ます。最初から永久の専門を決める必要はありませんが、ポートフォリオを作る段階では軸を一つに置きます。

どちらへ進む場合でも、HTTP、ブラウザ、Git、データベースの基礎は共通します。方向を仮決めする目的は、共通知識を捨てることではなく、作品の中心を決めることです。フロントエンド志望なら画面と状態管理を深くし、バックエンド志望ならAPIとデータ設計を深くします。

求人の技術名より、任される工程を読む

同じJavaScript求人でも、既存画面の修正、Reactによる新規開発、Node.jsのAPI開発では仕事が異なります。必須技術だけでなく、設計、実装、テスト、レビュー、運用のどこを担当するかを確認します。

HTML・CSSは、意味のある画面を自力で組めるところまで進める

HTMLでは、見た目より文書構造とフォームを理解する

見出し、段落、リスト、リンク、画像、表、フォームを正しい役割で使います。すべてをdivで囲むのではなく、内容の意味が伝わる構造にします。フォームではラベル、入力欄、ボタン、エラー表示を組み、利用者が何を入力するのか分かる状態を作ります。

CSSでは、余白と配置を自分で直せる状態を目指す

ボックスモデル、Flexbox、Grid、画面幅に応じたレイアウトを学びます。デザインを完全に再現するより、開発者ツールで崩れた原因を見つけ、修正できることが大切です。PCとスマートフォンの両方で一つの画面を整えられれば、JavaScriptへ進む土台になります。

静的サイトを何本も作るより、次の動作を入れる画面を一つ用意する

タスク管理、予約、記録、問い合わせなど、後からデータを扱える題材を選びます。HTML・CSSだけの段階でも、一覧、入力フォーム、詳細画面を作っておくと、JavaScriptやバックエンドの役割を接続しやすくなります。

JavaScriptでは、画面操作と通信の二つを理解する

構文は、実際の画面を変えるために使う

変数、配列、オブジェクト、条件分岐、繰り返し、関数を学んだら、入力値を受け取り、一覧へ追加し、条件で表示を変える処理に使います。問題集だけで構文を回すより、画面上で結果が見える小さな機能を作る方が役割を理解しやすくなります。

DOM操作とイベントで、利用者の操作に反応させる

ボタンのクリック、フォーム送信、入力中の検証を扱います。どの要素を取得し、どのタイミングで、何を変更したかを説明できるようにします。ライブラリを入れる前に、素のJavaScriptで一つの画面を動かす経験を持ちます。

非同期処理は、サーバーからデータを受け取る流れで学ぶ

fetchなどを使い、外部APIや自分のバックエンドからデータを取得します。成功時だけでなく、通信中、エラー、データが空の状態も表示します。非同期処理を完全に暗記するより、リクエストを送り、応答を受け、画面へ反映する流れを追えることが先です。

バックエンドは言語選びより、HTTPとデータの流れを学ぶ

言語は、求人と教材を見て一つに絞る

Node.js、PHP、Python、Java、Rubyなど複数の選択肢があります。どれが絶対に有利というより、応募したい求人があり、学習資料があり、一つのアプリを完成できることを優先します。複数言語を同時に始めると、フレームワークの違いに時間を取られます。

ルーティング、入力検証、データ保存を一本につなげる

画面から送られたリクエストを受け、入力を確認し、データベースへ保存し、結果を返します。作成、一覧、更新、削除の基本操作を実装し、失敗時の応答も決めます。SQLは文法だけでなく、アプリのどの操作で何が変わるかを見ながら学びます。

認証は写経で終わらせず、守る対象を理解する

ログイン機能を付ける場合は、パスワードをそのまま保存しない、権限のない利用者へ他人のデータを返さない、秘密情報をリポジトリへ置かない、といった基本を確認します。仕組みを説明できない認証機能を複雑にするより、信頼できる方法を小さく実装します。

Git・テスト・公開は、完成後ではなく制作中に入れる

Gitは、コードを置く場所ではなく変更理由を残す道具として使う

機能追加、修正、設定変更の単位でコミットし、何を変えたか分かるメッセージを付けます。完成後に一度だけアップロードすると、制作過程が見えません。Issueやメモに、問題と判断を短く残します。

テストは、壊れると困る処理から始める

すべてを自動化する必要はありません。ログイン、データ作成、権限、入力検証など主要な処理を選び、正常時と異常時を確認します。手動確認の場合も、何を試し、どの結果になったかを記録します。

公開後のログと秘密情報まで確認して完成とする

デプロイしたら別端末から開き、主要機能を操作します。エラー時にどこを見ればよいか、環境変数が公開されていないか、無料枠や停止条件を確認します。公開URLが動かない状態は、コード以前に確認を止める原因になります。

生成AIを使ってコードを補助しても、公開前の確認責任は自分にあります。依存パッケージのバージョン、ライセンス、秘密情報、生成された処理の意味を確認し、説明できない部分は減らします。制作速度より、変更時に自分で追えることを優先します。

ポートフォリオは機能数より、利用者の流れを完成させる

題材は、説明できる課題から選ぶ

前職や日常で感じた不便を題材にすると、誰が何に困り、なぜその機能が必要かを話しやすくなります。斬新なサービスを考える必要はありません。既存の題材でも、利用者、使う場面、判断した機能が自分の言葉で説明できれば意味があります。

主要経路と失敗時の状態を優先する

利用者が登録し、入力し、保存し、後から確認する流れを最後まで動かします。データがない場合、入力が誤っている場合、権限がない場合も整えます。機能を増やし続けるより、主な経路が壊れないことが先です。

READMEは、作品の説明と自分の判断を分けて書く

概要、対象者、主要機能、使用技術、構成、起動方法、テスト方法、工夫、残課題をまとめます。教材や生成AIを使った部分は隠さず、自分で変更した箇所と理解している範囲を書きます。採用担当がコードをすべて読まなくても、全体像が分かる状態を作ります。

応募開始は完璧さではなく、説明と動作の最低条件で決める

応募前に最低限そろえるものを決める

デモが開く、主要機能が動く、READMEがある、職務経歴書から作品へ辿れる、五分で説明できる。この条件が揃ったら、すべての技術を学び終えていなくても求人を見始めます。応募先によっては作品より研修適性や前職経験を重視する場合もあります。

会社ごとに、見せる部分を変える

フロントエンド求人なら画面設計、状態管理、アクセシビリティを強調し、バックエンド求人ならAPI、データ設計、入力検証、認証を前へ出します。同じ作品でも、求人が求める役割に合わせて説明の順番を変えます。

自社開発、受託開発、SESでは、同じ作品でも見られる点が違います。求人票の担当工程、チーム体制、使用技術を読み、作品のどこがその仕事に近いかを一文で示します。会社形態のイメージだけで応募先を絞らないことも重要です。

選考で詰まった質問を、次の学習計画へ戻す

書類が通らなければ求人水準と作品の一致を見直し、面接で説明できなかった処理は学び直します。反応がないから作品を全部作り直すのではなく、どの情報が不足していたかを切り分けます。応募は学習の終了後ではなく、市場とのずれを見つける工程です。

学習順序の目的は、一つのWebアプリを説明できる状態にすること