第1章研修の地図を持つ

新しい職場で最初に戸惑うのは、知らない言葉が多いことそのものではない。本当に難しいのは、その言葉が仕事のどこで使われ、何とつながり、どの順番で必要になるのかが見えないことである。

Git、HTTP、データベース、CI/CD、SRE、LLM。これらの言葉を一つずつ検索すれば、それぞれの定義は見つかる。しかし定義を集めただけでは、実務で何を見ればよいのかは分からない。地名だけが並んだ地図を渡されても、道順が分からなければ目的地へ進めないのと同じである。

この章で最初に使う言葉だけ、短く置いておく。 Gitは、ファイルの変更履歴を残す道具である。 HTTPは、ブラウザとサーバーが情報をやり取りする約束である。データベースは、アプリケーションがあとから使うデータを保存し、関係や制約を守る場所である。 CI/CDは、変更を自動で確認し、環境へ届ける流れである。 SREは、利用者にとって大事な体験を、指標、手順、改善で守る考え方である。 LLMは、文章やコードなどを入力として受け取り、出力を生成する大規模言語モデルである。

ここでの定義は入口であり、最終的な理解ではない。後の章で、それぞれの言葉を実際の作業、ログ、コード、テスト、文書に結びつけて学ぶ。

この章の目的は、研修全体の地図を持つことである。ここでいう地図とは、技術項目の一覧ではない。一つの仕事が、価値の確認、実装、品質確認、運用、共有へどう流れていくのかを見失わないための見取り図である。

この章でできるようになること

この章を読み終えたら、すべての技術用語を詳しく説明できる必要はない。代わりに、次の四つができればよい。

新しい技術用語が出てきたとき、価値、実装、品質、運用、共有のどこに関係しそうかを仮置きできる。
小さな機能依頼の中に、目的、データ、画面、権限、テスト、レビュー、運用が含まれることを説明できる。
自分が分かっていること、まだ分からないこと、次に確認したいことを現在地メモとして書ける。
本書の各章が、最終プロジェクトのどの準備になるのかを大まかに説明できる。

第1章は、詳しい操作手順を覚える章ではない。知らない言葉を減らすより、知らない言葉に出会ったときの置き場所を持つ章である。

小さな依頼の中に、仕事の全体が入っている

配属後、あなたが次のような依頼を受けたとする。

「メンターが担当受講者の支援ステータスを一覧で見られるようにしたい」

一見すると、これは画面に項目を一つ増やすだけの仕事に見える。しかし実際には、考えるべきことがいくつもある。

まず、誰が何に困っているのかを確認する必要がある。メンターは、担当受講者の状況を早く把握したいのか。支援が必要な人を見逃したくないのか。上長へ報告するために一覧が必要なのか。目的が違えば、画面に出す情報も、並び順も、更新できる人も変わる。

次に、その支援ステータスをどこに保存するのかを考える。状態は、データベースのカラムになるかもしれない。誰が更新したか、いつ更新したかも必要になるかもしれない。担当外のメンターが他人の受講者を更新できてはいけないなら、API側で認可を確認する必要がある。

さらに、画面では成功時だけでなく、読み込み中、保存中、失敗時、空の状態を扱う必要がある。テストでは、正常に更新できることだけでなく、担当外アクセスが拒否されることも確認する。レビューでは、なぜその変更をしたのか、どう確認したのか、何を今回やらないのかを説明する。

この小さな依頼の中に、研修で扱うほとんどの要素が入っている。だから本書では、このような小さな機能を題材にしながら、仕事の流れを一つずつ分解して学ぶ。

仕事は五つの視点で見られる

研修中に知らない言葉が出てきたら、まず次の五つのどこに関係するかを考えるとよい。

価値：誰の何を良くするのかを考える視点。
実装：どのように作り、どこに保存し、どう動かすのかを考える視点。
品質：期待どおり動くか、安全か、使いやすいかを確認する視点。
運用：他の環境で動かし、届け、問題に気づき、戻せるようにする視点。
共有：判断、変更、確認結果を、チームや未来の自分に渡す視点。

