SDDもそうだけど、トレーサビリティや整合性を持ち込むのも個人的にはイマイチなソリューションだと感じている 確かに、トレーサビリティという概念を持ち込めばSDDの課題を解決したうえで開発ができる、という発想は合理的に感じるし、実際に仕組み化できるのは素晴らしいことだと思う なので、これはあくまでも、個人の一意見としてツールを批判するものでは全くないということは留意していただきたい SDD with トレーサビリティは要件定義書・基本設計・詳細設計・実装・コミット・ブランチ名・PR・etcとトレーサビリティを担保しないといけない範囲が明らかに大きすぎる 成果物が増えるほど、それらを結び付け、更新し続けたり、整合性をチェックするための仕組みや、保守し続けるという管理コストがかかる これだけでも、SDD関連のSkillとトレーサビリティのSkillやSubagensなど、どれくらい必要になるのだろうか 最終的には、ソフトウェアを作るためではなく、トレーサビリティを維持するための開発になっても不思議ではないだろう 私はSDD自体が悪いとは思っていない ただし、開発全体を一つの巨大な仕様体系で覆うのではなく、何を仕様の中心にするかを決め、その周辺だけを小さく整合させるべきだと思っている 私の場合、その中心に置くのがREADMEだ READMEやチュートリアルを実装より先に書き、利用者がどのように機能を使うのかを具体化する そこからAPIや内部設計を考えることで、人間は完成形を理解でき、エージェントも「何を実装し、何を確認すれば完成なのか」という基準を持てる 私が最近行っているのは、このREADME駆動開発と、/grill-with-docsを組み合わせる方法だ ・READMEにユーザーの利用方法を記載する ・/grill-with-docsでREADMEから内部設計を作成する → 合わせてADRとドメイン用語集を残す ・READMEに記載されたユーザーの利用方法を検証する → 実装後に、pstackの/create-verification-skillでfeature mapと検証skillを作成し、検証する ・READMEに、利用者がどのように機能を使うのかを書く ・/grill-with-docsでREADMEの内容を掘り下げ、内部設計を作る → この時に、ADR、プロジェクト固有の言葉をドメイン用語集に残す ・実装後に、READMEに書いた使い方が本当に成立するかを検証する ・検証にはpstackの/create-verification-skillで作られる検証Skillを利用する → feature mapと検証Skillを作り、繰り返し検証できる形にする すべての成果物をトレーサビリティでつなぐのではなく、READMEに書かれた利用者の体験を起点に、設計、実装、検証をつなぐ READMEを外側の契約、/grill-with-docs を内側の設計、検証Skillを完成条件にする これにより理解負債も蓄積されずに、検証も付けられ、最低限のレビューで開発を進められている