2022年11月 1日 「1.5 ユーザが使っている「意味」を...」 を読む >> 目次に もどる


 本節は、SE たちから そうとうに反論が出ることを私は事前に推測していました www. というのは、SE たちは、自分たちが モデル を作成するのだという強い自負を抱いているし、実際 いわゆる 業務 モデリング の要件定義では SE たちが業務について ユーザ に聞き取りをして モデル (?) を作成するということが広く実施されているからです。そういう やりかた を、私は SE たちの自惚れだと思っていて、本節では真っ向から否定しています。本書は、モデル を次のように定義しています──

    モデル とは、「事実」 (現実的事態) を写像した形式的構造である。

 「事実」 は一つしかない、そして それについての 「解釈」 は多数──その 「事実」 を観た人の数ぶん──存する。SE がユーザから聴取したとしても、SE が有している知識 (Frame of Reference) によって、SE ごとに様々な 「解釈」 が生じます。事業過程・管理過程では、ユーザ は 「情報」 (原帳票などの管理資料) を共有して (ことば の) 「意味 (meaning)」 を伝達しています。すなわち、「情報」 に記載されている ことば (文字列) の 「意味」 は、事業のなかで ユーザ が合意して共有しています──ことば の 「意味」 は、事業という文脈 (生活様式) のなかで定立されています。言語使用での この状態を 「意味の使用説」 と云います。その生活様式 (文脈) を共有していない SE が そこで使われている ことば の 「意味」 を正確に把握できる訳がない。そういう状態のままで要件定義と称して ユーザ から ことば の 「意味」 を聴取しても行き違いが起こるのは当然でしょう。

 モデル は、「事実」 を写像する際に、その 「事実」 (現実的事態、すなわち事業) を記述している (かつ、ユーザ が共有している) 「情報」 (原帳票などの管理資料) を対象にしています。「情報」 のなかでは、ことば と 値 (言い替えれば、「意味」) は 「1-対-1」 対応しています。すなわち、ことば が値を 「名指し」 しています。言語使用での この 「意味 (sense)」 状態を 「意味の対象説」 と云います。ただし、それぞれの 「情報」 (原帳票などの管理資料) は、その 「情報」 のなかでしか記述されていない断片的な 「意味」 なので、その断片的な 「意味」 を事業構造 (すなわち、文脈) のなかで記述する (言い替えれば、座標を与える) のが モデル を作成する目的なのです。

 写像は、変換とか関数とも云い、形式的構造は当然ながら 「論理」 を使って構成されます。したがって、原像 (事業過程・管理過程) と写像された形式的構造のあいだで、写像規則が示されていれば、SE の個人的 「解釈」 など介入する余地はないでしょう。それが論理的意味論と云うことです。だから、私は、モデル 作成において、SE の個人的 「解釈」 (価値判断) など無用だと言っているのです。

 TM は、既存の事業を分析するための モデル 作成技術であって、新規の事業をつくる場合には使えない、と言った SE がいました。そんな戯言を ざっと言わないでください、新規事業を対象にする場合であっても、事業の プロセス (ワークフロー) を設計して、それぞれの プロセス のなかで使う 「情報」 (原帳票などの管理資料) が設計されたら、TM は なんら支障なく使うことができます。そして、事業 プロセス や 「情報」 の設計には SE が関与しなければならない (ときには、主導しなければならない) と言っている SE が多いようですが、冗談言っちゃいけない、SE が事業を机上で大雑把に考えていると、あたかも 事業を設計できるように思うらしいけれど、それは 事業のなかの事細かな手続きを実際にやったことのない SE の自惚れです、事業の設計は ユーザ の仕事です──事業のなかの個々の手続きを SE が設計できる訳がない。事業 (事業過程・管理過程) のなかで生起存在する モノ (事態・事物) を コンピュータ 向けの対象 (データ) にするのが システム・エンジニア の使命でしょう。 □

 




  << もどる HOME すすむ >>
  目次にもどる