Claude Codeで 仕様駆動開発可能な環境へ！ 〜1週間気合いのモブプロweek〜

仕様駆動開発しよう　そうしよう

Transcript

1. Claude Codeで 仕様駆動開発可能な環境へ！ 〜1週間気合いのモブプロweek〜 KDDI アジャイル開発センター 名古屋サテライトオフィス長 たかたに
4. Learning Outcome（持ち帰れるもの） AI駆動開発へ踏み出す、最初の1週間の整え方 初めての手法を試すときのマインドセット AI駆動開発での効果の計測方法 3
5. 使い方は、いろいろある Claude・Codex・Copilotは、使っていますか？ コーディング 日常業務の 便利ツール開発 …etc 今日は、このうち「コーディング」を、チームで仕様駆動にした話。
6. AIに対して多くの人が感じてそうなこと
7. AIに対して多くの人が感じてそうなこと 「人間」 「明らかに人間 じゃないけど人 間っぽい」 「明らかに人間 じゃない」 「人間だと思った けどよく見ると違 う」
8. AIに対して多くの人が感じてそうなこと バイブコーディン グ楽しそうな人 コーディング支援 で楽した人 （2023,2024年ぐらいのGithub Copilot） バイブコーディング でPoC倒れした人 セキュリティ のニュースと か。。。
10. ハーネスって何？ harness ＝ 馬具 馬を縛る道具やない。馬を走らせる道具。 雑に言うと、AIの足場/ルール。 毎回ゼロから推測する → 地図とテストの上を走る。 15
11. 位置づけ 社外秘C AI駆動開発の中に「仕様駆動開発」がある。 AI駆動開発（AI-Driven Development） AIに「作る」仕事を任せ、⼈は「決める・確かめる」に集中する開発の総称 バイブコーディン グ 仕様駆動開発 対話で即興的に作る 試作・個⼈作業向き チームで再現できる 仕様が共通の情報源。誰が動かしても同じも のができる 成果物が残る 設計書・テスト・証跡が仕様から派⽣して揃 う Spec-Driven Development 仕様を先に決め、AIがそれに従って 設計・実装・テスト・⽂書を作る なぜ仕様駆動開発か AIコーディング⽀ 援 ⼈が書き、AIが補完・ レビューを⼿伝う 今回の議題 品質を前倒しできる 仕様の段階でレビューし、テストも仕様から 決まる バイブコーディングは「速く試す」、仕様駆動開発は「チームで正しく作る」。本番のチーム開発には後者を選ぶ KDDI Agile Development Center Corporation 11
12. 位置づけ 社外秘C AI駆動開発の中に「仕様駆動開発」がある。 AI駆動開発（AI-Driven Development） AIに「作る」仕事を任せ、⼈は「決める・確かめる」に集中する開発の総称 バイブコーディン グ 仕様駆動開発 対話で即興的に作る 試作・個⼈作業向き なぜ仕様駆動開発か チームで再現できる 仕様が共通の情報源。誰が動かしても同じも のができる 成果物が残る 設計書・テスト・証跡が仕様から派⽣して揃 う Spec-Driven Development 仕様を先に決め、AIがそれに従って 設計・実装・テスト・⽂書を作る 本日の話 AIコーディング⽀ 援 ⼈が書き、AIが補完・ レビューを⼿伝う 今回の議題 品質を前倒しできる 仕様の段階でレビューし、テストも仕様から 決まる バイブコーディングは「速く試す」、仕様駆動開発は「チームで正しく作る」。本番のチーム開発には後者を選ぶ KDDI Agile Development Center Corporation 12
13. 社外秘C 〜ご支援したエピソード〜 KDDI Agile Development Center Corporation
14. （事例）ご支援先のチーム現状 4
15. （事例）ご支援先のチーム現状 依頼内容） 1週間以内に成果を上げて ほしい！！！ 4
16. AI活⽤の現在地と次ステップ 現在地はLv0、次は⽂書参照のLv1 Lv3 Lv0 今ここ ⼩さな修正 ⼈が指⽰し、AIは1ファ イルの修正だけ⾏う Lv1 次の⽬標 ⽂書参照 ⼈がCLAUDE.md・設計 書・API/DB仕様を渡し 、AIが読んで実装する Lv2 仕様駆動 ⼈が仕様を書き、AIが「 計画→タスク→実⾏」を 決まった型で回す ツール連携 AIがMCP/CLI経由で画 ⾯・クラウド・GitHub を直接操作する。ただし 検証は⼈が⾏う Lv5 Lv4 判断／承認 ⾃⼰検証 AIがテスト・CIで⾃分 の実装を検証し、失敗し たら⾃分で直してから PRを出す ※テスト・CIの整備が 前提 ⼈はPRを⾒て判断・承 認するだけ 検証は⼈が担う（Lv0〜3） 検証もAIが回す（Lv4〜） ⼈の役割︓⼿順を渡す（Lv0〜3） 基盤を整える ⼈が⼿順・⽂脈を渡し、結果も⼈が確認している ⼈は実装の⾯倒を⾒る側から、基盤を整え判断する側に 移る Lv4 判断する Lv5 ハーネス（CLAUDE.md・テスト・CI・権限設定）は全Lvで育て続ける。改善はチケット化して回す KDDI Agile Development Center Corporation 16
17. 体制 KAG 支援 2名 仕様駆動開発Readyへ の支援 私 SM Dev お客様チーム 5名 伴走 Dev Dev Dev Dev 若手 ベテラン開発者 ・要件検討 ・開発経験少し これまで開発して た人たち PO マネージャー 1チームの体制を1週間組んでみた。 5
18. モブプログラミングで実施 KAG 支援 2名 お客様チーム 伴走 仕様駆動開発Readyへ の支援 私 SM 5名 Dev ナビゲータ 必要なときに指示方針と、 出力の良し悪しを判断する Dev Dev Dev Dev 若手 ベテラン開発者 ・要件検討 ・開発経験少し これまで開発して た人たち ドライバー Claudeに指示し、 手を動かす。 PO マネージャー リサーチャー （ナビゲータ） チームにあった進め方のアイデア出し ハーネスを伴走。 5
19. Why モブプロ？ 若手が操作し、ベテランが判断。→ 設計思想を学べる 全員が同じ画面で議論 → 環境・チームの方向性統一 詰まりが、その場で解決する → 環境構築がスムーズに ハーネスを全員で作り、納得感が出る 全員で集中するため 10
21. 1週間、これ だけに専念で きる環境を作 った 1週間で、 仕様駆動開発 を作り切る。 そのゴールが あった 初対面の私た ちを、受け入 れてくれた モブで手元を 見せ、設計書 も全部出して くれた 初めてのプロセス 導入を受け入れ、 わからないを口に 出した
22. 仕様駆動開発とClaude開発環境整備を並⾛させた5⽇間 事前準備 Day1 チケット Day2 Day3 #1 着⼿ → 完了 Day4 Day5 #2〜#4 並⾏ #5 重い課題 重い課題で 型を検証 チームの進め⽅ Copilot実績 の整理 Spec Kit準 備 ⼿戻り率計 測 UI/UXルー ルを揃える Spec Kit導 ⼊ 仕様→実装 を並⾏で回 す Claude 開発環境整備 環境と権限 の準備 環境構築 トークン計 測 ハーネス整 備 MCP接続 トークン 節約術 ハーネスを 磨き込む 仕様駆動開発 ハーネス 毎朝ゴールを決め、毎⼣ふりかえる。気づきはその⽇のうちにハーネスへ戻してClaudeを育てる KDDI Agile Development Center Corporation 22
23. 1日の流れ 10:30 デイリーMTG ▶ モブ 応答待ちは雑談 ▶ 17:00〜 振り返り 応答待ちに雑談を増やし、関係性と意見の言いやす さが上がった 17時以降は、応答待ちの間に振り返り。 明日への改善点を話した 8
24. 1day sprintを実施 毎朝10:30、デイリーMTGの中身 1. 昨日やったこと 2. 今日トライしたいこと 3. 今日モブする時間 4. 今日のゴール（そのままAIへの指示にする） 5. 課題 7
25. 事前準備〜Day1 環境構築編
26. 仕様駆動開発とClaude開発環境整備を並⾛させた5⽇間 事前準備 Day1 チケット Day2 Day3 #1 着⼿ → 完了 Day4 Day5 #2〜#4 並⾏ #5 重い課題 重い課題で 型を検証 チームの進め⽅ Copilot実績 の整理 Spec Kit準 備 ⼿戻り率計 測 UI/UXルー ルを揃える Spec Kit導 ⼊ 仕様→実装 を並⾏で回 す Claude 開発環境整備 環境と権限 の準備 環境構築 トークン計 測 ハーネス整 備 MCP接続 トークン 節約術 ハーネスを 磨き込む 仕様駆動開発 ハーネス 毎朝ゴールを決め、毎⼣ふりかえる。気づきはその⽇のうちにハーネスへ戻してClaudeを育てる KDDI Agile Development Center Corporation 26
27. Day1 事前準備〜Day1 でやったこと ① 資料を集めた（旧設計書・図・API仕様） ② Claudeの環境を設定した ③ トークン・コストを、チケットに紐づけた 16
28. Day1 やったこと① AIに学習させる既存データの収集 領域 コードの規模 集めた資料 フロントエン ド 約数万行・約100ファイル／ 約10画面（React・ TypeScript） 画面遷移 約5本／画面設計 約5本・画面画像 約10 枚 バックエンド ・API 約数千行・約50ファイル／ API 約40本 Swagger（API約20本）／シーケンス 約5本／ユ ースケース（図約10枚） DB 約5テーブル・マイグレーショ ン約5本／PostgreSQL＋ Redis テーブル定義 約5本／状態遷移図 約3枚 他システムと の結合 外部API 約10本・3系統 システム構成／機器との通信図／値の変換仕様 全体 約2万行 旧設計書 md約40本・約数千行／図 約50枚／API 仕様 20本／社内のテスト観点チェックリスト
29. Day1 やったこと② Claudeの環境を設定した 権限 開発環境 設定ファイル Claudeに許可する操 作の範囲を決めた Claudeだけでなく、 GithubやAWS環境な ど、全員が同じ環境で 動くようにした CLAUDE.mdと .mcp.jsonの設定と置 く場所を用意した 環境と権限の準備
30. Day1 やったこと③ トークンとコストを、開発チケットに紐づけて 計測する環境を整えた 開発チケッ ト Claudeが作 業 着手する モブで進める MCP経由で 記録 チケットに 残る チケット管理の MCP トークン・コスト・ 手戻り ・チケット単位で、所要時間・トークン・Claude費が残る ・費用対効果を、チケットごとに出せる （成果サマリの元データ） ・手戻り率も、同じチケットに紐づけて取る
31. Day1 やったこと③ チケットに残る計測項⽬と、束ねて⾒える費⽤対効果算出。 ⾃動で取る Claude Codeの計測 • 実働時間（離席を除く） • トークン・LLMコスト • 押し戻し率（reject） 本⼈が付ける セッション終了時の3問 • AIがなかったら︖ • AIの貢献度 • ⼿戻りの量 作業から拾う リポジトリの痕跡 • ⼯程（調査・資料・開発） • commit・PR・編集ファイル TICKET Claude Code 実績 2倍超 開発内容 〇〇まわりをいい感じに改善 ROI（産出÷投下） 必要なら△△も対応… 約20時間分 中⾝が曖昧でも、実績は数字で残る 実働 トークン・費⽤ 分 $ 押し戻し率 1スプリントで束ねると % AIがなかったら 数倍かかった 貢献度 AI主導 ⼿戻り なし ⼯程 develop 成果物 PR KDDI Agile Development Center Corporation ⼿作業⽐で削れた時間 約7割 AI主導だったセッション ゼロ ⼤きな⼿戻り（半分以上） 数倍＝3倍・⼈時単価で換算した試算 31
32. Day1 やったこと③ なぜ、トークンと手戻り率を取るのか 先行指標 遅行指標 トークン 手戻り率 AIに、どれだけ任せたか 任せた結果、どれだけやり直したか 対で見る トークンだけ見ると 手戻り率だけ見ると 使っただけで、成果が出ない （お金使ってるだけ） AIを使わない方が、良く見える （人間がどれだけ正しいと判断） 偉い人「AIへの投資が成果につながっているかを、知りたい。AI適切に使ってるのかね？」 我々「AIにこれだけ任せて、これだけ検査してます！！！！！！」
33. Day1 課題・議題 ふりかえりの声 day1 進み始めた。モブで質問がすぐ解決した 開発環境まわりが大変だった Claudeが動かないとき、Copilotで打開できた 17
34. Day2 ハーネス整備編
35. 仕様駆動開発とClaude開発環境整備を並⾛させた5⽇間 事前準備 Day1 チケット Day2 Day3 #1 着⼿ → 完了 Day4 Day5 #2〜#4 並⾏ #5 重い課題 重い課題で 型を検証 チームの進め⽅ Copilot実績 の整理 Spec Kit準 備 ⼿戻り率計 測 UI/UXルー ルを揃える Spec Kit導 ⼊ 仕様→実装 を並⾏で回 す Claude 開発環境整備 環境と権限 の準備 環境構築 トークン計 測 ハーネス整 備 MCP接続 トークン 節約術 ハーネスを 磨き込む 仕様駆動開発 ハーネス 毎朝ゴールを決め、毎⼣ふりかえる。気づきはその⽇のうちにハーネスへ戻してClaudeを育てる KDDI Agile Development Center Corporation 35
36. ハーネスって何？ harness ＝ 馬具 馬を縛る道具やない。馬を走らせる道具。 雑に言うと、AIの足場/ルール。 毎回ゼロから推測する → 地図とテストの上を走る。 15
37. Day2 やったこと① バックエンドの設計書を取り込みまくり、md化 アウトプット（AIが読みやすいもの） 初日に集めたインプット 旧設計書 screens.md md 約40本 図 約70枚（PlantUML・ 画面） API仕様 20本 Claude Opus api.md ・ business-flows.md 既存コードと突き合わ せて、mdにする db.md architecture.md Opusで精査 known-issues.md 作業のためのルール：コードを正、旧設計書は意図の参考。 mdにしたら、人が確認する。確認は、若手＆ベテランと一緒に行い、設計の棚卸し。
38. Day2 やったこと② デザインの5階層でAIが理解できるよう整理することで ブレのないデザインをClaudeが出せるようにする。 input 要件定義書 ペルソナなど 戦略 ## 戦略 - 対象: 現場の申請担当者 （PC作業中心、ITリテラ シー中程度） - 成功: 申請1件を3分以内 に完了できる - トーン: 業務ツール。遊 びは入れない。装飾より 速さを優先する - やらないこと: ダッシュ ボード化、通知の多用 画面遷移図 状態遷移図 要件定義書 機能一覧など ▶ 要件 ## 要件 - Must: 申請作成 / 下書 き保存 / 差し戻し確認 - Won't: 一括承認（v2 に回す） - 1画面1タスク。複数 の目的を1画面に混ぜな い ▶ 構造 ## 構造 - 階層は最大3段（一 覧 → 詳細 → 編集） - どの画面からも一覧 へ1クリックで戻れる - 各画面に「空状態 / エラー / 送信中」を必 ず定義する 画面仕様書 ワイヤーフレーム アイコン デザイントークン 骨格 表層 ▶ ## 骨格 - 主ボタンは1画面に1 つだけ、右下に固定 - フォームは1カラム。 ラベルは入力欄の上に 置く - 破壊的操作は確認ダ イアログを経由し、主 ボタンとは離して置く - テーブルは左端に識 別子、右端に操作列 ▶ ## 表層 - 色: primary #1F3A93 / danger #E64A2E / そ れ以外はグレー階調だ け - 余白: 8の倍数 （8/16/24/32） - 文字: 本文14px、見 出しは2段階まで - 禁止: グラデーショ ン、角丸ピル型ボタン、 絵文字アイコン 19
39. Day2 チームの様子 ふりかえりの声 day2 ベテランエンジニア 若手 ・会話が、だいぶ増えた ・かなり学んだ ・知っていることを、その場で言葉 にしてくれた ・ハーネスができる過程を、一緒に 見て学んだ ハーネス整備は、AIの作業だけでなく、チームの学びでもあった。
40. Day3 チケット着手編 - 見えてきた課題 -
41. 仕様駆動開発とClaude開発環境整備を並⾛させた5⽇間 事前準備 Day1 チケット Day2 Day3 #1 着⼿ → 完了 Day4 Day5 #2〜#4 並⾏ #5 重い課題 重い課題で 型を検証 チームの進め⽅ Copilot実績 の整理 Spec Kit準 備 ⼿戻り率計 測 UI/UXルー ルを揃える Spec Kit導 ⼊ 仕様→実装 を並⾏で回 す Claude 開発環境整備 環境と権限 の準備 環境構築 トークン計 測 ハーネス整 備 MCP接続 トークン 節約術 ハーネスを 磨き込む 仕様駆動開発 ハーネス 毎朝ゴールを決め、毎⼣ふりかえる。気づきはその⽇のうちにハーネスへ戻してClaudeを育てる KDDI Agile Development Center Corporation 41
42. 開発開始！Spec Kitを使用。 7ステップで、人は3か所だけ見る。 ①仕様 ②計画 ③タスク ④実装 specify plan tasks implement converge stg→本番 MCP＋人 人＋AI AI AI AI 人 AI＋人 AI＋人 Opus Opus Sonnet Sonnet − − − タスクを順番 にコードにし ていく。テス トを書いて、 通るまで直す 仕様とズレて いないか、品 質・セキュリ ティはどうか を見る。 AIがパイプラ インを回して stgへ出す。人 が見て、本番 へ出す MCPで画面 を動かし、受 け入れ条件を 確認 目的・ユー ザー・受け入 れ条件を言葉 にする。AIが 曖昧な点を質 問して詰める 仕様を技術的 計画を、実装 な設計に落と できる粒度に す。技術選定、 分解する。 データモデル、 API、画面の 構造 ⑤レビュー. ⑥デプロイ ⑦確認 13
43. Day3 仕様 spec.md 計画 plan.md、datamodel.md、API 定義、画面遷移図 （構造・骨格） # Feature: 経費申請 ## ユーザーストーリー - 申請者として、領収書を添付して 経費を申請したい。月末の精算を早 く終わらせたいから ## 受け入れ条件 - [ ] 金額・日付・科目・領収書が揃 わないと送信できない タスク tasks.md 実装 コード、テスト、 （チェックリスト、 コミット／PR 各タスクの完了条 件、テスト観点） レビュー デプロイ レビューコメント、 stg環境、本番リ 手戻りのタスク、 リース、リリース マージ判断 ノート # Implementation Plan ## 技術構成 - Frontend: Next.js (App Router) - Backend: Lambda + API Gateway - DB: DynamoDB / 添付ファイル: S3（署名付 きURLでアップロード） ## 構成上の判断 - 下書きはステータス管理（draft / submitted / rejected / approved） - 画像はクライアントで圧縮してからアップ ロードする 確認 検証ログ、スク ショ、受け入れ判 定 ## Phase 1: Setup - [ ] T001 DynamoDBテーブルとS3 バケットをTerraformで作成 ## Phase 2: Tests First - [ ] T002 [P] POST /expenses の契 約テスト - [ ] T003 [P] 必須項目バリデーショ ンのテスト
44. Day3 出てきたmdと、レビューの観点 spec.md plan.md tasks.md ・ユーザーストーリー ・受け入れ条件 ・成功基準 ・確認したい点（clarify） ・調査 ・データ設計 ・API契約 ・確認手順 ・タスク一覧（約19件） ・テストを先に書く順 ・依存関係 レビューの観点 レビューの観点 レビューの観点 人が読んで合意する。受け 入れ条件が、確認できる形 か 憲章に反していないか。要 件チェックリストを通す spec・plan・tasksが、ず れていないか（analyze）
45. Day3 やったこと やったことサマリ チケット#1が完了 Playwright MCPを接続 トークン節約術を導入 ふりかえりで、ハーネスを足した 22
46. Day3 やったこと②（おまけ） トークン節約のルールをチームに布教 /statuslineで、使用トークンを常時表示 200kを超えたら、/compactか/clear。気づいた人 が声に出す 軽い作業は、Sonnetへ 23
47. Day3 課題・議題 ふりかえりの声 day3 ブラウザ操作MCPの出力が重く、トークンが溶けた 明確ならSonnet、整理から考えるならOpus Opusは一発で出て、トータルで安いこともある。金 額面は気になる 24
48. Day4 チケット着手編 - Claudeとの向き合い方編 -
49. 仕様駆動開発とClaude開発環境整備を並⾛させた5⽇間 事前準備 Day1 チケット Day2 Day3 #1 着⼿ → 完了 Day4 Day5 #2〜#4 並⾏ #5 重い課題 重い課題で 型を検証 チームの進め⽅ Copilot実績 の整理 Spec Kit準 備 ⼿戻り率計 測 UI/UXルー ルを揃える Spec Kit導 ⼊ 仕様→実装 を並⾏で回 す Claude 開発環境整備 環境と権限 の準備 環境構築 トークン計 測 ハーネス整 備 MCP接続 トークン 節約術 ハーネスを 磨き込む 仕様駆動開発 ハーネス 毎朝ゴールを決め、毎⼣ふりかえる。気づきはその⽇のうちにハーネスへ戻してClaudeを育てる KDDI Agile Development Center Corporation 49
50. Day4 やったこと 並行で回す。慣れてきた。 テスト駆動開発もトライし、品質向上 #2〜#5を、並行で回した 毎日のふりかえりで、ハーネスを足した やれるようになってきた。良い疲れ 25
51. Day4 やったこと② Playwright MCP(画面操作)で、E2E(自動テスト)を回した 受け入れ条件 spec.mdに書いた E2E Claudeが操作 Playwright MCPで画 面を動かす E2Eを実行 人が最終確認 動作を確認する ステージングの画面 単体テスト （画面側） Pytest （API側） 画面の確認を、人の手作業から、回せるテストに移した。
52. Day4 やったこと③ テスト駆動開発にトライしてみる。 Red Green Refactor テストを先に書き、 失敗させる テストが通るまで、 AIが実装 整える。型・lint・ビ ルドも通す ・tasks.mdが、最初からテスト先行の順に並ぶ ・テストまで書かせるので、レビューの戻りが少ない
53. Day4 課題・議題 ふりかえりの声 day4 議題：どこまで人が見る？ 確認すべき範囲の判断が大変 ユーザーストーリーで一度動かし、危険な部分は目で見る テストまで書かせ、レビューの戻りは少ない 26
54. Day5 チケット着手編 - 環境整備編 -
55. 仕様駆動開発とClaude開発環境整備を並⾛させた5⽇間 事前準備 Day1 チケット Day2 Day3 #1 着⼿ → 完了 Day4 Day5 #2〜#4 並⾏ #5 重い課題 重い課題で 型を検証 チームの進め⽅ Copilot実績 の整理 Spec Kit準 備 ⼿戻り率計 測 UI/UXルー ルを揃える Spec Kit導 ⼊ 仕様→実装 を並⾏で回 す Claude 開発環境整備 環境と権限 の準備 環境構築 トークン計 測 ハーネス整 備 MCP接続 トークン 節約術 ハーネスを 磨き込む 仕様駆動開発 ハーネス 毎朝ゴールを決め、毎⼣ふりかえる。気づきはその⽇のうちにハーネスへ戻してClaudeを育てる KDDI Agile Development Center Corporation 55
56. Day5 やったこと 重いチケット#5を、やりきった 最も重い課題に取り組んだ 終了後に、5日間のふりかえり DBと環境構築が壁。手戻りは少ない 27
57. Day5 課題 デプロイが、環境に縛られていた stgへは、dockerなしのスクリプトでデプロイしていた そのデプロイが、開発用コンテナ（DevContainer）に依存し ていた DBマイグレーションは、手動のまま DBと環境構築が、壁になった
58. Day5 次の打ち手（案） 次は、コンテナをそのままデプロイ 開発 ビルド コンテナで作る イメージを作る ステージン グ 同じイメージ ・環境の差が減る ・デプロイの手順が、誰がやっても同じになる ・本番の権限を、AIに渡さずに済む（CDで回す） 本番 同じイメージ
59. Day5 課題・議題 ふりかえりの声 day5 課題：DBが壁 DBが絡むと難しい 有識者と組まないと不安 規模で「誰と一緒にやるか」が 決まる 足りないもの CI/CD、UIのルール、デプロイ の手順 毎回AIにやらせる定型作業は、 高いcron 28
60. 結果・・・
61. 効果 10倍 ？！ 約20時間 → 約2時間 5チケットを1週間で完遂。費用対効果は約20倍。 29
62. 成果サマリ 1週間で5チケットを、仕様→計画→タスク→実装の型で完遂 # チケット レベル 感 所要時 間 トークン Claude 費 主なモデ ル 備考 1 画面の小さな追加 S 3.0h 約3,000 万 約4千円 Opus 5.5 確認の画面を追加 2 画面の小さな変更 S 1.5h 約4,000 万 約3千円 Sonnet 5 初期表示の状態を変更 3 画面・API・DBにまたがる変更 L 5h 約2億 約1万円 Sonnet 5 不具合をID管理で解消 4 定時処理の設定修正 S 0.5h − 1千円未 満 − 5 S 1.0h 約1,000 万 約1千円 Sonnet 5 参照されていないもの を削除 11h 約2億 約3万円 不要コードの整理 合計 実行時刻の指定を固定 レベル感 S：既存画面内の修正 ／ M：画面＋APIの追加 ／ L：画面・API・DBにまたがる追加 30
63. AI活⽤の現在地と次ステップ 現在地はLv3、次は検証もAIが回すLv4 Lv3 Lv0 ⼩さな修正 ⼈が指⽰し、AIは1ファ イルの修正だけ⾏う Lv1 ⽂書参照 ⼈がCLAUDE.md・設計 書・API/DB仕様を渡し 、AIが読んで実装する Lv2 仕様駆動 ⼈が仕様を書き、AIが「 計画→タスク→実⾏」を 決まった型で回す 今ここ ツール連携 AIがMCP/CLI経由で画 ⾯・クラウド・GitHub を直接操作する。ただし 検証は⼈が⾏う Lv4 次の⽬標 ⾃⼰検証 AIがテスト・CIで⾃分 の実装を検証し、失敗し たら⾃分で直してから PRを出す ※テスト・CIの整備が 前提 Lv5 判断／承認 ⼈はPRを⾒て判断・承 認するだけ 検証は⼈が担う（Lv0〜3） 検証もAIが回す（Lv4〜） ⼈の役割︓⼿順を渡す（Lv0〜3） 基盤を整える ⼈が⼿順・⽂脈を渡し、結果も⼈が確認している ⼈は実装の⾯倒を⾒る側から、基盤を整え判断する側に 移る Lv4 判断する Lv5 ハーネス（CLAUDE.md・テスト・CI・権限設定）は全Lvで育て続ける。改善はチケット化して回す KDDI Agile Development Center Corporation 63
64. 数字よりも価値があるものって、、、 モブやから、全員が理解した だから環境整備を、全員の手でやれた 全員で課題を理解し、ふりかえりをできた その結果、チーム適応できた 33
66. ・現状を会話し、 嘘をつかない ・ふりかえりで、 CLAUDE.mdに一行足 す ・ベテランが、持 っているナレッジ を公開する ・チーム運営ルールを 決める ・生まれたハーネスの大事なところを、 みんなで確認した。日々ふりかえり。 ・AIの中でも、押さえるポイントは押さえた
67. 転んだら、直す。それだけ。 転ぶ ▶ 不具合が出る！ AIが 原因を調べる ▶ 一行足す CLAUDE.md ▶ 次から 起きない 事故が、ルールになった。 透明性は地図、検査はテストとレビュー、適応は一行。 35
68. まとめ ・AIを現場導入するときは、足並み揃えるためモブがオススメ ・AIを現場導入するときは、計測＆観測し、ふりかえろう ・AIを現場導入するときは、ふりかえった結果、カイゼンしよう 35
69. まとめ ・AIを現場導入するときは、足並み揃えるためモブがオススメ ・AIを現場導入するときは、計測＆観測し、ふりかえろう ・AIを現場導入するときは、ふりかえった結果、カイゼンしよう → アジャイルマインドが大事 35