バックエンドエンジニアの勉強は何から始める？無料資料と最初の課題

最初は何を説明できるようにするか

バックエンドエンジニアの学習では、道具の操作と仕事の判断を結び付けることが大切です。業務ルールをAPIとデータモデルに落とし込むという作業を、どの条件を確認し、何を根拠に説明するかに分けて考えます。成果物の例はAPIとサーバー側のプログラムです。

予約APIの正常・重複・競合時の振る舞いを決める課題なら、身近な題材から始められます。正確な専門計算を急ぐより、分かっている条件、仮に置いた条件、まだ確かめられない条件を分けましょう。課題はLavaCareerの独自の教育例です。

要求とデータを対応させる

予約という身近な例で、利用者が何を送信し、サーバーが何を保存し、何を返すかを書きます。画面の操作とサーバーの処理を分け、予約ID、利用者ID、対象枠、状態など必要なデータを整理します。

成功時だけでなく、満席、入力不足、本人以外の閲覧も考えます。認証と利用権限の確認は別の役割なので、ログインしているだけで全予約を読める設計にしないことを課題にします。

練習では、リクエストと応答の例を作るところまで取り組みます。残すものはAPIの簡単な仕様書です。次へ進む目安は「正常と失敗の応答を対応させられる」こと。分からない箇所は、資料のどの説明を調べればよいかを書き足してください。

重複と同時更新を考える

残席1へ同時に2件の申込みが来る場面を紙で追います。画面で席数を確認してから保存するだけでは、同じ残席を複数人が見られるため、データの制約や更新のまとまりを調べます。

SQLの教材で、テーブル、検索、集計、更新を小さな架空データで試します。ここでは本番の認証基盤を作る必要はなく、予約の重複をどのルールで防ぎたいか説明できることを目標にします。

練習では、同時申込みの順序を図にするところまで取り組みます。残すものは予約データモデルと競合の説明です。次へ進む目安は「画面だけのチェックでは不十分な場合を説明できる」こと。分からない箇所は、資料のどの説明を調べればよいかを書き足してください。

仕様からテストを作る

同じ申込みを再送、満席、存在しない枠、本人以外の閲覧などをテストケースへ分けます。期待する応答だけでなく、失敗後にデータがどうなっているべきかを明記します。

ログには障害調査に必要な情報を残しつつ、個人情報や秘密をむやみに含めない方針を考えます。実装できた機能、未実装の権限管理、負荷試験などを分けて成果物を説明します。

練習では、5件のケースに期待結果を書くところまで取り組みます。残すものはAPI試験表です。次へ進む目安は「エラー時に保存データをどう確認するか説明できる」こと。分からない箇所は、資料のどの説明を調べればよいかを書き足してください。

無料の資料は目的を決めて読む

MDN サーバーサイドの概要、PostgreSQL 公式SQLチュートリアルを入口にできます。最初からすべてを読み切ろうとせず、今の課題を説明するために必要な節を探します。教材を開いたら、扱っている対象、使用する用語、計算やソフトウェアの前提を確認してください。

公式資料にも版や想定読者があります。公開日本語教材。サーバー・HTTPの概念。 公開英語教材。currentは将来版が変わるため教材の動作版を記録。 課題のために機材や有料講座を購入する必要はありません。公開の文章を読み、紙や表で条件と結果を整理する方法でも始められます。

つまずいたときに戻る場所

APIが成功を返せば完成と考えやすい。権限、競合、重複、エラー後のデータ、ログを仕様とテストに含める。

例えば「認証・データ更新・例外処理を実装する」が難しければ、作業を小さく区切り、入力として必要な情報を先に並べます。用語が分からないのか、情報が足りないのか、判断する基準が曖昧なのかを分けると、調べ直す範囲が具体的になります。学習を進める速さだけで職種との相性を決める必要はありません。

学習したことを企業研究へつなげる

バックエンドの募集では、業務仕様、API、データベース、認証、運用の範囲を分けます。使う言語とフレームワークだけで判断せず、設計判断や障害対応をどこまで担当するかを確認します。

自社サービスか受託かによっても顧客・利用部門との関係が変わります。開発の進め方、レビュー、テスト、本番反映、当番の有無を、実際の担当例から尋ねます。 学習記録には、課題、試した方法、分かったこと、未確認のことを残します。それを使って「業務仕様とAPI設計は誰が決めますか」と聞くと、入社後の仕事と自分の学習の接点を確かめられます。