私は、ソフトウェア技術者が「設計は終わったけれど、文書はまだ全然書いていないよ」と言うのをよく聞く。これはまったく意味をなさない。建築家が「君の新しい家の設計は終わったけれど、図面はまだまったく描いていないよ」と言っている、あるいは、小説家が「小説が完成したけれど、まだ何にも書いていないよ」と言っているのを想像できるだろうか。設計とは、選択し抽象化し、そしてその結果としての適切な基本構造とアルゴリズムを、紙かその他の媒体に記録することである。
（２０１の鉄則：原理６４＜設計の原理＝文書のない設計は設計とは言わない＞）
ここには、２つの問題が潜んでいます。一つは、設計書なるものを書かないでソースを書くことの問題で、もう一つは、設計書というものの書き方や内容の問題です。
プロジェクトのスケジュールに「設計」あるいは「設計工程」という文字が書かれていないことは無いと言っても過言ではありません。つまり、ソフトウェアの開発、とくに新規の開発にあたっては、「設計」という行為が不可欠だということには、ほとんどの人の同意が得られているのです。しかしながら、現実問題として、しっかりした設計書を目にすることは稀なこともまた事実なのです。
原理６４の指摘は、設計書というものを事前に書かないで「設計」が終わっているというのはおかしいと言うものです。それは図面もないのに、家の設計が終わりましたと言っているのと同じで、あなたはそんな建築士や工務店の提案を受け入れますか？という問い掛けです。もちろん、そんな提案を了承するはずはありません。でも、ソフトウェアの世界では、それがまかりと通っています。
外注のソフトハウスの場合、「設計書」の納品が求められていますので、設計書を書かないというわけには行きません。その結果、実装も終わって、テストも終わってから、“納品のために”設計書を書くということが行われます。いわゆる「後付けの設計書」というやつです。言うまでもなく、この種のドキュメントは内容的にも構成的にも参照性能が低く、利用価値も乏しい物となってしまいます。外注のソフトハウスが、このような「後付け」の文書を納品するのを防ぐ方法は、作業の進捗を追跡し、成果物ができ上がった時点で納品させることです。
それに対して自社の設計部門の場合は、「設計書」が強い約束になっていないこともあって、このような「後付け」の設計書が書かれることは、むしろ稀で、どちらかというと、原理６４のように何も書かれない方が多いものと思われます。
一方、「設計書」と名のつく文書は書けているが、その内容が設計書になっていないと言うこともしばしば見掛けます。その殆どは、詳細な仕様の記述に終始していて、肝心の「設計」部分が見当たらないというものです。確かに、設計作業に入るためには、そこで為されるべき詳細な仕様が明らかになっていることが条件です。「システム設計」に対してシステムの「要求仕様」があるように、「タスク（コンポーネント）設計」に対して、「タスク（コンポーネント）仕様」が必要です。しかしながら、「仕様」はやはり仕様であって、「設計」の代役は勤まりません。１冊の「○○タスク設計書」の中に混じることは構いませんが、明確に分かれていなければなりません。
そのような事態になる最大の理由は、「設計書」というものに何を書くのかが分からないことにあると思われます。「設計書」には、そこで実現することが求められている「仕様」を実現するための「基本構造（アーキテクチャ）」が書かれます。また必要に応じてその背景となる「アルゴリズム」も書くことがあります。言い換えれば、それらの「仕様」を“このような構造と役割分担で実現します”というのが「設計」です。
家の設計も同じです。お客さんの要求（一般に過大な要求）を整理し、それを実現するためにこのような間取りや仕掛けを考えました、というのが設計です。もちろん、仕様の中には相互に矛盾するものがありますので、それらは事前に調整し承諾を得なければなりません。そのことは、ソフトウェアの世界でも同じです。
それでは「設計書」というものはどのように書かれていれば良いのかとなると、少々難しい問題になります。要求仕様書の方は、ある程度の範囲に収まるのですが、設計書は、許容範囲が広く、判断が難しところです。もちろん、フル装備の設計書であれば、どのような場面でも通用しますが、現実問題として、要員は限られており、そのうえ納期に追われている状態で、それを求めることは無理ですし、今日の状況では、無駄なく的確な作業をするかが問われます。また、ビジュアル系の言語の発達も、設計書の存在を希薄にする原因になっています。
そこで、私が勧めている方法は、実装（コーディング）の生産性で判断する方法です。設計書が要件を満たしているのなら、その後の実装の作業が滞ることなく進むはずで、いわゆるコーディングに没頭出来るはずです。１分間に書けた行数が、没頭できたことを示しているなら、それは設計が出来ていたことを意味するものと判断できます。
逆に、がっかりするような行数であれば、それはコーディングしながら“設計行為”や“分析行為”をしているからであって、設計書の出来が悪いものと判断します。その原因が要求仕様の把握の甘さにあるかもしれませんが、何れにしても「実装」作業の生産性からも、設計書の出来栄えを判断することができます。