はじめに
皆さん、こんにちは。
ログラスでエンジニアをしている西代です。
今回は spec-kit を使ってみたことで見えた壁と今後の展望について話したいと思います。
背景
私は新規事業チームでエンジニアをしています。
新規事業での開発で一番求められるのは何でしょうか？
そう、スピードです。
お客様への価値提供サイクルを極限まで早め、高速で仮説検証を回す必要がある新規事業におけるプロダクト開発においてスピードは命といっても過言ではありません。
生成AIの進化により、開発スピードは格段に上がりました。
しかし、単に AI でコードを生成するだけでは、本質的なスピード向上には限界があります。
新規事業のプロダクト開発として一歩先へ進むためにはエージェンティックな開発の可能性を模索する必要がありました。
そこで私が試してみたのが 「仕様駆動開発」と Github が提供する仕様駆動開発のためのツールキットである spec-kit です。
仕様駆動開発とは?
仕様駆動開発とは、コードを書いてからドキュメントを整備するのではなく、最初に spec (仕様) を作成する開発手法です。この spec を正として、AIがコードの生成やテストを行います。これにより、人間の意図と実装の乖離を減らし、コード品質を高めることを目指します。
spec-kit とは？
spec-kit では以下の手順で開発を行います。
- specify
「何を」「どういう意図で」作るかを AI エージェントに伝え詳細な spec を作成します。
ここでは技術的な 「How」 ではなく、ユーザーにどのような体験を提供するのかを記載します。 - plan
specifyで生成した仕様書と、技術スタックなどの制約を元に、AI が技術的な実装計画を作成します。 - tasks
仕様書と実装計画を実際のタスクに分解します。タスクは個別に実装し、テストできる単位である必要があります。 - implement
tasks で生成されたタスクリストを元に AI エージェントがコードを実装します。
tasks フェーズまでで以下のドキュメントが生成されます。
├── spec.md # spec で生成
├── plan.md # plan で生成
├── research.md # plan で生成
├── data-model.md # plan で生成
├── quickstart.md # plan で生成
├── contracts/ # plan で生成
└── tasks.md # tasks で生成
各フェーズにおいて、生成されるドキュメントを AI と対話しながらブラッシュアップしていくことで考慮していなかったエッジケースに気付けたり、人間の意図と実装の乖離を防ぐことができます。
spec-kit によって開発スピードは上がったのか?
結論から言うと、現時点においては開発スピードの向上は感じられませんでした。
確かに spec-kit を用いて開発を行うことで、 AI が生成するコードの品質は上がりました。コードの品質が上がったことにより AI が生成したコードのレビューコストや修正コストは削減できましたし、 tasks まで行なった後は AI に任せられるので、作業の並行度は上がりました。
こう考えると、開発スピードが上がっているはずなのですが、なぜ開発スピードが上がっていないのでしょうか？
原因としては、以下の 2 点が考えられます。
- 各フェーズにおけるアウトプットのレビューコストが高い
-
spec-kitが真価を発揮するタスクが限定的
spec-kit を使って見えた課題と今後の展望
各フェーズにおけるアウトプットのレビューコストが高い
spec-kit を用いて機能を開発すると自前で AI に指示を出すよりも精度の高いものは出ます。
その反面、各フェースで生成されるドキュメントをレビューする必要があります。
specify と tasks のフェーズではそれぞれ 1 つのドキュメントしか生成しませんが、 plan では少なくとも 5 つのドキュメントが生成されます。
そうなると、それぞれのドキュメントの内容を精査し、それらのドキュメントの整合性もレビューしなくてはなりません。
1 つのドキュメントを修正すると、その修正が他のドキュメントと整合性を保っているかもレビューしなくてはならなくなるので、この作業に体感で 1 ~ 2 時間はかかりました。
要するに、ドキュメントのレビューにかけた時間とコードの品質の向上が見合っていないです。
この課題へのアクションとしては以下を検討しています。
- 生成されるドキュメントを絞る
-
quickstart.mdは毎回生成する必要なさそう
-
- 生成されるドキュメントの質を上げる
- ドキュメントのテンプレートの更新 (
/constitutionコマンドを用いる)
- ドキュメントのテンプレートの更新 (
/constitution コマンドについては以下の記事が参考になりました!
spec-kit が真価を発揮するタスクが限定的
- 頭の中で実装の筋道ができているもの
- 頭の中で実装の筋道ができているが、一部検討が必要なもの
- 仕様は整理できているが、どのように実装するかは実装してみないとわからないもの
実際に開発を行なっていると、実装タスクは上記の 3 つに大体分けられると思います。
これらのうち spec-kit での開発の費用対効果に見合うものは 2 の 「頭の中で実装の筋道ができているが、一部検討が必要なもの」であると考えています。
1 の「頭の中で実装の筋道ができているもの」に関しては spec-kit のフローに沿ってドキュメントを生成してレビューしなくても、 Cursor や Claude Code の Plan mode による AI のコミュニケーションで十分に品質の良いコードを生成できます。
3 の「仕様は整理できているが、どのように実装するかは実装してみないとわからないもの」に関しては、plan で実装計画が生成されてもレビューできないので、 AI に任せるには荷が重いと考えています。
そうなると、2 の「頭の中で実装の筋道ができているが、一部検討が必要なもの」が spec-kit での開発に適していることになるわけですが、この難易度の実装タスクはそこまで多くないと感じています。
要するに、spec-kit での開発の費用対効果に見合う実装タスクが少ない ということです。
この課題に関しては、以下のアクションを検討しています。
- 地道にスキルを上げ、3 の難易度から 2 の難易度になる実装タスクを増やす
- 3 の難易度の実装タスクでも壁打ちとして
spec-kitを用いる
まとめ
spec-kit を使うことで仕様駆動開発の強みを実感出来たと同時に課題も感じられました。
課題といっても仕様駆動開発自体の課題というよりも仕様駆動開発をどのように行うかをブラッシュアップしていくという面が強いです。
spec-kit 自体高い頻度で更新されており、最新の変更を取り込みつつ spec-kit のプロンプトのカスタマイズが必要だと考えています。
今後も仕様駆動開発に取り組み開発スピードを上げていきたいと思います。
Discussion