Tsumikiとcc-sddの比較

前提

違い

具体的に

Tsumikiは上流工程での指示を元に設計やタスクが進む。要件に対する承認を行うと、その後のゲートキーパーが弱い印象（不正確かもしれない）

cc-sdd：人間 ──[承認]──> AI ──[承認]──> AI ──[承認]──> AI
Tsumiki：人間 ──[委譲]──────────────────────────────> AI（全体）

そのため上流でズレていると、実装までズレが比例関数的に広がり、手戻りが大きくなる可能性がある。

# Tsumiki
要件定義(曖昧) → 設計(ズレ) → タスク(ズレ) → 実装(全滅)
        ↑ここでの品質が全体の品質を決定する

# cc-sdd
スコープA：要件→設計→[人間確認]→タスク→実装 ← ここで閉じる
スコープB：要件→設計→[人間確認]→タスク→実装 ← ここで閉じる
              ↑ スコープ間の整合性は人間が見る

ではcc-sddのほうが良いかというと、そうではない。

例えばゼロイチで要件がしっかり確定しているものや、既存のプロジェクトから導入する場合、全体を把握してそのうえで品質を担保する仕組みとしては筋がよいと感じる。

とはいえ今はAIのガードレールとしてルール整備・人がガードレールとなる必要性がある2026/02現在では、cc-sddのように小さく都度承認を進めていくスコープのほうがサイクルがコンパクトで改善を回しやすいと感じている。

ちなみに、プロセスの管理をcc-sddはjsonで管理しており、この手法がTsumikiよりも好ましく感じている。（.kiro/ というディレクトリで扱っているのは非常に嫌ではある。）