この五つは、独立した科目ではない。たとえばPull Requestは共有の道具だが、そこには価値、実装、品質の説明が入る。テストは品質の道具だが、何をテストするかは価値と要件から決まる。ログは運用の道具だが、デバッグやレビューでも証拠として使う。

つまり、技術用語は一つの箱にだけ入るものではない。同じ言葉が複数の視点をつなぐことがある。このつながりを意識できると、知らない言葉に出会っても、まずどこから理解すればよいかを決めやすくなる。

たとえば、支援ステータスのAPIという言葉は、実装だけの話ではない。メンターが支援対象を見つけやすくなるなら価値に関係する。誰が更新できるかを決めるなら品質とセキュリティに関係する。失敗時のログを見るなら運用に関係する。 API契約やPR本文に説明するなら共有に関係する。一つの言葉を一つの視点へ閉じ込めないことが、実務での理解を助ける。

24章は、変更を届ける流れに沿っている

本書の24章は、単に話題を並べたものではない。一つの変更を安全に届け、説明できるようになるための順番で並んでいる。

Part 1では、作る前の判断を扱う。研修全体の地図を持ち、価値を確認し、AIをどう使うかを決め、チームへ情報を渡す。手を動かす前に仕事を小さく、説明可能にする力を扱う。

Part 2では、手元で観察し、変更を扱う基本動作を学ぶ。ローカル環境で動かし、Gitで履歴を残し、Web通信を見て、既存コードを小さく読む。起きていることを見て、再現し、変更へつなげる力を扱う。

Part 3では、Webアプリケーションの中心部を作る。要件をドメインへ整理し、データベースへ落とし、APIとして公開し、画面を作り、テストとセキュリティを確認する。利用者の要求を、動く機能と守るべき品質へ変換する力を扱う。

Part 4では、作ったものを他の環境で動かし続ける。コンテナで実行前提をそろえ、クラウドとCI/CDで届け、ログやメトリクスで観察する。動いたものを終わりにせず、運用可能な状態へ近づける力を扱う。

Part 5では、AIと文書を扱う。 LLMを理解し、AIコーディングの作業範囲を管理し、技術文書で判断を残す。 AIの出力を検証し、チームの知識として再利用できる形にする力を扱う。

Part 6では、学んだことを一つの成果へ統合する。個人開発で作り、既存プロダクトとして改善し、本番前確認を行い、最終発表で判断と証拠を伝える。自分の成果を説明し、次の仕事へ接続する力を扱う。

この順番を知っておくと、後の章で細かい技術が出てきても、いま自分が仕事のどの地点にいるのかを見失いにくい。

言葉は、後の章で意味を増やしていく

第1章で、すべての用語を完全に理解する必要はない。むしろ、最初から完全な理解を目指すと、学習は重くなる。大切なのは、言葉が後でどのように再登場するかを知っておくことである。

価値という言葉は、第2章で機能の目的を考えるときに使う。検証という言葉は、第3章のAI利用、第13章のテスト、第23章のProduction Readiness Reviewで形を変えて出てくる。共有という言葉は、第4章の相談、第6章のPull Request、第20章の技術文書で何度も使う。

状態という言葉は、第9章ではドメインの一部として出てくる。第10章ではデータベースのカラムや制約になり、第11章ではAPIのrequestやresponseに現れ、第12章では画面状態として扱われる。同じ言葉が別の章で少しずつ姿を変える。

この変化を追うことが、技術書を読むときの重要な態度である。定義を一度読んで終わりにするのではなく、実際の作業の中でその言葉が何を指すのかを何度も確認する。

情報は、作業で確かめながら読む

本書では、多くの章で参考資料、README、実行結果、ログ、テスト、レビュー記録を使う。これは、読者に暗記量を増やすためではない。技術情報を、確かめられる形で扱うためである。

