Kilo や Spec Kit の仕様駆動開発とは仕様・実行計画・タスクリストを生成してくれて、それを人がレビューしつつ進めるという方法。
Kilo は少しだけだが Spec Kit は20時間くらい触ってみている（偉い）
利用してみた感じは
- AIの出力が冗長であったり、意図を伝えるための対話回数が多い
- 出力結果を得られるまでの時間がかかるのと、レビュー負荷が高い
AIとは関係ない話だがソフトウェア開発の歴史の話をすると
- 古い開発現場だとウォーターフォール開発、仕様第一でソースコードと対になる仕様書を常にメンテしていて、組織も上流/下流で分かれていた（上流の仕様を書く人はプログラムが書けないことも）
- Google ではアジャイル開発、ソースコードが仕様で機能追加するときにDesign Docを作る、組織も上流/下流とかないソフトウェアエンジニア
上記に対して
- 個人的なキャリアでいうと前者も後者も経験があるが、仕様書を常にメンテするのは本当に大変だったので、Design Doc は感動した思い出がある。
- 前者に該当する環境のひとはAIの仕様駆動開発はフィットするのかなと思う。一方で後者に該当する環境のひとはそんなに課題にも思ってないのかなと思う。
- 仕様・実行計画・タスクリストみたいなステップについても、仕様を書くときに実行計画やタスクリストの粒度で詳細設計を書くようにしているので、手続きが面倒に感じる
という感じで、個人開発や仕事で活かせるポイントを毎晩見い出せずに寝落ちして、朝の通勤時間で Gemini に整理をしてもらってモチベーションを支えてもらっていた。
1.仕様駆動開発に対する評価
- 肯定的な評価（メリット）
- 網羅性と品質向上: AIがエッジケースを含めてタスクを網羅的に洗い出すため、開発者の考慮漏れを防ぎ、成果物の品質を高める。
- 手戻りの削減: 開発初期段階で仕様を詳細に固めるため、後工程での大規模な手戻りを防ぐ。
- チームの認識統一: 詳細なドキュメントが生成されることで、チーム内の認識齟齬が減り、コミュニケーションが円滑になる。
- 否定的な評価（デメリット）
- 冗長性とオーバーヘッド: 必要以上に詳細な出力の確認・修正に時間がかかり、「AIのための作業」が発生することがある。
- 柔軟性の課題: 事前に計画を固めるため、仕様変更への追従コストが高くなる可能性がある。
- 対話コスト: AIが文脈を完全に理解できず、意図通りの出力を得るために何度もやり取りが必要になる場合がある。
2.「オーバーヘッド」は大規模プロジェクトでメリットになるか？
- 一見デメリットに見える「冗長性やオーバーヘッド」は、大規模プロジェクトにおいては「巨大な手戻りコストを防ぐための戦略的な初期投資」と見なせるため、結果的にメリットとなり得る。
- リスク低減: 初期段階で仕様の曖昧さをなくすことで、プロジェクト終盤での致命的な不具合発覚を防ぐ。
- コミュニケーション円滑化: 詳細なドキュメントが、大人数が関わるプロジェクトでの「共通言語」として機能し、認識のズレをなくす。
- 品質の標準化: 属人化しがちな品質を、AIによる網羅的なチェックで底上げする。
というような感じでプロジェクトや組織は選ぶのかなと思っている。それでもまだ可能性としてあるなと思ったのは
- Design Doc を採用している Google が仕様駆動開発っぽいツールを出したら、それは気にな
- Spec Kit のテンプレートを既存プロセスにカスタマイズ出来るので試しても良いのかもしれない
- ただ既存プロセスでそこまで時間はかかってない気もしていて、もっと支配的、圧縮率の高いことを優先する方が良いかなと思う