Atusy's blogせっかくClaude CodeのようなAIエージェントを導入したなら、できるだけほったらかしで成果を出したいものだ。しかしAIに複雑な機能を開発させたら明後日の方向に進むリスクはまだまだ高い。
それを防ぐ方法の一つが仕様駆動開発（Spec Driven Development）とかテスト駆動開発（Test Driven Development）なんだろうなと思う。私の理解するメリットをあげると、
- 仕様駆動開発は仕様を満たすようにタスクを細分化し、明確と集中可能なコンテキストを提供する
- テスト駆動開発は完了条件をテスト化し、コンテキストが複雑化したとしてもゴールだけは明瞭に保つ
といったところだろうか。
人間からしたら別に新しいことではない。ここまでしても方向性を違えてきたところすら、新規性がない。
- 最初に仕様を決めきろうとするが、決めきれるほど単純な要求ばかりではなく、理解の不足や誤りが仕様を汚染する
- 仮に正しく仕様を決めたとして、作業可能なレベルに細分化したタスクが、Specのどの位置に存在するかを見失う
- 仕様があいまいであれば、なにをテストすべきか見えない
その結果、このタスクってなにを目指してたんだっけ、わからないけど、聞く相手もいないし、進めよう。できた。え、求めてたのと違う？なんて悲しい結末を繰り返してきた。
この課題に対してスクラムの知見を導入したAI特化型スクラム「Agentic Scrum」を検証しているので紹介したい。スクラムガイドや実際のスクラム開発の経験をベースに、AI開発での私の経験を加味した手法だ。
Agentic Scrumで開発の方向性をぶれにくくする
AIを使った開発はコンテキスト（文脈）の扱いとの戦いだ。仕様駆動開発はコンテキストの複雑化を予防し、テスト駆動開発は複雑化しやすいコンテキストの中で正しい状態を維持する。
しかし、コンテキストの理解不足やコンテキストの肥大化との戦いに不足を感じる。
- コンテキストを正しく構築できれば理想の仕様ができるし、正しくテストすべきことも見える
- コンテキストサイズが適正なら仕様を維持できる
スクラムでこれらの問題に挑んでみよう。スクラムは有名なフレームワークだからAIも理解しやすい。
スクラムの課題整理術が仕様駆動開発を補完する
アジャイルとかスクラムが導入された背景の一部は、まさにこの問題に立ち向かうためだ。
特にスクラムはやりたいこととやることの整理がうまく設計されている。
- やりたいことの整理（Product Backlog Refinement）
- 「○○として、△△ができる。それは××のためだ」というUser Story形式のProduct Backlog Item（PBI）を使い、機能追加がどんな価値をもたらすかを明確にする
- 仕様を決めきれないようなPBIであれば、分割する。分割するときは優先度に応じて並べかえられるよう独立で、どこからやってもユーザーに価値をもたらすPBIにする
- PBIの優先順位を価値の大きさや仕様の決めやすさに応じて見直す
- 直近でやることの整理（Sprint Planning）
- 優先度の高いPBIをやることに決める
- PBI達成に必要な開発項目を洗い出す
- 開発項目単体で価値を出す必要はない
小さくとも価値があり着手可能なやりたいことから進めていけば、方向性は見失いにくいし、進め方のわからないやりたいこともプロジェクトの進行と共に理解が深まっていく。というのも、価値を築いていく過程で、我々は技術的な成長とドメイン知識の獲得が進むからだ。
Spec Driven Developmentでは最初に仕様を決めようとした。スクラムを導入すれば決められるところから決めていける。
Spec Driven Developmentではタスクを作業の独立性の観点から一度に細分化した。スクラムを導入すればタスクを価値の独立性の観点から細分化した上で、作業の独立性の観点でも細分化できる。
迷いが減る。
スクラムの検査術がテスト駆動開発を補完する
テスト駆動開発もすごくスクラムっぽいことを言っている。テストが書ける、つまりわかるところからやってけと。
スクラムは価値の観点を優先順位に加えているところが秀逸だ。
双方を意識すると、頭を悩ませがちな結合テストやE2Eテストみたいなテストサイズの大きなものについて、何をテストすべきか、1つの指標を与えてくれる。
つまり、単体テストより大きいところで必須なテストは「PBIが目的とする価値を実現できているかテストする」ことだ。
もちろん他にE2Eテストや結合テストを実装してもいいが、それは価値というよりリファクタしやすい保守性の観点だろう。
価値の検証方法がわかれば、迷っても立ち返る場所ができる。
Agentic Scrumを構築する
スクラム万歳！と言いたいところだが、おそらくスクラムをAIに最適化する必要がある。
たとえばスクラムは一定期間（1スプリント）ごとに進捗を検査するスプリントレビューがある。ここにはステークホルダーを呼んで、完成したPBIを見せてフィードバックをもらう。しかし、AIにスプリントごとに止まってもらうのは無駄だ。人を介さず進められるところまで何スプリントでも進めてもらって、止まったところでレビューしたほうがいい。
そのためには、Product Backlog Itemの優先順位の決めかたもかわるだろう。人だったら次のリリースで検証したい市場価値は何かを考えて、関連するPBIは優先度を高めにする。多少、わからないことがあっても、探索的に着手しスプリント期間満了と共に振り返って方向性を調整する。しかし、AIは時間の制約がないために、不明点に延々と取り組み、方向性のずれを大きくするリスクがある。 AIが単独でやれるPBIをとにかく高優先に設定し、人が必要なPBIは後回しにするのがよいだろう。
Product Backlog Itemの整理（Product Backlog Refinement）は、とにかく次のスプリントプランニングを着手可能にしておくことが目標だ。いつ行ってもいいが、人を集める性質上、週1回などの定期開催が多い。定期開催といっても、スプリントの切れ間で開催する方針にすると、タイムボックスの制限でスプリントプランニングを着手可能にできない恐れがある。だから、スプリントサイクルの途中で定期開催しつつ、必要に応じて追加開催するのがよいだろう。しかし、AIにとっては途中で余計な作業を挟む必然性はないし、タイムボックスを守る必要もない。だから、スプリントの切れ目で行うとよいだろう。
人のスプリントはタイムボックスがあるため、その間で完了できる複数のPBIを目標にする。しかし、AIにタイムボックスは不要だ。いっそプロダクトバックログリファインメントやスプリントレトロスペクティブの頻度を上げて、適応性を高めたほうがよいかもしれない。すなわち1スプリント1PBI完了を目標にするのがいいだろう。
こんな感じで、スクラムの各要素をAIに最適化していこうとしている。
ENJOY!
AIエージェントをできるだけほったらかしにして、適切な方向性を維持しつつ開発を進めたいと思ってAgentic Scrumを構築中だ。
取り組みにはちょっと成果が出ていて、何度やってもうまくいかなかったAI駆動個人開発が急速に前進するようになった。
そのあたりはまた別の記事にするつもりだ。