公式ドキュメント、リポジトリ内のREADME、実際に実行したコマンドの結果、テスト結果、ブラウザやサーバーのログは、判断の根拠になる。一方で、誰かの記憶、AIの出力、古い記事、未確認の推測は、そのまま確定情報として扱わない。使う場合は、作業仮説として置き、別の根拠で確認する。

特に、クラウドサービス、ライブラリ、セキュリティ標準、AI API、料金、外部サービスの仕様は変わる。本書に書かれた考え方は学習の土台になるが、実務で使う直前には、一次情報や実行結果へ戻る必要がある。第1章では、この姿勢だけ先に持っておく。後の章で、READMEを読む、Networkを見る、curlを実行する、テストを走らせる、公式資料へ戻る、という具体的な確認方法を学ぶ。

現在地メモを作る

学習を進める前に、自分の現在地を短く書いておくとよい。現在地メモは、立派な文章である必要はない。自分が何を知っていて、何をまだ説明できず、次に何を確認したいのかを見えるようにするためのメモである。

たとえば、第1章を読み終えた時点では、次のように書ければ十分である。

価値：機能名ではなく、誰の何が良くなるかを見る必要があることは分かった。具体的な聞き方はまだ弱い。
実装：Webアプリでは画面、API、データベースがつながることは分かった。どこから読めばよいかはこれから学ぶ。
品質：テストやセキュリティは最後ではなく、設計とつながることは分かった。
運用：コンテナ、CI/CD、SREはまだ言葉しか知らない。作ったものを動かし続ける話だと理解した。
共有：相談、PR、技術文書は、作業の証拠を相手に渡すために必要だと分かった。

このようなメモがあると、後の章で理解が増えたときに、自分の変化を確認できる。学習は、分からないことを消していく作業ではない。分からないことの名前を付け、次に確認できる形に変える作業である。

研修の地図で起きやすい誤解

章を独立した授業として覚え、後続の章で同じ題材が再利用されることを見落とす。
分からない語を検索だけで片づけ、実際の作業場面と結びつけない。
不安を隠して進め、メンターに聞くべき問いが曖昧なままになる。
ツール名を覚えたことを、仕事の流れを理解したことと混同する。

現在地メモで確認すること

chapter01-submission.md を作り、現在地、不安な語、最終プロジェクトとの接続を書く。

書くときは、できることだけを並べない。説明できないこと、まだ使ったことがないこと、次章以降で確認したいことも書く。よい現在地メモは、自信のある項目と不安な項目の両方を含んでいる。

現在地のまとめでは、価値、実装、品質、運用、共有の五つに分けて、自分の現在地を書く。各項目には、分かっていること、まだ自信がないこと、次に確認したいことを一つずつ入れる。

学習ロードマップのまとめでは、24章のうち特に不安な章、楽しみな章、最終プロジェクトで使いそうな章を書く。たとえば、クラウドが不安なら第16章と第17章を不安な章として書く。 AI利用が気になるなら第3章、第18章、第19章を重点的に見る章として書く。

この提出物は、提出のためだけに作るものではない。後の章で理解が増えたときに、自分の変化を確認するための基準になる。また、メンターへ相談するときに、何が分かっていて何を手伝ってほしいのかを伝える材料になる。

研修の地図で持ち帰ること

第1章で身につけるべきことは、個別の技術名を覚えることではない。技術が、価値、実装、品質、運用、共有のどこに関係するのかを見分けることである。

この地図があれば、後の章で知らない言葉に出会っても、すぐに立ち止まらずに済む。いま見ている言葉は、何を良くするためのものか。何を作るためのものか。何を確かめるためのものか。誰に何を渡すためのものか。この問いを持って読み進めれば、研修は断片的な知識の集まりではなく、一つの仕事の流れとして見えてくる。

価値から機能を考える章へ

次章では、この地図の最初の地点として、価値から機能を考える。画面名や機能名をすぐに実装へ移すのではなく、誰のどんな成果につながるのかを確認する。

第1章 研修の地図を持つ