ほんとそれ。

ああ、セカンドシステム効果とそこから学んだ教訓だね。

よく引用されるけど、実際に厳密に正しいのか疑問だな。「機能する」の定義を合理的に考えた場合ね。機械工学では確実に当てはまらないよ。

みんなこれを誤解して、物置から超高層ビルを段階的に作れると思ってるんだよね。

ここで重要なのは「ゼロから」という部分だと思う。通常、新しい（2番目、3番目、何でも）システムを古いものに置き換えるとき、前の設計の良い部分と悪い部分を考慮に入れるから、もはやゼロからではないんだ。それが成功を可能にするんだよ（少なくとも私の経験では、たいてい成功した）。

このコメントを追加するためにここに来たよ。 https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

一部のシステムは、その複雑さに完全にコミットする必要がある。単純な形ではうまく機能しないこともあるからね。多くの文脈において、「システム思考」は、より単純なサブシステムに還元できないシステムの設計について明示的に述べられていることが多い。時には、全てを受け入れなければならないこともあるよ。いくつかのタイプのソフトウェアでは、運用プロトタイプを構築するコストが、実際のコードを書くコストに漸近的に収束する現象もあるんだ。（これは、プロトタイプを構築することで納品リスクが大幅に減少すると思っている管理職に説明するのがいつも楽しいことだよ。）

オープンソースプロジェクトが、仕様に完全に依存するようになるのを想像できる これは本当に良い観察だね、君の予測は当たると思う。これにはSaaSに対する影響がある。お金を節約するためにvibecodeが必要な例のSaaSを想像できる。今それが不可能な理由は、Claudeができないからではなく、君が提案したように、正しい仕様を得るのが大変だからだ。よく書かれた仕様は、そのソフトウェアのドメインにおけるベストプラクティスだけでなく、法的なコンプライアンスの面倒くさいことも含まれている。適切なモジュール化された仕様があれば、もっとvibecodedなSaaSが見られるようになると思う。全体的に、君の予測は本当に強いと思う。

これに関するアイデアに興味がある。仕様のための異なるコンパクトなDSLを考えたことがあるけど、構造化されていないもの（ファイル固有の所有権の境界を超えた）は、私にはうまく機能している。

アイスバーグは、主に仕様だよ[0]。どんなデータが保存され、どのようにやり取りされるかを正確に定義している。コミュニティはまず仕様変更について広く議論する。最近のクロスプラットフォームSQL UDFについてのものを見てみて[1]。まだ大規模なLLM駆動の言語実装は見ていないけど、確かに可能だと思う。LLMにJavaの実装を必要な言語に翻訳するように指示する方が簡単だろう。vibe-codedな言語は、企業のデータに大きなダメージを与える可能性がある。[0] https://iceberg.apache.org/spec/ [1] https://lists.apache.org/thread/whbgoc325o99vm4b599f0g1owhgw...

ここにはテンプレートやマクロライブラリに関する考え方の類似点がある。一つの問題は、動作する参照実装がない仕様は、成功裏にコンパイルされたことのないプルリクエストと本質的に同じだということ。一般化は良いけど、結局のところ実際にやってみることからは逃れられない。C++のテンプレートでこの問題に直面したことがある。以前にテストされていない型をテンプレートに投げると、新しい面白い方法で壊れることがある。

ウェブを出発点として見ることができるよ: https://html.spec.whatwg.org/#history-2 > WHATWGは、いくつかのコア原則に基づいていて、(..) 仕様は、実装が互いにリバースエンジニアリングなしで完全な相互運用性を達成できるほど詳細である必要がある。だけど、私の経験では、仕様以上のものが必要だよ。実装は単に仕様を実装するものではなく、仕様がどのように実装されるかに関する多くのアーキテクチャ的選択の結果でもあるからね。それに、詳細な仕様があってもAIは追加の指導が必要なんだ。例えば、数週間前にCursorがウェブ標準と共有WPTテストスイートにアクセスできる何千ものエージェントを解き放ったけど、その結果は全くの無意味だった。だから、未来はむしろ仕様のロシアの人形のようになるかもしれない。高レベルのシステム記述から始めて、システムの各部分のより詳細な仕様でサポートする。これがコード自体にまで及ぶこともある。既存のアーキテクチャパターンは、そうしたパターンのバリエーションとして機能をコーディングするための仕様を提供する。だから、システムが新しいことをする必要があるときは、そのためのコードパターンを提供しなければならない。AIはその強みに relegated されるんだ。既存のパターンを適用することにね。TLA+にはリファインメントの概念があって、これは私が上で説明したロシアの人形のようなものだけど、TLA+の仕様にのみ適用される。ここにそのアイデアを説明する引用があるよ: 仕様と実装の間に根本的な区別はない。私たちは単に仕様を持っていて、その中には他の仕様を実装するものもある。JavaプログラムはJVM（Java Virtual Machine）プログラムの仕様と見なすことができ、これはアセンブリ言語プログラムの仕様と見なすことができ、これはコンピュータの機械命令の実行の仕様と見なすことができ、これはレジスタ転送レベル設計の実行の仕様と見なすことができる、という感じだよ。出典: https://cseweb.ucsd.edu/classes/sp05/cse128/ （第1章、最後のページ）

