1-1 はじめに

このプロジェクトでは、ECサイトをフルスタックで制作します。 商品一覧の表示からショッピングカート、決済機能まで、一連のEC機能を実装します。

所要時間 — 約1.5時間 難易度 — ★☆☆☆☆

はじめに読んでほしいこと — 答えはこの教材の中だけにはありません

この教材を読み始める前に、強めに伝えておきたい姿勢が1つあります。

このカリキュラムは「作ること」が目的ではありません

最初に このカリキュラムの本当の目的 をはっきりさせます。

このカリキュラムは、ただ EC サイトを作ることが目的ではありません。

完成した EC サイトそのものは「副産物」です。本当に取りに行ってほしいのは、作るまでにどれだけ調べ、どれだけ考え、どれだけ手を動かして粘ったか という「過程の濃度」です。

• 完成形のコードだけなら、教材リポジトリの main ブランチを git clone すれば 30 秒で手に入ります。
• しかし、それを 30 秒でクローンした人と、17 章を順番に詰まりながら 100 時間かけて完走した人では、半年後・1 年後のエンジニアとしての強さが桁違いに変わります。
• 差を作るのは「動く EC サイトを所有しているかどうか」ではなく、作るまでに自分の手と頭を何回動かしたか だからです。

途中で詰まる時間こそが本体です。エラーメッセージをじっと睨んで、公式ドキュメントを開いて、Stack Overflow を 5 件読んで、コードを書き直して、また動かして、また落ちて、ようやく原因が分かる — その 1 サイクルごとに、皆さんのエンジニアとしての筋肉が確実に厚くなります。完成のスピードを競うカリキュラムではなく、過程の濃度を競うカリキュラム だと思ってください。

どんな険しい道をたどったかというプロセスが大事です。

提出物として残るのは皆さんが書いた EC サイトのコードですが、講師が本当に評価するのは「ここをどう詰まり、どう調べ、どう抜け出したか」という皆さんの足跡です。つるつるの平坦な道をすいすい進んだ提出物より、何度も転んで、ドキュメントを 100 ページ読んで、3 日詰まってから抜け出した提出物のほうが、エンジニアとしての成長度は圧倒的に高い と運営は本気で思っています。

提出時の README やデモで「どこで詰まったか」「何を調べたか」「どう解決したか」を書く欄があるのはそのためです。最終形のコード以上に、その『険しかった道のりの記録』こそが、このカリキュラムの最大の成果物 だと思ってください。皆さんが書いたエラー解決の足跡 1 行 1 行が、半年後・1 年後の現場で同じパターンに当たったときに、「あ、これ知ってる」と即座に立ち上がれる筋肉になります。

キラキラ最短ルートで作ることよりも、遠回りをたくさんして着実に知識を作っていくことのほうが大切です。

SNS では「最短で◯日で作った」「AI でサクッと完成」といったキラキラした成果が目につきます。でもこのカリキュラムでは、遠回りこそが目的 です。

• 1 つの単語に 1 時間かけて公式ドキュメントを読み込む遠回り
• ==SQL の JOIN の意味が腹落ちするまで、図を 5 枚描いてみる遠回り==
• ==NullPointerException の原因を、null の伝搬経路を辿って 30 分かけて特定する遠回り==
• 「動いたけどなぜ動くか分からない」を放置せず、もう 1 階層下まで読み解く遠回り

これら 1 つひとつが、皆さんの中に 削れない知識の層 を積み重ねていきます。最短で作ったコードはすぐに忘れますが、3 日詰まって抜け出した経験は 5 年経っても覚えています。「ゆっくり遠回り」が、結果的にいちばん早い学習方法 です。本プロジェクトの 17 章を、急がず・焦らず・できるだけたくさん遠回りして進んでください。それが運営からの本気のお願いです。

分からないことはまずネット検索

分からない単語・エラー・挙動が出てきたら、まず自分でネット検索してください。

本教材は ECサイトを 1本作り切るための 道筋とつまずきポイント を提示しますが、Java / Servlet / JSP / Tomcat / PostgreSQL / Maven にまつわる すべての文法・API・エラーメッセージの意味をこの中に書き切ることはしません。書き切ってしまうと、受講生が「答え合わせの本を読むだけ」になってしまい、現場で役に立つスキルが身につかないからです。

