AIDF-NEXA トレーニングプログラム

Day 3: プロジェクト初期化 + RD 生成

前提条件: Day 2 完了、SoT・テンプレート概念理解済み

全体スケジュール

月 09/03 火 10/03 水 11/03 木 12/03 金 13/03 土日 月 16/03 火 17/03 水 18/03
AM
10~12
FARE 3日目
実践・後処理
★ Day 3
Init+RD
nexa-sample-1
Day 4
BD→DD
nexa-sample-1
Day 5
DD→Code
nexa-sample-1
Day 6
Code→Test
nexa-sample-1
- Day 7
RD→DD
nexa-sample-2
Day 8
PoC実践
BD→DD→Code
コース完了
レビュー
PM
16~17
演習レビュー
(オンライン)
演習レビュー
(オンライン)
- 演習レビュー
(オンライン)
コース完了
レビュー

★ 今日は Day 3(10/03):プロジェクト初期化 → RD 生成 → Git 提出

時間割

時間 トピック 時間配分
10:00 Day 2 振り返り 5 分
10:05 プロジェクト初期化 15 分
10:20 RD生成 理論 15 分
🔄 休憩 5 分
10:40 実習: RD生成+レビュー 40 分
11:20 Git ワークフロー 15 分
11:35 実習: 提出 20 分
11:55 まとめ + Q&A 5 分

パート1: 理論 (35m) + パート2: 実習 (1h25m)

パート1: プロジェクト初期化

10:00 - 10:35

Day 2 振り返り

Day 2 で学んだこと:

   SoT 4つのルール: 唯一のソース + 最新 + コピー + 編集不可

   5種テンプレート: 画面・API・DB・基本設計・非機能

   プロンプトパターン: @で指定 + 1画面ずつ + レビューしてから次

今日: プロジェクト初期化 → RD生成 → 提出

プロジェクト構造

nexa-sample-1/
│
├── 00_Input/                    ← 入力ドキュメント (SoT 原本)
│   ※ 入力 Input               ← Tài liệu đầu vào (SoT gốc) — KHÔNG ĐƯỢC SỬA
│
├── 01_要件定義/                 ← RD: Requirements Definition
│   ├── 90_Input/               ← BD→RD の SoT コピー
│   └── 91_Output/              ← AI生成の RD ドキュメント
│
├── 02_基本設計/                 ← BD: Basic Design
│   ├── 90_Input/               ← RD→BD の SoT コピー
│   └── 91_Output/              ← AI生成の BD ドキュメント
│
├── 03_詳細設計/                 ← DD: Detail Design
├── 04_実装/                     ← Code Implementation
├── 05_テスト/                   ← Test
│
├── .claude/                     ← NEXA Skills + Commands
│   ├── skills/                  ← /rd:generate, /bd:generate, etc.
│   └── commands/                ← Slash commands
│
└── CLAUDE.md                    ← プロジェクト設定

SoT フロー

00_Input/                          01_要件定義/
 requirements.md ──SoTルール3──→ 90_Input/requirements.md ──AI生成──→ 91_Output/
                   (コピー/Copy)                              (/rd:generate)
                                                                │
                                                    7ファイル生成
                                                    ├── 00_rd-summary.md
                                                    ├── 01_use-cases.md
                                                    ├── 02_business-rules.md
                                                    ├── 03_screen-inventory.md
                                                    ├── 04_api-inventory.md
                                                    ├── 05_table-inventory.md
                                                    └── 06_non-functional.md

SoT ルール:

  • ルール3 (コピー): Input は原本のコピー → 編集不可
    Input là bản copy của gốc → KHÔNG sửa
  • ルール4 (生成): Output は AI が生成 → レビュー後に修正可能
    Output do AI tạo → Sửa được SAU khi review

プロジェクト初期化

初期化コマンド:

# Claude Code でプロジェクトを開く
cd nexa-sample-1

# 初期化実行
/init-project

初期化でやること:

  1. フォルダ確認 — 00_Input 〜 05_テスト の構造チェック
    — cấu trúc 00_Input đến 05_テスト
  2. SoT コピー — 00_Input → 01_要件定義/90_Input/ へコピー
    — từ 00_Input sang 01_要件定義/90_Input/
  3. CLAUDE.md 確認 — プロジェクト設定 (tech stack, naming rules)
    — cấu hình project

