2005年 1月 1日 作成 | モデル (指示規則) | >> 目次 (テーマ ごと) |
2009年 2月 1日 補遺 |
事業過程 (あるいは、管理過程) を対象的事実とした モデル では、記号は、自然言語を使って記述される。つまり、モデル では、データ (データ 構造のなかに収録される データ) は、基本的に、値の真理性を実現していなければならない。「真」 概念には、おおまかに言えば、以下の 2つがある (カルナップ 氏が示した 「真」 概念)。
(1) F-真 (対象的事実と対応できる) 「F-真」 概念を扱う際に、(ポパー 氏が示した) 以下の 「3つの世界」 のあいだに成立する相互作用が論点になる。
(1) 第 1世界 (対象的事実) 第 1世界と第 2 世界のあいだには、相互作用があり、第 2世界と第 3世界のあいだにも、相互作用がある。すなわち、第 1世界 (観察現相) と第 3世界 (定式化された統一相) の対応関係 (指示関係) は、第 2世界 (認識主体) の観察系のなかで記述される。したがって、間主観的な 「統一的な認知規則」 がなければ、モデル は、たとえ、定式化されても、間主観的に、様々な構造となる。 事業過程 (購買過程、生産過程、販売過程、労務過程、財務過程) の管理は、管理過程 (購買管理、生産管理、販売管理、労務管理、財務管理) として整えられていて、事前報告・経過報告・事後報告という情報伝達のなかで、経営が運営されている。管理過程は、事業過程が効果的・効率的に運営されるように、長年に及んで、経営過程として、改善され整えられてきたのであって──企業のなかの膨大な歴史的暗黙知が、環境変化に対して適用してきたのであって──、少数の システム・エンジニア の 「視点 (観測系)」 を立脚点にして、記述できるほど単純な対象的事実ではない。そういう対象的事実を記述するのであれば、モデル は、少なくとも、事業過程のなかに関与している従業員たちが、「真」 (F-真および L-真) として認める構造を提示しなければならない。 事業過程は、混沌とした 1つの 「行為」 であるが、モデル は、それを 「モノ と関係」 から構成される 「構造」 として記述する。つまり、モデル は、「生の」 現象を、「閉じた」 体系として記述する。逆説的な言いかたになるが、事業過程が管理過程として写像されるのではなくて、管理過程が、事業過程を定義しているのである。従業員という概念は、事業過程のなかで感知されるのではなくて、管理過程のなかで認知される。 とすれば、事業過程を対象にして、少数の システム・エンジニア が、「モノ と関係」 を認知することは、無意味である。我々 システム・エンジニア が、事業を対象にした システム を作る際に、まず、知っていなければならない点は、管理過程のなかで、事業過程が、いかにして、管理されているか、という点である。したがって、管理されている対象 (モノ と関係) は、システム・エンジニア の観測系のなかで記述できる対象ではない。 管理過程は、事前報告・経過報告・事後報告のなかで運営されている。とすれば、我々 システム・エンジニア が、「モノ と関係」 の構造を作るなら、事前報告・経過報告・事後報告を対象にすればよい、ということになる。管理過程のなかで記述されている対象 (自然言語を使って記述されている概念) は、事業過程のなかに関与している対象 (現実の事態) と指示関係が成立している。 事業過程および管理過程を、それぞれ、集合として考えれば、2つの集合は、おおかた、まじわるが、かならずしも、一致しない。その まじわりのなかで、「F-真」 としての指示関係が実現されていなければならない。管理過程が、事業過程との指示関係を的確に示すために使われている手段が、コード 体系である──ただし、コード 体系は、個体を認知する コード のほかに、(コンピュータ を使うことを前提にすれば、) データ 入力の簡便性を実現するために導入されている コード もあれば、情報を保護するために導入されている暗号もふくまれている。しかも、コード 体系のなかで使われている コード が、かならずしも、効果的・効率的ではないことも起こっている。
管理過程が事業過程を コントロール しているのであれば、事業過程のなかに関与している人たちが、管理過程のなかで記述されている対象を、事業過程のなかで認知できるはずである──そういう指示関係が成立していなければ、事業過程を運営できない。
|
[ 補遺 ] (2009年 2月 1日)
事業過程・管理過程を システム 化する際、以下の 2つの 「解釈」 が入り込んできます。
(1) 現実的事態に対する 「解釈」 いわゆる 「分析段階」 と云われている段階では、従来、(1) を重視して、システム・エンジニア の理解力に依存した作業がおこなわれてきましたが、現実的事態に対する 「解釈」 というのは、すでに、事業過程・管理過程に関与している人たちのあいだで終わっています。したがって、システム・エンジニア が、現実的事態を 「解釈」 するというのは、所詮、二次的な所作であって、しかも、システム・エンジニア の理解力次第で、すでに運用されている 「意味」 が曲解されることが多々起こっています──エンドユーザ が 「椅子」 を設計してほしいにもかかわらず、システム・エンジニア が 「便器」 を作ってしまうという悲劇 (喜劇?) が ざらに起こっています。 事業過程・管理過程は、「情報」 を伝達して営まれているので──しかも、その 「情報」 の 「意味」 は、すでに、ユーザ のあいだで定立されているのであって──、システム・エンジニア が どうこう変形できる訳ではないでしょうね。とすれば、システム・エンジニア がやるべき仕事は、ユーザ の言語を変形しないで、その言語 (自然言語) で伝えられている 「意味」 に対して、形式的構造を与えて、運営されている事業の 「意味」 の善し悪しを判断すべきでしょう。したがって、システム・エンジニア がやるべき 「解釈」 というのは、現実的事態に対する 「解釈」 ではなくて、自然言語を形式的言語に翻訳したのちに、形式的構造のなかに現れる 「構造の妥当性」──すなわち、事業の強み・弱み、さらに、事業の環境適応力──を問うべきでしょう。それが、「モデル に対する 『解釈』」 ということです。「モデル に対する 『解釈』」 というのは、狭義には、モデル として記述された事態を現実的事態と対比してみて、虚構・隠蔽・改竄がないことを験証する作業ですが、システム・エンジニア の仕事では、それ (モデル と現実的事態との指示関係を調べること) は起点にすぎない。ただ、従来の やりかた では、その起点すら揺らいでしまっているのが問題点なのです。モデル における 「真」 という概念は、ひとり (あるいは、複数・多数) の システム・エンジニア の 「解釈」 で揺らぐ代物ではないでしょう。「現実的事態を 『正確に』 記述して」 はじめて、潜在的な問題を感知できて、その潜在的問題点に対して ソリューション を考えることができる、という当たり前のことを外した、システム・エンジニア の描いた ポンチ 絵では なんら 「分析 (job-analysis)」 にはならないでしょうね。 |
<< もどる | ベーシックス | すすむ >> | |
▼ データベースの基礎知識 |