実際の開発現場では、教材は1ミリも存在しません。

• 仕様書の代わりに「ふんわりした要望」と「過去の Slack ログ」しかない
• ライブラリのドキュメントは英語で、しかもバージョン違いの古い情報が混じっている
• エラーメッセージの最後の Caused by を読み解いて、Stack Overflow と GitHub Issues を3往復してようやく解決する

この 「自分で検索して、断片情報を組み合わせて、動く形に持っていく力」 こそ、エンジニアとして毎日使うコア能力です。教材で手取り足取り教えるよりも、現場と同じ環境で困って・調べて・解決する経験を積むほうが、5年後の伸びが圧倒的に違います。

検索のすすめ — こういうときは迷わずググる

英語で検索するほうがヒット数も品質も上がります。Stack Overflow GitHub Issues 公式ドキュメント (jakarta.ee / tomcat.apache.org / postgresql.org) の3つは、本教材より遥かに情報量が多く、最新です。

1 つの単語に 5〜10 記事を読む勢いで

検索したら 最初の 1 記事で満足しないでください。

たとえば HttpSession.setAttribute を初めて見たら、最低でもこのくらい開く。

1. 公式 Jakarta EE Servlet 仕様の HttpSession ページ
2. Tomcat 公式ドキュメントのセッション管理ガイド
3. Stack Overflow の「session attribute null after redirect」系 Q&A
4. Qiita / Zenn の「JavaのHttpSession入門」記事
5. GitHub Issues で setAttribute のバグレポートを覗く
6. Baeldung などの英語チュートリアル
7. 別の Stack Overflow Q&A（セッションタイムアウト関連）
8. Apache Tomcat ML の過去ログ
9. 個人ブログのアンチパターン解説
10. Microsoft / Oracle の公式チュートリアル

最初の 3 記事で「同じことが 3 通りの言い方で書いてある」のを見て、ようやく 1 つの概念が腑に落ちる のが普通です。1 記事で分かるなら、それは元から知っていただけです。

解説

「読みすぎでは？」と感じるかもしれません。実は これがエンジニアの普通 です。トップ層のエンジニアほど「公式」「英語」「複数ソース」を当たり前にやっており、5 分で検索を切り上げる人と、30 分かけて 10 記事読み比べる人とでは、半年後の理解の深さが桁違いになります。今のうちに「読み比べる癖」を身体に染み込ませてください。

この回数の積み重ねが自分を強くします。

検索 1 回・記事 1 本を「面倒くさい作業」ではなく 「自分のスキルが 1 mm 厚くなる瞬間」 として扱ってください。1 単語につき 5 〜 10 記事を読み比べるのを、本プロジェクトの 17 章全体で 延べ数百回 繰り返すことになります。その数百回が、終わったときに 「AI なしでもサーバーサイドが分かるエンジニア」という土台を作ります。教材を読み終わったときに残るのは、本教材の文章ではなく、皆さんが調べて読み比べた 1000 ページ分の記憶 です。そっちが本体です。

Zenn / Qiita / 個人ブログも遠慮なく頼ってください

「公式ドキュメントだけ読んで全部理解しなさい」と言うつもりは まったくありません。

公式ドキュメントは 正確だけど読みにくい のが普通です。仕様書として書かれているので、初学者には「結局どう使えばいいの？」が分からないことが多々あります。そこで Zenn / Qiita / 個人ブログ / Note といった日本語の解説記事が圧倒的に役立ちます。

「Qiita は古い記事もあるから〜」「Zenn は信頼できないから〜」みたいな話を聞いたことがあるかもしれませんが、気にせず読んでください。古い記事も「当時のエンジニアがどう考えていたか」を知る教材になりますし、複数記事を読み比べれば誤情報は自然と除外できます。

解説

読み比べこそが信頼性の源泉です。 1 記事だけ読んで「これが正解」と思い込むのではなく、Zenn / Qiita / 公式の 3 つを並べて「どこが共通していて、どこが違うか」を観察するのが、本物のエンジニアの読み方です。

おすすめの探し方

• Google で日本語と英語の両方で検索 — 例 Java HttpSession 使い方 と Java HttpSession tutorial の両方
• 検索結果の上位 5 件は最低でも開く — 1 記事で済まさない
• 「いいね」「Star」が多い記事を優先 — 多くの人が役に立ったと感じた証拠
• 書かれた日付を確認 — 5 年以上前の記事は「当時の常識」として読む（盲信しない）
• コメント欄も読む — 著者の見落としを読者が補完していることがある

