本書について | エンジニア入門研修

はじめに

この本は、Bootcamp 1 の全24回の講義スクリプトをもとに、配属直後のエンジニアが手元に置いて使える実務入門書として再構成したものである。講義の逐語録ではない。動画で話されていた内容を、読者が後から読み返し、作業の判断に使えるように、章ごとの問い、用語、考え方、成果物、参考資料へ整理し直している。

読者として想定しているのは、新卒入社後に初めて実務の開発へ入る人、あるいは開発経験はあるがチーム開発、Web、クラウド、AI利用、技術文書を一続きの仕事として学び直したい人である。本書では、コマンドやツールの名前を先に暗記することを目標にしない。誰の何を良くするのかを確認し、手元で動かし、変更を小さく作り、テストし、レビューを受け、運用や文書まで含めて届ける。この一連の流れを、24章で段階的に扱う。

本書の読み方は二つある。最初から通読する場合は、Part 1からPart 6へ順に進むと、仕事の入口から最終発表までの流れが見える。手元の作業で困ったときは、該当する章だけを開いてもよい。各章は独立して読めるようにしているが、第21章から第24章の最終プロジェクトでは、それ以前の章で作った提出物と考え方を再利用する。

本書で重視するのは、正解を一度で当てることではない。観察し、仮説を立て、確認し、説明し、必要なら修正する。実務の開発では、この往復をどれだけ丁寧に行えるかが、コードを書く力と同じくらい重要になる。

本書を貫くケーススタディ

本書では、複数の章を通じて「メンターが担当受講者の支援ステータスを扱う小さなWebアプリケーション機能」を題材にする。支援ステータスとは、受講者が順調なのか、少し気にかける必要があるのか、早めに支援が必要なのかを、メンターが確認しやすくするための状態である。

この題材を使う理由は、実務の要素が小さくまとまっているからである。利用者がいて、業務上の判断があり、データが保存され、APIがあり、画面があり、権限があり、テストと運用が必要になる。つまり、研修用の作り物でありながら、実務の縮図として扱える。

価値を確かめる：メンターが担当受講者の支援状態を把握しやすくする、という小さな業務課題を置く。最初に確認するのは画面名ではなく、誰がどの判断で困っているかである。
AIを補助に使う：AIには論点の洗い出しや文書の下書きを頼める。ただし、業務の目的、機密情報、採用判断、確認結果は人が持つ。
チームへ相談する：分からない点は、期待結果、実際の結果、確認済みのこと、判断してほしいことへ分けて相談する。
手元で動かす：READMEを読み、ローカル環境でアプリを起動し、ログとディレクトリ構成を観察する。
変更を履歴に残す：小さなbranchとcommitを作り、Pull Requestで背景、変更内容、確認方法を伝える。
Web通信を見る：画面操作の裏にあるURL、request、response、Cookieを観察し、問題の位置を切り分ける。
既存コードを読む：再現手順とログからコードの入口を探し、仮説を立て、小さく修正する。
ドメインを整理する：受講者、メンター、担当、支援ステータスという言葉の意味とルールをそろえる。
データへ落とす：状態と関係をテーブル、カラム、制約へ変え、SQLで保存と拒否の挙動を確かめる。
APIを設計する：画面が何を依頼し、バックエンドが何を判断し、どのエラーを返すかを契約として書く。
画面を作る：一覧、入力、保存中、失敗、空状態、キーボード操作、エラー表示を画面状態として設計する。
品質を確認する：受け入れ条件からテスト観点を作り、セキュリティでは認証、認可、入力、secretを確認する。
実行環境を整える：DockerfileとComposeで、アプリとDBの実行前提を他の人にも再現できる形にする。
届けて観察する：CI/CDで確認済みの変更を環境へ届け、ログ、メトリクス、トレース、SLOで動き続ける状態を見る。
AIと文書で知識化する：AIコーディングでは作業範囲と検証を管理し、技術文書で判断を残す。
発表して次へ進む：最終プロジェクトでは、何を作り、なぜ作り、どう確かめ、次に何を学ぶかを証拠とともに説明する。

