ソフトウェアの信頼性をどのようにして確保したらいいのかという議論がされ始めた時、そのお手本を建築設計に求めたと思います。
オランダのダイクストラが”Structured Programming”（日本語訳「構造化プログラミング」）を提唱したのは1960年代のことです。
彼のなんと言う本だったか、私も買ってかじりつきましたが、記号論理学や数学基礎論等を使って色々な証明をしていました。せいぜい200ページ程度の本でしたが、私には難しくて最後まで読むことができませんでした。
それはともかく、ダイクストラがどの程度建築設計の方法論を意識したかは知りませんが、少なくともタイトルに建築を想起させる「構造化」という用語を使用したのは、象徴的であったと思います。
建築設計は数千年の歴史をもちます。建築設計の方法論は古くて新しい議論です。
通常、建築では施主からの要求条件が出されると、まずエスキース（スケッチ）という段階で基本的な案を練ります。次の段階は基本設計です。建物の基本的な配置や形状が決定されます。続いて詳細設計で必要な詳細図を書きます。更に工事にかかると、実施図を書き、これを見て職人が仕事をします。建築設計では、設計の後戻りはありえません（もちろん現実にはあるが、それはあってはいけないことです）。
ソフトウェア設計の研究者は、このような建築設計の諸段階も研究したと思います。開発手法として最初期に提案された手法は、建築の設計手法と同じく後戻りしない手法で、後にこれをウォーターフォールといっています（建築設計とソフトウェア開発では、何かの違いがあると思います。ウォーターフォールの欠点が指摘され、最近のアジャイル開発まで様々な提案があります）。
またオブジェクト指向プログラミングの時代になって、デザインパターンの提唱がなされましたが、この原案は建築家のクリストファー・アレキサンダーがやはり1960年代に提唱したものです。
建築もソフトウェアもゼロから「もの」を作る創造の世界です。
似たところが沢山あります。しかし、決定的に異なる部分があります。建築設計は視覚的です。設計図も図面という視覚的な媒体を使いますし、建築そのものも視覚的です（もちろん物的、空間的です）。ソフトウェアはIDEを通して視覚化できますが、それはソフトウェアの一側面を表示しているだけです。ソフトウェアの本質はロジックで、基本的には設計者（あるいはプログラマ）の頭脳の中で構築していきます。
建築設計での図面のミスは、ベテランの技術者であれば、即座に指摘することができます。
しかしソフトウェアでミスを見つけることは大変難しい作業です。
人間の視覚によるパターン認識は、ロジックによる認識の何十倍何百倍も強烈です。そこに建築設計とソフトウェア開発の根源的な差異があるのだと思います。
建築の方法論では、たぶんに恣意的な面があり、人によってその解釈に差異が生じます。デザインパターンは建築の分野では、話としては分かるが広く明快に理解され、普及したわけではありません。
その点ソフトウェアのデザインパターンは、明確に定義づけられ、それなりに役立つ手法になっています。