Zenn / Qiita を読むのは「ズル」ではありません。むしろ 積極的に活用してください。日本語で書かれた良質な解説記事は、世界的に見ても日本のエンジニアコミュニティの宝です。それを使わない手はありません。

教材が「あえて答えを書かない」場面

本教材では次のような箇所で 意図的に答えを書きません。詰まったらまずネットで調べてください。

• @WebServlet @WebFilter の細かいオプション仕様
• JSTL <c:forEach> <c:if> の全構文
• PreparedStatement の型ごとの set メソッド一覧
• PostgreSQL の関数（NOW(), COALESCE, EXTRACT 等）の挙動詳細
• Maven のライフサイクルフェーズ（validate compile test package verify install deploy）

「教材に書いてないので進めません」ではなく、「公式ドキュメントを開いて、必要な部分だけ読み取る」 のが本プロジェクトの目的の半分です。

解説

もちろん、20分以上自力で調べて手詰まりになったら遠慮なく LuaGate の質問チャネルで聞いてください。「自力で調べる」と「抱え込む」は別物で、抱え込むのは時間の無駄です。

お約束 — 今回の実践 PJ に限り、AI や GPT を使わないでください

もう1つ、強くお願いしたいことがあります。

今回の実践開発プロジェクトに限り、ChatGPT / Claude / Gemini / GitHub Copilot などの AI コーディングアシスタントは使わないでください。

普段の業務や他の学習で AI を使うのは大いに結構です。便利ですし、現代エンジニアの必須スキルでもあります。ただ この 1 本だけは AI 抜きで作り切ってほしい のが運営からの強いお願いです。

解説

例外 — 本当にどうしようもなく詰まった最後の最後 は AI に頼って構いません。ただし、まず公式ドキュメントを読み、Stack Overflow を検索し、講師に質問して、それでも前に進めない場面に限ります。AI を使った場合は、提出時の README に「どこで AI を使ったか・何を聞いたか」を正直に書いてください（減点しません。むしろ「自力で粘った末に AI を使った」プロセスを評価します）。

「コード生成 AI に貼って答えをもらう」「エラーメッセージを AI に投げて直してもらう」「DAO クラスを丸ごと AI に書かせる」— これらをやると、確かに目の前のコードは動きます。ですが、手を動かして・公式ドキュメントを読んで・自分で組み立てる という、エンジニアとして一番大事な土台が育ちません。

AI が圧倒的に便利な時代だからこそ、AI を使わずに 1 本作り切った経験 に価値があります。AI 抜きで詰まりながら完走した人は、AI を使ったときの伸びも段違いです（土台があるので、AI が出してきたコードの「ここ怪しいな」が見抜ける）。

2022 年 11 月以前、ChatGPT は存在しませんでした

少しだけ歴史の話をさせてください。

==ChatGPT が世に出たのは 2022 年 11 月 30 日です。それ以前のエンジニア — つまり、世界中のシニアエンジニア・テックリード・CTO の大半 — は、ChatGPT も Copilot も使わずに、Google 検索と公式ドキュメントだけでキャリアを積み上げてきました==。

• Linux カーネルを書いた人たちも、Rails を作った人たちも、PostgreSQL のコミッターたちも、AI なしで動くシステムを作り続けてきました。
• 彼らが当たり前にやっていたのは、「英語で Google 検索する」「公式ドキュメントを読み込む」「Stack Overflow を 10 件読み比べる」「ソースコードを直接読む」 という、本教材で何度も言っている地味な習慣そのものです。
• それで彼らは「AI なしでも自走できるエンジニア」になり、いまや AI を使えば 超人的な生産性 を発揮します。土台があるからこそ AI が武器になる、という構図です。

AI が無かった時代の戦い方を一度通っておくこと は、AI 時代に生き残るための一番強い投資です。AI ネイティブ世代として「AI なしでは何もできないエンジニア」になるか、「AI が無かった時代の戦い方も知っているエンジニア」になるか。後者を選んでください。

