おい、要件を動くものにしろ - じゃあ、おうちで学べる

はじめに ドキュメントは、書いた瞬間から腐っていく。 読まれない。検証されない。更新されない。それでも、要件と呼ばれ続けている。 第1部では、要件を言葉にする規律について書きました。引き出し、観察し、ジョブを見極めながら、業務領域の言葉で書く。6つの特性を満たし、検証可能な形にする。揺らぎと固執を組み込んで、自分たちの色を要件に乗せる。 そこまでやって、初めて要件文が立ち上がります。ただ、立ち上がっただけでは足りないのだと、最近は思うようになりました。 第1部で扱ったのは「書かれずに死ぬ要件」でした。第2部で扱うのは、もう一段先の死、書かれたのに読まれずに死ぬ要件です。気づいたときには、ドキュメントと現場のあいだに、もう橋が架かっていない。 syu-m-5151.hatenablog.com 要件は、ドキュメントで生きるのではなく、動くものとして生きる必要があるのではないか——というのが、

[syu-m-5151]

書きました。GWに読んで欲しいです。要件はあくまで要件であり要望ではないので検証して更新しないといけないのですよ⋯？

[hanagesan]

基本この人の話は冗長で長い。上司に長いと詰められたことがないのだろう

[otihateten3510]

読みにくい、話を絞るべきだ　◯個のHogeHogeが多すぎる　要所要所で共感はできるんだけど

[jintrick]

色んな苦労にぶち当たってきた経験が滲み出てる貴重な文章。"動くものに散らされた要件" これを適切に、楽に管理できたらいいなー。じっくり読もう

[hogetax]

（本筋じゃないけど）個人開発だからプロンプト見せ合うって発想がなかったわ。面白そうだな

[yarumato]

“「要件」と「仕様」と「契約」は、何が違うのか。3つは別物です。仕様駆動開発を語る人の多くは、この3つを混ぜて使っています。　AIに実装を任せるとき、Type Firstで、型から書き始める”

[morimarii]

たぶん仕様や要件じゃなくてコンテキストの話をしているというか、AIにコーディングさせると結局コンテキストに行き着く。。。

[avaravax]

参考にはなるが、たしかに長い。ドメイン知識の構造化に触れているが、この記事も構造化できないものか？

[moke222]

全部詰め込もうとすると長くなるよね

[hetoheto]

おい、と言うのが苦手すぎる

[wwolf]

冗長過ぎる

[mmaka2787]

エクセル関数の頃からSSTは関数と思っていた。問題は関数は一目で理解できても何百何千行のコードでは無理なこと。しかし、今やLLMがものの数十秒でそれらを理解して自然言語にも翻訳する。文書の意味が変わった。

[kompiro]

なんか「屏風に書いた虎を動かせ」みたいなタイトルだ

[chaoschk]

要件である「機能」を,どのような構造で実現するかの「設計」の定義が曖昧だった。記事で「仕様」「契約」と呼んでるものは、詳細実装仕様に思えた。「要件を曖昧にしない」のは◎。 「要件」に「設計」も含めてそう

[isrc]

最近の仕様駆動開発の文脈では、仕様はバージョン管理可能で、人間が読める、AIエージェントを動かすための制御手段／ドキュメントという媒体そのものに、毎日読まれ続けるための仕組みが備わっていない

[gcyn]

『気づいたときには、ドキュメントと現場のあいだに、もう橋が架かっていない』 人間同士の「合意」って何なのか、それはなぜ軽んじる前提で進むのか、みたいなことがあまり再確認されないのが社会ってものなのかな

[mak_in]

要件が腐るから更新とかってのは真面目なウォーターフォールならやってる。アジャイルにも真面目なのとなんちゃっての品質の差があるように、ウォーターフォールもピンキリ。ウォーターフォールの上澄みで観た既視感

[kenzy_n]

要件を聞こうか・・・・・。

[nguyen-oi]

要件定義は腐るという真理。動くコードと検証プロセスに焼き込むのは現代開発の正解だな

[turanukimaru]

私にとって動作する要件とは自動テストのコードのことなのだが自動テストを維持できる人は少ないのと自動テストを維持することを評価する組織が少なくてな。挙動とかは文章よりテストコード見る方が分かりやすいのに

[uehaj]

要件の表現をドキュメントかコードではコードなのだが、コードでの焼き込み方に真髄があると