道理に合わないからといって、世間に長い間ならわしとなって
　　　　いる事柄を、急にやめようとするのはいけない。ただその欠点
　　　　だけを除くようにし、現にある物事はそのままにしておいて、
　　　　真実の道を探求すべきである。
　　　　万事を、むりやり道理にしたがってなおし、実行しようとする
　　　　のは、かえって本当の道の精神に合致しないことがある。（略）

　ちなみに、宣長の謂う 「道」 は 「古学 （やまとたましいの追究）」 ですが、ここでは、なんらかの範囲のなかで 「正しい （真）」 とされること というふうに翻訳しておきましょう。さらに、私 （佐藤正美） の仕事 （モデル の作成） で云うならば、「正しい （真）」 ことというのは、以下の 2つの 「真」 を実現している状態である、としておきます。

　　（1） 無矛盾性 （L-真）
　　（2） 完全性 （F-真）

　（1） は、いくつかの 「公理」 を前提にして矛盾しない文法に従って導出された 「妥当な構造」 のことを云い、（2） は、その構造のなかに値を入れたときに現実的事態と一致している──言い換えれば、虚構・隠蔽・改竄がない──状態 [ 真とされる値が充足されている状態 ] を云います。モデル では、（1） は 「生成規則」 として、（2） は 「指示規則」 として構成要件とされています。すなわち、これらの規則を完備している状態が 「正しい」 モデル です。

　さて、上述した 「正しい」 モデル の観点に立って、システム 設計で使われている （と思われる） 種々の やりかた──たとえば、DFD （Data Flow Diagram） とか ERD （Entity-Relationship Diagram） など──を検討してみれば、それらの やりかた が モデル ではないことがわかるでしょう。言い換えれば、「形式化」 の技術ではないことがわかるでしょう。というのは、それらは、（「形式化」 において、「L-真」 を担保するはずの)　生成規則をもっていないから。それらの やりかた は、（diagram という呼称が示しているように、） いわゆる 「見える化」 のための図であって、モデル ではない。私は、ここで、DFD・ERD の欠点を事細かに述べるつもりはないのですが、ひとつだけ付言しておけば、DFD は 「全順序 （線形順序）」 を記述するには向いているけれど、「全順序」 に関与する個体を記述しないし、ERD は 「半順序」 の構成なので、「全順序」──たとえば、事業の プロセス──を把握しにくい。しかし、現実的事態を形式化しようとすれば、「全順序」 と 「半順序」 のふたつとも記述しないと 「完全性」──現実的事態と一致した状態──を実現できない。

　DFD や ERD が実際の設計において使われているのかと云えば、（たぶん、政府関係の入札のほかでは、） 私の観るかぎりでは、ほとんど使われていないようです [ UML も、同じような状態にあるようです ]。そして、モデル も ほとんど使われていない。DFD らしき物や ERD らしき物は、いくぶんか使われているようです。

　そういう無法状態のなかで、モデル を導入しようとすれば、かならず、抵抗されます。その抵抗を撃破しようと向きになれば、モデル を過大に賞賛してしまい 「かえって本当の道の精神に合致しない」 状態に陥る危険性が高い。したがって、そういう抵抗を撃破しようと躍起にならないで、ロジック の正当性を落ち着いて説得するほうがいいでしょうね──ロジック の正当性は、だれも否定できないのだから。もし、ロジック の正当性を否定する ひとがいるとしたら、たぶん、そのひとは （今まで我流で通してきたが故に、） じぶんが今まで享 （う） けてきた 「既得利権」 を喪うのが嫌で抵抗しているのでしょう。そういうひとにとって、「真」 というのは、そもそも、邪魔でしかない。というのは、じぶんの便益を優先的に認めて、システム が ユーザ に貢献することなんか考えてもいないのだから。「ビジネス では、論理的に正しいことのみが通る訳ではない」 というような言い古されてきた （stereo-type の） 譫言を今更ここで向きになって反論するつもりは私には更々ない。

　
（参考）　「本居宣長集」 （日本の思想 15）、吉川幸次郎 編集、筑摩書房、大久保 正 訳。

　
　（2010年 1月23日）