このプロジェクトの 17 章は、2022 年 11 月以前のエンジニアと同じ環境で 1 本作り切る経験 を提供します。Google 検索とドキュメントと皆さんの頭、それだけで EC サイトを完成させてください。それが終わったとき、皆さんは「AI 時代に流されないエンジニア」の入り口に立っています。

本プロジェクトの提出を見れば、講師は「AI で書いたコード」かどうかが分かります。ハッシュ化処理の選択、エラーハンドリングの粒度、命名のクセ、コミットの粒度 — これらに不自然さが出るからです。提出までは 自分の手で書いてください。

解説

提出後は、復習として「AI に同じコードを書かせて自分のコードと比較する」のは強くおすすめします。AI が出した解と自分が書いた解の差分を読むと、その差が 次に伸びる余地 そのものになります。

完走したらぜひ胸を張って言ってください

このプロジェクトを AI 抜きで完走したら、「AI を一切使わずに、このポートフォリオを作りました」 と胸を張って言ってください。

これは現代の就職市場・転職市場において 強烈な差別化ポイント になります。AI でサクッと作ったポートフォリオが量産される時代だからこそ、「AI に頼らず自分の手で作り切った」という事実そのものが、エンジニアとしての地力の証明 になります。

• 面接官は「AI で書いた実装」を見抜けます。実装の意図を質問されたとき、AI に書かせた人はその場で説明に詰まります。
• 一方、自分で詰まりながら作った人は、なぜそう書いたかをすべて自分の言葉で答えられます。これが「採用したいエンジニア」の決定打になります。
• 「AI を使わずに作った」と言える経験は、5 年・10 年経っても色褪せない キャリアの土台 になります。

ポートフォリオに載せるとき、README に堂々とこう書いてください。

解説

==このプロジェクトは ChatGPT / Claude / Copilot などの AI コーディングアシスタントを一切使わずに、公式ドキュメント・Stack Overflow・自分の試行錯誤だけで作り上げました。==

この 1 行が、AI 時代における 皆さんの強さの宣言 です。胸を張ってアピールしてください。それだけの価値がある経験を、これから 17 章かけて積んでもらいます。

章番号の見方

本教材は 17章構成 です。実装パートは Ch8 〜 Ch17 のフラットな番号で統一されています。

解説

Java のパッケージ名は com.northclout.ecsite で統一しています。クライアント企業（ノースクラフト = northclout）の社内コードベースに納品する想定のパッケージ命名で、教材を通して同じプレフィックスを使います。

目的

• サーバーサイドJavaの基礎を実践で活用する
• データベース設計とCRUD操作を体験する
• セッション管理・認証の仕組みを理解する
• 実務に近い開発フローを経験する

コラム — なぜ今ECサイトを学ぶのか

日本のBtoC-EC市場規模は、2023年時点の経済産業省公表値で約22.7兆円、直近では24兆円超に達したという推計もあり、年率5〜10%で成長を続けています。EC領域はWeb開発の現場で求人が尽きないドメインです。さらに、本プロジェクトで使うJava/JSPは古びた技術と思われがちですが、金融SIerや大手流通系の基幹システムでは現役で動いており、保守・改修案件が今もコンスタントに発注されています。「最新技術ではないけれど、現場で安定して稼ぐスキル」を最初の1本目として身につける意義は大きいです。

使用技術

Java / JSP / Servlet

Java はサーバーサイド開発で広く使われているプログラミング言語です。Servlet は Java でWebリクエストを処理する仕組み、JSP（JavaServer Pages） は HTML の中に Java を埋め込んで動的な画面を生成する技術です。多くの企業システム（特に金融・SIer系）で採用されており、求人数も豊富です。

解説

補足 — サーバーサイド処理 とは「ブラウザがURLにアクセス → サーバー側で Java が動いて HTML を組み立てて返す」という流れのこと。ブラウザは出来上がった HTML を表示するだけで、計算や DB アクセスはサーバー側でやる。

https://www.java.com/ja/

https://jakarta.ee/specifications/pages/

Apache Tomcat

Java製の アプリケーションサーバー（Webサーバー） です。書いた Servlet / JSP を動かすための実行環境で、リクエストを受け取って Java コードを呼び出し、HTML を返してくれます。本プロジェクトでは Tomcat 10 を使います。

解説

