spec-kitとcc-sddの比較所感 v1

spec-kitとcc-sddを個人開発で

前提

いくつかの個人開発プロジェクトにおいて、以下の状況でspec-kitとcc-sddを使ってみた。

現時点では、cc-sddよりややspec-kitの方が好み。とはいえ、cc-sddにもありがたい機能があり、甲乙はつけづらいところ。

コマンドの粒度がcc-sddより細かめで、手動でフェーズを区切りやすい
デフォルトで生成されるドキュメントの種類が豊富で、人間目線でもたすかる
- 特に quickstart.md の存在はありがたい
consitutusion.md によって全体の大方針が作成される
- この内容を納得行くものにしておけば、以降の開発でも大外しはしにくい（外さないとは言わない）
- 逆にいうと、この内容を適当に流すと以降の開発でも「？」となる実装が出されやすい

生成されるドキュメントの場所を指定できない
- <root>/specs で固定。すでに <root>/docs などディレクトリが作ってあると、地味に鬱陶しい
/implements タスクが微妙に使いにくい
- 考えなしに叩くと一気にタスクを進めがち。大きめの仕様だったりするといきなり巨大な変更が積み上がったりする
- 結局、 /implements は使わずに、事前に作成されたタスクファイルを参照させて「Phase2まで進めて」のような指示を別途出しがち

デフォルトで生成されるドキュメントの量がやや少なめ
新規プロジェクトへ導入する場合、「全体の大方針」は別途提示する必要がある
フェーズごとの区切りが細かく厳密であることを謳うが、個人開発だとかえって煩わしい面もある
- セーフティがしっかりしているということなので、メリットではあるのだが、個人開発だと恩恵が少ない

要件・仕様を固めるための前段に対するカバーが、具体的には要求・シナリオレベルのカバーが甘い。最初に雑な仕様を入力しても結構カバーしようとしてくれるが、個人的には物足りなかった。

なので、実際に使う時は以下のような手順を取っている。

カバーが甘い範囲は別途AIとの壁打ちで言語化して、ファイルとして参照可能にしてから使うと結構いい感じ。ファイル内容にはまあまあ重複も発生するが、整理の粒度が違うということで今のところは目をつぶっている。

生成されたドキュメントは基本目を通す。特に要件〜仕様レベルはしっかり目に。タスクレベルのものはフェーズや大項目の粒度だけ見て、詳細は流し見程度にしている
人力レビューできるレベルで実装範囲を区切った上で、コード実装も基本任せている。レビューは人力 + codex・claude・copilotの並行チェック。各AIのGitHub連携を利用
レビュー時、「自分の中で実装イメージはもうあるが、指示を考える方が面倒」と思うレベルは自分で、「イメージはあるが、手を動かす方が面倒」と思うレベルはAIにレビュー対応を任せている
AIのつけたレビューコメントもチェック。内容によっては「対応しない」とマーク代わりにコメントしておいて、AIにも「“対応しない”とコメントしてあるレビューコメント以外に対応して」などと指示するなど
claude code / coex いずれを使うにせよ、 bypassPermissions や full-access を許可することを推奨。ちょっとした操作でもいちいち確認されて、遅々として進まない
- 当然、devcontainerなどを使って安全な環境を確保することが大前提