この流れを頭に置いて読むと、各章の技術用語が孤立しにくくなる。たとえば、ドメインで整理した「状態」は、データベースではカラムや制約になり、APIではrequestやresponseになり、フロントエンドでは画面状態になり、テストでは守りたいふるまいになる。

重要概念のつながり

技術書を読むときは、用語を一つずつ覚えるだけでは足りない。ある言葉が別の言葉とどのようにつながるかを見られると、実務で判断しやすくなる。本書では、次の関係を何度も使う。

ユーザー -> 課題 -> 成果：機能は、ユーザーが抱える課題を減らし、成果を生むために作る。機能名だけでは価値を判断できない。
MVP -> 受け入れ条件 -> 検証：MVPは最初に届ける範囲であり、受け入れ条件と検証方法があって初めて判断可能になる。
AI -> context -> 検証：AIの出力は、渡したcontextに強く依存する。検証方法を先に決めないと、自然な文章を正しい情報と誤認しやすい。
相談 -> 観察 -> 判断：チームへ渡す情報は、観察した事実、そこからの推測、相手に判断してほしいことへ分ける。
ローカル環境 -> ログ -> 再現：手元で動かす目的は、再現できる状態を作り、ログから問題を追えるようにすることである。
Git -> commit -> Pull Request：Gitの履歴は、Pull Requestでチームに渡す説明の土台になる。commitの単位が大きすぎるとレビューが難しくなる。
URL -> request -> response：Web画面は、URLから始まり、requestとresponseの往復で作られる。表示だけを見ても原因は分からない。
ドメイン -> 状態 -> ルール：ドメインを整理すると、何を保存し、何を許可し、何を拒否すべきかが見える。
テーブル -> 制約 -> SQL：データベース設計は、テーブルを作るだけではなく、制約で守り、SQLで確かめる作業である。
API -> 認可 -> エラー：APIは、入力を受け取るだけでなく、誰が操作してよいかを判断し、失敗を意味のあるエラーとして返す。
UI state -> アクセシビリティ -> ユーザー体験：画面状態とアクセシビリティは、利用者が今何が起きているかを理解するための基本品質である。
テスト -> リファクタリング -> 回帰確認：テストは、ふるまいを守りながら内部構造を変えるための支えになる。
secret -> 依存関係 -> セキュリティ：secretや依存関係は、コードの外に見えてもシステムの安全性に直結する。
Dockerfile -> Compose -> 実行環境：Dockerfileはimageの作り方、Composeは複数サービスの関係を記録する。
CI/CD -> rollback -> runbook：届ける仕組みは、失敗時に止める、戻す、説明する手順とセットで設計する。
ログ -> メトリクス -> トレース：観測データは役割が違う。出来事、数値、処理経路を組み合わせて問題を追う。
RAG -> 根拠 -> 評価：生成AIを業務で使うときは、検索した根拠と出力評価を分けて扱う。
README -> ADR -> インシデント報告：文書は一種類ではない。入口、判断、問題対応では、読者と目的が違う。
PRR -> 証拠 -> release decision：本番前判断は感覚ではなく、確認結果、残リスク、戻し方に基づいて行う。

本書で繰り返し使う原則

言葉をそろえる：同じ言葉を別の意味で使うと、設計、実装、レビュー、テストがずれる。用語集は初心者向けの補助ではなく、チーム開発の土台である。
境界を決める：今回作るものと作らないもの、AIに渡すものと渡さないもの、APIで受け取るものとサーバーで決めるものを分ける。境界が曖昧な仕事は膨らみやすい。
証拠を残す：ログ、テスト結果、PR、文書、画面、デモは、あとから判断を確認するための証拠になる。作業の記憶に頼らない。
失敗時を設計する：成功時だけを作ると、実務では使えない。エラー、権限不足、空状態、rollback、アラート、未確認事項まで扱う。
小さく戻れるようにする：小さなcommit、小さな修正、小さなMVP、小さな検証は、速さのためだけでなく、間違ったときに戻るために必要である。
人が最後に判断する：AI、CI、テスト、チェックリストは判断材料を増やす。採用するか、出すか、止めるかは、人が文脈を見て決める。