100%。知らない分野から新しいことを学ぼうと思ってここに来たけど、代わりに小さなイテレーションと大きな設計についてのコメントを見つけて、ちょっと退屈だなと思った。

「コードを書くこと」は仕事の中で最も簡単な部分の一つだ。難しいのは、どのコードを書く必要があるかを知ることだ。この考えには大いに賛同するよ。私の意見では、これが大規模な事前設計がリスクが高い理由だ。

そうだね、でも2000ページの仕様書を書いた2年後の統合テストでは、実際にはうまくいかないんだよね。アーキテクトから開発者に渡されて。

事前に全ての複雑さを考慮した大規模な仕様を作成してから、それを実装する。> そんなことは一度も起こったことがないし、これからも起こらないよ。君は全知全能じゃないからね。全てを把握できるほど賢くても、要件は常に変わる。私はこの記事に出てくる「戦いの傷を持つ20年以上のベテラン」の一人で、現在は多国籍企業の大規模プロジェクトに取り組んでいる。そこでは、全てを事前に指定し、JIRAで計画し、見積もりを出し、次のマイルストーンの契約を結ぶ前にガントチャートを設定する必要がある。このプロジェクトに18ヶ月取り組んできたけど、予期しない問題や最後の瞬間の変更、不完全な仕様のせいでマイルストーンが順調に進んだことはゼロ回だよ。こうした厳格な構造の中で納品しなければならないエンジニアたちには頭痛の種が増えていて、今や管理側もそれに気づいて、上層部にもっとアジャイルで反復的なアプローチが必要だと説得しようとしている。事前の仕様がソフトウェアの複雑さの全ての解決策だと主張する人は、実際の経験がないか、実際のエンジニアリングから遠く離れていて、何を話しているのかわからないんだと思う。

多くのソフトウェア関係の人はすぐに飛び込むのが好きで、計画を立てる人たちを最初に全てを把握しようとしているように描写するのをよく見るよ。私のアプローチは、特に多くの未知があるプロジェクトの場合、すぐに飛び込んでプロトタイプを作ろうとすることだ。その後、数回イテレーションを重ねる。もし小さなものであれば、数回のイテレーションで良い結果が得られる。もしもっと大きなものであれば、ここで計画を立てる価値が出てくる。多くの問題がすでに浮き彫りになっていて、問題がはるかに良く理解されているから。

ベント・フリューブイェルグの本「How Big Things Get Done」は、このスレッドで挙げられた懸念にしっかり答えてくれてるよ。ここで答えて、あちこちに返信を散らかさないようにするね。

