第7回 — Issue駆動開発① 設計とゲートレビュー

Phase 3｜Issue駆動開発 ／ 8時間（講義2h + ワークショップ6h）前提プラットフォーム：GitHub

---

この回の狙い

• いよいよ本丸。Issueを起点に、AIに方針提案させ、人がゲートレビューで品質を担保するサイクルを確立する
• 「良いIssue」の構造を体得する
• すべての経過をIssueに記録する＝属人化解消・追跡可能性を体験する

タイムテーブル

時間	内容
0:00–2:00	講義
2:15–5:00	WS① 構造化Issue作成→AI方針提案→ゲートレビュー
5:45–7:30	WS② 承認→実装→記録
7:30–8:00	振り返り・OJT課題

---

講義（2h）スライド構成

1. Issue駆動開発の全体像（再掲・詳細化）：Issue = 全対話と意思決定の集約拠点
2. ワークフロー：

   ① Issue作成（人）
   ② AIが調査し修正方針をIssueにコメント
   ③ 人がゲートレビュー（方針OK/修正指示）
   ④ AIが実装
   ⑤ 動作確認（→第8回）
   ⑥ PR作成・マージ（→第8回）

3. 良いIssueの構造（最重要）：
   • 概要：何をしたいか
   • 現状：今どうなっているか／問題点
   • 期待する動作：どうなれば正解か
   • 受け入れ条件：満たすべきチェックリスト
4. ゲートレビューとは：各ステップに人の承認を挟み、AIの暴走を防ぐ品質ゲート
5. なぜ方針提案を先にやらせるか：いきなり実装させず、方向を合わせてから実装 → 手戻り激減
6. 記録の価値：方針・対象ファイル・影響範囲・確認結果がすべてIssueに残る → 過去の意思決定を追跡可能／誰でも引き継げる／属人化しない
7. GitHub MCPの活用（第5回の応用）：IssueへのコメントをClaude Codeから直接
8. 本日のゴール

💡 講師メモ：ここでの「方針提案 → ゲートレビュー」の往復が研修の核心。実装の速さより方針合わせの精度を評価する。

---

ワークショップ（6h）

WS① Issue作成 → AI方針提案 → ゲートレビュー（約2h45m）

• [ ] 実務課題（またはサンプルリポジトリの練習Issue）から 構造化Issue を1件作成 （概要／現状／期待する動作／受け入れ条件）
• [ ] IssueのURL/内容をClaude Codeに渡す
• [ ] Claude Codeに：「このIssueについてコードベースを調査し、修正対象ファイル・修正方針・影響範囲をIssueにコメントして」
• [ ] 出てきた方針を ゲートレビュー： - 対象ファイルは妥当か／影響範囲の見落としはないか／受け入れ条件を満たす方針か
• [ ] 修正指示をIssueにコメント → AIに方針を更新させる（OKが出るまで往復）

WS② 承認 → 実装 → 記録（約1h45m）

• [ ] 方針承認後、Claude Codeに実装させる
• [ ] 差分を自分でレビュー
• [ ] 実装内容・判断の根拠をIssueにコメントとして記録
• [ ] 「このIssueを見れば、他人が経緯を追える」状態になっているか確認

⚠️ つまずきポイント：

• 受け入れ条件が曖昧 → AIの方針も曖昧に。条件は検証可能な形で書く
• ゲートレビューを飛ばして実装させると手戻り → 必ず方針合わせを挟む

---

OJT課題（次回まで）

実務で構造化Issueを1〜2件作成し、AIに方針提案までさせて記録する。

成果物

• 構造化Issue（記録付き）
• 方針提案→ゲートレビューの往復ログ

🎯 回のゴール

構造化Issueを起点に、AIの方針提案 → ゲートレビュー → 実装のサイクルを回せる。

講師チェック

• [ ] Issueに4要素（概要/現状/期待/受け入れ条件）が揃っている
• [ ] 方針提案にゲートレビューでフィードバックできた
• [ ] 経緯がIssueに記録されている