⚠️ 90_Input にファイルがない = RD生成できない!

パート2: RD 生成

10:20 - 11:20

RD とは?

RD (Requirements Definition) = 要件定義

入力 Input:               RD (要件定義):
  requirements.md           ├── ユースケース (Use Cases)
  "ログイン機能が必要"    →  ├── ビジネスルール (Business Rules)
  "タスク管理ができる"    →  ├── 画面一覧 (Screen Inventory)
  "メンバー招待"          →  ├── API一覧 (API Inventory)
                             ├── テーブル一覧 (Table Inventory)
                             └── 非機能要件 (Non-functional)

なぜ RD が重要?

  • RD なし → BD が曖昧 → DD が不完全 → コードにバグ

  • RD = パイプラインの基盤

RD 生成の3コマンド

ステップ1: 生成

/rd:generate

→ 90_Input/ を読み、7ファイルを 91_Output/ に生成

ステップ2: レビュー

/rd:review

→ 10項目チェック → スコア (x/10) → PASS/WARN/FAIL レポート

ステップ3: 修正→再レビュー

FAIL修正 → /rd:review → WARN修正 → /rd:review → スコア ≥ 9/10

品質ゲート①: RD スコア ≥ 9/10 → BD フェーズへ進める

RD レビュー 10項目

# チェック項目 結果
1 全機能にユースケースが存在する PASS/FAIL
2 全画面がインベントリに存在する PASS/FAIL
3 全APIがインベントリに存在する PASS/WARN
4 全テーブルがインベントリに存在する PASS/FAIL
5 Features ↔ Screens 双方向リンク PASS/FAIL
6 Screens ↔ APIs 双方向リンク PASS/FAIL
7 ユースケースに代替フローが存在する PASS/WARN
8 バリデーションルールが存在する PASS/WARN
9 非機能要件が定義されている PASS/FAIL
10 出力がテンプレート構造に一致する PASS/FAIL

FAIL = 必須修正 | WARN = 推奨修正

よくあるRDミス

# ミス 影響 対応
1 Screen-API 相互参照の誤り BD作成時にAPI漏れ API-ID を正しく修正
2 API カウント不一致 サマリーと実際が異なる カウント更新
3 代替フローなし 異常系の処理漏れ UC に 3a. 追加
4 バリデーション BR なし セキュリティ問題 BR-XXX 追加

Tips: FAIL 修正 → WARN 修正 → 再レビューの順番

パート3: RD 実習

10:40 - 11:20

実習: RD 生成手順

ステップ1 (3分): 準備

cd nexa-sample-1
ls 01_要件定義/90_Input/     # 入力ファイル確認

ステップ2 (10分): RD 生成

/rd:generate

→ 出力確認: ls 01_要件定義/91_Output/ → 7ファイル

ステップ3 (5分): 初回レビュー

/rd:review

→ スコアと PASS/WARN/FAIL を記録

ステップ4 (15分): 修正
→ FAIL 修正 → WARN 修正 → 各修正後にコミット

ステップ5 (7分): 再レビュー → 最終スコア ≥ 9/10

⚠️ 困ったらトレーナーに質問

パート4: Git ワークフロー + 成果物提出

11:20 - 11:55

Git ワークフロー全体像

main ──→ trainee/mori/cp1-rd ──→ commit v0 ──→ fix ──→ fix ──→ final ──→ push ──→ PR
              │                      │           │       │        │          │       │
              ▼                      ▼           ▼       ▼        ▼          ▼       ▼
          ブランチ作成           初回生成     FAIL修正 WARN修正 最終レビュー  Remote  レビュー依頼

3つの原則:

  1. 生成直後にコミット → v0チェックポイント(修正前の状態を保存)

  2. 修正ごとにコミット → 変更履歴を記録(何を・なぜ修正したか)

  3. 最終レビュー合格後にPR → レビュー依頼

Step 1-2: ブランチ + v0 コミット

ブランチ命名規則:

trainee/<名前>/<チェックポイント>
例: trainee/mori/cp1-rd
フェーズ ブランチ名
RD(要件定義) trainee/mori/cp1-rd
BD(基本設計) trainee/mori/cp2-bd
DD + Backend trainee/mori/cp3-dd-backend
Full App trainee/mori/cp4-full-app

v0 コミット (生成直後):

