You can't alter facts by filming them over dead romances.
　　　　（Aldous Huxley）

　　　　Realities are less dangerous than fancies.
　　　　Fact-finding is more important than fault-finding.
　　　　 (Carl Lotus Becker)

　これらの文を、私の仕事に照らしてみれば、「dead romances」 とか 「fancies」 というのは、「パターン」 と読み替えてもいいでしょう。「パターン」 を参照項としてのみ使うなら、それなりに役立つのですが、それを、そのまま、現実の世界に適用することに対して、私は、極めて、「生理的な嫌悪感」 を感じます。「生理的な嫌悪感」 というのは、理屈抜きで鳥肌がたつということです。

　ひとりの システム・エンジニア の私智に頼って モデル を作ることに比べたら、（いくつかの事例を材料にして作られた） 「パターン」 は マシ ですが、争点は、その 「パターン」 が どれくらいの数の事例を使って、どのような規則で作られたかという点です。もし、ひとりの システム・エンジニア が、いくつかの事例を材料にして、それらの事例の最大公約数 （あるいは、最小公倍数でも良いのですが） として作ったとすれば、あいかわらず、個人の理解力に頼った恣意性を免れている訳ではないでしょうね。もし、その事例が、2,000とか 30,000 であれば、私は、「パターン」 の有効性を、或る程度、認めますが、100 や 200 の事例を一般化したにすぎないのであれば、標本数が少な過ぎます--なぜなら、わが国の会社数は、二百万社以上あるのだから。

　確かに、モデル は、当初、数少ない--せいぜい、数十くらいの--事例を材料にして作らざるを得ないのですが、モデル として 「一般化された」 構成は、かならず、現実的事態に適用して フィードバック されます。そして、モデル を一般化するときには、一般化という用語が示しているように汎用形 [ ∀x P (x)、すべての ] を、まず、作ることになります。汎用形は、当然ながら、「すべての事態」 に対応できるように--個々の事例を帰納的に集約するのではなくて--、演繹的に作られます。演繹的に作るということは、ロジック の公理系を使わざるを得ないということです。そして、学問 （会計学・生産管理・経営学など） の 「通論」 を参照しなければならないということです。
　ポパー 氏は、モデル の作成過程を以下のように巧みに図式化しました。

　　　　P₁　→　TT　→　EE　→　P₂

　P₁は、思考対象となった問題点です。P₁からはじまって、TT という 「暫定的な ソリューション （あるいは、理論）」 に進みます。TT は、部分的あるいは全体的に、間違った理論かもしれない。そして、EE という 「誤り排除」--すなわち、実験的 テスト や験証や反証--の篩 （ふるい） にかけられます。TT として示された 「暫定的な ソリューション （あるいは、理論）」 は、演繹的に作られます。

　もし、学問の 「通論」 を学習するのが厭わしいので、「パターン」 を、そのまま、流用したがるのであれば、言い換えれば、現実的事態を軽視して、「パターン」 を借用するのであれば、「楽 （らく） した」 ぶんの--「手抜き」 したぶんの--対価 （犠牲） を払わなければならないのは当然でしょう。

　
　（2007年 9月16日）