データ 設計では、いわゆる 「トップダウン 手法と ボトムアップ手法」 がありますが、私は、トップダウン 手法を--CSF （Critical Success Factor） を取り込んで procedure まで詳細化する （ホランド氏 が示した） やりかたを除いて--信頼していない。特に、ER 図 （Entity-Relationship Diagram） を トップダウン で作成することに対して、私は、エンジニアとして、納得しかねる点を感じています。たとえば、「事業過程のなかでは、要 （かなめ） の モノ として 「商品」 entity があるよね」 などと、おおざっぱな ER 図を描くことを私は、皆目、納得できない。というのは、「その事業のなかで、どういう モノ が 『商品』 とされ、どういう モノ が 『商品』 とされないのか」 という定義がないままに、「商品」 が記述されて、転 （うた） た、ER 図が 「構成」 され、データ 設計 （あるいは、「要件定義」 とか 「基本設計」 とか） が漫然と進んでゆく様を観て、私は、エンジニア として、唖然としますし、憤怒さえ感じます。
そういう おおざっぱな 「分析」 などは、喩えてみれば、「われわれは、食事して、排便するんだよね」 「そうそう、そうだよね」 という、当然な・一般的な ことがら を しゃべっているにすぎない会話と同じでしょう。その会話でしゃべられていること （「食事して、排便する」 こと） は 「事実」 だし、だれも、反例を示すことができないけれど、こういう会話を 「対象を分析して、協議して、同意に至る」 会話とは云わないでしょう。たとえば、「要の モノ」 として 「商品」 が 「暗黙のうちに」 示されたとしても、「商品」 には商品番号が付与されていて、もし、オプション 品には、部品番号が付与されていて、オプション 品も単独で セールス されていれば、「商品」 概念のなかには、オプション 品も入るでしょう。「要の モノ」 としての 「商品」 が、実 データ （商品番号を付与された データ） の外延 （集合） を云うのか、それとも、カテゴリー （述語） として、そういう性質をもつ対象を概念的・包括的に構成しているのか--したがって、そういうときには、オプション 品も 「商品」 になるのですが--、きちんと協議されないまま、荒っぽい絵を描くことは、およそ、「分析 （あるいは、設計）」 の名に値しないでしょう--たとえ、詳細設計に先立つ 「基本」 設計だと言っても。なぜなら、「基本」 であればこそ、「前提」 を正しく定立しなければならないから。「基本」 というのは、「おおざっぱ」 という意味ではないでしょうに。
（2007年11月16日）