■ 1. 発表の背景と経緯
- 未経験メンバーへタスクを割り当てながら開発を推進し、限られた期間での進捗管理と成果物品質の両立が課題となった
- AI時代のジュニアエンジニアはアウトプットを量産できる一方、その粒度や品質には大きなばらつきがある
- 「何を作るか」よりも「どの単位で仕事を渡すか」が重要であり、タスクの粒度や完了定義が曖昧だと開発効率が下がる
- AIも人と同様に曖昧な指示では期待通りに動きにくいため、開発品質の標準化が必要であり、Issue駆動開発で解決する
■ 2. なぜIssue駆動開発なのか
- 「いきなりAI駆動開発」がもたらす問題:
- 抽象的な指示（「○○機能を実装して」とAIに丸投げ）
- 暴走する実装（不要なリファクタリング、既存実装との乖離）
- 差分の肥大化（実装者・レビュアー共に理解不能なPR）
- コードが書かれる速度は圧倒的に向上したが、検証・修正し、手戻りに対応するコストが最大のボトルネックとなる
- 開発の主戦場は「早く書かせる」から「手戻りなく制御する」へ移行し、開発品質の標準化が必要
- 解決策：SpecからIssue設計に落とし込む
- ソフトウェア開発における「Issue」の定義:
- ビジネス書における「イシュードリブン」（漠然とした「問い」「仮説」）とは別物
- AI開発におけるIssue：AIが迷わず自律実行・完遂できる単位、極小・単一責任かつ明示的なタスク
- 開発者が見慣れた「チケット」（Jira, Backlog, GitHub Projectなど）と同義
- 1〜2日で完了できる単位で、具体的で単一責任、明確な完了定義（DoD）を持つ
- 現場で標準化されていないことが多く、AI駆動開発成功の鍵となる
- Issueだけで開発した場合の問題点:
- AIに起こる現象：既存設計を理解せず実装、局所のみ正しいコード、短期間でのみの解決策
- 発生する問題：全体の整合性が崩壊、コード重複、責務の分散、技術的負債の蓄積
- Issueを満たす局所最適な実装によってシステム全体の整合性が崩壊する
- 解決策：SpecとIssueの「双方向同期」:
- Spec（判断基準、制約、設計原則、一貫性）とIssue（作業境界、実装範囲、完了定義、優先順位）を双方向に同期
- (1) 仕様からIssueを切り出して実装し、(2) 完了したら仕様に反映して最新化するサイクルを繰り返す
- アーキテクチャの一貫性と自律生産性を両立する
■ 3. 遭遇した課題と失敗から得た教訓
- 壁(1) ：変更範囲の肥大化と暴走:
- 原因：曖昧な依頼（完了定義がない、対象ファイルの境界が不明確、影響範囲が未定義）
- 結果：AIが推論を拡大し（関連クラスへの波及、不要なリファクタ、過剰な切り出し）、差分が肥大化
- 影響：何が本質的変更か分からない、想定外の副作用の混入、レビューコストの増大
- 対応策:
- Issueに分割（「散見するロジックの共通化」→「画面コンポーネント」「エラーハンドリング」と単一責任に分解）
- 作業境界を明示（変更可：Service/Repository、変更禁止：認証基盤・共通ライブラリ）
- 完了定義を明示（対象ディレクトリを指定・全テスト成功）
- 壁(2) ：作業の重複とコンフリクト:
- 原因：2つの要件のチケットを別々に並行で処理させたことで重複実装が生じる
- チケット間の関係性や並行制御が不明瞭だとコンフリクトを招く
- 個人で並列実装・メンバーとともに実装のどちらでも起こりうる問題
- 対応策：親Issueが全体設計と共通ルールを握る（目的・スコープ・責務分担・共通ルール・API設計）:
- 親Issueを共有コンテキストとして利用し、単なる管理単位として扱わず子チケットの実装を同期
- 親Issue→設計の一貫性を保持して子Issueを用いた実装の並列化に成功
■ 4. エンジニアの役割の変化：コード記述から設計デザインへ
- レビューの主戦場はIssue設計レビューへ移行する:
- 人間は仕様設計とIssueへの分割に専念（双方向同期デザイナー）
- AIに渡す前に完了定義と作業境界を合意（Issue設計レビュー）
- 完了定義の妥当性、境界線の閉じ方、実装方針を人間同士が事前に議論・合意し、Issue設計時点で不具合の芽を摘む
- これからのエンジニアに求められるもの:
- AIに対して脱線しないためのレールを敷くこと
- プログラミングの知識そのものではなく、システム全体を俯瞰しながら適切に境界を定義する力
- 境界をIssueとして言語化し、メンバーとの合意形成を進めていく力
- 「コードを書く人」から「AIが正しく動く仕組みを設計する人」へ
■ 5. 実践プロセス
- 全体フロー（仕様から実装・mergeまでの作業）:
- (1) 仕様書を用意（要件定義・設計書を投入し、docsに配置して管理）
- (2) 機能単位で抽出（既存実装の調査、タスクの洗い出し）
- (3) Issueに分解（タスク間の関係性、見積もりと完了定義）
- (4) チケット自動生成（タスク管理ツールAPIで一括作成、メンバーに展開・確認）
- (5) 実装（チケット番号を指定して自動実装〜PR作成）
- (6) レビュー・merge（レビュー用エージェント、docs更新エージェント）
- 実践プロセス(1) （仕様書からAI仕様のIssueへ）:
- 洗い出し時に調査してほしい内容はテンプレート化（実装方針、タスクリスト、注意点など）
- 調査で重視したい範囲はAgents.mdやSkillsで指定
- Issueをチケットで管理する:
- タスク管理ツールAPIで一括作成し、ラベルのルールなどPJごとの固有ルールを追加して管理・調整
- チケットをきれいに作成することよりもメンバーと認識齟齬がないか確認することが重要
- Issueの粒度に落とし込んだにもかかわらず「わからない」を避けるための自動化を実現
- 親子チケットで相互リンクで管理し、子チケット実装時にAIエージェントが親チケットを確認するよう制御することで他の子チケットの実装進捗を踏まえた実装が可能になる
- Issueによる実装品質の標準化:
- モデル依存の低減:
- テンプレート化によってAnthropic、OpenAI、Googleなどの差が出にくく、一定品質を維持
- Issueに分解するステップに設計に必要な推論・実装方針を決める指示追従性を切り出すことでモデル性能差の影響を抑制
- メンバー依存の低減：誰が担当しても同じIssueを基に実装するため成果のばらつきを抑制
- Issue分解が品質の下限を引き上げる実装品質の標準化を実現する
- 実践プロセス(2) （Issue→自律実装→仕様同期）:
- /start-work [チケット番号]で明示的に作業を指定し、自動実装〜PR作成まで一貫実行
- コマンド実行後に作業フローを確認し、誤った実装や作業フローがあればコマンド内の指示かチケットの粒度を検証・改善する
- 最終的には自動実行しても問題なく実装完了できる→実装者には依存しない
- PR作成・レビュー:
- レビュー用エージェントや標準のhooksで自動化
- 実装方針mdを用意しレビュー指摘を集積して反映・更新していく
- ここまでの作業で人の手が介入したのはIssue作成のみ
- Claudeのscheduleで実装コマンドを呼び出しPR作成まで自動化→Codexのhooksでレビュー
- 実装完了後の仕様同期:
- 実装差分が仕様書に含まれているか確認し自動追加を行う
- 最新の仕様書→新たなIssueを作成→… のサイクルを継続的に回していく
- 個人のふりかえりを加えた最適化:
- AIが行う作業や自身が受けたレビューはすべてドキュメント化し、ナレッジベースとして管理
- 受けたレビュー指摘を集めて自分特化レビュー指摘エージェントを構築
- 弱点を深堀して技術ブログでアウトプット
- 標準化→PJや個人の特性に合わせた最適化まで可能
■ 6. Token costの考え方
- メリット:
- ドキュメントを参照することで調査にかかるコストを抑制
- Issue単位で実装方針が明確であるためAIとの往復回数を削減
- デメリット:
- 各テンプレートやドキュメントの整備が必要
- フィードバックサイクル分のToken使用料が発生
- コスト構造の変化:
- 設計時へコストを前倒しにする
- 設計/Issue分割のコストは一部の担当者へ集約
- 実装担当者は少ないコンテキスト&安価なモデルで開発可能（Claude Codeにおける「Opusで設計、Sonnetで実装」の思想と同義）
- 組織単位でみれば設計担当者と実装者に付与する契約形態でコスト運用できる可能性
- Token Costは開発が進むほど減少する
■ 7. まとめと将来像
- Issue駆動開発によって品質の標準化を実現する:
- 標準化の課題：モデルや担当者によって成果物の品質がばらつく
- Issue駆動開発：仕様からIssueへ分解し完了定義や責務を明確化する
- 標準化の成功：仕様同期までをサイクル化し継続的に品質を向上させる
- 将来像：仕様・実装・テストが「完全自動同期ループ」する未来:
- フロー：仕様書を更新→Issue分割→エージェントの実装→静的解析/review
- 人間が「仕様設計」「Issue分割」「レビュー」に集中し、実装はAI主体となる
- エンジニアが担うのは仕様とIssueの設計品質に基づいて自律型エージェントを適材適所に配置するハーネスエンジニアリング
- 明日から始められる3つのこと:
- Issue分割（単一責任を徹底）
- 親子関係の管理（子Issueを管理することのできる親Issueの整備）
- 仕様書の更新（暗黙知や開発ルールをドキュメントで管理し、常に最新化）