Vibe Codingから仕様駆動開発（SDD）へ。AI時代の開発スタイルを見直しています

こんにちは、合同会社さっしの長澤です。

最近、開発の進め方として 仕様駆動開発（SDD：Specification Driven Development） に注目し、少しずつ開発スタイルをシフトしています。

AIを使った開発は、ここ数年で一気に身近になりました。
弊社でも以前から、CursorのようなAIエディターを使いながら、コードの修正や既存リポジトリの読み解き、ちょっとした機能追加などに活用してきました。

いわゆる Vibe Coding 的な開発です。

「こういう感じで直して」
「この処理を追加して」
「このコードを読んで改善して」

そういった指示に対して、AIがかなりのスピードで実装を進めてくれる。
これは本当に便利ですし、今でも非常に強力な開発手段だと感じています。

一方で、実際に使い続けていく中で、課題も見えてきました。

課題1：大きな開発が進めづらい

AIエディターを使うことで、一部の修正や小さな機能追加はかなり効率化できます。

たとえば、既存コードの一部を修正したり、エラーの原因を調べたり、処理を少し書き換えたりする場合には、かなり相性が良いです。

ただし、大きめの機能開発や、複数の処理が絡む実装になると、だんだん難しくなってきます。

理由はシンプルで、
こちら側の意図や仕様が曖昧なままだと、AIも曖昧なまま実装してしまうからです。

最初は「いい感じに進んでいる」ように見えても、後から見返すと、

「この仕様って、そもそもどう決めたんだっけ？」
「なぜこの処理にしたんだっけ？」
「この分岐は本当に必要だったっけ？」
「画面側とAPI側で前提がズレていない？」

という状態になることがありました。

これはAIの問題というより、
人間側が仕様を明確にできていない状態で、実装だけを先に進めてしまうことの限界だと思っています。

課題2：依頼内容が残りづらい

もう一つ、個人的に大きかったのが、
自分自身が何を依頼したのか分からなくなる問題 です。

AIとのやり取りはスピード感があります。
その場ではテンポよく進みますし、会話しながらコードも変わっていきます。

ただ、その分、

「最初に何を作ろうとしていたのか」
「途中でどう仕様変更したのか」
「なぜこの実装方針にしたのか」

が、後から追いづらくなることがあります。

開発は一度作って終わりではありません。
後から修正することもありますし、別の人が読むこともあります。
そのときに、仕様や判断の背景が残っていないと、保守性が下がってしまいます。

特に弊社では、既存システムの改善や保守運用も多く扱います。
そのため、「とりあえず動く」だけではなく、後から読めること、説明できること、改善し続けられることを大切にしたいと考えています。

仕様駆動開発の導入

そこで最近意識しているのが、仕様駆動開発です。

簡単に言うと、
先に仕様を整理してから、実装に入る開発スタイル です。

いきなりコードを書き始めるのではなく、

「何を作るのか」
「誰が使うのか」
「どの画面で、どの操作をするのか」
「正常系・異常系はどうなるのか」
「データはどう持つのか」
「既存機能への影響はあるのか」

といった内容を、できるだけ先に整理します。

そのうえで、AIにも仕様を渡し、実装方針やタスク分解、コード修正を進めていきます。

これによって、AIに対してもかなり明確な依頼ができるようになります。

「なんとなくいい感じに作って」ではなく、
「この仕様に沿って、この範囲を実装して」と伝えられる。

この違いはかなり大きいです。

仕様を先に決めるのは正直面倒

ただし、仕様駆動開発にも当然デメリットはあります。

一番大きいのは、
実装に入るまでに時間がかかること です。

Vibe Codingのように、気持ちよくすぐコードを書き始めることはできません。

まず考える必要があります。
整理する必要があります。
自分自身が「どうしたいのか」をある程度持っていないと、先に進めません。

もちろん、最初から完璧な仕様を作る必要はないと思っています。
ただ、少なくとも方向性がないと、AIに聞いても良い答えは返ってきません。

AIが便利になればなるほど、逆に人間側の「問いの質」や「判断の軸」が重要になる。
最近はそこを強く感じています。

最終的なスループットを意識する

仕様を先に決めるのは、少し面倒です。
スピード感が落ちたように感じることもあります。

ただ、最終的には手戻りが減るケースが多いのではないかと感じています。

途中で、

「やっぱりこの設計だと無理がある」
「画面側とAPI側の前提が違った」
「実装してみたけど、業務フローに合っていなかった」
「そもそも必要な機能が抜けていた」

ということが減るからです。

特に、大きめの機能開発や、複数人が関わる開発では、仕様があることの価値は大きいです。

仕様があることで、実装者だけでなく、レビューする人、テストする人、後から保守する人にとっても、判断しやすくなります。

Vibe Codingを否定したいわけではない

ここまで書くと、Vibe Codingが悪いように見えるかもしれませんが、まったくそうは思っていません。

むしろ、今後も使います。

小さな修正、調査、コードレビュー、リファクタリング、部分的な実装などでは、Vibe Coding的な進め方は非常に強いです。

たとえば、

・ちょっとした不具合修正
・既存処理の読み解き
・小さなUI修正
・テストコードのたたき台作成
・コードレビューの観点出し
・既存コードの改善案出し

こういった場面では、かなり有効です。

つまり、
Vibe Codingか仕様駆動開発か、どちらか一方を選ぶ話ではないと思っています。

大事なのは、使い分けです。

小さく速く試したいときはVibe Coding。
大きく確実に作りたいときは仕様駆動開発。

このバランスを取ることが、これからのAI時代の開発では重要になると感じています。

弊社が目指したい開発スタイル

AIを使えば、コードを書くスピードは確実に上がります。
ただ、良いプロダクトや良いシステムを作るためには、コードの速さだけでは足りません。

何を作るべきかを考えること。
なぜ作るのかを整理すること。
使う人や運用する人のことを想像すること。
後から保守できる形にすること。

そういった部分は、これからも人間がしっかり向き合う必要があると思っています。

弊社では、AIを単なる自動コード生成ツールとして使うのではなく、
より良い設計や仕様、開発体制を作るためのパートナー として活用していきたいと考えています。

そして、開発者自身もただ実装するだけではなく、
仕様を考え、課題を整理し、より良い進め方を一緒に作っていける存在であってほしいと思っています。