補足 — アプリケーションサーバー は、静的ファイルだけを返す Webサーバー（Apache HTTPD / nginx 等）とは別物。「Java を実行できる Webサーバー」と捉えると分かりやすい。

https://tomcat.apache.org/

PostgreSQL

オープンソースの リレーショナルデータベース（RDB） です。商品・注文・ユーザー情報など、構造化されたデータを保存します。本プロジェクトでは Neon（PaaS）上の PostgreSQL を一本で使います。

https://www.postgresql.org/

HTML / CSS

画面の 見た目を作る言語 です。HTML が構造（見出し・リスト・フォーム等）、CSS がデザイン（色・余白・レイアウト）を担当します。JSP の中で HTML を書きながら、CSS で整えていきます。

https://developer.mozilla.org/ja/docs/Web/HTML

GitHub Codespaces

GitHub が提供する クラウド開発環境 です。リポジトリをブラウザから開くと、Java や Tomcat がセットアップ済みの VS Code が立ち上がります。自分のPCにJDKやTomcatをインストールする必要はありません。無料枠は月60時間（個人アカウント、2026年5月時点。最新の枠は GitHub の Billing ページで確認）です。

https://github.com/features/codespaces

Neon

サーバーレスPostgreSQL を提供する PaaS（Platform as a Service）です。アカウント登録するだけで、すぐに使えるPostgreSQLデータベースが手に入ります。自分のPCにPostgreSQLをインストールする必要はありません。無料枠は 0.5GB までです。

https://neon.tech

Neon セットアップの全体像

DB を使い始めるまでの流れだけ先に押さえておきます。アカウント作成から、アプリが db.properties 経由で Neon に接続するところまでが 1 本の線でつながっています。

ポイントは「接続文字列（postgresql://...）は Neon のダッシュボードからコピーしてくる」ことと、「db.properties は Git にコミットしない（.gitignore 済み）」ことの2つです。

解説

補足 — psql コマンドで DB を直接触るとき用に、シェル環境変数 $DATABASE_URL も併用します。これはターミナルのセッション中だけ使う一時変数で、db.properties とは別管理です（詳細は Ch8, Ch9）。

解説

詳細手順（アカウント作成のスクショ、db.properties の置き場所、schema.sql / seed.sql の流し込み方）は Ch9 で扱います。本章では「Neon を使う」という方針が分かれば十分です。

開発環境

このプロジェクトはローカル環境構築なしで進められるように設計されています。

なぜCodespaces + Neon？

• PCのスペックを問わない（ブラウザだけで動く）
• 環境構築でつまずかない（リポジトリを開けば即開発開始）
• 動作確認まで Codespaces 内で完結

解説

ローカルPostgreSQL / ローカルTomcatでの開発も可能ですが、サポート対象外です。Codespaces + Neon を強く推奨します。

進め方

1. 各Chapterの内容を順番に進めてください
2. 分からないことがあれば LuaGate の質問チャネル（Mattermost、運営から案内されます）で質問してください
3. 完璧を目指す必要はありません。まずは動くものを作りましょう

このプロジェクトで身につくこと

このプロジェクトを完走すると、Web開発の流れ・技術スタック・実装スキル・実務感覚の4軸でスキルが積み上がります。下のマインドマップで全体像を俯瞰してから、各章に進みましょう。

「コードが書ける」だけでなく、設計書を読み解いて実装に落とす力・責務を分けて作る力・Git でコミットを積む実務感覚まで一通り経験することがこのプロジェクトのゴールです。

今回の作成物

ローカルで動作するECサイト一式です。具体的には次の機能を実装します。

• 商品一覧・商品詳細ページ
• ショッピングカート機能（追加・更新・削除）
• 会員登録・ログイン・ログアウト機能
• 注文確定処理（在庫更新と注文保存をトランザクションで実装）
• マイページ（情報変更・パスワード変更）
• 基本的なCSS・エラーハンドリング・セキュリティ対策

解説

商品データは seed として12件分が事前に登録されています（カテゴリ — インテリア / キッチン雑貨 / ファブリック / 文具 / ファッション / 食器）。商品の登録・編集・削除（管理画面）は本フェーズの対象外です。

完成版デモ（先に動かして確認できます）

実装に入る前に、完成版が ブラウザですぐ触れる 状態で公開されています。「自分が最終的に作るもの」を一度動かしておくと、各章での実装イメージが湧きやすくなります。

