毎度の事ながら定義が曖昧なまま議論が進んでいきますね。 とりあえずこの辺↓を読んで、定義を認識合わせした方が良さそう https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
"OpenAPIのスキーマだって、最初は自動生成していたのに途中から手で直し始めて、気づいたらスキーマとコードが別々に進化しているなんてことは珍しくないです。" さすがにこれはないなー
「仕様は使い捨て」は理想だけど、結局コードを仕様として読めるレベルに保つのが一番の無理ゲーな件。AI時代はプロンプトが「生きた仕様書」になっていくんだろうな
残すべき3つがまさに仕様書じゃん…。
Whyはコメントに書くべきではあるが、何でもかんでもコードに残すと人間もLLMも読めないから 判断の道筋はdocsディレクトリーに残しておいて、判断に困った時にLLMに読ませて一緒に考える位が良いかもね
プログラムが得意ではないけど、文章を書くのは得意なので、日本語で欲しいものを細かく定義して、実現可能な仕様書を書けばプログラムがその通りに出来上がってくるのはとても楽しい。
仕様駆動開発は、AIのコンテキスト制御の話で、"仕様"が目的だと勘違いする輩が出るから、名前よくないって指摘が既にされてて、まんまの事態になりましたという感想です。/ spec=仕様って訳て日本ではさらにねじれ
コードとテストがあれば、それが仕様書というのは一部であり、それだけでなんとかならないケースもある。
「でも、実装が終わった時点で、仕様書の内容は100%コードに反映されているはずです。反映されていなかったら、それはバグです」考えが甘い（笑）後になって「バグなのか仕様なのか」を確認することが普通にある。
いまのCodexは10万行程度のコードベースなら聞けば秒で仕様をコードから教えてくれるので、仕様書はさっさと捨てるに限る
「なぜそうしたのか」がコード外に残すべき情報、というのは自分も長年、思っていることなんだけど、IT 土建業の底辺にいると、偉い人にはそれが分からんのです、という絶望しかない。
仕様駆動開発の話は、どの仕様駆動の話なのかや、ツールを使った狭義の話なのか概論の話なのかなど、前提を整理してからでないと議論にならないので
SIerとは違う世界の話だよね。実装仕様の大半が不要なのは分かるが、業務仕様は無いと困る。業務仕様は文書化して、客先調整と実装に使うし。GUI以降、実装仕様をいかに軽くするかは色々考えられたと思う。
理念は分かるけれど「よし仕様書は捨てよう！」と踏ん切りがつかない。３人チームで要件定義から納品まで半年とかでお試し業務システム開発を仕様書なし縛りで回しきって得られた知見を共有して！よろちゃん！
元記事、そもそも論じるに値するレベルの記事じゃない、ただの日記。あれを起点に語るべきではない
AIに任せても入り口出口はずっと揃ったままになるの？
仕様書の価値は、なぜそうなったのかの過程が書いてあることの比重が結構大きい。コメントだと全体見れてなかったりするのよ。最近はコードFixしたごとにAIに仕様書更新させる運用なんじゃないの?
自分もまだ答えないのだけど人間の理解用として仕様書があったほうがよさそうと思ってる。コードと仕様書のズレは逆にAI開発だから同期出来るのでは。コーディング後に必ずドキュメントも修正させるようにするから。
うーん、確かに言われてみると仕様書なんて捨てた方がよさそうですね。メンテの手間にメリットが見合っていません。仕様書を直す余裕があるならコメントを直した方が良さそうです
なんか時代が… AIが発達して人間が退化した？
コードで表現できることはドキュメントに書かなくていいけど、逆を言えばコードで表現できないかするべきでないことはドキュメントに書かないといけないんじゃないの？みんなの得意な責務の話でしょ
これ系の話は前提条件が食い違ってるのでほとんど意味がない
こんなに簡単に仕様書が生成できるようになったのに、そのメリットを捨てる必要ないと思うけどなー。作業に取りかかる前に、まず仕様書を読みながら AI に最新のコードと同期してもらうのがいいと思う。
不変性の高い情報は外部文章に、可変性の高い情報は書かないかどうしても必要ならコードの内部、近いところに書くのが基本。「なぜそうしたのか」は不変性が高いのでドキュメント化する価値が高い。
僕のやってる仕様書駆動開発は、修正単位でその変更の意図や方針等を仕様書にまとめるところからスタートする。いらない派の人の話は包括的な仕様書とコードをリンクさせるような話になってて❔が浮かんでた。
ドリフト起きるからコードを正とするってのは分かるんだけどそれだとどうやってテストするのって問題がねぇ
最近SDDを触って自分がほしいのは適宜更新される仕様書ではなくADR何だなって気づいた
プロダクトのフェーズとかそこに集まってる人のコンテキストによる。一人でガンガンPoCするなら要らないし、既に大規模で不具合を消火するフェーズならあったほうがいい
多分、プロダクトの期待する挙動との不一致と、仕様としての考慮漏れ、AIの実装コードへの評価がすべてバグで表現されていて読みにくい。
肉じゃがのレシピでいろいろやってるうちにカレーになってしまったが元のレシピは捨ててしまった… まぁいいか
不要論はSDDをうまく使えなかったという相性問題しか根拠になっていない気がする。SDDの定義にもよるかもしれないけど、とにかくコンテキストに全部乗せようとするのはたとえ1Mコンテキストでも間違っているのは確実。
受け入れテストをしないユーザー。開発者ではなく。こういう人たちの言う「開発」とは発注のことで、「仕様」とは要求のこと。AIは人間の代替だとよく分かる。
仕様駆動開発(SDD)って、本当に不要なの？
毎度の事ながら定義が曖昧なまま議論が進んでいきますね。 とりあえずこの辺↓を読んで、定義を認識合わせした方が良さそう https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
"OpenAPIのスキーマだって、最初は自動生成していたのに途中から手で直し始めて、気づいたらスキーマとコードが別々に進化しているなんてことは珍しくないです。" さすがにこれはないなー
「仕様は使い捨て」は理想だけど、結局コードを仕様として読めるレベルに保つのが一番の無理ゲーな件。AI時代はプロンプトが「生きた仕様書」になっていくんだろうな
残すべき3つがまさに仕様書じゃん…。
Whyはコメントに書くべきではあるが、何でもかんでもコードに残すと人間もLLMも読めないから 判断の道筋はdocsディレクトリーに残しておいて、判断に困った時にLLMに読ませて一緒に考える位が良いかもね
プログラムが得意ではないけど、文章を書くのは得意なので、日本語で欲しいものを細かく定義して、実現可能な仕様書を書けばプログラムがその通りに出来上がってくるのはとても楽しい。
仕様駆動開発は、AIのコンテキスト制御の話で、"仕様"が目的だと勘違いする輩が出るから、名前よくないって指摘が既にされてて、まんまの事態になりましたという感想です。/ spec=仕様って訳て日本ではさらにねじれ
コードとテストがあれば、それが仕様書というのは一部であり、それだけでなんとかならないケースもある。
「でも、実装が終わった時点で、仕様書の内容は100%コードに反映されているはずです。反映されていなかったら、それはバグです」考えが甘い（笑）後になって「バグなのか仕様なのか」を確認することが普通にある。
いまのCodexは10万行程度のコードベースなら聞けば秒で仕様をコードから教えてくれるので、仕様書はさっさと捨てるに限る
「なぜそうしたのか」がコード外に残すべき情報、というのは自分も長年、思っていることなんだけど、IT 土建業の底辺にいると、偉い人にはそれが分からんのです、という絶望しかない。
仕様駆動開発の話は、どの仕様駆動の話なのかや、ツールを使った狭義の話なのか概論の話なのかなど、前提を整理してからでないと議論にならないので
SIerとは違う世界の話だよね。実装仕様の大半が不要なのは分かるが、業務仕様は無いと困る。業務仕様は文書化して、客先調整と実装に使うし。GUI以降、実装仕様をいかに軽くするかは色々考えられたと思う。
理念は分かるけれど「よし仕様書は捨てよう！」と踏ん切りがつかない。３人チームで要件定義から納品まで半年とかでお試し業務システム開発を仕様書なし縛りで回しきって得られた知見を共有して！よろちゃん！
元記事、そもそも論じるに値するレベルの記事じゃない、ただの日記。あれを起点に語るべきではない
AIに任せても入り口出口はずっと揃ったままになるの？
仕様書の価値は、なぜそうなったのかの過程が書いてあることの比重が結構大きい。コメントだと全体見れてなかったりするのよ。最近はコードFixしたごとにAIに仕様書更新させる運用なんじゃないの?
自分もまだ答えないのだけど人間の理解用として仕様書があったほうがよさそうと思ってる。コードと仕様書のズレは逆にAI開発だから同期出来るのでは。コーディング後に必ずドキュメントも修正させるようにするから。
うーん、確かに言われてみると仕様書なんて捨てた方がよさそうですね。メンテの手間にメリットが見合っていません。仕様書を直す余裕があるならコメントを直した方が良さそうです
なんか時代が… AIが発達して人間が退化した？
コードで表現できることはドキュメントに書かなくていいけど、逆を言えばコードで表現できないかするべきでないことはドキュメントに書かないといけないんじゃないの？みんなの得意な責務の話でしょ
これ系の話は前提条件が食い違ってるのでほとんど意味がない
こんなに簡単に仕様書が生成できるようになったのに、そのメリットを捨てる必要ないと思うけどなー。作業に取りかかる前に、まず仕様書を読みながら AI に最新のコードと同期してもらうのがいいと思う。
不変性の高い情報は外部文章に、可変性の高い情報は書かないかどうしても必要ならコードの内部、近いところに書くのが基本。「なぜそうしたのか」は不変性が高いのでドキュメント化する価値が高い。
僕のやってる仕様書駆動開発は、修正単位でその変更の意図や方針等を仕様書にまとめるところからスタートする。いらない派の人の話は包括的な仕様書とコードをリンクさせるような話になってて❔が浮かんでた。
ドリフト起きるからコードを正とするってのは分かるんだけどそれだとどうやってテストするのって問題がねぇ
最近SDDを触って自分がほしいのは適宜更新される仕様書ではなくADR何だなって気づいた
プロダクトのフェーズとかそこに集まってる人のコンテキストによる。一人でガンガンPoCするなら要らないし、既に大規模で不具合を消火するフェーズならあったほうがいい
多分、プロダクトの期待する挙動との不一致と、仕様としての考慮漏れ、AIの実装コードへの評価がすべてバグで表現されていて読みにくい。
肉じゃがのレシピでいろいろやってるうちにカレーになってしまったが元のレシピは捨ててしまった… まぁいいか
不要論はSDDをうまく使えなかったという相性問題しか根拠になっていない気がする。SDDの定義にもよるかもしれないけど、とにかくコンテキストに全部乗せようとするのはたとえ1Mコンテキストでも間違っているのは確実。
受け入れテストをしないユーザー。開発者ではなく。こういう人たちの言う「開発」とは発注のことで、「仕様」とは要求のこと。AIは人間の代替だとよく分かる。