git checkout -b trainee/mori/cp1-rd
git add 01_要件定義/
git commit -m "docs(rd): v0 initial RD generation

- Generated by: /rd:generate
- 7 files created in 01_要件定義/91_Output/
- Score: not yet reviewed"

Step 3: レビュー → 修正 → コミット

3a: レビュースコアをコミット:

/rd:review
git add -A
git commit -m "docs(rd): v0 review score 7/10

- PASS: 6, WARN: 3, FAIL: 1
- FAIL: Screen-API cross-reference errors"

3b: FAIL修正 → コミット:

git add -A
git commit -m "fix(rd): fix Screen-API cross-reference errors

- SCREEN-003: API-007 → API-014
- SCREEN-008: added API-018 (GET members)
- F-003, F-006 traceability corrected"

3c: WARN修正 → コミット:

git add -A
git commit -m "fix(rd): add missing alt flows and business rules

- UC-002: added alt flow for token failure
- Added BR-006, BR-007
- API count 16 → 18"

Step 4-5: 最終レビュー → Push → PR

4: 最終レビュー:

/rd:review   # スコア ≥ 9/10 を確認
git add -A
git commit -m "docs(rd): final review score 10/10

- All 10 checks PASS"

5: Push + PR作成:

git push -u origin trainee/mori/cp1-rd

gh pr create --base main \
  --title "docs(rd): RD completion — mori" \
  --body "## Summary
- Final score: 10/10
## Review History
| Version | Score | PASS | WARN | FAIL |
|---------|-------|------|------|------|
| v0      | 7/10  | 6    | 3    | 1    |
| final   | 10/10 | 10   | 0    | 0    |"

想定 Git Log(完成時)

f6g7h8i (HEAD -> trainee/mori/cp1-rd) docs(rd): final review score 10/10
d4e5f6g fix(rd): add missing alt flows and business rules
b2c3d4e fix(rd): fix Screen-API cross-reference errors
9a0b1c2 docs(rd): v0 review score 7/10
a1b2c3d docs(rd): v0 initial RD generation

✅ チェックポイント:

# 確認項目 必須
1 v0 生成コミットあり ✅ 必須
2 レビュースコアのコミットあり ✅ 必須
3 修正コミットにメッセージ詳細あり ✅ 必須
4 最終スコア ≥ 9/10 ✅ 必須
5 PR作成済み ✅ 必須

Backlog チケット報告

タイトル: [TRAINING] RD完了報告 — 森

## 概要
RD(要件定義)ドキュメントの生成・レビュー・修正を完了しました。

## 実施タスク
| # | タスク          | 状態 | 備考                             |
|---|-----------------|------|----------------------------------|
| 1 | /rd:generate    | 完了 | v0 生成(7ファイル)              |
| 2 | /rd:review 初回 | 完了 | スコア: 7/10                      |
| 3 | FAIL修正        | 完了 | Screen-API相互参照修正、API-018追加 |
| 4 | WARN修正        | 完了 | 代替フロー追加、BR-006/007追加     |
| 5 | /rd:review 最終 | 完了 | スコア: 10/10                     |

## レビュースコア推移
| バージョン   | スコア | PASS | WARN | FAIL |
|-------------|--------|------|------|------|
| v0(初回)   | 7/10   | 6    | 3    | 1    |

## ブランチ・PR

## 所感・学び
(自由記述 / Tự do viết)

評価基準

評価項目 配点 説明
RD最終スコア 40% /rd:review 最終結果 (x/10 × 4)
Gitワークフロー 20% checkpoint commit、メッセージ規約
修正品質 20% 正確・完全・新規バグなし
Backlog報告 10% フォーマット準拠、明確
PR品質 10% タイトル・本文・チェックリスト
**合計 100%**
点数 評価
90-100 A — 優秀
80-89 B — 良好
70-79 C — 合格
< 70 D — 要改善

確認クイズ

Q1: SoT ルール3 (コピー) の意味は?

  • a) Output をコピーして別の場所に保存
  • b) Input は原本のコピー → 編集不可 ✅
  • c) 全ファイルをバックアップ

Q2: /rd:review のスコアが 6/10 の場合、次にすることは?

  • a) そのまま BD フェーズへ
  • b) FAIL 修正 → WARN 修正 → 再レビュー ✅
  • c) 最初から再生成