• デモURL — https://prod-luagate-pj-ec-demo-v3bbmayaea-an.a.run.app
• 試せる操作 — 商品一覧 / 商品詳細 / カート追加・更新・削除 / 会員登録 / ログイン / 注文確定 / マイページ
• 動作環境 — Tomcat 10 / Java 25 / PostgreSQL 17（Neon マネージド）

解説

このデモは共有環境です。会員登録すれば自分のアカウントで試せますが、他の受講生と DB を共有しているため、注文・カートの状態は時々リセットされる可能性があります。「正解の挙動を確認するための場所」として使ってください。

個人情報（実在のメールアドレス・実在のクレジットカード番号など）は入力しないでください。デモは学習用のため、入力データは他の受講生からも見える可能性があります。

完成版と starter — まずは触ってみる

実装に入る前に、完成版 と starter の 2 つを並べて触っておくと、これから自分が埋めていく差分のイメージが一気に掴めます。どちらも 運営が用意した参考デモ環境 で、ブラウザから即アクセスできる状態になっています。受講生は 自分でデプロイ作業をする必要はなく、ブラウザから挙動を確認するだけ で OK です。

• 完成版 LIVE DEMO は会員登録〜カート〜注文確定まで一通り動く状態。「最終的に自分が作るもの」がそのまま動く形で見える
• starter LIVE DEMO は受講生が clone した直後とまったく同じ「空骨格」状態。商品一覧は空、ログインもまだ動かない。最初に何が「無い」のかを目で確認できる
• 本プロジェクトは starter から始めて、Ch10 〜 Ch14 で TODO を 1 つずつ埋めて完成版に追いつく 流れになる
• starter LIVE DEMO はあくまで「初期状態の見本」。実際の実装作業は、starter ブランチを自分のマシン (または Codespaces) に clone して進める のが基本

starter を手元に取得するコマンド例。

git clone -b starter https://github.com/Luagate-com/luagate_pj_ec_site.git

すでに作成されているもの（教材として用意済み）

実装に集中できるよう、上流工程の成果物はあらかじめ用意してあります。皆さんはこれらを読み解いて実装に落とす役割です。

• ヒアリングシート・企画書・要件定義書・基本設計書・詳細設計書（docs/ 配下）
• DBスキーマと初期データ（db/schema.sql / db/seed.sql — 商品12件のseed込み）
• ビルド設定（pom.xml / src/main/webapp/WEB-INF/web.xml）
• CSS雛形（src/main/webapp/assets/css/）
• 商品画像（src/main/webapp/assets/images/goods/ — 12点 + プレースホルダ）
• Figmaデザイン（画面のビジュアル仕様）
• 実装FAQ（よく詰まるポイントの解決策）

解説

実務でも、エンジニアが入る前に企画・設計が固まっているケースは多くあります。設計書を読み込んで実装する力は実務に直結するスキルです。

このプロジェクトの全体像

このプロジェクトは、実務と同じ流れでECサイト構築を体験する構成になっています。下図は、ヒアリングからテスト・提出までの大きな流れです。各章はこのフローに沿って進みます。

上流工程（ヒアリング〜詳細設計）は教材として用意してあり、受講生はそれを読み解いて実装に落とす流れになります。

教材リポジトリ

教材リポジトリの starter ブランチには、雛形・設計ファイル・DBスキーマ・seed・CSS・商品画像などが入った初期状態が用意されています。ここに章を進めながら自分でコードを足していきます。

リポジトリ — Luagate-com/luagate_pj_ec_site

Step 1. fork する

GitHubで Luagate-com/luagate_pj_ec_site を開き、右上の Fork ボタンを押して自分のアカウントに複製します。

Step 2. Codespaces で開く

forkしたリポジトリのページで、starter ブランチに切り替えてから「Code」 → 「Codespaces」 → 「Create codespace on starter」を選びます。

ブラウザだけで VS Code 環境が立ち上がります。

解説

Codespaces を starter ブランチで 起動した場合は、すでに starter をチェックアウトした状態で開かれるため git checkout starter は不要です。

Codespaces 起動から Hello 画面まで

ここで、最終的に画面が表示されるまでに 誰が誰を呼び出すのか を一枚の概念図で押さえておきます。ブラウザが Tomcat にリクエストを投げ、Tomcat が Servlet/JSP を実行し、必要に応じて DB を読みに行く、という4要素の流れです。

