Issue設計から始める仕様駆動開発 / 20260731 Mizuki Hirata

2026/7/31 AI駆動開発カンファレンス2026夏
https://www.ai-driven.dev/

AIアジャイル開発部 アジャイル推進グループ
平田 瑞樹

Transcript

1. AI駆動開発カンファレンス 2026 7 / 31 Issue設計から始める仕様駆動開発 13:50 - 14:30 株式会社SHIFT 開発本部 開発事業部 AIアジャイル開発部 平田 瑞樹 Copyright SHIFT Inc., All Rights Reserved. Mizuki Hirata 1
2. 自己紹介 平田 瑞樹｜Mizuki Hirata 株式会社SHIFT 開発本部 開発事業部 AIアジャイル開発部 2024年 株式会社SHIFTに入社 ・案件管理システム開発にメンバーとして参画 ・AIエンジンを用いた応対支援システム 開発チームリーダーとして参画中 Copyright SHIFT Inc., All Rights Reserved. 2
3. 本発表の経緯 背景 ・未経験メンバーへタスクを割り当てながら開発を推進 ・限られた期間で、進捗管理と成果物品質の両立が課題 →AI時代のジュニアエンジニアはアウトプットを量産できる一方、 その粒度や品質には大きなばらつきがある。 学び ・何を作るかよりも「どの単位で仕事を渡すか」が重要 ・タスクの粒度や完了定義が曖昧だと開発効率が下がる AI駆動開発の課題 ・AIも人と同様に曖昧な指示では期待通りに動きにくい ・開発品質の標準化が必要→Issue駆動開発で解決！ Copyright SHIFT Inc., All Rights Reserved. 3
4. アジェンダ 1. なぜIssue駆動開発なのか 2. 遭遇した課題と失敗から得た教訓 3. エンジニアの役割はコード記述から設計デザインへ 4. 実践プロセス 5. まとめ Copyright SHIFT Inc., All Rights Reserved. 4
5. 1. なぜIssue駆動開発なのか 2. 遭遇した課題と失敗から得た教訓 3. エンジニアの役割はコード記述から設計デザインへ 4. 実践プロセス 5. まとめ Copyright SHIFT Inc., All Rights Reserved. 5
6. 「いきなりAI駆動開発」がもたらす悲劇 抽象的な指示 暴走する実装 差分の肥大化 「◦◦機能を実装して」 とAIに丸投げ 不要なリファクタリング 実装者・レビュアー共に 理解不能なPRに 既存実装との乖離 コ ード が 書か れ る速 度 は圧 倒 的に 向 上し た が、 検 証・ 修 正し 、手 戻り に 対応 す るコ ス トが 最 大の ボ トル ネ ック 開 発の 主 戦場 は 「早く書かせる」から「手戻りなく制御する」へ →開発品質の標準化 この課題を解決するアプローチ SpecからIssue設計に落とし込む Copyright SHIFT Inc., All Rights Reserved. 6
7. ソフトウェア開発における「Issue」の定義 『イシューからはじめよ』※における “イシュードリブン”とは別物 ✕ ビジネス書のIssue ✓ AI開発におけるIssue ・漠然とした「問い」「仮説」 ・AIが迷わず自律実行・完遂できる単位 ・そのままAIに渡すと解釈がブレる ・極小／単一責任かつ明示的なタスク Copyright SHIFT Inc., All Rights Reserved. ※安宅和人『イシューからはじめよ［改訂版］―知的生産の「シンプルな本質」』英治出版、2024年 7
8. Issue ＝ 開発者が見慣れた「チケット」と捉える プロジェクトの進捗を管理するタスク管理ツール（Jira, Backlog, GitHub Projectなど） Feature Issue #00001 ユーザー情報と課金状態を 管理するテーブルを追加 実装方針 ✕✕✕・・・ Issueは1〜2日で完了できる単位 ・具体的で単一責任 ・明確な完了定義（DoD） →現場で標準化されていないことが多い ✓ AI駆動開発成功の鍵 Copyright SHIFT Inc., All Rights Reserved. 8
9. Issueだけで開発した場合の病 Issue ・Spec実現の作業単位 ・機能追加 ・バグ修正 ・リファクタリング ・短寿命な設計 AIに起こる現象 ・既存設計を理解せず実装 ・局所のみ正しいコード ・短期間でのみの解決策 発生する問題 ・全体の整合性が崩壊 ・コード重複 ・責務の分散 ・技術的負債の蓄積 Issueを満たす局所最適な実装によってシステム全体の整合性が崩壊してしまう Copyright SHIFT Inc., All Rights Reserved. 9
10. 解決策：SpecとIssueの「双方向同期」 Spec 双方向同期ループ Issue ① 切り出し・タスク化 ・判断基準 ・制約 ・設計原則 ・一貫性 ② 最新の実装と同期 ・作業境界 ・実装範囲 ・完了定義 ・優先順位 ✓ 解決：双方向同期 ①仕様からIssueを切り出して実装 ②完了したら仕様に反映して最新化 これを繰り返し、 アーキテクチャの一貫性と自律生産性を両立 Copyright SHIFT Inc., All Rights Reserved. 10
11. 1. なぜIssue駆動開発なのか 2. 遭遇した課題と失敗から得た教訓 3. エンジニアの役割はコード記述から設計デザインへ 4. 実践プロセス 5. まとめ Copyright SHIFT Inc., All Rights Reserved. 11
12. 遭遇した壁①：変更範囲の肥大化と暴走 曖昧な依頼 AIが推論を拡大 ・完了定義がない ・対象ファイルの境界が不明確 ・影響範囲が未定義 ・関連クラスへの波及 ・不要なリファクタ ・過剰な切り出し 差分が肥大化して実装者もレビュワーも理解不能な事態に ・何が本質的変更か分からない ・想定外の副作用が混入 ・レビューコストの増大 Copyright SHIFT Inc., All Rights Reserved. 12
13. 壁①への対応策と教訓 実装単位をIssueに落とし込み、完了定義と作業境界を明示する ① Issueに分割 「散見するロジックの共通化」 →「画面コンポーネント」「エラーハンドリング」 ➁ 作業境界を明示 変更可：Service/Repository 変更禁止：認証基盤・共通ライブラリ ③ 完了定義を明示 対象ディレクトリを指定・全テスト成功 Copyright SHIFT Inc., All Rights Reserved. 13
14. 遭遇した壁②：作業の重複とコンフリクト 個人で並列実装・メンバーとともに実装のどちらでも起こりうる問題 Issue A バックエンド実装担当 PR作成 バックエンドも 必要だとAIが判断 Issue B フロントエンド実装担当 PRレビュー/merge時に ・不要な工数が発生 ・コンフリクト修正の手間 ・不要なコードの残存 PR作成 不毛なコンフリクトや作業の重複が発生 ・2つの要件のチケットを別々に並行で処理させたことで重複実装が生じる ・チケット間の関係性や並行制御が不明瞭だとコンフリクトを招く Copyright SHIFT Inc., All Rights Reserved. 14
15. 親Issueが持つ役割：全体設計と共通ルールを握る 親 Issue：◦◦画面 全体設計：目的・スコープ・責務分担・共通ルール・API設計 共通コンポーネント：UserSettingService 制約：新規 Service 作成禁止 Issue A DB実装 Issue B BE実装 Issue C FE実装 親Issueを共有コンテキストとして利用する ・単なる管理単位として親チケットを扱わず、子チケットの実装を同期 ・親Issue→設計の一貫性を保持して子Issueを用いた実装の並列化に成功 Copyright SHIFT Inc., All Rights Reserved. 15
16. 1. なぜIssue駆動開発なのか 2. 遭遇した課題と失敗から得た教訓 3. エンジニアの役割はコード記述から設計デザインへ 4. 実践プロセス 5. まとめ Copyright SHIFT Inc., All Rights Reserved. 16
17. 役割：レビューの主戦場はIssue設計レビューへ Spec Issue 双方向同期デザイナー 人間は仕様設計とIssueへの分割に専念 Issue設計レビュー AIに渡す前に完了定義と作業境界を合意 ・完了定義は妥当か、境界線は正しく閉じているか、実装方針は問題ないか →人間同士が事前に議論・合意し、Issue設計時点で不具合の芽を摘む 開発品質の標準化のためのアクションが重要 Copyright SHIFT Inc., All Rights Reserved. 17
18. これからのエンジニアに求められる AIに対して脱線しないためのレールを敷くこと 求められるのはプログラミングの知識そのものではなく システム全体を俯瞰しながら適切に境界を定義し、 それをIssueとして言語化・メンバーとの合意形成を進めていく力 境界を定義 Issueとして言語化 メンバーと合意 「コードを書く人」から「AIが正しく動く仕組みを設計する人」へ Copyright SHIFT Inc., All Rights Reserved. 18
19. 1. なぜIssue駆動開発なのか 2. 遭遇した課題と失敗から得た教訓 3. エンジニアの役割はコード記述から設計デザインへ 4. 実践プロセス 5. まとめ Copyright SHIFT Inc., All Rights Reserved. 19
20. 全体フロー：仕様から実装・mergeまでの作業 ①仕様書を用意 ④チケット自動生成 ・要件定義、設計書を投入 ・docsに配置して管理 ・タスク管理ツールAPIで 一括作成 ・メンバーに展開・確認 ➁機能単位で抽出 ⑤実装 「◦◦画面の設計」 ・既存実装の調査 ・タスクの洗い出し ・チケット番号を指定して 自動実装〜PR作成 ③Issueに分解 ⑥レビュー・merge ・タスク間の関係性 ・見積もりと完了定義 ・レビュー用エージェント ・docs更新エージェント Copyright SHIFT Inc., All Rights Reserved. 20
21. 実践プロセス① 仕様書からAI仕様のIssueへ Copyright SHIFT Inc., All Rights Reserved. 21
22. 開発時の実装フロー テンプレート例 ①仕様書を用意 ・要件定義、設計書を投入 ・docsに配置して管理 ➁機能単位で抽出 「◦◦画面の設計」 ・既存実装の調査 ・タスクの洗い出し ③Issueに分解 ・タスク間の関係性 ・見積もりと完了定義 Copyright SHIFT Inc., All Rights Reserved. ・実装方針、タスクリスト（Issue分解用）、注意点など 洗い出し時に調査してほしい内容はテンプレート化 ・調査で重視したい範囲はAgents.mdやSkillsで指定 22
23. Issueをチケットで管理する チケット作成プロンプト例 ④チケット自動生成 ・タスク管理ツールAPIで 一括作成 ・ラベルのルールなど PJごとの固有ルールを 追加して管理・調整 Discussion! Agree! ・チケットをきれいに作成することよりもメンバーと認識齟齬がないか確認することが重要 ・Issueの粒度に落とし込んだにもかかわらず「わからない」を避けるための自動化に Copyright SHIFT Inc., All Rights Reserved. 23
24. 作成したチケットの確認 親チケット 子チケット ・親子チケットで相互リンクで管理 ・子チケット実装時にAIエージェントが親チケットを確認するよう制御することで 他の子チケットの実装進捗を踏まえて対象チケットの実装を進める Copyright SHIFT Inc., All Rights Reserved. 24
25. Issueによる実装品質の標準化 モデル依存の低減 ・テンプレート化によってAnthropic、 OpenAI、 Googleなどの差が出にくい →思考特性の影響はあるが、テンプレート化によって出力形式の差が埋められる →modelベンダーが異なっていても一定品質を維持 ・実装時点でOpus、Sonnetのような同一ベンダー内の性能差に依存しにくい → Issueに分解するステップに設計に必要な推論・実装方針を決める指示追従性を切り出し →model性能差の影響を抑えられる メンバー依存の低減 誰が担当しても同じIssueを基に実装するため成果のばらつきを抑制 Issue分解が品質の下限を引き上げる実装品質の標準化 Copyright SHIFT Inc., All Rights Reserved. 25
26. 実践プロセス② Issue → 自律実装 → 仕様同期 Copyright SHIFT Inc., All Rights Reserved. 26
27. Issue→実装の自動化 実装用プロンプト例 ⑤実装 ・チケット番号を指定して 自動実装〜PR作成 ・/start-work [チケット番号] 明示的に作業を指定 ・PJ特性に合わせて改良 例)branch戦略、静的解析… ・コマンド実行後に作業フローを確認し、誤った実装や作業フローがあれば コマンド内の指示がおかしいのか子チケットの粒度がおかしいのか検証・改善する ・最終的には自動実行しても問題なく実装完了できる→実装者には依存しない Copyright SHIFT Inc., All Rights Reserved. 27
28. PR作成・レビュー ⑥レビュー・merge ・レビュー用エージェントや 標準のhooksで自動化 ・実装方針mdを用意し レビュー指摘を集積して 反映・更新していく ・ここまでの作業で人の手が介入したのはIssue作成のみ ・Claudeのscheduleで実装コマンドを呼び出しPR作成まで自動化→Codexのhooksでレビュー Copyright SHIFT Inc., All Rights Reserved. 28
29. 改善：実装完了後の仕様同期 ドキュメント例 Spec Review Issue Skills ・実装差分が仕様書に含まれているか確認し自動追加を行う ・最新の仕様書→新たなIssueを作成→… のサイクルを回していく Copyright SHIFT Inc., All Rights Reserved. 29
30. 開発フローのまとめ ①仕様書を用意 ④チケット自動生成 ・要件定義、設計書を投入 ・docsに配置して管理 ・タスク管理ツールAPIで 一括作成 ・メンバーに展開・確認 ➁機能単位で抽出 ⑤実装 「◦◦画面の設計」 ・既存実装の調査 ・タスクの洗い出し 改善！ ・チケット番号を指定して 自動実装〜PR作成 ③Issueに分解 ⑥レビュー・merge ・タスク間の関係性 ・見積もりと完了定義 ・レビュー用エージェント ・docs更新エージェント Copyright SHIFT Inc., All Rights Reserved. 30
31. 個人のふりかえりを加えた最適化の取り組み ここまでに紹介したAIが行う作業や自身が受けたレビューはすべてドキュメント化 →疑問点や自身の弱点を集めたナレッジベースとして管理 ・受けたレビュー指摘を集めて 自分特化レビュー指摘エージェント ・弱点を深堀して技術ブログでアウトプット 標準化→PJや個人の特性に合わせた最適化まで可能に Copyright SHIFT Inc., All Rights Reserved. 31
32. 本運用におけるToken cost メリット ・ドキュメントを参照 →調査にかかるコスト抑制 ・Issue単位で実装方針が明確 →AIとの往復回数を削減 デメリット ・各テンプレートやドキュメントの整備 ・フィードバックサイクル分の Token使用料が発生 設計 実装 従来 ・設計時へコストを前倒し ・設計／Issue分割のコストは一部の担当者へ集約 Issue ・実装担当者は少ないコンテキスト&安価なモデルで開発可能 →Claude Codeにおける「Opusで設計、Sonnetで実装」の思想と同義 組織単位でみれば設計担当者と実装者に付与する契約形態でコスト運用できる可能性 ・Token Costは開発が進むほど減少する Copyright SHIFT Inc., All Rights Reserved. 32
33. 1. なぜIssue駆動開発なのか 2. 遭遇した課題と失敗から得た教訓 3. エンジニアの役割はコード記述から設計デザインへ 4. 実践プロセス 5. まとめ Copyright SHIFT Inc., All Rights Reserved. 33
34. まとめ 1. 標準化の課題 2. Issue駆動開発 3. 標準化の成功 モデルや担当者によって 成果物の品質がばらつく 仕様からIssueへ分解し 完了定義や責務を明確化 仕様同期までをサイクル化し 継続的に品質を向上 Issue駆動開発によって品質の標準化を実現する Copyright SHIFT Inc., All Rights Reserved. 34
35. 仕様・実装・テストが「完全自動同期ループ」する未来 仕様書を更新 Issue分割 エージェント の実装 静的解析 review 人間が「仕様設計」「Issue分割」「レビュー」に集中し 実装はAI主体となる未来 エンジニアが担うのは仕様とIssueの設計品質に基づいて 自律型エージェントを適材適所に配置するハーネスエンジニアリング Copyright SHIFT Inc., All Rights Reserved. 35
36. 明日から始められる3つのこと 1. Issue分割 2. 親子関係の管理 3. 仕様書の更新 単一責任を徹底 子Issueを管理することの できる親Issueの整備 暗黙知や開発ルールを ドキュメントで管理 常に最新化 Copyright SHIFT Inc., All Rights Reserved. 36
37. Issue分解が品質の下限を引き上げる 実装品質の標準化 Copyright SHIFT Inc., All Rights Reserved. 37
38. ご清聴ありがとうございました Copyright SHIFT Inc., All Rights Reserved.