私が、いま、TM に関して取り組んでいる課題は、TM の 「個性」 を削ぎ落として、TM を単なる 「文法 （手続き）」 にすることです。TM は、いまでも、そういう状態になっていますが、世間では、TM に対して 「佐藤正美の」 という くだらない形容詞が付着しているようです。その くだらない形容詞を削ぎ落とすために、私は、TM を数学基礎論・言語哲学に照らして、少しでも 「個性的」 と感じられる語彙・文法に対して容赦しないで 「無機質的」 にする作業を進めています。「Ｔ字形 ER手法」 という昔の呼称を TM という言いかたに変えた理由のひとつは、その点にあります。
TM という言いかたは、数学基礎論を学習している人なら、直ぐに 「チューリング・マシーン」 の略語として使われていることを思い起こすでしょう。私は、それを意識して、（「Ｔ字形 ER手法」 の名称を変更するときに、） TM という言いかたを使いました。というのは、データ 設計においても、「チューリング・マシーン」 のように、なんらかの アルゴリズム があることを示すために。
データ 設計では、「解釈」 という語には、以下の 2つの意味があるようです。
（1） 現実的事態に対する 「解釈」
（2） 形式的構成に対する 「解釈」
われわれ システム・エンジニア は、現実的事態を コンピュータ のなかで記述する仕事をしているので、当然ながら、「解釈」 という語の使いかたは、形式的構成に対して適用されるはずです。なぜなら、現実的事態 （事業過程・管理過程） に対する 「解釈」 は、ユーザ が すでに承認して事業を営んでいるのであって──すなわち、そういうふうな 「意味」 を伝達して事業を営んでいるのであって──ユーザ が すでに承認している 「意味」 を システム・エンジニア が勝手に変形できる訳がない。そして、争点になるのは、ユーザ が承認している 「意味」 が妥当かどうか を調べる点です。したがって、ユーザ が使っている 「意味」 に対して形式的構造を与えて、以下の 2点を検証するのが システム・エンジニア の仕事のはずです。
（1） 形式的構造が妥当か。
（2） 形式的構造の値が真か。
そして、形式的構造に対して、「真とされる値が充足しているかどうか」 ということを検証するのが 「解釈」 ということです。しかしながら、システム・エンジニア の多くが、「解釈」 という語を思い違いしているようですね。
形式的構造が妥当であることを確認して はじめて、システム・エンジニア は仕事の起点に立ったことになります。すなわち、形式的構造として記述された現実的事態 （事業過程・管理過程） の やりかた が本当に効果的・効率的かどうかを調べるのが システム・エンジニア の仕事のはずです。
（2008年10月16日）