解説

補足 — 図中の JDBC（Java Database Connectivity）は「Java から DB に話すためのドライバ規格」。PostgreSQL 用の JDBC ドライバ（postgresql-42.7.4.jar）を経由して、Java コードから SQL を投げる。

実際の手順は次のとおりです。

1. fork した自分のリポジトリで starter ブランチを開く
2. 「Code」 → 「Codespaces」 → 「Create codespace on starter」をクリック
3. ブラウザに VS Code が立ち上がる。下部の「ターミナル」を開く
4. ここで ls を打つと、db/ docs/ pom.xml src/ などが見える状態

解説

この時点ではまだ Tomcat は起動していません。実際の起動（mvn tomcat10:run など）は Ch9 で行います。本章ではあくまで「Codespaces を立ち上げてターミナルが触れる」状態までをゴールにします。

Step 3. ローカルで作業する場合（任意）

Codespacesではなくローカルで開発する場合は clone します。

# 自分のforkをcloneする（YOUR_NAMEは自分のGitHubユーザー名）
git clone https://github.com/YOUR_NAME/luagate_pj_ec_site.git
cd luagate_pj_ec_site

# starter ブランチに切り替え
git checkout starter

Step 4. 進め方

LuaGate の各章を読みながら、starter に機能を実装していきます。詰まったときは LuaGate の質問チャネルで講師に質問してください。

開発の進め方（Git運用）

このプロジェクトは 実務と同じく Git でコミットを積みながら 開発します。

基本フロー

1. リポジトリを fork して自分用にする
2. starter ブランチを Codespaces で開く
3. starter ブランチに直接 commit していく（個人開発なのでfeatureブランチは不要）
4. 章ごと・機能単位でこまめに commit
5. 1日の終わり、または機能の区切りで push

ブランチについて

このプロジェクトでは starter ブランチに直接コミットしていきます。

理由

• 1人で開発するため、機能ブランチを切る必要がない
• forkした自分のリポジトリで作業するので、元の教材リポジトリには影響しない
• PR・マージなどの操作を覚える必要がなく、実装に集中できる

解説

Pull Request やブランチ運用は、次の実践開発プロジェクト（チーム開発編）で扱います。

origin と upstream の確認

fork した時点で、自分のリポジトリの URL が origin として自動設定されています。Codespaces のターミナルで git remote -v を打つと確認できます。

$ git remote -v
origin  https://github.com/YOUR_NAME/luagate_pj_ec_site.git (fetch)
origin  https://github.com/YOUR_NAME/luagate_pj_ec_site.git (push)

origin が 自分の fork を指していれば OK です。git push するとこの URL に向かってコミットが送られます。

解説

教材本家（Luagate-com/luagate_pj_ec_site）を upstream として追加するかは任意です。教材側に修正が入ったときに git fetch upstream で取り込みたい人だけ、次のように追加してください。

Copy

git remote add upstream https://github.com/Luagate-com/luagate_pj_ec_site.git

本教材を進めるだけなら追加不要です。

コマンド例

各章で実装が終わったら、以下のように commit & push します。

git add .
git commit -m "Ch8: 環境構築完了"
git push

機能単位の例

git add .
git commit -m "商品一覧ページを実装"
git push

git add .
git commit -m "カートに追加機能を実装"
git push

なぜコミットを積むか

• 実務でも 小さい単位でコミットするのが基本
• 詰まったときに「動いていた状態」に戻れる
• Mattermostで「どこで詰まっているか」を講師に共有しやすい
• GitHubの開発履歴がそのままポートフォリオの実績になる

解説

コミットメッセージは日本語でOK。章番号や機能名を含めると後から見返しやすいです。

章末演習

次のステップ

• 1-1: Claude Code とは何か — 開発の主役になる Claude Code の全体像をまず押さえると、本プロジェクトが何倍も進めやすくなります
• 1-2: Claude Code で何ができる？ — EC サイト開発の中で Claude Code に何を任せるかをイメージしておくと、教材の指示が読み解きやすくなります
• 2-1: インストールと初期設定 — Codespaces で開いた直後に Claude Code を起動できるよう、ローカル側の準備も同時に整えましょう