分かりみが深い。確か「文章を書くように」と設計されたCOBOLが意外とAI時代は相性良かったりして（笑）
SDDを、SSoT -> Code の順で作ると思っているからおかしくなる。Spec は、commit できる Plan-mode だ。技術面の SSoT は ADR とか、各フェイズの最後に整合させる。今後はSDD + E2E が無いと修正,レビューで律速になる
ここで「ぴゅう太」の日本語ベーシックですよ🤔
全体のドキュメントは欲しいけど、機能単位は要らないよね
計画⇒実装⇒検証 の順番にすすめる。仕様は計画に含める 何を作るか決めないと何もできない
SSDのドキュメントは意思決定した内容のみの最小限に留める努力が必要なんでは？AI目線でコードだけだと絶対変えられない仕様というのがわからんし。詳細にドキュメント詰め過ぎたらただの二重定義
結局ドキュメントが腐るのはAI時代も同じか。盆栽いじってる方がマシってのは草
コードだけ置いて説明の無い技術ブログとか溢れてるけどあれはやめてほしい。ドキュメント不要論の勘違い。
コードを読めばわかる人のみの職場ならいいのでは？他人どころか将来の自分がコードを読んで「よくわからん…」となる可能性もあるから、自然言語で読みやすいドキュメントが必要なわけで。
アーキテクチャの全体図の話でIaCの話をする人の意見が参考になるとは思えない。
わかる。仕様をAIに書かせると必要最低限なドキュメントにならんし、綺麗なだけで可読性もほどほど。最初に作業計画とテストで作って、ドキュメントは最後、が今のところ満足いく。
どの範囲でいらないという話かよくわからんが、人間がテストしないで完成にする前提なの？
仕様駆動開発、いつのまにか狭義の意味での仕様駆動開発のことを指す言葉になっており、使うのがめんどくさい言葉になっている感があり
関係者全員がコードを読めるならね
これは "使っている側" がたどり着く境地
作りすぎてもだめだしまったくないのも困るのでトレードオフかなぁ。
｢ドキュメント修正の実行が確率的｣と｢仕様がわからんくなったらclaudeに聞けばいい｣は矛盾していない?あと､ビジネス要件を開発者以外の他者と協議しない環境?
ドキュメント作らないで済む規模感の開発なら作らないでいいんじゃない？0-1で仕様駆動はメリット薄そう。本番は10-100フェーズでしょ
そう、これは1人で早くなってるだけ。チームはどうだ。 チームも使ってたら良いのか という話になるが…じゃあ振る舞いを決定する.md次第だろうな。プロジェクトごとの.mdではあるが、グローバルの.mdの話しね
いまは壁打ちから Issue を起こさせて、実装計画とコードレビューは文書で残させてるけど、人が書いたストーリーから Spec を書かせて、人がレビューした Spec から Issue を起こさせるようにしようとしてるとこ。
どういうスケールかによると思うのだが,,,, ウチレベル. (ec2のmicroのinstanceだとbuild後なら普通に動くし, まぁ軽いSaaSレベルとか,ゲームのサーバー) ぐらいならdoc/code両方あった方が楽な印象よ？docないと意図がわからん
Spec-first で仕様ドキュメントを先に書いておいてそれを使って開発を Steering し、実装終わったらドキュメントは削除してる
コード（集合）から仕様を生成してビジネスレビューできれば問題はない。問題はそこまでの品質のものはまだみたことはないので、これからかなと思うけど。
仕様書駆動とか言ってるから勘違いしている気がする。kiroとか使ってみると分かるけど、この記事に書いてある内容とは大きく違う
よくわからないが、仕様書ならそうだと思うが、AIの文脈では設計書駆動開発なんじゃないかな。データ構造とかパラメータ表とかそう言う資料は要るはず。そう言うのソース見ろってなんだかでしょう。
お客様との合意はどうやってるんですかね。この手の話はプロダクトのオーナーとかお客様の話が出てこないんだよな。
チームや後任のことを無視すればそれでいいのでは。まあベンチャーって書いてあるし後のことは考えずに好きなようにして出ていくんだろけど。
どれくらいの規模の開発について書いているのかわからん。開発に関わる人数によって必要なドキュメント量も質も変わってくる話で、ソースコードだけで十分なのが通じるのはかなり限定される。
仕様かて駆動
要求仕様書(人間がメンテして人とAIが読む)、コード解説書(AIがメンテして人が読む)に分ける。そしてコード解説書はコードに従属し、コードは要求仕様書に従属する、というルールはどうだろう。
数式を使わずに数学をやりたいニーズは分かるけど、それは本当に数学なの？っていう感じ。
技術スタックを分離して書いておけば移植やフレームワークの移行が容易なのではと思うけどコードから生成すればいいのか。十分な精度でできればまぁなんでもいいのかな。
Claudeに聞けばいいって言うけど、それだと聞いたことしか教えてくれないよね。AIがあれば本はいらない、みたいな話だと思うなー。全体を概観して忘れてたことに気づかせてもらうには、仕様書が要ると思う
ADRは残しておかないと人間が後で困る
ややこしい仕様が絡む部分だけ、コードにコメントで書くだけ。外部のビジネス的事情をmdで書いてる
実装のドキュメントを仕様と言ってる謎の定義 なぜドキュメントを自動生成する方向にはいかないんだ
PRDとADRにstatusを付けて残すだけで良いという結論に達した。specとplanは更新し続けることが困難なので、Issue等に残してそのときだけ利用する。
仕様書は作業指示書ではないぞ。動作は必ずしもコードに現れない。
コードでわかることが仕様だと思ってるの？「仕様駆動開発」の例をいくつか見てきたけど、すべて要求をAIに伝えてるだけだった。つまり、ユーザーが開発者ぶってるだけなんだよね。
「API一覧とかコンポーネント一覧みたいなのがあった方がいい？」って聞いたら「ファイル見たら分かるから別にいらんよ」と言われたな。「外部仕様は分からんから書いといて」とも言われた。実際その通りだと思う。
外部設計どころか内部設計書（を更に作業指示にしたもの）のことを言ってる？？要求仕様書とかを見たことない人が使うワードなんだろうか。
"コメントやdocsrtingをドキュメントに含めるとおっしゃるならばビジネス要件に関してはドキュメントが必要" / 情報としては間違いなくいるんだし、どこに書くかの議論をしてもなぁ。あと客に見せる事考えてる？
仕様駆動開発は止めた方がええ／仕様駆動開発早めた方がええ ドキュメントがないってのは、料理の見た目だけで味を判断しろってのと同じやろ。
一人開発ならいいんじゃね? ちゃんとサービスチームに引き継ぎする気があるならドキュメントちゃんと作れや
タイトルと中身が違う気がする。「ドキュメント作成をやめた方がいい」ではないか？
ほなら実装が常に正なわけでテストも不要よな。
みんなの言う「仕様」が指す範囲が全然違うので埒が明かない
開発者が要件をコントロールできるなら良いかもだけど、業務システムでは権限やら顧客やら状況の条件での要件が多いし、それをまとめての機能設計はどうしても必要。となると仕様駆動になるでしょう感
要求駆動開発が好きです
タイトルと書いてあることが違う気がする・・・まぁ少人数で同じメンバーでずっと開発するならそのやり方で良いんじゃないかな。
仕様駆動開発はやめた方がええ
分かりみが深い。確か「文章を書くように」と設計されたCOBOLが意外とAI時代は相性良かったりして（笑）
SDDを、SSoT -> Code の順で作ると思っているからおかしくなる。Spec は、commit できる Plan-mode だ。技術面の SSoT は ADR とか、各フェイズの最後に整合させる。今後はSDD + E2E が無いと修正,レビューで律速になる
ここで「ぴゅう太」の日本語ベーシックですよ🤔
全体のドキュメントは欲しいけど、機能単位は要らないよね
計画⇒実装⇒検証 の順番にすすめる。仕様は計画に含める 何を作るか決めないと何もできない
SSDのドキュメントは意思決定した内容のみの最小限に留める努力が必要なんでは？AI目線でコードだけだと絶対変えられない仕様というのがわからんし。詳細にドキュメント詰め過ぎたらただの二重定義
結局ドキュメントが腐るのはAI時代も同じか。盆栽いじってる方がマシってのは草
コードだけ置いて説明の無い技術ブログとか溢れてるけどあれはやめてほしい。ドキュメント不要論の勘違い。
コードを読めばわかる人のみの職場ならいいのでは？他人どころか将来の自分がコードを読んで「よくわからん…」となる可能性もあるから、自然言語で読みやすいドキュメントが必要なわけで。
アーキテクチャの全体図の話でIaCの話をする人の意見が参考になるとは思えない。
わかる。仕様をAIに書かせると必要最低限なドキュメントにならんし、綺麗なだけで可読性もほどほど。最初に作業計画とテストで作って、ドキュメントは最後、が今のところ満足いく。
どの範囲でいらないという話かよくわからんが、人間がテストしないで完成にする前提なの？
仕様駆動開発、いつのまにか狭義の意味での仕様駆動開発のことを指す言葉になっており、使うのがめんどくさい言葉になっている感があり
関係者全員がコードを読めるならね
これは "使っている側" がたどり着く境地
作りすぎてもだめだしまったくないのも困るのでトレードオフかなぁ。
｢ドキュメント修正の実行が確率的｣と｢仕様がわからんくなったらclaudeに聞けばいい｣は矛盾していない?あと､ビジネス要件を開発者以外の他者と協議しない環境?
ドキュメント作らないで済む規模感の開発なら作らないでいいんじゃない？0-1で仕様駆動はメリット薄そう。本番は10-100フェーズでしょ
そう、これは1人で早くなってるだけ。チームはどうだ。 チームも使ってたら良いのか という話になるが…じゃあ振る舞いを決定する.md次第だろうな。プロジェクトごとの.mdではあるが、グローバルの.mdの話しね
いまは壁打ちから Issue を起こさせて、実装計画とコードレビューは文書で残させてるけど、人が書いたストーリーから Spec を書かせて、人がレビューした Spec から Issue を起こさせるようにしようとしてるとこ。
どういうスケールかによると思うのだが,,,, ウチレベル. (ec2のmicroのinstanceだとbuild後なら普通に動くし, まぁ軽いSaaSレベルとか,ゲームのサーバー) ぐらいならdoc/code両方あった方が楽な印象よ？docないと意図がわからん
Spec-first で仕様ドキュメントを先に書いておいてそれを使って開発を Steering し、実装終わったらドキュメントは削除してる
コード（集合）から仕様を生成してビジネスレビューできれば問題はない。問題はそこまでの品質のものはまだみたことはないので、これからかなと思うけど。
仕様書駆動とか言ってるから勘違いしている気がする。kiroとか使ってみると分かるけど、この記事に書いてある内容とは大きく違う
よくわからないが、仕様書ならそうだと思うが、AIの文脈では設計書駆動開発なんじゃないかな。データ構造とかパラメータ表とかそう言う資料は要るはず。そう言うのソース見ろってなんだかでしょう。
お客様との合意はどうやってるんですかね。この手の話はプロダクトのオーナーとかお客様の話が出てこないんだよな。
チームや後任のことを無視すればそれでいいのでは。まあベンチャーって書いてあるし後のことは考えずに好きなようにして出ていくんだろけど。
どれくらいの規模の開発について書いているのかわからん。開発に関わる人数によって必要なドキュメント量も質も変わってくる話で、ソースコードだけで十分なのが通じるのはかなり限定される。
仕様かて駆動
要求仕様書(人間がメンテして人とAIが読む)、コード解説書(AIがメンテして人が読む)に分ける。そしてコード解説書はコードに従属し、コードは要求仕様書に従属する、というルールはどうだろう。
数式を使わずに数学をやりたいニーズは分かるけど、それは本当に数学なの？っていう感じ。
技術スタックを分離して書いておけば移植やフレームワークの移行が容易なのではと思うけどコードから生成すればいいのか。十分な精度でできればまぁなんでもいいのかな。
Claudeに聞けばいいって言うけど、それだと聞いたことしか教えてくれないよね。AIがあれば本はいらない、みたいな話だと思うなー。全体を概観して忘れてたことに気づかせてもらうには、仕様書が要ると思う
ADRは残しておかないと人間が後で困る
ややこしい仕様が絡む部分だけ、コードにコメントで書くだけ。外部のビジネス的事情をmdで書いてる
実装のドキュメントを仕様と言ってる謎の定義 なぜドキュメントを自動生成する方向にはいかないんだ
PRDとADRにstatusを付けて残すだけで良いという結論に達した。specとplanは更新し続けることが困難なので、Issue等に残してそのときだけ利用する。
仕様書は作業指示書ではないぞ。動作は必ずしもコードに現れない。
コードでわかることが仕様だと思ってるの？「仕様駆動開発」の例をいくつか見てきたけど、すべて要求をAIに伝えてるだけだった。つまり、ユーザーが開発者ぶってるだけなんだよね。
「API一覧とかコンポーネント一覧みたいなのがあった方がいい？」って聞いたら「ファイル見たら分かるから別にいらんよ」と言われたな。「外部仕様は分からんから書いといて」とも言われた。実際その通りだと思う。
外部設計どころか内部設計書（を更に作業指示にしたもの）のことを言ってる？？要求仕様書とかを見たことない人が使うワードなんだろうか。
"コメントやdocsrtingをドキュメントに含めるとおっしゃるならばビジネス要件に関してはドキュメントが必要" / 情報としては間違いなくいるんだし、どこに書くかの議論をしてもなぁ。あと客に見せる事考えてる？
仕様駆動開発は止めた方がええ／仕様駆動開発早めた方がええ ドキュメントがないってのは、料理の見た目だけで味を判断しろってのと同じやろ。
一人開発ならいいんじゃね? ちゃんとサービスチームに引き継ぎする気があるならドキュメントちゃんと作れや
タイトルと中身が違う気がする。「ドキュメント作成をやめた方がいい」ではないか？
ほなら実装が常に正なわけでテストも不要よな。
みんなの言う「仕様」が指す範囲が全然違うので埒が明かない
開発者が要件をコントロールできるなら良いかもだけど、業務システムでは権限やら顧客やら状況の条件での要件が多いし、それをまとめての機能設計はどうしても必要。となると仕様駆動になるでしょう感
要求駆動開発が好きです
タイトルと書いてあることが違う気がする・・・まぁ少人数で同じメンバーでずっと開発するならそのやり方で良いんじゃないかな。