「研修でJavaは書けるようになったのに、現場に入ったらチーム開発で全然動けない…」
これは多くの新人エンジニアが感じるギャップです。個人演習と実務の間には、「チームで仕様を合わせる力」「役割を分担して動く力」「設計書を書く力」という大きな壁があります。
この記事では、その壁を乗り越えるために設計された「プロジェクト型演習（プロ演）」の全体像を紹介します。JSP＋Java＋MySQLという実務スタックを使い、15名が5チームに分かれ、1つのWebシステムを機能単位で協力して作り上げる——3ヶ月間の本格的な研修モデルです。
この記事でわかること：
- 機能別チーム分けとMVP開発の設計思想
- JSP直呼び＋Servletの「モダン感覚に近いアーキテクチャ」の全体像
- チーム間を繋ぐ「お約束（共通ルール）」の定め方
- 3ヶ月スケジュールの組み立て方と注意点
- AIを実装以外で積極活用する具体的な方法
研修設計者・エンジニア講師・人事担当者の方にすぐ使えるヒントが詰まっています。ぜひ最後まどうぞ！
目次
- 設計のコンセプト：なぜ「機能別チーム×MVP開発」なのか
- 全体構成：5チーム・3人・1システム
- 技術スタックと開発環境（確定版）
- アーキテクチャ：JSP直呼び＋Servletの役割分担
- チーム間を繋ぐ「お約束（共通ルール）」
- チームに任せる部分
- ディレクトリ・パッケージ構成
- 3ヶ月スケジュール
- AI活用：実装以外で鍛える力
- 注意点と落とし穴
- まとめ
1. 設計のコンセプト：なぜ「機能別チーム×MVP開発」なのか
このプロ演の設計には、3つの核となる考え方があります。
① 機能単位でチームを分ける
「MVCのレイヤーでチームを分ける」方法（ViewチームとControllerチームを分ける等）は、初学者には責務の境界がわかりにくく混乱を招きがちです。代わりに「タスク機能チーム」「コメント機能チーム」のように機能単位で分けることで、チームが「自分たちの機能」を一気通貫で担当できます。
② MVP（Minimum Viable Product）に絞る
システム全体を作ろうとすると、3ヶ月では完成しないリスクがあります。「優先すべき5機能だけを作る」と決めることで、全チームが完成体験を確実に得られます。何を作るかは受講生自身が決めることで、当事者意識と主体性も育ちます。
③ 学習ステップに合った技術選択
Spring Bootなどのモダンフレームワークは便利ですが、魔法が多すぎて「なぜ動くのかわからない」状態になりやすいです。JSP＋Servlet＋素のJavaという構成は記述量は増えますが、リクエストの流れ・データの受け渡し・DB操作の仕組みがすべて「見える」ため、初学者の理解に最も向いています。
2. 全体構成：5チーム・3人・1システム
| 項目 | 内容 |
|---|---|
| 参加人数 | 15名（5チーム × 3名） |
| 開発対象 | 受講生が企画した1つのWebシステム |
| 開発範囲 | MVP：優先機能5つのみ |
| チーム分け | 機能単位（例：タスク・コメント・検索・通知・プロフィール） |
| 講師担当 | ログイン/ログアウト・アカウント管理・共通部品 |
| システムテーマ | 受講生が4月の企画フェーズで決定（テーマ：「みんなの役に立つWebシステム」） |
3人チームの中での役割分担はチームに委ねます。ただし全員が全体を把握できるよう、相互レビューや週次の進捗共有を習慣づけることが重要です。
3. 技術スタックと開発環境（確定版）
| 区分 | 技術 | バージョン |
|---|---|---|
| 運用環境 | OS | Ubuntu（Linux） |
| Java / Tomcat | Java 17 / Tomcat 10 | |
| DB | MySQL 8.0.43 | |
| 開発環境 | OS | Windows 11 |
| IDE | Eclipse（Pleiades 2025） | |
| Java / ビルド | Java 17 / Maven 3.9.7 | |
| DB（ローカル） | MySQL 8.0.43（WSL2上） |
4. アーキテクチャ：JSP直呼び＋Servletの役割分担
このプロ演のアーキテクチャの特徴は「URLがそのままJSPファイルに対応する」点です。モダンなWebフレームワークのルーティング感覚に近く、初学者でも「どのファイルがどの画面か」が直感的に把握できます。
GET・POST どちらもブラウザはJSPを直接呼び出します。JSPはブラウザからリクエストを受け取ると、内部で HttpClient を使ってServletにリクエストを投げ、Servletが返すJSONを受け取って画面を組み立てます。
| 操作 | ブラウザの入口 | JSP内部の動き | Servletの役割 |
|---|---|---|---|
| 画面表示（GET） | /tasks/list.jsp |
HttpClientでServletにGETリクエスト → JSON取得 → スクリプレットで描画 | データ取得してJSONを返す |
| データ登録・更新（POST） | /tasks/form.jsp |
HttpClientでServletにPOSTリクエスト → 結果JSONを受け取り → 画面遷移 | バリデーション＋DB更新してJSONを返す |
処理の全体フローはこちらです。
【GETの場合：画面表示】
ブラウザ → GET /tasks/list.jsp
└─ JSP内でHttpClient → GET /api/tasks（Servlet）
└─ TaskService → TaskDao → MySQL
└─ JSON レスポンス
└─ JSP：JSONをパースしてスクリプレットで描画
【POSTの場合：データ登録・更新】
ブラウザ → POST /tasks/form.jsp（フォーム送信）
└─ JSP内でHttpClient → POST /api/tasks（Servlet）
└─ TaskService → TaskDao → MySQL
└─ JSON レスポンス（成功/エラー）
└─ JSP：結果を受け取り → 完了画面 or エラーメッセージ表示
JSPは「画面の入口＋HttpClientによるServlet呼び出し＋スクリプレットによる描画」を担い、ビジネスロジックはServlet → Service → DAOに徹底的に委譲します。
⚠️ なお、EL式（${}）は使用しません。データの描画はスクリプレット（<% %>）とJSONパース結果で行います。
5. チーム間を繋ぐ「お約束（共通ルール）」
5チームが独立して動くためには、チームをまたいで守るべき「お約束」を講師が事前に定義・提供することが必須です。お約束が曖昧だと、結合フェーズで大量の不整合が発生します。
このプロ演で定める「お約束」は以下の5つです。
① DB接続は必ず DBUtil 経由
// ✅ 正しい接続方法（これだけ守ればOK） Connection con = DBUtil.getConnection();
② 全JSPの先頭に認証チェックを必ず入れる
<%-- 全JSPの先頭に必ず記述 --%> <%@ include file="/common/auth_check.jsp" %>
③ GET・POST ともにJSP直呼び。データ取得・更新はHttpClientでServletを呼ぶ
ブラウザはHTTPメソッドにかかわらず常にJSPを呼び出します。JSP内でServletへのリクエストを行い、返却されたJSONを処理します。直接Servletにフォーム送信するパターンは使いません。
④ パッケージ・ディレクトリの命名規則を守る
Java : com.example.{機能名}.{ClassName}
JSP : /{機能名}/{画面名}.jsp
Servlet : /api/{機能名} （例：/api/tasks）
⑤ 共通POJOは勝手に変更しない
model/Task.java や model/User.java など全チームが使う共通クラスは講師が管理します。変更が必要な場合は全体ミーティングで合意を取ります。
講師はこれらを「配布物セット」としてまとめて提供します。
| 配布物 | 内容 |
|---|---|
DBUtil.java | DB接続共通クラス |
AuthUtil.java | 認証ヘルパークラス |
auth_check.jsp | 認証チェック共通部品 |
header.jsp / footer.jsp | 共通レイアウト部品 |
model/User.java 等 | 共通POJO雛形 |
| コーディング規約.md | お約束のまとめドキュメント |
| ログイン機能（動くサンプル） | JSP/Servlet/Service/DAOが揃った見本コード |
中でも「動くログイン機能のサンプルコード」が最も強力な教材です。GET/POSTの使い分け・Serviceへの委譲・JSPへのデータ受け渡し・DBアクセスまで、すべての「お約束」が一通り含まれています。チームはこれを参考にしながら自分たちの機能を実装できます。
6. チームに任せる部分
お約束以外はチームに委ねます。自由度を与えることで、チームごとに工夫が生まれ、発表時の比較や振り返りが豊かになります。
| 項目 | 自由度 |
|---|---|
JSPのスクリプレット（<% %>）の使い方 | ✅ 自由 |
| CSS・デザイン・レイアウト | ✅ 自由（モバイルファーストのみ守る） |
| Serviceクラスのメソッド設計 | ✅ 自由 |
| DAOの実装方法 | ✅ 自由 |
| エラー時の画面表示 | ✅ 自由 |
| AIの活用場面・活用方法 | ✅ 自由 |
| チーム内の役割分担 | ✅ 自由 |
7. ディレクトリ・パッケージ構成
【Javaソース：機能別パッケージ】
com.example
├── model/ ← 全チーム共通（講師管理）
│ ├── Task.java
│ └── User.java
│
├── common/ ← 共通部品（講師担当）
│ ├── DBUtil.java
│ └── AuthUtil.java
│
├── auth/ ← 講師担当（ログイン/ログアウト/アカウント管理）
│ ├── LoginServlet.java
│ ├── LogoutServlet.java
│ └── AccountServlet.java
│
├── task/ ← チームA担当（タスク機能）
│ ├── TaskService.java
│ └── TaskDao.java
│
├── comment/ ← チームB担当（コメント機能）
│ ├── CommentService.java
│ └── CommentDao.java
│
└── （以降、機能ごとにパッケージを追加）
【WebContent：JSP・共通部品】
WebContent/
├── common/
│ ├── auth_check.jsp
│ ├── header.jsp
│ └── footer.jsp
│
├── auth/ ← 講師担当JSP
│ └── login.jsp
│
├── tasks/ ← チームA担当JSP
│ ├── list.jsp
│ ├── detail.jsp
│ └── form.jsp
│
├── comments/ ← チームB担当JSP
│ └── list.jsp
│
└── WEB-INF/
└── web.xml
8. 3ヶ月スケジュール
| 月 | フェーズ | 全体ミーティング | 主なアウトプット |
|---|---|---|---|
| 4月 | 企画立案 / 要件定義 | ◎ 月末に実施 | システムテーマ決定・機能一覧・ユーザーストーリー・チーム編成 |
| 5月 | 基本設計 / MVP設計 | ◎ 月末に実施 | ER図・画面遷移図・共通POJO定義・お約束ドキュメント合意 |
| 6月 | 詳細設計 / 実装 / テスト | 週次で進捗共有 | 各チームの機能完成・結合テスト・成果発表 |
5月末が最重要マイルストーンです。model/ 配下のPOJO定義・DBのテーブル設計・お約束ドキュメントの3点を全チーム合意で確定させることが、6月の結合品質を左右します。ここがズレると6月に全チームへ影響が波及します。
9. AI活用：実装以外で鍛える力
このプロ演では「実装以外でAIを積極的に活用する」をルールとして設けています。AIにコードを全部書かせるのではなく、エンジニアとしての思考・設計・ドキュメント力をAIで底上げするという使い方です。
| フェーズ | AI活用の具体例 |
|---|---|
| 企画立案 | システムアイデアのブレスト・ペルソナ作成・ユーザーストーリー生成 |
| 要件定義 | 機能一覧の整理・想定QAの洗い出し・ユースケース整理 |
| 基本設計 | ER図の叩き台・画面遷移の整理・テーブル定義書ドラフト |
| 詳細設計 | テストケース生成・コードレビュー補助・エラーメッセージ解読 |
| 試験 | バグ原因の仮説出し・修正案リストアップ・テスト観点の網羅チェック |
特にドキュメント作成へのAI活用は効果が大きいです。「AIが生成したドキュメントをチームでレビューして修正する」という流れは、仕様の認識齟齬を減らしながら、議論の質も高めます。
⚠️ 注意：AIが生成したコードを「理解せずに貼る」クセがつくと成長が止まります。AIを使ったら必ず「なぜそう書くのか」をチーム内で説明させる習慣を作りましょう。
10. 注意点と落とし穴
設計・運営上で特に気をつけたいポイントを整理します。
🔴 WSL2上のMySQL接続設定
Windows側のEclipseからWSL2上のMySQLに接続する際、ホスト名・ポート・ユーザー設定でつまずきやすいです。環境構築手順書をAIで生成して事前に配布すると初動がスムーズになります。
🔴 5月末のPOJO・テーブル定義変更は全体に影響
Task.java のフィールド追加など、共通POJOへの変更は全チームのコードに影響します。5月末以降は変更凍結ルールを設け、変更が必要な場合は必ず全体ミーティングで合意を取る運用にしましょう。
🔴 チーム間の進捗差が開きすぎる
週次で全体の進捗を共有する場を設けましょう。詰まっているチームへの早期サポートが、演習全体のリズムを守ります。
🔴 JSPのスクリプレット乱用
JSP内に大量のJavaコードが書かれると、Viewとロジックが混在して可読性・保守性が下がります。「Service呼び出しの1〜2行のみ許容、それ以外はServiceに移す」という指針を示すと、チームが設計を考えるきっかけになります。
🟡 モバイルファーストは最初から意識させる
「後からレスポンシブ対応」は工数が膨らみます。BootstrapやFlexboxを使ったモバイルファーストのHTML設計を最初から習慣づけましょう。
11. まとめ
このプロジェクト型演習の設計を一言で表すと、「現場感覚を持ちながら、初学者が完走できる規模に絞ったチーム開発体験」です。
要点を整理します。
- 機能別チーム分けでMVP開発：チームが「自分たちの機能」を一気通貫で担当し、完成体験を確実に得られる
- JSP直呼び＋HttpClient＋Servlet（JSON）：GET・POST ともにJSPが入口。JSPからHttpClientでServletを呼びJSONを受け取る構成で、URLと画面が1対1に対応し初学者が混乱しにくい
- お約束（共通ルール）でチームを繋ぐ：DBUtil・認証チェック・命名規則・共通POJOの4点セットを講師が提供し、チーム間の不整合を防ぐ
- お約束以外はチームに任せる：自由度を与えることで主体性と工夫が生まれる
- 5月末が最重要マイルストーン：POJO・テーブル定義・お約束の3点を全体合意で確定させることが6月の品質を左右する
- AIは実装以外に積極活用：設計・ドキュメント・テスト観点にAIを使い、エンジニアとしての思考力を鍛える
新人研修でチーム開発を取り入れるとき、技術的なハードルと運営上の落とし穴の両方を意識した設計が成否を分けます。この記事が、あなたの研修設計の参考になれば嬉しいです。ぜひ試してみてください！