バックエンドエンジニアの学習ルート

予約APIの正常・重複・競合時の振る舞いを決めるところから、仕事で使う考え方を学びます。

週に数時間を使う場合、入門1週・練習2週・成果物整理1週が一つの例です。経験や資料の難しさに合わせて調整してください。

段階1

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

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

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

リクエストと応答の例を作る。成果物：APIの簡単な仕様書。

正常と失敗の応答を対応させられる

この課題の状況

段階2

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

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

同時申込みの順序を図にする。成果物：予約データモデルと競合の説明。

画面だけのチェックでは不十分な場合を説明できる

この課題の状況

段階3

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

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

5件のケースに期待結果を書く。成果物：API試験表。

エラー時に保存データをどう確認するか説明できる

この課題の状況

このルートについて

課題と学習順序は編集部の提案です。資格取得や採用を保証するものではありません。資料の提供条件や版はリンク先で確認してください。情報確認：2026年10月29日。