前回の 「『真』 概念 （その 1）」 （376 ページ） で、TM （Ｔ字形 ER手法の改良版） の手続きは、以下の手続きであることを 「完全性」 「健全性」 の観点から説明しました──その ページ のほかにも、この手続きは、本 ホームページ のあちこちで説明しています。

　　　「合意」 された認知 → 「L-真」 の構成 → 「F-真」 の験証

　この手続きのなかで最初の段階となっている 「『合意』 された認知」 という概念を本 エッセー で説明しています。
　さらに、システム 設計において、「解釈」 が front-end に出てくる局面として、以下の ふたつの局面が考えられるでしょう。

　（1） 現実的事態に対する 「解釈」
　（2） モデル （形式的構成） に対する 「解釈」

　従来の システム 設計では、「要件定義」 として、（1） が重視されてきました。すなわち、システム・エンジニア が現実的事態 （事業過程） を観て、（「業務分析」 と称して、） 事業の構成を記述して、さらに、エンドユーザ に対して ヒアリング を実施して改善要望を聴いて、新 システム の要件を まとめるという やりかた を （1960年代から） 踏襲してきました。しかし、こういう やりかた を続けてきて明らかになった点の ひとつは、新 システム が導入されたあとの メンテナンス の 64％ は、「分析・設計」 段階の ミス だった、という点です [ この数値は、1980年代なかばに、マーチン J. 氏が調査報告した数値で古いのですが、現代でも、ユーザ の意見を聞いた感じでは──あくまで、印象にすぎないのですが──この数値が低くなっていないようです ]。すなわち、システム・エンジニア が ユーザ の要件を正確に把握できていないという点が明らかにされてきました。今後も、こういう やりかた を続けていれば、この数値は改善されることはないでしょうね。

　上述した TM の手続きを図式化すれば、以下の図として表すことができます （368ページ を参照されたい）。

　　　　　　　　　　　　　　　　　　（F-真）
　　┌──────────────────────────────────┐
　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
　　│　　　　　　　　　┌───────┐　　　　　　　　　　　　　　　　│
　　│　　　　　　　　　│　　　　　　　│　　　　　　　　　　　　　　　　│
　　│　　　　　　　　─┘　　　　　　　└─　　　　　　　　　　　　　　　↓
　　y （形式的構造）　←　　　　f　　　　←　x （語彙） ← 「情報」 ← 現実的事態
　　　　　　　　　　　─┐　（L-真）　　┌─
　　　　　　　　　　　　│　　　　　　　│
　　　　　　　　　　　　└───────┘

　事業過程では、「情報 （帳票、画面、レポート など）」 を使って、仕事の 「意味」 が伝えられてきます。そうならば、事業を理解するには、「情報」 を解析すれば良いということになるでしょう──ただし、「情報」 に記載されたことが 「正しい」 かどうか [ 言い換えれば、「情報」 に記載されたとおりに実際の仕事をやっているかどうか ] はわからない。そこで、「現実的事態」 と 「情報」 とのあいだに不一致がないことを以下のように調べれば良いでしょう。

　（1） 「情報」 に対して形式的構成を与える。
　（2） 形式的構成を現実的事態と対比して 「正しい」 ことを験証する。

　すなわち、前述した 「解釈」 では、「モデル に対する 『解釈』」 を重視するということです。そのためには、「情報」 に対して形式的構成を与えるときに、以下の 2点を遵守しなければならないでしょう。

　（1） ユーザ が使っている言語を変形しない。
　（2） ユーザ が使っている言語に対して、できるだけ機械的に構成を与える。

　「機械的に構成を与える」 ということは、「論理法則」 を使って構成するということです。しかも、「情報」 に対して形式的構成を与えれば、事業の 「意味」 を正確に理解できるでしょう。言い換えれば、システム・エンジニア の理解力に頼った 「解釈」 は排除されるということです。そして、上述した図のなかで、関数 f （論理法則） を隠蔽すれば、この図式が示していることは非常に単純なことであって、「文として記述されたことが 『真』 であるのは、実際に そういう事態が起こったことを確認すればいい」 ということです。デイヴィドソン 氏風に言えば、「言明 『p』 が真であるのは、時刻 t において、事態 p と一致するとき、そして、そのときに限る」 ということ。