背景 / 課題
AI並行開発は、タスクが増えるほど「どこに向かってるか」がすぐ分からなくなる。 その結果、作るために作るようなビルドトラップに落ちやすい。 この時のボトルネックは実装速度というより 人間の意思決定なので、そこを最適化すべき。 前提・決定・影響範囲が散逸する問題を、スクラムのメタファーで解決する。
取り組んだこと
-
前提: Issueベースの並行開発で、Claude Codeなどが独立して作業できるワークフロー組めている前提。
/fix {issueNum}で、Claude Codeが「PR作成 → CIを通す → レビュー指摘対応」まで走れるようにしてる- Cursor の
/plan {repository}で、Issue作成・クリティカルパス分析・並行できるIssueツリー作成までできるようにしてる /session-retrospectiveで、Claude Codeが自分のセッションログを分析して、要約と改善案を出力できるようにしてる
-
新たに
/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運用の更新）
学び / 次のアクション
- 並行開発の辛さってタスクが多いじゃなくて、コンテキストスイッチが多すぎてどこへ向かってるか分からなくなること
- とにかく並行で進めるのが目的ではなく、特定の方向へ進めるうえで“脳が把握しながら同時に進められるもの”を選ぶのが大事
- バラバラのIssueを特定の観点でまとめて、スプリントゴールを決め、並行開発できるプランを練ってから始める
- 振り返りで改善点を発見し、そのうち重要度が高いものを並行で改善していく
- これがあることで、気になったことをすぐ始めちゃってこんがらがるというのがなくなる