2005年 7月16日 作成 「規則に従う」 ということ >> 目次 (テーマ ごと)
2009年 8月16日 補遺  


 
 「論理 データベース 論考」では、ウィトゲンシュタイン 氏の後期哲学 (「言語 ゲーム」 の思想) を、以下のように、総括している (172ページ)。

  9. 5. 2 反-私的言語
   人は規則に 「私的に」 従うことはできない。コード 体系に従う限りにおいて、私的な言語は成立しない。

  9. 5. 3 行為 ≡ 規則
   規則 (コード) が行為 (ビジネス) を規制するのではなくて、行為が規則である。「規則に従う」 ということは実践である。

 
 これらの文のみを読んで、ウィトゲンシュタイン 氏の 「言語 ゲーム」 概念を、すぐに、理解できる人は、まず、いないでしょうね。これらの文は、ウィトゲンシュタイン 氏の哲学を、そうとうに知っていることを前提にして綴られている。
 したがって、9. 5. 3 を、そのまま (字句どおりに) 読めば、コード を起点にしている TM の基本思想と相反するように感じられるかもしれない。

 ウィトゲンシュタイン 氏が示した 「規則に従う」 という概念を、クリプキ 氏は、「規則に従うことを一人だけ孤立した状態」 と 「共同体の状態」 の 2つの状態を、丁寧に検討して、「共同体のなかで、『規則に従う』」 ことに対して、以下のように、的確な解釈を与えている。(参考)

 (1) 教師は、生徒に、彼は自分自身が与えるであろう答えと同じ答えを与える、と判断している。
 (2) 教師は、生徒に、彼は自身が適用しようとしている やりかた と同じやりかたを適用している、と判断している。

 つまり、「反応と適用」 を観て判断する、ということである。
 そして、ウィトゲンシュタイン は、「言語像」 として、真理条件──「言明」 が 「事実」 と一致することを前提にした 「真」 概念が成立する条件──ではなくて、言語可能性条件 (あるいは、正当化条件) を探究していたのである。
 そのために、TM は、まず、事業過程のなかで使われている言語──それは、管理過程として、フォーマル に、共同体のなかで、伝達される情報として示されるが──を対象にしているのである。言い換えれば、事業のなかで使われている言語が、それに関与している人たちの (共同体的営みに対する) 「適用と反応」 を示す規準なのである。

 しかも、事業のなかで使われている言語は、適用上、多様に入り組んだ mechanism (膨大な暗黙知や詳細な法的規制など) を前提にしている。事業過程のなかで、管理対象となっている事態に対しては、できうるかぎり、「F-真」 が崩れないように、「事実」 と 「情報 (記録)」 とのあいだには、照査が組み込まれているが──たとえば、入庫では、商品と入庫伝票を照査するとか──、その照査は、かならずしも、「情報の真実性」 を保証する訳ではない。
 たとえば、入庫された商品 20個に対して、入庫伝票の数量が 20個となっていても、そのなかから、2個を抜き取って、減耗損として、2個を減算すれば、「情報」 と 「事実」 との指示関係は正しいが、「事実」 そのものが 「虚構」 であることを、「情報」 を観て、判断することはできない。当然ながら、「虚偽」 が入り込まないようにするために、照査制度を周到に組織して、監査上、内部牽制組織として、一人の入庫係が減耗を記録することを禁止することは考えられるし、そういうふうに内部牽制組織が作られている、と思う。

 さて、そういう内部牽制組織が、もし、欠如しているとすれば、そういう内部牽制組織が導入されなければならないことを、システム・エンジニア が、わずか、半年ほど、エンドユーザ の事業過程を、「直に」 観察して──あるいは、エンドユーザ と面談しながら、事業過程を記述しようとして──思い浮かぶだろうか。

 そういう内部牽制組織が導入されていなければならない、ということは、システム・エンジニア が、「あらかじめ」、知識として習得していなければならない点なのである。事業過程を 「直に」 観て、そのやりかたの不備──ここでは、内部牽制組織の欠如──を思い浮かぶ訳ではない。「事実」 そのもの-の 「虚構」 (あるいは、「隠蔽」) は、「情報」 を観てもわからないので、事業過程そのものを 「直に」 観察しなければならない、というのは幻想にすぎない。というのは、「事実」 が 「虚構」 であった、ということは、事後に露呈することであるから──したがって、産業的・組織的な虚偽事件では、容疑のほうが、現行犯 (caught in the act) に比べて多い、と思われる (しかも、「虚構」 が、周到に仕組まれていればいるほど)。実際には、(「F-真」 を前提にして──「事実」 と 「情報」 が照査されていることを前提にして、) 「情報」 のなかで、矛盾点や曖昧な点があれば、それらを問う、というのが、ふつうである。ただし、それが唯一の手段であると言うつもりはない。というのは、内部告発もあるから。

 「事実」 と 「情報」 の照査制度は、事業過程と管理過程の相互作用のなかで──法的規制を考慮しながら──導入され熟成されてきた制度であって、そもそも、一人 (あるいは、複数の) システム・エンジニア が、事業過程を観察しながら、良否を判断できるほど単純な構成ではない。そして、「情報の真実性」 を実現するために、いかなる照査制度が、それぞれの事業過程のなかに導入されていて、それらの照査制度は、どのような手続きを実施しなければならないのか、という点は、組織過程のなかで、ドキュメント として用意されている──しかも、それらは、「情報」 である。はたして、システム・エンジニア は、それらの ドキュメント を、すべて、読んで、事業過程のなかで、照査制度が、そのとおりに実施されているかどうか、という点を、(すべての照査制度を対象にして、) 観察するつもりなのだろうか──そういう仕事は、監査人の仕事である。

 事業を営むために伝達されている 「情報」 のなかで、ことばが、どのようにして使われているか、という点を、凝視すればよい。事業過程に関与する人たちのあいだで伝達される (フォーマル な) 「情報」 は、1つの 「言語 ゲーム」 である。その事業のなかで伝達されている 「受注」 の概念を習得したと認められる人は、だれであれ、「受注」 という仕事のなか使われている 「ことばの使いかた」 が、共同体の与える答えと一致したときに、そして、そのときにかぎり、共同体のなかで、「受注」 という仕事を理解していると判断されるのである──もっと、つよい考えかたをすれば、「受注」 の手続きを、実地にやってみて、そのやりかたが、まわりの人たちが考えている 「適用と反応」 と同じであれば、「(「受注」を) 完璧に理解している」 と判断される。それが、小生の著作のなかで 9. 5. 3 として示した意味である。(注意)

 
