背景 / 課題
AI並行開発は、タスクが増えるほど「どこに向かってるか」がすぐ分からなくなる。 その結果、作るために作るようなビルドトラップに落ちやすい。 この時のボトルネックは実装速度というより 人間の意思決定なので、そこを最適化すべき。 前提・決定・影響範囲が散逸する問題を、スクラムのメタファーで解決する。
取り組んだこと
-
前提: Issueベースの並行開発で、Claude Codeなどが独立して作業できるワークフロー組めている前提。
/fix {issueNum}で、Claude Codeが「PR作成 → CIを通す → レビュー指摘対応」まで走れるようにしてる- Cursorの
/plan {repository}で、Issue作成・クリティカルパス分析・並行できるIssueツリー作成までできるようにしてる /session-retrospectiveで、Claude Codeが自分のセッションログを分析して、要約と改善案を出力できるようにしてる
-
新たに
/planを「全Issueを集めて、特定のゴールに向けて進めるスプリント親Issueを生成」できるようにした- 目的: ゴールと達成条件を固定し、Issueをリンクできる スプリント親Issue（コンテキスト集約点） を運用の中心に据える
- 親Issueには Goal / Not in sprint / DoD / Lanes（並行開発プラン）を定義する
- 子Issueは親に紐付け、共有すべきコンテキストは親に集約する
- 1スプリントを Plan → Status → Retro の反復として扱う（運用・コマンドもそこに揃える）
-
新たに
/retroで、各セッション分析から「Issueにすべき改善」を峻別して起票するようにした -
まだ運用していないが、状況更新する
/statusコマンド追加したので、親イシューベースの情報更新試す。
実装・設定のポイント
1) 途中の状況共有を「親Issueコメント」に一本化
- 「〜のイシューが完了した」「追加の観点が出た」「衝突しそう」「次これやって」みたいな情報を、親Issueにだけ積む。
- 子Issue側は
Parent sprint: #...の最小リンクで貼り、必要に応じて親Issueから情報をpullさせる
2) レトロは“改善を増やす”のではなく“峻別する”
- Enablement（仕組み化/ルール整備）は無限に増やせる。
- だから、毎回 1〜3件に絞る前提でレトロを回す。
3) 要件定義をしっかりする
- 顧客とのコミュニケーションは全てMeetで録画し、NotebookLMなどでテキスト化して議事録に落とす（Issue化できる状態にする）
- こうすることで「既存仕様はリポジトリに」「今後の仕様はIssueに」「根拠となる新規議事録もリポジトリに」という状態が作れる
成果
だいたい、1日に4〜5Issueを解決するスプリントが2〜3回ほど回せる感じ。 ツールや環境もどんどん改善して、エージェントもどんどん賢くなるので、改善がサチってきたらXとかで情報集める暇もできる。
受託案件側
10Issueほどクローズ
vive(自分で作ってる並行開発ツール)
- 軽微な修正のIssueを2件ほどクローズ
dotfiles側（Cursor運用の更新）
- 並行スプリント運用に合わせて、Cursorのルール/コマンドを更新してコミットした。
学び / 次のアクション
- 並行開発の辛さってタスクが多いじゃなくて、コンテキストスイッチが多すぎてどこへ向かってるか分からなくなること
- とにかく並行で進めるのが目的ではなく、特定の方向へ進めるうえで“脳が把握しながら同時に進められるもの”を選ぶのが大事
- バラバラのIssueを特定の観点でまとめて、スプリントゴールを決め、並行開発できるプランを練ってから始める
- このゴールとプラン自体もAIと擦り合わせることで、並行開発を把握できるし、コミュニケーションの土台になる
- 親Issueは共有メモリ的に使える
- ある種PMとして、自分がどこに向かっているかを把握できている状態に、工数を適切に使うべき
- 振り返りで改善点を発見し、そのうち重要度が高いものを並行で改善していく
- これがあることで、気になったことをすぐ始めちゃってこんがらがるというのがなくなる