Q3: v0 コミットはいつ作る?

  • a) レビュー後
  • b) 修正後
  • c) 生成直後、修正前 ✅

Day 3 まとめ + Day 4 プレビュー

今日学んだこと:

  • ✅ プロジェクト構造: 00_Input → 01_要件定義 → ... → 05_テスト
  • ✅ SoT フロー: Input → 90_Input (コピー) → 91_Output (生成)
  • ✅ RD生成: /rd:generate → /rd:review → 修正 → スコア ≥ 9/10
  • ✅ Git ワークフロー: ブランチ → v0 → fix → push → PR

Day 4:

  • BD 生成 (基本設計)
  • DD 生成 (詳細設計)

Day 4でお会いしましょう!

BD生成 + DD生成

Chào mừng mọi người đến với Day 3 — hôm nay chúng ta bắt đầu thực hành thực sự. Đầu tiên khởi tạo dự án NEXA, sau đó tạo RD (Requirements Definition) — tài liệu yêu cầu đầu tiên trong pipeline. Cuối buổi sẽ thực hiện Git workflow chuyên nghiệp để nộp sản phẩm.

Đây là lịch trình tổng thể. Hôm nay Day 3 — khởi tạo dự án NEXA, tạo RD, và nộp qua Git workflow. Ngày mai Day 4 tiếp tục BD→DD. Day 5 DD→Code. Day 6 Code→Test. Tuần sau chuyển sang nexa-sample-2, rồi PoC thực tế. Buổi chiều 16:00 là review online.

Chương trình Day 3: 35 phút lý thuyết, 1 giờ 25 phút thực hành. Phần 1 ôn Day 2 rồi học khởi tạo dự án và RD generation. Phần 2 thực hành tạo RD, review, fix, rồi Git workflow nộp sản phẩm. Tỷ lệ thực hành cao hơn ngày trước — hôm nay tập trung làm.

Bắt đầu với phần khởi tạo dự án NEXA. Hiểu cấu trúc thư mục, cách setup Claude Code, và quy trình tạo RD.

Ôn tập nhanh Day 2: 4 quy tắc SoT, 5 loại template, mẫu prompt hiệu quả. Hôm nay chúng ta sẽ áp dụng tất cả: khởi tạo dự án NEXA đúng cấu trúc, tạo RD (yêu cầu hệ thống), review và sửa cho đạt điểm, rồi nộp qua Git workflow.

Cấu trúc dự án NEXA theo mô hình waterfall Nhật Bản. 00_Input chứa tài liệu đầu vào gốc — đây là SoT source of truth, TUYỆT ĐỐI KHÔNG SỬA. Từ 01 đến 05 là các phase phát triển. Mỗi phase có 90_Input (SoT copy từ phase trước) và 91_Output (do AI tạo). Thư mục .claude chứa NEXA skills và commands. CLAUDE.md là project config.

Luồng SoT: file requirements.md từ 00_Input được copy vào 01_要件定義/90_Input — đây là SoT rule 3, bản copy không được sửa. Từ 90_Input, chạy /rd:generate tạo 7 file output: summary, use cases, business rules, screen inventory, API inventory, table inventory, non-functional. Đây là SoT rule 4 — output do AI tạo, có thể sửa sau khi review.

Khởi tạo dự án có 3 bước. Bước 1: kiểm tra thư mục — đảm bảo cấu trúc đúng. Bước 2: copy SoT — file yêu cầu từ 00_Input sang 01_要件定義/90_Input. Đây là bước quan trọng nhất — nếu 90_Input trống, không thể tạo RD. Bước 3: kiểm tra CLAUDE.md — xác nhận cấu hình project đúng. Dùng lệnh /init-project để tự động hóa.

Phần quan trọng nhất hôm nay: tạo RD. Chúng ta sẽ học lý thuyết 15 phút, rồi thực hành 40 phút. RD là tài liệu yêu cầu — nền tảng cho toàn bộ pipeline.

RD là Requirements Definition — tài liệu yêu cầu. Từ file input mô tả chức năng ("cần chức năng đăng nhập", "quản lý task"...), AI phân tích và tạo ra 7 tài liệu chi tiết: use cases, business rules, screen inventory, API inventory, table inventory, non-functional requirements. RD là nền tảng — nếu RD sai thì toàn bộ pipeline sai theo.

