SDDについての所感

cc-sddという手軽にSDDを実践できるツールがあり、そちらをプロジェクトで導入し、使ってみたので、現時点での所感をメモしておく。

SDDとは

仕様駆動開発というだけあって、実装の前に明示的に仕様記述を残し、それに沿ってCoding Agentが実装を進めるというもの。これだけ聞くと、これまでも仕様書をexcelに書いてから実装をしていたので、やっていることはそこまで変わらない。

ただ、その過程を我々のプロンプトに従ってAgentが行う、仕様書はコードと同じリポジトリに置かれ、仕様書と実装がセットで管理される点にある。設計→実装のステップを必ず踏むので仕様書と実装の乖離をなくし、死んだ仕様書が生まれにくくなる。

感想

仕様書フェーズ

仕様書すら手書きすることはなくなり、/kiro:spec-requirements コマンドでClaude Codeが作成する。対話形式で詳細に要件をインプットしていき、人間側で考慮から漏れていそうな点などは逐一質問してくれる。要件が固まれば、続けて /kiro:spec-design で技術設計書に展開してくれる。

ここで大事なことは、要件の背景やドメイン知識もセットで伝えること。要件の背景がわからないと、表面的な設計に終始しがちで、余計に時間を使ってしまう。要件→技術的な仕様策定と進むのだが、要件で十分なドメイン知識をインプットできていないと、ソフトウェア設計がかなり微妙なものになる。

イメージ的には、0から設計してもらうんじゃなくて、こちら側の設計イメージを具体化・壁打ちしながら穴を埋めていく作業に近いものを感じた。

例えば、検索条件はほぼ共通で出力フォーマットだけが異なる検索機能を10種類ほど実装する、というケースを考える。画面はそれぞれ分かれており、開発リソースも限られている。

この前提なら、Strategyパターンで共通部分を括り、対象ごとの差分だけ差し替えられるようにするのが素直で、共通化による工数削減も狙える。ところがClaudeから最初に上がってきた設計は対象ごとに個別実装する案で、Strategyパターンの発想は出てこなかった。最終的に僕の方から「ここはStrategyで書けるはず」と提案して設計を整え直した。

つまり、cc-sddは「仕様書を書く労力」はかなり下げてくれるが、設計の良し悪しはエンジニア側に残ったままだ、ということ。ドメイン知識と、それを設計に落とすための手札の両方を持っていないと、Claudeが出してくる素直な案をそのまま受け入れると、むしろ筋の悪い設計に着地してしまう。

実装フェーズ

仕様書ができれば、/kiro:spec-tasks でタスクリストに分解し、/kiro:spec-impl で順次実装まで走らせられる。ここから先、僕はほぼレビュワーに徹している。数行程度の修正やリファクタなら自分で手を入れることもあるが、基本はレビューしながら修正方針をClaudeに投げ返す進め方だ。

困るのは、自分が書いていない大量のコードと向き合う必要があることで、そのコードがちゃんと仕様を満たしているかを把握するのが意外と大変だ。最近は、コード本体よりも先にテストコードを読むようにしている。テストが何を検証しているかを追えば、その実装が何を保証しているのかがわかる。

ということは、コード品質と同じくらいテストコードの品質が大事になる。テストの意図を説明してもらったり、考慮できていないケースを足してもらったりしながら、仕様を満たしていることを確認していく流れが多い。テストが薄いと「動いてはいるけど何を保証しているのか不明」という状態に陥りやすい。

突き詰めると、開発速度のボトルネックはClaudeの実装速度ではなく、人間のレビューに移っている。となると、レビューにかかる時間をいかに減らすかを考えることになるが、ここで効くのがskillsだ。そもそも良いコード・テストを最初から書いてもらえれば、指摘回数を減らせる。なので、最近はテストコード用のskillsを整備している。

あわせて、レビュー観点をある程度定めておくことも重要だと感じる。テストコード、アーキテクチャ、ドメインモデル、Web APIのI/Fなど、見るべき切り口を最初から持っていれば、レビューの漏れが減るし、観点ごとに集中して見られるので一回あたりの判断も早くなる。

はまりどころ

ここまで書いてきた「仕様書を起点に進める」体験そのものは良いのだが、運用面では悩ましいところもある。一番ネックに感じているのは、仕様書類自体の運用コストだ。

まず、どの粒度で仕様書を書くかが難しい。細かすぎると更新時のメンテが追いつかなくなり、いずれ実装と乖離していく。逆に粗すぎるとAgentが解釈に詰まったり、レビューで「この挙動は仕様にあるんだっけ?」と毎回掘り直しが発生する。ちょうどよい粒度は機能の性質や複雑度によって変わるので、案件・機能ごとにチューニングが必要になる。

もう一つは重複だ。同型の機能が増えてくると、共通の前提や制約があちこちのspecに重複して書かれる状態になりやすい。仕様変更が入ったときに全specへの追随漏れが発生しやすい。

このあたりは銀の弾丸はなく、フォーマットを最初に決めて終わり、ではないと思っている。実際に運用しながら「ここは共通のsteeringに切り出す」「このセクションは省略可にする」など、柔軟に最適化していく姿勢が求められる。