でも、飛び込む前に良い計画を立てることには価値があると思う。特に、_良い_計画に重点を置いてね。ほとんどの「計画」はひどくて、その名前に値しない。 事前に明確にして、JIRAで計画するのは良いアプローチだね。仕様はその計画の一部であるべきだし、実行中に必要に応じて適応する準備は必要だけど、変更を避けるために仕様を良くする努力も大事だよ。ただし、君が言った「事前の仕様」は、計画を立てる前に書かれた可能性が高いから、それは悪いアプローチだね。それは「計画」と呼ばれる何かの一部として書かれたもので、実際の計画とは関係ない。そうなると、その仕様は完全にフィクションだよ。 提供された見積もり もしこのプロジェクトが特別でない限り、見積もりもフィクションだと思うよ。 ガントチャートの設定 ガントチャートはモデルであって、計画ではない。モデルは良いもので、プロジェクトに対する洞察を与えてくれる。でも、モデルを計画と混同しちゃいけない。計画を立てるために必要な小さな断片の一つに過ぎないし、ガントチャートは計画を立てるために必要な多くのモデルの一つに過ぎない。 次のマイルストーンの契約にサインする前に それは良いことだね。契約にサインするのは取り返しのつかない決定だから。計画が終わる前にサインすべき契約は、プランナーを雇うための契約だけだよ。 事前の仕様が解決策だと主張する人 さっきの話を見てみて。堅固な事前の仕様は通常、計画ではなく、純粋なフィクションだよ。 特に多くの未知があるプロジェクトの場合、私のアプローチはすぐに飛び込んでプロトタイプを作ることだね。これを計画と呼ぶか「飛び込む」と呼ぶかは用語の違いで、アプローチの違いではない。重要なのは、問題を理解するために実験しているけど、取り返しのつかない決定はしていないことだよ。この本の用語を使うと、君は_計画_しているのであって、_実行_しているわけじゃない。 2000ページの仕様書が書かれ、建築家から開発者に渡された後 もし2000ページの仕様が書かれている間に開発者に渡されていなかったら、それは計画の一部ではなく、純粋なフィクションだよ。その仕様に基づいてソフトウェアを開発しようとするのは計画の一部だね。

PRINCE2とSSADMを見てみてほしいな。あるいは、元のロイスの論文を読んでみて - https://www.praxisframework.org/files/royce1970.pdf は、このアンチパターンを「ウォーターフォール」と明示的に呼ぶために書かれたものだよ。（ロイスはこれをアンチパターンとしてマークしていることに注意してね。）このことについては、https://www.ebiester.com/agile/2023/04/22/what-agile-alterna... で少し話したけど、方法の歴史についても触れているよ。今やこの議論はほぼ70年続いているんだ。グレース・ホッパーやジョン・モークリーがUNIVACプログラムについて議論していたのは間違いないよ。

こんなことはこれまで一度も起こったことがないし、これからも起こらないだろう。君は全知全能ではないからね。たとえ君がすべてを理解するのに十分賢くても、要件は変わってしまうよ。私の今までのベストプロジェクトは、主にウォーターフォール型のもので、A4の仕様書が50〜60ページくらいあった。その多くをクライアントと一緒に作成したんだ。すべての計画と同様に、実施中に多くのことが変わったけど、同じ機能を実装する方法を見つけて、約15ページ分を削減する自動化を実現したよ。さらに、実際にコードを書き始める頃には、必要な回答が必要だった質問のほとんどがすでに出ていて解決できていたし、ドメインが技術にどう変換されるかについてのエッジケースも知っていたから、全体の仕組みや見た目も分かっていたんだ。これに対して、プロジェクトに参加して手伝うように頼まれ、進行中の開発の真っ只中に飛び込むと、特定のシステムやチームが過去数週間や数ヶ月間に焦点を当てていたさまざまなことについてあまり知らないことが多いよね。 もし彼らが本当に大きなシステムをいくつか持っていたら、彼らの問題の多くは消えてしまうだろうというのは簡単に想像できるよね。データ、セキュリティ、運用、品質、アクセスの間の不整合は、すべての切り離されたプロジェクトで大きかったんだ。あるシステムは最新だったけど、別のシステムは古くて、うまく機能しているものもあれば、ほとんど機能していないものもあった。システムが少なくなれば、自ら引き起こした問題の多くは消えてしまうだろうね。また、これを思い出させるのが https://calpaterson.com/bank-python.html 特にこの部分： バーバラには複数の「リング」、つまり名前空間があるけど、デフォルトのリングは銀行全体の単一のグローバルオブジェクトデータベースに近いものだ。デフォルトのリングからは、取引データや楽器データ（上記のように）、市場データなどを引き出すことができる。日常的に使用される

その通り - これが良いアジャイルが目指すところなんだ。ユーザー向けの機能を可能な限り小さいサイズで実装すること（これも重要）。この二つがあれば、問題や質問を最速のフィードバックループで特定できる。実際、「大きなイテレーション」は、著者が言及する全ての問題が最初に現れるところだと主張できるよ！