3 lệnh RD: generate, review, fix. Bước 1 /rd:generate đọc input và tạo 7 file. Bước 2 /rd:review kiểm tra 10 mục và cho điểm. Bước 3 sửa lỗi FAIL trước, WARN sau, rồi review lại. Mục tiêu: đạt ≥ 9/10 — đây là Quality Gate 1, chưa đạt thì không được sang BD.

10 mục kiểm tra. Mục 1-2: kiểm tra use case và screen có đầy đủ. Mục 3-4: API và table inventory. Mục 5-6: liên kết 2 chiều giữa feature/screen/API — đây thường là chỗ lỗi nhiều nhất. Mục 7-8: alternative flow và validation rule — thường là WARN. Mục 9-10: non-functional và template format. FAIL phải sửa bắt buộc, WARN nên sửa để tăng điểm.

4 lỗi phổ biến nhất. Lỗi 1: Screen-API cross-reference sai — ví dụ SCREEN-003 tham chiếu API-007 nhưng đúng ra phải là API-014. Lỗi 2: summary ghi 16 API nhưng thực tế có 17. Lỗi 3: Use Case thiếu alternative flow — ví dụ UC-002 logout không có flow khi xóa token thất bại. Lỗi 4: field thiếu business rule — display_name không có max length. Sửa theo thứ tự: FAIL trước, WARN sau.

Bắt đầu thực hành. Mỗi người sẽ tự tay khởi tạo dự án, tạo RD, review, fix, cho đến khi score ≥ 9/10. Đây là 40 phút làm việc thực tế với NEXA.

Thực hành 40 phút, 5 bước. Bước 1: chuẩn bị — mở project, kiểm tra input có file chưa. Bước 2: chạy /rd:generate — chờ AI tạo 7 file. Bước 3: chạy /rd:review — xem score và kết quả. Bước 4: sửa lỗi — FAIL trước, WARN sau, commit mỗi lần sửa. Bước 5: review lại, đạt ≥ 9/10. Ai gặp khó khăn hỏi trainer — đừng ngồi stuck quá lâu.

Phần cuối: Git workflow chuyên nghiệp. Các bạn sẽ tách nhánh, commit theo checkpoint, push, tạo PR, và viết báo cáo Backlog. Kết quả sẽ được chấm điểm.

Đây là toàn bộ Git workflow. 3 nguyên tắc: commit ngay sau gen để có checkpoint v0, commit mỗi lần sửa để log quá trình, tạo PR sau khi final review đạt.

Bước 1: tạo nhánh theo quy tắc trainee/tên/checkpoint. Bước 2: commit v0 ngay sau khi gen — TRƯỚC khi sửa. Commit message format: type(scope): description.

Bước 3 gồm 3 phần. 3a: commit score. 3b: sửa FAIL, commit riêng. 3c: sửa WARN, commit riêng. Mỗi commit message mô tả cụ thể sửa gì.

Bước 4: review cuối, score ≥ 9/10, commit. Bước 5: push + tạo PR. PR body chứa bảng Review History.

Git log mẫu: 5 commits đúng thứ tự. Checklist 5 điểm bắt buộc. Reviewer sẽ kiểm tra tất cả.

Backlog ticket: title format [TRAINING] RD完了報告 — tên. Nội dung gồm bảng task, score history, branch/PR info, và phần 所感・学び tự viết.

5 tiêu chí: RD score 40%, Git workflow 20%, Fix quality 20%, Backlog report 10%, PR quality 10%. A là 90+, D là dưới 70.

3 câu kiểm tra. Câu 1: SoT Rule 3 — Input là bản copy, không sửa. Câu 2: Score dưới 9 thì fix FAIL trước, WARN sau, review lại. Câu 3: v0 commit ngay sau gen, trước khi sửa bất cứ gì.

Tổng kết Day 3: hiểu cấu trúc dự án NEXA, luồng SoT qua các phase, thực hành tạo RD và đạt quality gate, thực hiện Git workflow chuyên nghiệp. Day 4 tiếp tục với BD generation và DD generation.

Hẹn gặp lại Day 4! Chúng ta sẽ tạo BD và DD — từ yêu cầu sang thiết kế tổng thể rồi thiết kế chi tiết. Hãy ôn lại SoT rules và RD output — đó là input cho BD. Cảm ơn mọi người!