「専門家であればあるほど、知らないことが多い」という 言いかた は、事実とは正反対のことを言っているように思われるが、正しい。
　たとえば、データベースの専門家は、ウェッブのことを、ほとんど、知らない。専門家は、自らの専門領域の仕事だけでも、手に余っている。専門領域では、「実証」が大切にされる。膨大な事象に対して、１つの手法 （概念） を適用して、もし、手法を適用できない事象があれば、手法を改善しなければならないのか、それとも、事象自体が例外なのか、という点を判断しなければならない。
　仮説を実証するためには、理論と事象の両方に精通していなければならない。

　実務家 （practitioner） が恵まれている点は、膨大な「生の」材料 （事象） を、日々、扱うことができる、という点である。したがって、実務家 （practitioner） は「理論」を熟知していなければならない。なぜなら、精神は、それが対象とする仕事を、高所からコントロールしなければならないから。
　エンジニアは、仕事のなかで、具体的な技術に対して熱中するので、往々にして、自らが体得している技術以外のことを認めようとしない傾向がつよい。言い換えれば、自らが知っている以上の知識を獲得しようとしないで、自らが体得している技術によって束縛されてしまうのである。

　エンジニアの良識とは、「事実」を立脚点にする点にある。たしかに、「事実」や「体験」に任せておけば、技術は、「現実」から遊離しない。エンジニアは、文章のなかで記述されている概念のなかに、「訳のわからない 戯言」がふくまれている、と思う傾向がつよい。
　しかし、事象は「事実」ではない。「事実」は１つの判断である。そもそも、知的労働には、相反する２つの性質が帰属している。１つは「集中 （charge）」であり、もう１つは「拡散 （discharge）」である。
　技術を実地に適用するためには、精神を集中しなければならない。しかし、いっぽうでは、仕事から、一歩、離れて、技術の適用の是非を判断する余裕がなければならない。

　「事実」が１つの判断であるかぎり、事象を、どのようにして形式化するのか、という点は、エンジニアの価値観に委ねられる。しかし、形式化された構造が、１人のエンジニアの価値観を回避するためには、理論的な整合性がなければならない。理論的な整合性があれば、ほかの人たちも、合意することができる。
　その意味において、エンジニアは「理論」に精通していなければならない。なぜなら、我流を回避するために。

　１人のエンジニアが、システムの「すべて」を熟知することはできないのであるから、１つのシステムを作るためには、それぞれの専門領域のエンジニアたちが集まってプロジェクトを編成することになる。プロジェクトでは、それぞれの専門領域は、理論的に整合的な （したがって、合意された） やりかたを前提にしているはずである。こういう やりかた をすれば、エンジニアに特有な自尊心が、自らの仕事ばかりに集中しないで、共同作業に注がれ、「協業」という喜びを味わうことができるはずである。
　したがって、「私」が主語ではなくて、「我々」が主語になる。なぜなら、個人の力量が前提とされないで、整合的な理論を前提にした技術が論点になるはずだから。
　しかし、現実のプロジェクトは、悲しいことに、そうにはなっていない。

　プロジェクトを管理するために、プロジェクトの管理技法を「制度化 （あるいは、標準化）」することは無駄とは言わないが、第一義ではないことは確かである。従来からも、プロジェクトは管理されてきた。従来のプロジェクト管理が成功しなかった理由は、プロジェクト管理の手続きが標準化されていなかったからではない。システムを作る技術が「整合的な理論を前提にした」技法ではないから、プロジェクトのなかで、それらの技術を集成しても、プロジェクトが成功しないのである。

　プロジェクトの破綻は、プロジェクト管理が原因ではない。job-analysis や データ設計が「整合的ではない」から、プロジェクトが破綻しているのである。整合的な設計図がない、という点が問題点なのである。にもかかわらず、エンジニアの技術力が低下して、エンジニアが基本的な問題点を論点にできなくなって、ドキュメントの作成ばかりを論点にしているのは本末転倒である、と思う。

　（2003年11月2日）