(参考) 「ウィトゲンシュタインのパラドックス」、黒崎 宏 訳、産業図書。

(注意) ここでは、インフォーマル・システム には言及しない。



[ 補遺 ] (2009年 8月16日)

 本 エッセー では、「システム・エンジニア が 『実際の』 事業過程を 『観て』、システムを──ただし、コンピュータ・システム に限らない──構成する」 ことが不可能であることを述べただけです。にもかかわらず、システム・エンジニア の多くが 「業務分析」 をやっているのは、どうしてかしら (謎)。

 「現実を観る」 と謂っても、様々な視点があります。たとえば、「私を観てください」 と謂ったときに、私の服装を観るのか、私の仕草を観るのか、私の顔つきを観るのか、、、様々な視点があって、捉え所がないでしょう。なにがしかの 「事態」 を観るということは、なにがしかの 「判断 (あるいは、解釈)」 を おこなうということであって、そういう 「判断 (あるいは、解釈)」 を おこなうためには、「事前に、なんらかの知識がなければならない」 でしょう。つまり、被定義項に対しては、定義項がなければならない、ということ。もし、システム・エンジニア たちが、そういう前提を無視するのであれば、事業過程に対して 「管理過程を すべて 改めて構成する」 という、およそ非現実的な企てをやろうとしていることになるでしょう。

 本 エッセー のなかで述べた 「適用と反応」 を、事業過程において システム・エンジニア が期待されている訳ではない──その 「適用と反応」 は ユーザ の仕事です。われわれ システム・エンジニア の仕事は、ユーザ が営んでいる事業過程が 「妥当」 なのかどうかを調べることであって、したがって、ユーザ が事業を営むために伝達している 「情報」 を定義項にして、事業過程を被定義項にするしかないでしょう。すなわち、「情報」 を input にして、なんらかの 「形式的構成」 を作って、その 「形式的構成」 が実際の事態と一致しているかどうかを調べて、さらに、その 「形式的構成」 が事業環境の変化に適応できるかどうかを調べるのが われわれ システム・エンジニア の職責であるはずです。

 事業過程を対象にした 「解釈」 には、以下の 2つがあります。

 (1) 現実的事態に対する 「解釈」
 (2) 現実的事態の形式的構成に対する 「解釈」

 現実的事態に対する 「解釈」 は、すでに、ユーザ が おこなっていることであって、われわれ システム・エンジニア が そこに勝手な 「解釈」 を導入することはできない──すなわち、ユーザ が使っている言語を変形することはできない。われわれ システム・エンジニア が おこなう 「解釈」 は、現実的事態を モデル 化した 「形式的構成」 に対する 「解釈」 です。言い換えれば、ユーザ が使っている言語を変形しないで、それに対して できるかぎり機械的に 「形式的構成」 を作って、その 「形式的構成」 が現実的事態と同値であるかどうか [ すなわち、無矛盾性・完全性を実現しているかどうか ] を調べるのが われわれ システム・エンジニア の職責でしょう。その職責を果たすためには、当然ながら、モデル を作る 「文法」 を持っていなければならない。そういう 「文法」 を無視して、ただ、じぶんの目で現実を観て 「解釈」 するというのは、「わがまま (あるいは、道化)」 にすぎないでしょうね。





  << もどる ベーシックス すすむ >>
  データベースの基礎知識