スクラムからAI-DLCへ ― コマンド化で実装するAI駆動開発

2025年11月13日 LT登壇資料 CO-LAB Tech Night vol.5 事業を成長させるサービス開発×生成AIのリアル

Transcript

1. AI時代の開発フロー AI-DLCについて スクラムからAI-DLCへ ― コマンド化で実装するAI駆動開発 発表者: Ryobi AlgoTech Capital 安田 佳央
2. 自己紹介 岡山から来ました 会社: RyobiAlgoTechCapital 役割: エンジニアリングマネージャー 関心: AI駆動開発の実践、組織づくり
3. 会社紹介 岡山のITベンダ両備システムズの子会社 (ファンド部門+CVC部門 15人程度) 為替のスペシャリストである鈴木恭輔が 立ち上げ AI為替ヘッジファンド・為替自動取引プ ラットフォームのプロダクトを開発中
4. Before： スクラム導入（2025年初頭） ▪ 時期: 2025年初頭、開発プロセス改善のために導入 ▪ 運用方法: 2週間スプリント、標準的なスクラムイベントを実施 ▪ 目的: プロセスの可視化と継続的な改善 ▪ 初期成果: 当初は有効に機能していた
5. 転機: AI駆動開発の進化 Copilot Cursor Claude Code 各段階で開発速度が向上 スクラムのフレームワークが追いつかなくなる Copilot Cursor Claude Code
6. 2つの課題 ① スプリントゴールの不整合 ② ストーリーポイントのインフレ 数日でバックログが枯渇、スプリント中の追加が常態化 ゴールと成果の整合性が曖昧 に 人間の開発速度を前提とした時間枠(2週間)が適切でなくなった 並行実行などで、50pt → 100pt超へ ベロシティの比較が無意味化 AI影響で変動が激しく、予測が困難に 並行稼働で処理 できる量が増え、見積もりの意味自体が問われる → 新たなフレームワークの導入を検討
7. AI-DLCとは(1/2): 定義 2025年8月、AWSが "AI-DLC（AI-Driven Development Lifecycle）" という 「AIを中 心に据えた新しいソフトウェア開発の進め方」 を提唱しました。
8. AI-DLCとは(2/2): 特徴 ・会話の方向を逆転させる - AIが主導、人間は承認者・検証者に ・部分的なアシスタント（コード補完、テスト生成など）から、プロセス全 体を担う共同設計者 ・設計技術をコアに統合 - DDD/BDD/TDDを本質的に適用、ソフトウェア品 質を維持 ・柔軟なイテレーション - Bolt(時間または日単位)で迅速に開発
9. スクラム vs AI-DLC（主な違い） スクラム 主導者: 会話の流れ: イテレーション: 見積もり: フィードバック: 人間 人間→AI 指示 2〜4週間（スプリント） ストーリーポイント スプリント末 AI-DLC 主導者: 会話の流れ: イテレーション: 見積もり: フィードバック: AI AI→人間 提案と選択 数時間〜数日（Bolt） 原則不要、価値重視 リアルタイム
10. AI-DLC 実現のために：コマンド化 .claude/commands配置: /コマンド名で直接実行可能 Claude Code / Cursor どちらでも同一体験: 環境を選ばず同じコマンドが実行可能 GitHub連携を自動化: Issue作成 / Project Board追加 / Status更新 / Issue-Branchリンク プロセス標準化: チーム全体で統一されたプロセスを実現、再現性向上
11. AI-DLCの2つのフェーズ Elaboration Phase（構想フェーズ） Construction Phase（構築フェーズ） 目的: 意図をキャプチャし、ユニット(Units)に変換する 手段: Mob Elaboration儀式。AIが意図をユーザーストーリー、受け入 れ基準、ユニットに初期分解を提案し、プロダクトオーナー、開発者、 QAなどのモブが協力的にレビュー・洗練する 目的: 構想フェーズで定義されたユニットをテスト済みの運用準備完了 のデプロイメントユニットに変換する 手段: ドメイン設計→論理設計→コード生成→自動テストの反復的実行。 各ステップでAIが生成し、開発者が検証する
12. Mob Elaboration: コマンド実行 Cursorのチャット画面で /ai-dlc-elaboration と入力すると、AIと対話的にビジネス意図 (intent)→機能(unit) → タスク(bolt)への分 解を実行できます。 1. コマンド入力: /ai-dlc-elaboration 2. AIが質問・提案を生成: 意図の明確化から具体的なBolt分解まで 3. 人間が承認・修正指示: 提案内容を確認し必要に応じて修正 4. GitHub Issue/Project自動連携: Issue作成、Project追加、Status更新
13. SPEC駆動開発の継承 Construction（構築フェーズ）：従来のSPEC駆動開発の流れを継承しつつ、調査駆動設 計でBolt実装計画を作成 Bolt単位のSPEC: 従来のSPEC駆動開発を継承 requirements.md → design.md → implementation_plan.md → tests/ 調査駆動設計 • Context7・Grep/Globによる事実収集 • design.mdに調査ログを記録 • decisions.md/assumptions.mdに判断・仮説を記録 Unitへのフィードバック: • 設計ドキュメントの陳腐化を防止 • Bolt実装中の発見をcomponent_model.md/architecture.mdに反映 • サブドメイン粒度で管理されたUnit設計が常に最新状態に • 機能全体のドキュメント品質を維持
14. GitHub：Project(KANBAN)と統合 コマンド実行 → GitHub自動連携: Issue作成、Project Board追加、Status更新を一気通貫 で自動化 作成(Redy) → 構築開始(In Progress) → 構築終了(Review) → PR レビュー(Done)
15. スクラムイベントの変化（Before/After） Before（スクラム） プランニング : デイリー: 計測: 継続イベン ト: 隔週の長時間会議 人間主導のタスク分解 デイリースクラム 3つの質問形式 ストーリーポイント ベロシティ予測 スプリントレビュー レトロスペクティブ After（AI-DLC） プランニング : デイリー: 計測: 継続イベン ト: 1週間以内の対話的エラボレー ション AIが主導、人間が承認 デイリーエラボレーション Bolt化中心、AIが自動判断 Bolt単位での完了予測 見積もり原則不要 Intent単位のレビュー 最適化されたレトロ
16. 3つの発見とメッセージ 【発見】 【メッセージ】 1. 速度とプロセスの整合がポイント — 固定時間枠から柔軟なBoltへ 2. 見積もり再考 — SP/Velocityからの脱却 3. コマンド化が標準化と再現性を生む スクラムプロセスを守るよりアジャイルに コマンド化から小さく試す — Claude/Cursorで実践可能
17. ご清聴ありがとう ございました