SDDという名前が付く前から、1年やっていた。効いたことと、続かなかったこと

生成AIにコードを書かせる開発が広がるにつれ、「動くけど何をしているか分からない」という沼にハマる開発者が増えている。その対策として「仕様駆動開発」という言葉が浮上してきたが、この記事の面白さは「名前が付く前から実装してた」という実務からの逆算だ。著者はAIに8割のコードを書かせるWordPressプラグイン開発者。半年後に自分のコードが読めなくなり、対策として「完成基準を機械判定できる形にする」「テストを先に置く」「なぜを記す」という3つを握った。これらは全て、AIへの指示を精密にするプロセスが同時に自分の曖昧さを潰すという気づきから生まれている。

AIの鬼の視点で痺れるのは、ここだ。「仕様駆動開発」という綺麗な名前が付くと、どうしても「先に仕様書を完璧に書く」という理想形を想像しがちだ。しかし著者が1年やって残したのは、独立した仕様書ではなく「テストとlintの設定」という強制力を持つもの。仕様書は3か月で化石になるのに、ずれたら落ちるテストだけが勝手に維持される。一人で試作が本番になる世界では、完璧な設計より「記憶の揺れに強い防波堤」の方が実用的だということだ。

中小企業でAIを導入するなら、この判断基準を持つこと。何を作るか、どこまでできたら完成かの2点だけ人間が握り、あとは任せる。ただし維持されるのは文書ではなく、自動で落ちる仕組みだけ。これを先に用意してからAIを投入すれば、半年後に知らないコードの山に埋もれることはない。