2005年 1月 1日 作成 モデル (指示規則) >> 目次 (テーマ ごと)
2009年 2月 1日 補遺  


 
 モデル として、意味論のなかで、中核になる規則が、「指示規則」 である。すなわち、「対象的事実と (モデル のなかで使われている) 記号との指示関係」 が、「一意的に」 示されていなければならない。

 事業過程 (あるいは、管理過程) を対象的事実とした モデル では、記号は、自然言語を使って記述される。つまり、モデル では、データ (データ 構造のなかに収録される データ) は、基本的に、値の真理性を実現していなければならない。「真」 概念には、おおまかに言えば、以下の 2つがある (カルナップ 氏が示した 「真」 概念)。

 (1) F-真 (対象的事実と対応できる)
 (2) L-真 (F-真を前提にして、導出規則のなかで構成される)

 「F-真」 概念を扱う際に、(ポパー 氏が示した) 以下の 「3つの世界」 のあいだに成立する相互作用が論点になる。

 (1) 第 1世界 (対象的事実)
 (2) 第 2世界 (認識主体)
 (3) 第 3世界 (モデル)

 第 1世界と第 2 世界のあいだには、相互作用があり、第 2世界と第 3世界のあいだにも、相互作用がある。すなわち、第 1世界 (観察現相) と第 3世界 (定式化された統一相) の対応関係 (指示関係) は、第 2世界 (認識主体) の観察系のなかで記述される。したがって、間主観的な 「統一的な認知規則」 がなければ、モデル は、たとえ、定式化されても、間主観的に、様々な構造となる。

 事業過程 (購買過程、生産過程、販売過程、労務過程、財務過程) の管理は、管理過程 (購買管理、生産管理、販売管理、労務管理、財務管理) として整えられていて、事前報告・経過報告・事後報告という情報伝達のなかで、経営が運営されている。管理過程は、事業過程が効果的・効率的に運営されるように、長年に及んで、経営過程として、改善され整えられてきたのであって──企業のなかの膨大な歴史的暗黙知が、環境変化に対して適用してきたのであって──、少数の システム・エンジニア の 「視点 (観測系)」 を立脚点にして、記述できるほど単純な対象的事実ではない。そういう対象的事実を記述するのであれば、モデル は、少なくとも、事業過程のなかに関与している従業員たちが、「真」 (F-真および L-真) として認める構造を提示しなければならない。

 事業過程は、混沌とした 1つの 「行為」 であるが、モデル は、それを 「モノ と関係」 から構成される 「構造」 として記述する。つまり、モデル は、「生の」 現象を、「閉じた」 体系として記述する。逆説的な言いかたになるが、事業過程が管理過程として写像されるのではなくて、管理過程が、事業過程を定義しているのである。従業員という概念は、事業過程のなかで感知されるのではなくて、管理過程のなかで認知される。

 とすれば、事業過程を対象にして、少数の システム・エンジニア が、「モノ と関係」 を認知することは、無意味である。我々 システム・エンジニア が、事業を対象にした システム を作る際に、まず、知っていなければならない点は、管理過程のなかで、事業過程が、いかにして、管理されているか、という点である。したがって、管理されている対象 (モノ と関係) は、システム・エンジニア の観測系のなかで記述できる対象ではない。

 管理過程は、事前報告・経過報告・事後報告のなかで運営されている。とすれば、我々 システム・エンジニア が、「モノ と関係」 の構造を作るなら、事前報告・経過報告・事後報告を対象にすればよい、ということになる。管理過程のなかで記述されている対象 (自然言語を使って記述されている概念) は、事業過程のなかに関与している対象 (現実の事態) と指示関係が成立している。

 事業過程および管理過程を、それぞれ、集合として考えれば、2つの集合は、おおかた、まじわるが、かならずしも、一致しない。その まじわりのなかで、「F-真」 としての指示関係が実現されていなければならない。管理過程が、事業過程との指示関係を的確に示すために使われている手段が、コード 体系である──ただし、コード 体系は、個体を認知する コード のほかに、(コンピュータ を使うことを前提にすれば、) データ 入力の簡便性を実現するために導入されている コード もあれば、情報を保護するために導入されている暗号もふくまれている。しかも、コード 体系のなかで使われている コード が、かならずしも、効果的・効率的ではないことも起こっている。

 管理過程が事業過程を コントロール しているのであれば、事業過程のなかに関与している人たちが、管理過程のなかで記述されている対象を、事業過程のなかで認知できるはずである──そういう指示関係が成立していなければ、事業過程を運営できない。
 とすれば、管理過程のなかで使われている記述に対して、モデル として、「モノ と関係」 の構造を作って、事業過程との指示関係 (「F-真」 概念) を実現すれば良い、ということになる。そうすれば、さきほど述べた ポパー 氏の 「第 2世界 (認識主体)」 を排除することができる (システム・エンジニア の恣意性を排除することができる)。



[ 補遺 ] (2009年 2月 1日)

 事業過程・管理過程を システム 化する際、以下の 2つの 「解釈」 が入り込んできます。

 (1) 現実的事態に対する 「解釈」
 (2) モデル に対する 「解釈」

 いわゆる 「分析段階」 と云われている段階では、従来、(1) を重視して、システム・エンジニア の理解力に依存した作業がおこなわれてきましたが、現実的事態に対する 「解釈」 というのは、すでに、事業過程・管理過程に関与している人たちのあいだで終わっています。したがって、システム・エンジニア が、現実的事態を 「解釈」 するというのは、所詮、二次的な所作であって、しかも、システム・エンジニア の理解力次第で、すでに運用されている 「意味」 が曲解されることが多々起こっています──エンドユーザ が 「椅子」 を設計してほしいにもかかわらず、システム・エンジニア が 「便器」 を作ってしまうという悲劇 (喜劇?) が ざらに起こっています。

 事業過程・管理過程は、「情報」 を伝達して営まれているので──しかも、その 「情報」 の 「意味」 は、すでに、ユーザ のあいだで定立されているのであって──、システム・エンジニア が どうこう変形できる訳ではないでしょうね。とすれば、システム・エンジニア がやるべき仕事は、ユーザ の言語を変形しないで、その言語 (自然言語) で伝えられている 「意味」 に対して、形式的構造を与えて、運営されている事業の 「意味」 の善し悪しを判断すべきでしょう。したがって、システム・エンジニア がやるべき 「解釈」 というのは、現実的事態に対する 「解釈」 ではなくて、自然言語を形式的言語に翻訳したのちに、形式的構造のなかに現れる 「構造の妥当性」──すなわち、事業の強み・弱み、さらに、事業の環境適応力──を問うべきでしょう。それが、「モデル に対する 『解釈』」 ということです。「モデル に対する 『解釈』」 というのは、狭義には、モデル として記述された事態を現実的事態と対比してみて、虚構・隠蔽・改竄がないことを験証する作業ですが、システム・エンジニア の仕事では、それ (モデル と現実的事態との指示関係を調べること) は起点にすぎない。ただ、従来の やりかた では、その起点すら揺らいでしまっているのが問題点なのです。モデル における 「真」 という概念は、ひとり (あるいは、複数・多数) の システム・エンジニア の 「解釈」 で揺らぐ代物ではないでしょう。「現実的事態を 『正確に』 記述して」 はじめて、潜在的な問題を感知できて、その潜在的問題点に対して ソリューション を考えることができる、という当たり前のことを外した、システム・エンジニア の描いた ポンチ 絵では なんら 「分析 (job-analysis)」 にはならないでしょうね。





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